为 AI 的结果负责，究竟要负责什么？

很多 AI 项目的起点，是一个令人兴奋的演示。输入问题，得到答案；上传资料，生成内容。但企业最终要回答的问题更具体：这件事进入日常工作后，究竟改善了什么？

我希望围绕这个问题开展工作。为 AI 的结果负责，需要把“结果”说清楚，再把它放到真实业务中验证。

先确定谁的哪一项工作需要改变

“我们想做 AI”还不足以开始一个项目。“客服同事每天重复回答相同问题，希望缩短处理时间，同时保持回答质量”，已经更接近可以验证的目标。

接下来还要问：问题来自哪些渠道？现有回答依据是什么？哪些情况必须由人处理？谁会真正使用这个方案？

如果这些问题没有答案，我会先梳理流程。技术选型应当建立在对工作的理解之上。

为目标找到当前基线

要判断是否改善，需要先了解现在的表现。一次任务花多少时间？包括哪些步骤？返工出现在哪里？团队实际投入了多少人力？

这不一定需要一套复杂的数据系统。可以从有代表性的任务记录开始，但需要说明样本的选择、覆盖范围和局限。

没有基线时，先建立基线。这样才能避免上线后只凭印象判断成败。

在试点前约定怎样验收

以回复辅助为例，只看生成速度并不够。还要看答案是否可靠、人工检查需要多久、错误如何处理，以及客户信息是否被适当使用。

一个试点可以同时观察几件事：

• 完成整个任务的时间，包括检查和返工。
• 在约定样本上的质量，以及不可接受的错误。
• 系统使用成本和必要的人工投入。
• 实际使用者能否顺利采用这套流程。

具体指标由业务目标决定。试点开始前，还应该约定：达到什么条件可以扩大，出现什么情况需要调整，哪些问题意味着应该停止。

新问题需要学习，也需要验证

我不会只根据过去使用过的技术决定能解决什么问题。客户的需要可能涉及新的行业知识、工具或实现方式，我需要持续补齐这些能力。

但学习意愿不能代替交付证据。遇到陌生需求，我会先理解业务、查验关键假设，必要时寻找具备相关专业能力的协作者，再通过小范围实验判断可行性。

我会明确哪些是已有经验，哪些已经验证，哪些仍有不确定性。交付承诺应当与证据相匹配。

上线以后，还要看工作有没有真正改变

系统能运行，只说明具备了使用条件。团队是否持续使用、是否增加了新的检查负担、异常有没有人接手，都影响最终效果。

因此，上线需要明确使用说明、人员责任和维护安排。复盘时，要把实际效果与原来的目标放在一起看。

如果没有达到预期，需要检查原因。问题可能来自样本不代表实际工作、流程衔接不顺，或者最初选择的场景就不适合。找到原因后，才能决定继续改进还是停止投入。

我愿意承担的责任

我愿意把目标讲清楚，把方案放进实际工作验证，如实说明结果，并对约定范围内的交付、改进和交接负责。具体的目标、验收和责任范围，需要在每次合作中明确。

这也是我做这个网站的起点：让需要帮助的企业看清我的判断方式、实践过程和交付方法，再决定是否一起推进。