截至 2026 年 7 月，Codex 的插件已经不再只是几个简单扩展。一个插件可以同时带来工作流说明、外部服务连接和可调用工具。问题也随之变化：开发者真正需要的不是 “装得多”，而是让 Codex 在关键环节拿到真实上下文，并按可复用的工程流程做事。
本文从 OpenAI 官方文档和插件仓库出发，再对照 GitHub Issue、X、CSDN、掘金、博客园等公开讨论，最终选出 9 个含金量较高的开发者插件。每个插件都说明了使用场景、使用方式、可观察效果和边界。

先分清 Plugin、Skill、Connector 和 MCP

按照 OpenAI 的插件说明，它们的关系是：
名称
负责什么
典型例子
Plugin
可安装、可分发的能力包
GitHub、Figma、Vercel
Skill
告诉 Codex 某类任务应该怎样做
TDD、排查 CI、部署验收
Connector
连接需要登录的外部服务
GitHub、Sentry、Figma 账户
MCP Server
向 Codex 暴露结构化工具和外部上下文
查询部署、Issue、日志或设计节点
一个 Plugin 可以只包含 Skill，也可以把 Skill、Connector 和 MCP Server 打包在一起。本文只把当前 Codex 插件体系中的安装包计入 9 个候选，不把一个独立 MCP 地址单独叫作「插件」。
插件目前支持 ChatGPT Work 网页端、ChatGPT Work / Codex 桌面端和 Codex CLI；不支持 Codex IDE 扩展和移动端。安装后需要新建会话，新的 Skill 和工具才会进入会话环境。这些范围都来自 OpenAI 官方插件文档。

9 个插件的作用

我采用了四条筛选标准：
  1. 能补充本地仓库之外的真实上下文，或者固化一个重要工程检查点。
  1. 有公开的官方文档、插件清单或维护仓库，能够核对实际能力。
  1. 使用结果可以观察，例如读到真实 PR、返回具体部署日志或生成一份可审查的安全报告。
  1. 权限和适用边界足够明确，不靠「提升十倍」之类无法验证的口号入选。
快速选择如下：
插件
它在开发链中的位置
最适合谁
是否建议常驻
GitHub
仓库、PR、Issue、CI、发布
代码托管在 GitHub 的开发者
是
Superpowers
规划、TDD、调试、交付流程
复杂、多阶段任务
视任务而定
CodeRabbit
提交前与 PR 代码审查
缺少第二位审查者的个人或小团队
视评审频率而定
Codex Security
安全扫描、验证和调查
涉及鉴权、支付、上传、用户数据的项目
发布前启用
Build Web Apps
React / Next.js、UI、测试、数据库
Web 全栈与前端开发者
Web 项目常驻
Vercel
Preview、部署、日志、环境变量、域名
使用 Vercel 的团队
是
Sentry
线上错误、Trace、监控与修复
已接入或准备接入 Sentry 的项目
是
Figma
设计稿读取、Design to Code、Code Connect
从 Figma 落地 UI 的开发者
设计阶段启用
OpenAI Developers
OpenAI API、API Key、Agents SDK、排错
构建 OpenAI 应用或 Agent 的开发者
相关项目常驻
这里的「常驻」仍然有前提。例如代码不在 GitHub，就没有必要安装 GitHub；项目没有使用 Vercel，也不需要让 Vercel 插件占据 Skill 列表。

GitHub：最接近通用必装

如果项目代码放在 GitHub，GitHub 是这 9 个里最接近「必装」的一个。它解决的不是写代码本身，而是让 Codex 看到真实的仓库协作状态。
GitHub 插件清单明确列出它的能力：检查仓库、处理 PR 和 Issue、排查 CI、回应评审意见，并准备发布变更。使用 ChatGPT 账户登录 Codex 时，它通过 GitHub Connector 授权，不要求开发者把 PAT 直接写进对话；API Key 登录的 Codex 环境则可以按官方说明配置 GitHub MCP 和环境变量。
适合这样使用：
安装后的可观察变化是：Codex 可以直接读取指定 PR、评论和检查状态，不需要你复制整段日志；处理完成后也能把结果落回真实 GitHub 工作流。
它不能代替权限控制。仓库写入、回复、合并和发布都属于外部动作，提示词里应该明确「只读」「允许修改」和「是否允许推送」。

Superpowers：把复杂任务变成工程流程，但不一定更省

Superpowers 是一个由多个 Skill 组成的软件开发方法包，覆盖需求澄清、规划、测试驱动开发、系统化调试、代码审查和交付。它已经进入 Codex 官方插件目录，安装方法由项目仓库直接维护。
它最适合的不是改一行配置，而是需求仍然模糊、修改跨多个模块、需要分阶段验收的任务。
在 Codex 中，最稳妥的调用方式是自然语言点名需要的工作流。项目 Issue 已专门提醒：Codex 侧主要暴露 Skill，并不保证像其他 Agent 一样提供 /brainstorming 这类斜杠命令。相关说明见 GitHub Issue。
公开数据也提醒我们不要把它写成「自动变强」。一项第三方 A/B 测试使用 500 个 SWE-bench 类任务比较原生 Codex 与 Superpowers：正确率差异没有达到统计显著，平均 provider token 使用量却从约 156 万上升到 218 万。实验作者公开了测试口径和结果。
这不是官方评测，也没有在本文中独立复现，但至少说明一个边界：更完整的流程通常意味着更高的时间和 token 成本。
所以它的正确用法是：复杂功能、棘手故障和长任务启用；简单修改不用为了「仪式完整」强行走全套流程。

CodeRabbit：在提交前引入第二位审查者

GitHub 插件负责仓库协作，CodeRabbit 更专注于代码审查。它可以检查当前 Diff，把发现按严重程度整理，并把可操作问题交回 Codex 修复；修复后还可以再次评审。官方 Codex 集成文档说明了自然语言触发评审的路径。
安装后的直接效果不是「代码一定正确」，而是提交前多出一个结构化反馈回路。对独立开发者而言，它能发现自己和 Codex 可能共享的盲点；对团队而言，它更适合作为人工 Review 前的预筛。
这里有一组值得保留的数据。2026 年一项针对 CodeRabbit 的实证研究分析了 239 个 GitHub 仓库、10,191 个 PR 中的 31,073 对评审与开发者反馈：36.4% 的建议被接受，7.3% 引发讨论，56.3% 被拒绝。拒绝原因包括误报、重复、超出范围和不符合开发者意图。论文摘要与方法见 arXiv:2607.03316。
这项研究观察的是 GitHub 上的 CodeRabbit 评审，不是 Codex 插件单独评测，不能直接换算成插件准确率。但它足以支持一个实际原则：把 AI Review 当作第二意见，而不是合并依据。

Codex Security：安全问题需要专门工作流

普通代码审查会看逻辑、可维护性和测试，安全扫描则需要威胁建模、攻击路径、证据验证和误报处理。Codex Security 正是为这个环节设计的。
官方插件清单显示，它支持扫描代码库或 Diff、分析与验证发现、调查相关产物；默认入口包括全仓扫描、Diff 扫描和已有安全发现的复核。OpenAI 也在官方 X 帖中给出了选择仓库目录并启动扫描的使用路径。
可观察结果应该是一份能定位到文件、代码路径和验证状态的报告，而不是一句「安全性良好」。对于鉴权、支付、文件上传、反序列化、用户数据和密钥处理，建议在发布前单独跑一次。
目前没有找到能证明该插件在所有语言、仓库和漏洞类型上达到某个固定准确率的公开数据。因此它不能替代人工安全审计、依赖扫描、Secret Scanning 和真实测试。

Build Web Apps：让 Web 实现不止停在生成页面

Build Web Apps 适合 React、Next.js 和常见 Web 全栈任务。它与 Vercel 插件不是一回事：前者主要规范本地代码实现与验证，后者连接真实部署平台。
OpenAI 插件仓库列出的 Skill 包括前端应用构建、前端测试与调试、React 最佳实践、shadcn/ui、Stripe 和 Supabase / Postgres。它的目标也明确包含浏览器测试，而不只是生成一批 TSX 文件。
安装后的可观察变化是：任务会更容易形成「读取现有约束 → 实现 → 启动 → 浏览器验证 → 修复」的闭环。它不能保证生成的 UI 自动符合产品需求，也不等于完成可访问性、性能和跨浏览器测试。
没有可靠公开数据证明该插件会让所有 Web 任务提升固定百分比，因此本文不提供效率数字。

Vercel：把本地完成推进到真实 Preview

Vercel 插件适合已经使用 Vercel 部署的项目。它补充的是部署层真实状态：项目配置、Preview、构建结果、运行日志、环境变量、域名和平台文档。
Vercel 在 2026 年 3 月宣布 Codex 与 Codex CLI 支持时，公开说明插件包含 39 个以上平台 Skill 和 3 个专门 Agent；这是能力数量，不是性能提升数据。Vercel Changelog可以核对这一版本说明。当前 Vercel MCP 文档则列出项目、部署、团队和 Web Analytics 等查询能力。
可观察效果很直接：最终应该得到一个对应当前提交的 Preview，以及构建状态和验证结果；失败时应返回真实日志证据，而不是让你手动复制 Vercel 控制台内容。
注意，Vercel 插件本身覆盖面很大。只做一个简单静态站时，不一定需要全部 Skill 长期可见；不用 Vercel 的项目则完全没有安装必要。

Sentry：让 Codex 看到真实线上错误

代码在本地和 CI 里通过，不代表生产环境不会出错。Sentry 插件把线上 Issue、错误事件、Trace 和监控配置带进 Codex 的排查过程。
Sentry 官方 Agent Plugin 文档说明，该插件可以完成 SDK 接入、查找和修复生产问题、配置监控；它支持 Codex 等多种编码 Agent。Sentry 的公开仓库还给出了 Next.js、Rails、iOS 等不同技术栈的接入示例，以及查询最近错误和修复 Sentry Issue 的提示词。功能清单可见 getsentry/sentry-for-ai。
安装后的可观察变化是：排查起点从「用户说页面崩了」变成具体错误事件、版本、调用链和代码位置。它仍然依赖项目正确接入 Sentry；没有采集到的数据，插件无法凭空补齐。
公开资料没有给出「安装 Codex 插件后平均修复时间下降多少」的可复核数据，所以本文只确认它能接通哪些证据，不推导修复速度。

Figma：减少设计稿到代码之间的信息损失

Figma 插件适合已经有 Figma Frame、组件或设计系统的项目。它与「把截图丢给模型」的区别是可以读取结构化设计上下文，并配合 Code Connect 和项目规则保持组件映射。
OpenAI 插件仓库中的 Figma 说明列出 Design to Code、设计上下文与截图检查、Code Connect 模板、设计系统规则、创建和更新 Figma 页面等能力。
可观察效果是：Codex 能引用真实设计节点、组件和截图，并在实现后做视觉对照。它不能替代设计决策；缺失的移动端状态、交互说明和无障碍要求仍需要产品或设计人员补充。
本文没有找到 Figma 插件对设计还原度的公开统一评测，因此不写「还原度提升多少」。

OpenAI Developers：构建 OpenAI 应用时减少过时 API 猜测

如果项目使用 OpenAI API、Responses API、Agents SDK 或 ChatGPT Apps，OpenAI Developers 插件值得常驻。它的价值不是让模型「更懂 AI」，而是把当前官方文档、API Key 配置、Agents SDK 工作流和常见 API 错误排查放在一起。
OpenAI Developers 插件官方页面列出四类主要能力：连接 OpenAI API Platform、处理 API Key 配置、构建和部署 Agents SDK 应用，以及诊断常见 API 错误。官方还明确要求在第一次安装后新建会话。
可观察效果是：回答和修改能够引用当前官方文档，并在真正运行 API 前经过 Key 配置检查。它只对 OpenAI 平台项目有价值；普通后端、游戏逻辑或本地工具没有必要为了「可能用到」而安装。
目前没有公开数据能把该插件与 API 错误率下降直接建立因果关系，因此本文只确认工作流变化。

为什么没有把所有热门工具都列进来

搜索 GitHub、X、CSDN、掘金和博客园时，经常还能看到 Context7、各种 Skill Pack、MCP 管理器、CircleCI、Expo、Game Studio 等名字。没有进入前 9，不等于它们没有价值，而是本文采用了更窄的开发者通用链路。
  • Context7 常以独立 MCP Server 形式接入，本文不把 MCP 单独冒充正式 Plugin。
  • CircleCI 只适合真实使用 CircleCI 的项目；GitHub Actions 用户先用 GitHub 插件即可。
  • Expo 对 Expo / React Native 项目很有价值，但不是通用移动开发插件。
这也是「按技术栈选装」比「照榜单全装」更可靠的原因。

安装方法与最小组合

Codex 桌面端和 CLI 的安装流程很短。

Codex 桌面端

  1. 打开 Codex。
  1. 进入 Plugins。
  1. 搜索插件名称并选择安装。
  1. 需要外部服务时完成 OAuth 授权。
  1. 新建一个会话再使用。

Codex CLI

在 Codex TUI 中输入：
搜索并安装插件，然后退出当前会话并启动新会话。不要把 Claude Code 的 /plugin install 命令直接照搬到 Codex；不同产品的插件命令并不相同。
建议从下面的最小组合开始：
项目类型
建议组合
GitHub 上的个人项目
GitHub + CodeRabbit；发布前临时加 Codex Security
React / Next.js + Vercel
GitHub + Build Web Apps + Vercel；上线后加 Sentry
有完整设计稿的前端项目
GitHub + Figma + Build Web Apps
OpenAI API / Agent 项目
GitHub + OpenAI Developers + Codex Security
复杂、多模块长期任务
在原组合上按需启用 Superpowers
安装后不要急着问「插件有没有生效」。用一个可验证请求测试它是否读到了真实对象，例如指定 PR 编号、Vercel Deployment、Sentry Issue 或 Figma Frame，并要求返回对象标识、状态和证据。

插件不是越多越好

插件会增加 Skill、工具和权限面。OpenAI 官方文档特别提醒，插件可能包含在生命周期节点运行的 Hook，启用前应该审查并信任这些命令。插件组成与 Hook 风险见官方说明。
社区已经报告了两个实际问题：
  • 部分 Windows、账户或地区环境曾出现 /plugins 为空，或者安装结果重启后丢失。复现见 #24736和#29103。
遇到插件不显示时，先确认自己使用的是支持插件的界面，更新 Codex、重新登录、检查工作区管理员限制，并在安装后新建会话。不要在没有弄清来源的情况下，直接复制网络上的配置去覆盖 config.toml。
权限方面也遵守最小化原则：
  • 只授权任务需要的仓库、组织和服务。
  • 先读、后写；外部发送、合并、部署和删除都要求明确确认。
  • 不在提示词、日志或仓库中粘贴 Token、PAT 和 API Key。
  • 定期禁用已经不用的插件，减少上下文和权限面。

最终建议

开发者真正值得安装的插件，通常符合两个条件之一：让 Codex 读取真实外部上下文，或者让它在关键节点执行一套可复用的工程检查。
如果只选两个，代码在 GitHub 的开发者可以先装 GitHub，再从 CodeRabbit 或 Codex Security 中选择一个。如果是 Web 项目，再按实际平台加入 Build Web Apps、Vercel、Sentry 和 Figma；构建 OpenAI 应用时加入 OpenAI Developers；只有任务足够复杂时，再让 Superpowers 接管完整流程。
插件不会自动把 Codex 变成更资深的工程师，它能做的是减少上下文搬运、补上固定检查点，并让结果更容易验证。选得少、用得准，比把插件目录装满更有价值。