📑 本页目录（点开跳转）
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 面试你
操作步骤
第 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重开，用吸收了教训的新提示词。因为上下文已被失败尝试污染，模型每一轮都在读那些错误示范，继续拉扯只会更糟。
🛑 可以停在这里
⚡ 走神救援
先记住这几件事
- 先定义能运行、能判断结果的验证，再要求实现提供证据。
- 按加载范围与执行时机选择指令、规则、技能或 hook，不把所有要求塞进同一文件。
- 探索、规划、实施与验收各有产物；交付前同时检查自动化结果与实际使用效果。
下一节 👉 06-工作流还是Agent.md