夜雨聆风"如果你觉得 Codex 用起来'还行但总差一口气'，大部分原因不是它不够聪明，而是你没有给它配插件。"
插件就是给 Codex 装「腿」
Codex 本身很聪明，但有个硬伤：它出生在一个信息孤岛里。
你的代码在 GitHub，设计稿在 Figma，最新信息在浏览器网页里。Codex 什么都不知道，只能靠你一条一条搬过来喂给它。
装了插件，就不一样了。
插件是 Codex 的腿和手。GitHub 插件让它能直接进你的仓库；Figma 插件让它能直接读设计稿；context7 插件让它获取最新版本的库文档和代码示例，自动注入到Codex的上下文中。
你只需要说需求，它自己去取信息、自己干活。
搞清楚 Codex 插件是指什么？
插件其实是Codex的能力扩展方式，主要有3种：MCP、Skill、Plugin。
MCP（模型上下文协议）：让 Codex 连接外部工具的"接口标准"。比如连 GitHub、数据库、搜索引擎。配好之后 Codex 就不只看你代码了，它能直接去读这些外部数据源。
Skills（技能）：封装好的工作流模板。比如"生成单元测试"的标准流程。你或社区其他人写好一个 SKILL.md 文件，定义"遇到某类任务该怎么做"，Codex 就会自动按这个流程执行。可以理解为"经验封装成了可复用工具"。
Plugin（内置插件）：Codex 自带的功能模块。比如 Computer Use（接管桌面）、Browser Use（控制浏览器）、Presentations（生成 PPT）、Spreadsheets（处理表格）。在对话框里输入 @ 就能看到可用的插件列表，选择即可调用。
简单说：Plugin 给你能力，Skills 给你经验，MCP 给你数据。
本文说的"插件"，主要指 MCP 连接和 Skills ——因为它们最能直接扩展 Codex 的能力边界。
为什么必装？一句话：裸装的 Codex 只能操作本地文件和跑终端命令。装了插件之后，它能连 GitHub、查实时文档、操作浏览器、记住你的偏好。是Codex 从"能用"到"好用"的必经之路
必装插件详解
1. GitHub MCP
为什么必装：
不用 GitHub MCP 的时候，你跟 Codex 说"帮我看一下这个 PR"，它只会说"你把内容贴给我"。你得手动复制 Issue 描述、PR diff、文件变更——你自己成了人肉 API。
装了之后，Codex 可以直接读 Issue、查 PR、分析 commit 历史、甚至帮你提 PR。
安装方式（Codex CLI）：
codex mcp add --env GITHUB_TOKEN=你的Token\ github -- npx -y @modelcontextprotocol/server-githubGitHub Token 获取：GitHub → Settings → Developer settings → Personal access tokens → 生成一个带 repo 权限的 token。
或在 ~/.codex/config.toml 里手动配置：
[mcp_servers.github]command = "npx"args = ["-y", "@modelcontextprotocol/server-github"][mcp_servers.github.env]GITHUB_TOKEN = "你的token"实测场景：
> "帮我审查 PR #231：检查有没有安全问题、性能隐患、代码规范问题。输出 Markdown 格式的 review。"Codex 自动拉取 PR 的所有 diff，逐个文件分析，输出了一份结构清晰的审查报告。连"第 73 行变量命名不规范"这种细节都标出来了。
前后对比：
2. Context7（实时文档注入）
是什么：自动获取最新版本的库文档和代码示例，注入到Codex的上下文中。
解决什么问题：Codex的训练数据有截止日期，它可能用过时的API、错误的参数、已经被废弃的函数。最可怕的是，它对此非常自信，你根本看不出来它错了。
为什么要装：这个Skill让Codex在写代码前先查最新文档，确保用的是当前版本的正确API。它解决了AI编码最大的隐患："一本正经地胡说八道"。
安装前后对比：
实例：
小明要用Next.js 15的新特性写中间件。
没装Context7时：
小明："帮我写一个Next.js中间件，实现路由守卫。" Codex：自信地写了一段代码，用了
middleware.ts和NextResponse.redirect，但用的是Next.js 14的写法。小明跑起来，发现中间件不生效，报错"matcher配置错误"。 小明去查文档，发现Next.js 15改了matcher的语法。花了45分钟排查，最后手动改对。
装了Context7后：
小明："帮我写一个Next.js 15中间件，实现路由守卫，用context7查最新文档。" Codex：调用Context7 → 获取Next.js 15最新middleware文档 → 确认matcher新语法 → 生成完全符合v15规范的代码 → 附带最新示例和注意事项。 一次跑通，零报错。
安装方式（MCP配置）：
codex mcp add context7 \ -- npx -y @upstash/context7-mcp@latest3. playwright（操作浏览器）
是什么：让Codex能直接操作真实浏览器，点击按钮、填写表单、验证页面反馈。
解决什么问题：前端开发最痛苦的不是写代码，是写完了要手动测试。打开浏览器、输入地址、登录、点按钮、看结果——这些重复劳动占了你50%的时间。
为什么要装：装完之后，Codex能自动完成端到端的网页交互验证。你写完代码，它自己打开浏览器跑一遍，告诉你哪里崩了、哪里样式不对。
安装前后对比：
实例：
小明写了一个电商后台的"商品上架"功能。
没装playwright时：
小明写完了代码，自己打开浏览器，登录后台，找到商品管理，点击"上架"，填写信息，提交。发现提交后页面没跳转，返回去改代码。再手动测试，发现图片上传后没预览，再改。再测试，发现价格校验逻辑错了……来来回回6次，花了1个半小时。
装了playwright后：
小明："帮我写商品上架功能，然后用playwright-interactive跑一遍完整流程，确认上架成功且页面正常跳转。" Codex：写代码 → 自动打开浏览器 → 自动登录 → 自动点击上架 → 自动填写测试数据 → 自动提交 → 验证跳转和提示信息。 全程自动，15分钟搞定，小明在旁边喝咖啡。
安装命令：
codex mcp add playwright \ -- npx -y @playwright/mcp@latestnpx skills add openai/skills@playwright-interactive -g -y4. figma-implement-design（Figma设计稿转代码）
是什么：直接读取Figma设计文件，提取设计信息、下载资源、映射设计token，生成生产级前端代码。
解决什么问题：设计师给了Figma稿，你对着它一行行写CSS，量间距、取色值、切图片——这是前端开发最枯燥的部分，占了你30%的时间。
为什么要装：这个Skill让Codex直接"看懂"Figma稿，自动提取样式、生成代码、下载图片资源。你拿到设计稿，一句话就能开始写页面。
安装前后对比：
实例：
设计师给小明一个登录页面的Figma稿，包含Logo、表单、按钮、背景图。
没装figma-implement-design时：
小明打开Figma，放大到100%，开始量：
输入框高度48px，圆角8px，边框颜色#E5E7EB 按钮主色#4F46E5，hover色#4338CA 背景图分辨率1920x1080 手动写HTML/CSS，复制色值，下载图片。写了1小时，最后发现有个间距量错了，按钮偏了2px。
装了figma-implement-design后：
小明："按这个Figma链接实现登录页面：figma.com/file/xxx，用figma-implement-design。" Codex：读取Figma文件 → 提取所有图层信息 → 下载Logo和背景图 → 映射设计token → 生成React组件 → 自动截图比对Figma和实现效果 → 标记1处差异并修复。 25分钟搞定，设计师说"还原度很高"。
安装命令：
npx skills add openai/skills@figma-implement-design -g -y5. Memory MCP
为什么必装：
这个很多人不知道——Codex 的默认行为是每次新会话都从零开始。你上次花了半小时跟它解释项目背景，关了终端重开，它就"失忆"了。
Memory MCP 解决的就是这个。它基于 SQLite + 知识图谱，每次会话结束时自动存关键信息，下次会话自动召回。不需要外部数据库。
安装方式：
codex mcp add --env MEMORY_FILE_PATH=./.codex/memory.json \ memory -- npx -y @modelcontextprotocol/server-memory实测场景：
第一次会话：
> "记住：我的项目 PostgreSQL 连接串是 postgresql://admin:xxx@localhost:5432/myapp。 代码规范：函数名用驼峰，组件名用帕斯卡。测试用 pytest。"开新会话后：
> "我之前跟你说的数据库连接串是什么？测试用什么框架？"Codex 直接从 Memory MCP 召回之前存的信息。不用重新解释。
前后对比：
6. Superpowers（结构化Agent工作流）
是什么：给Codex加一套完整的工程化工作流，包括需求澄清、计划审批、TDD实现、并行子Agent执行、验证闭环。
解决什么问题：Codex默认行为像个"热血青年"——拿到任务就开始写，写到一半发现理解错了，或者同时改6个文件互相冲突，或者写了测试没运行就提交。这个Skill给它套上"工程师规范"。
为什么要装：它是目前GitHub上最火的AI编码工作流Skill，强调TDD、YAGNI、DRY原则。装完之后，Codex会：先澄清需求 → 再出计划 → 你确认 → 按TDD写测试 → 再写实现 → 自动验证 → 审查代码质量。
安装前后对比：
实例：
小明要实现一个"优惠券计算"功能。
没装Superpowers时：
小明："帮我写优惠券计算功能。" Codex：直接写了一个函数，支持满减和折扣。小明测试发现：满减和折扣叠加时逻辑错了，边界条件（金额为0、负数）没处理，重复代码没提取。回炉重造。
装了Superpowers后：
小明："帮我写优惠券计算功能，用superpowers工作流。" Codex：
需求澄清："确认一下：支持哪些券类型？能否叠加？边界条件是什么？" 计划输出：Step 1 写测试用例（满减、折扣、叠加、边界）→ Step 2 写核心计算逻辑 → Step 3 写校验层 → Step 4 集成验证 TDD执行：先写8个测试用例（全部失败）→ 再写实现（让测试通过）→ 重构优化 自动验证：运行全部测试，覆盖率100%，边界全覆盖 代码审查：检查命名、复杂度、重复逻辑，自动优化 小明审核后一键提交，代码质量直接达到团队标准。
安装命令：
# 在Codex CLI中/plugins# 切换到 Add Marketplace 输入 obra/superpowers# 安装市场成功后，再继续安装superpowers skill7. create-plan（任务拆解与计划）
是什么：强制Codex在动手写代码之前，先输出一份可执行的任务计划。
解决什么问题：很多人用Codex写代码，上来就说"帮我改这个功能"，结果Codex一上来就改文件，改到一半发现依赖没理清、文件漏改了、逻辑自相矛盾，最后越改越乱，你还得手动收拾残局。
为什么要装：这个Skill让Codex养成"先想后做"的习惯。它会先分析需求、拆解步骤、识别依赖关系、评估风险，给你一份清晰的计划，等你确认后再执行。
安装前后对比：
实例：
小明要做一个"订单退款"功能，涉及前端页面、后端接口、数据库表三个部分。
没装create-plan时：
小明："帮我做订单退款功能。" Codex：直接开始写前端代码，写了一半发现需要后端接口，又去写接口，接口写完了发现数据库字段没加，回头补字段，最后前端和后端对不上，报错一堆。
装了create-plan后：
小明："帮我做订单退款功能，先用create-plan规划。" Codex：输出计划——
数据库：添加refund_status字段 后端：新增/refund接口，处理退款逻辑 前端：添加退款按钮和状态展示 测试：验证退款流程端到端 小明确认后，Codex按步骤执行，每步完成自动验证，40分钟搞定，零bug。
安装命令：
npx skills add openai/skills@create-plan -g -y8. gh-address-comments（PR评论自动处理）
是什么：自动读取GitHub PR的review评论，汇总需要修改的点，逐条处理。
解决什么问题：PR被review了，评论分散在多个文件、多个行，你得一条条看、一条条改、一条条回复。这个过程机械、重复、容易漏。
为什么要装：装了这个，Codex自动帮你汇总所有评论、分类优先级、逐条修改、生成回复。你只需审核，不用手动改。
安装前后对比：
实例：
小明的PR被导师review了，留了12条评论。
没装gh-address-comments时：
小明打开PR页面，逐条看评论：
"这里变量命名不清晰" → 找到文件 → 改名 → 回复"已修改" "缺少边界条件处理" → 找到文件 → 补逻辑 → 回复"已补充" "这个函数太长，建议拆分" → 找到文件 → 重构 → 回复"已拆分" ……12条评论，花了1小时，眼睛都看花了。
装了gh-address-comments后：
小明："帮我处理PR #42的评论。" Codex：读取12条评论 → 汇总为3类：命名问题（4条）、逻辑问题（5条）、架构问题（3条） → 逐条定位代码 → 自动修改 → 生成回复摘要 → 小明审核后一键提交。 20分钟搞定，零遗漏。
安装命令：
npx skills add openai/skills@gh-address-comments -g -y9. frontend-skill（前端UI生成增强）
是什么：将设计规范和组件样式编码到Skill中，让Codex生成更精致、更符合设计系统的前端界面。
解决什么问题：Codex默认生成的前端代码，能跑，但丑。间距随机、颜色乱配、组件风格不统一，一看就是"AI生成的"。
为什么要装：这个Skill相当于给Codex发了一本"设计规范手册"，告诉它：我们项目用Tailwind、主色是蓝色、按钮圆角8px、间距用4的倍数。生成出来的代码直接符合团队规范。
安装前后对比：
实例：
小明要做一个用户管理后台的表格页面。
没装frontend-skill时：
小明："帮我写个用户管理表格。" Codex：生成了一个表格，但用了默认的灰色边框、蓝色链接、无间距的紧凑布局。小明看了直摇头："这不像我们项目的风格。" 手动改：调颜色、加padding、换字体、统一按钮样式……花了40分钟。
装了frontend-skill后：
小明："帮我写个用户管理表格，使用frontend-skill规范。" Codex：读取设计系统 → 生成表格：主色indigo-600、圆角lg、间距4的倍数、按钮用项目统一组件、表格带hover效果。 小明看了一眼："这就对了。"直接提交。
安装命令：
npx skills add openai/skills@frontend-skill -g -y10. webapp-testing（自动化Web测试）
是什么：自动检测项目的测试框架，生成符合项目风格的测试用例，运行测试并输出报告。
解决什么问题：AI写代码最容易制造的错觉就是"看起来写完了"，但跑过没有？测过没有？改这一处，会不会把别的地方带崩？
为什么要装：这个Skill不是帮你多生成一点代码，而是帮你确认这次改动到底是不是真的能用。它自动检测你项目用Jest还是Vitest还是Pytest，生成风格一致的测试，跑完给你报告。
安装前后对比：
实例：
小明改了一个用户注册的接口，加了手机号格式校验。
没装webapp-testing时：
小明："帮我改一下注册接口，加上手机号格式校验。" Codex：改了接口代码。小明觉得"应该没问题"，没写测试，直接提交。 一周后，用户反馈：邮箱注册时提示"手机号格式错误"。原来Codex改校验逻辑时，把邮箱注册的流程也影响了。线上bug，紧急修复。
装了webapp-testing后：
小明："帮我改注册接口，加手机号校验，然后用webapp-testing补测试并验证。" Codex：改接口 → 自动生成测试：手机号格式正确/错误/为空、邮箱注册不受影响、已有用户不受影响 → 运行全部测试 → 发现1个回归问题：邮箱注册被误拦截 → 自动修复 → 重新运行 → 全部通过。 小明放心提交，零线上bug。
安装命令：
npx skills add openai/skills@webapp-testing -g -y要避开的坑
坑1：无脑装一堆，反而更乱
Skill装太多会触发"技能冲突"——多个Skill都觉得自己适合当前任务，Codex就懵了。而且每个Skill都会往上下文里塞规则，装多了会污染上下文，效果反而变差。
建议：先装必要的，再根据不同的业务场景选择其它专用Skill。
坑2：从GitHub随便装Skill，不看内容
Skill本质是让Codex执行你电脑上的命令。如果Skill里有恶意脚本，它真的会执行。
建议：从官方仓库（github.com/openai/skills）或可信社区（如Composio的awesome-codex-skills）安装，装之前先看 SKILL.md 内容确认安全。
坑3：API Key 写死在配置文件里面
# 正确：用环境变量env.GITHUB_PERSONAL_ACCESS_TOKEN = "${GITHUB_TOKEN}"# 错误：明文写在配置文件里# env.GITHUB_PERSONAL_ACCESS_TOKEN = "ghp_abc123..."坑4：没给Codex足够的构建和测试信息
Codex需要知道怎么跑你的项目（比如 npm run build、pytest），否则它改完代码没法自验证。
建议：在项目根目录的 AGENTS.md 里写清楚构建和测试命令。
坑5：Context7 查到的文档跟你用的版本对不上
Context7 默认查最新文档，但你的项目可能用的是旧版本。版本不一致会导致 API 不兼容。
建议： 明确告诉 Codex 你用的版本号，比如"用 Context7 查 React 18（不是 19）的 forwardRef 用法"。总结
开发本质上是信息流转——需求、设计、代码、测试、部署、运维，这些信息在不同的工具之间流动。
以前靠开发者人肉搬运，现在插件帮 Codex 接进了每一个节点。
搬运信息这件事，让 AI 来做。你来做判断和决策。
这就是 Codex 插件真正想解决的问题。
