为什么你的 AI Coding 总是又慢又乱？因为你还在审批每一步
最近看一些 AI Coding 和 AI 原生开发工作流的材料，越看越觉得：很多说法方向没错，但协作粒度还是选错了。
这类叙事通常会强调，AI 不再只是被动回答问题的助手，而会主动规划、主动提议行动；开发者则从执行者转为“指挥者”与“审批者”。同时，规范、长期上下文、可编排行动也被当作 AI 原生工作流的重要基础：用 spec 定义意图，用上下文沉淀记忆，再让 AI 通过命令、工具和自动化去执行。
这些思路本身都没问题。问题在于，它们很容易被进一步落成一种“动作级审批”模型：
人先提出目标，AI 给出下一步动作建议，人确认，AI 执行，返回结果，然后再进入下一轮。
这套流程在演示里很好看，在局部小任务上也确实能成立。但一旦进入真实的复杂开发，就会暴露出一个很核心的问题：
人的审阅带宽，和 AI 的生成速度、改动体量，并不匹配。
一、问题不在 AI 太快，而在协作粒度选错了
很多人会把问题归结为“AI 还不够可靠”，或者“人还不会用”。但我越来越觉得，更底层的问题其实是：
人到底应该在什么粒度上参与协作？
如果让人去审批 AI 的每一个动作，看起来很安全，实际上很快就会陷入两难。
一种情况是，人根本看不过来，只能大致点头。表面上像是在掌控，实际上已经失控。
另一种情况是，人试图认真审阅每次修改、每条命令、每个文件变化，结果协作成本高得离谱，最后还不如自己来做。
这不是习惯问题，而是结构问题。
AI 擅长高速展开、大量生成、连续执行；
人擅长判断目标、校准边界、识别偏差、做阶段性取舍。
如果把人放在“每一步动作审批”的位置上，人就会被迫承担大量低信息密度、碎片化、却又必须谨慎处理的审阅工作。结果是，AI 的效率没有真正发挥出来，人的判断力也没有用在最关键的地方。
二、真正该由人控制的，不是动作，而是收敛
在复杂任务里，最稀缺的通常不是“执行动作”的能力，而是下面这些事情：
当前到底在解决什么问题；
这个问题对象是否已经稳定；
哪些是核心目标，哪些只是当前障碍；
边界和约束是否已经明确；
这一轮该推进到什么程度；
应该用什么标准判断这轮算完成。
如果这些没有搞清楚，那么无论是让 AI 读文件、跑测试、改代码，还是调工具、调 Agent、拆子任务，本质上都只是“在不稳定对象上高速动作”。
动作本身不会自动带来清晰，反而会掩盖一个事实：问题对象其实还没稳定。
所以，人真正该控制的，不是“AI 下一步要不要读 a.go”，也不是“现在要不要跑一遍测试”，而是更高一层的东西：
目标、边界、规范、计划、测试口径、阶段验收。
三、更现实的协作方式：人主导收敛，AI 主导展开
我越来越认可一种更现实的人机协作方式：
人负责高信息密度的收敛与定标，AI 负责高体量的展开与执行。
这里的关键不是谁更聪明，而是谁更适合处理哪类工作。
1. 问题还没稳定时，人必须深度参与
这个阶段不能急着让 AI 开始大规模生成，更不能让它一路自己往前跑。
真正该做的是：
先把当前问题重述清楚；
区分核心问题和障碍；
明确约束；
判断对象是否稳定；
只补最关键的那个缺口；
必要时逐层细化，而不是一上来把所有东西全部摊开。
很多时候，问题不是“AI 不会做”，而是“我们还没把要做的对象稳定下来”。在这种状态下，AI 越能干，跑偏得可能越快。
2. 规范、计划、测试，不适合一次性全部写完
复杂事情很少是先写出一份完整 spec，然后交给 AI 一口气跑完。
更现实的做法，是按层次逐步细化。
先定主干：主问题、主目标、主边界。
再展开分支：当前阶段的子目标、关键约束、主要方案。
最后细到叶子：具体任务、测试样例、验收口径、局部实现。
这样做有两个好处。
第一，人能一直抓住主线，不会一开始就被大量细节淹没。
第二，AI 每次拿到的约束都更清晰，生成出来的东西也更容易验证和承接。
3. 约束一旦明确，就不要再让人盯每个细动作
当规范、计划和测试口径已经敲定之后，就应该让 AI 去高速执行：
大量生成；
连续修改；
自动补测试；
自己运行测试；
在局部范围内反复迭代。
这时候，人不再盯“它每一步做了什么”，而是盯这些更关键的问题：
有没有偏离当前规范；
有没有完成当前阶段目标；
测试是否通过；
结果是否达到验收标准；
有没有出现超出边界的异常改动。
说得更直白一点，就是：
人卡阶段，AI 跑过程。
这比“人批每一步”更现实，也更有可能在复杂任务里长期跑下去。
四、为什么“阶段受控”比“动作受控”更有效
很多工作流看起来很安全，是因为它把控制点放在动作上。
但动作控制通常会带来两个副作用。
第一，控制点太密，人会被迫变成高频审核器。
第二，控制点太低，人一直盯着局部动作，却看不到阶段目标是否真的达成。
更有效的方式，是把控制点上提到阶段性产物上。
比如看：
这一轮问题是不是已经稳定；
这一轮规范是不是已经可执行；
这一轮计划是不是已经可推进；
这一轮测试是不是足以约束生成；
这一轮结果是不是通过验收。
这种方式不是放松控制，而是重新设计控制粒度。
它不是不要人类监督，而是让人类监督落在真正有价值的位置上。
五、这不是“放权给 AI”，而是重新分配职责
这种模型很容易被误解成：“前面讨论一下，后面就让 AI 自己干。”
其实不是。
它并不是把决定权交给 AI，而是把人与 AI 的职责重新划分得更清楚。
人负责：
定义问题；
稳定对象；
明确边界；
敲定规范；
确认阶段计划；
决定验收标准；
在关键节点做选择和复核。
AI 负责：
展开细节；
生成实现；
执行命令；
跑测试；
在既定边界内快速试错；
回收执行结果并反馈。
所以真正的分工不是“人负责判断，AI 负责建议”，而是：
人负责定标与收敛，AI 负责展开与执行。
六、很多讨论已经覆盖了工具层，但还缺“协作粒度”这一层
现在很多产品和教程已经意识到这些东西的重要性：
需要 spec；
需要长期上下文；
需要工具调用；
需要自动化工作流；
需要 review 和安全边界。
这些都很重要。
但在我看来，更关键、也更容易被忽视的一层，是：
如何让人不被 AI 的速度拖垮，同时又不因为过度干预而拖慢 AI。
这不是单纯的工具能力问题，而是协作设计问题。
真正值得补上的，不一定是更多按钮、更多 Agent、更多自动化，而是更清晰的人机分工原则：
在问题不稳定时，人必须主导收敛；
在规范已经明确后，AI 应主导执行；
人不盯每个动作，而盯阶段边界和结果验收。
七、最后收成一句话
复杂任务中的人机协作，不应该是“AI 每步申请，人逐步审批”，而应该是“人主导高密度收敛，AI 主导高体量执行；人卡阶段，AI 跑过程”。
这套方式不算炫，也不适合做那种很顺滑的演示。但它更现实，也更接近复杂工作真正能持续跑起来的样子。
