📑 本页目录（点开跳转）
05 · Claude Code 实操：指令到底该放哪
⏱ 30 分钟 ｜ ⭐⭐ 每天都在用的一章
🎯 一句话
新手把所有规矩都往 CLAUDE.md 里堆，结果它变成一个没人看的垃圾桶。
七种引导方式各有各的加载时机和强制力，选对了才有用。
🧲 先说最重要的一条心法：给它一个能自己跑的验证
问题：Claude 在「看起来完成」时就会停。没有可运行的检查，你就成了人肉验证环节——每个错误都要等你发现、你指出、它再改。
解法：给它一个能产生「通过 / 失败」信号的东西，循环就自己闭合了：
检查可以是：测试套件、构建退出码、linter、对比 fixture 的 diff 脚本、跟设计稿对比的浏览器截图。
验证的四个升级档位
| 档位 | 做法 | 适用 |
|---|---|---|
| 单次提示内 | 同一条消息里要求「实现后跑测试并迭代到通过」 | 任何任务，今天就能用 ⭐ |
| 跨会话 | 设为持续目标，每轮后由独立评估器复查 | 需要持续到达标的任务 |
| 确定性闸门 | Stop hook 跑检查脚本，不通过就阻止回合结束 | 无人值守运行 |
| 第二意见 | 验证子 Agent 用全新上下文试图推翻结果 | 高风险变更 |
🔑 还要求它出示证据：跑了什么命令、返回什么、测试输出、截图。 审阅证据比你自己重跑一遍快得多。
🎯 什么样的验证才算「好验证」
⭐ 好验证的四个特征：
① 能自动跑 —— 一条命令，不需要人操作
② 输出是二元的 —— 通过/失败，不是"看起来还行"
③ 快 —— 几秒到几十秒。要跑 10 分钟的验证，它不会主动跑
④ 错误信息可操作 —— "第 42 行期望 X 得到 Y"，不是"失败了"
对照一下三种常见验证的质量：
| 验证 | 自动 | 二元 | 快 | 信息可操作 | 结论 |
|---|---|---|---|---|---|
| 单元测试 | ✅ | ✅ | ✅ | ✅ | ⭐ 最好的验证 |
| linter / 类型检查 | ✅ | ✅ | ✅ | ✅ | ⭐ 几乎白赚 |
| 完整 E2E 测试 | ✅ | ✅ | ❌ 慢 | 🟡 | 只在最后跑 |
| "你自己看一眼对不对" | ❌ | ❌ | ❌ | ❌ | ❌ 这不是验证 |
💡 一个立刻能做的改进：如果你的项目没有测试，先加类型检查。
mypy/tsc --noEmit这类几秒就能跑完，且能挡掉一大批错误—— 它是"从零到有"性价比最高的一步。
⚠️ 一个反直觉的现实：验证的价值不在于它有多全面，而在于它有多快被跑。 一个覆盖 60% 但 3 秒跑完的测试套件，比覆盖 95% 但要 10 分钟的有用得多—— 因为前者会在每一轮迭代里被跑，后者只会在最后被跑一次。
🔄 基本工作流：探索 → 规划 → 编码 → 提交
直接让 Claude 开写，最常见的后果是——它高质量地解决了错误的问题。
① 探索 进 plan mode：只读文件、回答问题，不做任何修改
② 规划 让它产出详细实现计划（你可以直接改这份计划）
③ 编码 退出 plan mode，按计划实现 + 对照验证
④ 提交 描述性 commit + 开 PR
什么时候可以跳过规划：改错字、加日志、改名——一句话能描述清楚 diff 的任务，直接做。
规划最值钱的三个场景：方案不确定 / 改动跨多文件 / 你不熟这段代码。
🎤 大功能的杀手锏：让 Claude 面试你
你：一句话描述需求
然后要求：「就技术实现、UI/UX、边界情况、权衡逐项追问我，
问完产出 SPEC.md」
↓
它会问到一堆你没想过的点
↓
产出 SPEC.md
↓
⭐ 开一个全新会话执行这份规格
（干净的上下文全部用于实现，不被讨论过程占用）
第 3 节的「让模型面试你」在编码场景的完整用法。这是单条提示词和一个想清楚的项目之间的差别。
🗂️ 七种引导方式（本章核心）
先问三个问题，答案决定用哪种
① 这该【什么时候加载】？ 永远 / 按需 / 被调用时 / 事件触发
② 它该【如何持久】？ 缓存 / 每轮重注入 / 绕过压缩 / 只回摘要
③ 必须被【多严格遵守】？ 建议性 / 具体约束 / 确定性保证 ⭐
第 ③ 问最关键：需要「确定性保证」的东西，永远不要写进提示词——提示词是概率性的（第 13 节同款铁律）。
速查表
| 方式 | 上下文成本 | 加载时机 | 该放什么 |
|---|---|---|---|
| CLAUDE.md | 高（常驻） | 永远 | 项目概览、构建命令、目录结构、团队约定。控制在 200 行内 |
| Rules | 中 | 匹配路径时 | 横切约束，用 paths: 限定只在相关文件加载 |
| Skills | 低 | 判断相关时 | 程序性工作流——部署检查单、审查流程、发布步骤（第 10 节） |
| 子 Agent | 零（调用前） | 被调用时 | 隔离的支线任务——深度搜索、日志分析、依赖审计 |
| Hooks | 低 | 事件触发 | 必须每次都发生、零例外的确定性动作 ⭐ |
| Output Styles | 高 | 永远 | 罕见的重大角色转变。会覆盖默认指令，慎用 |
| append-system-prompt | 中 | 本次会话 | 一次性会话的领域知识 |
🚫 四个反模式（照着改能立刻见效）
| ❌ 常见错误 | ✅ 正确做法 |
|---|---|
| CLAUDE.md 写「每次改完代码都要跑 lint」 | 用 hook 确定性执行——写在提示里它会忘 |
| 把「绝不要 rm -rf」当提示词规则 | 用 PreToolUse hook 退出码 2 直接拦截 |
| CLAUDE.md 塞 30 行部署手册 | 做成 skill，只在真要部署时加载 |
| API 专用规则不限定路径 | 加 paths: src/api/**，别让它污染所有会话 |
🔑 一句话记忆：把 CLAUDE.md 当索引，不是垃圾桶。
📐 一张决策图（卡住时照着走）
你有一条想让 Claude 遵守的规矩
│
├─ 它必须【每次都发生、零例外】吗？
│ ✅ 是 → 🪝 Hook（确定性，代码级保证）⭐
│ ❌ 否 ↓
│
├─ 它是【一套多步骤的流程】吗（>10 行）？
│ ✅ 是 → 🎯 Skill（按需加载，不占常驻上下文）
│ ❌ 否 ↓
│
├─ 它只跟【某些文件/目录】相关吗？
│ ✅ 是 → 📏 Rule + `paths:` 限定
│ ❌ 否 ↓
│
├─ 它需要【大量翻阅但只要结论】吗？
│ ✅ 是 → 🤖 子 Agent（隔离上下文）
│ ❌ 否 ↓
│
└─ 剩下的、简短的、全局都要知道的
→ 📄 CLAUDE.md（严格控制在 200 行内）
💰 为什么「上下文成本」这一列这么重要
CLAUDE.md 里的每一行，都在【每一轮对话】里被重新读一遍
一个 500 行的 CLAUDE.md：
· 常驻占用几千 token
· 在 20 轮对话里被读了 20 遍
· ⚠️ 而且它稀释了真正重要的指令 —— 这才是最大的代价 ⭐
🔗 这就是第 4 章上下文工程说的「上下文是有限预算」的具体形态。 CLAUDE.md 膨胀不只是浪费钱，它会让 Claude 更容易忽略你真正在乎的那几条规矩。
💡 一个判断信号：如果你发现「明明写在 CLAUDE.md 里了它还是不听」， 十有八九不是它不听话，是那条规矩被淹没了。 先精简，再加强。
🩺 CLAUDE.md 体检法
逐行问：「删掉这一行，Claude 会犯错吗？」
- 不会 → 删
- 会，且是「每次都必须」→ 改成 hook
- 会，且超过 10 行流程 → 改成 skill
- 会，且只跟某目录相关 → 改成带 paths: 的 rule
目标：200 行以内，每行都过得了这个测试。
🧹 会话管理：上下文的日常维护
第 4 节讲了上下文腐烂的原理，这里是它的日常操作面。
| 动作 | 什么时候用 |
|---|---|
Esc |
它跑偏了，立刻打断 —— 越早越好 |
Esc Esc / /rewind |
回滚到之前的检查点 |
/clear |
任务之间、或上下文已脏 |
| 「用子 Agent 调查 X」 | 需要大量翻阅但只要结论时 |
⭐ 两次纠正规则
同一个问题纠正超过两次 → 停。
/clear重来。
因为此时上下文里已经堆满了失败的尝试，模型每一轮都在读那些错误示范。 带着吸收了教训的更好提示词重开一局，几乎总是优于在长会话里继续拉扯。
这是第 4 节「上下文腐烂」最实用的一条推论。
五个常见失败模式
| 失败模式 | 修复 |
|---|---|
| 大杂烩会话（一个会话干五件事） | 任务间 /clear |
| 反复纠正同一问题 | 两次失败后 /clear 重来 |
| 过度膨胀的 CLAUDE.md | 无情修剪，或转成 hook / skill |
| 信任但不验证 | 永远提供可运行的验证手段 |
| 无边界的调查（"看看代码库有什么问题"） | 限定范围，或交给子 Agent |
🔨 动手：三件事，今天就能做
- 建一个验证闭环：找出你每次改完代码都手动做的检查 → 变成一条命令 → 下次任务里明确要求「实现后运行它并修到通过」
- 审计 CLAUDE.md：按上面的体检法逐行过一遍，压到 200 行内
- 改一条 hook：找出一条「每次都要…」的规则，改成 hook
📚 延伸阅读
- Claude Code 智能体编码最佳实践
- 引导 Claude Code：何时用 CLAUDE.md / Skills / Hooks / 子 Agent
- 循环工程入门
- 用 Skills 构建验证循环
✅ 检查点
- 为什么「给它一个能自己跑的验证」是最重要的一条实践？
- 好验证的四个特征是什么？为什么"你自己看一眼"不算验证？
- 为什么说「验证的价值不在于全面，而在于多快被跑」？
- 项目还没有测试时，性价比最高的第一步是什么？
- 「每次编辑后都要跑 linter」该写进 CLAUDE.md 还是做成 hook？为什么？
- 决定用哪种引导方式的三个问题是什么？哪个最关键？
- CLAUDE.md 膨胀最大的代价是什么（不是钱）？
- 「明明写在 CLAUDE.md 里了它还是不听」，最可能的原因是什么？
- 什么时候可以跳过规划直接写？
- 连续纠正同一个问题三次，最该做什么？为什么？
👀 答案
- 没有可运行的检查，你就成了人肉验证环节，每个错误都要等你发现、你指出、它再改。有了它，Claude 能自己闭合「做→测→改」的循环。
- ①能自动跑（一条命令）②输出是二元的（通过/失败）③快（几秒到几十秒）④错误信息可操作。"你自己看一眼"四条全不满足——它不自动、不二元、不快、不给可操作信息。
- 因为快的验证会在每一轮迭代里被跑，慢的只会在最后被跑一次。覆盖 60% 但 3 秒跑完的，比覆盖 95% 但要 10 分钟的有用得多。
- 加类型检查（
mypy/tsc --noEmit）。几秒跑完，能挡掉一大批错误，是"从零到有"性价比最高的一步。 - hook。因为这是「必须每次都发生、零例外」的确定性要求，写进提示词只是概率性的建议，它会忘。
- ①什么时候加载 ②如何持久 ③必须被多严格遵守。第③个最关键——需要确定性保证的绝不能靠提示词。
- 它稀释了真正重要的指令。CLAUDE.md 的每一行都在每一轮被重读，500 行的文件会让 Claude 更容易忽略你真正在乎的那几条。
- 那条规矩被淹没了——不是它不听话。先精简 CLAUDE.md，再考虑加强措辞。
- 一句话能描述清楚 diff 的任务（改错字、加日志、改名）。
/clear重开，用吸收了教训的新提示词。因为上下文已被失败尝试污染，模型每一轮都在读那些错误示范，继续拉扯只会更糟。
🛑 可以停在这里
⚡ 走神救援
核心心法：给它能自己跑的验证（四档位：单次提示/跨会话/Stop hook闸门/验证子Agent），并要它出示证据。⭐好验证四特征：能自动跑、输出二元、快、错误信息可操作——"你自己看一眼"四条全不满足所以不算验证；⭐验证的价值不在全面而在多快被跑（3秒跑完覆盖60%的，比10分钟覆盖95%的有用，因为前者每轮都会跑）；没测试的项目先加类型检查，性价比最高。工作流：探索(plan mode)→规划→编码→提交；大功能先让它面试你产出SPEC.md，再开新会话实现（干净上下文全用于实现）。七种引导按「何时加载/如何持久/多严格」三问选（第三问最关键：要确定性保证的绝不写进提示词）：必须每次发生→hook；多步骤流程→skill；只跟某些目录相关→rule加paths；要大量翻阅但只要结论→子Agent；剩下的短的全局的→CLAUDE.md（限200行）。⭐CLAUDE.md 膨胀最大的代价不是钱，是稀释了真正重要的指令——"写了它还是不听"十有八九是那条被淹没了，先精简再加强。会话管理：⭐同一问题纠正超两次就 /clear 重来（上下文已被失败尝试污染，模型每轮都在读错误示范）。
下一节 👉 06-工作流还是Agent.md