下面是根据您提供的【原始文章内容】进行 SEO 重写与优化后的完整文本。所有 Markdown 格式、图片链接、代码块、列表结构均原样保留，仅对中文纯文本进行了表达优化、关键词自然融入和逻辑连贯性增强。 --- 事情是这样的。 从今年3月开始，整个团队就全面切换到了Claude Code。起初势头良好，大家往`CLAUDE.md`里添加项目规范，顺手配置几个`/deploy`、`/review`之类的Custom Commands，日子过得还算顺畅。 **一个月后，噩梦开始了。** 前端同学用Skill封装了一套“组件库使用规范”，后端同学用MCP接了个内部API做配置查询，DevOps同学用Hook挂了pre-tool检查。三套扩展各自跑得欢，但互相不知道对方的存在。最离谱的是，有一天发现同一个“数据库建表规范”的逻辑，在三个地方以三种形态并存：`CLAUDE.md`里一堆Markdown、一个Skill的`SKILL.md`、一个MCP Server的Python脚本里又写了一份。 这引发了一个关键问题：这四种东西到底该在什么场景用？它们之间是什么关系？ 通过三周时间，翻阅了大量官方文档，并在生产环境中踩了许多坑，最终整理出一张清晰的架构图。今天就把这张图展开讲讲。 ### 一个你大概率搞错了的事：它们不是平级概念 坦白讲，这是最常见的误区。 大多数人面对Skill、MCP、Hook、Plugin时，容易陷入“四选一”的思维定式，认为需要从这四个选项里挑一个来解决当前需求。但这个思维模型本身就有问题。  它们解决的不是同一个层次的问题。Skill解决的是“Claude知不知道怎么做”，MCP解决的是“Claude能不能跟外部系统对话”，Hook解决的是“Claude做事前后要不要自动触发点什么”，Plugin解决的是“这些能力怎么分发给团队”。 这不是Anthropic凭空发明的四个并列功能——这是软件开发中四个永恒问题在AI编程工具里的自然投影：**知识管理、系统集成、流程自动化、能力分发**。 在生产环境中的真实体感是：80%的场景用Skill + MCP就足够了，Hook和Plugin解决的是规模化以后才暴露的治理问题。 做了多年后端架构的人，大概率见过太多“过度设计”的惨案——项目刚启动就上了消息队列和微服务，结果三个月后连业务逻辑都没跑通。Claude Code的扩展机制也一样：**Skill起步，遇到真实瓶颈再加，别提前设计**。 ### Skill：给模型穿上知识铠甲 Skill的本质是什么？ 官方文档的定义很精确：Skill是一组指令、工作流和工具配置，告诉Claude“做这类任务时该按什么步骤来”。 但有个比喻更贴切：**Skill是给模型穿上的“知识铠甲”**。没有Skill，Claude像一个聪明但对你项目一无所知的新同事；有了Skill，它变成了一个带着SOP手册的老兵。 Skill和`CLAUDE.md`的区别是最容易搞混的地方。`CLAUDE.md`可以理解为“项目宪法”，始终加载，定义全局规则。而Skill则是“SOP手册”，按需加载，只在处理特定任务时激活。 举个例子。团队在`CLAUDE.md`里写了7条全局规则：“所有API接口必须返回`{code, data, message}`结构”“数据库字段用下划线命名”。这些是所有任务共享的底线。 但“前端如何接入埋点SDK”这件事，只有做前端需求的Claude需要知道。如果把它塞进`CLAUDE.md`里，就成了全局噪音——后端Claude每次处理PR都得浪费几百个token读一段跟自己无关的内容。 这就是Skill的存在意义：**按需加载，不污染全局上下文**。 ```ja vascript --- name: frontend-tracking description: 前端埋点 SDK 接入规范。当需要添加用户行为追踪时使用。 --- # 前端埋点规范 ## 初始化方式 在 `app.tsx` 中引入 `@company/tracker`，调用 `initTracker({ appId: process.env.TRACKER_APP_ID })`。 ## 事件命名规范 - 页面浏览：`page_view_{pageName}` - 按钮点击：`btn_click_{buttonName}` - 表单提交：`form_submit_{formName}` ## 禁止事项 - 禁止在 `useEffect` 中直接调用 `track()`，必须封装成自定义 Hook - 禁止上报用户手机号、邮箱等 PII 数据 ``` 这个Skill写好之后，Claude只有在前端任务中需要处理埋点逻辑时才会加载它。 从Custom Commands到Skills的演进，是一次范式转换。Custom Commands是人驱动，你说“执行这个”，Claude照做。Skill是模型驱动，Claude自己判断“现在该用这个能力了”。这个转变的意义远超功能本身——Custom Commands是给Claude加“按钮”，Skill是给Claude加“直觉”。  ### MCP：打破数据孤岛的USB接口 上面提到Skill解决的是“知不知道怎么做”，但有个场景Skill打死也解决不了。 你需要查数据库里某张表的实时字段。Skill可以描述“字段A是什么类型、字段B的枚举值有哪些”，但这份描述是写文章时人工录入的。两周后表结构变了，Skill里的描述就过期了。 **Skill是静态知识，而MCP是实时连接。** MCP（Model Context Protocol）是Anthropic在2024年11月发布的协议，如今已经成了AI工具集成外部系统的事实标准。设计思路很直接：如果每个外部系统都要单独适配Claude Code，Anthropic得维护几百个connector。不如定义一个标准协议，让系统自己暴露能力。 坦诚说，MCP的token消耗确实比Skill高。每一次MCP tool调用都要经过“Claude描述意图→MCP Server解析→执行→返回结果”四个环节，仅一个简单的数据库查询就可能多消耗500-1000 token。 但“省token”不是拒绝MCP的理由。 什么时候该用MCP？一个硬判断标准：**当需求涉及“实时数据”或者“外部系统状态变更”时，Skill做不到。** 查数据库当前状态、调用内部API创建工单、读取Kubernetes集群的Pod状态，这些都是MCP的主场。Skill能给Claude“知识”，但给不了“此刻的真实世界信息”。 ```python # 一个简单的 MCP Server 示例：查询内部服务状态 from mcp.server import Server from mcp.types import Tool, TextContent server = Server("service-health") @server.list_tools() async def list_tools(): return [Tool( name="check_service_status", description="查询指定服务的健康状态", inputSchema={ "type": "object", "properties": { "service_name": { "type": "string", "description": "服务名称" } }, "required": ["service_name"] } )] @server.call_tool() async def call_tool(name: str, arguments: dict): if name == "check_service_status": service = arguments["service_name"] # 实际调用内部健康检查 API result = await internal_api.health_check(service) return [TextContent(type="text", text=str(result))] ``` 生产环境有一个典型的“Skill不够用，上了MCP”的案例：自动化部署流程。一开始用Skill写了部署步骤的SOP，“先跑测试，再构建镜像，再滚动更新”。但实际部署时，Claude需要知道“当前K8s集群里老Pod还在不在”“新镜像有没有成功拉取”。这些是Skill描述不出来的实时状态。**Skill能告诉你该怎么做，但MCP能告诉你现在是什么情况。**  ### Hook：流程的隐形守护者 Hook是四个机制里最容易被低估的一个。 很多人第一次看到Hook的反应是：“噢，跟Git Hooks差不多，就是自动化脚本。”但Claude Code Hooks远比Git Hooks强大。Git Hooks只能做“提交前检查代码格式”这种yes/no判断。Claude Code Hooks可以修改工具输入、阻止工具执行、注入额外上下文、甚至调用MCP工具。 这是官方Hooks文档里的一段配置片段： ```json { "hooks": { "PreToolUse": [{ "matcher": "Write|Edit", "hooks": [{ "type": "command", "command": "python3 .claude/hooks/pre-write-check.py", "timeout": 10000 }] }], "PostToolUse": [{ "matcher": "", "hooks": [{ "type": "command", "command": "python3 .claude/hooks/log-tool-usage.py" }] }] } } ``` `PreToolUse`可以在Claude写文件之前拦截，比如检查修改的文件是否包含敏感信息（密钥、内部域名），如果有就阻止写入。`PostToolUse`可以在每次工具调用后自动记录日志，不侵入任何Skill或MCP的逻辑。 团队曾经踩过一个坑：有位同事在调试时把测试环境的数据库连接串写进了一个`.env.example`文件，差点提交。后来用Hook挂了一个`PreToolUse`检查——任何Write/Edit操作写入包含“密码”“secret”“connectionString”等关键词的文件时，自动拦截并警告。 **Hook解决的是“什么时候”的问题**。Skill和MCP回答“怎么做”，Hook回答“什么情况下触发”。它们是正交的两个维度。 一个判断标准：**如果需求是“每次做X之前/之后自动做Y”，这就是Hook的活**。别把这种逻辑塞进Skill里。Skill应该只描述“怎么做”，不应该关心“什么时候做”。  ### Plugin：团队能力的标准化容器 Plugin是四个概念里最“上层”的一个，也是误解最多的一个。 最常见的误解：“Plugin不就是把Skill和Hook打个包？跟我直接放`.claude`目录有什么区别？” 技术上确实，Plugin就是把Skill、Hook、MCP配置打包在一起。但Plugin解决的不是技术问题，是**治理问题**。 亲身教训：10个人的团队，每个人在`~/.claude/skills/`下维护自己的Skill。三周后，出现了3个不同版本的“代码审查Skill”，2个版本的“部署脚本Skill”，还有1个同事的Skill引用了已废弃的内部API地址。 **Skill是个人效率工具，而Plugin是团队能力标准。** 当你把一组Skill + Hook + MCP配置封装成Plugin、发布到内部源之后，团队所有人装的是同一个版本、同一份逻辑。更新也是集中升级，不存在“A用的v1.2，B还在用v1.0”的情况。 什么时候需要Plugin？**当“多人协作”和“版本一致性”成为痛点时。** 如果是个人使用Claude Code，Plugin几乎没意义，直接维护`CLAUDE.md`和`~/.claude/skills/`就够了。但3人以上的团队，Plugin是避免混乱的有效方式。 目前Claude Code插件市场已有9000+插件，这个生态的成熟度远超大部分人的想象。Claude Code本身也在以惊人速度迭代，v2.1.0一个版本的更新就有1096个commits。这种迭代密度意味着扩展机制的设计还在快速演进中。 ### 三层决策框架：以后遇到新需求自己判断 说了这么多，落地到实际：怎么判断自己的场景该用哪个？ 这里有一个三层决策框架。  **第一层：你的问题属于哪个层次？** 问自己：“我到底在解决什么问题？” - 想让Claude知道某件事该怎么做——知识层，往下走。 - 想让Claude能访问外部系统或实时数据——集成层，往下走。 - 想让Claude在特定时机自动执行某些操作——自动化层，往下走。 - 想把一组能力标准化分发给团队——分发层，直接选Plugin。 **第二层：关键判断** 如果落在“知识层”，再问自己：这份知识是所有任务都需要，还是只有特定任务需要？ - 全局规则 → `CLAUDE.md` - 特定任务 → Skill 如果落在“集成层”，再问自己：连接的是静态文档（API手册、数据库schema说明）还是实时系统（数据库本体、K8s集群、内部API）？ - 静态文档 → Skill就够了，加MCP属于过度设计 - 实时系统 → MCP Server 如果落在“自动化层”，再问自己：这个操作需要在Claude“做某事前”触发，还是“做完后”触发？ - 事前 → PreToolUse Hook - 事后 → PostToolUse Hook - 会话级 → SessionStart / Stop Hook **第三层：选型结论** 下面这张表建议存下来。 | 维度 | CLAUDE.md | Skill | MCP | Hook | Plugin | |------|-----------|-------|-----|------|--------| | 层次 | 知识层（全局） | 知识层（按需） | 集成层 | 自动化层 | 分发层 | | 触发方式 | 始终加载 | 模型判断加载 | 模型调用 | 生命周期事件 | 安装后生效 | | Token消耗 | 始终消耗 | 按需消耗 | 单次高 | 按事件消耗 | 同所含组件 | | 适用规模 | 个人/团队 | 个人/团队 | 个人/团队 | 个人/团队 | 3人以上团队 | | 核心解决 | 全局底线规则 | 特定任务SOP | 外部系统连接 | 时机自动化 | 能力标准化分发 | | 不能做的事 | 访问外部API | 获取实时数据 | 做代码规范检查 | 给Claude知识 | 解决技术选型 | ### 从Skill到MCP的真实升级路径 聊一个实操问题：什么信号说明Skill不够用了，该升级到MCP Server了？ 总结起来有三个触发条件，缺一不可： **信号一：Skill里的数据开始过期。** 在Skill里维护了一份“服务列表”或者“API字段说明”，隔两周就要手动更新。这意味着这份知识本质上是“实时数据的快照”。Skill不该承载快照，MCP才该承载。 **信号二：Claude做决策时需要“验证事实”。** 不是“我以为”而是“事实是什么”。比如“这个接口现在能不能调通”“这个配置项线上当前值是多少”。Skill能给Claude信心，MCP能给Claude事实。 **信号三：在Skill里写了“执行脚本”。** 如果发现自己写的Skill包含大量`bash`命令（查数据库、调API、读文件），这就是MCP的典型领域。Skill该描述的是流程和规范，不该是执行逻辑。 三个信号同时出现，就该动手拆MCP Server了。 但要说一句实在话：绝大多数情况下，信号一和信号二不会同时出现。大多数团队的需求就是“告诉Claude我们团队的代码规范”“给它一个部署的SOP步骤”。Skill完全够用，别为了升级而升级。 生产环境有一个反面案例：团队一开始用MCP接了一个内部文档搜索API，token消耗很高，每次调用3000 token。后来发现这个文档三个月才更新一次。直接用Skill描述文档结构就够了，省了60%的token。**选型的第一原则永远不是“哪个更高级”，而是“哪个刚好解决我的问题”。** --- 投个票：你现在主要用什么方式扩展Claude Code？ - Skill（SOP手册式，按需加载） - MCP Server（接外部API / 数据库） - Hook（生命周期自动化脚本） - Plugin（打包分发） - `CLAUDE.md`一把梭，没拆 ### FAQ **问：CLAUDE.md和Skill到底怎么分？现在CLAUDE.md已经3000行了。** 删。 把`CLAUDE.md`精简到只放三类东西：(1) 项目技术栈声明（语言、框架版本）；(2) 硬性编码规范（命名、目录结构）；(3) 安全红线（禁止的操作）。 剩下的全部拆成Skill。前端规范拆一个、数据库规范拆一个、部署流程拆一个。拆完之后，Claude只在做对应任务时才加载对应Skill，token消耗立刻降下来。 **问：Hook能不能替代Skill？比如用PreToolUse在每次Claude写代码前自动注入代码规范？** 技术上可以。但这是个坏设计。 Hook的生命周期跟“事件”绑定，跟“任务语义”无关。用Hook注入代码规范，意味着“Claude改README时”也会触发规范检查，但它根本不需要。**Hook做任务无关的自动化，Skill做任务相关的知识注入。** 别混用。 **问：现在的场景是“一个人的项目，但以后可能团队用”，要不要直接上Plugin？** 不要。等到真的有多人协作的需求时再封装。过早的Plugin会带来额外的维护成本：版本号管理、发布流程、兼容性测试。一个人根本不需要这些。架构设计的黄金法则：**别为还没出现的需求写代码。** **问：9000+插件都是什么类型的？值得用吗？** 目前插件市场的主流是三类：(1) 框架集成（Next.js、Nuxt、Spring Boot的项目模板）；(2) 工具增强（Git工作流优化、代码审查规则包）；(3) 平台对接（Vercel部署、Supabase数据库管理）。如果你的技术栈恰好匹配，第三类很值得，比自己写MCP Server省时间。 坦白讲，前两类谨慎安装。它们往往塞了很多不需要的规则，反而增加token噪音。 --- 如果读到这里，脑子里应该有了一个清晰的图景：**Skill是模型的知识铠甲，MCP是外部系统的连接器，Hook是流程的守夜人，Plugin是团队能力的分发包。** 它们不是竞争关系，是一个工作流的不同零件。 团队的实际结论是：90%的日常场景Skill + MCP就够了。Hook只在安全检查和自动化记录时用，Plugin是给10人以上团队准备的。 下一篇准备聊聊Claude Code的上下文治理：`CLAUDE.md`怎么写到刚好200行不冗余不遗漏、`/compact`什么时候用、TOKENOFF和TODO到底怎么配合。想看的评论区吱一声，人多就写。