12 · 怎么给 AI 装插件
翔宇一直在想一个问题：为什么有些人用 Claude Code 效率是别人的十倍？技术能力差距没那么大。追到底，发现答案是——他们把自己的经验打包成了可复用的模块
翔宇一直在想一个问题：为什么有些人用 Claude Code 效率是别人的十倍？技术能力差距没那么大。追到底，发现答案是——他们把自己的经验打包成了可复用的模块。这个「打包」的动作看起来简单，但背后的设计哲学值得拆一拆。——翔宇
要点速览
- 你将理解为什么学完了所有功能，「怎么组合」才是真正的问题
- 你将理解散装能力为什么难以传递，以及 Plugin 怎么解决这个问题
- 你将理解命名空间、LSP 支持等设计决策背后的逻辑
- 你将理解 Marketplace 解决的分发问题
- 你将从整个 12 篇系列中看到一张完整的概念网络
1. 一个有趣的问题
你花了两周时间把 Claude Code 调教得非常顺手。CLAUDE.md 写了详细的项目规范，配了三个 MCP 服务器（GitHub、数据库、搜索），设了五个 Hooks（代码格式化、敏感文件保护、桌面通知、日志审计、上下文注入），还写了几个 Skills 让 Claude Code 掌握你团队的编码风格。
效率翻倍了。你很满意。
然后你的同事问：「你 Claude Code 配了什么？我也想用。」
你愣了一下。怎么给他？
CLAUDE.md 可以共享——它就是一个文件。但 Hooks 配置分散在 settings.json 里，脚本散落在 .claude/hooks/ 目录下。MCP 服务器配置也在 settings.json 里，有些还带环境变量。Skills 在另一个目录。这些东西互相依赖、互相配合，但它们是散装的。
你得手动教同事：「先把这个文件复制到这里，再把那段 JSON 粘贴到那里，然后别忘了装 jq，还有这个脚本要 chmod +x……」
到第三个同事来问的时候，你已经不想重复了。
这个场景引出了一个问题：学完了所有功能，怎么把它们组合起来，并且把组合传递给别人？
2. 第一步尝试：手动打包
最朴素的方式是什么？写一个文档，列出所有配置步骤，让同事照着做。
能行。但你很快会发现三个问题。
第一，步骤太多容易出错。漏一步就不工作，而且出了问题很难排查。
第二，更新很痛苦。你改了 Hook 的逻辑，得通知所有人重新配置。
第三，冲突。你的同事已经有自己的 Hooks 和 Skills，你的配置和他的怎么共存？
🧠 底层逻辑 这个问题不是 Claude Code 特有的。软件工程里反复出现同一个模式。最早的程序是一个个 .c 文件，手动复制分享。后来有了包管理器——npm、pip、cargo——把代码、依赖、配置打包在一起，一条命令安装。最早的服务器配置是手动一行行执行命令。后来有了 docker——把系统、依赖、配置打包成镜像，一条命令运行。每个领域在成熟的过程中都会经历从「散装」到「打包」的转折。
Claude Code 的 Skills、Hooks、MCP、Agents 正处于这个转折点。它们各自很强大，但缺一个把它们组合在一起的容器。
3. 遇到新问题：需要一个容器
那这个容器应该长什么样？
想一想：一个好的包管理系统需要什么？
首先，它需要一个清单——「这个包里有什么」。npm 有 package.json，docker 有 dockerfile。Claude Code 的容器需要一个类似的东西。
其次，它需要一个安装方式——「一条命令搞定」，不需要手动复制文件。
第三，它需要隔离——你的包和我的包不冲突。
这三个需求指向的就是 Plugin。
4. 再深一步：Plugin 到底打包了什么
一个 Plugin 可以包含五种组件。你已经在前面的篇章里认识了它们：
| 组件 | 你在哪篇见过 | 在 Plugin 里的位置 |
|---|---|---|
| Commands（命令） | 第 4 篇「对话」 | commands/ 目录 |
| Agents（proxy） | 第 7 篇「proxy」 | agents/ 目录 |
| Skills（技能） | 第 6 篇「技能」 | skills/ 目录 |
| Hooks（钩子） | 第 10 篇「确定性」 | hooks/hooks.json |
| MCP 服务器 | 第 9 篇「连接」 | .mcp.json |
一个 Plugin 不需要包含所有五种。它可以只有一个命令，也可以是全套组合。但关键是：不管包含什么，它们被放在同一个目录结构里，由同一个 plugin.json 描述，作为一个整体安装和卸载。
🎨 打个比方 如果 Skills 是螺丝刀、Hooks 是扳手、MCP 是电钻，那 Plugin 就是工具箱。工具箱不增加任何工具的功能——螺丝刀还是那个螺丝刀。但工具箱做了两件事：一是把相关的工具组合在一起（打开一个箱子就有一整套），二是让你能把这套工具递给别人（「给你这个箱子」比「给你这个螺丝刀，再给你那个扳手，再去那边拿电钻」简洁得多）。
5. plugin.json——插件的身份证
每个 Plugin 的核心是一个叫 .claude-plugin/plugin.json 的文件。它描述了这个 Plugin 是什么、包含什么。
必需的字段只有一个：name。其他都是可选的。但翔宇建议你至少填写 name、description 和 version。
name 必须用 kebab-case（小写字母加连字符），比如 code-review-toolkit。为什么？因为 name 会被用在文件系统路径和命令标识符里，空格和大写字母在这些场景下会引发问题。
6. 发现一：命名空间解决冲突
这里有一个探索过程中浮现的有趣问题。
假设你装了两个插件，都提供了一个叫 format 的命令。如果是散装的，两个命令会冲突——Claude Code 不知道你要调用哪一个。
Plugin 系统通过命名空间解决了这个问题。每个 Plugin 的组件都在它自己的命名空间里。当你安装 code-formatter@team-tools 和 doc-formatter@community-tools 时，即使它们都有 format 命令，也不会冲突——因为完整标识符不同。
命名空间不是什么新概念。npm 的 @scope/package、Java 的 com.company.package 都是命名空间。它解决的是同一个问题：当独立开发的模块被组合在一起时，如何避免名字冲突。没有命名空间，Plugin 生态就无法规模化。
7. 发现二：LSP 让 AI 获得精确感知
继续探索。Plugin 还有一个不太起眼但很有价值的能力：LSP（Language Server Protocol）支持。
LSP 是编辑器和语言工具之间的标准协议。当你在 VS Code 里写 Python，输入一个变量名后按点号，弹出的自动补全列表——那就是 LSP 语言服务器在工作。
Plugin 可以通过 .lsp.json 文件配置语言服务器。安装这个 Plugin 后，Claude Code 就能利用 LSP 提供的精确类型信息来辅助代码分析。
🔑 关键点 为什么这很重要？AI 理解代码靠的是模式匹配和上下文推理——大多数时候很准，但偶尔会犯类型错误或者找不到函数定义。LSP 提供的是编译器级别的精确信息——这个变量的类型是什么、这个函数定义在哪里、哪些地方引用了它。AI 的推理能力 + 语言服务器的精确类型信息 = 更靠谱的代码分析。LSP 支持让 Plugin 不只是给 AI 添加「知识」，还能给 AI 添加「精确感知」。
8. 发现三：Marketplace 解决分发
Plugin 解决了打包的问题。但打包好的东西还需要分发——别人怎么找到你的 Plugin、怎么安装它？
这就是 Marketplace（市场）的角色。Plugin 是 APP，Marketplace 是 APP Store。
Marketplace 本身非常简单——它就是一个 JSON 文件（marketplace.json），列出了这个市场里有哪些 Plugin、在哪里能找到它们。这个 JSON 文件可以托管在 GitHub 仓库里、GitLab 上、甚至你本地的一个文件夹。
一个团队的典型工作流：
- 团队里有人开发了一个 Plugin
- 把它放到团队的 GitHub 仓库里
- 在仓库里创建一个 marketplace.json 列出这个 Plugin
- 其他人用
/plugin marketplace add owner/repo添加这个市场 - 用
/plugin install plugin-name@marketplace-name安装
想一想：你的团队里有没有一些「每个人都在重复做的配置」？比如代码格式化规则、测试流程、部署脚本？这些就是最适合做成 Plugin 的候选者。
9. 温和纠偏：Plugin 的价值不在于「新功能」
走到这里，你可能会觉得 Plugin 就是给 Claude Code 加功能的。
不完全对。Plugin 里的每一个组件——命令、技能、钩子、MCP 服务器——都是 Claude Code 本来就支持的能力。你不需要 Plugin 也能配 Hooks、装 MCP。
Plugin 的价值在于三件事：
组合——把相关的能力打包在一起，形成一个完整的工作流。
分发——让这个工作流可以被其他人一键安装。
维护——更新 Plugin 就能更新所有使用它的人的配置。
💬 通俗讲 这三个价值看起来不如「新功能」那么性感，但在实际工作中，它们往往决定了一个工具能不能从「个人利器」变成「团队基础设施」。散装的能力再强大，如果不能方便地传递给别人，它的价值就被锁死在你一个人身上。
10. 全貌浮现——12 篇概念网络
这是费曼系列的最后一篇。我们从第 1 篇的「位置」走到了第 12 篇的「扩展」。现在回头看看，这 12 个概念之间是什么关系。
根基层
位置（第 1 篇）是一切的起点。AI 住在你电脑里——这个看似简单的设计决定，让后面所有功能成为可能。
感知层
上下文（第 2 篇）是 AI 的视野——它能看到多少、记住多少。记忆（第 3 篇）是持久化的上下文——跨会话的偏好和知识。这两者决定了 AI 对你项目的理解深度。
交互层
对话（第 4 篇）是你和 AI 沟通的方式。思考（第 5 篇）是 AI 处理问题的深度——你可以控制它想多深。
能力层
技能（第 6 篇）让 AI 掌握特定领域的知识和流程。proxy（第 7 篇）让 AI 派出分身并行处理子任务。协作（第 8 篇）让多个 AI 组成团队分工合作。连接（第 9 篇）让 AI 通过 MCP 够到外部世界。
保障层
确定性（第 10 篇）用 Hooks 确保关键操作 100% 执行。边界（第 11 篇）用权限、沙盒和成本控制划定活动范围。
生态层
扩展（第 12 篇，这篇）用 Plugin 把上面所有能力打包、组合、分发。
🧠 底层逻辑 这六层不是随意排列的——它们是一条从底层到顶层的生长路径。没有「位置」就没有「感知」，没有「感知」就没有「能力」，没有「能力」就没有「保障」的必要，没有这些散装的零件就不需要「打包」。每一层都建立在前一层的基础上。
11. 一个更大的图景
如果你把 12 篇都读完了，你会发现 Claude Code 的设计哲学始终如一：
给用户控制权。
它不是一个「全自动」的工具。它给你工具来控制 AI 的行为，而不是替你做决定。
CLAUDE.md 让你控制方向。Hooks 让你控制执行。权限让你控制边界。effort 让你控制成本。Plugin 让你控制分发。
每一个设计选择都在同一条线上：AI 是工具，不是主人。它应该增强你的能力，而不是取代你的判断。
这也是费曼系列想传达的核心——不是教你「怎么用 Claude Code」，而是帮你理解「Claude Code 为什么这样设计」。理解了设计哲学，具体操作你自己就能摸索出来。
⚡ 速记 Plugin = 能力的容器（Skills + Hooks + MCP + Agents + Commands）。plugin.json 是身份证，marketplace.json 是应用商店。命名空间防冲突，LSP 添精确感知。Plugin 的价值不是新功能，是组合 + 分发 + 维护。
12. 你真的懂了吗
这篇拆了两个概念：打包和全局回顾。
- 散装的 Skills + Hooks + MCP 和打包成 Plugin 的 Skills + Hooks + MCP，功能上有什么区别？没有区别的话，Plugin 的价值到底在哪？
- 命名空间解决什么问题？如果没有命名空间，Plugin 生态会遇到什么困境？
- 回顾 12 篇的概念网络，你能画出从「位置」到「扩展」的依赖关系图吗？哪些概念依赖哪些概念？
- 有人说「Claude Code 就是一个 AI 编程工具」。你现在还同意这个定义吗？如果不同意，你会怎么重新定义它？
- 12 篇的设计哲学有一条主线。你能用一句话概括吗？
