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。
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。
