TL;DR解释代码、修 Bug、补测试、更新文档——四个高频低风险工作流。跑通这四个等于验证了 CLAUDE.md、测试闭环和模块边界。跑不通就别做复杂任务。为什么要从这四个工作流开始团队引入 Claude Code 后最常见的错误直接甩一个大需求过去结果改了一堆不该改的文件、没跑测试、引入回归然后得出结论AI 不靠谱。问题不在 AI。问题在于你没有先验证基础设施。这四个工作流的共同特征高频、低风险、可快速验证。它们不是目的是诊断工具。每个工作流都会暴露一类配置缺陷|工作流|诊断什么|暴露的问题|| — | — | — ||解释代码|项目地图是否完整|CLAUDE.md 缺少架构描述||修 Bug|模块边界是否清晰|Claude Code 改了不该改的文件||补测试|测试命令是否正确|CLAUDE.md 的 Commands 段有误||写文档|文档规则是否明确|Claude Code 不知道文档放哪里|如果这四个工作流都跑不顺说明你的 CLAUDE.md、Hooks 和权限配置还不支持复杂任务。先把基础诊断能力校准好。工作流 1解释代码目的新人 onboarding、Code review 前准备、理解不熟悉的模块。解释代码不需要 Claude Code 修改任何文件是纯只读操作零风险。提示词模式解释 src/services/payment/ 目录的架构。 列出每个文件的职责、导出的函数、和调用它的模块。 标注哪些函数有测试覆盖哪些没有。关键约束只读不修改。如果 Claude Code 在解释过程中顺手改了代码说明你的权限或规则配置有问题。验证方式人工确认 Claude Code 的解释和实际代码一致。重点检查• 文件职责描述是否准确不是泛泛而谈• 函数列表是否完整没有遗漏导出函数• 调用关系是否正确确实是被那些模块调用• 测试覆盖标注是否和实际测试文件对应暴露的配置问题如果 Claude Code 解释不准确原因通常是验证清单解释代码验证清单 [ ] 文件职责描述与代码注释一致 [ ] 导出函数列表完整手动 spot check 3 个文件 [ ] 调用关系与 grep 结果匹配 [ ] 测试覆盖标注与实际 test 文件对应 [ ] Claude Code 没有修改任何文件纯只读如果五个都通过说明项目地图配置有效。如果第二个和第五个失败优先修 CLAUDE.md 的架构描述段。工作流 2修 Bug目的小范围行为修复。关键词是小范围——一个 bug 最多涉及 2 个文件。超过 2 个文件的修改已经不算简单 bug fix 了。完整提示词模式Bug: 用户注册后欢迎邮件没有发送。 1. 先定位相关代码注册逻辑在哪个文件邮件发送在哪个文件 2. 解释当前行为和预期行为的差异 3. 提出最小修改方案只改必要的代码 4. 修改后运行最小相关测试 5. 总结改了什么、为什么、测试结果、剩余风险这个提示词强制 Claude Code 走一条结构化路径定位 → 诊断 → 方案 → 执行 → 验证。不是让它自由发挥而是每一步都有可检查的产出。质量指标|指标|标准|不达标时的含义|| — | — | — ||修改文件数|≤ 2|超过说明模块边界不清或诊断有误||测试通过|最小相关测试全部通过|要么测试没跑要么改坏了||无关变更|0|Claude Code 在顺手优化需要加强规则||诊断准确|root cause 和实际一致|上下文不足需要补 CLAUDE.md|失败诊断树Bug 修失败了按这个顺序排查1. Bug 没修好 → 诊断错误Claude Code 定位到了错误的代码 → 上下文不足Claude Code 不知道关键的调用链 → 修复补 CLAUDE.md 的架构描述和模块依赖2. 改了太多文件 → 范围蔓延Claude Code 觉得顺便重构一下 → 边界规则缺失CLAUDE.md 没有明确哪些模块不能动 → 修复补 CLAUDE.md 的 Working Rules 和模块边界3. 测试没跑 → 没有验证习惯Claude Code 改完就结束了 → CLAUDE.md 没有要求修改后必须运行测试 → 修复加 PostToolUse Hook 或在 CLAUDE.md Commands 段强调测试4. 引入了回归 → 没有覆盖原始行为的测试 → 修改影响了其他调用方 → 修复先补回归测试再修 bug实战检查修完 bug 后对照这个 diff 检查清单Bug Fix 验证清单 [ ] 修改文件数 ≤ 2 [ ] 每个 hunk 都和 bug 直接相关无顺手改动 [ ] 最小相关测试已运行且通过 [ ] Claude Code 解释了 root cause [ ] Claude Code 列出了剩余风险 [ ] 没有引入新的 typecheck 或 lint 错误工作流 3补测试目的提高回归保护。补测试和修 Bug 互为镜像修 Bug 是测试告诉你行为错了补测试是先写好网以后改坏了能知道。提示词模式为 src/services/payment/processRefund.ts 补测试。 要求 1. 先读源文件列出所有导出函数和分支 2. 列出需要覆盖的场景正常、边界、异常 3. 写测试每个测试只验证一个行为 4. 确认测试先失败再通过验证测试本身有效 5. 报告覆盖率第五步报告覆盖率容易被忽略但它是判断测试质量的关键。如果 Claude Code 报告覆盖率从 40% 提升到 65%你至少知道测试确实在测代码。如果覆盖率没变说明测试可能测的是无关路径。质量标准什么样的测试是有效的// 无效测试测的是 mock 本身不是业务逻辑it(#x27;should work#x27;,(){mockDb.query.mockResolvedValue({rows:[]});constresultprocessRefund(#x27;order-123#x27;);expect(result).toBeDefined();// 永远通过});// 有效测试测的是具体行为it(#x27;拒绝已退款的订单二次退款#x27;,async(){mockDb.query.mockResolvedValue({rows:[{status:#x27;refunded#x27;}]});awaitexpect(processRefund(#x27;order-123#x27;)).rejects.toThrow(#x27;ORDER_ALREADY_REFUNDED#x27;);});有效测试的判断标准•测试名字描述具体行为不是 “should work” 或 “test case 1”•断言具体值不是toBeDefined()这种永远通过的断言•每个测试只验证一个行为一个 it 块里不要测三件事•先失败再通过确保测试真的能捕获 bug暴露的配置问题如果 Claude Code 补的测试跑不起来通常只有一个原因CLAUDE.md 里的测试命令是错的。常见错误 - CLAUDE.md 写的是 npm test项目实际用的是 pnpm test - CLAUDE.md 写的是 pnpm test但单测命令是 pnpm test:unit - 测试需要环境变量CLAUDE.md 没提 - 测试框架用的是 vitestCLAUDE.md 写的是 jest这类问题修一次就好——更新 CLAUDE.md 的 Commands 段。验证清单补测试验证清单 [ ] Claude Code 列出了所有导出函数和分支 [ ] 场景覆盖了正常路径、边界值和异常情况 [ ] 每个测试只验证一个行为 [ ] 测试先失败再通过不是天生就通过 [ ] 覆盖率有提升 [ ] 测试命令和 CLAUDE.md 一致工作流 4更新文档目的文档和代码同步。这是最容易被跳过的工作流但它的诊断价值不低——如果 Claude Code 不知道文档在哪、用什么格式、遵循什么规范说明 CLAUDE.md 缺少文档规则。提示词模式src/services/payment/processRefund.ts 刚修改了退款策略 - 超过 30 天的订单不再支持退款 - 新增部分退款逻辑 更新所有受影响的文档 1. 找到引用旧退款策略的文档 2. 用现有文档风格更新内容 3. 更新 API 示例中的请求和响应 4. 确认文档内的链接仍然有效验证方式文档验证比代码验证更难自动化需要人工检查•位置正确文档放在项目约定的位置不是随便找个地方新建•格式一致和现有文档的 markdown 风格、标题层级、代码块格式一致•内容准确示例命令能跑、API 参数和实际代码一致•链接有效文档内引用的其他文档路径仍然可访问暴露的配置问题常见问题 - 文档放在 /docs 而不是 /wiki - 用的是中文文档Claude Code 写了英文 - API 文档用 OpenAPI 格式Claude Code 写了纯 markdown - CHANGELOG 更新规范没写进 CLAUDE.md工作流质量诊断矩阵四个工作流跑完后用这个矩阵判断项目配置的健康度|工作流|暴露的配置问题|失败指标|修复方法|| — | — | — | — ||解释代码|项目地图缺失|结构描述不准确、调用关系错误|补 CLAUDE.md 架构描述||修 Bug|模块边界不清|改了不该改的文件、无关变更 0|补 CLAUDE.md Working Rules 和边界说明||补测试|测试命令错误|测试跑不起来、命令不匹配|修正 CLAUDE.md Commands 段||写文档|文档规则缺失|写错位置、格式不统一|补 CLAUDE.md 文档规则段|诊断方法每个工作流跑两轮。第一轮暴露问题修复配置后跑第二轮验证。如果第二轮全部通过基础配置合格。真实失败案例背景一个 6 人团队在支付系统仓库里引入 Claude Code。仓库没有 CLAUDE.md没有 Hooks权限完全开放。第一天后端工程师让 Claude Code 修一个简单的 bug用户登录后偶尔出现 session 过期的提示。事件经过Claude Code 的操作5 个文件被修改原始 bug 只涉及 1 个文件。Claude Code “顺手做了一些优化”。后果- logout 流程被破坏用户无法正常退出 - session store 的刷新逻辑和 Redis 配置不兼容生产环境 session 全部失效 - 没有运行任何测试 - 部署后 15 分钟内收到 200 用户反馈根因分析三个配置缺失导致的连锁失败 1. 没有 CLAUDE.md → Claude Code 不知道 session-store.ts 是共享基础设施不能随便改 → Claude Code 不知道 logout-handler.ts 的错误处理是刻意设计的 2. 没有 PostToolUse Hook → 修改文件后没有自动提醒运行测试 → Claude Code 改完就认为任务完成了 3. 没有模块边界规则 → Claude Code 的顺手优化没有被任何规则约束 → 没有告知哪些文件属于共享层、不能在 bug fix 中修改成本时间成本 - 4 小时紧急排查和修复 - 1 小时回滚部署 - 2 小时事后复盘和补写 CLAUDE.md 信任成本 - 团队对 Claude Code 的信心从期待降到怀疑 - 两周没人愿意再用 Claude Code修复措施事后团队做了三件事1. 创建 CLAUDE.md包含 - 模块边界说明共享层 vs 业务层 - 修改规则bug fix 最多改 2 个文件 - 测试命令和验证要求 2. 添加 PostToolUse Hook - 修改 src/ 下文件后自动运行最小相关测试 - 测试失败时提醒 Claude Code 回退修改 3. 配置 .claude/rules/ 路径规则 - 共享模块session-store, cache需要确认才能修改 - 修改 API 网关需要安全审查如果团队先跑通四个基础工作流这个失败不会发生。修 Bug 工作流会立刻暴露改了太多文件的问题。补测试工作流会暴露测试没跑的问题。解释代码工作流会暴露没有项目地图的问题。何时超越基础工作流四个基础工作流能覆盖日常 60-70% 的任务。但有些任务超出了它们的范围。复杂度判断矩阵|信号|说明|基础工作流还能用吗|下一步|| — | — | — | — ||可能改动 3 个文件|超出简单 bug 范围|不适合|用 plan 模式先拆分任务||需要先研究影响范围|不确定改了会怎样|解释代码可以修 Bug 不行|用 Explorer subagent 调研||跨模块影响|改动涉及多个服务|不适合|用 parallel exploration 并行调研||安全敏感|涉及认证、权限、数据|不适合直接改|用 security-reviewer subagent 审查||需要设计决策|多种实现方案|不适合|先讨论方案再拆成小任务|判断标准很简单如果你自己也不确定怎么改就不要让 Claude Code 直接改。先让它调研、解释、列方案你确认方案后再执行。从基础到复杂的过渡路径Level 1: 四个基础工作流本篇 解释代码 → 修 Bug → 补测试 → 写文档 Level 2: 有结构的复杂任务 先 plan → 拆成多个 Level 1 任务 → 逐个执行验证 Level 3: 需要专项角色 调研用 Explorer、安全用 Reviewer、测试用 QA subagent Level 4: 多角色协作 多个 subagent 并行 主会话整合结果不要跳级。Level 1 没跑通就去 Level 3只会得到更混乱的结果。进阶提示词工程模式四个基础工作流的提示词模板可以进一步系统化。以下是每种工作流在不同复杂度下的提示词变体以及为什么这些变体能引导 Claude Code 产生更好的输出。解释代码的分层提示词Level 1 — 快速概览适合陌生模块首次接触 列出 src/services/auth/ 下的所有文件。 每个文件用一句话描述职责。 Level 2 — 结构分析适合理解模块间关系 解释 src/services/auth/ 的架构。 列出每个文件的职责、导出的函数、和调用它的模块。 用箭头标注文件之间的调用方向A → B 表示 A 调用 B。 Level 3 — 深度审计适合 code review 前准备 对 src/services/auth/ 做完整的代码审计准备 1. 列出每个导出函数的签名、参数类型和返回类型 2. 标注每个函数的测试覆盖状态有测试/无测试/部分覆盖 3. 标注错误处理路径哪些异常被 catch哪些没有 4. 标注外部依赖调用了哪些其他模块、第三方库、API 5. 列出你注意到的潜在问题不修改代码只列出观察分层的原因Level 1 消耗约 2000 token 的输出Level 3 消耗约 8000 token。如果你只需要知道一个模块大概做什么Level 3 的输出反而增加了审查负担。反过来如果要做代码审查前的准备Level 1 的信息不够用。修 Bug 的结构化提示词变体基础版适合简单 bug。以下变体处理更复杂的场景变体 A — 不确定 bug 所在位置 Bug 报告[现象描述] 1. 先用 Grep 搜索相关关键词定位可能出错的代码区域 2. 列出你找到的所有可疑位置标注可能性高/中/低 3. 解释每个位置为什么可疑 4. 等我确认后再提出修改方案 约束只做诊断不做任何修改。 变体 B — Bug 涉及多个模块 Bug 报告[现象描述] 1. 定位 bug 涉及的所有文件 2. 画出调用链从入口到出错位置经过哪些文件和函数 3. 在调用链上标注每一步的数据流输入什么、输出什么、在哪一步出错 4. 提出最小修改方案解释为什么改动这些文件就足够 5. 列出调用链上其他可能受影响的调用方 6. 修改后运行所有相关测试不只是出错的那个文件的测试 约束修改前先画调用链确认我同意后再改代码。 变体 C — 间歇性 bug难以稳定复现 Bug 报告[间歇性现象描述复现条件不明确] 1. 搜索代码中所有和该现象相关的代码路径 2. 识别可能导致间歇性行为的代码模式 - 竞态条件并发访问共享状态 - 时序依赖setTimeout、事件顺序 - 外部状态缓存、数据库、第三方 API - 条件分支中未处理的边界情况 3. 对每个可疑模式解释为什么它可能导致间歇性行为 4. 建议添加哪些日志或断言来帮助缩小范围 5. 不要修改代码只输出诊断报告变体 A 增加了一个交互检查点“等我确认后”避免 Claude Code 在错误的位置做修改。变体 B 强制画出调用链这在多文件 bug 中能暴露真正的 root cause。变体 C 的重点是诊断而非修复——间歇性 bug 在没有充分信息时贸然修改往往引入新问题。补测试的提示词工程进阶版 — 带覆盖率分析的测试补充 为 src/services/payment/processRefund.ts 补测试。 执行步骤 1. 读源文件列出所有导出函数 2. 对每个函数列出所有分支if/else, switch, try/catch, ?. , ?? 3. 标注已有测试覆盖的分支读取现有测试文件对比 4. 只为未覆盖的分支写测试 5. 每个测试用 describe/it 结构组织it 描述具体行为 6. 运行测试前报告新增了几个测试、覆盖了哪些分支 7. 运行测试报告通过率和覆盖率变化 输出格式要求 - 测试文件路径[和源文件对应的测试路径] - 新增测试数量[N] - 覆盖分支列表[列出] - 运行命令[精确命令] - 覆盖率变化[从 X% 到 Y%]这个变体的关键是步骤 3——“标注已有测试覆盖的分支”。没有这一步Claude Code 可能重复写已有的测试场景浪费 token 且不增加覆盖率。写文档的提示词工程进阶版 — 变更影响分析驱动的文档更新 刚完成了以下变更 [列出变更内容] 请更新所有受影响的文档 1. 搜索阶段 - Grep 搜索所有 .md 文件中引用变更内容的文档 - 列出搜索结果标注哪些文档确实需要更新 2. 更新阶段 - 按现有文档风格更新内容保持标题层级、代码块格式一致 - 如果涉及 API 变更更新请求/响应示例 - 如果涉及配置变更更新环境变量表 3. 验证阶段 - 确认文档内链接仍然有效Grep 检查引用路径是否存在 - 确认示例命令能运行如果是 shell 命令验证命令格式正确 - 列出你更新了哪些文件的哪些段落 4. 遗漏检查 - 列出可能还需要的文档更新但你不确定的标注需要确认步骤 4 “遗漏检查” 是这个变体的关键创新。Claude Code 可能无法确定某些文档是否需要更新比如 CHANGELOG、内部的架构决策记录让它列出不确定项比让它自己做决定更安全。工作流失败诊断树完整版前文给出了修 Bug 的失败诊断树。以下是所有四个工作流的完整诊断流程┌─ 解释代码失败 │ ├─ 结构描述不准确 → CLAUDE.md 缺少 Structure 段 │ │ → 补充每个顶层目录加一句话描述 │ ├─ 调用关系错误 → CLAUDE.md 缺少依赖方向声明 │ │ → 补充Boundaries 段加谁可以调用谁│ ├─ 遗漏目录 → CLAUDE.md 的 Structure 段过期 │ │ → 触发条件新增了目录但没更新 CLAUDE.md │ └─ 对生成文件做了描述 → CLAUDE.md 缺少 Off-limits 段 │ → 补充列出所有不应手动修改的路径 │ ├─ 修 Bug 失败 │ ├─ 改了太多文件 │ │ ├─ Claude Code顺手优化→ CLAUDE.md 加No unrelated changes规则 │ │ ├─ 诊断定位错误 → 项目地图不够精确Claude Code 找错了位置 │ │ └─ 模块边界不清 → Boundaries 段需要更明确的约束 │ ├─ 测试没跑 │ │ ├─ CLAUDE.md 没有要求 → Commands 段补充测试命令 │ │ ├─ Hook 缺失 → 添加 PostToolUse Hook 自动运行测试 │ │ └─ 测试命令错误 → 修正 Commands 段中的命令写法 │ ├─ Bug 没修好 │ │ ├─ Root cause 判断错误 → CLAUDE.md 补充调用链和依赖关系 │ │ ├─ 只修了表面症状 → 提示词增加解释 root cause步骤 │ │ └─ 遗漏了相关分支 → 提示词增加列出所有影响范围│ └─ 引入回归 │ ├─ 没有覆盖原始行为的测试 → 先补回归测试再修 bug │ ├─ 修改影响了其他调用方 → Boundaries 段补充调用方信息 │ └─ 没有跑全量相关测试 → Commands 段补充影响范围测试命令 │ ├─ 补测试失败 │ ├─ 测试跑不起来 │ │ ├─ 命令不存在 → CLAUDE.md Commands 段的测试命令是错的 │ │ │ → 修正验证命令在终端能跑通再写进 CLAUDE.md │ │ ├─ 环境变量缺失 → CLAUDE.md 补充测试前置条件 │ │ └─ 测试框架不匹配 → 修正 Commands 段中的框架名称 │ ├─ 测试天生就通过无效测试 │ │ ├─ 提示词没有要求先失败再通过→ 加上确认测试先失败再通过步骤 │ │ ├─ 断言太弱 → 提示词增加断言具体值不用 toBeDefined()要求 │ │ └─ Mock 拦截了真实逻辑 → 提示词增加测试真实行为不测 mock│ └─ 覆盖率没提升 │ ├─ 测试测的是无关路径 → 提示词增加列出源文件所有分支步骤 │ └─ 重复已有测试 → 提示词增加标注已有测试覆盖的分支步骤 │ └─ 写文档失败 ├─ 位置错误 → CLAUDE.md 补充文档目录结构说明 │ → 说明/docs 放用户文档/wiki 放内部文档根目录放 README ├─ 格式不一致 → CLAUDE.md 补充文档格式规范 │ → 或创建 .claude/rules/docs.md 做路径级加载 ├─ 内容不准确 → 提示词增加验证示例命令能运行步骤 └─ 遗漏相关文档 → 提示词增加搜索所有引用旧内容的文档步骤更多真实工作流案例案例二API 版本迁移工作流场景后端服务需要把/api/v1/orders迁移到/api/v2/ordersv2 改变了部分响应字段的结构。这是一个跨文件、需要协调前后端的任务但可以拆成多个基础工作流来执行。Phase 1 — 解释代码只读摸清影响范围 列出所有引用 /api/v1/orders 的文件。 区分前端调用方、后端 handler、测试文件、文档。 标注每个引用的上下文是请求 URL、测试 fixture、还是文档示例。 Phase 2 — 补测试先加保护网 为 v1 的现有 handler 补充测试如果覆盖率不足。 要求测试必须验证当前 v1 的响应格式。 目的确保迁移后 v1 的行为不变向后兼容期。 Phase 3 — 修 Bug这里是迁移而非修 bug但用同样的约束 实现 v2 handler每个变更控制在 2 个文件以内。 v2 handler 写在独立文件中不修改 v1 handler。 路由注册在 routes/index.ts 中添加这个文件会改但只加路由不改现有路由。 Phase 4 — 写文档更新 API 文档 更新 API 文档中的 v2 端点说明。 添加迁移指南v1 到 v2 的字段映射。 标注 v1 的废弃时间表。这个案例的关键是按顺序执行四个基础工作流而不是一次性让 Claude Code “把 v1 迁移到 v2”。顺序执行的好处是每个 phase 都有独立的验证点Phase 1 的输出是影响范围清单Phase 2 的输出是测试通过报告Phase 3 的输出是 diff 和测试结果Phase 4 的输出是文档更新清单。任何一个 phase 不通过不会影响前面的成果。案例三依赖升级工作流场景将项目从 React 17 升级到 React 18。这种任务看起来复杂但拆成基础工作流后每一步都是可控的。Phase 1 — 解释代码评估影响 列出 package.json 中所有 React 相关依赖的当前版本。 Grep 搜索代码中使用 React 17 特有 API 的位置 - ReactDOM.renderReact 18 用 createRoot - componentWillMount 等 deprecated 生命周期 - 依赖 react-scripts 的配置 列出第三方依赖中可能不兼容 React 18 的包。 Phase 2 — 补测试升级前的安全网 确认所有现有测试在 React 17 下通过。 如果有组件没有测试为核心渲染组件补充快照测试。 快照测试的目的是捕获升级后的渲染输出变化。 Phase 3 — 修 Bug分步升级 步骤 1更新 package.json 中的 react 和 react-dom 版本 步骤 2运行 pnpm install检查是否有 peer dependency 冲突 步骤 3修改 ReactDOM.render → createRootGrep 逐个修改 步骤 4运行测试确认通过。失败则逐个修复。 约束每个步骤只做一件事做完跑测试再进入下一步。 Phase 4 — 写文档 更新项目 README 中的 React 版本说明。 更新 CLAUDE.md 的 frontmatter如果有 framework 版本声明。 记录升级过程中遇到的 breaking changes 和解决方案。这个案例的特殊之处在于 Phase 3 被进一步拆分成了多个子步骤。依赖升级的每一小步都可能引入不同的问题一次改完几乎必然导致不可调试的失败。渐进复杂度决策矩阵当你拿到一个任务时用这个矩阵判断应该用哪个级别的提示词任务特征 │ 提示词级别 │ 预期交互轮次 ─────────────────────────────────┼─────────────┼───────────── 单文件行为明确 │ 基础版 │ 1 轮 单文件需要先定位 │ 变体 A │ 2 轮诊断 执行 多文件调用链清晰 │ 变体 B │ 2-3 轮 多文件影响范围不确定 │ 先解释代码 │ 3-4 轮 │ 再修 Bug │ 间歇性/难以复现 │ 变体 C │ 2 轮纯诊断 跨服务/API 变更 │ 拆成多阶段 │ 4-6 轮 依赖升级 │ 拆成多阶段 │ 4-6 轮判断的核心逻辑任务的不确定度越高提示词中诊断部分的权重应该越大执行部分应该越靠后。如果你在任务描述中用了可能、“大概”、不确定这类词说明你应该先用解释代码工作流做诊断而不是直接让 Claude Code 动手修改。工作流质量验证检查清单综合版四个工作流全部跑完后不仅要验证每个工作流的结果还要验证它们之间的协同是否正常单工作流验证 [ ] 解释代码输出准确无修改文件 [ ] 修 Bug修改 ≤ 2 文件无无关变更测试通过 [ ] 补测试测试先失败再通过覆盖率提升 [ ] 写文档位置正确格式一致链接有效 跨工作流验证 [ ] 解释代码识别的问题在修 Bug 中被正确处理 [ ] 修 Bug 后的代码在补测试中获得了覆盖 [ ] 补测试新增的测试在写文档中被引用如有必要 [ ] 四个工作流使用的命令全部来自 CLAUDE.md Commands 段 基础设施验证 [ ] PostToolUse Hook 正确触发修改文件后自动跑测试 [ ] .claude/rules/ 中的路径规则被遵守 [ ] CLAUDE.md 的项目地图在四个工作流中都没有暴露过期信息 [ ] Claude Code 的每个输出都包含 diff、验证结果和剩余风险跨工作流验证这个维度容易被忽略。如果解释代码工作流正确识别了模块 A 和模块 B 之间的调用关系但修 Bug 时 Claude Code 仍然在模块 A 里写了属于模块 B 的逻辑说明项目地图的 Boundaries 段写对了但 Claude Code 没有遵守——这可能需要在 .claude/rules/ 中加一条路径级的强制规则。落地清单四个工作流全部跑通后才算基础配置合格基础工作流验证清单 [ ] 解释代码Claude Code 能准确描述模块结构和调用关系 [ ] 修 Bug每次 bug fix 修改 ≤ 2 个文件无无关变更 [ ] 补测试测试能跑、先失败再通过、覆盖率有提升 [ ] 写文档文档位置、格式、内容都正确 [ ] 修改后自动运行最小相关测试PostToolUse Hook 或 CLAUDE.md 规则 [ ] Claude Code 每次都报告 diff、验证结果和剩余风险全通过项目配置有效可以开始更复杂的任务。有失败先修配置再重来。权衡这四个工作流看起来不炫但它们解决的是最实际的问题你的项目配置到底有没有效。跑通这四个后面用 subagent、parallel exploration、Hooks 才有基础。跑不通复杂工作流只会放大混乱。交叉参考• 02 - 安装、登录、权限和第一个任务[1]第一次进入仓库时验证环境• 04 - CLAUDE.md 项目记忆[2]工作流暴露的所有问题最终都修到这里• 12 - Subagents 基础概念[3]基础工作流跑通后再接触专项角色• 24 - PostToolUse 自动验证[4]修改后自动跑测试的 Hook 配置引用链接[1]02 - 安装、登录、权限和第一个任务:02-setup-permission-first-repo-task.md[2]04 - CLAUDE.md 项目记忆:04-claude-md-project-memory.md[3]12 - Subagents 基础概念:12-subagents-mental-model.md[4]24 - PostToolUse 自动验证:24-posttooluse-stop-verification.md