AI 工作流真正解决的，不是写代码，而是治理执行过程
摘要：我后来对 AI 开发流程的理解发生了一个明显变化。重点不是“怎么让它更快写代码”，而是“怎么让它在正确的阶段做正确的事，并在失败时停得住”。所以我把 AI 工作流拆成阶段，同时开始治理低能力智能体的失败行为，并把交棒契约当成流程是否稳定的核心。
很多人用 AI 做开发，第一反应都是：怎么让它更快写代码。
但从我的经验来看，真正应该先解决的问题不是速度，而是两个更基础的问题：
- 它是不是在正确的阶段做正确的事
- 它失败之后会不会继续乱做
如果这两个问题不解决，AI 越快，返工也越快。
所以我后来把整个 AI 协作流程拆成了 6 个阶段：
proposal → discuss → apply → review → archive → commit同时，我开始把低能力智能体当成一个需要治理的执行体，而不是一个“多提醒几句就会变乖”的助手。
先拆阶段，不让 AI 提前越界
我拆这 6 个阶段，不是为了显得流程完整，而是为了给 AI 一个明确边界。
proposal 只回答：为什么做、做什么
需求阶段最怕的一件事，就是 AI 过早进入实现思维。
明明还在讨论业务目标，它却已经开始说：
- 这个页面应该改哪个组件
- 这个字段应该放在哪一列
- 这个接口应该怎么封装
- 这个菜单应该怎么加权限
这些都不是 proposal 阶段该回答的。
proposal 只应该回答：
- 这个需求为什么存在
- 用户真正想要什么
- 改动大概影响什么范围
它回答的是：
Why 和 What
而不是：
How
一旦在这个阶段过早进入实现，AI 就很容易把“推断”包装成“事实”。
discuss 才回答：怎么做
真正的技术方案、代码探索、影响范围确认，应该留到 discuss。
因为到这个阶段，我们已经确认了目标，接下来要解决的是：
- 找入口
- 看引用链
- 找相似实现
- 定影响范围
- 确认哪些文件可以动，哪些不该动
- 把这些内容沉淀成执行契约
这一阶段回答的是：
How
我后来越来越觉得，很多 AI 失控不是发生在写代码的时候，而是发生在 discuss 阶段边界没收住。
apply 只执行，不重新设计
我后来对 apply 阶段有一个很强的判断：
执行阶段最怕重新思考。
因为一旦允许 AI 在 apply 阶段重新设计，它几乎一定会：
- 扩大范围
- 偷偷改设计
- 顺手补它觉得也该改的东西
- 失败后切一条完全不同的路径继续试
所以 apply 应该只做一件事：
消费 discuss 交棒下来的执行契约。
如果契约不完整，正确动作不是继续猜，而是回到 discuss 补齐。
review、archive、commit 解决的是“怎么闭环”
review 不只是看结果能不能用，还要验证：
- 需求是不是满足了
- 设计是不是按约定实现了
- 实际改动有没有超出宣称范围
- 上游交棒有没有被绕过
archive 不是单纯收尾，而是沉淀：
- 业务规则
- 代码定位路径
- 组件使用场景
- 归档摘要
commit 也不只是提交代码，而是确认：
- 代码改动完整
- 文档归档完成
- 知识沉淀到位
- 摘要可复用
但阶段拆开还不够，关键在交棒契约
很多团队会说自己已经拆了流程：
需求 → 设计 → 开发 → 审查 → 归档但如果阶段之间的交棒只是自然语言描述，那本质上还是一段连续对话。
比如设计阶段说：
- 可能涉及某个页面
- 大概会改某几个文件
- 也许要补一个配置
开发阶段拿到这些信息时，很容易发生两件事：
- 把推断当事实
- 把模糊点靠猜补齐
这就意味着，虽然名义上已经进入了“开发阶段”，但实际上它仍然在继续做设计。
所以我后来越来越觉得：
阶段边界不是靠名字划出来的，而是靠交棒契约锁出来的。
好的交棒契约，不是记录信息，而是限制自由度
交棒契约真正重要的地方，不在“记录信息”，而在“限制下一阶段的自由度”。
如果一个阶段结束后只交出去一句：
这次应该改表头配置，顺便同步一下。
那执行阶段几乎一定会重新理解：
- 表头配置属于哪一类
- 用哪个工具改
- 需要不要先查旧值
- 同步之前要不要预览
- 失败之后要不要重试
而如果交出去的是结构化契约：
- 用哪个能力域
- 允许哪个工具
- 禁止哪个工具
- 哪一步先做
- 哪一步后做
- 哪些错误可重试
- 哪些错误必须阻断
那下一阶段要做的就不是“重新理解任务”，而是“执行明确约束下的任务”。
好的交棒契约一定要同时解决三件事
1. 事实源必须明确
下一阶段最怕的，不是信息少，而是信息来源不清。
比如一个 menuId，如果只写一个值，没有来源，那执行阶段就很容易问自己：
- 这个值是猜的还是查的
- 能不能换成另一个值
- 有没有更适合的配置入口
2. 执行边界必须明确
下一阶段必须知道：
- 哪些文件可以动
- 哪些文件只能读
- 哪些范围禁止触碰
- 哪些工具允许调用
- 哪些工具绝对不能碰
3. 错误策略必须前置定义
如果交棒里没有明确写：
- 什么错误可以重试
- 什么错误不能重试
- 什么情况要切流程
- 什么情况必须阻断
那低能力智能体默认就会做一件事：
继续试。
所以交棒契约不只是“任务清单”，它还必须是“失败治理策略”。
阶段拆开之后，还要解决另一个问题：低能力智能体不会停
我后来越来越确定：
低能力智能体最危险的，不是不会做，而是失败之后还在继续做。
不会做，其实不可怕。真正可怕的是它第一次失败了，然后：
- 不知道为什么失败
- 不会停
- 换个参数继续试
- 换个工具继续试
- 最后把上下文越搞越乱
所以我后来开始做“熔断”
我后来对这类问题的处理方式很直接：
不要指望它自己判断什么时候该停。
你必须替它定义清楚：
- 什么错误可以重试
- 什么错误不能重试
- 什么情况必须立即阻断
比如：
可以重试的
- 网络超时
- 临时连接失败
- 服务端 500
不能重试的
- 参数错误
- 权限错误
- 业务状态错误
- 调错工具
- 目标不存在
- 目标已存在但流程没切换
然后加熔断规则：
- 同一工具 + 同一参数失败 2 次后，停止
- 调错工具，立即停止
- 参数错误，不许重试
- 权限错误，不许重试
最后一句
我后来对 AI 工作流的理解，已经不再是“怎么让它写得更快”。
而是：
怎么让它在正确的阶段做正确的事，并在失败的时候停得住。
从这个角度看，流程和治理不是额外负担，它们本身就是 AI 真正进入工程系统的前提。