说实话我第一次用 Codex 的时候真没觉得它有多神。终端里敲几条命令让 AI 帮我写个函数、修个 bug聊几个来回就完事了——这种感觉更像是在玩一个加强版命令行助手跟那些直接在编辑器里满屏飘代码的 AI 工具完全不是一回事。我一度想卸载直到我把编辑器侧的插件、上下文工具、提示词模板整套搭起来之后Codex 才真正变成我每天都在用的主力工具。这篇不写那些虚的就讲两件事一是我装完就没卸过的 10 个插件/扩展二是能够让 Codex 真正干活的提示词。如果你刚装好 Codex或者装了之后觉得它也就那样那你大概率是缺了下面这套搭配。文章最后我会把这段时间踩过的坑包括打不开、本地代理报错这类热门问题一并交代清楚。1. 先把话说清楚Codex 到底是个什么插件生态1.1 Codex CLI 和编辑器扩展别把两者搞混很多朋友第一次接触 Codex是因为某篇文章里那句OpenAI 开源了 Codex CLI。于是大家去 GitHub 上把 CLI 装好在终端里敲codex开聊。这个方向没错但问题在于CLI 只是 Codex 的发动机它本身并不自带方向盘和仪表盘。如果你一直停留在黑框框里对话你的使用体验就永远只局限于命令行助手这个层面。Codex 真正强大的是它代理Agent式的工作方式它可以在你给的指令下自己读代码、自己改文件、自己跑命令、自己看报错然后再继续。这个能力在 CLI 里也能体验但效率不高因为你没法直观地看到它正在改哪些文件、上下文覆盖到哪儿了。VS Code 里的官方扩展就是把这一套搬到了图形界面里让 Codex 操作文件、展示 diff、管理会话都变得一目了然。Codex CLI 是一个独立安装的程序而 VS Code 里的 OpenAI Codex 扩展则是对 CLI 能力的图形化封装。两者配合才是我推荐的工作方式。你可以把 Codex 想象成一个新来的同事CLI 是让他隔着对讲机干活扩展是让他坐在你旁边一起看代码。1.2 我给Codex 插件下的定义整条 AI 辅助链路既然标题是Codex 插件怎么选我得先定义一下什么叫Codex 插件。在 VS Code 的扩展商店里搜索 Codex你只会看到官方扩展和少量社区封装真正的插件生态并不像 Chrome 商店那么丰富。但如果你把眼光放宽一点Codex 的可扩展性其实体现在三个层面编辑器侧扩展比如官方 Codex 扩展、Cline、Continue它们负责的是AI 如何和你交互上下文侧插件比如 GitLens、Error Lens它们负责给 AI 提供高质量的代码上下文协议侧扩展比如 MCPModel Context Protocol服务器它们让 Codex 能访问外部数据源、数据库、文档仓库。所以我推荐的 10 个插件其实是围绕 Codex 的这套完整协作链路。如果你只装了 Codex 就开干等于雇了个聪明但没带工具箱的师傅把配套插件配齐才是真正进入AI 辅助开发的状态。2. 装完就没卸过的 10 个插件/扩展清单与选型逻辑2.1 第一梯队和 Codex 直接打配合的 4 个1. OpenAI Codex 官方扩展这是第一优先级没有它你后面那些都谈不上。在 VS Code 扩展商店直接搜 Codex认准 OpenAI 官方出品。装好之后它会自动探测你已经登录的 Codex CLI 会话不需要重复登录。我实测下来官方扩展最有价值的功能不是聊天窗口而是Checkpoint检查点每次 Codex 做一轮修改你都可以对比改动前后的差异随时回滚。这比你在终端里用手动 git checkout 来补救要安全得多。尤其是 Codex 一顿操作猛如虎给你改了十几个文件之后检查点是你的后悔药。2. ClineCline 不是 OpenAI 官方的它是我用的最狠的一个类 Codex工具。它和 Codex 的核心区别在于Cline 把自主操作终端这件事做得更显性你可以看到它每一步会执行什么命令、为什么要执行。当 Codex 官方 CLI 还在纯文本界面打转的时候Cline 已经在用分步计划模式帮你拆解任务了。我在实际项目中通常这么分工Codex 主攻代码修改和跨文件重构Cline 负责那些我想让它一步步确认着做的敏感任务比如改动数据库迁移脚本或者操作生产环境相关的配置文件。Cline 的计划模式会先出方案、等你点头再执行这种慎重的风格在关键任务上很讨喜。3. ContinueContinue 和 Codex 的关系很多人没搞明白。Continue 适合当你需要在多个模型之间快速切换对比时使用——同一个问题让 Codex 答一遍再让其他模型答一遍看看谁的理解更准。这个插件对我最大的用处是验收Codex 改完代码后我会用 Continue 换个模型读一遍 diff相当于免费的代码评审第二意见。4. GitHub Copilot你一定想问Copilot 和 Codex 不是竞争关系吗怎么还装一起了我的经验是两者的工作习惯差异很大Copilot 的补全速度快、单行/小块代码场景极顺Codex 的强项是大范围和跨文件的修改。装一个补全快装一个改得深两者正好互补。你不必在工具栏上同时开两个 AI 对话窗口但可以在日常编码时依赖 Copilot 的补全在需要重构时把大任务丢给 Codex。2.2 第二梯队补全上下文与代码理解的 3 个如果说第一梯队负责AI 怎么和你对话第二梯队负责AI 凭什么能听懂你在说什么。5. GitLensGitLens 初看是一个看代码历史的工具但对 Codex 来说它是上下文的富矿。我经常让 Codex 调查一个 bug这个函数最近 10 次提交里改了什么哪次改动引入了问题如果没有 GitLens 把 blame 信息和提交历史清晰展示在代码侧边Codex 很多时候只能基于当前文件的状态瞎猜。我个人的技巧是在给 Codex 的提示词里明确写上先看 git log 和当前文件的 git blame再回答。配合 GitLens 使得这些信息在 VS Code 里一目了然Codex 的推理会扎实很多。6. Error LensError Lens 的作用是把代码里的错误、警告直接渲染在对应行后面省去你鼠标悬停看提示的步骤。这个插件对 Codex 的意义在于它让错误成为上下文的一部分。Codex 在生成代码的时候如果你能看到当前文件末尾又多了一行红色的波浪线你就能立刻把报错信息复制给 AI形成写代码—看报错—让 AI 修—再看报错的高频闭环。否则你常常会遇到一种尴尬Codex 自信地给你改完一版代码你发现编译错误其实是上一处本来就存在的根本和它的修改无关。有了 Error Lens 实时反馈AI 背锅的概率大大降低。7. REST ClientREST Client 是个轻量级的 API 调试工具但我要给它一个额外的身份帮助 Codex 理解接口长什么样。我的习惯是这样的遇到不清楚的接口返回结构先用 REST Client 调一次把 response 直接塞给 Codex让它基于真实数据去写类型定义或对接代码。比起让 AI 从文档里猜字段直接给真实响应是最快、最不易错的方式。2.3 第三梯队把提示词和规则变成资产的 3 个8. Markdown Preview EnhancedMarkdown Preview Enhanced 是一个老牌插件但它在 Codex 工作流里扮演的是提示词文档化的角色。我把常用提示词、Codex 规则说明、项目约定都写在.md文件里用这个插件实时预览。这样当我需要让 Codex 按照某种工程规范干活时我可以把一段写好的提示词文档直接拖进对话或者直接引用文件路径让 Codex 去读。提示词不应该靠脑子记应该沉淀成文档资产。9. Todo TreeTodo Tree 可以在侧边栏把所有代码注释里的TODO、FIXME集中列出来。你可能觉得这和 Codex 有什么关系关系大了。我每周一上班的第一件事就是打开 Todo Tree 看一遍待办清单然后把条目丢给 Codex这几个 TODO 分布在哪些文件逐个说明上下文和潜在风险。没有这个插件你就得自己在代码里到处搜注释效率差太多。10. VS Code MCP Client这是 Codex 进阶玩法的关键拼图。Codex 官方 CLI 在较新版本里支持通过config.toml配置 MCP 服务器让模型能够调用外部工具比如查询数据库、读某个内部文档站、搜索某个日志平台。而 VS Code 生态里有对应的 MCP Client 插件可以帮助你把 MCP 能力接进编辑器侧。举个例子我把一个可以查询公司内部 API 文档的 MCP 服务器配好之后Codex 可以直接去查文档而不是靠记忆猜接口的参数。这就好比你给 AI 配了一个内部资料库的通行证。如果你还没用到 MCP先把官方扩展用熟等觉得手上项目里模型经常因为不知道外部系统的状态而答错时再来研究 MCP 也不迟。3. 选插件的判断标准不只看下载量要看和 Codex 的配合方式3.1 我筛选这 10 个插件的三条标准网上类似十大必装插件的文章很多但大多数是下载量排行榜并不针对 Codex 工作流。我自己筛选的时候只看三条它是否提升了我给 Codex 下达指令的质量比如说 Error Lens、GitLens它们让代码状态更透明模型能更快抓重点它是不是能减少我的人工搬运比如说 Cline 的计划模式能减少我反复确认的时间REST Client 能把接口响应直接变成 AI 的参考它是否帮助把项目知识沉淀下来比如说 Markdown Preview Enhanced 和 Todo Tree一个管提示词文档一个管项目待办都能在长期项目中积累有用信息。很多插件虽然下载量很高但不符合以上任何一条比如各种主题美化图标美化之类的。不是说它们不好而是它们对 Codex 这条主线没有增量价值装多了反而增加启动开销。3.2 哪些情况不要装插件过度扩展是我踩过的一个坑。给 Codex 配置了 20 多个 MCP 或是装了一堆重度代码分析插件后你会发现自己陷入了调试 AI 工具链的泥潭真正用来写业务的时间反而变少了。工具是拿来省时间的如果你花在配置和折腾插件上的时间超过了它帮你省下的时间就该做减法。我目前的准则是每个插件在最近 30 天里至少被真实用到 3 次否则就卸载或者停用。我一直坚持这个习惯目前的 10 个全是过检选手。你可以根据自己的项目类型、你自己平时是否依赖调试器、模型上下文窗口等因素做微调不用机械照搬我的清单。比如前端为主的项目里Vue DevTools 类的调试工具可能就比 REST Client 更值得进前五。4. 提示词才是插件的上层建筑附可直接复制的提示词插件解决的是Codex 能碰到什么提示词解决的是Codex 到底该干什么。我见过太多人插件装了一大堆结果提示词还是帮我修一下这个 bug然后抱怨 AI 答得不对。这种一句话任务哪怕换成人类同事也很难给出你满意的结果。下面这些提示词模板是我高强度用了一个月之后沉淀下来的可以直接复制微调。4.1 任务型提示词模板让 Codex 当执行者而不是答题者先说一个最重要的认知Codex 是一个 Agent不是一个聊天机器人。你给它的指令应该是去把这件事办了而不是你觉得这事儿该怎么办。同样是写一个登录接口聊天机器人式的问法是帮我写一个用户登录接口。Codex 听到这种指令会不知道怎么落地因为你没告诉它项目里用的是什么框架、要存哪些字段、需不需要验证码、是走 JWT 还是 session。而代理式的任务指令应该是请实现用户登录功能要求如下 1. 项目使用 Express Prisma请遵循现有 src/api 下的路由组织方式。 2. 请求参数包含 email 和 passwordpassword 用 argon2 校验。 3. 登录成功后返回 accessToken有效期 2 小时和 refreshToken有效期 7 天。 4. 失败情况统一返回 { code: 40101, message: 邮箱或密码错误 }不要泄露用户是否存在。 5. 先读现有 models/User.ts确认字段名后再动手不要假设字段。 6. 完成后运行 npm run typecheck 确保通过并列出所有改动文件。注意到了吗我给的不只是需求还包括约束条件、参考源头、验收标准、执行步骤。Codex 拿到这样的提示词才能像真正的同事一样知道去哪儿查资料、按什么标准交付。4.2 代码审查型提示词让 Codex 当第二双眼睛让 Codex 审代码是它最擅长且最不会翻车的场景。相比让 AI 直接改代码审查里的风险更小收益更稳定。我推荐下面这个模板请对以下代码进行审查按【正确性】【可维护性】【性能】三个维度输出问题列表。 每个问题必须包含 - 文件路径与行号 - 问题类型与严重程度 - 具体解释为什么这是个问题 - 修复建议给出代码片段 注意不要为了批评而批评如果没有问题就说明没有问题。也不要重写整段代码。这个提示词最大的价值在于不要重写整段代码这一句。你不加这句Codex 很容易热情过度把你的代码整个重构一遍最后你 diff 一拉改动量巨大根本不敢合并。加了这句之后它就老老实实当审查员而不是抢你的键盘。4.3 测试生成型提示词想清楚测什么再让 AI 动手让 Codex 写单元测试很多人会翻车因为 AI 特别容易生成自嗨型测试——测试代码运行起来没问题但因为断言太弱根本测不出 bug。问题出在提示词没把测试目标交代清楚。我用的是请为 src/services/orderService.ts 编写单元测试。 测试框架使用 Vitestmock 方式参照现有 test 目录下的写法。 目标场景必须覆盖 - 创建订单时若商品库存不足则抛出指定错误 - 并发创建同一商品订单时不能出现超卖 - 用户订单列表返回时按时间倒序排列 要求 - 每个测试用例用中文注释说明测试意图 - 不要 mock 被测函数自身 - 运行 pnpm test:unit 后必须全部通过关键点在于你先自己把要覆盖的场景列出来AI 只是去实现你的测试清单。如果你连场景都没想清楚就让 Codex 写它大概率只挑最简单、最不容易出错的路径来测结果就是测试覆盖率好看实际 bug 一个没拦住。4.4 错误排查型提示词把报错原文喂给它并限定排查路径Codex 用来排查运行时问题是它另一个高热场景。但很多人一上来就问为什么会报错信息量太少AI 只能瞎猜。我的排查模板是以下是运行时错误信息 [粘贴完整错误堆栈] 我在 main.ts 第 42 行调用了 fetchData()随后进入 catch 分支。 请按以下路径排查 1. 首先检查 fetchData 的调用方传参是否符合函数签名。 2. 再检查 API 返回结构是否和类型定义一致。 3. 如果以上都没问题查看这个错误是否可能来自未捕获的 Promise rejection。 不要直接给结论先输出你的分析过程和证据链。先输出分析过程再给结论这个要求很重要。它对 Codex 的意义在于强迫模型先做推理而不是直接跳到最可能的结论。实际上用下来加了这句话之后错误判断的准确率提升得相当明显因为它自动触发了模型的思维链机制。你要是觉得输出太长可以在最后补一句分析过程不超过 200 字。4.5 把常用提示词固化到 AGENTS.md最后分享一个一劳永逸的做法把项目级别的偏好写进 AGENTS.md 文件让 Codex 每次进入项目都自动读取。这个文件里可以放项目技术栈、代码风格、禁止使用的库、测试命令、你需要 Codex 遵守的规则。我自己的项目里AGENTS.md 大致是这样# 项目规则Codex 必需遵守 - 后端目录使用 src/api 和 src/services 分层禁止在 route 中写业务逻辑。 - 数据库字段命名使用 snake_case接口返回字段使用 camelCase。 - 所有错误响应必须符合 src/utils/error.ts 中定义的格式。 - 测试文件放在与源码同级的 test 目录中命名 *.test.ts。 - 修改完代码后必须运行 pnpm typecheck有类型错误要先修再交付。 ## 提示词风格偏好 - 所有回复前先列出将要修改的文件清单等确认后再动手。 - 解释问题时给出具体文件和行号别只说结论。有这份文件之后Codex 在项目里的表现会稳定很多。你可以把 AGENTS.md 理解成公司的新人入职手册它不需要每次对话都重申背景而是让 Codex 自动遵守既定的团队规范。5. 热门问题实测登录、打不开、第三方模型接入、本地代理报错5.1 装完插件打不开或者空白界面先查这三个地方我在网上总能看到Codex 打不开Codex 登录后白屏的讨论自己也遇到过一次。这类问题 90% 出在三个地方按顺序排查基本能解决Node.js 版本过旧Codex 对新版本依赖较多如果本机 Node 还是 16 或者更早请先升级到 18 以上最好直接用 LTS 最新版。你可以在终端运行node -v确认版本。这个问题的典型表现是CLI 能启动但 VS Code 扩展连不上后端服务。VS Code 版本过旧官方扩展对编辑器 API 的依赖较新老版本可能缺少某些接口。把 VS Code 更新到最新版再试一次。登录态失效如果扩展能打开但一直转圈多半是 token 过期。最简单的方式是回到终端运行codex login重新登录再回到编辑器里Reload Window。这个操作路径很关键——很多人直接在编辑器里反复点登录反而是终端里 CLI 的登录态和编辑器不同步导致白屏。5.2 cc switch local proxy failed while handling codex endpoint /responses是怎么回事这个报错最近在社区里被反复贴出来文字很长但核心意思是Codex 在访问/responses端点时本地代理local proxy在切换过程中失败。不要慌这通常不是 Codex 本身坏了而是你电脑上有全局代理或环境变量干扰了它的请求。如果你平时会用一些本地代理工具或者设置了 HTTP_PROXY、HTTPS_PROXY 环境变量Codex 会尝试走这个代理。一旦代理工具恰好处于切换状态或者代理证书不受信任就会出现这个报错。排查步骤我建议这么走先打开终端执行env | grep -i proxy如果显示有http_proxy或https_proxy说明环境变量确实存在。临时清掉环境变量试一次unset http_proxy https_proxy再运行 Codex。如果问题消失说明就是代理干扰。如果你确实需要走本地代理比如公司内网环境那就把 Codex 需要访问的域名加入 NO_PROXYexport NO_PROXYapi.openai.com,localhost让它直连而不是走代理。检查代理工具的证书是否已安装到系统信任区很多时候是 TLS 握手失败导致的。说实话这个报错出现频率最高的场景反而是那种你根本不需要代理但系统里残留了某些环境变量的情况。所以我的建议是先确认自己是否真的需要全局代理不需要就直接清掉别让 Codex 替你做无用的联网转圈。5.3 Codex 接入 DeepSeek 等第三方模型的完整配置最近的另外一个高频问题是Codex 怎么接入 DeepSeek。很多人想让 Codex 的代理能力配上国产模型原因无非是成本考虑或者已有的 API 生态。技术上这件事是可以做的前提是你的 Codex 版本支持自定义模型接口。它的核心是修改config.toml通过配置模型提供方model provider和接口地址来实现。我自己的配置流程是这样1. 找到 Codex 的配置文件终端执行 codex --help 可以打印配置路径通常是 ~/.codex/config.toml。 2. 在配置中新增模型提供方填入第三方 API 的 Base URL 和对应的 API Key 环境变量。 3. 设置默认模型为第三方模型 ID例如 deepseek-chat。 4. 重启 Codex在扩展里重新选择模型后测试。写进config.toml的本地配置大致长这样这是我的简化示例具体字段要以你的 Codex 版本文档为准[model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY [model] provider deepseek name deepseek-chat配置好之后需要先把 DeepSeek 的 API Key 设置到环境变量里比如export DEEPSEEK_API_KEY你的key。这里大家最容易踩的坑是环境变量没有在新开的终端里加载明明 export 了但 Codex 还是提示找不到 key。建议把 export 写入你的 shell 配置文件~/.zshrc或~/.bashrc再重启终端最稳。我实际跑下来的感受DeepSeek 在代码理解和逻辑推理上的表现相当不错特别适合日常重构和代码解释这类任务但在遵守必须跑 typecheck 之后交付这种细粒度约束上偶尔不如官方模型听话。所以我的用法是大而化之的探索性问题用第三方模型省成本需要严格操作的代码修改任务切回官方模型。6. 用了一个月之后的真实体会与建议如果你只看了清单和提示词就准备去装我还想再多说几句真实体验。最重要的一条插件和提示词都不会自动让你进步真正的增量在于你开始用工程化的方式和 AI 协作。以前我写代码思路是脑子里想清楚再敲;现在有了 Codex我的工作方式是把思路拆成任务描述让 AI 去执行我负责审查和纠偏。这个转变的收益不是码字速度变快了而是我可以把精力从重复劳动中抽出来放在设计、架构和方案权衡上。如果你不想一次装满 10 个我给你一个只装 3 个的保底组合官方 Codex 扩展 Error Lens GitLens。三个就能覆盖最核心的闭环下达指令、看到错误、回顾改动。剩余插件等你感受到瓶颈之后再按需补上。最后再分享一个小习惯每次 Codex 给出一个让你觉得惊艳的解决方案我会顺手把当时的提示词和上下文存进一个固定的文档里分门别类。一个月下来我的提示词库已经有四十多条经过实战检验的模板。下次遇到类似场景直接调出来改改参数就能用。你要是有心这个方法带来的长期复利比到处搜热门插件大得多。