失败一：场景选错
选了输入不稳定、没有复核人、错误代价又高的场景，模型再强也做不出稳定结果。判断标准很朴素：这类任务过去有没有人能稳定做好，如果没有，交给模型大概率同样做不好，只是错误更隐蔽，也更难被一线察觉。
失败二：靠演示验收
没有评测集的项目，验收只能看演示，而演示样本通常经过挑选。真实流量一进来错误率就暴露，双方开始互相指责，项目进入反复返工，最后以需求变更的名义收场，没有人愿意复盘真正的原因，也没有留下可比较的记录。
失败三：知识底稿缺失
期望模型自己知道内部制度与产品细节，结果回答看似合理却处处出错。企业知识必须以可检索、有版本、有责任人的形式整理出来，这一步没有捷径，也无法在交付完成后长期外包给外部团队维护。
失败四：流程权限未动
模型输出进不了业务系统，员工要把结果复制粘贴到另一个界面，效率反而下降。权限、审批与留痕需要同步改造，否则系统只能停留在试用阶段，两周后就被一线绕开，反而增加了额外的工作量；系统也就失去了存在价值。
失败五：上线即撤场
交付方做完演示就撤，内部没人能改提示词、更新知识、查看日志。三个月后场景漂移，系统被停用，前期投入变成沉没成本，下一次立项时审批会更难通过，团队也对这类项目失去信心；组织记忆也随之丢失。
适用与不适用
适合谁
- 立项评审前需要做风险排查的项目组
- 已上线但使用率不及预期的团队，正在寻找原因
- 需要向管理层复盘失败原因的负责人
不适合谁
- 尚未确定具体场景、仍处于广泛调研阶段的团队
- 把 AI 当作宣传项目、不打算真的给业务使用的部门
典型场景
某零售企业年初上线导购助手，年中复盘时发现日活不到一成。追查后发现三个问题叠加：场景选在促销话术这类天天变化的领域，知识库无人更新，导购要在手机与电脑之间来回切换。复盘后砍掉两个场景，只保留退换货政策问答，并把更新责任交给客服主管，两个月后使用率才逐步回升。
可执行步骤
- 立项评审时逐条对照五种失败模式打分，把结论写进评审纪要并指定整改责任人
- 把每个场景的复核人、错误代价与兜底方式写进任务卡，由业务负责人现场确认
- 上线前确认知识更新责任人、更新频率与审核方式，并为其留出固定工时
- 核查模型输出是否已接入业务流程，操作是否留痕、能否按人按次追溯，避免只靠演示判断效果
- 约定上线后三个月的运营支持责任与交接安排，写清停止使用的触发条件
常见坑
- 把失败归因为模型不够强，换一个模型重做一遍，同样的问题在半年后原样重演，预算却已消耗殆尽。
- 多个场景同时上线，资源被摊薄，每个都做到一半，最后没有一个真正可用，还拖累了后续立项；处理起来也更被动。
- 知识库由实习生一次性录入后无人维护，三个月后过期内容超过一半，回答开始误导用户，投诉集中出现。
- 没有约定运营期责任，出问题后业务方与 IT 相互推诿，系统被闲置在角落直到合同到期，无人复盘；风险无人兜底。
自检与验收清单
- 场景是否有稳定输入、明确复核人与可接受的错误代价
- 是否有真实样本构成的评测集与固定判定口径
- 知识底稿是否有版本记录、生效时间与维护责任人
- 模型输出是否进入业务流程，且操作过程完整留痕
- 上线后三个月是否有人负责运营与知识更新，并有固定交接安排
常见问题
失败最多的环节是哪一个？
从复盘看，知识底稿与流程改造占多数，这两项都在技术之外。模型能力通常不是瓶颈，把制度、话术、案例整理成可检索的资产，才是多数项目真正的工作量所在，也是最容易被低估的一段。
小项目也会失败吗？
会，而且更隐蔽。小项目常省略评测集与交接文档，第一版能用，换人维护的第二版就崩。建议无论规模大小，都保留一份最小评测集与一页运维说明，成本很低但能显著延长系统寿命。
怎么判断该停掉一个场景？
设定观察窗口，例如上线后八周。若接管率持续偏高、错误又集中在无法通过补知识解决的类型，就应停掉或换场景，而不是继续追加预算硬撑，那样只会延长沉没期并消耗团队信心。