最近把主力工作流切到 VS Code Codex 之后最大的感受是Codex 本身确实强但真正让它“好用得卸不下来”的往往是周围那一圈插件。这十来个东西是我反复试装、卸载、再装之后留下的固定组合既有传统工程插件也有专门为 AI 编程工作流服务的提示词管理工具。如果你也装了 Codex 但觉得差点意思或者正在纠结装哪些插件这篇可以直接抄作业每个插件我都附了使用场景和对应的提示词写法。1. 装之前先搞清楚Codex 到底是个什么东西1.1 它不是一个聊天框而是一个能自己干活的代理很多人第一次用 Codex以为它跟普通 AI 插件一样就是个对话窗口你问一句它答一段。实际不是。Codex 的核心定位是“代理式编程”你给它一个任务它能自己读项目文件、定位问题、修改多个文件、执行命令然后把改动结果展示给你。正因为它是代理式工作它对“上下文”的胃口特别大需要读取很多东西项目结构、相关文件内容、终端输出、错误堆栈。这就决定了它跟你用的其他插件之间不是并列关系而是“要用好 Codex得先把它周围的信息渠道铺好”的搭配关系。这也是这篇清单存在的意义。1.2 两个形态CLI 和 VS Code 插件Codex 目前有两条使用线一条是终端里的codex命令行工具一条是 VS Code 扩展。我日常工作大部分都在 VS Code 里完成所以主力是 VS Code 扩展终端 CLI 作为某些需要独立执行场景的备用。两者登录方式是互通的装好 VS Code 扩展后第一次使用会引导登录登录成功后在~/.codex/目录下会生成配置文件包含认证信息和模型偏好。这里提醒一下如果在登录环节遇到 auth token 相关报错大多数是重复登录导致本地凭据状态不一致清掉配置目录重新走一次登录流程基本能解决后面第 5 章会细说。1.3 先想清楚一个问题你要拿 Codex 干什么插件怎么选第一位不是看插件本身而是看你要 Codex 帮你做什么。我给自己做了个分类日常写业务代码需要自动补全、生成样板对应的是自动执行模式改老项目、排查 bug需要先看方案再动手对应的是 plan 模式写测试、写文档、做代码审查对应的是各种提示词模板批量迁移、重构对应的是多文件改动能力不同需求下的插件组合权重完全不同。我下面的清单是基于“日常业务开发 老项目维护 测试补充”这个场景排的你如果纯写新项目有些插件可以晚点再装。2. 10 个装完就没卸过的搭配插件2.1 总览为什么是这 10 个先给个总表格方便按需安装插件核心理由主要作用GitLens代码溯源和 diff 审查让 Codex 的改动可追溯、可 reviewError Lens错误实时内联显示让 Codex 能快速感知问题位置Better Comments彩色注释区分提示词把提示词沉淀在代码里Todo TreeTODO 统一管理把任务标记变成 Codex 上下文Markdown All in One提示词库/文档支持管理你的提示词模板库Prettier代码格式化减少 AI 生成的格式噪音ESLint静态规范检查给 Codex 提供规范反馈REST Client接口本地调试验证 AI 生成的接口代码Test Explorer UI测试集可视化一键跑测试让 Codex 看到结果Code Runner快速脚本执行验证小段逻辑不用开终端这里面没有一个是“AI 插件”但每一个都在给 Codex 铺路。下面分组细说。2.2 第一组代码理解与定位GitLens Error LensGitLens是我最早装上、再也没卸过的插件。它的价值在 AI 时代反而变大了Codex 改完代码我第一反应是看它到底改了什么。GitLens 的 blame 和 inline diff 能直接在编辑器里看到每一行的改动来源配合侧边栏的 commit 历史可以在几分钟内判断这次改动是否合理。我的习惯是给 Codex 下任务之前先选中有问题的代码区间右键用 GitLens 看最近几次提交搞清楚这段代码什么时候引入的、之前想干嘛然后在提示词里把这些信息丢给 Codex。这样它就不会“凭空猜测”历史意图改起来更贴合原有逻辑。注意 GitLens 有的版本会把行内信息铺得很满需要在设置里把gitlens.currentLine.enabled调成只在按住快捷键时显示不然屏幕会很挤。Error Lens则解决一个痛点Codex 经常会在不报错的代码里“自作聪明”补出问题。Error Lens 会把编译错误、TypeScript 类型错误、ESLint 警告、甚至拼写问题直接内联到出错行旁边红色波浪线和错误信息就在眼前。这对 Codex 工作流有两个实际好处第一你把提示词发给 Codex 时可以直接引用 Error Lens 显示的错误文本省得再手动复制粘贴一堆报错第二Codex 改完后你能快速扫一遍当前文件的错误标记是否消除。实测下来配合 ESLint 一起用AI 生成代码的“隐性类型问题”可以缩短排查时间一大半。2.3 第二组提示词家族的“文档三件套”Better Comments Todo Tree Markdown All in One这三件套是我压箱底的习惯。用 AI 编程最大的坑不是提示词写不好而是提示词飘在聊天框里关掉窗口就没了。我把提示词当作“一等公民”来管理靠的就是这三个插件。Better Comments让你能用不同颜色区分注释普通备注、TODO、提醒、不用检查的说明。我会在代码文件头部加一段彩色注释块写明这个文件里面哪些地方是 AI 帮写的、写的时候遵循什么约束。比如# ! AI-GENERATED: 本文件的异常处理逻辑由 Codex 辅助生成 # ? 约束: 不要修改 pytest 现有 fixture # TODO: 后续替换为正式配置中心接入这种注释对后续维护很有价值一段时间后再看文件能立刻分辨哪些是 AI 生成、哪些是手写降低“AI 代码黑盒”的恐慌感。Codex 读文件时也会把这些注释当作上下文生成风格会自觉对齐。Todo Tree会把代码里的 TODO、FIXME 统一收集到侧边栏。我用它维护一个“给 Codex 的任务池”手动写 TODO 注释然后让 Codex 按池子里的标记逐个处理。这样不需要每次打开聊天框重新输入任务背景Codex 自己读项目就能看到 TODO 分布。例如我会在代码里埋这样的标记// TODO: 这里的分页逻辑在数据量超过 5000 时会出现游标重复 // TODO: 需要补一个批量导出失败时的重试机制然后提示词只需说“读取项目内所有 TODO 标记按优先级处理前两个”它就能自己找到位置、理解上下文。Todo Tree 的作用本质上是把任务状态可视化让你随时知道还有多少待办没被 AI 消化。Markdown All in One则是管理提示词模板库的核心工具。我在项目根目录建了一个docs/prompts/文件夹里面按场景存 markdown 提示词模板。Markdown All in One 提供目录生成、自动格式化表格、列表编辑等能力写提示词文档非常顺手。更关键的是Codex 能直接读取这些 markdown 文件。我会在提示词中写“先读docs/prompts/code-review.md按里面的规则审查当前代码”它就完全按照我沉淀的提示词标准来执行。这比每次手打一段提示词稳定得多。2.4 第三组工程化配套Prettier ESLintPrettier是很多人装了就不管的插件但它在 AI 编程时代承担了额外的职责抹平 AI 生成的代码风格差异。Codex 生成的代码常常功能正确但缩进、引号、换行风格不稳定。与其让 Codex“注意风格”不如交给 Prettier 在保存时统一格式化。我的配置是保存时自动格式化 一个.prettierrc统一团队规范。这样就算 Codex 生成的代码乱一点保存后立刻规整。Codex 拿到格式化后的代码做后续修改时产生风格冲突的概率也小很多。ESLint更主动一些它会在代码保存后直接告诉你哪里不符合规范哪里可能出了逻辑问题。很多人觉得 ESLint 是“找茬”的但在 Codex 工作流里它是给 AI 提供反馈信号的裁判。我通常这样配合先让 Codex 改代码改完触发 ESLint 检查然后我直接把 ESLint 报错全选复制给 Codex让它参照报错逐条修正。你可以把这理解为“AI 写代码规则引擎判分然后再把判分结果喂回去迭代”。这种闭环比单纯让 Codex 一次性生成最终代码稳定得多尤其适合 TypeScript 项目。2.5 第四组调试与验证REST Client Test Explorer Code RunnerAI 写代码最大的问题不是写不出来而是写出来的东西你敢不敢直接信。我的原则是Codex 每改完一个功能必须在本地立刻验证。这三个插件是验证闭环的关键。REST Client是在 VS Code 里直接发 HTTP 请求的工具比 Postman 轻量。Codex 写完一个接口我会在旁边建一个.http测试文件写几个请求直接点着试。这个文件的请求记录也可以当作提示词上下文把接口返回值和报错粘贴给 Codex它能立刻调整。Test Explorer UI是测试集成的可视化入口。我配合 Vitest/Jest 用把项目里所有测试用例列在侧边栏一键跑全部或单个文件。Codex 改完逻辑我先跑相关测试红了直接把失败信息复制给它修不红就进入下一步。这比“信任 AI 的代码”靠谱太多。Code Runner则是处理小段代码的利器。当 Codex 给你一段独立的算法片段或脚本时你不用建文件、不跑终端直接选中代码一键执行。我拿它验证 JSON 解析、正则匹配、数据处理逻辑执行结果就地显示。速度非常快大大缩短“AI 生成 → 人工验证”的循环。3. 附带的提示词模板拿来就能用3.1 提示词为什么能“一招吃遍天”很多人以为提示词是魔法咒语写得越华丽效果越好。我自己的体会完全相反给 Codex 写提示词本质上是写“任务说明书”它需要四样东西角色定位、目标、约束条件、输出格式。比如你不该写“帮我看看这段代码”而应该写“你是熟悉 TypeScript 的代码审查者请审查src/services/user.ts的异常处理逻辑重点关注未捕获的 Promise 拒绝输出按严重程度排序的问题列表每条问题给出对应行号和修改建议”。后者听起来啰嗦但 Codex 作为代理执行时指令边界越清楚跑偏概率越低。3.2 可以直接抄的 6 个提示词模板我沉淀了一套自己常用的模板按场景贴出来。注意里面用包住的地方按实际替换。模板一代码审查提示词你是资深代码审查者。请审查 文件名或目录重点关注 1. 是否有边界条件遗漏 2. 是否有不安全的类型断言 3. 是否存在重复代码可以抽取 输出格式 - 问题列表按严重程度排序 - 每条问题附上文件行号 - 最后给一句总体评价不超过 50 个字模板二报错诊断提示词我遇到了以下报错请结合报错上下文分析根因并给出修复方案。 报错文本 粘贴完整的错误堆栈 项目相关文件 列出相关文件的路径和关键片段 注意 - 先分析可能导致错误的 3 种原因 - 再给出最小改动方案 - 不要重构无关代码模板三测试用例生成提示词请为 功能模块/函数名 生成测试用例。 要求 - 覆盖正常路径、边界值、异常输入三种情况 - 测试命名用 given_when_then 风格 - 不要 mock 掉被测函数的内部依赖除非依赖是网络或时间 - 输出可直接运行的测试文件模板四代码解释提示词请逐段解释 文件/代码块 的实现逻辑。 要求 - 按函数粒度分段 - 每段说明输入、输出、副作用 - 对复杂度高的逻辑用生活化类比解释 - 标注最容易踩坑的地方模板五批量修改提示词请帮我在 整个项目或目录 范围内做以下修改 修改需求 约束 - 只修改与需求直接相关的文件 - 所有改动必须保持现有导出的接口不变 - 改完列出所有涉及的文件和改动摘要 - 不要顺手做格式化或重构模板六项目结构分析提示词请分析当前项目的整体架构输出一份 markdown 报告。 报告中需要包含 1. 项目技术栈和关键依赖 2. 主要模块划分 3. 数据流向 4. 可扩展点和可优化的技术债点 5. 如果我要新增 某功能应该改哪些文件这些模板有一个共同点全部给了“输出格式限制”和“动作边界”。Codex 是代理式执行给它的边界越清晰出活越稳不会跑着跑着去把你其他无关模块也重构了。3.3 提示词工程的三条红线我踩过几个大坑总结成三条红线第一不要同时给多个目标。你在一条提示词里既让它“修复 bug”又让它“优化性能”又让它“补充注释”它往往会在某个目标上发挥过头。最好一条提示词只干一件事。第二不要让它处理没给上下文的代码。Codex 能自己读文件但不代表它知道你心里的预期。你至少要告诉它“这个模块的作用是什么、你期望它做什么”否则它会按自己的理解发挥。第三不要用“你应该”式模糊指令。比如“你应该更稳健一点”等于没说。要量化改成“所有网络请求需要设置 5 秒超时并捕获超时异常”。4. 一次完整的实操从装好到改完一个 bug4.1 场景设定与初始提示词纸上谈兵没用我给你还原一个真实的操作现场。假设项目里有个老 Python 脚本解析 JSON 时偶尔崩我需要用 Codex 找到根因并修复。第一步不是打开聊天框而是先做信息收集用 Error Lens 查看当前文件有没有高亮问题用 GitLens 看这段解析代码上次改动时间然后写提示词你是熟悉 Python 的调试专家。请分析 scripts/import_data.py 中 JSON 解析偶发崩溃的问题。 我观察到每天凌晨跑批时约 2% 的任务失败错误日志指向 json.loads 附近但本地复现时不是每次都能触发。 请 1. 先阅读整个文件理解数据来源和处理链路 2. 找出可能导致偶发异常的关键路径 3. 给出可以复现问题的建议方式 4. 最后给出修复方案并直接修改代码这里我刻意没有粘贴报错信息而是让 Codex 先读文件找可疑点。因为错误日志指向的地方不一定就是根因让 AI 从头看一遍链路反而更容易发现前置环节的问题。4.2 Codex 的处理过程与中途介入Codex 在 plan 模式下的回复很快它先分析了文件结构定位到json.loads的输入是另一个接口返回的字符串然后引用了一个之前没注意的细节——那个接口在超时时会返回一个空字符串而空字符串用json.loads不会抛异常但代码里对解析结果取了多层嵌套的 key有个单独的逻辑在目标 key 不存在时会抛 KeyError这个异常在本地没有稳定复现的特性因为只在接口超时的那几次出现。它给了修复方案解析前先判断输入是否为空并对缺失 key 做默认值兜底。我切换到 execute 模式让它修改。这个过程中我没有放它一个人跑而是在它改完第一个文件后暂停用 GitLens 的 diff 看了一眼改动确认影响边界只在import_data.py内部才让它继续改调用的测试文件。4.3 验证闭环与沉淀改完之后我没有直接收工。用 Code Runner 跑了几个本地构造的边界样例空字符串、key 缺失、正常数据。然后写了一条带着结果的反馈提示词我按修复后的代码跑了三个样例 1. 空字符串输入 - 正常返回空列表 2. 缺失主键 - 返回默认值 3. 正常数据 - 正确解析 其中第 1 个样例实际输出是 []但我期望的是 None。请调整返回策略并同步修改测试文件中的断言。这样就形成了“写代码 → 验证 → 反馈 → 修改”的闭环。很多用 Codex 的人只走到第一步改完就跑然后出了问题再回来骂 AI 不行。实际上代理式 AI 的产出必须搭配你亲手验证的那一步才能把置信度提上去。最后我还在文件头部用 Better Comments 写了一段注释记录这次修复的原因和验证方式方便半个月后的自己快速回忆。5. 常见问题排查与避坑实录5.1 高频安装与使用问题整理一个排查表都是我真实遇到过的问题问题原因解决办法插件装上但活动栏不显示VS Code 版本过低或扩展冲突升级 VS Code 到最新禁用其他 AI 类插件后重启登录时报 auth token is unavailable本地认证状态被覆盖或过期删除~/.codex/下认证文件重新登录Codex 能对话但无法读文件工作区信任被关闭检查 VS Code 工作区信任设置确保当前项目处于信任状态提示词写了但 Codex 只回一小段上下文窗口被占满换一个新会话先让它读关键文件而不是全部文件生成代码格式混乱没有配置格式化装 Prettier 并开启保存时自动格式化代码质量参差不齐ESLint 未接入安装 ESLint 并配置扁平化配置文件让 Codex 看检查结果迭代Codex 与 Copilot 同时抢补全两个 AI 插件都开着按场景切换同一时间只启用一个5.2 第三方模型接入的注意点Codex 本身默认连接官方推理接口但也可以在配置里指定第三方兼容的模型接口。操作上一般是通过环境变量或~/.codex/config.toml设置模型提供方、密钥和模型名称。注意三件事第一接口要严格兼容 Codex 预期的请求格式不是所有声称“兼容”的都真的能跑通接完先跑一条最简单的问题验证。第二模型能力差异很大能跑通不代表效果一样建议把复杂任务拆小了再试因为弱模型在长链路任务上容易丢掉中间上下文。第三如果换了模型之后出现异常行为最优先的做法是切回默认配置别在第三方模型上调来调去浪费时间。5.3 我和这些插件之间的“相处之道”最后说点关于插件跟人之间的事。插件不是装得越多越好尤其是 AI 类插件装多了互相干扰严重。我的原则是“让一个 AI 做主力其他全关掉”。Codex 做主力代理Copilot 或 Cursor Tab 这种补全型 AI 偶尔在短代码场景用但同一时间绝不两个都开着否则你会看到两个 AI 在同一个文件里互相打架。其次是插件的配置也要用起来才有意义。很多人装了 Error Lens 但开着默认配置嫌弹窗多装了 GitLens 但没养成看 blame 的习惯。我的建议是每装一个插件花二十分钟调一调设置把它真正融合到自己的工作流里然后再决定是卸载还是留下。装完不卸只是结果“装完真的在用”才是关键。我在实际用 Codex 的过程中体会最深的一点是工具越强人越要把住“验收”这一关。代码是 Codex 写的但跑不跑得起来、边界兜不兜得住最终负责的是你。这套插件组合的意义不在于让 Codex 显得多厉害而在于让我能高效地验证它、约束它、复盘它。如果你才刚开始用 Codex可以从 GitLens、Error Lens、Code Runner 这三个装配起等流程跑顺了再逐步补上提示词三件套和工程化配套。后面等这套工作流玩熟了你大概率也会找到只属于你自己的那一份“装完就没卸过”的清单。