前面五章里，我们装好了 Claude Code、发出了指令、走出了卡壳、设计了权限。这一章讲的是改造工具本身。扩展这种东西，光记住名字是用不起来的。真正有用的是「我现在这个不满，该用哪一个来解」的对照表。

选型地图 —— 四个问题就能定下来

扩展有六种，但要想的只有四件事：用嘴说说够不够／要不要确定地生效／要不要分到另一个语境里／要不要连到外部去——按这个顺序自问一遍，答案基本就唯一了。

Q1
用嘴说说够不够

偶尔漏掉也不致命的话，写成文字就够了。→ CLAUDE.md（全局前提）／Skills（特定工作的流程）

Q2
要不要确定地生效

哪怕漏一次都受不了，那就用机制去拦。→ hooks。它不经过模型判断，必定会执行。

Q3
要不要分到另一个语境里

不想让海量输出把正题挤掉，就放到外面去做，只拿回结论。→ subagents

Q4
要不要连到外部去

需要 AI 不可能知道的信息（数据库里的当前值、任务系统里的内容）时。→ MCP

第五个问题是「要不要分发给别人」——要分发就用 plugins。最容易混淆的是 Q1 和 Q2，也就是 CLAUDE.md、Skills、hooks。三者看着都差不多，区别在于什么时候被读取、由谁来执行。

CLAUDE.md —— 不会消失的记忆。但写长了就等于消失

CLAUDE.md 放在项目根目录下，就会在每次开启会话时被自动读取（想对所有项目通用，就放到 ~/.claude/CLAUDE.md）。因为它是文件，所以不受第 1 章那个「拖长了就忘掉前半段」的影响。它是你每次都要交代的那些话的安放处。

「说是读了却不照做」，这不是偷懒，而是结构上的问题，原因有三个。

  • 中段会沉下去——长文中间的指示容易被漏掉，写得越长，正中间的规则实际上就越等于不存在
  • 会被压缩成摘要——一旦触发压缩，细的运行规则就被压扁了。越到后半段违规越多，就是这个原因
  • 最近的指令会赢——一句「先提交了再说」，就能让几百轮之前读过的确认流程整个跳过去

办法是删。经验上确实有效的是控制在 100 到 150 行上下。超出了，就只把最要命的几条戒律留在开头，细节挪到别的文件里（重复会带来偏差，所以正本只留一份）。只给绝对不能漏的那几条标上「CRITICAL」，而且要写成从外部可以判定的形式——不是「写得用心一点」，而是「三行以内写完」。

「我读了」不能算证据。 可作判断依据的只有执行之后的行为。改写了很多遍还是不被遵守的规则，问题就不在写法上了——那是下一节要干的活。

hooks —— 不是拜托它，而是确定地生效

「不要改写 .env」——写进 CLAUDE.md，九成的情况会被遵守。漏掉那一成也不要紧，写成文字就够；要紧，就上 hooks——分界点就在这里。

hooks 是在特定时点自动执行的 shell 命令。执行它的不是模型，而是 Claude Code 本体（harness），所以它不等模型判断，必定会跑。全貌见 Claude Code hooks 是什么。常用的触发点有九个。

SessionStart 开始或恢复时 UserPromptSubmit 发送之后立刻 ［可拦截］ PreToolUse 调用工具之前＝门卫 ［可拦截］ PostToolUse 工具成功之后＝整形 ［可拦截］ Notification 等待输入、等待授权 Stop 回答结束 ［可拦截］ SubagentStop 子智能体结束 ［可拦截］ SessionEnd 会话结束 PreCompact 压缩之前 ［可拦截］

「可拦截」的意思是能在那里把动作叫停。用 PreToolUse 把危险命令挡在门外，用 PostToolUse 自动格式化——这两个是最常见的入口。配置写在 settings.json 的 "hooks" 键下面，放在哪里就决定了作用范围（~/.claude/＝个人，.claude/＝共享，settings.local.json＝只对自己）。

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "..." } ] } ] } }

结构是事件名 → 匹配式加命令的数组。matcher 写目标工具名（像 "Edit|Write" 这样用 | 分隔，省略就是全部匹配）。钩子从标准输入接收 JSON，用退出码返回结果——0 是成功，2 是拦截（此时标准错误输出会被交给 Claude）。目标文件的路径也能从输入 JSON 里取到，所以「是这个路径就叫停」是写得出来的。

钩子能把限制收紧，但不能把限制放松。 就算它返回放行，也只是省掉一次弹窗，拒绝规则始终优先。PreToolUse 的拒绝在跳过全部批准的模式下也照样有效，所以可以拿它当第 5 章放松出来的那一截的兜底。

代价也先说在前面。hooks 会以你的权限自动执行任意 shell 命令。官方也明确写着「责任完全在你」。只配置你信得过的东西，并且要校验输入。配置在会话开始时就固定下来了，所以「明明改了却不生效」的时候，请开一个新会话。

subagents —— 把语境分开再交出去

测试的全部输出、庞大的日志——这些本来看过就该丢掉的大段文本堆积起来，关键的前提就被挤出去了。subagents 就是把那部分工作放到另一个上下文里去跑，只拿回结论的摘要的机制。它有自己的上下文窗口、系统提示词和工具权限，也看不到你的对话历史，所以调查留下的残渣不会回流到主线里。

  • 分出去划算——面很宽的调查／伴随大量输出的核对／只要结论就行的自足型任务
  • 分出去吃亏——需要按顺序处理／来回沟通频繁／会改同一批文件的并行作业／一两步就能改完的修正

它是标准功能，不做配置也能用。想加自定义定义，就写在 .claude/agents/<名称>.md（想通用就放 ~/.claude/agents/），用 YAML 前置元数据写上 name / description / tools / model。管理用 /agents，调用写 @agent-<名称>。先从标准自带的探索型、计划型、通用型用起就好。

决定它会不会被调用的关键是 description。主智能体是看着这段文字来决定要不要委派的，写得含糊，它就一次也不会被叫到。要具体写清做什么，以及什么时候用——同样的坑在 Skills 里也有。

容易和它混淆的 Agent Teams，是让多个独立会话通过共享任务清单来协作的机制。它处于实验阶段、需要主动开启、默认关闭（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1）。因为跑的是另外的实例，所以令牌消耗大，而且不能嵌套。两者的区别在 subagents 与 Agent Teams 的区别 里做了对比。拿不准就用单个会话或者 subagents。

Skills —— 把流程变成资产

面对「每次都按这套流程来」的固定套路，Skills 的长处在于它只在需要的时候才被打开。它的实体是一个以 SKILL.md 为核心的目录：开头写 name 和 description，下面用 Markdown 写流程，还可以一并放上 reference/ 和 scripts/。只要放进 .claude/skills/（项目）或 ~/.claude/skills/（通用），它就会被识别。

要点在于渐进式披露。会话开始时被读进去的，只有每个技能那段简短的 description，只有当你的请求与之对上了，正文和附带资料才会被加载。所以就算装上几十个，平时的上下文也几乎不会被占掉——这正是它和「全文永远都在」的 CLAUDE.md 的决定性区别。反过来说，对不上就永远不会被打开。description 一含糊，你写的那套流程就等于不存在。怎么写见 Claude Agent Skills 是什么。

一句话概括：CLAUDE.md ＝始终会被读到的前提，Skills ＝由 Claude 判断后打开的操作手册，hooks ＝必定会执行的处理。

MCP —— 把手伸到外部系统

前面三种都是改变做法的扩展。只有 MCP（Model Context Protocol）是扩大它能碰到的范围——它是一套规范，让 AI 的手能够到数据库里的当前值、任务系统里的工单这类它在结构上不可能知道的东西。连接的形式有两种，而它们卡住的地方不一样。

  • 本地（stdio）——在自己的电脑上把服务器作为子进程启动。卡住的往往是启动本身（路径、环境变量、命令解析）
  • 远程（HTTP）——用 URL 连到云上的服务器。卡住的几乎都是认证＝返回了 401 或 403

所以不要把「连不上」笼统地当成一件事，先用 /mcp 看状态。failed 就查本地启动，needs authentication 就查远程的认证，pending approval 就是在等批准——状态决定了下一步怎么走。具体处理办法整理在 MCP 服务器连接报错的修复方法 里。

还有几个专属的坑。共享配置 .mcp.json 要放在仓库根目录（既不在 .claude/ 下面，也不在 settings.json 里面），API 密钥要写进每个服务器各自的 env。在 Windows 上，npx 的实体是批处理文件，所以经由 cmd 传成 /c npx ... 才能跑通。

接上去的服务器是要消耗上下文的。 光是工具定义堆在那里，就已经在挤占上下文了。不用的服务器先停掉比较稳妥。

plugins —— 打成一包分发出去

当技能、子智能体定义、钩子、MCP 配置开始散落各处时，把它们打成一包好分发的形式，就是 plugins。最容易搞错的是目录规则。清单文件是 .claude-plugin/plugin.json，而放进 .claude-plugin/ 的就只有它一个。skills/、agents/、hooks/hooks.json、.mcp.json 都放在根目录。

/plugin marketplace add owner/repo ← 登记一个目录源 /plugin install name@marketplace ← 再从里面逐个安装 /plugin list ← 查看已经装了哪些

引入分两步。先登记目录源，然后再逐个安装——光是加了源，什么都不会装上。作用范围分 user（所有项目）／project（所有协作者）／local（只对自己）／managed（管理员下发、不可更改），团队要统一就用 project。自己做一个的步骤见 plugins 与 marketplace 是什么。

插件有可能以你的权限执行任意代码——这是官方文档里明写的。Anthropic 不会审核第三方插件，也不会审核随插件附带的 MCP 服务器。只装来自你信得过的发布方的东西。第 5 章的权限设计，在这里以别人写的代码的形式又回来了。

从哪个开始装 —— 顺序的问题

虽然列了六种，但并不需要全都装上。在还没有困扰的时候就装，增加的只有配置的复杂度。顺序要从症状出发。

  • 每次都在交代同样的话 → CLAUDE.md。只涉及某项特定工作的话，就用 Skills
  • 写了却不被遵守 → 先删。只把真会造成损失的那几条挪到 hooks
  • 上下文一下子就满 → 把重的调查工作交给 subagents／把不用的 MCP 停掉
  • AI 够不到那些信息 → 上 MCP。一个一个接，看着通了再接下一个
  • 想把同一套配置分发出去 → plugins。只打包你自己已经用顺手的东西
  • 没什么特别的困扰 → 什么都别装。这才是最好的状态

最后一行不是玩笑。扩展也会增加卡壳的来源——「Claude Code 怎么怪怪的」，真相往往是你自己加上去的那一层。所以第 4 章的排查要排在前面。

小结

  • 选型的标准是四个问题——用嘴说说够不够（CLAUDE.md、Skills）／要不要确定地生效（hooks）／要不要分到另一个语境（subagents）／要不要连到外部（MCP）。要分发就用 plugins
  • CLAUDE.md 是跨会话的记忆。写长了中段会沉下去，被压缩冲淡，还会输给最近的指令。要删，并且把优先级标明
  • hooks 由 harness 来执行，所以不掺入判断。它能收紧限制，但放松不了
  • subagents 在另一个上下文里干活，只把摘要带回来。不适合按顺序处理和频繁来回
  • Skills 只在 description 对上时才打开，走的是渐进式披露。装多了也不重，但说明含糊就不会被调用
  • MCP 是扩大可触及范围的规范。/mcp 的状态决定了下一步怎么走
  • plugins 是分发用的盒子。别人的代码会以你的权限运行，所以要核实发布方
  • 装的顺序从症状出发。等困扰真的出现了，再一个一个来

扩展得越多，消耗也就越大。最后一章我们来讲长期用下去所需要的运营方法。请前往 第 7 章「成本与用量上限」。