Codex 好用的插件和 Skill 推荐
约 1985 字大约 7 分钟
AIOpenAICodexMCP
2026-04-09
先装这几个插件 / MCP
1. OpenAI Docs MCP
这是我认为 Codex 用户最该先装的一个。
适合场景：
- 查 Codex、OpenAI API、ChatGPT Apps SDK 的最新官方文档
- 避免模型凭旧记忆回答过期配置
- 写 API 接入、升级模型、查参数时直接把官方文档拉进上下文
为什么推荐：
- OpenAI 官方提供，信息源最干净
- 只读文档型 MCP，风险低
- 很适合作为
AGENTS.md里的默认规则
官方添加方式：
codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp如果你经常写 OpenAI 相关代码，这个几乎是必装。
2. Context7
如果 OpenAI Docs MCP 解决的是“OpenAI 自家文档”，那 Context7 解决的就是“第三方库文档过期”。
适合场景：
- React / Next.js / Tailwind / Supabase / Prisma 这类更新快的生态
- 你不想让 Codex 按旧版本 API 写代码
- 你希望 agent 直接带着版本相关文档来生成代码
为什么推荐：
- 它的定位非常清楚，就是给 agent 喂最新、版本相关的代码文档
- 既能走 MCP，也能走 CLI + Skill
- 对“框架升级”“新库接入”“脚手架初始化”特别有价值
官方给出的最省事安装方式：
npx ctx7 setup使用建议：
- 小项目：先装默认模式就够
- 经常写前端 / 全栈：非常值得常驻
- 涉及安全或支付链路时，不要盲信返回内容，仍然要回到官方文档复核
3. GitHub MCP Server
如果你的真实工作不是“本地玩玩”，而是要看 issue、PR、Actions、review comment，那 GitHub MCP 很快就会变成高频工具。
适合场景：
- 让 Codex 直接读 issue / PR 上下文
- 查 CI 失败、看 workflow 状态
- 做 review、补评论、联动仓库信息
为什么推荐：
- GitHub 官方维护
- 不只是“读代码”，还可以把仓库协作上下文一起接进来
- 对 review、缺陷定位、发布前排查很有帮助
我的建议不是“默认开全权限”，而是：
- 先只开只读或最小 toolset
- 明确 token 权限范围
- 真的需要写 issue / PR 时再扩权
这类服务器能力强，但权限也大，适合放在第二批安装。
4. Playwright MCP
如果你经常让 Codex 改页面、修前端、验证交互，Playwright MCP 的价值非常直接。
适合场景：
- 页面流程测试
- 表单填写、按钮点击、导航跳转
- 让 agent 在浏览器里做结构化验证，而不是只靠猜
为什么推荐：
- Microsoft 维护，成熟度高
- 不靠截图理解页面，而是基于可访问性树做结构化操作
- 对“改 UI 后顺手验一遍”特别实用
官方给出的 Codex 添加方式：
codex mcp add playwright npx "@playwright/mcp@latest"如果你主要做后端，可以后装；如果你常改前端，它基本属于必装。
5. Serena（可选增强）
Serena 不是“先装最好”的那种，而是“大仓库越用越香”的那种。
适合场景：
- 仓库很大，靠全文搜索找上下文越来越慢
- 你希望 agent 按符号级别去找定义、引用、结构关系
- 多语言、多模块、长期维护项目
为什么推荐：
- 它强调语义级检索和编辑，而不是纯文本 grep
- 对复杂代码库，能减少 agent 到处乱读文件的成本
- 特别适合重构、跨文件定位、符号级修改
但我不把它放第一梯队，原因也很简单：
- 配置成本比前几个高
- 某些语言还要额外准备对应语言服务
- 小仓库里未必能马上感受到明显收益
一句话判断：仓库越大、语言越多、上下文越乱，越值得装 Serena。
Skill 我推荐先留这些
这里的 Skill，我更建议理解为“稳定工作流模板”，而不是“提示词收藏夹”。
下面提到的 Skill 名称，基于我当前使用的 Codex + oh-my-codex 环境；如果你本地没有完全同名的 Skill，也可以按同样思路自己做一套。
1. create-kb-article
如果你经常让 Codex 写知识库、博客、技术调研，这是最值的 Skill 之一。
它解决的不是“帮你生成一篇 Markdown”，而是：
- 自动落到正确目录
- 镜像同目录 frontmatter 和 permalink 风格
- 检查是否要补导航
- 让输出直接变成仓库内可维护页面
对内容型仓库，这种 Skill 的价值比通用写作 prompt 高很多。
2. code-review
这个 Skill 适合高频 review 场景，尤其是你不想每次都重新解释“先找风险，不要先讲总结”。
它适合：
- 审当前工作区 diff
- 审最新 commit
- 快速扫一轮回归风险、逻辑问题、缺失测试
如果你的团队已经形成固定 review 口径，最好把它固化成 Skill，而不是每次重新口述。
3. security-review
安全审查不应该每次都靠“顺便看看”。
这个 Skill 适合：
- 权限边界检查
- token / secret 暴露检查
- 外部输入、命令执行、文件写入路径检查
- MCP、插件、自动化流程的边界复核
尤其在你已经开始接 GitHub MCP、数据库 MCP、浏览器自动化之后，安全 review 的价值会明显上升。
4. deep-interview 或 plan
很多失败不是因为 Codex 执行差，而是因为需求一开始就没问清楚。
这类 Skill 适合：
- 用户只给一句模糊目标
- 需求边界不清
- 方案分叉很多，贸然开工容易返工
经验上看：
- 需求非常糊的时候，用
deep-interview - 需求已经比较清楚，只差执行计划时，用
plan
它们本质上是“防止错误开工”的前置保险。
5. note 和 trace
这两个不是“看起来最炫”的 Skill，但很实用。
note 适合：
- 保存阶段性结论
- 把中途确认过的约束写下来
- 降低长会话压缩后的信息丢失
trace 适合：
- 回看 agent 是怎么走到这个结果的
- 复盘多 agent 流程
- 调整某个 workflow 为什么总跑偏
如果你已经开始依赖更长、更复杂的 agent 流程，这两个 Skill 非常值得留下。
我的安装顺序建议
如果你想少走弯路，建议按这个顺序来：
- 先装 OpenAI Docs MCP
- 再装 Context7
- 做 GitHub 协作多，再补 GitHub MCP
- 常做前端，再补 Playwright MCP
- 仓库很大时，再考虑 Serena
- Skill 方面先固化你最高频的 3 到 5 个动作，不要一上来堆满
一个很好用的组合是：
- 文档查找：OpenAI Docs MCP + Context7
- 仓库协作：GitHub MCP
- 前端验证：Playwright MCP
- 固定工作流：
code-review+create-kb-article+deep-interview
装这些东西时要注意什么
最后补三条很重要的原则：
- 优先只读、最小权限。 GitHub、数据库、浏览器、文件系统类插件不要默认开大权限。
- 优先官方源，其次头部项目。 OpenAI Docs MCP、GitHub MCP、Playwright MCP 这种来源更稳；社区项目像 Context7、Serena 很强，但也要看维护质量和权限边界。
- 不要把 Skill 写成大而全万能 Prompt。 好 Skill 应该解决一个稳定场景，比如 code review、写知识库、做安全审计，而不是“一切都能干”。
总结
如果你只想记一句话，我的建议是：
Codex 的增强优先级不是“多装”，而是“先把文档、协作、验证、工作流四层补齐”。
先把 OpenAI Docs MCP、Context7、GitHub MCP、Playwright MCP 这几层搭起来，再把常用动作做成 Skill，Codex 才会从“会写代码的聊天框”真正变成“能稳定交付的 agent”。