一个失败的 AI 项目，通常坏在这 5 个地方

先说明边界：下面不是某个真实客户案例，而是把常见工程约束组合成一个合成情境。没有客户名称、项目数据或测试结果，也不把推演写成亲历事实。

先说结论。很多 AI 项目不是坏在模型完全不能用，而是坏在目标、数据、动作、验收和运营没有形成闭环。Demo 可以绕过这些问题，业务上线却绕不过去。

合成情境：一个内部知识助手

某团队希望把散落在共享盘、协作平台和邮件附件中的制度文档接入问答助手。管理层期待员工直接提问，系统给出答案并减少重复咨询。

原流程是员工先搜文档，找不到再问部门联系人；联系人根据最新制度回答，并在必要时让负责人确认。项目方案则直接把文档导入知识库，接一个聊天页面，计划后续自动回复。

表面上这是标准 RAG 场景，真正风险却在制度版本、权限和责任链。

本文没有真实上线结果可报告。以下“结果”均指方案推演后可以检查的状态变化，不写节省工时、准确率或用户数量。

第一个坏点：目标写成“建设助手”

项目没有明确要减少哪类咨询、服务哪些部门、哪些问题允许回答、哪些必须转人工。于是所有人都能提出任何问题，团队也无法判断效果。

更合理的做法是先选一个文档边界和一类高频问题，例如只覆盖已生效、对全员公开的行政制度，输出必须带来源，涉及个案判断时转人工。

判断标准是能否用一句话描述使用人、任务、范围和输出。不能，就还没有项目目标。

第二个坏点：文档被导入，却没有治理

共享盘中可能同时存在草稿、旧版、扫描件和重复附件。系统检索到内容不代表内容有效。若同一制度有两个版本，模型会把冲突包装成流畅答案。

方案应先建立文档清单，标所有者、生效时间、版本、权限和更新责任。无法确认的文档不进入正式库；扫描质量差的先处理解析和抽检。

这里的技术取舍是先缩小知识范围，而不是先扩大召回。少而可信的资料，比全量但失控的资料更适合试点。

第三个坏点：从回答直接跳到自动执行

团队看到问答效果不错，就想让助手自动提交申请、修改记录或发送通知。原本可审核的文字错误，会变成系统动作错误。

更稳妥的方案是分层：第一阶段只读和引用；第二阶段生成表单草稿；第三阶段在身份校验和人工审批后写入。付款、删除、权限和个案承诺始终保留高等级控制。

失败兜底包括拒答、请求补充、转人工和回到原流程，而不是反复调用模型直到出现答案。

第四个坏点：验收只有“功能能跑”

页面能打开、模型能回答，并不能说明知识助手可用。验收至少要看问题是否在范围内、检索来源是否正确、答案是否受来源支持、权限是否有效、无法回答时是否正确退出。

评估集应来自去敏后的真实问题，并包含过期政策、无权限文档、模糊问题和范围外问题。没有现成数据时，先建立记录机制，不编造准确率。

技术取舍是把“拒绝错误问题”也当成功状态，而不是要求每个问题都生成答案。

第五个坏点：上线后没有知识负责人

制度变化、人员调整和文档迁移会持续发生。没有人负责更新、下线、反馈和未命中问题，知识库会逐步失真。

需要明确知识所有者、系统运维者、业务审核人和反馈处理人。日志中记录引用版本、未命中问题、用户纠正和权限失败，定期进入治理流程。

项目交付不是结束。知识库本质上是一项持续运营能力。

为什么这五个问题会一起出现

它们共享一个根因：团队把模型能力当成完整产品。模型只负责链路中的部分判断，目标、数据、权限、验收和运营仍由组织承担。

目标不清会导致数据无限扩张；数据不可信会让验收无从定义；验收缺失会鼓励自动化越权；运营无人负责又让系统上线后快速过期。

因此修复不能只换模型或重写 Prompt，而要回到流程重建责任链。

修复顺序也不能反过来。先暂停新增文档和自动执行，确认目标与知识范围；再清理版本、权限和所有者；随后建立问题集与拒答规则；最后才调整检索、提示和模型。若继续在污染数据上优化回答，短期指标可能变化，责任边界仍然没有改善。

每次修复都要留下可观察结果：某类冲突文档是否被下线，范围外问题是否正确转人工，更新后的来源是否进入回归。没有这些证据，“已经优化”仍然只是项目状态描述。

结果：合成复盘只能交付可验证条件

经过上述修复，项目能合理声称的不是“知识助手成功上线”，而是形成了 4 类可验证条件：服务范围有负责人，正式文档有版本与权限，问题集同时覆盖回答和拒答，失败后有人工接管与回归入口。

这些条件仍不等于业务效果。团队必须在获得授权的真实问题上运行，记录引用、纠正、拒答和权限结果，才能决定是否进入受控试点。若真实样本证明旧资料无法治理，停止项目也是有效结果。

技术取舍同样被保留下来：先做小范围只读问答，不做自动提交；先验证证据与权限，不追求全量召回；先保留人工流程，不把 Demo 代码直接当生产系统。

反例：什么时候可以做得更轻

一次性内部资料整理、非敏感内容摘要或短期演示，可以降低权限和运营投入，但必须明确结果不进入正式业务决策。

若文档范围小、版本统一、使用人固定，也可以采用更简单的搜索加生成方案。不是每个知识问答都需要大型平台。

轻量实现的前提是风险和生命周期都轻，而不是团队暂时没有时间处理风险。

同类项目复盘清单

1. 项目目标是否描述具体流程变化？
2. 文档是否有所有者、版本、生效和权限字段？
3. 模型输出与系统动作是否分层？
4. 是否有真实问题、边界问题和拒答样本？
5. 人工审核与降级入口是否存在？
6. 日志能否追到来源和工作流版本？
7. 上线后谁更新知识、处理反馈和未命中问题？

下一步可拿这五类坏点审查当前项目。若其中三类仍没有负责人，不要急着扩功能；先把目标、数据和验收补齐，通常比继续调模型更有效。