一、为什么 AI 项目越做越久，却越来越难停
1. 把演示效果当成业务结果
演示时，团队可以挑选最适合的文件、最清晰的问题和最容易展示的流程。上线后，用户会输入错别字、缺字段、过期规则和相互冲突的信息，系统还要面对真实权限、真实接口和真实责任。
一个会写总结的模型，不等于员工愿意每天使用；一个能回答制度问题的机器人，也不等于它能够把问题分派、记录和追踪完成。
2. 把“有人在用”当成“产生价值”
项目群里每天有很多测试消息，不代表业务真的改变了。真正有价值的使用，应该发生在原有工作流程里，并且能减少重复时间、降低漏处理、提高交付质量或缩短决策周期。
如果员工只是把 AI 当成一个额外聊天窗口，用完还要复制到原系统、重新核对、再次录入，表面上有调用量，实际可能增加了工作量。
3. 把已经花掉的钱当成继续投入的理由
“前面已经投入这么多了，再做一点就能完成。”这句话在软件项目里很常见，在 AI 项目里尤其危险。过去的投入无法追回，接下来要不要投入，应该只看未来能不能获得足够的业务价值和风险收益。
老板可以保留项目的沉没成本，但不能让沉没成本决定下一笔预算。
4. 没有把失败责任分开
模型效果不好，可能是数据质量问题；数据质量不好，可能是业务规则没有统一；流程没有结果，可能是没有负责人；费用超支，可能是调用路径和人工复核没有设计。
如果所有问题最后都归结为“模型还不够强”，团队就会不断换模型，却不解决真正的管理和系统问题。
二、四条停损线，建议在立项时就写进预算和合同
停损线一：连续使用，却没有真实业务闭环
AI 项目必须绑定一条真实流程，例如客服答疑、销售方案初稿、工单分派、合同信息抽取或内部知识检索。老板要看的是：
- 用户是否在原有工作入口使用，而不是只在演示环境测试；
- AI 输出是否进入下一步业务动作；
- 人工复核后是否真的节省时间或减少错误；
- 结果能否回写系统，形成可追踪记录；
- 没有 AI 时，原流程和有 AI 时有什么可比较的差异。
如果连续几个周期都有调用量，但没有任何业务动作被改变，就不应该直接扩大范围。可以先暂停新增功能，重新确认是不是选错场景、入口太远，或者结果没有嵌入原系统。
这里的停损不一定是立刻关闭系统，而是停止“继续堆功能”，把预算转向流程重做或入口整合。
停损线二：人工复核成本超过了节省的时间
AI 输出不是越多越好。对很多企业来说，真正需要计算的是“完成一个合格任务需要多少总成本”。
可以用一个简单公式估算：
单个有效任务成本 = AI 调用 + 检索和接口 + 人工核对 + 错误返工 + 运维摊销
如果 AI 生成一份报告只需要一分钟，但员工要花十五分钟逐句核对、改格式、补数据，项目可能没有创造效率，甚至只是把工作从“制作”转成了“检查”。
人工复核不是问题，关键在于复核范围是否越来越稳定，复核时间是否逐步下降，错误是否集中在可以修复的少数类别。如果三个月后仍然需要对每一条结果全量重做，老板就要重新评估系统边界。
停损线三：风险边界控制不住
有些 AI 项目即使节省了时间，也不适合继续扩大，因为它在关键环节存在不可接受的风险。
例如：
- 没有依据时仍然生成确定的政策、价格或合同条款；
- 普通员工可以看到不该访问的客户、财务或人事数据；
- 智能体能够直接付款、删除、发信或改生产数据，却没有审批和撤销；
- 模型更新或提示调整后，原本稳定的流程突然失控；
- 日志无法说明谁发起、AI 读取了什么、执行了什么动作。
风险停损线不能等到发生事故后才定义。项目立项时就要列出“出现一次也不能接受”的错误，以及出现后必须暂停哪些权限。关于 AI 项目验收，可以参考《AI 系统怎么验收？“准确率 90%”远远不够》，把异常、权限和人工接管纳入测试。
停损线四：单位成本和长期维护不可控
AI 项目常见的成本失控，不是某一次调用突然特别贵，而是使用范围扩大后，所有配套成本一起增长：
- 每次回答都拉取过长上下文；
- 失败后自动重复调用，形成隐性循环；
- 一个小功能接入了多个付费服务；
- 大量结果需要人工复核和重新录入；
- 供应商调整价格或服务策略，企业没有替代路径；
- 上线后没有专人维护知识、权限、提示和回归测试。
老板要设置的不只是总预算，还要设置单个有效任务、单个用户、单个业务部门和每月总额的上限。超过阈值后，系统应该告警、限流、降级或暂停，而不是等月底看账单。
如果团队只能给出“模型调用很便宜”，却说不清一项业务完成的总成本，项目还没有进入可经营状态。
三、90 天应该怎样安排，才能拿到可用证据
第 0—15 天：只确认问题和基线
这个阶段不急着做复杂功能，先完成五件事：
- 选定一条业务流程和一类用户；
- 记录没有 AI 时的时间、错误、人工步骤和成本；
- 明确哪些任务由 AI 建议，哪些任务必须由人决定；
- 准备一批脱敏、包含边界情况的真实样本；
- 写出预算上限、风险红线和停止条件。
如果 15 天内连基线和负责人都没有定下来，不建议直接进入大规模开发。此时追加模型费用，通常只会让后面的比较更困难。
第 16—45 天：只做人工辅助，不急着放权
让 AI 先生成建议、摘要、分类或草稿，由业务人员确认后再进入原流程。这个阶段要记录：
- 使用者是否愿意主动使用；
- AI 输出被采纳、修改和拒绝的比例；
- 每项任务节省了多少时间；
- 哪些错误重复出现；
- 人工复核是不是越来越快；
- 每个有效任务的真实成本。
不要只记录调用次数和满意度。满意度很容易受新鲜感影响，不能替代业务结果。
第 46—90 天：只开放低风险、可撤销的动作
当人工辅助有了稳定证据，才考虑让 AI 触发少量系统动作，例如创建待办、生成工单草稿、标记待复核记录或提醒负责人。付款、删除、对外承诺、修改核心数据等高风险动作，仍然应该保留审批。
第 90 天的评审应当拿出一套对比：使用前后流程、有效任务数、人工时间、错误类别、风险事件、单位成本、维护投入和用户留存。没有这些证据，不能仅凭“大家觉得不错”决定扩大预算。
四、90 天后不是只有“继续”和“停止”两个选项
继续扩大
适合以下情况：场景有稳定使用者，结果进入真实流程，人工复核成本下降，风险在边界内，单位成本可预测，且有明确维护责任。
扩大时也不要同时增加所有部门、所有数据和所有权限。先扩大一个变量，才能知道结果为什么变化。
缩小范围后继续
如果核心价值存在，但某些任务错误率高、成本高或资料不稳定，可以缩小任务范围。例如只处理高频低风险问题，只给出建议不直接执行，只接入一类资料。
这不是失败，而是把项目从“什么都想做”改成“先把一个闭环做稳”。
暂停并重做流程
如果用户愿意使用，但系统无法接入现有业务入口，或者数据和权限问题阻碍了结果，就应暂停功能开发，先补系统整合、资料管理或责任机制。
很多 AI 项目不是模型不能用，而是企业没有给它准备可以工作的业务环境。
终止项目
如果业务问题本身不重要、没人愿意长期负责、风险红线无法控制，或者单位成本明显高于人工且没有改善路径，就应该停止。终止时要保留样本、测试记录、费用、失败原因和可复用的接口资产，避免下一次换个名字重新踩同一个坑。
五、老板每周只看这张项目卡
为了避免项目重新陷入技术细节，可以要求团队每周用一页纸回答：
- 本周完成了多少个真实有效任务；
- 其中多少进入了原业务流程；
- 采纳、修改、拒绝和人工接管分别是多少；
- 本周发生了哪几类错误，有没有触碰风险红线；
- 一个有效任务的总成本是多少；
- 哪个指标比上周改善，哪个指标变差；
- 下周准备验证哪一个假设；
- 如果验证失败，是否会触发停止、缩小或改道。
这张项目卡比一份堆满技术术语的周报更适合老板做判断。它迫使团队把“我们又调了模型”翻译成“业务到底发生了什么变化”。
六、合同里要把退出机制写成可执行条款
AI 项目不应该只有上线付款条款，还应该有阶段性退出安排：
- 每个阶段的业务结果、样本范围和通过标准；
- 达不到标准时，是整改、缩小范围还是暂停；
- 超过预算或调用上限时谁可以暂停服务；
- 发现严重权限、隐私或错误执行时，多久内必须关闭相关能力；
- 退出时企业能拿回哪些代码、配置、数据、日志和文档；
- 模型或第三方服务停止、涨价、降级时如何迁移；
- 已经产生的资料和数据如何删除、归还或继续留存。
“双方另行协商”不是退出机制。真正可执行的条款应该有触发条件、通知方式、暂停动作、责任人和复测要求。
如果企业还在计算建设和长期运营成本，可以结合《定制系统上线后每年还要花多少钱？》的思路，把模型、接口、运维和人工复核放在同一张预算表里，而不是只看第一期开发报价。
