Claude Code 扩展机制该怎么选

Claude Code 的 Skills、Hooks、Subagents 看起来都能帮你定制工作流，但它们解决的是不同问题：教模型按流程做事、在指定事件上执行检查、把大量分析搬到独立上下文。Plugins 则负责把这些东西打包分享。

原文最有用的是一套选择顺序：先看要求是否必须执行，再看是否需要隔离上下文，接着判断要不要沉淀成可复用流程，最后考虑分发。不过，文中关于成本、执行保证和部分能力的表述偏满，需要和这套思路分开看。

必须执行的规则，为什么不能只写进 Skill

Skills 是存放在 .claude/skills/ 下、以 SKILL.md 为入口的 Markdown 指令。适合收纳团队约定、部署手册，以及你每次打开会话都要重新粘贴的操作流程。

它采用渐进式披露（progressive disclosure）：先让模型看到名称和描述，匹配到任务后再加载正文。作者给出的量级是，初始元数据约 50 tokens，正文通常约 500 tokens；也可以通过 /deploy-checklist 显式调用。description 因而直接影响触发效果，不能只写一个含糊的「帮助开发」。

但流程写得再详细，也仍由模型理解和执行。它可以指导模型，却不能单独承担强制约束。

Hooks 则绑定生命周期事件，在 settings.json 中配置。原文列出的事件包括 PreToolUse、PostToolUse、SessionStart 和 Stop。前者适合执行前拦截，后者适合编辑完成后格式化。

原文用下面的配置演示：每次调用 Edit 或 Write 后运行 Prettier。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write $CLAUDE_FILE_PATH"
          }
        ]
      }
    ]
  }
}

重点看 matcher 和 command：一个决定匹配哪些工具调用，一个决定执行什么。不过，原文没有交代 $CLAUDE_FILE_PATH 的注入来源，也没有处理路径引用和命令失败，不能把这段示例直接当成经过验证的项目配置。

对于 rm -rf、git push --force 这样的操作，作者建议用匹配 Bash 的 PreToolUse 检查并返回 deny。这里真正有价值的原则是：需要强制执行的要求，应交给执行机制承担。

部署流程则不同。测试、预发检查、数据库迁移是否可逆、打标签、整理变更记录，需要在主会话里逐步推进，也需要人参与判断。它适合做成 Skill；其中不可绕过的检查，再交给 Hook、权限规则或已有发布系统。

大量文件分析，为什么适合交给 Subagent

Skill 主要改变模型如何做事，Subagent 改变工作发生在哪里。

原文介绍的 Subagents 定义在 .claude/agents/，由主会话通过 Agent 工具调用，拥有独立上下文，完成后把摘要返回主会话。大量文件内容和搜索结果留在子任务里，主会话继续处理当前问题。

作者举了两类任务：扫描 500 个文件查找安全问题，以及读取 50 个 package.json、300 条锁文件记录进行依赖分析。这些是场景举例，原文没有给出实际项目或运行记录。

下面的定义展示了模型选择和工具范围：

---
name: dependency-auditor
description: Audits project dependencies for vulnerabilities and license issues
model: haiku
tools: Read, Grep, Glob
---
You are a dependency auditor. Scan package files for
outdated or vulnerable packages. Return a concise
summary of findings with severity levels and
recommended actions.

重点看 model: haiku 和 tools: Read, Grep, Glob。作者希望用 Haiku 承担较轻的分析工作，并把工具限制在读取和搜索范围。

但这段定义没有提供漏洞公告数据库的访问方式。读取依赖名称和版本，只完成了审计的一部分；要判断已知漏洞、受影响区间和修复建议，还需要可信的数据来源。仅凭这段提示词，不能保证得到可靠的漏洞报告。

原文还介绍了内置的 Explore 和 Plan：前者用于只读搜索，后者用于调查问题并返回计划。同时声称 Subagent 可以预加载 Skills、限定自己的 MCP servers，并最多嵌套 5 层。这些属于原文的能力描述，没有附版本号或验证记录。

对前端和 Node 团队，最值得借鉴的是任务边界：依赖梳理、跨目录搜索、日志分析可以先独立完成，再返回带文件位置和证据的结论。摘要要压缩噪声，也要保留复查入口。

上下文要按需加载，Plugins 留到分发时再考虑

把所有要求塞进 CLAUDE.md 很方便，却也会让当前任务承担无关指令的成本。

作者用一组估算说明差别：调用 3 个 Skill，按每个 500 tokens 计算，约占 1500 tokens；手动重复粘贴流程可能每次花 2000 tokens；包含 10 个流程的 CLAUDE.md 可能占 5000 tokens，即使其中 9 个流程暂时用不上。

Subagent 则把成本分散到独立上下文。原文假设一次审计读取 300 个文件，内部花费 20000 tokens，主会话只接收约 200—300 tokens 的摘要。它减少的是主会话接收的内容，子任务自身的推理和工具调用仍然有成本。

隔离上下文与降低总费用，是两个需要分别验证的目标。

因此，CLAUDE.md 更适合保留简短、普遍适用的项目约定；完整流程放入 Skills，大量材料处理交给 Subagents。作者还建议按文件路径或项目类型限定 Skill，避免 React 组件约定在处理 Python 文件时误加载，但没有提供具体配置。

Plugins 则解决共享问题。它通过 .claude-plugin/plugin.json 声明内容，可以打包 Skills、Hooks、Subagents 和 MCP servers。原文的清单示例叫 team-workflow，版本为 1.0.0，安装入口包括 marketplace、git URL 和 /plugin install。

先确定各部分怎样工作，再决定是否打包，顺序很实用。插件不会替你解决流程设计问题，它主要让团队安装、管理版本和共享配置更方便。

原文末尾还提到一种组合：在 Skill 的 frontmatter 中通过 hooks: 声明局部 Hooks，只在相关流程运行期间启用。不过，提供的内容在部署案例中途截断，没有完整配置，无法据此复现。

我的判断

这篇文章的分类框架值得保留：流程指导、事件执行、上下文隔离、团队分发，确实是不同层面的问题。遇到需求先辨认它属于哪一层，比直接增加提示词更容易控制复杂度。

但作者没有给出可复现的实验或对照数据。50、500、200—300 tokens，以及「有效上下文翻倍」等说法，只能作为量级说明，不能当作性能结论。具体开销取决于指令长度、输出规模和运行方式，让模型自行报告上下文用量也不足以构成完整测量。

文中对 Hooks 的描述尤其需要收紧。事件能够触发，不代表脚本必然成功；原文同时列出了 command、http、mcp_tool、prompt、agent 共 5 种 handler，并称 agent 仍属实验性。既然其中包含 LLM 调用，就不能把所有 Hook 都理解成零 token、零判断成本。

「模型完全看不到 Hook」「多个 Hook 按顺序执行」「Subagent 最多嵌套 5 层」等表述，也缺少版本和适用条件。原文没有证明这些是所有环境下的保证。

与常见替代做法相比，Hooks 适合提供编辑后的即时反馈；CI 更适合作为团队合并和发布的统一检查入口。Skills 方便指导流程，不能替代权限控制。作者把已知 flaky test 作为部署时可能调整流程的例子，也不应被理解成允许模型自行放行失败测试。

能拿来做什么

• 把反复粘贴的 React 或 Node 项目操作流程整理为 SKILL.md，在描述中写清任务和触发条件，让 CLAUDE.md 保持简短。
• 对编辑后运行 Prettier 这类要求，先验证 Hook 的事件、文件路径传递和失败反馈，再接入实际项目，并保留 CI 中的统一检查。
• 把 monorepo 依赖梳理交给独立 Subagent，要求报告包含文件路径、版本、证据来源和待确认项；漏洞判断应接入可信公告数据。
• 等 Skills、Hooks 和 Subagents 在项目中运行稳定，再打包成 Plugin，并明确团队使用的版本和升级方式。