Cursor万星插件库拆解：一条命令装进Claude Code

Cursor官方插件库在GitHub上攒了超过一万颗星，但你可能不知道，它的插件规范从第一天起就没打算只服务Cursor一个软件。B站UP主“1024工程笔记”最近做了一次拆解，不仅把Cursor插件装进了Claude Code，还验证了同一份Skill文件在两个客户端之间的兼容性。

插件清单的极简设计：一个字段就能上架

这份规范的核心是一个叫plugin.json的清单文件。UP主把它称作“字段的说明书”——做一个能上架的插件，必填字段只有一个：name。版本、作者、图标、许可证全是可选。你建个文件夹，放一个JSON文件，写一行name，它就是个合法的插件。

name还不能随便起：小写字母打头，中间只能加横线和点。这个约束简单到近乎随意，但正是这种极简设计让一万多星的仓库有了轻量地基。

光有名字当然不干活。一份清单可以挂七类组件：命令、智能体、Skill、规则、钩子、MCP服务、变量。但UP主提醒了一个容易忽略的细节——组件不用在清单里挨个登记。agents文件夹里的文件自动当智能体加载，skills文件夹里的自动当Skill加载，清单里写路径只在特定场景下才需要。

官方插件Thermos（分支审查）的清单里只列了两个文件夹，一行代码没有。Pocket Strait把大任务分给云端智能体并行跑，也是纯说明文件堆出来的。那份200行的字段说明养出来的插件，大半就是这样。

plugin.json 是插件系统的清单文件（manifest），类比于 npm 的 package.json 或 VS Code 扩展的 package.json。它的作用是向宿主客户端声明"这个插件叫什么、包含哪些能力、适用于哪个客户端版本"。清单本身不执行业务逻辑，只做声明；真正的功能由清单指向的组件目录（如 skills/、agents/）承载。正因为清单只负责"索引"而非"实现"，规范才能做到极简——把复杂度下放到各组件自己的文件格式里，清单层只保留最少的必要信息。这种分层设计也是插件生态能快速扩张的原因之一：开发者只需理解自己那类组件的写法，不必先啃完整套元数据规范。

隐藏的客户端分发字段：为多端兼容埋下伏笔

规范里有个容易漏看的字段：minClientVersion。UP主指出，这个字段管的是“这份插件发给谁”。字段里能看到的客户端有两个——Cursor和Grogbot（注：原文如此，可能指GitHub Copilot或类似客户端）。

一份清单同时管着两个客户端的分发，还能对其中一个写上never直接整个隐藏。UP主由此判断：这份规范从第一天起就没打算只服务Cursor一个软件。

实测：一条命令把Cursor插件装进Claude Code

仓库根目录下有个.claude-plugin文件夹，里面是marketplace.json——这是Claude Code插件市场的清单格式。Cursor官方的仓库里放着竞品的市场清单，UP主当场做了实测。

先敲一句版本确认命令，确认本地Claude Code支持市场安装。然后把克隆下来的仓库注册成市场，执行claude plugin install，格式是“插件名@市场名”。回车之后屏幕上出现安装成功的输出，“一个字没改”。

装上的是Origin Apps，官方写的一套Skill，教智能体把GitHub应用搬到Origin平台。用/details命令查看明细：两个Skill平时常驻占用约等于0 Token，每个Skill调用一次不到20个Token。对比一下，你自己写一条系统提示词就是几千个Token。

但UP主把边界说得很清楚：这份兼容清单里只有一个插件Origin Apps，剩下16个官方插件、50多个第三方都没进来。“它不是全量互通，是一扇门不是一座桥。”想把17个官方插件全用上，还是得装Cursor本体。

marketplace.json 是 Claude Code 的插件市场清单，作用类似于一个"应用商店的索引文件"：它列出该市场下有哪些插件、每个插件的来源地址和元信息。执行 claude plugin install 插件名@市场名 时，Claude Code 会先读取已注册市场的 marketplace.json，按名字找到对应条目，再拉取插件内容并落到本地插件目录。"注册市场"这一步本质上是把某个 Git 仓库或本地路径加入客户端的市场列表，之后安装命令才有据可查。这也解释了为什么 Cursor 仓库里放一份 marketplace.json 就能被 Claude Code 识别——兼容的关键不在代码，而在于双方都遵循同一套"市场索引 + 清单"的约定。

Skill格式通用：同一份文件，两边都认

UP主用官方脚手架create-plugin十分钟做了一个校对插件“Token Reading Rules”，管口播稿里数字怎么读。总共两个文件：一个清单JSON放在.cursor-plugin文件夹，一个说明文件放在skills文件夹，13个字段里name必填其余选填。说明文件9行，把数字按数值读的规则写进去。

官方约定了一个本地目录.cursor/plugins/local，脚手架文档写明放进去就生效，不用安装Cursor本体。UP主实测确认：打开本地目录，两个文件直接被识别。

更关键的验证在后面。他把同一份说明文件原封不动复制一份，放进Claude Code的Skill文件夹，新开一个绘画（对话）问它“你有没有Token Reading Rules”，回答“有”。同一份文件，一边是Cursor插件的组件，一边是Claude Code的Skill，两边都认。

Skill 是这类插件体系中的一种组件类型，通常是一个 Markdown 说明文件，用自然语言描述"在什么场景下、按什么规则做事"，由智能体在需要时按需加载。它的关键特性是渐进式披露：Skill 文件平时只保留极短的元信息（名称、触发条件），只有被调用时才把正文注入上下文，因此常驻 Token 开销接近于零。这与系统提示词"一次性全量塞入"的方式形成鲜明对比。也正因为 Skill 的本质是"纯文本 + 约定格式"，不依赖特定客户端的 API，它才具备跨客户端复用的天然条件——同一份 Markdown，Cursor 当作插件组件读，Claude Code 当作 Skill 读，内容完全一致。

官方校验工具：多余字段一律不许有

UP主用官方那份字段说明书校验自己写的清单，一次通过。他故意塞了个规范里没有的字段，直接被拒，错误还标明了在第几行。说明书里写得很明确：多余字段一律不许有。

这就是官方的质量门——字段拼错一个字母，市场就把你拦在门外，不用等人审。UP主用同一把尺子扫了仓库里全部100个清单，100个全过，零例外。

Schema 校验（模式校验）是指用一份预先定义的字段规范去检查 JSON 文件是否符合约定：哪些字段必填、哪些可选、类型是什么、是否允许额外字段。严格模式（additionalProperties: false）会拒绝任何规范之外的字段，这正是"多余字段一律不许有"的技术来源。这种做法的好处是把质量把关前移到提交阶段——拼错字段名、多写一个键，都会在本地或 CI 阶段被机器拦下并报出行号，无需人工审核。代价是规范演进时必须同步更新 Schema，否则合法的旧插件可能被误判。对插件市场而言，机器化校验是规模化扩张的前提：一万个插件靠人审不现实，靠 Schema 可以秒级全量扫描。

两条路线的对比：官方定规范 vs 社区野蛮生长

UP主把Cursor和DeepSeek^广告的插件生态放在一起对比：DeepSeek那边靠社区4000个插件自己筛，Cursor靠官方17个插件直接装。质量把关方式也不同——一个靠实测测评，一个靠机器校验清单。组件规格上DeepSeek四类，Cursor七类，但Skill格式两边通用。上手速度都是一条命令的量级。

UP主的结论是：两套都用，Cursor用Claude的格式做兼容，Claude的生态也在涨自己的插件市场格式，正在合流。先学会写这份“说明书”的人，两边通吃。

对于想自己动手的开发者，两条安装命令和校对插件的两个文件都在UP主的置顶评论里，复制就能跑。下一期他计划分析Thermos官方怎么做代码评审。