综合练习

这一课你将能做到

1. 独立完成「修 bug → TDD → 重构 → review → 提交」的完整 agent 工作流
2. 为自己的项目一次性配齐四件套：CLAUDE.md、权限规则、格式化 Hook、审查子代理
3. 用 headless 命令做收尾自动化（变更摘要、changelog 生成），形成可复用的个人工作流

为什么要学

前 11 课的知识是散装的零件，这一课把它们装成一台整机。选择真实场景的原因：日常开发中「修一个线上 bug」这条链路恰好覆盖全部核心机制——需要记忆文件提供项目常识、Plan 模式锁定方案、TDD 提供验证、Hook 保证格式、子代理做审查、headless 产出交付物。走通一遍，你就有了自己的 SOP，之后每个项目都能按此模板快速就位。

人话：这是毕业设计。零件（命令、权限、Hook、Skill）你都认识了，现在要交出一台能跑的车，并附上保养手册（你的工作流清单）。

先建立图像

准备(一次性)              主链路(每次任务)              收尾
────────────            ──────────────────────      ─────────────
CLAUDE.md    ┐          ①描述现象+日志               ③生成 commit
权限规则     ├→ 基建    ②Plan 模式出方案             ④headless 摘要
格式化 Hook  │          ③确认方案→TDD 实现           ⑤PR + 子代理 review
审查子代理   ┘          ④全量测试通过                ⑥归档经验→CLAUDE.md

练习项目要求：任意你负责的真实仓库（有 git、有测试、能跑构建），准备一个「已知但未修」的 bug 作为靶子；没有现成 bug 就故意埋一个（如把分页参数 off-by-one 注入某个查询）。

跟着做

步骤 1：基建四件套（一次性投入）

cd 你的项目 && git status   # 确认工作区干净

会话内：

/init

随后人工修订 CLAUDE.md（构建/测试命令、目录约定、禁忌）；创建 .claude/settings.json 写入 allow（测试/构建命令）与 deny（.env、force push）；按 Hooks 课给 PostToolUse(Edit|Write) 挂格式化；按 Skills 课建 .claude/agents/code-reviewer.md（只读工具）。提交这批配置进 git。

步骤 2：描述现场，触发调查

用户反馈：分页到第 11 页时和第 1 页数据重复。
复现步骤与接口日志如下：…（贴日志）
先调查原因，不要改代码。

观察它用 Grep/Read 追调用链。你提供的线索越结构化（现象+复现+日志），它绕的弯越少。

步骤 3：Plan 模式锁定方案

Shift+Tab 进入 Plan 模式：

给出修复方案：改动文件清单、每步内容、如何用测试证明修复有效。

审查计划，修正偏差（比如「不要改公共分页工具类，只在本模块修」），确认后切回默认模式。

步骤 4：TDD 实现

先写一个复现该 bug 的单元测试，运行并贴出失败输出；
我确认失败原因正确后，再实现修复并让测试转绿，
最后跑全量测试确保无回归。

关键验收点：你必须亲眼看到「失败→转绿」两次测试输出。

步骤 5：提交 + headless 摘要

看 git diff，按 conventional commits 生成 commit 并提交（只含相关文件）

然后终端里：

claude -p "对比 HEAD~1..HEAD 的改动，输出 100 字内的中文变更说明" --model haiku

这段输出可直接贴进 PR 描述——廉价模型干廉价活。

步骤 6：子代理 review + 经验归档

用 code-reviewer 审查刚才的 commit，只输出问题报告

有真问题就修，没有就合并。最后一步最容易被忽略：

把这次 bug 的根因和「分页参数必须做上界校验」这条教训写进 CLAUDE.md

步骤 7：可选进阶——把链路搬进 CI

参照扩展课，在 GitHub Actions 配 @claude 触发，把步骤 2-4 的模式复用到线上协作（先在个人玩具仓库演练）。

讲清楚要点

1. 基建是杠杆：CLAUDE.md/权限/Hook/子代理四件套一次配置，之后每个任务都受益。判断投入产出：每周任务数 × 每次省的分钟数，通常第一天就回本。
2. 每个阶段有且只有一个验收物：调查→根因结论；计划→方案清单；实现→两次测试输出；提交→干净的 diff；审查→问题报告。没有验收物的阶段等于没做。
3. 模型分档贯穿全程：调查与实施用默认档，摘要/归档类用 haiku，方案存疑时升档深思考——同一链路里的成本意识。
4. 失败是流程的一部分：测试失败、review 报错、权限拒绝都是反馈信号，按「打断→复盘→补充约束→重试」处理，而不是换任务逃避。
5. 经验回流才形成复利：每次任务结束往 CLAUDE.md 回写一条教训，三个月后你的项目记忆就是最贵的资产。

你可能会懵的地方

• 没有现成项目怎么练？ 用脚手架起一个最小 Spring Boot / Node 项目，先让 Claude 生成一些带坑的代码（故意写 N+1 查询、漏判空），再走完整修复链路。练习价值不在项目真不真，而在链路全不全。

• 每个 bug 都要走这么重的流程吗？ 不。一行改动的小修可以砍掉 Plan 与 review；流程的「重」要匹配改动的「险」。原则：影响面越大，前置环节越多。

• 中途上下文乱了怎么救？ /clear 重开，用一句话交接：「当前任务 X，已完成 A/B，剩余 C，方案见 PLAN.md」。把状态落到文件，会话就随时可弃。

• 怎么判断该打断还是让它继续？ 两条红线：连续两轮在同一个错误上打转；开始修改与任务无关的文件。命中任一立即 Esc。其余小失败让它自己消化。

• 这套流程对团队怎么推广？ 把四件套模板（CLAUDE.md 骨架、settings.json、Hook 脚本、reviewer 代理）放进仓库模板 repo，新项目开箱即得；用一次内部分享讲清「验收物清单」即可，不必强推工具本身。

错法对照

错法	问题	正解
跳过基建直接开干	每个任务都在重复交代常识	先四件套，后任务
测试没看到失败就进实现	修复正确性无证据	TDD 两段式验收
review 走过场（自己审自己）	盲区原样通过	只读子代理独立视角
让它「顺手把其他问题也修了」	diff 膨胀，回滚困难	记下问题开新任务处理
结束不归档经验	同样的坑反复踩	每任务一条教训进 CLAUDE.md

卡点急救

1. 步骤 4 测试始终不转绿：确认测试真的在调被修代码（打断点/加日志验证）；若实现思路有误，回 Plan 模式重议方案，别硬调。
2. diff 超出预期范围：git restore 无关文件；把「只改 X」写进任务描述并在 CLAUDE.md 禁忌中固化。
3. 整体流程跑不完一屏：任务太大，拆成「调查」「修复」「测试」三次会话，中间用文件交接状态。

面试常问

• 你如何把 AI agent 融入日常开发工作流？ 分三层答：个人层（CLAUDE.md + Plan 模式 + TDD 节奏）、团队层（共享配置进 git、审查子代理、统一规范）、组织层（CI 集成、权限治理、成本监控）。强调每个环节都有人类验收点。

• 怎么衡量 coding agent 带来的收益？ 定性：任务吞吐、返工率、上下文切换减少。定量：任务耗时对比（同任务有/无 agent）、agent 产出的 PR 一次通过率、成本口径（订阅/API 费用 vs 节省工时）。避免只报「写了多少行」这种虚荣指标。

• 用 agent 踩过最大的坑是什么？ 标准答案结构：现象（如放权过度导致误改公共模块）→ 根因（缺硬约束与验收物）→ 改进（deny 规则 + 每阶段验收物 + diff 审查习惯）。展示「机制化改进」思维比展示零失误更有说服力。

自测三问

1. 本课的「基建四件套」是什么？分别对应哪几课的知识？
2. TDD 环节必须亲眼确认的两个测试输出是什么？
3. 任务中途会话状态混乱时的标准救援动作是什么？

小结一句话

把散装技能串成固定链路——基建先行、阶段验收、成本分档、经验回流——你就从「会用 Claude Code」升级为「拥有自己的 agent 工作流」。

延伸

• 最佳实践官方博客/文档
• 系列完：回到 Claude Code 路线图 标记掌握节点，并将四件套模板落地到你当前负责的仓库。