坑一：把采购当转型
签下平台合同不等于转型开始。若没有明确任务、责任人和验收标准，平台会变成又一个闲置系统；更麻烦的是钱已经花了，团队更难承认判断失误，只能继续追加投入。
坑二：把演示当上线
演示环境的问题经过挑选，真实业务的输入脏、边界多。没有评测集与灰度，上线首周就会遇到演示中从未出现的输入，业务方随之失去信心，项目被迫回炉。
坑三：知识库一次性建设
知识库不是交付物，而是运营对象。制度更新、产品迭代、话术调整都要回流；缺少责任人与更新节奏，半年后回答准确率下降，一线会绕开系统自己找资料。
坑四：跳过评测靠感觉验收
没有固定评测集，就无法比较模型、检索与提示词改动的效果，出问题时也无法定位原因。评测集不必很大，但必须覆盖真实高频问题与高风险问题两类。
坑五与坑六：岗位不改、治理后补
前者让复核变成额外负担，员工能躲就躲；后者让已开发功能卡在合规评审。两者都是组织问题：一个要改岗位说明书与考核，一个要在立项时就把数据分级与内容标识写进范围。
适用与不适用
适合谁
- 已启动但推进受阻的 AI 项目负责人
- 正在编制年度 AI 预算与规划的部门
- 需要向管理层汇报风险与节奏的管理者
不适合谁
- 只想要工具清单、不做组织调整的团队
- 尚未明确任何业务问题就要求整体方案的企业
典型场景
某集团一年内采购了三套 AI 工具，使用率持续走低。复盘发现三个项目都没有评测集，也没有指定接管人，知识库由 IT 兼职维护。团队停掉两个项目，保留一个客服场景，补齐评测集与周度复盘后，使用率才回升。
可执行步骤
- 把现有 AI 项目按任务、责任人、验收标准列成一张表
- 逐个检查是否有评测集与接管机制
- 停掉无任务、无责任人的项目，集中资源
- 为保留项目补知识维护人与更新节奏
- 在立项模板中加入数据分级与标识要求
常见坑
- 用登录人数、调用次数当成效指标，掩盖了回答质量下降，问题在半年后集中爆发。
- 把失败归因于模型不够强，忽略知识过期与流程缺失，换模型后问题依旧。
- 一次铺开大量场景，每个都做到一半，最后没有一个能稳定交付。
- 合规评审安排在开发完成后，返工成本高，还容易被迫砍掉核心功能。
自检与验收清单
- 每个项目是否有唯一业务负责人
- 是否有覆盖高频与高风险问题的评测集
- 知识库是否有维护人与更新频率
- 接管条件与接管人是否书面化
- 数据分级与内容标识是否在立项范围内
常见问题
误区这么多，是不是不该做？
不是。误区集中在组织与验收环节，与模型能力关系不大。把任务、责任人、评测集三件事做实，多数坑可以提前避开。
中小企业也会踩这些坑吗？
会，只是形式不同。中小企业更容易一次上太多场景，也更容易把负责人的直觉当验收标准，反而更需要一张简单的评测清单。
怎么说服管理层停下来补课？
用现有项目的数据说话：接管率、错误类型、知识更新记录。把返工与停用风险摆出来，比讲方法论更容易获得支持。