先拆误区：AI 编程不是把需求丢进聊天框
很多人试过让 AI 帮忙写代码：把需求往对话框里一丢，等它吐出结果。结果往往差强人意——它好像不太懂你想要什么。问题不一定出在 AI 身上，而是输入太模糊。Matt Pocock 是工程师、教育者和内容创作者。在他展示的 AI 开发流程里，第一步不是写代码，而是把一句模糊的 brief（需求简报）压力测试成一份 agent-ready 的 PRD。
这两个词先打个底。agent-ready 指一份 AI 能直接理解并执行的需求描述；PRD 是产品需求文档，一份写清楚要做什么、为什么做、怎样算完成的计划。为什么要这么讲究？可以把它理解为给实习生派活：你说做个好用的 App，他只能挠头；你说清用户是谁、解决什么问题、第一版要哪些功能，他才知道从哪儿下手。AI 也是一样——缺的往往不是 AI 的能力，而是给 AI 准备输入的方法。对普通团队而言，这意味着给 AI 下指令前先写清楚“我要什么”，通常是最值得优先尝试的改进。
七阶段工作坊：从模糊想法到可运行代码的完整闭环
2026 年 4 月，Matt 在一场公开视频《Full Walkthrough: Workflow for AI Coding》里，把整套 AI 辅助开发流程拆成七个阶段：研究与原型、Grill Session、写 PRD、拆分 Issues、AI Agents 实现、人工审查、部署与监控。这是用来讲清全貌的教学框架。串起来看，每一步都在解决一个具体问题：
研究与原型：把模糊需求变成能上手讨论的东西。
Grill Session：压力测试想法。Grill 本意是拷问，这里指像审问一样反复追问，把没想清楚的隐含假设逼出来。
写 PRD：把讨论结果固化成人和 AI 都能读的计划。
拆分 Issues：把大计划切成小块。这里的小块不是随便切，而是 tracer bullet（曳光弹）式的垂直切片——可以把它理解为一根针穿过所有层：沿着数据结构、接口、界面、测试各层走一条窄而完整、能独立演示的路径。
AI Agents 实现：让 agent 在 TDD 框架内执行编码任务。TDD（测试驱动开发）就是先写测试、再写代码让它通过，让对不对由客观标准说了算。
人工审查：人检查 agent 的产出，不是走过场。
部署与监控：上线，并在运行中观察表现。
为什么是这个顺序？分析一下：每一步都在缩小不确定性——先想清楚做什么，再拆小怎么做，最后验证做对没有。
这七步里有两个很值得记住的模型。第一个是 smart zone / dumb zone：上下文越长、越混杂，AI 的表现越差。可以把它理解为：别让 AI 背着越来越重的行李爬坡——任务拆得越碎，每个 agent 手里的上下文越干净，它就越不容易犯糊涂。所以要把大任务拆成小任务，让 agent 始终在比较新鲜、干净的上下文里工作；Matt 甚至更偏好清空后回到稳定起点，而不是反复压缩同一段越来越乱的对话。第二个是白班 / 夜班：人负责前半程——想法、Grill、PRD、任务看板，相当于白班，定方向、做判断；进入实现后，才让一个或多个 agent 去消化任务看板，相当于夜班，做执行和重复。这句话的另一面是：判断先于自治——人先把方向定清楚，AI 再去跑腿，而不是把整件事丢给 AI。此外还有一条贯穿始终的主张：测试、类型检查这些反馈回路，是 AI 输出质量的上限之一，回路越密越准，AI 越不容易跑偏。视频还涉及面向 AI 效能的代码库设计——让仓库更容易被 AI 读懂，但公开资料细节有限，本文不单独展开。
从工作坊到工具：2026 年 8 月的五步技能链
教学框架讲的是道理，真正上手还需要工具。截至 2026 年 8 月，Matt 在他的 AI Hero 官网上，把方法收敛成一条五步技能链：grill-with-docs → to-spec → to-tickets → implement → code-review。要特别注意：七阶段是 2026 年 4 月的教学框架，五步链是 2026 年 8 月的产品化工具，时间不同、用途不同，不是同一个版本的两种叫法。
grill-with-docs：通过访谈达成共享理解，把术语和关键决策记录进仓库。翻译过来就是开工前先把人和 AI 拉到同一张桌子，说清楚这些词是什么意思、为什么这么定。
to-spec：把已定的决策固化成文档，作为跨会话的交接物。注意，spec 不是越长越好——它是已经达成的决策记录，不是重新做决定的地方；而且只有当工作跨越多个 agent 会话时才需要它，小任务可以直接跳过、进 implement。
to-tickets：把 spec 拆成一张张 ticket（任务卡）。每张 ticket 都必须是 tracer bullet：沿 schema、API、UI、tests 等层面走一条窄而完整、可独立演示的路径，标出阻塞边界，控制在一个全新上下文窗口能完成的大小。这里 schema、API、UI、tests 分别指数据层、接口层、界面层和测试层。
implement：接收已经决定好的 ticket、spec 或会话计划，不再重新打开规划，而是围绕预先约定的可观察行为边界驱动 TDD、持续做类型检查，末尾跑一遍 code-review 再提交。
code-review：把审查拆成两条互不混合的轴——Standards 检查你按仓库规范写对了吗，Spec 检查你做的是对的事吗、实现了原始需求吗。一条轴通过，掩盖不了另一条轴的失败。
和七阶段相比，有两处可观察的差异（这是分析，不是已证实的合并关系）：七阶段里的研究与原型和 Grill Session，在五步主链里不再作为独立命名的步骤出现——但我们无法确定它们被合并进了哪一步，只能说当前技能链没有把它们单列出来；另外，code-review 的官方定义只支持 Standards 与 Spec 双轴 diff 审查，部署与监控在五步主链里也没有作为命名步骤列出。这不是说那些环节不重要了，而是说明：教学时要摊开讲清每个环节，产品化时则会收敛取舍——但共同的内核没有变（分析）：先对齐（人和 AI 共享理解）→ 切小闭环（tracer bullet 小任务）→ 反馈兜底（测试、类型检查、code-review）。
普通团队能借鉴什么：边界与可迁移原则
看到这儿你可能会问：我又不是 Matt，也没装 AI Hero，能带走什么？这套方法的核心其实不是工具，而是几条可以迁移的原则（分析 / 推论）：
先提高输入的可执行性：给 AI 任何指令前，先把“我要什么、怎样算完成”写清楚，把模糊需求改写成 agent-ready 的描述。对普通团队而言，这是成本较低、最值得先尝试的一步。
判断先于自治：先人工讨论出方向，再让 AI 执行具体步骤。对普通团队而言，这意味着人负责做什么和对不对，AI 负责怎么做，别一上来就放权。
拆小、拆垂直：把大任务切成边界清楚、能独立验证的小块，让每块都有完整路径和客观完成标准。对普通团队而言，哪怕没有专门的工具，也可以用"验收标准 + 小块交付"来约束 AI。
反馈回路是上限：给 AI 的工作配自动化测试或类型检查，别只靠人眼盯。对普通团队而言，能把一部分检查前移并自动化，就能减少只靠人眼发现问题的压力。
小任务不必走全流程：改一行文案，直接做就好，不必写 spec。流程是给大事准备的，小事套全流程反而拖慢。
也要讲清边界（推论）：Matt 这套流程是他个人的教学实践，不是经过对照实验验证的效率定律——目前没有公开数据能证明它能提升多少效率、减少多少 bug，所以这篇文章不给数字；agent 自治也不等于人类退出责任，七阶段里人工审查和部署监控始终在场，五步链的 implement 也要求人选择正确的分支、ticket 和会话边界。AI 替你跑的每一步，前面都得有一个想清楚的人——这正是这套方法真正值得带走的纪律。
参考文献
71 次点赞
今天可以点赞一次