这篇文章不是写给围观新模型的人，而是写给准备把 AI 真正接进业务的人。到了 2026 年 7 月 15 日，几乎每个团队都能做出一段像样的 AI Demo，但 Demo 不等于上线。真正危险的时刻，往往发生在所有人都觉得“差不多可以用了”的那一周：功能能跑，截图好看，老板着急，流程却还是空的。所以我更愿意把今天这篇文章写成一张贴在工位上的停工板。没有下面这些条件，宁可晚一周，也不要把 AI 直接推上生产。
第一张：没有验收标准，就不要让模型接活
很多 AI 项目死在一开始就没有定义“完成”二字。团队说要做智能客服、智能填单、智能审单、智能写报告，但到底怎样算通过，常常只剩一句“像人一样”。这不是标准，这是逃避标准。
上线前至少要写清楚三件事：输入边界是什么，输出必须包含什么，错误出现后由谁兜底。如果一项工作连人类同事都没有统一验收口径，就不要指望模型能稳定完成。AI 不是把模糊需求自动变清楚的机器，它只会把模糊批量放大。
第二张：没有回滚路径，就不要让 AI 直接写回系统
只读型 AI 和写入型 AI 是两种风险等级。前者答错了，最多让人皱眉；后者写错了，可能把客户记录、库存状态、审批结果和知识库版本一起带偏。
所以凡是会落库、发消息、改配置、触发外部动作的链路，都应该先设计回滚。撤销按钮放在哪里，补偿逻辑谁执行，失败后怎样恢复到人工接管状态，这些都要在上线前演练一遍。没有回滚的自动化，不叫效率，叫赌运气。
第三张：没有权限分层，就不要把总钥匙塞给一个提示词
团队最容易犯的错，是为了省事给 AI 一个“大而全”的账号：能读、能改、能发、能删。短期看起来通了，长期一定出事。因为真正触发问题的，不一定是模型恶意，而是上下文误判、工具串用和操作范围失控。
权限应该按任务切，不按工具切。查资料的 Agent 只查资料，生成草稿的 Agent 只生成草稿，执行动作的 Agent 只拿到那一步最小必要权限。把 AI 当成一组工位，不是一位皇帝。每张工位卡都该有自己的门禁。
第四张：没有证据留存，就不要相信“它已经处理完了”
AI 最会制造一种错觉：过程看起来很顺，结果看起来也像对的，于是大家默认它中间一定也做对了。可真正的生产环境不接受这种想象。谁调用了哪个工具，读了哪些输入，生成了什么中间产物，为什么判定成功，这些都要留下来。
证据留存不是为了审判模型，而是为了让团队能复盘。没有证据，你就无法区分到底是需求错了、上下文脏了、模型漂了、外部接口坏了，还是某一段提示词把风险吞掉了。没有证据的 AI 交付，出问题时只会演变成多人互相猜测。
第五张：没有成本闸门，就不要把每个请求都送去最贵的模型
今天很多 AI 项目上线初期看起来效果很好，三个月后却突然被财务叫停，不是因为没人用，而是因为越用越贵。团队一开始没有把任务分层，导致摘要、改写、分类、审核、检索增强和复杂推理全走同一条昂贵链路。
成本控制不是上线后的优化项，而是架构的一部分。哪些请求必须上高推理模型，哪些可以降级，哪些要先缓存，哪些要熔断，哪些超过预算直接切人工，这些闸门越晚补，越容易在扩容时被动收缩。AI 产品不是一次性演示，它是持续开销。
第六张：没有责任闭环，就不要把失败归因给“模型波动”
AI 项目一出错，最常见的说法是“模型这次不稳定”。这句话最大的问题，是它把所有责任都推回一团雾里。可生产环境要问的是：谁定义了验收，谁批准了权限，谁决定直接写回，谁负责回滚脚本，谁看每天的失败样本。
模型当然会波动，但组织不能跟着一起漂。每条链路必须有明确的责任人，不是为了背锅，而是为了让异常真正回到可以修复的地方。只有这样，失败才会变成下一次更稳的输入，而不是下一轮会议上的情绪噪音。
最后一张纸：先把停工机制建好，再谈规模化
我越来越不相信“先上线再治理”这句话。对普通网页功能，它有时成立；对 AI，它经常意味着先把不可解释、不可回滚、不可追责的东西接进主流程，然后等事故教育团队。
更稳的顺序应该反过来：先把停工牌贴出来，先把不能做错的地方圈出来，先把失败如何被看见设计好，再去谈提效、放量和复制。AI 项目真正的成熟，不是系统会不会自己干活，而是系统在不该继续时，能不能自己停下来。