CLAUDE.md 正在成为 Claude 用户的效率杀手！Anthropic 官方揭秘七种指令机制的正确用法，从路径限定规则到隔离运行的子代理，这篇文章将彻底改变你配置 AI 开发助手的方式。学会在正确的位置放置指令，不仅能释放宝贵的上下文窗口，更能让 Claude 的表现提升一个量级。
如果你用 Claude Code 超过一周，CLAUDE.md 大概率已经变成了一个垃圾桶。
构建命令扔进去。代码规范扔进去。部署流程扔进去。”永远不要用 var”扔进去。”记得跑 lint”扔进去。安全审查清单也扔进去。每个人往上加东西，没人敢删东西——因为没人知道哪条指令什么时候会生效。
结果呢？Claude 每次启动都把这堆东西从头读到尾。今天的任务是修一个拼写错误——全文照读。重构整个认证模块——还是全文照读。每行字都在消耗 Token。上下文窗口被不重要的事挤满，该记住的反而被稀释了。
Anthropic 显然看到了这个问题。今年 6 月 18 日，他们在官方博客发了一篇文章——标题就很直接：Steering Claude Code: CLAUDE.md files, skills, hooks, rules, subagents and more。通篇在讲一件事：你的指令放在哪里，比指令本身写得多好更重要。
Claude Code 其实提供了七种自定义行为的方式。大多数人只用了 CLAUDE.md 这一种。剩下六种被闲置，纯粹是因为没人告诉你它们各自解决什么问题。
这篇文章就是那篇官方博文的深度拆解。我会把七种机制的差异讲透，然后给你一套决策框架——以后你再往 CLAUDE.md 里塞东西之前，脑子里会先过一遍：这东西真的该待在这吗？
Anthropic 在文章里给了一张对比表。这张表值得单独拿出来说——它不光告诉你每种机制”能干什么”，更告诉你三种关键差异：什么时候加载、压缩时怎么处理、上下文成本有多高。
逐条拆开看：
追加系统提示词。通过 CLI 标志在调用时传入，仅对那次调用生效。跟 Output Styles 不同，它不会覆盖默认角色，只是在上面追加。缓存后成本中等。适合临时调整语气、输出长度、格式偏好。
这张表说的事其实就一句：上下文窗口是 Claude 最贵的资源。你放进去的每一个字都在花钱，而且会挤掉重要信息。
CLAUDE.md 的定位很明确——它应该是 Claude 对项目的”第一印象”。构建命令、目录结构、Monorepo 布局、编码约定。
它不该是什么？部署步骤、安全检查清单、代码审查工作流。这些是流程，流程该在 Skill 里。CLAUD.md 是”事实”，Skill 是”程序”。分不清这个，文件就会无限膨胀。
Anthropic 给了一个硬建议：CLAUDE.md 控制在 200 行以内，给它指定一个负责人，像审代码一样审它的每一次变更。
还有一个容易被忽略的细节：子目录 CLAUDE.md 和根目录 CLAUDE.md 的加载时机完全不同。子目录版本是按需的——只有当你碰那个目录时才触发。在 Monorepo 里，这是省钱的关键。每个团队管好自己的子目录 CLAUDE.md，前端不用为后端规范买单，反之亦然。
Rules 本身跟 CLAUDE.md 区别不大——都是 Markdown，都是给 Claude 看的指令。关键变量是 paths: 字段。
没有 paths 的 rule，行为跟 CLAUDE.md 一样：始终加载，始终占用 Token。加上 paths 之后，事情就变了——这条规则只在匹配的文件被触碰时才进入上下文。
举个例子：你有一条规则说”所有 API handler 必须用 Zod 做输入校验”。如果不加 paths，它会在你写 CSS、配 Docker、调 README 时都杵在上下文中，尽管跟这些任务毫无关系。加了 paths: [“src/api/**”] 之后，它只在 Claude 碰 API 代码时才出现。
Rules 的价值就在这——把上下文成本精确分配到它有用的时候。
什么时候用 Rules 而不是子目录 CLAUDE.md？当指令涉及”跨多个目录但从不出现在另一些目录”的横切关注点时。比如”所有 .handler.ts 文件必须做输入校验”，这些文件可能分散在不同模块中——用 paths 匹配比在每个子目录放 CLAUDE.md 干净得多。
Skill 的加载机制非常聪明：启动时只读名字和描述，正文在调用时才加载。这意味着你可以装 50 个 Skill，但不相关的永远不会消耗 Token。
但这也意味着一个常见的坑：描述写得太模糊，Skill 根本不会被触发。 描述越精确，匹配越可靠。写描述的时候问自己：Claude 在什么情况下应该自动调用这个 Skill？
Skill 可以通过斜杠命令手动调用（/code-review），也可以被 Claude 自动匹配——取决于你怎么配置。
压缩行为也值得注意：已调用的 Skill 会被重新注入，但有一个共享预算。调得太多，老的就丢了。所以不要让 Claude 在一个会话里调用 15 个 Skill——那不是 Skill 的设计场景。
Subagent 的核心价值在一句话里：中间结果别进主对话。
你让它去做一次深度搜索。它读了 20 个文件，调了 15 次 grep，出错了 3 次，最终汇总成两句话的结论。如果这一切发生在主对话里，你的上下文窗口已经塞满了你不想再看第二遍的日志。但 Subagent 把这些全部关在自己的窗口里——传回来的只有那两句话。
Anthropic 在文章中透露了一个重要细节：Subagent 支持最多五层嵌套。而且动态工作流可以编排几十上百个后台代理，编排计划和中间结果存在脚本变量里，不在 Claude 的上下文中。这解释了为什么 Subagent 能扩展到那种规模——隔离不止保护了上下文，还打开了并行的大门。
什么时候用 Subagent 而不是 Skill？当你不想看到中间过程的时候。Skill 在主线程里运行，每一步你都能看见，也能干预。Subagent 是”把门关上，给我结果”。
这是文章里最核心的判断之一。
Hooks 跟前面所有机制有一个根本区别：它是代码，不是指令。当你通过 CLAUDE.md 告诉 Claude “每次编辑后跑 prettier”时，你在指望模型记住并执行这件事。但模型会忘，会被其他指令稀释，会在长时间会话中丢失这条规则。
Hook 不一样。它是一个 PreToolUse 或 PostToolUse 事件触发一段 shell 命令或 HTTP 请求。它是确定性的——代码不会忘，不会犹豫，不会被上下文压力影响。
文章里举了一个关键场景：PreToolUse 钩子可以审查任何工具调用，以退出码 2 来阻断它。这是真正的、不可绕过的安全护栏。与此相比，在 CLAUDE.md 里写”永远不要执行 rm -rf”只是一个礼貌的请求——在足够大的上下文压力下，模型可能就忽略它了。
Hook 的类型也有讲究。command、http、mcp_tool 三种是纯确定性的，执行固定逻辑。prompt 和 agent 两种使用了模型判断——它们仍然比纯提示词可靠，因为触发的时机是确定的，只是判断逻辑用了模型。
这两个机制放在最后，因为它们的使用场景最狭窄。
Output Styles 直接覆盖默认系统提示词。Claude Code 的默认系统提示词里包含了大量关键指令：如何限定变更范围、什么时候加注释、安全问题的处理方式、验证习惯。自定义 Output Style 会把这一切全扔掉，Claude 从一个编程助手退化成一个通用助手。
所以 Anthropic 的建议是：在写自定义 Output Style 之前，先看看内置的三种——Proactive、Explanatory、Learning——它们覆盖了最常见的需求。
追加系统提示词比 Output Styles 安全一些——它只是追加，不覆盖。但它有一个递减效应：加的指令越多，每条指令被遵守的程度越低，特别是当指令之间存在矛盾时。
Anthropic 在文章末尾给了几个”快速提示”，每一种都是在说”你可能放错了地方”。我把它们扩展成五个反模式，配合正确做法：
反模式一：”每次做完 X，就做 Y”，写在了 CLAUDE.md 里。 比如”每次改完代码就跑 lint”。如果这个行为必须可靠地发生，放在 Hook 里。让模型选择要不要跑格式化工具，跟工具自动跑，是两个完全不同的世界。
反模式二：”绝对不要做这件事”，写在了 CLAUDE.md 里。 当某件事绝对不能发生时，提示词是错的工具。大多数时候模型会遵守，但在长会话、模糊情境、或者文件中有注入攻击时，模型就可能跳过这条规则。真正的护栏必须是确定性的——PreToolUse 钩子加退出码 2。再加一层托管策略（managed settings），这是唯一能部署组织级硬护栏的方式。
反模式三：CLAUDE.md 里有一段 30 行的操作流程。 流程属于 Skill。CLAUDE.md 放的是”事实”——构建命令、目录布局、团队约定。部署手册和安全审查清单应该放在 .claude/skills/ 下，正文只在调用时加载。
反模式四：针对某个 API 目录的规则，没加路径限制。 如果一条规则只跟 src/api/** 有关，不加 paths: 就等于在所有对话中都占用 Token。加上路径过滤后，它只在相关内容被触碰时才出现。
反模式五：个人偏好写进了项目级 CLAUDE.md。 所有基于文件的方法都有对应的用户级别位置。个人偏好（比如”我永远用语义化提交消息”）放在本地文件夹。项目级文件放的是团队通用但对这个代码库特有的偏好。
如果你现在打开 CLAUDE.md 发现它已经四五百行了，不要试图一次性把所有内容迁移到正确的位置。Anthropic 在文章里给了一个渐进路径，我把它拆成四个阶段：
第一阶段：把 CLAUDE.md 控制在 200 行以内。 这是最直接的收益。砍掉流程类内容（迁移到 Skill），把跨模块约束的改成路径限定的 Rules。留下来的东西应该是”Claude 每次都需要知道的基础事实”。
第二阶段：识别你的”每次都……”并做成 Hooks。 格式化、Lint、提交后通知、命令阻断——这些东西不该靠提示词来保证。一个 PostToolUse Hook 跑 prettier，一个新文件创建后跑 tsc，一个 PreToolUse 阻断危险命令。这些 Hook 一旦设置好，永远不需要再想。
第三阶段：把重复流程做成 Skills。 部署、发布、代码审查、安全检查——那些你每次做都有一套固定步骤的事情。Skill 的渐进加载意味着它的存在几乎不消耗常驻 Token——只在被调用时才进入上下文。
第四阶段：让 Subagent 处理”只看结果就行”的脏活。 深度搜索、日志分析、依赖审计。这些任务产生大量中间输出——搜索结果堆叠、试错路径、死胡同——你根本不关心过程，只需要结论。把它们关进 Subagent 的独立上下文里。
一旦这几个层都跑通了，你可以把 Skills、Subagents、Hooks、Output Styles 打包成 Plugin，分发给团队。一个人配置好，全团队受益。
Claude Code 从对话工具演进到执行环境，中间最重要的变化不是模型更强了，而是指令系统有了分层架构。
过去你只有一种方式告诉 Claude 该怎么做：写进提示词。现在你有七种。它们之间的差异不是”哪个更好”——你得分清楚哪个更对。对在加载时机、对在存活时间、对在成本控制。
CLAUDE.md 适合事实。Rules 在路径限定后适合约束。Skills 适合流程。Subagents 适合隔离任务。Hooks 适合确定性的自动化。Output Styles 和追加系统提示词适合系统级的角色调整。
判断放哪里的核心问题只有三个：
这个决策框架不值得记：用几次之后它会变成本能。那时你再打开 CLAUDE.md，看到的不是堆满的杂项，而是一份干净清晰的索引。而剩下的六种机制，各自在各自该在的地方，该加载时才加载，该省的地方一分 Token 不多花。
提示词的尽头是配置，配置的尽头是 Hook。这不是修辞，这是架构。
本文由 @枝酒 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。