原视频链接：Full Walkthrough Workflow for AI Coding
YouTube URL：https://www.youtube.com/watch?v=-QFHIoCo-Ko
这篇文章基于 Matt Pocock 的 Full Walkthrough Workflow for AI Coding 整理。重点不是复述某个工具，而是抽出一套更稳定的 AI Coding 工作流：先把模糊需求变成可执行任务，再让 Agent 在清晰边界、测试反馈和独立评审中完成实现。
一、核心判断：AI Coding 仍然是软件工程
AI Coding 很容易被讲成一种全新的范式：写一个 prompt，Agent 自动把功能做完。
但更接近现实的理解是：AI 改变了执行方式，却没有取消软件工程本身。
需求仍然要澄清，任务仍然要拆分，架构边界仍然要设计，测试仍然要跑，代码仍然要评审，用户路径仍然要人工验收。Agent 可以承担越来越多实现细节，但它不能替开发者决定什么值得做、系统边界在哪里、什么结果算完成。
所以，好的 AI Coding 不是“把提示词写狠一点，然后希望模型做对”。更可靠的方式是设计一套系统，让 Agent 接收到：
- 清晰的目标；
- 足够小的任务；
- 可执行的反馈；
- 隔离的工作空间；
- 新鲜上下文里的评审；
- 人类最终 QA。
换句话说，AI Coding 的重点不是让人离开流程，而是把人的精力前移到需求、边界、反馈和验收上。
二、上下文窗口有聪明区，也有失真区
LLM 的上下文窗口并不是越长越稳定。
在一次长会话里，随着 token 不断累积，模型需要维持越来越多注意力关系。前面的问题、旧假设、局部讨论、失败路径和临时结论都会留在上下文里。会话越长，模型越容易把过期信息当成事实，也越容易在局部路径上越走越偏。
演讲里把相对可靠的上下文区间称为 smart zone，把后面容易失真的部分称为 dumb zone。这个说法虽然口语化，但对实际编码很有帮助。
它提醒我们：任务应该被切到 Agent 能在可靠上下文内完成探索、实现和验证。
这也解释了为什么“清空上下文”经常比“不断压缩上下文”更好。
压缩可以保留摘要，但摘要也会保留噪音、旧判断和被扭曲的历史。清空上下文后，Agent 回到系统提示词、仓库说明和当前新材料组成的基础状态。只要任务文档写得足够清楚，新的干净会话反而更可靠。
因此，AI Coding 的一个关键设计原则是：不要依赖一条无限延长的聊天记录。把重要决策写进可复用的任务文档，让每个任务都能从干净上下文重新接手。
三、先对齐，而不是直接计划
很多 AI Coding 失败，并不是因为模型不会写代码，而是因为一开始的需求就不够清楚。
例如一句“给产品加游戏化”听起来像一个功能，其实隐藏了很多决策：
- 哪些行为可以获得积分；
- 历史进度是否要回填；
- 积分展示在哪里；
- 是否需要排行榜；
- 是否影响现有权限和数据模型；
- 哪些东西明确不做。
这些决策通常依赖产品判断、业务上下文和用户偏好，不能直接交给模型猜。
所以工作流的第一步不应该是“让 Agent 写计划”，而应该是 alignment：先让 Agent 追问，直到人和 Agent 对问题形成共同理解。
一个有效的对齐方式是让 Agent 一次只问一个问题，并给出推荐答案和取舍说明。这样做有两个好处：
第一，用户不会被一大串问题压垮。
第二，Agent 不能在关键决策暴露之前就急着生成计划。
这一步的产物不是代码，而是经过澄清的决策记录。它决定了后面任务能不能被安全委托。
四、PRD 是目的地，看板是旅程
完成需求对齐后，下一步是把对话压缩成一份目的地文档。
这里的 PRD 不需要是很重的公司模板。它的作用更具体：记录问题、目标、用户故事、实现决策、测试决策和不做什么。
一份对 Agent 有用的 PRD 至少应该回答这些问题：
| 问题 | 作用 |
|---|---|
| 要解决什么问题 | 防止 Agent 做偏 |
| 用户会看到什么变化 | 明确用户可见结果 |
| 关键实现决策是什么 | 固化已经做过的取舍 |
| 哪些内容不做 | 控制范围 |
| 如何验证完成 | 给 Agent 可执行反馈 |
PRD 说明“要去哪里”，但还不说明“怎么走”。真正用于执行的是下一层：issue 看板。
演讲里更推荐把 PRD 拆成带阻塞关系的 Kanban backlog，而不是一份线性多阶段计划。
线性计划通常假设一个 Agent 按阶段推进：先数据库，再服务层，再接口，再前端。看起来很整齐，但很容易把真实反馈推迟到最后。
看板的好处是可以显式记录依赖关系。一个 issue 被哪些任务阻塞，哪些任务可以并行，哪些任务必须先做，都能在 backlog 里表达出来。
当 backlog 结构清楚后，它就变成了人类和 Agent 的交接物。人负责塑造任务，Agent 负责领取未阻塞的小任务并执行。
五、任务拆分要优先垂直切片
Agent 很容易按技术层横向拆任务：
数据库 -> 服务层 -> API -> 前端这种拆法对人类架构师很熟悉，但对 AI Coding 不一定稳定。因为它会延迟端到端反馈：前几步看起来都完成了，直到最后接起来才发现数据模型、接口语义和 UI 状态不匹配。
更好的拆法是 vertical slice，也就是垂直切片。
一个垂直切片会穿过必要的技术层，产出一个很小但可验证的结果。它不追求一次完成完整功能，而是尽早证明路径走得通。
例如，与其这样拆：
1. 创建积分表
2. 写积分服务
3. 写积分 API
4. 写积分页面不如先做一个最小闭环：
当用户完成一次指定动作时，系统能写入一条积分记录，
接口能返回当前积分总数，
页面能显示这个数字，
并且测试覆盖这条路径。这个切片很小，但它能验证数据库、业务逻辑、接口和 UI 是否真的连通。后续扩展排行榜、历史回填、规则配置时，都会站在一个已经跑通的基础上。
这就是软件工程里 tracer bullet 的价值：先看到弹道，再决定是否继续加火力。
六、AFK 实现不是失控实现
当 PRD 和 issue 看板足够清楚后，部分实现任务可以进入 AFK 状态。
这里的 AFK 不是“完全放飞”，而是 Agent 可以在没有持续人工提示的情况下完成一个边界明确的任务。前提是任务已经具备：
- 明确目标；
- 输入上下文；
- 约束条件；
- 验收方式；
- 可运行检查；
- 失败时的处理边界。
一个最小实现循环可以写成这样：
读取 PRD 和 issue 看板
查看最近提交
选择一个未阻塞的 AFK issue
确认任务边界和验收标准
先补失败测试
实现最小改动
运行测试、类型检查和构建
提交结果这个循环里最重要的是反馈。没有测试、类型检查、lint、构建和本地验证时，Agent 就是在盲写代码。反馈越弱，Agent 的产出上限越低。
这也是为什么 TDD 对 Agent 编程特别有价值。
先写失败测试，可以把需求变成可执行约束。再实现最小改动，可以减少 Agent 自由发挥的空间。最后重构，则把代码质量拉回到可维护状态。
如果让 Agent 先随便实现，再补一个证明自己实现正确的测试，测试就很容易变成形式主义。TDD 的关键是让测试先于实现出现。
七、评审要使用新鲜上下文
Agent 实现完后，可以继续用 AI 做代码评审，但最好不要在同一个已经很长的实现会话里评审。
原因很直接：实现过程可能已经消耗了上下文的可靠区间。更重要的是，实现会话里带有大量局部假设，评审者如果继承这些假设，就不容易发现问题。
更好的模式是：
清空上下文
提供 PRD / issue / diff / commit
要求 Reviewer 只看最终变化
对照编码规范、测试策略和任务目标做审查实现阶段可以把编码规范作为 pull-based 信息：Agent 需要时自己查。
评审阶段则应该把编码规范作为 push-based 信息：明确要求 Reviewer 拿代码和规范对照。
这会让评审更尖锐，因为 Reviewer 不会被实现者的局部路径影响。
自动化评审之后，仍然需要人工 QA。尤其是前端、交互、文案和产品体验，模型很难稳定判断成熟界面里的细节质量。
人工 QA 是把品味和真实用户体验重新放回系统的环节。它不只是“看一眼页面”，而是要真实走一遍用户路径，并把发现的问题重新写回 issue 看板。
八、代码库质量决定 Agent 上限
糟糕代码库会产生糟糕的 Agent 输出。
如果一个项目对人来说难以理解，对 Agent 通常也难以导航。大量浅模块、细碎导出、隐式全局状态和模糊边界，会让模型很难建立稳定心智模型。
更适合 Agent 协作的代码库，通常具备这些特征：
- 模块边界清楚；
- 公共接口较小；
- 内部行为足够集中；
- 测试边界明确；
- 命名和目录能反映业务语义；
- 本地检查命令稳定可运行。
这里的重点不是把代码拆得越碎越好，而是形成 deep modules：接口尽量小，内部行为足够完整，外部调用者不需要知道太多内部细节。
人类应该牢牢掌握模块边界、公共接口、数据模型和测试策略。Agent 更适合在这些约束下实现内部细节。
一旦边界交给模型随意扩散，后面的维护成本会迅速回到人身上。
九、过程文档有用，但也会腐化
PRD、计划和 issue 是执行期间非常有用的材料，但它们也会过期。
如果一份旧 PRD 长期留在仓库里，未来 Agent 可能把它当成权威上下文，即使代码、命名、需求和用户行为已经变化。
这就是 documentation rot 的问题：文档活得比事实更久。
比较稳妥的处理方式是：
- 执行中的 PRD 和 issue 保持清晰；
- 完成后的计划材料及时关闭或归档；
- 不让历史过程文档静默影响未来任务；
- 真正长期有效的信息，沉淀到 README、架构文档或测试里。
过程文档的价值在于服务当前执行。它一旦变成历史材料，就应该降低权威性。
十、并行 Agent 需要结构化 backlog
多 Agent 并行只有在任务已经被整理成适合并行的形状时才有价值。
如果 backlog 没有依赖关系，多个 Agent 很容易领取冲突任务：一个改数据模型，一个改 API，一个改前端，最后合并时互相打架。
更可靠的多 Agent 模式是：
Planner 选择下一组未阻塞 issue
Implementer 在独立 worktree 或分支里实现
Reviewer 检查对应 commit
Merger 控制合并顺序并处理冲突关键不在具体工具，而在系统形态：隔离工作、明确评审、受控合并。
这也说明并行不是起点，而是规划质量的结果。只有当任务边界、依赖关系和验证方式已经足够清楚时，并行 Agent 才能提升吞吐，而不是制造混乱。
十一、一套可执行的简化流程
如果把整套方法压缩成实践步骤，可以是下面这样：
- 把模糊需求变成追问会话。
- 要求 Agent 一次只问一个问题，并给出推荐答案和取舍。
- 把对齐后的内容整理成 PRD，记录目标、决策、测试和不做什么。
- 把 PRD 拆成 issue，看板里显式写出阻塞关系。
- 拒绝纯横向分层的 issue，优先做可验证的垂直切片。
- 标出哪些 issue 可以 AFK 实现，哪些必须人工决策。
- 让 Agent 对单个未阻塞 issue 使用 TDD 和本地检查完成实现。
- 用新鲜上下文评审最终 diff 或 commit。
- 人工 QA 用户可见路径。
- 把缺陷重新写回 issue，并关闭或归档过期过程文档。
这套流程的核心不是复杂，而是让每一步都能留下可检查的产物。
对齐阶段留下决策。
PRD 留下目的地。
看板留下路径。
测试留下约束。
提交留下结果。
评审留下问题。
QA 留下真实反馈。
十二、总结
这场演讲最有价值的部分，不是某个具体工具，也不是某个万能 prompt。
真正有价值的是工作流形状。
AI Coding 做得好时，开发者不是坐等模型生成代码，而是在设计一套让 Agent 更容易成功的工程系统。这个系统会限制任务范围，暴露关键决策，提供可执行反馈，隔离实现上下文，并用新的上下文做评审。
工具会继续变化，但困难的部分仍然是那些老问题：需求、边界、反馈、测试、评审和品味。
这也是为什么 AI Coding 越往后走，越不像单纯的 prompt 技巧，反而越像软件工程本身。