Codex 这波更新之后身边问得最多的就是“到底该装哪些插件”。说实话Codex 的生态跟传统 IDE 插件市场不太一样它不是单纯的“装个扩展完事”而是围绕 CLI、编辑器、MCP、提示词管理的一整套工作流组合。这篇文章把我装了之后一直没卸的 10 个插件或者说“增强工具”挨个讲清楚每个都附上我实际在用的提示词照着抄就行。1. 先说清楚Codex 的“插件”到底指什么很多人刚接触 Codex 时第一反应是去插件市场搜“Codex”结果发现官方插件其实没几个反而被各种第三方扩展搞晕了。这里先统一一下概念Codex 的“插件”分四类。官方命令行工具本身openai/codexnpm 全局安装这是所有插件的基础环境。MCPModel 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 套件真正意义上的“能力插件”MCPModel 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 token2不改变现有组件 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 reject4改动是否影响现有接口的兼容性。 输出格式问题位置 严重程度 修复建议。这个工具帮我挡住过好几次低级错误比如数组下标越界和 useEffect 依赖缺失属于“用了就回不去”的类型。2.8 tmux 会话管理脚本终端党的“隐形插件”如果你跟我一样在终端里工作Codex 跑长任务时经常会遇到一个问题窗口一关任务就断了。所以我写了一个 tmux 会话管理脚本专门用于跑 Codex 的长时间任务比如批量重构、多文件测试修复。这个脚本的作用相当于“给 Codex 开了个后台守护”核心逻辑是新建/复用 tmux 会话把 Codex 命令塞进去运行日志重定向到文件任务结束后发送通知。核心脚本片段#!/bin/bash # codex-run.sh SESSION_NAMEcodex-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 Serverfilesystem, git按项目增减第二引擎Claude CodeUI 细节和视觉还原规则文件AGENTS.md项目根目录提示词管理本地 Markdown 脚本个人资产库后台任务tmux 脚本长任务不中断这些组件彼此互补基本覆盖了我日常“需求分析—写代码—自测—审查—写文档”的全流程。它们不是装完就结束的东西需要你在使用中不断调整提示词和配置才会真正变成“顺手”的工具。 Codex插件选配指南：10个实用增强工具与提示词模板
Codex 这波更新之后身边问得最多的就是“到底该装哪些插件”。说实话Codex 的生态跟传统 IDE 插件市场不太一样它不是单纯的“装个扩展完事”而是围绕 CLI、编辑器、MCP、提示词管理的一整套工作流组合。这篇文章把我装了之后一直没卸的 10 个插件或者说“增强工具”挨个讲清楚每个都附上我实际在用的提示词照着抄就行。1. 先说清楚Codex 的“插件”到底指什么很多人刚接触 Codex 时第一反应是去插件市场搜“Codex”结果发现官方插件其实没几个反而被各种第三方扩展搞晕了。这里先统一一下概念Codex 的“插件”分四类。官方命令行工具本身openai/codexnpm 全局安装这是所有插件的基础环境。MCPModel 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 套件真正意义上的“能力插件”MCPModel 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 token2不改变现有组件 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 reject4改动是否影响现有接口的兼容性。 输出格式问题位置 严重程度 修复建议。这个工具帮我挡住过好几次低级错误比如数组下标越界和 useEffect 依赖缺失属于“用了就回不去”的类型。2.8 tmux 会话管理脚本终端党的“隐形插件”如果你跟我一样在终端里工作Codex 跑长任务时经常会遇到一个问题窗口一关任务就断了。所以我写了一个 tmux 会话管理脚本专门用于跑 Codex 的长时间任务比如批量重构、多文件测试修复。这个脚本的作用相当于“给 Codex 开了个后台守护”核心逻辑是新建/复用 tmux 会话把 Codex 命令塞进去运行日志重定向到文件任务结束后发送通知。核心脚本片段#!/bin/bash # codex-run.sh SESSION_NAMEcodex-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 Serverfilesystem, git按项目增减第二引擎Claude CodeUI 细节和视觉还原规则文件AGENTS.md项目根目录提示词管理本地 Markdown 脚本个人资产库后台任务tmux 脚本长任务不中断这些组件彼此互补基本覆盖了我日常“需求分析—写代码—自测—审查—写文档”的全流程。它们不是装完就结束的东西需要你在使用中不断调整提示词和配置才会真正变成“顺手”的工具。