📌 项目地址：openai/plugins | ⭐ 1,428
颗星 | 🔧 JavaScript | 📜 未标注
这个仓库 (openai/plugins) 经常被人跟 ChatGPT Plugins
搞混。它俩完全是两回事。ChatGPT Plugins 是给聊天机器人用的，这里存的是
Codex 插件示例——Codex 是 OpenAI 的那个编程助手（现在叫
CLI 工具），插件用来扩展它能调用的工具链。
仓库只有 1428 个 star（写这篇文章时），但在用 Codex
的人眼里，它是唯一的官方示范。我花了些时间把 plugins/
下面每个目录都过了一遍，说几个我觉得有价值的点。
不是代码库，是目录结构说明书
这个项目不提供 npm install 或者 pip install，你 clone
下来之后也没有可执行文件。它的价值全在
插件目录的骨架设计。
每个插件都放在 plugins/<name>/ 下面，核心入口是
.codex-plugin/plugin.json。这个文件定义插件叫什么、能提供什么“能力”（ability）、需不需要环境变量。跟它平级的可选文件有：
skills/——
存放“技能”的目录，每个技能是一个独立的可调用操作（比如 Figma 插件里的
use_figma命令）commands/—— 自定义命令，用户可以在 Codex 里直接敲
/xxx触发agents/—— 更复杂的代理行为，可能是多步工作流hooks.json——
生命周期钩子，比如插件加载后自动检查版本更新mcp.json—— Model Context Protocol
配置，让插件声明自己能暴露哪些外部工具给 Codex.app.json—— 可能是应用级别的元数据（仓库没细说）assets/—— 静态资源，比如图标、模板文件
我看完的感觉是：这是一个拼图式的设计。插件可以只写一个
plugin.json
加上几个技能文件，变成一个“轻量工具”；也可以塞满
agents/、hooks.json、mcp.json，变成一个“重型工作流引擎”。自由度很大，但对新手不友好。
亮点示例：Figma、Notion、构建类插件
README 里明确列出了六个“highlighted richer
examples”，我挑三个讲讲它们能教什么。
Figma：把设计系统写进代码助手
plugins/figma 提供了 use_figma
这个技能。你可以在 Codex 里输入“把这段 UI 应用到 Figma 设计稿”，Codex
就会通过这个技能调用 Figma API。它还包含 Code to
Canvas（代码转画板元素）和 Code
Connect（代码组件与设计组件双向映射）。如果你在用 design token
或者维护设计系统库，这个插件的实现方式可以直接照搬。
Notion：知识的单向管道
plugins/notion
的卖点是“计划、研究、会议、知识捕捉”——说白了就是让 Codex
对话结果能直接写入 Notion
数据库。它演示了如何让一个编程助手跟文档工具双向交流（其实是单向写入，读取需要额外配置）。我觉得它的
skills/
目录值得一看，里面分了几个粒度不同的操作，比如“记录一个想法”和“创建一份完整的研究笔记”对应不同的技能文件。
build-ios-apps /
build-macos-apps：脚手架 + 调试指南
这两个插件相当庞大。iOS 那个包含 SwiftUI
实现、性能分析、调试步骤；macOS 的还多了构建/运行/调试循环的自动化，以及
.app 打包指导。它们展示的是
如何在插件里组织多步骤技能，而不是一个简单的“发请求拿数据”。比如构建
iOS 应用的 skills/ 里可能有“创建 SwiftUI
View”、“运行单元测试”、“分析 Instruments
数据”等多个子技能，每个技能有自己独立的 prompt
和参数。这种结构对于想通过插件实现脚手架工具的开发者来说，是最直接的参考。
MCP 配置到底在解决什么问题？
.mcp.json 这个文件被多次提及。Model Context Protocol 是
OpenAI
提的一个开放协议（仓库里并没给出完整规范），它的核心思想是：插件不再仅仅“给
Codex 提供函数调用”，而是向 Codex 暴露一个资源目录。比如 Google
Slides 插件可以通过 MCP 告诉
Codex：“我能读取你当前幻灯片的所有页面，也能创建新页面”，Codex
自己决定什么时候调用哪些资源。
我翻了下 plugins/google-slides 和
plugins/netlify，它们的 mcp.json
确实比普通技能文件复杂，包含 tools（工具列表）和
resources（资源列表）字段。如果你计划写一个能跟外部服务深度交互的插件，抄这个结构会比从零设计省很多事。
这个仓库到底适合谁来读
- 已经在用 Codex CLI
的人：可以直接把某个插件目录软链接到
~/.codex/plugins/里体验（注意：仓库 README
没写这一步，但它确实是标准做法） - 打算给 Codex
写插件的人：这是唯一的官方示例集合，比读抽象文档直观。尤其
plugin.json里用abilities字段描述能力，每个
ability 可以关联一个 prompt 模板，这种设计在其他项目里很少见 - 想理解 MCP 的人：
mcp.json
文件分布在多个插件里，对比着看能理解 MCP 跟传统 function calling
有什么不同
不适合谁？没有 Codex 环境的人。这些插件不能独立运行，它们只活在 Codex
的上下文里。你也别指望它们能直接装到 ChatGPT 或者 VS Code 里。
一点实话
这个仓库目前还在比较早期的状态（最后一次提交是几个月前，有一些 issue
没人回）。示例数量少（大概十几个），而且有些插件的 skills/
目录几乎是空的，只放了几个
README.md。如果你想找一个“开箱即用”的东西，肯定会失望。但如果你需要理解
Codex
插件的设计哲学和目录规范，它是目前能找到的最好样本——没有第二份官方资料告诉你
hooks.json 怎么写、.app.json 跟
plugin.json 怎么配合。
我建议重点关注 plugins/figma 和
plugins/build-ios-apps 这两个，它们的内容量最大，能覆盖 80%
的常见模式。