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 验证的不是“能不能跑”，而是“有没有按约定做”
review 不只是看结果能不能用，还要验证：
- 需求是不是满足了
- 设计是不是按约定实现了
- 实际改动有没有超出宣称范围
- 上游交棒信息有没有被绕过
也就是说，review 真正防的是 AI 在 apply 阶段偷偷扩大范围。
archive 和 commit 是把一次执行变成下次的资产
archive 不是单纯收尾，而是沉淀：
- 业务规则
- 代码定位路径
- 组件使用场景
- 归档摘要
commit 也不只是提交代码，而是确认：
- 代码改动完整
- 文档归档完成
- 知识沉淀到位
- 摘要可复用
这两步的意义不是“形式完整”，而是让下一次 AI 不用从零开始猜。
阶段拆开之后，还要解决另一个问题：低能力智能体不会停
我后来越来越确定：
低能力智能体最危险的，不是不会做，而是失败之后还在继续做。
不会做，其实不可怕。真正可怕的是它第一次失败了，然后：
- 不知道为什么失败
- 不会停
- 换个参数继续试
- 换个工具继续试
- 最后把上下文越搞越乱
这种行为看起来像“很努力”，但本质上是在制造噪音。
它的问题不在理解，而在控制
很多人会以为低能力智能体的问题是理解力不够。
但我后来发现，很多时候它不是“不知道规则”，而是：
不知道什么时候该停。
比如一个配置修改任务，它第一次调用失败之后，正确动作应该是：
- 判断是参数错了
- 判断是权限错了
- 判断是工具调错了
- 然后决定修参数、切流程，或者直接阻断
但低能力智能体经常会把所有失败都理解成：
再试一次。
这时候问题就不是认知问题，而是执行控制问题。
失败后乱试，是工作流里最大的噪音源
在真实开发里，我们其实很清楚：
- 参数错误，不应该重试
- 权限错误，不应该重试
- 工具调错了，不应该重试
- 业务状态错误，也不应该重试
可低能力智能体不是这么想的。
它经常会做这种事情：
失败
→ 重试
→ 还是失败
→ 换个工具
→ 继续试
→ 再失败
→ 再换参数最后你会发现，它最擅长的不是修问题，而是把问题掩盖在重复调用里。
所以我后来开始做“熔断”
我后来对这类问题的处理方式很直接：
不要指望它自己判断什么时候该停。
你必须替它定义清楚：
- 什么错误可以重试
- 什么错误不能重试
- 什么情况必须立即阻断
我后来把失败大致分成两类。
可以重试的
- 网络超时
- 临时连接失败
- 服务端 500
不能重试的
- 参数错误
- 权限错误
- 业务状态错误
- 调错工具
- 目标不存在
- 目标已存在但流程没切换
然后加熔断规则：
- 同一工具 + 同一参数失败 2 次后，停止
- 调错工具，立即停止
- 参数错误，不许重试
- 权限错误，不许重试
白名单和状态回写，比提醒更有效
我后来发现，治理低能力智能体最有效的几件事是：
- 工具白名单
- 禁用工具清单
- 结构化步骤
- 状态回写
- 错误分类
- 失败熔断
因为真正危险的，不是它不会做，而是：
它失败之后还在继续做不该做的事。
最后一句
我后来对 AI 工作流的理解，已经不再是“怎么让它写得更快”。
而是：
怎么让它在正确的阶段做正确的事，并在失败的时候停得住。
从这个角度看，流程和治理不是额外负担，它们本身就是 AI 真正进入工程系统的前提。