六个维度，逐项比
这张表只写官方文档里能直接对上的机制，不做类比。看不懂的行，下面每节都会展开。
| 维度 | skill | plugin |
|---|---|---|
| 能做什么 |
一份 SKILL.md 说明，可带参考文件与脚本；变成 /name 命令，
或被 Claude 在相关时自动加载；支持 allowed-tools、context: fork 这类开关
|
一个目录，可含 skills、agents、hooks、MCP 服务器、hook 模块，作为一个单元安装；
里面的 skill 用 /plugin-name:skill-name 调用
|
| 装在哪 |
个人 ~/.claude/skills/<name>/SKILL.md；项目
.claude/skills/<name>/SKILL.md；还有企业托管目录、
--add-dir 附加目录、插件内、claude.ai 同步目录
|
从市场装，已获取的内容落在 ~/.claude/plugins/；
按用户、项目、本地三种作用域启用；云会话不加载本地设置里的插件
|
| 怎么共享给团队 |
把 .claude/skills/ 提交进仓库，或通过托管设置全组织下发，
或打进一个插件里
|
建市场（.claude-plugin/marketplace.json）或走官方市场；
项目作用域写进提交的 .claude/settings.json，但协作者仍要在自己机器上安装
|
| 权限边界 | allowed-tools 只在调用那一轮免确认，发下一条消息就清；
而且工作区信任管不住它——从仓库拉下来的 skill 可以给自己预先批准很宽的工具权限，提交前必须看
|
插件运行的内容以你的身份运行；插件子代理出于安全会忽略 hooks、
mcpServers、permissionMode；插件 skill 不受
skillOverrides 控制，要通过 /plugin 管
|
| 更新方式 |
改文件即生效（目录被监视），新建顶级目录后跑一次 /reload-skills；
没有版本号，仓库的 commit 就是版本
| /plugin 或 claude plugin 管理，/plugin marketplace update
刷新市场；改了 hooks、.mcp.json、agents 需要 /reload-plugins；可版本化发布
|
| 是否引入可执行代码 |
默认全文本，但能带：scripts/ 里的脚本会被执行（不是读入），
正文里的 ! 命令会在渲染时真的跑一次——来源不明的 skill 等同于来源不明的脚本
| 经常会：hooks 在生命周期事件自动执行，MCP 服务器在你每个会话旁边起进程， hook 模块是 JS 函数。这些不需要你按就会运行，所以官方专门有「插件安全和信任」一节 |
权限边界那格：skill 的 allowed-tools 绕过工作区信任。
官方文档写得很明确——即使在从未信任过的文件夹里跑，项目 skill 的
allowed-tools 依然生效。也就是说仓库里放一个 skill，
就能给自己预先批准 Bash(git push *) 这类权限。看到别人仓库里的
skill，先读它的 frontmatter，再决定要不要放进项目里。
三种组合方案，各自适合谁
只用 skill
自己在 .claude/skills/ 里写几个目录，提交进仓库。没有市场、没有版本号，
也没有任何东西会在后台自动跑。
适合谁：一到五个人的小团队；流程还在变、需要天天改文件的人； 希望 skill 也能给 Cursor、Codex 这些 agent 用（它遵循 Agent Skills 标准）。
不适合：需要 hooks 强制执行、需要多个 agent 定义一起分发的时候。
只用 plugin
从官方市场或别人维护的市场装现成的，比如
/plugin install skill-creator@claude-plugins-official。
一次装一整套，更新走市场。
适合谁：不想自己写、只想用别人打磨好的整套；团队要把 review 流程、 子代理、MCP 一起统一起来；愿意接受「装进来的东西会自动跑」。
不适合：只想加一条项目约定的人——为一个说明装整套，成本不对等。
两者叠加
插件当基座：子代理、hooks、MCP 服务器由它提供；项目 skill 补业务约定，
提交在仓库里跟着代码走。命名不冲突——插件 skill 是
/plugin-name:skill-name，项目 skill 是 /name。
适合谁：多仓库的团队；通用能力想复用、项目规则又想自己管的人。
注意：插件 skill 不受 skillOverrides 管，
要改某条插件行为只能禁用整个插件，或者复制一份成本地 skill。
三种方案里，官方那句判断最好用：skills、子代理、hooks、MCP 服务器都能独立工作， 插件存在的意义只是「把多个组件打包成一个单元装」。所以先问「我到底有几个组件」， 只有一个的时候做插件就是给自己加了一层。
选错的代价
这页真正想说的就这一段。装错层级的代价不是「不好看」，是每回合都在付。
- 为一条说明装一个插件，付的是全局上下文。 启用插件后，它里面每个 skill、agent 和可自动调用的命令，名字加描述每回合都在上下文里， 即使这次会话一次都没跑。这不是估算，是官方在「启用的插件为会话添加什么」里写明的行为， 所以官方才会在安装前的市场页面给上下文成本估计。
- 用插件管理「我想改一点」的 skill，会卡住。
插件 skill 不受
skillOverrides影响，关不掉单条，只能通过/plugin禁用或卸载整个插件。你在本地改它的文件，也不构成一份可版本化的配置。 真要定制，把它复制成自己仓库里的项目 skill。 - 用 skill 承担「必须执行」的约束，迟早失守。 skill 靠模型照着做，而且长对话压缩后，每个被调用的 skill 只保留最近一次调用的前 5,000 个 token、总预算 25,000——早调用的那条可能整段消失。官方给的方案是把这类规则挪进 hook， 因为 hook 在事件发生时每次都运行。
- 以为项目作用域会替同事安装。
项目作用域只是通过提交的
.claude/settings.json启用插件， 每个协作者仍要在自己机器上装一次。新人克隆仓库后发现命令不存在，通常就是这个原因。 相比之下，项目 skill 提交进.claude/skills/就真的跟着仓库走了。 - 装一堆插件和子代理，把描述预算吃满。 子代理的描述也有预算：非内置子代理的描述合计超过 15,000 个 token 时， Claude Code 会在启动时警告。装的时候觉得「反正不用就不花钱」，实际是反的。
五分钟自测：按顺序问四句
- 这东西只有一份说明吗？是 → 写 skill，别做插件。
只有一个人用就放
~/.claude/skills/，要共享就放项目.claude/skills/并提交。 - 里面有需要「每次都跑」的规则，或者要连外部系统吗？ 是 → 那就不是 skill 的事：规则进 hook，外部系统走 MCP server。 插件只是把这些装到一起的方式。
- 要分发的是三个以上组件、还要能统一更新吗？ 是 → 做插件、建市场，并接受「启用即加载」的成本。
- 跨 agent 也要用吗？是 → 优先 skill（Agent Skills 标准， 跨 agent 安装器支持 40+ 个 agent），因为插件这套是 Claude Code 自己的机制。
先看「Claude Skills 是什么」那页的四者边界表—— 花了二十分钟搞清楚 skill / plugin / MCP / subagent 各自管什么， 比装十个再用不上省事得多。确定要装之后，去 值得装的清单按场景挑，那里每条都写了不适合谁。
接着看
-
Claude Skills 是什么？和插件、MCP 有什么区别
一句话定义、三层来源、四者边界表，以及「什么时候该上 MCP」的判断清单。
-
值得装的 Claude Code Skills：按场景选，不按 star 排
只收装过、跑过、还能继续用的；每条都写清解决什么、不适合谁、坑在哪。
这一页的依据
- code.claude.com/docs/zh-CN/plugins/overview ——插件包含哪些组件、什么时候需要插件、启用后的上下文成本、安装作用域、第三方市场与信任。
- code.claude.com/docs/zh-CN/skills
——skill 的文件结构、加载位置与优先级、
allowed-tools与工作区信任的关系、 内容生命周期与压缩预算、skillOverrides的范围。 - code.claude.com/docs/zh-CN/sub-agents ——子代理定义、15,000 token 描述预算、插件子代理忽略的三个字段。
- code.claude.com/docs/zh-CN/mcp ——MCP 服务器进程与连接方式、工具搜索延迟加载、提示注入提醒。
本页未做安装与运行的对照实测，因此不提供耗时、token 差值一类的数字。 机制描述取自 2026-10-19 的官方中文文档；文档更新后以文档为准。