把失败归因于「模型还不够强」是最省事也最无用的解释。在实际项目里，技术能力通常是最后才成为瓶颈的环节。下面 5 个原因是反复出现的模式，且多数在立项阶段就已注定。
原因一：场景贪多，没有主次
立项时列出十几个场景，每个都「很重要」，于是并行推进。资源被摊薄到每个场景都只能做到演示级，没有一个能进生产。
早期信号
第一次汇报里出现 5 个以上场景；每个场景都没有明确的责任业务方；问到「先做哪个」时回答「可以一起做」。
原因二：中层与骨干的抵触被当成态度问题
这一条最容易被低估。智能体一旦接管了某段流程，原来负责这段流程的岗位价值就被重新定义了。抵触不是不认同技术，而是对自身位置的合理担忧。把它当成「思想工作没做到位」，只会让抵触转入地下。
- 让潜在受影响的骨干参与设计，而不是在方案定了之后通知他们
- 把他们的经验沉淀为规则，明确署名与贡献，让知识资产化成为其价值增量
- 新的角色（如智能体效果负责人）优先从这批人里选，而不是从外部空降
- 对个人产出指标做同步调整，避免出现「机器干得多了但考核标准没变」
原因三：验收标准模糊或事后定义
「提升业务效率」不是验收标准。真正可用的标准必须包含口径、基线和目标值三要素，且在动手之前就写进方案。事后定义的标准无法区分「达到目标」和「目标被降低」。
| 不合格的表述 | 合格的口径 |
|---|---|
| 提升合规审查效率 | 单份合规意见初稿耗时从平均 95 分钟降至 40 分钟内 |
| 减少客服重复问题 | 门店咨询中重复类工单占比从 61% 降至 35% 以下 |
| 改善研发文档质量 | 接口文档缺失率从 38% 降至 10% 以内 |
原因四：数据拿不到，或质量不足以支撑判断
技术方案通过评估后，项目往往卡在「数据在另一个系统里，那边不配合开接口」或者「数据格式不统一，字段对不上」。这类问题在立项阶段通常被低估为「对接一下就行」。
务实的做法是在立项阶段就做一次数据可行性预检：把所需字段逐个落到具体系统、具体表、具体接口，并确认权限审批链路和大致周期。这份清单里任何一项标不上，都不能视为可用数据源。
原因五：上线即终点，没有推广与迭代
项目组在验收后解散，没人负责知识库更新、效果监控和问题响应。半年后知识陈旧、效果下滑，用户自然流失。此时再重启的成本高于重做。
- 明确上线后的责任人与响应机制，写进合同而不是口头承诺
- 建立效果看板，至少覆盖使用率、采纳率、人工修正率三项
- 约定固定周期的知识更新节奏，避免知识库随时间腐化
- 上线三个月后做一次正式复盘，用数据决定扩围还是调整
如果你正处在立项或中期阶段，我们可以用这 5 条逐项对一遍，指出已经出现的早期信号与对应的补救动作。
预约风险诊断