用 Codex 一年多了从命令行一路用到桌面版和 VS Code 扩展我最大的感受是Codex 本身再强也要靠周围一圈插件和提示词才能把效率真正拉满。很多人装上 Codex 就急着让它写功能结果没两天就放弃了——不是 Codex 不行而是周围的插件生态没搭对。今天把这 10 个我装了挺久都不舍得卸的插件整理出来每个都配上我自己实际在用的提示词全部给到可以直接复制的那种。这篇文章既不谈玄学也不堆名词就是我个人的真实选型记录和避坑笔记。准备折腾 Codex 的同学或者已经装了但总觉得差点意思的朋友可以按这个清单照抄再根据自己的项目做调整。1. 选插件前先想清楚Codex 要的是“补位”不是“重复造轮子”1.1 Codex 的强项与短板Codex 现在能做的事很多读项目结构、改代码、跑命令、根据报错自查自修甚至帮你把一整个模块从零搭起来。它的强项在于对代码语义的理解和大范围改动的能力这两点让它在 AI 编程工具里属于第一梯队。但真正用一段时间就会发现Codex 有几个天生短板。第一它生成的代码风格不一定符合你项目的既有规范缩进、引号、换行可能全都不一样第二它改完代码之后你有没有快速确认到底改了什么的手段直接决定你敢不敢让它放手干活第三它写接口、写页面很在行但写完之后的验证环节——请求长什么样、服务能不能起、依赖齐不齐——它不会替你主动搞定。这些短板恰恰是 IDE 插件生态最擅长补的位置。1.2 我选插件的三条原则插件不是越多越好我选的时候只看三条。第一条每个插件必须解决一个明确痛点。装上去用不到两次的直接删。像有些花哨的主题、状态栏美化对我的 Codex 工作流没有任何帮助一律不装。第二条优先选和 AI 工作流互补的插件。Codex 负责写插件负责管。比如 GitLens 负责让我看清 AI 到底改了什么Error Lens 负责让报错直接出现在眼前ESLint 和 Prettier 负责把 AI 生成的代码拉回团队规范。这些插件不是替代 Codex而是给 Codex 的行为兜底。第三条提示词必须可持续积累。同一款插件配上不同的提示词效果天差地别。我的做法是在项目根目录建一个PROMPTS.md把常用的提示词模板全部沉淀下来每次让 Codex 干活之前先让它读一遍效果比临时想一句帮我改改好太多。2. 十个装了就没卸过的插件每个都有固定提示词2.1 AI 工作流三件套官方扩展、Continue、Cline 怎么分工先说我平时主力用的三个 AI 相关插件这三个我把分工分得很清楚避免功能打架。Codex 官方 VS Code 扩展是我最常用的入口。CLI 适合批量扫目录、跑全局重构但在编辑器里逐文件对话、看 diff、选改还是不改GUI 要顺手得多。官方扩展把对话放在编辑器侧边Codex 生成的修改会以 diff 形式摊开你可以逐行采纳也可以整块回退这种可掌控感是命令行里没有的。我日常的提示词是这样的先从项目根目录读一下 README 和 package.json弄清当前技术栈 然后解释我选中的这段代码到底在干什么指出可能的边界问题和隐藏缺陷。 先给分析结论不要直接动手改。Continue是我用来兜底的第二款 AI 插件。它的特点是开源、可配多种模型短平快的解释、补全任务可以用它来跑不占用 Codex 的高价值调用额度。Continue 的context机制也方便能把当前文件、目录甚至整个仓库变成上下文喂给模型。我一般用它做代码讲解和单函数补全用最直白的话解释这个函数就当给刚入行的同事讲。 讲完别停列出这个函数在哪些输入下会出问题。Cline则是自主代理路线的代表。Codex 偏向对话式编码Cline 偏向任务规划型执行你给它一个目标它可以自己决定改哪些文件、执行哪些命令。它的执行过程记录得很完整每一步都有日志适合帮我实现某个模块的全部单测这种多步骤任务。我用 Cline 的提示词通常长这样这是一份 requirements.md 需求文档。请先拆解成不超过 5 个实施步骤 每完成一步先停下来总结当前状态和验证方法不要一口气把所有文件改完。2.2 代码质量四件套让 Codex 写出来的代码不至于乱AI 生成的代码最容易出问题的地方不是功能而是质量。这四款插件是我专门用来管Codex 产出的。ESLint是把隐性质量问题显性化的关键。Codex 生成的代码通常能跑但不一定符合规范。装了 ESLint 之后所有未定义变量、未使用的引入、不合理的写法都会直接标红。我更看重的是让 Codex 自己修 lint 错误提示词里必须写清楚约束运行 npx eslint src/**/*.js 拿错误列表逐个修复。 约束不能改变业务逻辑不做额外重构每修一处用一句话说明原因。Prettier负责统一格式。很多人觉得格式化是小问题但在团队协作里格式不统一会产生大量噪音 diffCodex 真正改了什么反而被淹没。Prettier 装好后把默认格式化器指到它保存即格式化问题就少了一大半。配合提示词提交之前先运行 prettier --write 处理所有改动文件 然后 review 格式化产生的 diff把真实改动和格式噪音区分开。Error Lens是我觉得被低估的一款。它把编译错误、lint 警告直接内联显示在代码行尾不用鼠标悬停过去才能看到。配合 Codex 时尤其好用你把 Error Lens 标出来的错误原样发给 Codex它理解上下文的速度会快很多。提示词执行为针对当前文档里所有高亮错误按优先级输出三件事错误原因、影响范围、最小修复方案。 不要贴大段代码直接给每个错误的结论和一行修复建议。GitLens是我审查 AI 改动时的底牌。Codex 帮你改完代码你第一反应应该是它到底动了什么。GitLens 能把每一行代码的作者、提交信息、改动历史全部可视化配合 diff 视图看 AI 的改动心里踏实很多。我让它写提交信息的提示词基于 git diff --staged 的改动写一个符合 Conventional Commits 规范的提交信息。 要求体现改动模块和影响范围不超过 80 个字。2.3 工程效率三件套把验证和交付环节补上写代码只是前半段后面还有验证、交付、收尾这三款插件解决的就是这些事。REST Client是 Postman 的轻量替代品。Codex 写完接口之后你总得真的发起一次请求试试吧REST Client 用.http文件组织请求请求带什么 header、什么 body 一目了然而且这个文件本身是纯文本可以直接让 Codex 生成和维护。我的提示词根据 routes 目录下的路由文件生成一个 api.http 测试文件 包含所有接口的 GET/POST/PUT/DELETE 请求示例补上必要的 headers 和 JSON body 统一使用 http://localhost:3000 作为 base url。Docker扩展解决的是环境一致性问题。Codex 写代码通常在你本地环境跑得欢但换个机器就各种缺依赖。装上 Docker 扩展后我会让 Codex 顺手生成 Dockerfile 和 compose 文件需要验证环境的时候一键起容器。给 Codex 的提示词为当前项目写一个多阶段构建的 Dockerfile。 开发阶段保留 devDependencies生产阶段只装 prod 依赖。 写完解释每一层的作用别让我猜。Todo Tree则是 AI 时代的收尾神器。Codex 干活时经常在代码里留 TODO、FIXME、HACK 标记这些标记散落在各个文件里时间一长就忘了。Todo Tree 会把它们统一收集成树状清单标红高亮让你一眼看清哪些是遗留风险。配合提示词扫描整个项目的 TODO 注释按文件分组输出任务清单 标注每个 TODO 的优先级、涉及模块和可能的影响点。2.4 提示词速查表10 个插件对应的复制即用模板上面每个插件都配了一段提示词这里整理成速查表方便直接收藏。插件核心用途一句话提示词要点Codex 官方扩展编辑器内对话、逐行采纳 diff先读项目结构再分析选中代码的意图和边界问题Continue轻量解释、补全多模型切换用新人能懂的话解释函数并列出出错场景Cline自主规划多步实施任务拆解步骤每完成一步停下来总结状态ESLint代码规范显性化只修 lint 错误不改业务逻辑Prettier格式统一先格式化再区分真实改动与格式噪音Error Lens内联报错提示按优先级输出错误原因、影响范围、修复方案GitLens代码历史与 diff 审查基于 staged diff 生成规范的提交信息REST Client接口快速验证根据路由生成完整 .http 请求文件Docker容器化环境生成多阶段 Dockerfile 并解释每层用途Todo TreeTODO 标记管理扫描项目 TODO按文件分组输出任务清单3. 实操从安装配置到插件协同完成一个真实任务3.1 安装与最小配置5 分钟搭好基础环境先搞定基础环境。打开 VS Code 扩展市场把上面 10 款插件逐个搜索安装这一步没什么难度。重点在配置。第一件事把 Prettier 设为默认格式化器。在 VS Code 设置里搜defaultFormatter选择 Prettier再打开保存时格式化editor.formatOnSave这样 Codex 生成的代码写出来就是统一风格。第二件事设置 ESLint 为工作区校验工具。安装 ESLint 插件后如果你的项目里没有.eslintrc配置文件第一次运行会报错。我会让 Codex 先生成一份基础配置提示词是根据当前项目技术栈生成一份 ESLint 配置支持 JavaScript 和 TypeScript规则不要过于严格。第三件事准备 API Key 或登录 Codex 账号。官方扩展装好后在扩展设置里填好凭证。如果走第三方模型接入需要确认三项配置端点地址、模型名称、密钥。这三项必须完全匹配错了任何一个都会导致请求失败报错信息各不相同后面排查部分我会细说。第四件事建一个PROMPTS.md文件把上面 10 段提示词全部存进去。以后每次开新任务先让 Codex 读这个文件再提具体需求。3.2 完整案例用四类插件协同实现“Todo API 模块”我拿一个真实场景演示整套流程在后端项目里实现一个 Todo API 模块包括增删改查四个接口并且要跑通验证。第一步让 Codex 官方扩展写代码。打开侧边对话发送提示词阅读 PROMPTS.md然后为当前项目实现一个 Todo 模块 包含新增、列表、更新、删除四个接口使用项目现有的路由风格和存储方式。 代码要符合项目的 ESLint 规则。写完后列出生成的文件清单。Codex 会读出项目结构按你项目的现有风格生成代码并直接以 diff 形式展示。我会先快速逐行扫一遍重点看它有没有引入不存在的依赖。第二步跑 lint 验收。打开终端执行npx eslint src/八成会有几个报错。把错误列表复制给 Codex这是 lint 报错列表。逐个修复不要改业务逻辑修完解释每一处为什么这么改。此时 Codex 会定位到具体行做最小修复不会顺手重构。这一步验证的是质量兜底。第三步用 REST Client 验证接口。切换到我常用的.http文件问 Codex为 Todo 模块生成 api.http 测试内容包含新增、列表、更新、删除四个请求用 localhost:3000。生成之后点一下Send Request四个接口的真实响应会立刻显示。如果哪一步返回 500直接把响应报文丢给 Codex 让它查。第四步用 GitLens 审 diff 并提交。全部验证通过后我看一眼 GitLens 面板里的文件改动确认没有误删误改。然后让 Codex 写提交信息基于 git diff --staged 生成提交信息遵循 Conventional Commits结构为 type(scope): summary。列出改动文件。这一步走完一个功能从写到验证到提交全部在 Codex 插件组成的闭环里完成。4. 装完不好用的常见问题与排查记录4.1 插件明明装了却完全没生效这是装完插件后最常遇到的问题。如果你发现某个插件行为异常第一件事不是重装而是按下面顺序排查。先看版本兼容性。VS Code 插件市场里的版本和你的 VS Code 版本不匹配时插件会静默失效。检查方式是在扩展列表里看有没有黄色警告图标。接着看主设置里有没有被覆盖。特别是 Prettier 和 ESLint如果有多个相关插件同时抢一个能力设置会被后来的覆盖掉。最后记得重新加载窗口CtrlShiftP输入Reload Window能解决大部分加载不完整的问题。还有一个我踩过的坑工作区信任。如果你打开的是不受信任的文件夹VS Code 会限制插件权限很多功能会直接不启动。在操作系统的提示里选择信任此文件夹即可。4.2 多个 AI 插件同时开着上下文互相打架装了 Codex、Continue、Cline 之后很容易出现一种混乱三个插件都在同一份代码里给出建议你也不知道听谁的。我的处理方式是给每个插件定义明确的职责边界。Codex 负责主线功能开发和重构Continue 负责短平快的解释、翻译、单函数补全Cline 负责需要多步骤规划的自主执行任务。这是分工。技术层面也要防干扰。Continue 默认有自动补全功能在某些环境下会抢占 Tab 键影响 Codex 的修改体验。如果你不需要把它的自动补全关掉。Cline 默认可能会读取大量文件作为上下文如果和 Codex 同时开可能造成两个工具的上下文不一致。建议同一时间段只让一个自主执行型插件的文件读写权限开启。4.3 提示词越写越不灵问题出在这三点同样的插件别人的提示词好用你的不好用多数是三个原因。第一个提示词太宽泛。帮我优化代码这种话模型拿到后根本不知道优化目标是什么。正确写法要包含范围、约束、输出格式。对比一下没约束的版本帮我优化这段代码。 有约束的版本优化 src/utils/format.ts目标是把字符串格式化逻辑抽成单独函数不改变导出接口完成后输出改动文件列表和测试建议。第二个缺少负面约束。AI 默认会做他认为合理的事比如顺手升级依赖、顺手改函数签名。如果不加不要改动 A、不要升级 B这类限制它经常跑偏跑偏后再回退反而浪费时间。第三个没有给出输出格式。你想要表格、清单、还是直接脚本提示词里不写模型就自由发挥。我现在的习惯是每次都在提示词末尾追加一句输出格式先用列表说明思路再给代码。4.4 接入第三方模型端点时的检查清单Codex 默认用官方服务但很多人会把它接到第三方模型服务上。如果你改了端点配置后请求一直失败按四项检查。第一端点地址是否正确。改了新的地址后尾部路径到底带不带额外字段必须严格照接。第二模型名称是否精确匹配。模型标识符差一个点、差一个后缀都会直接报错。第三密钥配置是否存在多余空格。复制粘贴时最容易带进来看不到的空格字符。第四确认你设置的模型是否支持 Codex 需要的请求格式。有些兼容接口的返回结构字段名不一样Codex 解析不了就报错。提示排查这类问题先把日志输出级别调到 debug看清楚实际发出的请求参数再逐项比对远比反复重启工具高效。我在实际使用中还有一个体会装插件这件事少而精永远比大而全靠谱。每装一个新插件我都会问自己一句它能替代我现在哪个操作步骤如果答不上来就果断卸掉。最后再分享一个小技巧团队协作时把PROMPTS.md放进仓库里所有人共用一套提示词模板Codex 在不同人手里产出的代码风格会稳定很多。这套插件组合我用了很长时间期间换过很多工具唯一没动的就是这份清单。