如果说 Claude Code 插件目录像“AI 编程的包管理器雏形”，那 cursor/plugins 就是另一个信号：AI IDE 不想再把能力都塞进产品本体里，它们开始让工作流以插件形式流动。
本次抓取时，Cursor 官方的 cursor/plugins 仓库约 644 stars、80 forks，在 GitHub TypeScript Trending 中单日新增约 133 stars。这个数字不算夸张，但它代表的结构变化很重要。
README 开头写得很直接：这是“Official Cursor plugins for popular developer tools, frameworks, and SaaS products”。每个插件都是仓库根目录下的独立目录，并且有自己的 .cursor-plugin/plugin.json manifest。仓库根部还有 .cursor-plugin/marketplace.json，用于列出整个 marketplace。
真正有意思的是目录结构。Cursor 的插件不仅是 UI 扩展，也可以包含：
skills/：带 frontmatter 的 Agent Skillsrules/：Cursor 规则文件，也就是我们熟悉的.mdcmcp.json：MCP server 定义README.md、CHANGELOG.md、LICENSE
这说明 Cursor 对插件的理解不是“给编辑器加一个按钮”，而是“把一套 Agent 工作方式打包”。
举个开发团队最熟悉的例子。一个前端团队可能有自己的组件约束：禁止直接写裸 CSS、必须走设计 token、接口请求要统一封装、测试必须覆盖关键交互。过去这些东西散落在 Cursor rules、项目文档、PR 评论里。你换一个项目，就要重新解释一次；新人接手，也要慢慢踩坑。
插件规范出现后，这些约束可以变成一个“可安装工作流”：规则放进 rules/，可执行能力放进 skills/，外部服务接入放进 mcp.json。AI 不再靠猜团队习惯，而是读到一组明确的行为边界。
这会改变 AI IDE 的竞争方式。
过去的竞争是：谁补全更快，谁聊天更顺，谁的上下文窗口更大。接下来会多一个维度：谁的工作流资产更容易迁移。 如果一个团队为 Cursor 写下了大量 rules、skills 和 MCP 配置，这些东西就是生产资产。它们能否跨项目复用，能否被审查，能否按版本升级，都会影响工具粘性。
但这里也有一个现实问题：各家都在定义自己的插件目录结构。Claude Code 有 .claude-plugin/plugin.json，Cursor 有 .cursor-plugin/plugin.json。表面上都支持 skills、MCP、commands/rules 这类概念，细节却不完全一致。短期内这是生态创新，长期看可能会变成迁移成本。
我的建议很简单：如果你现在就想给团队沉淀 AI 工作流，不要只写“给某个工具看的 prompt”。尽量把内容拆成更中性的三层：规则、技能、工具连接。规则描述边界，技能描述步骤，MCP 描述外部能力。这样即使不同 AI IDE 的插件格式变化，你也不至于从头重写。
对团队负责人来说，最值得现在就做的事情不是追插件数量，而是建立一份“AI 工作流资产清单”：哪些规则属于项目通用规范，哪些技能只适合某个仓库，哪些 MCP 服务会触碰敏感数据。等插件生态成熟后，这份清单就能直接转成可安装目录。没有这一步，插件市场再热，也只会变成新的配置混乱。
Cursor 插件规范现在还早，但方向已经清楚：AI IDE 的价值不只是“帮你写代码”，而是让团队把自己的工程方法装进去。