最近 AI 编程圈有个说法越来越常见：「插件可能会成为下一种重要的产品形态」。小红书小红书上已经有人放出从零开发 Codex 插件的完整教程，也有公众号开始喊「Claude 插件红利来了」。
但多数人的真实状态是：打开 Claude Code 的插件市场，看着两百多个插件，刷着两篇说法打架的「必装清单」，越看越不敢动手。
我把官方市场 claude-plugins-official 的完整名单和近半年各平台的评测文章都对了一遍。结论有点反直觉：203 个插件里，真正值得大多数人装的，只有十来个。其余的可以归成三类，下面逐一说清楚。
先看市场的盘子
先交代数据口径：以下统计来自两位作者 5 月下旬的盘点，现在的数字可能有出入，但结构不会大变。
GitHub 仓库 claude-plugins-official 目前 27.3k Star、2.9k Fork，2025 年 11 月创建，至今持续活跃。微信
官方与第三方的占比，一个来源的口径是 Anthropic 自己写了 36 个官方插件，其余 168 个是第三方合作插件，全部经过审核。微信
另一个来源的口径是市场共收录 203 个插件，其中 50 个由 Anthropic 内部维护，153 个由各厂商自建并提交索引，微软、Google、AWS、Stripe、Shopify、Figma、Adobe、MongoDB、Redis、Cloudflare 都交了作业。今日头条两个口径对不上，但结论一致：第三方插件占了七成以上。
分类上：203 个插件里开发类 92 个、效率类 39 个、数据库类 20 个，其余散在设计、运维、CRM 等垂直领域。微信这个盘子走的是「VS Code 插件市场」的模式：Anthropic 自己只维护核心插件，其余由各厂商自己开发、自己维护、自己提交索引。今日头条好处是生态扩张快，代价是质量下限由厂商自觉决定。
这个盘子结构还说明两件事。
第一，审核不等于安全背书。市场 README 里原话写着「Make sure you trust a plugin before installing」。微信审核看的是结构和功能质量，没人替你担保插件背后的外部依赖和外部服务，尤其是天生要连外部服务的 MCP 类插件。
第二，生态还很早。大量第三方插件停留在 v0.x，靠 git-subdir 或 SHA pin 挂外部仓库。微信仓库上线不到一年，今天的推荐清单是有保质期的。
共识清单：多来源都提到、且有实评的
跨平台对推荐做交叉验证时，我定了个门槛：至少两个独立来源有实评提到，才算共识。筛完只剩这几个。
code-review：提 PR 时不是简单跑一遍 lint，而是起多个专业审查代理并行查，每条发现打置信度分，80 分以下自动过滤，不刷屏。今日头条团队用 CLAUDE.md 管理代码约定的话，它还会逐条核对变更。整个市场里共识度最高的一个。
feature-dev：把功能开发拆成七个阶段的结构化流程——先读代码库、提问澄清，再做架构设计，然后才写代码，最后审查。微信想治「Claude 上来就开干」的毛病，用这个。
hookify：用 Markdown 文件写自定义 hook，不用写代码。今日头条比如「出现 rm -rf 就拦截」「不经确认不许动某类文件」，兜底型选手。
frontend-design：写前端时插件自动介入，注入设计风格指引，让 Claude 生成的页面少一点「AI 味」的审美。微信做前端的可装。
再降一档，是只有一个来源实评、但场景明确的：claude-md-management（审计 CLAUDE.md 是否跟代码库现状一致，越写越长的项目很需要）、mcp-server-dev（想把内部 API 接进来时，引导你一步步搭 MCP server）、code-modernization（遗留系统改造六步流程，自动出架构图和数据血缘图）、commit-commands（提交、推送、建 PR 一条龙）。
ralph-loop 单拎出来说：它让 Claude 自循环「写代码→跑测试→修→再跑」，直到全部通过。社区有传说，有人用这个方法一晚上搞了 6 个仓库出来，还有个 5 万美金的项目只花了 297 美金 API 费用。今日头条但实评作者自己提醒——只适合定义清晰、可自动验证的任务，且必须设 --max-iterations 上限，不然真的会无限转下去。这种只有一个来源提到、玩法又激进的插件，定义不清任务的人别碰。
三类不用碰
剩下那 180 来个，基本落进三类。
你根本不用的品牌集成。203 个插件里的大头，是特定数据库、监控平台、SaaS 工具的官方集成——如果你不用 MongoDB、Datadog 或 ServiceNow，它们和你无关。微信这类插件是给厂商自家用户准备的，不是给市场凑数的。
纯 prompt 预设。像 explanatory-output-style、learning-output-style 这类插件，本质上是预设的 prompt 模板，改的是 Claude 回话的风格。微信有用，但不是能力跃迁——自己写一段 CLAUDE.md，效果差不多。
技术演示型。真正打磨到位的也就十几二十个，很多厂商提交的插件看着唬人，实际更像技术演示，离生产可用有距离。今日头条版本号常年不动、描述里全是愿景没有细节的，直接跳过。
两个很多人忽略的成本
第一是上下文成本。插件装上后，它的命令和技能会进入提示池。有教程专门统计过：所有技能在列表里只显示名称和描述，每个只占 100-200 token，靠渐进式加载控制开销。微信但这只是「列表层面」的开销，真正触发时该加载的指令一行不少。装得越多，Claude 的「菜单」越长，命令重名、注意力稀释都是真实存在的问题。所以各教程的建议都是 3-5 个，不是 30-50 个。
第二是 MCP 类插件的变动风险。MCP 规范刚经历了史上最大的一次修订，会话和握手机制都动了。基于旧范式做的 MCP 插件，接下来会有一波适配震荡。要装 MCP 类插件，优先选大厂出品、更新勤快的。
什么时候该自己写？
这才是这篇文章最想回答的问题。插件的本质，是把 prompt 工程经验产品化——把可复用的工作流打包。所以判断标准其实很简单：
该装的情况：需求是通用的（代码审查、提交流程），或者你正好用某个厂商的产品，又或者那个插件有你自己写不出来的工程打磨（比如多代理并行加置信度过滤）。
该自己写的情况：需求高度个性化——你团队的规范、你的高频工作流、你反复手打的那段提示词。这种时候，自己做一个插件，往往比在 203 个里翻找更省事。
自己写的成本比多数人想的低：一个目录、一个 plugin.json 文件——它就是插件的「身份证」，定义了插件的基本信息——再加 commands 或 skills 目录下的一个 Markdown 文件，就是一个能跑的自定义能力。值得买社区值得买社区有保姆级教程，半小时能跑通第一个。
但如果你是想「写插件卖钱」，建议先等等。官方市场目前完全免费分发，付费机制没开放。值得买社区市面上已经出现喊「插件红利」的文章，点进去卖的是完整课程。微信自用型插件现在就可以动手，变现型插件等分发和收费机制落地再说。
行动清单
纯观望：不用装。记住「插件是 prompt 工程的产品化」这一句，看看别人把什么经验打包成了什么形状，本身就是有效信息。
日常在用：从 code-review 或 feature-dev 开始，总数别超 3-5 个。懒得挑就先装 claude-code-setup，让它扫你的项目给推荐。
团队使用：code-review 加 claude-md-management 组合，先把约定写进 CLAUDE.md，再让插件按约定执行。
想动手开发：从自己高频需求的命令型插件起步，MCP 类先别碰，规范还没落定。
值得继续盯的三个信号：市场插件数量与版本转正的速度、Anthropic 是否开放付费分发、MCP 规范修订后各插件的适配进度。哪个先动，这篇文章的结论就该更新。
