AI 编程越用越返工？因为你让 AI 自己批改自己的作业
AI 编程很强，这一点没人否认。但你有没有发现一个诡异的现象：代码出得更快了，返工反而更多了。
需求确实更容易写偏了。你给它一句话，它给你补成一整套系统——推荐引擎、统计报表、多标签筛选、三张数据库表、权限模块、完整测试计划。看起来很积极，但越积极越危险，因为这些范围还没被你确认，就已经被固化进了代码。
最后还是你在修范围、改命名、补测试、查 bug、补验收。
你不是没有用 AI，你是被 AI 的输出拖着跑。
问题的根源不在于 AI 不够强，而在于你缺少一套控制 AI 输出的流程。
今天分享一个核心方法论，我叫它"三权分立"。它帮我把 AI 编程从"人肉流水线"变成了可控的开发链路。
一、你现在的工作方式：人肉流水线
先看你现在的状态。
你手动在每个 AI 窗口之间当调度员：输入需求、让 AI 澄清、确认、切窗口写代码、再切回来自己验收。看起来在协作，其实你是人肉流水线。
更关键的问题藏在深处——写代码的和验收代码的是同一个 AI。它给你一份看起来很完整的输出，但里面可能埋了没确认的假设、跳过的步骤，甚至是伪造的证据。
同一个 AI 同时扮演写代码和验代码两个角色，这就是"提示词驱动"的天花板。
提示词写得再长、再漂亮，也解决不了这个结构性矛盾。就像你不能让一个学生自己出题、自己答卷、自己批卷，然后相信他考了满分。
二、三权分立：把四个角色分开
核心思路其实很简单。把原来你一个人当调度员，拆成四个角色，各管各的。
总控 Skill 是流程调度员。它就是一个 SKILL.md 文件，定义了状态机——管理流程推进，决定什么时候让 AI 写、什么时候让 AI 验、什么时候停下来问你。
Maker 是执行者。它只负责写代码和生成证据。它最多把自己的产出标记为 ready_for_checker，禁止自己声明"我做完了"。
Checker 是验收者。它只读权限，不改代码。它读 OpenSpec、源码、diff 和证据，只输出三个结果之一：PASS、FAIL 或 BLOCKED。
你 是关键决策者。你只在四个关键点介入：启动需求、确认方案、确认切片、处理阻塞。其他全自动。
这四个角色里，最重要的规则只有一条：
写代码的 AI 永远不能验收自己的代码。只有 Checker 说 PASS，才算完成。
三、Maker 永远不能自己判 PASS
这是整套方法论最关键的一条规则，值得单独拿出来说。
Maker 只能标记 ready_for_checker，永远不能自己判 PASS。只有 Checker 独立审查后返回 PASS，总控才把状态改成 done。
如果 Checker 说 FAIL，工作自动回到 Maker。但 Maker 只修失败项，不扩大范围，不改验收标准。
如果 Checker 说 BLOCKED，才升级到你来做决策。
这条规则消灭了 AI 编程最大的风险——AI 自己批改自己的作业。
你可能会觉得这是常识，但你去看看现在市面上绝大多数 AI 编程教程和工作流，是不是都在让同一个 AI 从写代码到跑测试一条龙包办？那个"测试通过"到底是真的通过了，还是 AI 帮你写了一个永远会通过的测试？
四、从模糊需求到可控交付的状态机
整条链路是这样的：
澄清 → 方案 → 切片 → 执行 → 验收 → 最终 QA
具体来说：先澄清需求，AI 读上下文，只问一个关键问题，不写代码。然后自动生成方案（proposal、design、spec 和 tasks.md）。接着拆成 vertical slice issues，过质量门禁。然后 Maker 逐个执行 issue，每个 issue 必须通过 Checker 才能继续。全部完成后跑最终 QA。
每一步都有明确的门禁，不允许跳步。
这不是纸面上的理论。它背后是真实的 skill 编排——从 grill-with-docs（需求澄清）到 to-issues（任务切片）到 writing-plans（实现计划）到 TDD（测试驱动开发）到 review（代码审查）到 verification（完成验证），每一步都有对应的开源工具支撑。
举个真实场景。给制造 ERP 加自动拆批功能，按产线产能约束拆分批次。Checker 审查后查出三个问题：验收标准缺失、跨天场景未覆盖、门禁逻辑没说清。直接打回 Maker 修复。
再比如 Web 路由迁移，产品页路由从旧组件树迁到新架构。Checker Gate 要求必须真实点击"产品中心"入口，验证页面到达 /product-center 而不是被重定向到旧的 /category/cabinet 路径。不能只检查 href 属性——那只是表面通过。
这些都是真实开发中会碰到的硬骨头，不是玩具 Demo。
五、五大反模式：你必须避开的坑
用了这套方法之后，我总结出五个必须避免的反模式。
第一，手动写 Maker 提示词。 每个 issue 都手写一遍 Maker 提示词，效率极低，容易出错。应该由总控 skill 自动编排。
第二，手动写 Checker 提示词。 每个 issue 都手写验收提示词，跟没有这套方法没区别。
第三，在聊天里维护第二份 TODO。 tasks.md 是唯一执行清单，聊天里再造一份会导致状态分裂。你在聊天里说"这个先跳过"，但 tasks.md 里没改，后面执行的时候一定会冲突。
第四，让 Maker 自评 PASS。 这是最危险的反模式。AI 批改自己的作业，永远判自己通过。
第五，Checker 没过就进入下一个 Issue。 带病推进，后期必然返工，而且问题越积越深。
这五条是无数真实开发踩坑总结出来的。每一条看起来都"好像也没那么严重"，但每一条都会在项目后期以十倍的成本回来找你。
六、小改动不用走全流程
有人会说：改个 typo 也要走十步流程吗？
当然不是。
这套方法论内置了风险自适应机制。AI 会先评估变更的风险等级。如果是低风险的小改动——比如改个错别字、调整一下样式——直接跳过方案阶段，做最小变更加针对性验证。
只有高风险变更，比如涉及权限、租户隔离、核心业务逻辑的改动，才走完整流程。
流程的重量应该随风险自动调节，而不是要么全跑要么全不跑。
七、一句话记住
以前，你是流程调度员，AI 是执行者。
以后，Skill 是流程调度员，Maker 是执行者，Checker 是验收者，你是关键决策者。
而且这不需要任何插件或复杂工具。只需要一个 SKILL.md 定义状态机，加上固定的 Maker 和 Checker 提示词模板。本质是用纪律编排现有能力，实现质变。
AI 编程真正的提效，不是让 AI 更快写代码，而是让你更少为 AI 的输出返工。
如果你看完想系统掌握这套控制 AI 编程的方法，我做了一套 12 集实战课程，前两集免费，帮你建立判断框架。CSDN 搜索：AI 编程实战 Superpowers gstack MattPocockSkills。