外观
第 9 章 · AI Agent 工作流方法论
前面 8 章教的是「零件」：Prompt、TUI、上下文、规则、Agent、工具、配置。本章把它们组装成一台完整的机器——一套可重复的工作方法，让你从「会问 AI 问题」进阶到「用 AI 系统性地交付项目」。高手与新手的差距，往往不在单个技巧，而在有没有稳定的工作流。
本章包含 5 个知识点：
- 任务拆解：把大需求切成 AI 能吃下的块
- 计划先行：让 AI 先想清楚再动手
- 探索—构建—验证：一个回合的标准循环
- 子代理编排：主 Agent 当调度，子 Agent 当工人
- 快照安全网、复盘与交付纪律
知识点 1：任务拆解：把大需求切成 AI 能吃下的块
① 定位
工作流的第一步永远发生在动手之前：判断任务有多大、切成几块。 这是决定整个项目成败的一环——大块任务直接丢给 AI，是返工、混乱、上下文爆炸的最大来源。
② 是什么（What）
任务拆解就是把一个大目标，按「可独立完成、可独立验证」的原则分成若干小任务，每次只让 AI 做一件事（呼应第 1 章的单任务原则）。
一个好的子任务有三个特征：
- 边界清晰：明确改哪个模块、不碰哪里；
- 结果可验证：有明确的完成信号（测试通过、某行为出现）；
- 上下文可承受：所需材料放得进窗口，不需要 AI 同时理解整个系统。
拆解的常用切法：
| 切法 | 例子 |
|---|---|
| 按层次切 | 数据层 → 接口层 → UI |
| 按功能切片（推荐） | 每个切片含「后端 + 前端 + 测试」，可独立演示 |
| 按风险切 | 先做低风险探路部分，再做核心难点 |
| 按依赖顺序切 | 被依赖的基础模块先行 |
③ 怎么做（How）
- 拿到需求先自己（或让 plan Agent）写出任务清单与依赖顺序，不要直接开做；
- 每个子任务用一条独立、完整的 Prompt 交代（含上下文与验收标准）；
- 一个子任务完成、验证通过后，再进入下一个；
- 发现子任务仍然太大（AI 一轮做不完 / 频繁压缩）→ 继续切细；
- 用 Tabs / Sessions 把不同子任务分开（第 2 章），避免互相污染上下文。
④ 为什么这么做（Why）
- 大任务超出模型的「一次规划能力」。 让 AI 一步到位实现一个完整系统，它必须在脑中同时维护几十个决策，错误率随复杂度急剧上升；切成小块后，每步只需处理少数决策，成功率大幅提高。
- 小任务的反馈环短，纠错成本低。 整块做一小时后才发现方向错了，返工巨大；每个小块几分钟内验证，错误被关在最小范围内。这是工程上「小步快跑」的根本理由。
- 上下文窗口是硬约束。 大任务需要的证据（十几个文件、长讨论）可能装不下，模型只能看到片段；拆解后每个子任务携带精炼上下文，信息密度高。
- 可验证的切片让进度真实可信。 「完成了 60%」无法度量；「6 个切片中 4 个已通过测试」清清楚楚，交付风险可见。
- 拆解本身就是理解需求的过程。 写不出任务清单，往往说明需求还没想清楚——先拆解能逼出模糊点，避免让 AI 替你猜测一个含糊的目标。
⑤ 这样做的好处
- 每个子任务成功率高，整体进度稳定。
- 返工范围小，错误早发现。
- 上下文始终精炼，减少压缩与遗漏。
- 进度可度量、风险可见。
- 需求模糊点在动手前暴露。
⑥ 不这么做的问题 / 坏处
- 大需求一句话丢给 AI → 它东改西改、遗漏需求、上下文爆满。
- 不排依赖顺序 → 后做的基础模块推翻前面的工作。
- 子任务无验收标准 → 「做完了」却无法确认对错。
- 多个任务挤在一个会话 → 上下文滚成一团，后期质量骤降。
⑦ 举一反三：三个例子
例 1（基础）：拆解一个登录功能
📌 场景：「给网站加登录。」
✅ 切分：① 用户表 / 数据模型 → ② 注册 + 密码哈希接口 → ③ 登录签发 token 接口 → ④ 前端登录页 → ⑤ 鉴权中间件保护页面；每步含测试。
🔍 讲解：按依赖顺序切成 5 个可验证小块。每块 AI 只需理解少数文件，做完跑测试再进入下一块——比一句「帮我做登录」可靠十倍。
例 2（进阶）：按功能切片组织团队协作
📌 场景：一个功能横跨前后端，你希望尽早看到可演示成果。
✅ 切法：不按「先做完所有后端、再做所有前端」分层，而切成薄切片（如「能创建一条记录并在页面看到」），每切片纵向贯穿前后端、可独立演示。
🔍 讲解：功能切片让每个小块都产生用户可见价值，风险（如前后端接口理解不一致）在第一个切片就暴露，而不是在集成阶段集中爆发。
例 3（挑战）：拆解一个模糊的大目标
📌 场景：老板说「把系统的性能优化一下」。
✅ 做法：先不切代码任务，而切成「① 确定性能指标与基线（哪里慢、慢多少）→ ② 定位瓶颈 → ③ 针对头号瓶颈出方案 → ④ 实施并对比指标」；第一步本身是个探索任务。
🔍 讲解：模糊目标无法直接拆解成代码块，要先切出「度量与定位」环节。没有基线就无法验证优化是否有效——先让问题可测量，是处理一切模糊需求的通用起手式。
⑧ 练习题 ×2
练习 1（巩固型）
📝 题目：一个好的子任务有哪三个特征？说出至少三种任务切法。
💡 思路提示：边界 / 可验证 / 上下文可承受；层次、切片、风险、依赖。
✅ 参考答案：
text
三特征：边界清晰（改哪、不碰哪）、结果可验证（有完成信号）、
上下文可承受（材料放得进窗口）。
切法：按层次、按功能切片、按风险、按依赖顺序。🔍 讲解：用这三把尺子检查每个子任务，不合格就继续切细。
练习 2（迁移型）
📝 题目：迁移到写长篇小说 / 论著：作家为什么先列大纲与分章、而不是提笔从头写到尾？章节的「独立成篇 + 服务主线」与子任务的什么特征对应？
💡 思路提示：全局结构、局部闭环。
✅ 参考答案（示例）：
text
- 先列大纲：保证全局结构合理、前后呼应，避免写到后期推翻重来；
- 分章写作：每章自成一个可独立打磨的闭环，反馈环短；
- 章节同时服务主线：独立成篇 ≈ 子任务可独立验证，
服务主线 ≈ 子任务边界对齐整体目标与依赖。
共性：AI 项目的任务拆解与写作分章同构——先有全局蓝图，
再把大目标切成各自闭环、又彼此衔接的小块逐个攻克。知识点 2：计划先行：让 AI 先想清楚再动手
① 定位
任务切成块之后，每个块动手之前还有一道关键工序：先出方案、审查后再做。 这一步把「AI 擅自发挥」挡在改动发生之前，是成本最低的质量控制。
② 是什么（What）
计划先行就是要求 AI 在修改任何文件前，先给出它的理解与方案：
- 对需求的理解：它认为要解决什么问题；
- 影响面分析：涉及哪些文件、模块、接口；
- 实施步骤：按什么顺序做；
- 风险与权衡：有哪些副作用、需要你决策的取舍点。
V2 的 plan Agent 正是为这个阶段设计：它以 primary 模式运行，不编辑普通项目文件（被要求时可写 OpenCode 的 plan 文件），专注探索与出方案。你可以 <leader>a 切到它，或直接对 build 说「先别改，先给方案」。
一个典型的两段式：
text
plan 阶段：探索代码 → 输出方案（零改动）
↓ 你审查、提修改意见、确认
build 阶段：按确认的方案实现③ 怎么做（How）
- 每个非琐碎子任务，先让 plan（或让 build 声明「先计划」）出方案；
- 审查方案时重点看：它理解对需求了吗？影响面漏了吗？顺序合理吗？
- 有疑问就在此阶段提出，让它修订方案——改动方案比改动代码便宜；
- 确认后再切 build 实现，并可让它按已确认的计划逐步推进；
- 简单到一眼能看清的任务可跳过计划，避免仪式过重——计划的详略与任务风险匹配。
④ 为什么这么做（Why）
- 错误的方案无法靠好的执行挽救。 方向错了，实现得越快、错得越多；在零改动阶段把方案审查清楚，是从源头消灭返工。质量控制越靠前，成本越低——这是「质量左移」。
- 模型对需求的理解可能与你不同。 让它先复述理解，分歧在写代码前就暴露；否则它可能按自己的解读做出一堆改动，你才发现答非所问。
- plan Agent 不碰项目文件，消除审查时的心理负担。 你可以放心让它大胆探索，不必担心它一边想一边改；工具层面的只读约束比「请先别改」的口头要求可靠（第 5、7 章）。
- 方案中的风险清单把隐性决策显性化。 「这两个方案各有什么取舍」被写出来后，决策权回到你手里，而不是被模型默默替你选了。
- 审查的是思路而非 diff，认知负荷低。 看一页方案比审查十个文件的改动轻松得多，也更容易发现结构性问题。
⑤ 这样做的好处
- 方向正确再投入，返工大幅减少。
- 需求分歧早暴露。
- 探索阶段零副作用。
- 取舍由你决策，不失控制权。
- 审查轻松：思路比代码易读。
⑥ 不这么做的问题 / 坏处
- 上来就让 build 动手 → 方向错时面对一堆 diff，纠偏昂贵。
- 不要求复述理解 → 模型按错误解读做完才发现。
- 口头「别改」却用可写 Agent → 它可能边想边改，不可控。
- 方案不看就批准 → 计划环节沦为形式，隐患被带进实现。
⑦ 举一反三：三个例子
例 1（基础）：改 bug 前先定位
📌 场景：用户反馈某个页面偶发报错。
✅ 顺序：先让 plan 探索：复现条件是什么？错误可能从哪几条路径产生？需要看哪些证据？确认假设后，再让 build 做最小修复。
🔍 讲解：bug 修复最忌「看到症状就猜原因、直接改」。先计划 = 先定位根因，避免头痛医头、改完别处又犯。
例 2（进阶）：多方案取舍请你决策
📌 场景：实现一个功能有「破坏性改动」与「兼容层」两条路。
✅ 做法：让 plan 把两个方案的影响面、工作量、长期后果并列写出，并给出推荐与理由，但把选择权留给你。
🔍 讲解：方案设计阶段最重要的产出之一，就是把「需要人拍板的取舍」显式呈上。模型可以给建议，价值判断（要不要破坏兼容）应由你做。
例 3（挑战）：方案与现状不符时的处理
📌 场景：plan 给出的方案基于对代码的错误假设（它以为某函数存在）。
✅ 做法：审查时指出「请先核实 X 是否如你所说」，让它重新探索、修订方案后再确认；必要时让它先读关键文件拿证据。
🔍 讲解：方案可能包含模型的臆测。成熟的做法是要求方案中的关键前提有代码证据支撑——先验证假设、再批准计划，别让空中楼阁进入实现阶段。
⑧ 练习题 ×2
练习 1（巩固型）
📝 题目：计划阶段应包含哪四部分内容？plan Agent 为什么适合这个阶段？
💡 思路提示：理解 / 影响面 / 步骤 / 风险；不编辑项目文件。
✅ 参考答案：
text
四部分：对需求的理解、影响面分析、实施步骤、风险与取舍。
plan Agent 以 primary 模式运行、不编辑普通项目文件，
探索零副作用，且 shell 仍受权限控制——正好匹配
「先想清楚再动手」的计划阶段。🔍 讲解：记住计划的四块内容和 plan 的只读特性，你就能把质量控制稳定地前置。
练习 2（迁移型）
📝 题目：迁移到建筑施工：为什么正规工程要「先出图纸、甲方签字、再施工」，而不是边设计边盖？图纸会审环节与 AI 的计划审查有何共性？
💡 思路提示：图纸改动便宜、拆墙昂贵。
✅ 参考答案（示例）：
text
- 图纸阶段纠错成本极低，建筑一旦动工，拆改代价巨大；
- 图纸会审让结构、水电、甲方在施工前达成一致，暴露冲突；
- 签字确认 = 对方案的正式批准，施工按图推进。
共性：AI 的「plan → 审查 → build」就是软件工程的
「图纸 → 会审 → 施工」——越靠前的环节纠错越便宜，
计划先行是用最小成本保方向正确。知识点 3：探索—构建—验证：一个回合的标准循环
① 定位
计划批准后进入实现阶段。实现不是「让 AI 写完拉倒」，而有一个最小循环：先摸清现状、再动手、最后用客观证据验证。 本知识点讲透这个每小时要重复多次的核心循环。
② 是什么（What）
一个标准回合分三步：
text
① 探索（Explore）：读相关代码，搞清现状与约定，不臆测
② 构建（Build）：做最小、聚焦的改动
③ 验证（Verify）：跑测试 / 构建 / 实际触发行为，用证据确认三步各自的纪律：
- 探索：AI 应先 grep / read 拿到事实，而不是凭文件名猜；改动要遵循该文件已有的风格与模式。
- 构建：改动范围最小化，只动与任务相关的部分；不顺手「清理」无关代码。
- 验证：优先跑已有测试；没有测试时用构建、类型检查或实际复现来验证。没有验证的「完成」不算完成。
这个循环与 Agent 选型对应：探索可派 explore 子代理，构建设想用 build；验证靠 shell 工具（第 7 章）。
③ 怎么做（How）
- 在任务 Prompt 中明确三步要求：「先读 X 相关代码，再做最小改动，最后跑 Y 测试」；
- 验证失败 → 让 AI 回到循环：读报错、再改、再验证，直到通过；
- 项目缺少测试时，要求它先补一个能复现问题的测试，再修复（测试驱动）；
- 每个循环控制在小范围内，通过后再开下一循环；
- 连续几轮验证不过 → 检查是否方向 / 模型能力问题，而不是无限重试。
④ 为什么这么做（Why）
- 探索先行防止「在错误的假设上施工」。 模型若凭记忆假定某函数的行为，改动可能与真实代码冲突；先读事实，每个决策才有依据。这延续了第 7 章「先内后外、证据优先」。
- 最小改动控制爆炸半径。 一次只改任务相关部分，出问题时容易定位；顺手重构无关代码会把一个小任务变成无法审查的大改动，且可能引入新 bug。
- 验证让「完成」成为客观事实而非主观宣称。 模型说「已修复」不可直接采信；测试通过、行为复现成功才是证据。没有验证环节，错误会流到下游、由用户替你发现。
- 短循环带来快速反馈。 探索—构建—验证几分钟转一圈，错误被立刻捕获；这与知识点 1 的小任务切分共同构成「小步快跑」。
- 失败驱动下一轮，而非靠人重述。 报错输出直接回到上下文，AI 能据此自我修正，多数问题两三圈内解决。
- 测试先行（无测试时补测试）把修复固化成回归保护，防止同一问题以后再犯。
⑤ 这样做的好处
- 改动建立在事实之上，少臆测。
- 爆炸半径小，审查与回滚都容易。
- 完成有客观证据，质量可信。
- 反馈快、自我修正高效。
- 测试资产持续积累。
⑥ 不这么做的问题 / 坏处
- 跳过探索直接改 → 与现有代码冲突、违反项目约定。
- 改动不设边界 → 小任务变成大重构，牵出新问题。
- 不验证就当完成 → 错误流到线上才暴露。
- 验证失败却从头硬聊 → 不利用报错证据，反复在原地打转。
⑦ 举一反三：三个例子
例 1（基础）：修一个有测试覆盖的 bug
📌 场景：某函数在边界输入下出错，已有测试文件。
✅ 循环：先读该函数与现有测试 → 补一个复现边界情况的失败测试 → 做最小修复 → 跑全部相关测试转绿。
🔍 讲解：测试先行让「修复是否有效」一目了然，且新测试永久守护该边界。这是最干净的修复循环。
例 2（进阶）：没有测试的遗留代码
📌 场景：报错来自一个没有任何测试的老模块。
✅ 做法：先让 AI 读懂该模块、为受影响函数补「锁定当前行为 / 复现 bug」的最小测试，再进入修复—验证循环；不要求一步补齐全套测试。
🔍 讲解：遗留代码无验证手段时，先建立一个最小的「安全网」再动手，否则你无法确认改动有没有改坏别的行为。
例 3（挑战）：连续失败时的升级判断
📌 场景：同一个验证已经失败三四轮，AI 每次改一点、换一个错法。
✅ 判断与动作：停下来区分——是它没拿到关键证据？（让它把报错与相关代码完整读一遍）；是方案本身错了？（退回 plan 重新设计）；还是任务超出当前模型能力？（切更强模型，第 6 章）。
🔍 讲解：失败循环本身是信号：连续在同一处打转说明瓶颈不在执行层。及时升级「证据 / 计划 / 模型」中的正确一层，而不是机械重试。
⑧ 练习题 ×2
练习 1（巩固型）
📝 题目：写出标准回合的三步及各自主纪律。为什么「模型说完成了」不能作为完成标准？
💡 思路提示：探索拿事实、构建最小化、验证靠证据。
✅ 参考答案：
text
① 探索：grep/read 拿事实，遵循现有风格，不臆测；
② 构建：最小、聚焦改动，不顺手重构无关代码；
③ 验证：跑测试 / 构建 / 复现行为。
完成标准：模型的「已修复」是主观宣称，测试通过、
行为验证成功才是客观证据——没有验证不算完成。🔍 讲解：三步中验证是最常被偷工的一环；守住它，质量才有底线。
练习 2（迁移型）
📝 题目：迁移到科学实验方法：「观察现象 → 提出假设 → 做实验验证」的循环，与「探索—构建—验证」有何共性？为什么实验失败的记录反而是进步的来源？
💡 思路提示：证据驱动、失败给信息。
✅ 参考答案（示例）：
text
- 观察 ≈ 探索（先掌握事实）；提出假设 ≈ 构建（给出改动 /
解释）；实验 ≈ 验证（用客观结果检验）；
- 三者都以证据而非权威 / 直觉为准，循环迭代；
- 失败的实验排除了错误假设、提供新信息，指引下一轮；
AI 验证失败的报错同理——它告诉模型哪条路不通。
共性：Agent 工作循环就是工程化的科学方法：小步假设、
即刻检验、让失败指导下一轮，而不是一次押注一个大答案。知识点 4：子代理编排：主 Agent 当调度，子 Agent 当工人
① 定位
当任务需要「同时查好几块不相关的代码」或「某类研究子任务反复出现」时，全塞进主会话会让上下文臃肿。子代理（subagent）机制解决这个问题——本知识点讲如何像调度团队一样编排它们。
② 是什么（What）
子代理是主 Agent 派出的独立子会话，关键事实（第 5、7 章已核实）：
- fresh context：子代理从干净上下文开始，只接收主 Agent 给的任务说明；它的搜索 / 思考过程不进入主会话，最终只把汇总结果带回；
- 可前台或后台运行：前台等待结果；
background: true异步执行、完成时通知； - 默认嵌套深度 1：子代理不能再无限派生（内置 general 也不能再启动子代理）；
- 内置子代理：
explore（快速定位代码）、general（研究型多步工作、工具广）；自定义 Agent 设mode: subagent或all即可被派出； - 权限各自独立：父 Agent 的权限决定它能启动哪些子代理，子代理用自己的
permissions规则。
一句话：主 Agent 是调度员，子 Agent 是带独立工位、干完只交报告的专业工人。
③ 怎么做（How）
- 任务中有「可并行、彼此不相关」的调查部分 → 让主 Agent 分别派子代理（如一个查认证链路、一个查计费模块）；
- 在 Prompt 中为每个子任务说清要回答的问题与交付格式（文件行号、结论、建议）；
- 独立的子任务可要求后台并行，主 Agent 同时推进别的工作；
- 收到子代理报告后，由主 Agent（和你）综合决策，再动手；
- 频繁复用的子任务固化成自定义 subagent（第 5 章），写好
subagent.description供主模型选择。
④ 为什么这么做（Why）
- 子代理保护主会话的上下文。 让主 Agent 自己翻 20 个文件，所有搜索细节都堆进上下文、挤占后续决策；子代理把过程留在子会话，主会话只收到精炼结论——信息在源头被压缩。
- fresh context 让子任务专注、不受前文污染。 长会话里早期的错误假设可能影响后续判断；子代理从零开始、只看本任务证据，结论更客观。
- 并行子任务缩短总耗时。 三块独立调查串行做要三倍时间，后台并行则接近一倍——可并行性是子代理相对「顺序追问」的核心优势。
- 嵌套深度限制防止失控的代理洪流。 无界派生可能引发指数级调用（成本与故障都不可控）；深度 1 让调度结构简单、可预测。
- 角色专业化提高质量。 explore 专精定位、general 专精研究；主 Agent 不必为每类子任务都背一身工具，分工协作更高效——与人类团队同理。
⑤ 这样做的好处
- 主上下文保持精炼，决策质量稳定。
- 并行省时。
- 子任务结论客观、聚焦。
- 调用结构可控、成本可预期。
- 专业角色复用，常见子任务一键派出。
⑥ 不这么做的问题 / 坏处
- 所有调查都主 Agent 亲为 → 上下文被搜索细节淹没，后期变笨。
- 该并行的串行做 → 等待时间成倍增加。
- 子任务指令含糊 → 子代理自由发挥，报告不回答你要的问题。
- 不理解嵌套限制 → 指望子代理再派一大群，实际被系统阻止。
⑦ 举一反三：三个例子
例 1（基础）：派 explore 摸清陌生功能
📌 场景：接手陌生仓库，要搞清权限校验在哪些地方发生。
✅ 指令：「派 explore 子代理：列出所有与权限 / token 校验相关的文件与函数，给出调用链和关键行号，只读不改。」
🔍 讲解：搜索过程留在子会话，主会话只拿到一张「权限地图」。之后主 Agent 基于这张地图做规划，上下文干净。
例 2（进阶）：并行调查两个假设
📌 场景：一个故障可能出在网关，也可能出在下游服务。
✅ 做法：后台同时派两个子代理分别核查两条路径，各自给出「证据 + 是否成立」；主 Agent 等两份报告回来再判断。
🔍 讲解：两个假设互不依赖，正是并行的理想场景。总耗时由较长的那个决定，比串行排查快一倍。
例 3（挑战）：把子任务结果转化为决策
📌 场景：三个子代理分别交来了代码库不同模块的调查报告。
✅ 做法：主 Agent 汇总成「现状 → 共性问题 → 建议的改动顺序」，你审查后再让它动手；若报告间有矛盾，点名让相关子代理（带着矛盾点）再核实。
🔍 讲解：编排的价值不止于分派，更在于综合。子代理给的是局部事实，跨模块的判断与决策仍由主 Agent 和你完成——分工而不放任。
⑧ 练习题 ×2
练习 1（巩固型）
📝 题目：子代理会话有哪三个关键特性（上下文、运行方式、嵌套）？主会话最终收到的是它的搜索过程还是汇总结果？
💡 思路提示：fresh context、前台 / 后台、深度 1。
✅ 参考答案：
text
特性：fresh context（干净上下文开始）、可前台或后台运行、
默认嵌套深度 1（不能无限派生）。
主会话只收到子代理的汇总结果，其搜索 / 思考细节
留在子会话中，不污染主上下文。🔍 讲解：这三点解释了子代理为何能既扩展调查能力、又不拖垮主会话。
练习 2（迁移型）
📝 题目：迁移到公司的项目管理：项目经理为什么把任务分派给不同专员、要求「只交结论与方案」，而不是让所有人的全部过程材料都堆给自己？并行立项的前提是什么？
💡 思路提示：管理带宽、独立性。
✅ 参考答案（示例）：
text
- 项目经理的注意力（≈ 主会话上下文）有限，收全部过程材料
会被淹没；只要结论与方案，信息密度高；
- 专员独立调研、各管一摊（≈ fresh context / 独立权限）；
- 可并行立项的前提：任务彼此独立、无强依赖、边界清晰。
共性：子代理编排就是 AI 版的团队管理——主 Agent 调度、
子代理专精、只回传结论，独立任务并行推进。知识点 5：快照安全网、复盘与交付纪律
① 定位
工作流的收尾环节：改动出问题时如何安全撤回、任务结束前如何自查、以及怎样把每次经验沉淀成下一次的改进。本知识点讲快照（undo/revert）机制与交付、复盘纪律，为整个方法论闭环。
② 是什么（What）
快照（Snapshots）让对话与文件改动一起回退，关键事实（官方文档已核实）：
| 项 | 说明 |
|---|---|
| 触发方式 | /undo（默认快捷键 <leader>u）暂存「回退上一条回复」；/redo（<leader>r）取消暂存；也可选更早的消息选 Revert 回退到该点 |
| 回退内容 | 恢复受影响文件，并把被撤回的 Prompt 放回输入框供你改写后重发；提交改写后的 Prompt 即确认回退 |
| 采集时机 | 每个模型步骤调用前拍快照 A、步骤结束（成功 / 失败）拍快照 B，记录期间变更的路径（best effort） |
| 覆盖范围 | 会话活动目录（Git worktree 内）：已跟踪文件、≤2 MiB 的未跟踪文件；不含 git-ignored、>2 MiB 文件、目录外改动、Git 元数据与进程等副作用 |
| 前提 | 必须在 Git 仓库内；重要内容仍应以 Git 提交 / 备份为准 |
交付前自查清单（建议固化进 AGENTS.md 或 review 命令）：
- 相关测试是否全绿？构建 / 类型检查是否通过？
- 是否有遗漏的需求点、未处理的边界？
- diff 是否只含本次任务应有的改动（无顺手重构、无调试残留）？
- 文档 / 注释是否需要同步？
复盘：任务交付后简短回顾——哪些 Prompt / 选型有效、哪里返工、什么规则值得写进 AGENTS.md。
③ 怎么做（How）
- 上一条回复方向不对 →
<leader>u暂存回退，文件还原后改写 Prompt 重发；犹豫可<leader>r取消； - 回退只作「修订近期工作」用；关键节点及时 Git commit，把可长期依赖的安全网交给版本控制；
- 交付前逐项过自查清单（可让 AI 自己先跑一遍并汇报）；
- 提交前做最终 code review（或派只读 reviewer 子代理）；
- 项目结束花几分钟复盘，把反复出现的教训固化成规则 / 命令 / Agent。
④ 为什么这么做（Why）
- 快照把「试错」变成低成本操作。 知道能一键撤回对话 + 文件，你才敢让 AI 大胆尝试；它提供的是「近期工作」的局部安全网，与 Git 的长期版本线互补，二者缺一不可。
- 快照有明确边界（活动目录、小文件、不含副作用），因此不能替代 Git。 已提交的历史、分支、数据库变更不在其覆盖内；误把快照当唯一保障，可能在边界外丢失工作。理解限制才能正确使用。
- 交付自查在错误到达用户前拦最后一道。 测试、边界、diff 卫生都是机械可查项；把清单固化下来，交付质量不依赖记忆和心情。
- 最终审查保护仓库的整体一致性。 AI 按子任务局部优化，可能产生跨任务的不一致；一次收口审查能发现这些拼接缝。
- 复盘让个人能力复利增长。 每次返工的根因若只解决一次，下次还会犯；把教训写进 AGENTS.md / 命令 / Agent，未来的每个会话自动受益——这是规则系统（第 4 章）存在的终极意义。
- 方法论的终点是沉淀，而非重复。 成熟使用者的配置会随项目越用越厚、越用越准，新手则每次从零开始。
⑤ 这样做的好处
- 试错安心、撤回便捷。
- 安全网分层清晰：快照管近期、Git 管长期。
- 交付质量稳定：自查清单兜底。
- 经验持续沉淀，能力复利增长。
- 形成完整闭环：拆解 → 计划 → 循环 → 编排 → 交付复盘。
⑥ 不这么做的问题 / 坏处
- 不了解 undo → 错了只能手工恢复文件、重述需求。
- 只靠快照不提交 Git → 在快照覆盖范围外（已提交历史、副作用）可能无法恢复。
- 交付前不自查 → 调试残留、漏测改动流入仓库。
- 从不复盘 → 同样的返工反复发生，经验无法积累。
⑦ 举一反三：三个例子
例 1（基础）：撤回一次跑偏的修改
📌 场景：AI 误解需求，上一轮改动方向完全不对。
✅ 操作：<leader>u 暂存回退 → 文件恢复、旧 Prompt 回到输入框 → 改写 Prompt（补上被忽略的约束）→ 重发即确认。
🔍 讲解：比手工 git checkout + 重新解释更连贯：对话与文件同时回到上一步，你在原 Prompt 基础上修订，信息损耗最小。
例 2（进阶）：长任务中的安全节奏
📌 场景：一个多步骤重构持续大半天。
✅ 节奏：每个子任务验证通过后立即 Git commit（长期安全网）；步骤内的尝试性改动靠 <leader>u 快速回退（近期安全网）；两层网络各司其职。
🔍 讲解：commit 点把大任务切成「一旦失败最多回到上一个绿点」的小区间；快照处理 commit 之间的分钟级试错。组合使用才稳。
例 3（挑战）：把一次复盘变成永久改进
📌 场景：项目中 AI 三次忘记更新对应的 CHANGELOG。
✅ 落地：复盘后把「涉及用户可见改动时必须同步 CHANGELOG」写进项目 AGENTS.md，并可在 review 命令的检查清单中加一条；从此自动执行。
🔍 讲解：复盘最有价值的产出是「一条可执行的新规则」。让教训进入规则系统，而不是停留在「下次注意」——下次会话的「注意」必须由上下文承载才可靠。
⑧ 练习题 ×2
练习 1（巩固型）
📝 题目：/undo 的默认快捷键是什么？回退时文件和 Prompt 分别怎样处理？快照覆盖范围不含哪三类东西，因此应配合什么使用？
💡 思路提示：leader+u；文件恢复、Prompt 回输入框；Git。
✅ 参考答案：
text
快捷键：<leader>u（取消暂存 <leader>r）。
回退：恢复受影响文件，被撤回的 Prompt 放回输入框供改写，
重发即确认回退。
不含：git-ignored 文件、>2 MiB 的未跟踪文件、活动目录外
改动，以及 Git 元数据 / 数据库 / 进程等副作用。
快照需在 Git 仓库内，应配合 Git 提交做长期保障。🔍 讲解：搞清快照能做什么、不能做什么，你就建立了「短期快照 + 长期 Git」的正确安全习惯。
练习 2（迁移型）
📝 题目：迁移到专业运动队的复盘：为什么强队赛后要看录像、把失误转成训练清单，而不是只靠球员「下次记住」？这与用 AI 后的复盘和规则沉淀有何共性？
💡 思路提示：外显记录、转成可重复训练 / 规则。
✅ 参考答案（示例）：
text
- 看录像：把失误从「感觉」变成可回看、可讨论的客观记录；
- 转成训练清单：让纠正动作在后续训练中被反复执行，
而非寄望记忆；
- 共性：用 AI 复盘也是把返工根因外显记录、再转成
AGENTS.md / 命令 / Agent 等「每个会话自动加载的训练项」；
「下次注意」不可靠，写进上下文的规则才会被执行。
本质：个人（及团队）的 AI 工作能力 = 一套持续复盘、
持续沉淀、自动复用的改进系统。🔍 讲解：复盘—沉淀是所有专业能力精进的通用结构。理解这层共性，你就掌握了本章、乃至全书的最终落点：把每一次使用，都变成下一次更好的起点。
本章小结
| 知识点 | 一句话核心 |
|---|---|
| 1. 任务拆解 | 切成边界清晰、可验证、上下文可承受的小块，先有蓝图再动手 |
| 2. 计划先行 | plan 只读探索、出方案；零改动阶段审查，质量左移 |
| 3. 探索—构建—验证 | 先拿事实、最小改动、用测试 / 证据确认完成 |
| 4. 子代理编排 | fresh context、只回传结论、独立任务并行；主 Agent 综合决策 |
| 5. 快照与复盘 | <leader>u 管近期回退、Git 管长期；交付自查、复盘沉淀成规则 |
全章主线：拆解 → 计划 → 循环 → 编排 → 交付复盘，构成一个可重复的完整工作流。把它与前 8 章的技巧结合，你就具备了用 AI 系统性交付项目的能力。
下一章是《常见问题与排障》：安装、网络、鉴权、模型、上下文、权限等各类高频问题的诊断思路与解法，让你在遇到异常时不慌张、有章法。