企业 AI 项目，不要停在「已完成」：用证据判断下一步

「失败」会让人警觉，「已完成」却最容易让人放松警惕。

失败会迫使团队停下来处理问题。「已完成」却可能只表示功能做完、文件交付或者任务关闭。它没有回答谁在使用、结果进入了哪一步工作、发生异常时谁来接手，也没有证明业务因此发生了变化。

如果把这些状态压缩成一个词，一个现场演示、一个刚上线的工具和一条稳定运行的流程，就可能被当成三个同等成熟的项目。项目数量没有错，问题在于数量无法代替成熟度。

把「完成」拆成六类证据

我现在会把企业 AI 项目拆成六个可以分别核对的阶段。它们不是行业标准，也不要求所有项目严格按顺序前进；作用是让团队知道当前已经证明了什么。

先说明问题、输入、输出、使用者和责任人。员工提出的痛点可以成为线索，但只有放回完整流程，才能判断它是否值得正式投入。

方案在真实或受控样例上产生了可检查的结果。试点回答「这条技术路线有没有可能工作」，不等于工具已经进入生产，也不等于整条业务流程已经改变。

工具进入真实环境，使用者有明确入口，基本权限和反馈路径已经存在。上线证明人可以接触到工具，仍然不能证明他会持续使用。

业务人员在真实工作中重复使用，输出也进入了下一步流程。采用最好由运行记录、交付痕迹或使用者确认支持；仅有开发者的描述还不够。

常见异常、维护方式、权限和责任边界已经明确。一次顺利运行不能推出长期稳定；系统还要能说明失败在哪里、是否已经产生写入、能否重试以及谁来处理。

经过足够周期后，才讨论处理时间、错误率、交付周期或其他业务变化。结果需要基线、统计口径和来源。局部步骤变快，不能直接写成整条流程已经提效。

项目复盘里常见三种跳跃。

第一种是把「跑通」写成「上线」。开发者在自己的环境里得到正确输出，只能证明这批输入和这套规则可以工作。下一批数据变化、权限失败或结果写错位置时，真实使用者是否能处理，仍然未知。

第二种是把「交付」写成「采用」。工具有入口，不代表业务人员愿意改变原来的工作方式。如果结果需要下载、改格式，再复制回原有表格，技术流程完成了，人的流程可能反而更长。

第三种是把「有人使用」写成「产生结果」。一条自动化可能每天都在运行，但如果没有统一记录机器运行、人工复核、失败处理和原流程基线，就还算不出净变化。

准确区分这些状态反而能让下一步投入更清楚：已经采用但缺稳定证据，就补异常和维护；已经稳定但缺结果数据，就补基线和运行记录；上线后长期没人用，就回到工作路径重新审视，加更多功能改变不了采用问题。

同一句「已经使用」，依据不同，可信程度也不同。我至少会区分三类来源：

系统记录也有边界。一份日志没有失败，只能证明那次运行没有留下失败记录；一次测试通过，只能证明当前实现覆盖了这些测试。业务确认同样要说明是谁在什么场景下确认了什么，不能被扩写成长期结果。

把来源写出来，不会削弱案例。读者反而能够判断一项结论可以走多远。

项目到了一个开发节点后，应该重新决定是否继续投入；默认延续等于跳过这次决策。

如果有人持续使用，价值方向也清楚，可以继续补稳定性和结果证据。如果项目看起来有用，但缺运行记录或前后对比，就先补证。如果工具做出来后没人采用，也没有业务负责人，暂停通常比继续扩功能更诚实。问题本身价值有限，或者培训、流程调整和现成工具已经足够，也可以关闭。

一张项目表不必因此变得复杂。可以先在「已完成」后面增加四个问题：

「已完成」可以保留，但它只说明工作到了一个节点。企业真正需要管理的，是项目从需求走到结果的证据链，以及证据不足时是否愿意停下来重新判断。