别再什么都塞进 CLAUDE.md 了——Anthropic 官方发布的七种自定义方式决策框架

0 评论 103 浏览 0 收藏 20 分钟

CLAUDE.md 正在成为 Claude 用户的效率杀手!Anthropic 官方揭秘七种指令机制的正确用法,从路径限定规则到隔离运行的子代理,这篇文章将彻底改变你配置 AI 开发助手的方式。学会在正确的位置放置指令,不仅能释放宝贵的上下文窗口,更能让 Claude 的表现提升一个量级。

一、你的 CLAUDE.md,正在拖垮你的 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 在文章里给了一张对比表。这张表值得单独拿出来说——它不光告诉你每种机制”能干什么”,更告诉你三种关键差异:什么时候加载、压缩时怎么处理、上下文成本有多高。

逐条拆开看:

  • CLAUDE.md(根目录)。会话启动就加载,全程不释放。压缩时会被重新读取。上下文成本最高——每行字都在消耗 Token,不管你今天的任务跟它有没有关系。适合放构建命令、目录结构、团队约定——那些”每次会话都用得上”的东西。
  • CLAUDE.md(子目录)。按需加载——只有当 Claude 读到那个子目录下的文件时才触发。压缩后就丢了,直到下次碰那个目录。上下文成本很低。适合放”只跟某个模块有关”的约定。
  • Rules(规则)。未加路径限制的规则行为跟 CLAUDE.md 一样,始终加载。但加了 paths: 字段后,只在匹配的文件被触碰时才加载。压缩后会被重新注入。关键创新就在这里——你不需要为全仓库的规范买单,只付你用到的那部分。
  • Skills(技能)。启动时只加载名字和描述(约 100 个 Token),技能体在调用时才加载。压缩后已调用的技能会重新注入,但有一个共享预算上限——最早调用的先被丢弃。适合放”流程类”的东西:部署清单、发布流程、代码审查步骤。
  • Subagents(子代理)。启动时加载名字、描述和工具列表,代理体只在通过 Agent 工具调用时才加载。最关键的是:子代理在自己的独立上下文中运行,只有最终结果返回主会话。中间过程的噪音永远不会进入你的主对话。适合深度搜索、日志分析、依赖审计这类”中间结果你不关心的活”。
  • Hooks(钩子)。基于生命周期事件触发,完全绕过压缩机制。配置本身不在主上下文里,只有少数情况(比如阻断错误)会返回输出。适合”必须确定性地发生”的事:文件编辑后自动格式化、完成后发 Slack、阻断危险命令。
  • Output Styles(输出风格)。会话启动时注入系统提示词,永不压缩。上下文成本高——因为它会覆盖默认的系统提示词。适合”角色转换”场景:把 Claude 从编程助手改成通用助手。

追加系统提示词。通过 CLI 标志在调用时传入,仅对那次调用生效。跟 Output Styles 不同,它不会覆盖默认角色,只是在上面追加。缓存后成本中等。适合临时调整语气、输出长度、格式偏好。

这张表说的事其实就一句:上下文窗口是 Claude 最贵的资源。你放进去的每一个字都在花钱,而且会挤掉重要信息。

三、逐个拆解:每种机制的正确姿势

CLAUDE.md:你的项目宪法。操作手册请放别处

CLAUDE.md 的定位很明确——它应该是 Claude 对项目的”第一印象”。构建命令、目录结构、Monorepo 布局、编码约定。

它不该是什么?部署步骤、安全检查清单、代码审查工作流。这些是流程,流程该在 Skill 里。CLAUD.md 是”事实”,Skill 是”程序”。分不清这个,文件就会无限膨胀。

Anthropic 给了一个硬建议:CLAUDE.md 控制在 200 行以内,给它指定一个负责人,像审代码一样审它的每一次变更。

还有一个容易被忽略的细节:子目录 CLAUDE.md 和根目录 CLAUDE.md 的加载时机完全不同。子目录版本是按需的——只有当你碰那个目录时才触发。在 Monorepo 里,这是省钱的关键。每个团队管好自己的子目录 CLAUDE.md,前端不用为后端规范买单,反之亦然。

Rules:路径范围过滤,分水岭在此

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 干净得多。

Skills:名字和描述是入场券,流程体才是干货

Skill 的加载机制非常聪明:启动时只读名字和描述,正文在调用时才加载。这意味着你可以装 50 个 Skill,但不相关的永远不会消耗 Token。

但这也意味着一个常见的坑:描述写得太模糊,Skill 根本不会被触发。 描述越精确,匹配越可靠。写描述的时候问自己:Claude 在什么情况下应该自动调用这个 Skill?

Skill 可以通过斜杠命令手动调用(/code-review),也可以被 Claude 自动匹配——取决于你怎么配置。

压缩行为也值得注意:已调用的 Skill 会被重新注入,但有一个共享预算。调得太多,老的就丢了。所以不要让 Claude 在一个会话里调用 15 个 Skill——那不是 Skill 的设计场景。

Subagents:上下文隔离是朋友,不用当开销

Subagent 的核心价值在一句话里:中间结果别进主对话。

你让它去做一次深度搜索。它读了 20 个文件,调了 15 次 grep,出错了 3 次,最终汇总成两句话的结论。如果这一切发生在主对话里,你的上下文窗口已经塞满了你不想再看第二遍的日志。但 Subagent 把这些全部关在自己的窗口里——传回来的只有那两句话。

Anthropic 在文章中透露了一个重要细节:Subagent 支持最多五层嵌套。而且动态工作流可以编排几十上百个后台代理,编排计划和中间结果存在脚本变量里,不在 Claude 的上下文中。这解释了为什么 Subagent 能扩展到那种规模——隔离不止保护了上下文,还打开了并行的大门。

什么时候用 Subagent 而不是 Skill?当你不想看到中间过程的时候。Skill 在主线程里运行,每一步你都能看见,也能干预。Subagent 是”把门关上,给我结果”。

Hooks:提示词的尽头是 Hook

这是文章里最核心的判断之一。

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 和追加系统提示词:别轻易动底层的默认角色

这两个机制放在最后,因为它们的使用场景最狭窄。

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,分发给团队。一个人配置好,全团队受益。

六、指令的艺术:放对地方就是省 Token,放错地方就是烧钱

Claude Code 从对话工具演进到执行环境,中间最重要的变化不是模型更强了,而是指令系统有了分层架构。

过去你只有一种方式告诉 Claude 该怎么做:写进提示词。现在你有七种。它们之间的差异不是”哪个更好”——你得分清楚哪个更对。对在加载时机、对在存活时间、对在成本控制。

CLAUDE.md 适合事实。Rules 在路径限定后适合约束。Skills 适合流程。Subagents 适合隔离任务。Hooks 适合确定性的自动化。Output Styles 和追加系统提示词适合系统级的角色调整。

判断放哪里的核心问题只有三个:

  1. 这东西每次会话都用得上吗? 是→CLAUDE.md。否→继续往下。
  2. 只在碰特定文件时才有用吗? 是→路径限定 Rules。否→继续往下。
  3. 需要确定性地发生,还是要靠模型记住? 需要确定性→Hooks。可以靠模型→Skills 或 Subagents。

这个决策框架不值得记:用几次之后它会变成本能。那时你再打开 CLAUDE.md,看到的不是堆满的杂项,而是一份干净清晰的索引。而剩下的六种机制,各自在各自该在的地方,该加载时才加载,该省的地方一分 Token 不多花。

提示词的尽头是配置,配置的尽头是 Hook。这不是修辞,这是架构。

本文由 @枝酒 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自作者提供

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!