企业 AI 项目失败的常见原因

企业 AI 项目失败，多数不是模型不行，而是六类前提没有成立。这六类问题在早期都有可识别的信号，只是当时往往被当成「推进中的小问题」，直到项目无法收口才被重新提起。逐类看清信号，比事后复盘更有用

六类原因与早期信号

• 没有验收人：每次汇报都说「效果不错」，但没有人能签字。处置：立项时就指定一个人，由他来定义什么叫做成了。
• 数据现状不明：需求讨论了两轮，才有人问「这个字段系统里有吗」。处置：先做一次数据盘点，再谈方案。
• 规则未定：同一件事，不同的人有不同的处理方式。处置：先把规则写成一句话；写不出来，就先别改流程。
• 只由技术推动：业务方只在演示时出现。处置：让使用部门成为需求的提出方，而不是接收方。
• 缺少评测：判断效果靠演示和个例。处置：用真实问题建一份评测集，并明确谁来维护它。
• 上线后无人维护：文档与索引的更新没有归属。处置：把维护写进岗位职责，而不是挂在项目组上。

立项前的自查表

• 这个场景的验收人是谁，他的名字能写下来吗
• 需要的数据字段是否已确认存在，且口径一致
• 判断对错的规则能否用一句话写清
• 评测集是否来自真实问题、并由业务方确认过答案
• 上线之后谁负责更新知识与复跑评测
• 出现异常或答错时，回到哪个既有流程
• 这六项里，有没有一项是你现在答不上来的 —— 那就是第一步要解决的事

六类原因的共同点

这六类里没有一类是「模型不够强」。它们全部发生在模型之外，而且都可以在项目早期被发现 —— 代价只是当时愿意多问一句。反过来说，如果一个项目在这六项上都站得住，即使中途换掉模型，项目也不会散。

把这些信号放在一起看，会发现它们指向同一个动作：把口头共识变成书面口径。这一步做完，项目推进会明显变慢，但也变得可解释 —— 而可解释正是它最终能交付的原因。

边界

这份清单不是立项门槛，而是排查工具。发现其中一条不成立，不代表项目不能做，而是说明它需要先解决那一件事，再往下走。

两个容易被忽略的前置动作

• 先盘点「谁在用什么」：把现在实际在用的系统、表格与群聊都列一遍。最容易踩的坑，是接了一批名义上在用、实际上早已废弃的数据源。
• 先写「这次不做什么」：明确哪些环节本轮不碰。范围写大了，前面那六类问题会一起出现。

这两件事都不需要技术投入，却能省掉后面大量返工：盘点决定数据可不可信，不做清单决定项目收不收得回来。