夜雨聆风
Codex 装好以后就能改代码，但“能改代码”和“能稳定完成工作”之间，还隔着插件、Skills、MCP、项目规则和验收闭环。本文不追求把插件市场装满，而是给你一套从轻到重、可以直接照抄的配置思路。
第一次打开 Codex，很多人的使用方式都差不多：
帮我看看这个报错。
帮我改一下这个页面。
帮我写几个测试。
它当然能做，但体验很容易忽高忽低。
原因并不神秘。一个刚加入团队的工程师，如果既不知道项目规范，也看不到 GitHub 上的 Issue，打不开真实页面，还不知道“做到什么程度才算完成”，表现同样不会稳定。
插件和 MCP 的价值，就是把这些缺失的手、眼睛和资料补上；Skill 和 AGENTS.md 的价值，则是把你的做事方法和项目规则交给 Codex。
先给结论：不要问“有哪些插件能装”，要问“我的工作流缺哪一环”。
一、先把四个概念分清楚
Codex 里最容易混淆的是 Plugin、Skill、MCP 和 AGENTS.md。可以用一家小公司来理解：
AGENTS.md | ||
举个例子：
“这个项目只用 pnpm，改完必须跑类型检查”——写进 AGENTS.md；“每次做代码审查都先看需求，再按严重程度输出问题”——做成 Skill； “读取 GitHub PR 和 CI 结果”——交给 GitHub 连接器或 MCP； “把审查流程、GitHub 能力和安全检查一起安装”——适合做成 Plugin。
这四层各管一件事。把所有要求都塞进一条超长提示词，短期能用，长期一定会乱。
二、插件和 MCP 到底怎么装
在桌面端，进入 Codex 后打开 Plugins，搜索插件并点击加号安装；需要连接外部服务时，按提示完成授权。安装完成后要新建一个聊天，插件里包含的 Skills 和工具才会进入新会话。
在 Codex CLI 中输入：
/plugins
即可打开插件浏览器，查看不同 Marketplace、安装或卸载插件，并用空格启用或停用。安装后同样建议启动新的 CLI 会话。
如果你配置的是独立 MCP，可以在桌面端进入 Settings → MCP servers → Add server，也可以使用 CLI：
# 查看已配置服务
codex mcp list
# 添加远程 HTTP MCP
codex mcp add <name> --url <server-url>
# 添加本地 STDIO MCP
codex mcp add <name> -- <command> <args>
目前插件目录主要面向桌面端和 Codex CLI；IDE 扩展不能直接浏览安装插件，但可以使用同一 Codex Host 上配置的 MCP 服务。具体入口仍以你的客户端版本与工作区策略为准。
三、我建议优先配置的 6 类能力
插件目录和可用能力会随账号、客户端、工作区策略变化，下面不是“必须全部安装”的榜单，而是一张按场景选择的装机清单。
1. Browser：先让 Codex 能看见真实页面
这是我最建议前端、全栈和独立开发者优先配置的能力。
Codex 写完页面，如果只能告诉你“理论上应该可以”，闭环还没有完成。Browser 能让它打开页面、检查元素、走一遍操作流程、读取控制台错误，再验证修改是否生效。
适合它做的事：
复现登录、注册、表单提交等流程； 检查响应式布局和交互状态； 修改代码后刷新页面做回归验证； 收集页面文本、DOM 状态与控制台错误； 研究公开网页并整理资料。
可以这样提示：
修复设置页保存后刷新丢失的问题。
先用浏览器复现，再检查相关代码；修复后重新走一遍相同流程。
不要只根据代码推测已修复，最后报告实际验证结果。
一句话：Browser 不是为了炫耀“AI 会点按钮”，而是为了补齐验证。
2. Chrome：需要登录态时再装
Browser 更适合相对独立、可控的网页任务；Chrome 类能力的优势，是能利用你现有浏览器中的登录状态、标签页和扩展环境。
例如：
查看登录后的内部管理后台； 操作必须依赖 Chrome 扩展的网站； 在你已经打开的页面上继续工作。
但登录态也意味着更高的隐私和误操作风险。建议只在确实需要时启用，并明确边界：
可以读取当前页面并整理信息，但不要发送消息、提交表单、删除内容或修改权限。
3. GitHub：把“写代码”升级为“完成研发协作”
只读取本地仓库，Codex 看到的是代码；接入 GitHub 后，它才能把 Issue、PR、Review 评论和 CI 状态串起来。
典型用法包括：
根据 Issue 定位相关代码； 总结 PR 的改动与潜在风险； 查看失败的 Actions/Checks； 根据 Review 意见准备修复； 草拟 PR 描述和发布说明。
推荐提示词：
读取这个 PR 的需求、改动文件、Review 评论和 CI 结果。
先列出仍未解决的问题，再检查本地实现。
只准备修改和回复草稿，不要替我合并、发布或发送评论。
这里最重要的技巧是：把“读”和“写”分开授权。先允许它收集与分析，真正发布评论、合并 PR 时再确认。
4. OpenAI Docs / Context7：给代码建议接上“实时地基”
模型记忆不是最新文档。遇到 API 参数、框架新版本、弃用项和迁移问题时，让 Codex 读取当前文档，比让它凭印象回答可靠得多。
OpenAI 官方文档给出的常见 MCP 示例中，就包括 OpenAI Docs MCP 和 Context7。前者适合查询 OpenAI 产品与 API，后者适合读取较新的开发文档。
例如安装 Context7：
codex mcp add context7 -- npx -y @upstash/context7-mcp
之后可以这样问：
用 Context7 核对 Next.js 当前版本关于缓存失效的官方说明，
再检查这个项目的写法是否已经过时。请附来源，不要只给通用建议。
5. Documents / PDF / Spreadsheets / Presentations：让结果直接成为文件
如果你的工作不只有写代码，这组能力的投入产出比非常高。
Documents：生成或编辑 Word 文档、说明书和报告； PDF：提取、检查、创建或填写 PDF； Spreadsheets：分析表格、生成公式和图表、交付 .xlsx；Presentations：把材料整理成真正可编辑的演示稿。
它们与普通聊天最大的区别是：不止给你一段“可以复制的内容”，而是产出可继续编辑的文件，并进行格式和视觉检查。
提示时要说明最终用途：
把这份技术调研整理成 8 页汇报 PPT，面向非技术管理者。
结论和决策放前面，每页只表达一个重点；生成可编辑的 PPTX，
并检查文字是否溢出、图表是否清晰、前后数据是否一致。
6. Computer Use 与安全插件：一个补“最后一公里”，一个补“第二双眼睛”
有些系统没有 API、没有 MCP，只能通过桌面界面操作。这时 Computer Use 可以完成跨应用的最后一公里，例如把数据从旧系统录入桌面软件、检查本地应用状态等。
不过它不适合成为默认入口。能用结构化 API、连接器或 CLI 完成的任务，优先使用结构化工具；桌面点击更容易受到弹窗、布局变化和误操作影响。
另一类值得团队考虑的是 Codex Security 等安全能力。它适合对授权代码做安全扫描、验证疑似漏洞，再准备经过复核的修复。注意：安全插件是辅助审查，不是“装完就绝对安全”的认证章。
四、不要装成“插件杂货铺”：三套组合就够了
组合 A：日常开发基础版
Browser + GitHub + 一个文档 MCP
适合绝大多数开发者。它覆盖需求来源、代码修改、真实页面验证和最新文档查询。
组合 B：内容与办公交付版
Browser + Documents/PDF + Spreadsheets + Presentations
适合产品、运营、咨询、教师和经常写方案的开发者。重点是把信息变成可以直接交付的文档，而不只是聊天内容。
组合 C：团队研发增强版
GitHub + Browser/Chrome + 文档 MCP + Security + 团队自定义 Skill
适合有固定研发规范的团队。插件负责工具，Skill 固化流程，AGENTS.md 固化仓库规则。
我的建议是：每次只新增一种能力，完成一个真实任务后再装下一个。 一次装十几个插件，遇到权限、认证或工具选择问题时很难定位。
五、真正拉开差距的 8 个技巧
技巧 1：提示词写“终点”，不要遥控每一步
官方提示词指南给出了一个很好用的四段式：
目标 Goal：最终要得到什么？
上下文 Context：应该读取哪些文件、页面或资料？
输出 Output：交付什么格式，写给谁看？
边界 Boundaries：什么不能改，哪些动作需要确认？
例如：
目标：修复订单列表偶尔重复请求的问题。
上下文：先检查 src/orders 和相关测试，复现步骤在 issue #184。
输出：最小修复、回归测试、修改摘要。
边界：不改接口结构，不升级依赖，不重构无关模块。
完成前运行最相关的测试并检查 diff。
这比“先打开 A 文件，再搜索 B，再改 C”更稳，因为它给了 Codex 足够的调查空间，也保留了明确护栏。
技巧 2：长期项目规则写进 AGENTS.md
凡是你每次都要重复说的话，都应该考虑从提示词里搬出去。
一个实用的 AGENTS.md 至少回答四个问题：
## Project structure
- 前端、后端、测试和配置分别在哪里？
## Commands
- 怎么安装、启动、测试和构建？
## Rules
- 哪些目录不能动？是否允许新增依赖？遵循什么风格？
## Verification
- 不同改动完成前分别要跑什么检查？
不要把它写成公司文化墙。越短、越具体、越可执行，价值越大。
技巧 3：大任务先 /plan，小任务直接做
跨模块功能、迁移、复杂 Bug 和权限改造，适合先让 Codex 调查并给出计划；文案修改、简单空判断和小范围测试，没有必要增加仪式感。
计划阶段可以要求它回答：
根因或目标理解； 影响范围； 修改顺序； 风险和不确定信息； 最小验证方案。
方向错了，改计划只需要一分钟；代码铺开后再回头，代价就高得多。
技巧 4：正在跑偏就 Steer，独立后续就 Queue
Codex 工作过程中，你不必等它结束再补充信息。
发现方向错了，用 Steer 立刻纠偏； 想到一个独立的后续任务，用 Queue 排到下一轮。
比如当前正在修登录状态，你发现它准备重构路由，可以立即说：
停止扩大范围。保留现有路由结构，只修复登录状态初始化。
如果只是想让它结束后补一段变更说明，则放进下一轮，不要把当前任务不断扩容。
技巧 5：给每个任务写“完成定义”
“代码写完了”不等于“任务完成了”。建议在任务末尾固定加一句：
完成前运行最相关的测试、Lint 和类型检查；
查看 git diff，确认没有误改；
最后报告执行过的命令、结果和仍存在的风险。
小改动跑小验证，大改动扩大验证范围。验证不是为了堆命令，而是为了降低错误逃逸概率。
技巧 6：写代码和审代码，分成两次思考
实现时，Codex 的目标是把功能做成；Review 时，它的目标应该切换成寻找错误。
完成修改后可以再发一条：
现在从审查者角度检查这次 diff。
重点找逻辑错误、兼容性问题、安全风险、缺失测试和无关改动。
先列问题，按严重程度排序；没有问题时明确说明。
同一个模型切换任务视角，往往就能发现第一轮忽略的边界条件。
技巧 7：读操作可以自动化，外部写操作保留确认
读取文档、查看 PR、检查页面通常风险较低；发送邮件、发布文章、合并 PR、删除文件、提交表单和修改权限会产生外部副作用。
一个很实用的边界模板是：
你可以自主读取、分析和准备草稿。
任何发送、发布、删除、购买、合并或权限修改，都必须在执行前让我确认。
最小权限不是妨碍效率，而是让自动化可以长期放心地跑。
技巧 8：同一流程重复三次，就沉淀成 Skill
如果你已经第三次要求 Codex“先查资料—再搭大纲—写初稿—做图—检查引用”，就不要继续靠记忆重复提示了。
把它做成 Skill：
---
name: wechat-tech-article
description: 用于撰写有资料来源、配图和发布检查的中文技术公众号文章。
---
1. 明确目标读者和文章角度。
2. 优先核对官方资料，再参考公开的高质量实践文章。
3. 先搭建叙事大纲，再写正文。
4. 使用原创图表解释复杂关系，不搬运第三方图片。
5. 检查事实、链接、图片路径、标题节奏和移动端阅读体验。
Skill 不是一段更长的万能提示词，而是一份可以被反复执行和逐步改进的作业流程。
六、一个完整案例：让 Codex 修完 Bug，而不是只改完代码
假设后台设置页出现问题：点击保存显示成功，但刷新后开关又恢复原状。
没有工作流时，你可能只说：
帮我修一下设置页。
配置好 Browser、GitHub 和项目规则后，可以这样交代：
修复设置页“保存成功但刷新后状态丢失”的问题。
上下文：
- 需求和复现记录在 GitHub issue #246；
- 相关前端代码在 src/settings；
- 遵守仓库 AGENTS.md。
要求：
1. 先用浏览器按 Issue 步骤复现，并记录实际表现；
2. 检查保存请求、成功提示和状态重新加载链路；
3. 做最小修复，不改变后端接口，不新增依赖；
4. 增加最相关的回归测试；
5. 修复后用同一路径重新验证；
6. 最后审查 diff，报告根因、修改、测试结果和剩余风险。
不要发布评论或提交 PR，只准备本地修改和 PR 描述草稿。
这条提示词并不“玄学”。它只是把需求来源、项目规则、工具、权限和验收标准接成了一个闭环。
Codex 真正的效率也来自这里：不是一次生成更多代码，而是少走几次“写完—人工发现不对—重新解释—再改”的回头路。
七、安装和使用时最容易踩的 5 个坑
1. 把 Plugin、Skill 和 MCP 当成同一件事
结果是明明只需要写一份流程，却先搭了一个服务；或者明明需要实时数据，却指望 Skill 凭空读取。
记住：流程用 Skill，外部工具用 MCP/连接器，分发组合用 Plugin。
2. 装完插件继续使用旧会话
根据官方说明，插件安装后，通常要启动新的聊天或 CLI 会话，插件中包含的 Skills 和工具才会进入新会话。
3. 只看“已连接”，不做真实任务验证
codex mcp list 能看到服务，并不代表认证、网络、权限和具体工具都可用。安装后立刻做一个最小读取任务，确认工具真的能工作。
4. 把 Token 直接写进提示词或配置示例
敏感凭据应该通过环境变量、OAuth 或服务支持的安全认证方式提供，不要贴进聊天、仓库或截图。
5. 给所有任务都开最高权限
日常代码任务通常只需要工作区写权限。涉及联网、工作区外文件或外部系统时，再针对具体动作授权。权限越大并不会让模型理解得更准确，只会让误解的影响范围更大。
八、给新手的一条 30 分钟升级路线
如果你今天刚开始认真用 Codex，可以按这个顺序：
给当前项目补一份一页以内的 AGENTS.md；安装或启用 Browser，跑通一次“修改—打开页面—验证”； 接入 GitHub，先做只读的 Issue/PR 总结； 配置一个与你技术栈相关的文档 MCP； 给常用任务补上“目标—上下文—输出—边界”； 每次完成前要求测试、diff 检查和风险说明； 某个流程重复三次后，把它做成 Skill； 只有出现明确需求时，再增加 Chrome、Computer Use、办公文件或安全能力。
你会发现，真正让 Codex 变好用的，不是某个神奇开关，而是逐步搭起一套属于自己的工作系统。
最后
Codex 和普通聊天机器人的关键差别，不是它更会“说”，而是它能在受控环境里持续“做”：读取项目、连接工具、修改文件、运行命令、查看页面、检查结果。
插件给它工具，MCP 给它接口，Skill 给它方法，AGENTS.md 给它规矩，而你负责定义目标、边界和验收标准。
所以，最值得安装的从来不是“排行榜第一名插件”，而是那个能补上你当前工作流缺口的能力。
先从 Browser、GitHub 和一个文档 MCP 开始。等你的工作流真正跑通，再把重复经验沉淀成 Skill。到那一步，Codex 才不再只是一个聪明的聊天框，而是开始成为一套可以积累、复用和进化的生产力系统。
参考资料
OpenAI Docs：Plugins OpenAI Docs：Skills 与自定义概览 OpenAI Docs：Model Context Protocol OpenAI Docs：Prompting OpenAI Docs：Build skills
注：Codex 更新较快，插件名称、菜单位置和可用范围可能随客户端、账号方案与工作区策略变化
欢迎关注我的公众号，每天分享一些技术文章和实战经验。
往期推荐
