过去几年我们参与评估过不少企业内部 AI 项目。共同规律是：PoC 阶段的成功率远高于生产落地率。 演示时效果惊艳，真正要交付给业务连续使用，问题就集中爆发。我们把这类失败归纳成四个断层。
断层一：场景选在了「好看」而不是「好算」的地方
最容易立项的场景往往是最容易演示的场景：写诗、写软文、做一个能聊天的数字人。 但这类场景很难算清 ROI，业务方也没有硬性指标去验收，项目做完就晾在那里。
相反，真正能活下来的场景通常长这样：高频发生、流程固定、有明确的验收标准、错了能被人发现。 例如信贷材料审核、工单分派、设备故障查询——它们的共同点是「人的时间被明确节省了」，可以折算成钱。
立项时的动作：让业务方给出三个人工基线数字——每次处理耗时、日均处理量、错误率。这三个数字算不出来， 说明这个场景还不该做。
断层二：数据是一次性的，而业务是持续的
PoC 阶段通常由 IT 部门手动导出一批「干净」的文档喂进去，效果自然好。 上线以后，新增文档源源不断进来：格式不统一、版本混杂、扫描件模糊、附件藏在邮件里。 三个月后知识库就变成了垃圾场。
这类问题的修复成本极高，因为它不是模型问题，而是数据管道问题。 我们建议在 PoC 阶段就同步设计三件事：文档入库的准入规则、增量更新的触发机制、过期版本的失效策略。
断层三：没有评估基线，效果好坏全靠感觉
「比以前好一些」是项目复盘里最常见的结论，也是最没用的结论。没有基线，你既无法证明价值， 也无法在效果下滑时及时发现。
可执行的做法：项目启动第一周就建一个 50 条左右的评测集，标注标准答案与依据。 每次改动都跑一遍，形成趋势曲线。这样在汇报时你能说出具体数字，在出问题时你能定位到环节。 关于指标设计，可以参考我们另一篇文章 《RAG 效果评估的五个关键指标》。
断层四：上线即终点，没有人负责运营
很多项目的排期表到「上线验收」就结束了。但 AI 系统不是装完就稳定的软件， 它的表现会随着数据漂移、模型更新、业务变化而波动，需要有人持续看数、收集反馈、迭代提示词与检索策略。
我们的做法是把「运营」写进合同：上线后三个月内按月复盘，输出 Badcase 归因报告与优化清单。 客户团队同时参与，三个月后完成能力转移，由客户自己接手。
判断一个 AI 项目是否真的成功，不看演示，看三个问题： 它在被谁每天使用？它的效果怎么被衡量？出问题谁来修？
立项自查清单
- 这个场景的人工基线（耗时、量、错误率）是否已量化？
- 数据来源是否可持续，增量更新由谁负责？
- 验收标准是「感觉变好了」还是具体指标？
- 上线后三个月，谁来看数据、谁来改提示词？
- 如果效果不达标，止损条件是什么？
这五个问题如果都能在立项会上得到明确回答，项目失败的概率会大幅下降。 它们不涉及任何技术细节，但比技术选型更决定成败。