AI辅助编程工作流：Matt Pocock的8条实战经验

AI编程工具越来越强大，但很多人发现：用AI写代码一段时间后，生成质量反而下降。问题出在哪里？Matt Pocock在他最近的工作坊《Full Walkthrough: Workflow for AI Coding》中给出了一套系统答案。

他的核心观点是：好的AI辅助编程不在于写出更精妙的提示词，而在于把扎实的软件工程实践应用到AI代理上。 换言之，AI并没有取代软件工程基本功，反而让这些基本功变得更加重要。

理解AI的"智能区"与"迟钝区"

Matt Pocock提出了一个直观的比喻：LLM的上下文窗口有两个区域。

• 智能区（Smart Zone）：上下文新鲜、任务聚焦，模型做决策的质量更高。
• 迟钝区（Dumb Zone）：上下文膨胀、信息过载，模型可靠性下降，错误增多。

他以大约100K token作为实践中的警戒线——这不是技术上的硬限制，而是一个需要警惕的信号。

对应策略包括：把大任务拆成小的独立任务；系统指令保持精简；与其反复压缩长对话，不如清空上下文、用明确定义的任务重新开始；需要隔离探索时使用子代理（subagent），避免污染主代理的上下文。

这背后其实是一条朴素原则：任务越小、上下文越干净，AI的输出质量越可控。

上下文窗口（Context Window） 是LLM单次推理时能“看到”的全部token序列，包括系统提示、历史对话、代码文件和工具返回结果，通常以token数计量。主流模型的名义上限从128K到200K不等，但有效推理能力往往在远低于上限时就已衰减：注意力被大量无关内容稀释，关键指令的相对权重下降，模型开始遗漏约束或重复犯错。因此业界常说的“有效上下文”（effective context）通常显著小于标称窗口，实践中需要靠任务切分、子代理隔离和结构化摘要来控制真正喂给模型的信号密度，而不是简单地把所有材料塞进窗口。

先对齐需求，再写代码

大多数人的习惯是直接把需求扔给AI，让它开始实现。Matt Pocock的做法相反：他设计了一个叫"Grill Me"的技能——让AI反过来采访开发者，一次问一个问题，并给出建议答案。

比如要做一个游戏化功能，AI会逐条追问：哪些活动能赚积分？老用户是否补发追溯积分？等级如何运作？UI放在哪里？

目标是在动手之前达成共识。这揭示了一个重要判断：规划阶段需要人的深度参与，编码阶段才可以放心委托给AI。 需求模糊时就让AI开写，后续返工的成本远高于前期多花十分钟对齐。

PRD与独立任务：定义目的地

需求清晰之后，下一步是写产品需求文档（PRD），覆盖问题与方案、用户故事与验收标准、实现决策、测试要求、以及明确排除在范围之外的功能。

PRD描述的是"目的地"。接下来把它拆解成带显式依赖关系的独立issue，形成看板式的任务队列，代理可以逐项处理，甚至并行推进。

这套做法的价值在于把"人做架构决策"和"AI做实现执行"分开。任务边界越清晰，AI跑偏的空间越小。

垂直切片，而非水平分层

AI有一个天然的倾向：按层实现功能——先建整个数据库层，再做所有API，最后写前端。问题是，端到端的有效反馈来得太晚。

Matt Pocock推荐垂直切片（tracer bullets）：每个小功能都贯穿数据库变更、后端逻辑、API集成、最小前端和测试。每一片都能独立运行和验证。

这样集成问题暴露得更早，修复成本更低，也让AI在每一步都能拿到真实的反馈信号。

tracer bullets（曳光弹） 一词出自《The Pragmatic Programmer》，原意是夜战中曳光弹能显示弹道，让射手即时修正方向。在软件开发中它指用最小但端到端可运行的一条功能路径贯穿所有层次，以便尽早获得真实环境下的反馈。它与水平分层的关键区别在于反馈时机：分层实现要等所有层都完成后才能第一次运行系统，而垂直切片每一步都产出可验证的行为。对AI代理而言这一点尤其重要，因为模型只能在可执行的反馈信号上迭代，无法运行的系统等于没有反馈。

Ralph循环与并行执行

任务队列就绪后，实现可以变成自动化循环：选一个未被阻塞的issue、探索相关代码、实现功能、运行测试和类型检查、提交变更、重复直到队列清空。Matt Pocock用"Ralph风格"的循环演示了这一过程。

并行执行方面，他介绍了Sand Castle——利用隔离的Git worktree和Docker沙箱，让不同代理分别负责规划、实现、审查和合并。这种分工方式把软件工程中的CI/CD思路延伸到了AI代理的编排上。

TDD让AI更可靠

Matt Pocock强烈推荐对AI代理使用测试驱动开发（TDD），遵循红→绿→重构的节奏：先写一个失败的测试，再实现刚好通过测试的最小代码，最后在测试保持绿色的前提下重构。

先写测试有一个微妙但关键的作用：它让AI很难生成"只确认自己已有实现"的弱测试。更根本的是，AI需要快速反馈回路——单元测试与集成测试、类型检查、lint、自动化代码审查。

一句话总结他的观点：反馈回路的质量，往往决定了AI生成代码的质量。

红→绿→重构 是TDD的三段节奏：红指先写一个必然失败的测试，确认测试本身有效且需求被准确表达；绿指编写刚好让测试通过的最小实现，避免过度设计；重构指在测试保持绿色的保护下改善结构。对AI代理来说，“红”这一步还承担了规格说明的作用——测试先于实现存在，模型就无法反向根据已有代码编造一个必然通过的断言。若缺少这一约束，模型倾向于写出与被测实现高度同构的测试，覆盖率看似很高却无法发现真实缺陷。

深模块与简单接口

Matt Pocock还借用了《A Philosophy of Software Design》中的概念，推荐深模块设计：公开接口小而清晰，内部隐藏大量功能，职责明确，边界易于测试。

这优于大量细小且紧耦合的模块。开发者应当理解和掌控整体架构，把内部实现细节委托给AI。随着AI生成的代码越来越多，这条原则是防止开发者丧失架构理解的护栏。

深模块 是John Ousterhout在《A Philosophy of Software Design》中提出的核心概念，用以对比“浅模块”：浅模块接口复杂而内部实现简单，大量逻辑外泄到调用方，导致复杂度在系统中扩散；深模块则用少量方法承载大量功能，把复杂度封装在内部。书中提出的“pass-through method”“信息泄漏”“类线团”等反模式都指向同一结论：软件设计的主要目标是控制复杂度。对AI辅助开发而言，深模块还有一个额外好处——接口小意味着代理需要理解的契约面小，生成和修改代码时出错的机会也随之减少。

人工QA与代码审查不可跳过

自动化测试通过不等于产品可用。Matt Pocock强调人类仍需：验证真实的用户行为、审查重要的架构决策、检查测试与关键代码、评估前端可用性、识别遗漏的需求。

他还建议用全新的AI上下文来做代码审查，而不是让代理在长时间实现会话后审查自己的产出——后者容易陷入自我确认的盲区。QA发现的问题可以回流为新的backlog条目，形成持续改进的循环。

完整工作流一览

这套方法论可以串成一条清晰的流水线：

1. 想法
2. Grill Me（需求对齐）
3. PRD（定义目的地）
4. 独立issue（垂直切片）
5. AI实现（Ralph循环）
6. TDD与自动化反馈
7. AI代码审查
8. 人工QA
9. 新issue与改进
10. 循环往复

开发者的角色正从"写每一行代码"转向定义需求、设计系统、提供反馈和维护质量。AI能承担大量实现工作，但决策权和最终产品的责任仍然在人手里。

如果你正在用Claude Code、Cursor或其他AI编程代理，不妨从这套流程中挑一两个环节先试起来——比如下次动手前先让AI"采访"你一轮，或者强制自己先写测试。这些看起来朴素的工程习惯，恰恰是AI时代最稀缺的竞争力。