Codex 这波更新之后，身边问得最多的就是“到底该装哪些插件”。说实话，Codex 的生态跟传统 IDE 插件市场不太一样，它不是单纯的“装个扩展完事”，而是围绕 CLI、编辑器、MCP、提示词管理的一整套工作流组合。这篇文章把我装了之后一直没卸的 10 个插件（或者说“增强工具”）挨个讲清楚，每个都附上我实际在用的提示词，照着抄就行。
1. 先说清楚：Codex 的“插件”到底指什么
很多人刚接触 Codex 时，第一反应是去插件市场搜“Codex”，结果发现官方插件其实没几个，反而被各种第三方扩展搞晕了。这里先统一一下概念：Codex 的“插件”分四类。
- 官方命令行工具本身：
@openai/codex，npm 全局安装，这是所有插件的基础环境。 - MCP（Model Context Protocol）服务器：通过 MCP 协议给 Codex 挂载文件系统、浏览器、数据库、Git 等工具能力，这才是真正意义上的“功能插件”。
- IDE 扩展：VS Code、Cursor 里的 Codex 相关扩展，解决“在编辑器里用”的问题。
- 提示词工程与规则文件：比如
AGENTS.md、系统提示词模板，它们不叫插件，但对最终效果的影响比插件还大。
理解了这四层，你就知道“选插件”不是一个简单的安装动作，而是搭一套环境。我下面推荐的 10 个，基本都是围绕这四层展开的，每个都对应了我在真实项目里踩过坑后的选择。
1.1 选插件的三个原则
先说三个原则，否则你装上也是吃灰。
第一个，插件服务于工作流，而不是反过来。你平时是终端党还是 IDE 党？如果主要在 VS Code 里写代码，那就优先装 VS Code 扩展；如果像我喜欢用 tmux + vim，那 CLI 工具链和 MCP 才是重点。强行装一堆不用场景的插件，最后只会变成“装了但没用”的摆设。
第二个，优先选官方或社区活跃度高的项目。Codex 本身迭代很快，API 变动频繁，冷门插件往往跟不上节奏，可能出现“昨天还能用，今天接口一变就挂”的情况。我踩过一次：某个第三方扩展两个月没更新，直接导致 Codex 会话无法加载历史记录，从那以后我只用 issues 反应及时、发布频率高的插件。
第三个，记住插件是“上下文增强器”。Codex 再聪明，它能看到的只有你提供给它的上下文。所以插件的作用边界是“帮 Codex 看得更全、操作更准”，而不是“替你做决策”。装好插件之后，你依然需要靠提示词把任务意图表达清楚，这两者是乘法关系。
2. 10 个我装了就没卸过的 Codex 配套插件
下面按安装顺序来，从基础环境到高级工作流，逐个说清楚“为什么装”“怎么配”“提示词怎么给”。
2.1 Codex CLI：一切的入口
严格来说这不是插件，但没有它，后面所有插件都无从谈起。Codex CLI 是 OpenAI 官方出的命令行 AI 编程工具，支持在终端里以对话或非交互模式运行，能读写文件、执行命令、分析项目结构。
安装就是一条命令：
npm install -g @openai/codex装完后建议做两件事：第一，登录（codex login），让后续操作带上你的账号凭证；第二，初始化配置文件~/.codex/config.toml，把默认模型、温度、工作目录等参数固定下来，避免每次启动都手动指定。
我实际使用的配置片段：
model = "gpt-5-codex" reasoning_effort = "medium" enable_default_sandbox = false注意我关了沙箱模式，因为很多项目需要真实的网络请求和文件写入，默认沙箱会频繁弹出权限确认，极其打断心流。如果你更看重安全，可以保持砂箱开，把常用目录加白名单也行。
提示词示例：
你是这个项目的资深工程师。请从 package.json 出发，梳理当前的依赖关系，指出哪些依赖版本过旧、哪些存在已知的安全问题，然后给出升级建议。升级建议要包含具体的命令和可能受影响的文件清单。这个提示词的设计思路是：先给身份定位，再给明确的分析起点（package.json），最后限定输出范围（命令+文件清单），避免 Codex 漫无边际地发挥。
2.2 MCP Server 套件：真正意义上的“能力插件”
MCP（Model Context Protocol）是 Codex 扩展能力的核心通道，你可以把它理解为“给 Codex 插上各种外设”。我装的最常用的是这几个 MCP Server：
- 文件系统 MCP Server：精确读写指定目录，不受默认工作区限制。
- Git MCP Server：让 Codex 直接查看 diff、提交历史、切换分支，不需要在终端里手动敲 Git 命令。
- 浏览器 MCP Server（比如 Playwright MCP）：让 Codex 能打开页面、点击元素、截图，主要用于前端调试和自动化测试。
- SQLite/Database MCP Server：查询和分析本地数据库，特别适合做数据迁移脚本时的辅助检查。
安装方式通常是 npx 一行命令，然后在 Codex 配置里注册：
[mcp_servers.fs] command = "npx" args = ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/workspace"] [mcp_servers.git] command = "npx" args = ["-y", "@modelcontextprotocol/server-git"]配好后，在对话里直接说“用 Git MCP 查看当前分支的改动”，Codex 就会调用对应工具，而不是傻乎乎地让你贴代码。
MCP 场景的提示词模板：
通过 Git MCP 工具获取当前分支与 main 分支的差异，逐个文件分析改动意图，重点关注：1）是否有破坏性变更；2）是否遗漏了相关测试；3）是否存在重复代码。输出一份评审意见，按严重程度排序。这里的关键是“通过 Git MCP 工具获取”这句指令，它告诉 Codex 优先走工具调用路径，而不是自己臆想代码内容。
2.3 VS Code 里的 Codex 扩展
如果你不是纯终端用户，VS Code 扩展是刚需。官方的 VS Code extension 支持直接在编辑器里选中代码、右键发送给 Codex、看到行内 diff 建议，体验比终端里粘贴代码强很多。
我装的是这两个：
- official Codex extension：基础对话、代码补全、diff 预览。
- Continue：一个开源 AI 编程助手，支持对接多种后端，包括 Codex。它最大的价值是可以自定义提示词模板和上下文选择策略，比如只让 AI 读取当前文件的函数签名，而不必加载整个文件。
Continue 的安装也不复杂，直接在扩展市场搜“Continue”安装，然后在配置里把 provider 指向 Codex。这里给一个我自定义的 slash command 模板，用来快速生成单元测试：
/slash 生成测试 针对当前文件中的每个导出函数，生成一组 pytest 单元测试。 要求：1）覆盖正常路径；2）覆盖异常路径；3）断言使用准确； 4）不 mock 不属于外部依赖的内容。只输出测试代码，不解释。把这个模板存成 Continue 的自定义 command 之后，每次写单测就从“开长对话”变成了“一键出活”，效率提升明显。
2.4 Cline：自主任务型 IDE 插件
Cline 是另一个值得装的 VS Code 插件，定位跟 Codex 官方扩展不同，它是“agent 模式”的：你给它一个端到端任务，比如“把这个 React 组件从 class 写法改成 hooks 写法”，它会自动规划步骤、修改文件、运行测试，然后向你汇报。
为什么我要同时装 Codex 和 Cline？因为我发现两者在不同任务上各有优势：Codex 在复杂系统级理解和跨文件重构上更强，Cline 则更擅长在 IDE 里按“计划—执行—检查”循环跑小任务。日常我通常把 Cline 当成执行器，把 Codex 当成架构师。
Cline 里用的提示词示例：
任务：将 src/utils/api.ts 中的请求封装从 fetch 替换为 axios。 约束：1）保持函数签名不变；2）保留原有的错误处理逻辑； 3）所有调用方文件名写入变更记录；4）完成后运行 npm run typecheck，确保无类型错误。 请直接开始执行，不需要解释。注意我在最后写了“不需要解释”，这是控制 Cline 话痨体质的关键。如果你不写这句，它会花大量时间给你讲故事，而不是干活。
2.5 AGENTS.md 规则文件：项目的“插件级配置”
严格说这也不是插件，但它的重要性值得单独占一个位。Codex 对AGENTS.md文件有原生支持，放在项目根目录下，Codex 每次进入项目时都会自动加载这个文件，相当于“记住了你的工程规范”。
我的AGENTS.md模板：
# 项目规范 - 前端框架：React 18 + TypeScript，禁止使用 any。 - 样式方案：Tailwind CSS，禁止引入 UI 组件库。 - 测试：所有工具函数必须附带 Vitest 测试。 - 提交信息：遵循 Conventional Commits 格式。 - 架构约束：业务逻辑不得直接写在组件中，必须抽离到 hooks 或 services。这个文件的作用是让 Codex 在每次对话前就“知道”规则，不需要你在提示词里反复叮嘱。我统计过一个中型项目，加上这个文件之后，Codex 生成代码的返工率大概降了 30%，因为它不会再写出违背架构约束的代码了。
配合它的提示词可以这样写：
请阅读项目根目录的 AGENTS.md，然后按其中的约束帮我新增一个 user login 的 service 模块。 要求：包含参数校验、错误处理、单元测试，并且不破坏现有 API 的返回结构。2.6 Claude Code：跨模型互补的“第二引擎”
你可能觉得奇怪，Codex 的文章里为什么要推荐 Claude Code？我的理由很简单：不同模型在不同任务上表现差异极大，与其一个模型死磕，不如两个模型各司其职。
Claude Code 是 Anthropic 官方推出的命令行编程工具，安装方式类似：
npm install -g @anthropic-ai/claude-code我实际的分工是这样的：Codex 负责 TypeScript 后端和系统设计，Claude Code 负责前端 UI 细节和复杂样式还原。因为 Claude 在视觉理解上天然有优势（多模态训练充分），给它一段设计稿图片，它能比较准确地生成 className 布局；Codex 在这类任务上偶尔会出现“元素定位偏差”。
Claude Code 里我常用的提示词：
这是一个 Vue 3 + Tailwind 的页面，请根据截图还原布局。 要求：1）严格控制间距变量，使用 design token；2）不改变现有组件 API； 3）响应式断点分为 sm/md/lg 三档。最后展示关键代码，并用一句说明 bil-mu-liu 实现思路。注意，跨模型协作的前提是“项目规范统一”，所以 AGENTS.md 同样要被 Claude Code 读取。好在它也支持规则文件加载，配置方法一样。
2.7 npm 包codex的辅助脚本：codex-before-commit
这个其实是 npm 包生态里的一个小工具，不是官方插件，但非常实用。它可以在你提交代码之前自动触发 Codex 做增量代码审查，把风险扼杀在本地。
安装方式：
npm install -D codex-before-commit然后在package.json里挂到 git hooks（配合 husky）：
{ "husky": { "hooks": { "pre-commit": "codex-before-commit" } } }它会做的事情是：收集当前暂存区的 diff，调用 Codex 分析 diff 中的潜在 bug、风格问题、遗漏测试，然后把报告输出到终端。如果发现问题超过阈值，会阻止提交。
配合的提示词写在工具的配置文件里：
请只分析以下 diff，不要提出与 diff 无关的建议。 重点检查：1）空指针与数组越界；2）状态更新是否会导致死循环； 3）是否有未处理的 Promise reject；4）改动是否影响现有接口的兼容性。 输出格式：问题位置 + 严重程度 + 修复建议。这个工具帮我挡住过好几次低级错误，比如数组下标越界和 useEffect 依赖缺失，属于“用了就回不去”的类型。
2.8 tmux 会话管理脚本：终端党的“隐形插件”
如果你跟我一样在终端里工作，Codex 跑长任务时经常会遇到一个问题：窗口一关，任务就断了。所以我写了一个 tmux 会话管理脚本，专门用于跑 Codex 的长时间任务（比如批量重构、多文件测试修复）。
这个脚本的作用相当于“给 Codex 开了个后台守护”，核心逻辑是：新建/复用 tmux 会话，把 Codex 命令塞进去运行，日志重定向到文件，任务结束后发送通知。
核心脚本片段：
#!/bin/bash # codex-run.sh SESSION_NAME="codex-focus" if ! tmux has-session -t $SESSION_NAME 2>/dev/null; then tmux new-session -d -s $SESSION_NAME fi tmux send-keys -t $SESSION_NAME "codex \"$1\"" C-m tmux pipe-pane -t $SESSION_NAME -o "tee /tmp/codex-output.log"配合提示词使用，比如你要“把项目里所有 TODO 注释汇总并批量生成 issue”，直接执行：
./codex-run.sh "请扫描整个仓库的 TODO/FIXME 注释，按模块分组输出清单，并给出每项的优先级建议。"之后你就可以关掉终端去干别的，tmux 会继续跑任务。日志写入了/tmp/codex-output.log，随时查看进展。
2.9gh-codex：用 GitHub CLI 跟 Codex 联动
这是我自己封装的一个小插件，核心思路是：gh负责跟 GitHub 交互，codex负责理解代码，两者通过管道结合。
典型场景是处理 GitHub Issue 或 PR 评论。比如你收到一个 PR review 意见，想用 Codex 分析建议是否合理，可以这样：
gh pr diff 123 | codex "请审查以下 PR diff，列出所有潜在问题，并判断 review 中提出的建议是否有必要全部落实。"更实用的场景是自动生成 PR 描述。我先用gh pr diff拿到改动内容，再让 Codex 生成描述：
gh pr diff 123 | codex "请根据改动生成 PR 描述，包含：背景、改动点、测试情况、风险提示。用简洁的条目式输出。"省掉了一小时的手写描述时间。提示词看着简单，但有个细节：管道输入会把所有内容当作上下文，“请根据改动生成”这句指令必须放在开头，否则 Codex 可能把前面的 diff 误认为任务本身。
2.10 提示词模板管理脚本：我的 20 个高频提示词库
最后这个不是传统插件，但我觉得是最值得分享的“个人插件”。用久了你会发现，Codex 效果的好坏，很大程度上取决于提示词是否稳定可复用。同样是“生成 API 文档”，随口说的效果和用固定模板的效果，差别非常大。
我在~/.codex-prompts目录下建了一堆 Markdown 文件，每个文件对应一个场景，然后用一个简单的 shell 脚本把它们拼接到命令行：
# cdprompt.sh PROMPT_FILE="$HOME/.codex-prompts/$1.md" shift codex "$(cat $PROMPT_FILE) $@"比如~/.codex-prompts/api-doc.md的内容是：
请为 src/api 目录下的所有 TypeScript 接口生成 OpenAPI 风格的文档。 要求：1）每个接口标注请求参数、响应类型、错误码；2）不修改任何源码； 3）按模块输出到 docs/api/ 目录；4）文档中的示例必须能直接通过类型检查。使用时执行：
./cdprompt.sh api-doc这个脚本让“提示词”变成了可管理、可搜索、可版本化的资产，而不是每次临时输入的一段话。我强烈建议你也建一个自己的提示词库，积累久了就是一套“专属工作流方法论”。
3. 提示词怎么设计？我总结的思路与模板
插件装得再多，最后还得落实到提示词上。我把自己的提示词设计方法整理成一个四步流程。
- 第一步：给身份。明确角色，比如“资深后端工程师”“前端实习生”，不同身份直接影响 Codex 的措辞和关注点。所谓“实习生”，其实就是让它默认多写注释、多解释。
- 第二步：给约束。把不能做的事说死，比如“不要引入新的依赖”“不要修改公共接口”“不要重新格式化不相关的代码”。没有约束的 Codex 会自我放飞。
- 第三步：给检查点。让 Codex 输出中间结果，比如“先用三点路径规划，确认后再动手”，可以有效防止大任务跑偏后半路返工。
- 第四步：给交付格式。明确说明输出形式，比如“输出 JSON”“生成表格”“只展示改动代码”。没有格式要求，你得到的就是一段冗长的废话。
把四步串起来，一个通用模板长这样：
[身份]你是一个熟悉 [技术栈] 的资深工程师。 [任务]请 [具体描述任务]，不修改非必要的现有代码。 [约束]禁止 [列举禁忌]；保持现有业务逻辑不变。 [过程]先分析当前代码结构并给出计划，确认后执行。 [输出]最后用 [格式] 输出结果，并注明改动影响范围。举一个我在真实项目里用过的完整示例，任务是重构一个支付回调模块：
你是一个熟悉 Node.js 和支付接口的资深工程师。 请重构 src/payment/webhook.ts 中的回调处理逻辑，当前存在重复代码和异常处理缺失。 禁止修改 router 层的路由定义，禁止改变数据库表结构。 先通读相关文件并列出重构方案，再执行修改。 完成后输出：1）改动文件清单；2）每个文件的核心变化；3）需要手动验证的场景。这个提示词跑下来，Codex 的产出比我直接说“帮我重构一下”要精准得多。多花 30 秒写清楚，省下的是半小时的返工。
3.1 针对不同类型任务的提示词速查表
| 任务类型 | 核心提示词关键词 | 示例开头 |
|---|---|---|
| 代码审查 | diff、严重程度、兼容性 | “请按严重程度审查以下代码……” |
| 重构 | 保持行为不变、风险点 | “重构时保持对外行为不变，指出潜在风险……” |
| 生成测试 | 覆盖路径、断言准确 | “为以下函数生成单元测试，要求覆盖正常与异常……” |
| 写文档 | 格式要求、示例可用 | “输出 OpenAPI 风格文档，示例可通过类型检查……” |
| 排查 Bug | 复现步骤、分步分析 | “请先列出可能导致报错的原因，再逐个排查……” |
| 数据库迁移 | 兼容旧数据、回滚方案 | “设计迁移方案，必须提供可回滚的脚本……” |
| 性能优化 | 指标量化、瓶颈分析 | “请先从算法复杂度入手分析性能瓶颈……” |
这张表是我日常用的“查字典”，不确定怎么开口时，先选任务类型，再套模板。
4. 实操中的常见问题与排查记录
插件装多了，问题也少不了。我把自己碰到过的几类高频问题整理一下，很多都是搜索一时半会儿查不到答案的细节。
4.1 登录或调用时报 “cc switch local proxy failed”
这个报错的完整形态通常是类似“cc switch local proxy failed while handling codex endpoint /responses”的日志信息。我第一次遇到时有点懵，排查了半天，最后发现问题出在网络代理中间层的配置冲突上——系统环境里设置了代理变量，Codex 在内部切换代理通道时失败，导致请求打到 endpoint 时中断。
排查思路分三步：
- 检查环境变量：运行
env | grep -i proxy，确认HTTP_PROXY、HTTPS_PROXY、ALL_PROXY是否设置。如果有多余代理配置，先取消它们再重试。 - 检查 Codex 日志：使用
codex --verbose启动，或者查看~/.codex/log/下的日志文件，定位到具体的失败请求，确认错误发生在连接建立还是响应处理阶段。 - 重置网络配置：如果是企业内网或路由器级别的代理策略导致，最直接的办法是临时切换网络或调整代理白名单，把 Codex 使用的 endpoint 地址加入直连名单。
我在公司网络环境里复现过这个报错，最后是通过清理系统代理变量 + 在 Codex 配置里显式关闭代理相关设置解决的。
# config.toml [network] proxy = ""显式置空，比依赖环境变量要稳。这个问题跟地理位置无关，纯粹是本机代理栈的配置兼容性，排查方向千万不要跑偏。
提示：遇到任何网络相关的报错，不要第一时间怀疑 Codex 本身，先检查你的代理变量和防火墙设置。90% 的情况是这些基础环境在捣乱。
4.2 Codex 登录后 “转圈” 或提示无法同步会话
这种问题我遇到过两次，一次是网络波动导致令牌没刷新成功，一次是本地配置的模型版本过旧与服务端不兼容。
处理方法：
- 先重新登录：
codex logout && codex login - 如果重登无效，清掉本地的缓存目录：
rm -rf ~/.codex/cache，再重启 Codex。 - 最后一步是检查有没有旧版本的全局安装残留，执行
npm ls -g @openai/codex，确保只有一个版本。
需要注意，清缓存之前它会删掉一些本地历史会话索引，但对正在用的项目没有影响，不用太担心。
4.3 上下文太大，Codex 开始“降智”
这是我最常遇到的问题之一。当你有大型仓库、或者开了很多 MCP 工具时，恢复信号长度会快速增长。Codex 不会立刻拒绝，但输出的答案会越来越泛化，甚至出现“遗忘”早期约定的情况。
我的解法是把“上下文控制”当成一种习惯：
- 在提示词里直接声明“请只关注
src/app/目录，忽略node_modules和dist。” - 用
AGENTS.md屏蔽不重要的目录，明确告诉 Codex 哪些路径不值得读取。 - 大任务拆成多个小任务。与其一次说“把整个系统重构了”，不如分阶段“先重构模块 A，完成后再处理 B”。
- 必要时直接新开会话，把必要的背景在前几句话里重新交代一遍，而不是拖着上个会话的完整历史跑下去。
有一次我对一个代码库跑了个“全局梳理”的任务，结果 Codex 聊到一半开始重复前面的代码片段，就是因为上下文撑爆了。换成“分目录逐个分析”之后，结果质量立刻回来了。
4.4 MCP 工具调用失败或行为异常
MCP 偶尔会抽风，常见的表现是：Codex 说“我正在调用 Git MCP 工具”，但后面没反应或报错。
排查步骤：
- 确认 MCP Server 是否启动成功。终端手动执行一遍
npx命令，看有没有报错。 - 检查 config.toml 里的路径和参数，
command必须要绝对路径或可执行命令，args里的路径不能有拼写错误。 - 调高日志级别：在 Codex 里执行
codex --log-level debug，观察 MCP 请求的响应。 - 如果是某个特定 MCP Server 反复失败，直接换替代工具。比如文件系统 MCP 挂掉，可以先用
codex自带的文件读写能力顶着，不一定非要修好它。
MCP 问题大多是配置细节，把日志打开基本都能定位。不用慌，也不建议在单个 MCP Server 上死磕太久，换一个同类工具往往更快。
5. 避坑心得与配置清单
最后分享几条我“装了又卸、卸了又装”之后沉淀下来的心得。
第一，别一上来就装 10 个插件。壳子搭好之后，先只装 Codex CLI + 一个 IDE 扩展 + AGENTS.md，跑通一个完整的小项目，再逐步加 MCP 和提示词库。一次性全配齐，出了问题你根本不知道是哪一个环节在闹鬼。
第二，插件配置一定要纳入版本管理。我的做法是把config.toml、AGENTS.md、提示词库、安装脚本全部放到一个单独的 dotfiles 仓库里。这样换电脑、重装系统，15 分钟就能把整套 Codex 环境拉起来，不需要每次都“从零开始调”。
第三，保持“提示词是资产”的意识。每次你写出一个效果很好的提示词，就存进提示词库，不要让它只在终端里飘过。一个月之后你会拥有一本自己的“AI 编程手册”，这比任何网上找得到的大而全模板都好用。
第四，定期审视插件是否仍然有用。我每个月会清一次不常用的插件。标准很简单：两周内没打开过、没在对话里触发过的，就卸掉。这个习惯能让你的 Codex 环境始终保持精简，调试成本和心智负担都更低。
附一个我的基础配置清单：
| 组件 | 选择 | 备注 |
|---|---|---|
| 核心引擎 | Codex CLI | 全局安装 |
| IDE 扩展 | Official extension + Continue | 按场景切换 |
| MCP Server | filesystem, git | 按项目增减 |
| 第二引擎 | Claude Code | UI 细节和视觉还原 |
| 规则文件 | AGENTS.md | 项目根目录 |
| 提示词管理 | 本地 Markdown + 脚本 | 个人资产库 |
| 后台任务 | tmux 脚本 | 长任务不中断 |
这些组件彼此互补，基本覆盖了我日常“需求分析—写代码—自测—审查—写文档”的全流程。它们不是装完就结束的东西，需要你在使用中不断调整提示词和配置，才会真正变成“顺手”的工具。
