Steering Claude Code: When to Use CLAUDE.md, Skills, Hooks, and Subagents（引导 Claude Code：何时用 CLAUDE.md / skills / hooks / 子 Agent）
📄 来自 Claude 官方博客
- 原文标题
- Steering Claude Code: When to Use CLAUDE.md, Skills, Hooks, and Subagents（引导 Claude Code：何时用 CLAUDE.md / skills / hooks / 子 Agent）
- 原文链接
- https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more
- 作者
- Michael Segner（Anthropic）
- 发布日期
- 2026-06-18
⚠️ 本页是原文的中文结构化整理笔记（保留架构、数据、案例、结论），并非逐字翻译。具体参数与功能名更新很快，落地前请点击上方链接核对原文。
🎯 一句话
引导 Agent 的手段按成本从低到高排列，永远先试便宜的那个。⭐ 大多数「模型不听话」的问题，在前两三种手段里就能解决。
Claude Code 提供七种定制行为的方式，各自在上下文成本、持久性、指令权重上有不同权衡。选型取决于三个问题：指令何时加载、长会话中如何持久、在决策中的权重多大。
七种方式全对比
| 方式 | 何时加载 | 压缩后行为 | 上下文成本 | 适合什么 |
|---|---|---|---|---|
| CLAUDE.md | 根目录版会话开始时加载并常驻；子目录版在读该目录文件时按需加载 | 每会话重读并缓存，压缩后缓存清除 | 高（每行都吃 token，无论是否相关） | 项目概览、构建命令、目录结构、编码约定、团队规范 |
| Rules（规则） | 路径限定的规则只在读匹配文件时加载；未限定的像 CLAUDE.md 一样会话开始加载 | 压缩时重新注入 | 中 | 具体约束或横切约定（如「所有 API handler 必须用 Zod 校验输入」） |
| Skills | 名称和描述会话开始加载；正文仅在被斜杠命令或自动匹配调用时加载 | 已调用的技能在共享预算内重新注入，超出时最旧的先掉 | 低 | 程序性工作流——部署检查单、代码审查流程、发布流程 |
| 子 Agent | 名称、描述、工具列表会话开始加载；正文仅在通过 Agent 工具调用时加载 | 只有最终摘要和元数据回到主会话，中间结果保持隔离 | 零（调用前对父窗口零成本） | 隔离的支线任务——深度搜索、日志分析、依赖审计 |
| Hooks | 注册在 settings.json、托管策略或 skill/agent frontmatter；在生命周期事件时触发 | 完全绕过压缩 | 低（配置在主上下文之外） | 确定性自动化——编辑后跑 linter、完成时发 Slack、执行前拦截危险命令 |
| Output Styles | 注入系统提示词，会话开始加载 | 从不被压缩 | 高（且指令权重最高） | 重大角色转变（从编码助手变通用助手） |
| append-system-prompt | 通过 CLI 参数在调用时传入 | 从不压缩；首次请求后缓存 | 中（边际收益递减） | 一次性会话的领域知识、编码标准、输出格式 |
关键细节
- CLAUDE.md 要控制在 200 行以内并有明确归属人。在共享仓库中它会随团队不断追加而膨胀，稀释对关键准则的遵守
- Rules 用路径限定（
paths:frontmatter）能避免无关指令在别的工作中白白吃 token - 子 Agent 可嵌套五层，能编排数十个后台 Agent
- Hooks 与其他方式本质不同：它通过代码确定性执行，不依赖 Claude 的判断
- Output Styles 会覆盖所有默认指令（安全准则、范围最佳实践、测试习惯），除非设置
keep-coding-instructions: true。内置样式（Proactive、Explanatory、Learning）已能覆盖大多数需求
四个「反模式 → 更好做法」
| ❌ 反模式 | ✅ 更好做法 |
|---|---|
| CLAUDE.md 里写「每次 X 都要做 Y」 | 用 hook 确定性地执行格式化或通知 |
| 把「绝对不要做某事」当提示词规则写 | 用 PreToolUse hook（退出码 2 拦截调用），或用托管设置做全组织护栏 |
| CLAUDE.md 里塞 30 行的部署手册 | 做成 skill 放 .claude/skills/，正文只在 /deploy 时加载 |
| API 专用规则不做路径限定 | 加 paths: frontmatter 让它只在 src/api/** 下加载 |
决策框架
选型时问自己三个问题： 1. 这该什么时候加载？（永远 / 按需 / 被调用时 / 事件触发） 2. 它该如何持久？（缓存 / 重新注入 / 绕过压缩 / 只返回摘要） 3. 必须被严格遵守到什么程度？（建议性 / 具体约束 / 确定性保证）
结论
有效的定制应当：把 CLAUDE.md 当索引而非垃圾桶、把流程下放给 skills 和子 Agent、用 hooks 强制硬性护栏、把系统提示词修改留给罕见的刻意角色转变。这种分层方式能在团队规模化时仍保持指令的有效性。
✅ 检查点
- 为什么要按成本从低到高地尝试引导手段？
- 最轻的几种手段是什么？
- 什么时候才该动用最重的手段（如微调）？
👀 答案
- 因为低成本手段见效快、可逆、便于试错；而重手段（建复杂流程、微调）投入大且会固化，一旦模型或需求变了就要重做。⭐ 先便宜后昂贵，是所有调试的通用顺序。
- ⭐ 依次是：①把要求写清楚（明确目标和验收标准）②给出正例/反例 ③补充上下文和资料 ④提供更合适的工具。这四种都只是改输入，成本极低。
- ⚠️ 只有当前面所有手段都试过、且失败模式稳定可复现时。具体判据：问题不是「说不清楚」而是「模型确实不具备这个能力或风格」，并且你有足够的高质量样本。⭐ 现实中绝大多数场景，把力气花在上下文和工具上的回报远高于微调。
🛑 可以停在这里
⚡ 走神救援
⭐引导手段按成本从低到高排，永远先试便宜的——大多数「模型不听话」的问题在前两三种手段里就能解决。最轻的四种（都只改输入，成本极低）：把要求写清楚（明确目标和验收标准）→ 给正例反例 → 补充上下文和资料 → 提供更合适的工具。先便宜后昂贵的理由：低成本手段见效快、可逆、便于试错；重手段投入大且会固化，模型或需求一变就要重做。⚠️只有前面全试过、失败模式稳定可复现，且问题是「模型确实不具备这个能力或风格」而非「说不清楚」时，才该考虑微调；⭐现实中绝大多数场景，力气花在上下文和工具上的回报远高于微调。