大家好，我是程序员鱼皮。
最近 Anthropic 官方发了一篇博文，标题叫《Steering Claude Code》，把 Claude Code 的整套配置体系从底层逻辑到使用场景讲了个透。
由于是官方团队亲自写的，相当于出题人告诉你标准答案，因此整篇文章的干货价值非常高。
今天我结合官方内容加上我自己使用 Claude Code 的经验，给大家做一个完整的中文解读。
原文指路：https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more
Claude Code 的调教方式共有 7 种：CLAUDE.md 文件、Rules 规则、Skills 技能、Subagents 子智能体、Hooks 钩子、Output Styles 输出风格，以及 Append System Prompt 系统提示词追加。
每种方式的核心区别在于 3 点：
什么时候加载到上下文
长对话压缩时会不会被丢掉
占用多少 token
如果你把指令放错了地方，AI 可能直接忽略掉你的指令，白白浪费 tokens。
接下来咱们挨个儿学习。
CLAUDE.md 是放在项目根目录的 Markdown 文件，会话一开始就加载，全程常驻在上下文中。
那 CLAUDE.md 里适合放什么内容呢？
像构建命令、目录结构、代码规范、团队约定这些 AI 需要 时刻记住 的事实性信息。
我在自己的 中多次强调，CLAUDE.md 就像给新同事写的项目文档。你不需要每次都跟 AI 解释项目用的是什么技术、有什么规矩，只要写一次，之后都会生效。
CLAUDE.md 的加载分两种方式。
根目录的 CLAUDE.md 是始终加载的，压缩对话时也会重新读取，不会丢失。
子目录的 CLAUDE.md 比如 app/api/CLAUDE.md，只有当 Claude 读取该目录下的文件时才会加载，适合放只跟特定模块相关的约定。
官方明确建议，CLAUDE.md 尽量控制在 200 行以内。
原因很简单，CLAUDE.md 的每一行都占 token，不管当前任务会不会用到。
如果你塞了 500 行进去，哪怕做一个简单的前端样式调整，也得带着那些后端部署规范一起加载，纯属浪费。
我自己就踩过这个坑，之前把所有东西都往 CLAUDE.md 里堆，后来发现 AI 的指令遵循度明显下降了，特别是在长对话里。后来精简了一波，把流程性的内容移到了 Skills 里，效果立竿见影。
所以记住一个原则就好：CLAUDE.md 只放「事实」，不放「流程」。
构建命令、技术栈、目录结构、命名规范是事实。部署流程、代码审查清单、发布步骤是流程，应该封装为 Skills。
2、Rules 规则 - 路径级的精准约束
Rules 是放在 .claude/rules/ 目录下的 Markdown 文件，用来给 Claude 设定具体的约束或编码规范。
它最强大的地方在于支持路径作用域。你在规则文件的头部加一个 paths 字段，就能让这条规则只在 Claude 读取特定路径下的文件时才生效。
比如我有一条规则是「所有 API 处理器必须使用 Zod 进行输入验证」，我把它的作用域设为 src/api/**。这样当我只是在改前端页面的时候，这条规则压根不会加载，也就不浪费 token。
---
paths:
- "src/api/**"
- "**/*.handler.ts"
---
所有 API 处理器必须使用 Zod 进行输入验证。
我自己在项目中就是这么用的，把数据库相关的规范限定在 src/db/** 下面，前端相关的限定在 src/components/** 下面，各管各的。
什么时候该用 Rule，而不是子目录 CLAUDE.md 呢？
答案是：当一条规范需要跨目录生效的时候。
比如所有 .test.ts 文件都要遵守某个测试规则，用路径作用域的 Rule 更合适。子目录 CLAUDE.md 只能管它所在那个目录下面的文件。
3、Skills 技能 - 按需加载的工作流
Skills 放在 .claude/skills/ 目录下，每个技能是一个文件夹，核心是一个 SKILL.md 描述文件。
Skills 的渐进式加载设计非常优雅。会话开始时，Claude 只会读取每个 Skill 的名称和简短描述，完整的技能内容只有在被触发时才加载到上下文中。
这意味着你可以定义几十个 Skills，但平时它们几乎不占 token。只有当你主动调用（比如输入 /code-review），或者 AI 自动匹配到当前任务需要某个技能时，完整的指令内容才会加载进来。
我在 .claude/skills/ 下面放了部署流程、代码审查清单、创建新组件的标准步骤等等。这些流程性的东西如果全写在 CLAUDE.md 里，哪怕你只是说个「你好」，就得白白浪费不知道多少 tokens。放在 Skills 里就不一样了，需要时才加载。
还有个很重要的细节。压缩对话时，已触发的 Skills 会按总预算重新注入，如果预算不够，最早触发的技能会被优先丢弃。所以一次会话里别触发太多 Skills，聚焦当前任务最重要。
4、Subagents 子智能体 - 隔离的独立助手
Subagents 放在 .claude/agents/ 目录下，每个文件定义一个独立的 AI 助手。
跟 Skills 最大的区别在于，Subagent 运行在自己独立的上下文窗口里，只有最终结果会返回给主会话。所有中间过程完全不占用你主对话的上下文空间。
什么场景适合用 Subagent 呢？
比如深度搜索代码库找某个 Bug 的根因、分析日志文件定位性能瓶颈、做依赖审计检查哪些包有安全漏洞。这类任务的中间过程可能产生几万 token 的内容，如果都堆在主对话里，很快就会把上下文撑爆。
Subagent 还支持嵌套，最多可以嵌套 5 层深，配合动态工作流可以编排几十甚至上百个后台 Agent 并行工作。
我之前用 Claude Code 的 /batch 命令批量迁移 API 版本，本质上就是在用 Subagent。它会自动把任务拆成十几个子任务，每个在独立工作树中运行，互不干扰。
那 Skills 和 Subagents 怎么选呢？
很简单，如果你想看到 AI 的执行过程并随时干预，用 Skill。如果你只关心最终结果、不想被中间信息干扰，用 Subagent。
5、Hooks 钩子 - 确定性的自动化
Hooks 是 7 种方式里最特殊的一个。
前面讲的 CLAUDE.md、Rules、Skills 本质上都是给 AI 的「建议」，AI 可能遵循也可能不遵循，特别是在长会话或复杂场景下。
但 Hooks 不一样，它不是指令，而是自动化代码。到了触发条件就一定会执行，不需要 AI 来决定要不要做。
Hooks 通过 settings.json 注册，绑定到 Claude Code 生命周期中的特定事件，比如工具调用前（PreToolUse）、工具调用后（PostToolUse）、压缩对话前（PreCompact）等等。
最经典的用法就是：每次编辑文件后自动跑 Prettier 格式化。
这件事如果写在 CLAUDE.md 里，AI 大概率会遵循，但也可能会忘掉。
用 Hook 就不存在这个问题，文件一编辑，Prettier 就自动执行，跟 AI 模型本身无关。
而且 Hook 的上下文成本几乎为零，因为配置信息压根不在主上下文里。
「永远不要做 X」靠指令是不够的
这是官方博文里我觉得最值得记住的一个观点。
你在 CLAUDE.md 里写「永远不要删除数据库迁移文件」，Claude 大部分时候确实会遵守。但是在长会话、上下文压缩、或者遇到某个文件里的 prompt 注入时，AI 是有可能违反这条指令的。
真正的安全防线需要 Hook + 权限 双重保障。你可以用 PreToolUse Hook 检查每一次工具调用，一旦发现要删除数据库迁移文件，就直接 exit code 2 拦截掉。再配合 Managed Settings 从组织层面强制禁止某些操作，这样才能真正做到万无一失。
这个思路跟我之前分析 Claude Code 源码时看到的 fail-closed 设计是类似的。Claude Code 内部的工具系统默认把所有工具当作「危险操作」处理，除非工具明确声明自己是只读的。
安全这件事，不能指望 AI 的自觉性。
最后两种方式我用的相对较少，所以放在一起讲。
Output Styles 是用来定义 Claude 输出风格和行为模式的。它放在 .claude/output-styles/ 目录下，会被注入到系统提示词中，永远不会被压缩丢掉。
但有一点要特别注意，自定义输出风格会替换掉 Claude Code 的默认系统提示词。
也就是说，Claude Code 原本内置的那些关键行为，比如怎么确定修改范围、什么时候加注释、遇到安全问题怎么处理，自定义之后就全没了。
所以官方的建议是先看看内置的几种风格够不够用，别轻易去自定义。目前内置了 Proactive 主动执行、Explanatory 详细解释、Learning 协作学习这 3 种模式，基本覆盖了大多数使用场景。
Append System Prompt 是另一种调整 Claude 行为的方式，它允许你在不修改任何文件的情况下，临时给 Claude 追加一段指令。
具体用法是通过 CLI 的 --append-system-prompt 参数传入，只对当次调用生效。
跟 Output Style 的区别在于，它是追加而非替换，不会影响 Claude Code 的默认行为。适合临时调整语气、输出格式这些轻量需求。
不过官方也提到了一个限制，追加的指令越多，AI 对每条指令的遵循度就越低，特别是指令之间有冲突的时候。
什么时候该用什么？
一口气看完 7 种方式，你可能会有点蒙。
没关系，官方给了几条判断标准，有个印象就行。
第一，CLAUDE.md 放「事实」，Skills 放「流程」。
如果你的 CLAUDE.md 里有超过 30 行的步骤性内容，比如部署 runbook、安全审查清单，就应该把它移到 .claude/skills/ 里面去。
第二，「每次 X 后做 Y」这类需求应该用 Hook，不要写在指令里。
比如每次编辑后跑 Prettier、提交前检查 lint、完成任务后发 Slack 通知，这些都不应该依赖 AI 的记忆力。模型选择做某件事，和某件事自动发生，这完全是两回事。
第三，「绝对不能做 X」这种硬性要求需要 Hook + 权限双保险。
光靠指令只能做到 AI 大部分时候遵守，真正的安全边界必须用确定性机制来保证。这跟写代码一个道理，你不会靠注释来防止某个函数被错误调用，你会用类型系统和权限检查来兜底。
我的实践经验
再分享几个我自己配置 Claude Code 的心得。
首先是 CLAUDE.md 要有「索引」思维。不要把它当百科全书，把它当目录就好。告诉 Claude 项目的基本信息，然后用指针指向更详细的文件。
比如写上：前端组件规范见 docs/FRONTEND.md、部署流程用 /deploy 技能。
这样 CLAUDE.md 保持精简，Claude 需要详细信息的时候会自己去读对应文件。
然后是 Skills，我觉得这是目前最被低估的功能。我现在把很多重复性的工作流程都封装成了 Skill，什么 AI 热点搜集、视频动画制作、图文创作工作流等等。
Subagent 我主要用来做调研型任务。比如：帮我调研一下这个库有没有替代方案、搜集信息、分析一下这个 Bug 的原因，这类任务中间过程很长，但最终只需要一个结论，用 Subagent 可以让主对话保持干净。不过很多 AI 工具现在都能自动创建和管理 Subagent 了。
最后哔哔
OK 就分享到这里，你会发现 Claude Code 的配置体系设计得很讲究。事实和流程分离、按需加载降低成本、确定性保障优于概率性指令、隔离执行避免上下文污染。这些设计思想不管你是想深度使用 Claude Code，还是想自己搭建 AI Agent 系统，都值得好好学一学。
本文会收录到我免费开源的 ，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。
我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~
也欢迎在评论区聊聊：你的 Claude Code 配置是怎么组织的？有没有什么好用的 Skills 或 Hooks 推荐？
热门跟贴