第一周用 Codex 的时候我几乎每天都在装插件——别人说好用的装热榜上排前面的也装结果装了二十多个最后真正稳定留下来的只有 10 个。这个筛选过程让我想明白一个问题Codex 这类工具插件的价值不是越多越好而是要和它的工作方式形成互补。我写这篇不是给你罗列热门列表而是把这 10 个我装完就没卸过的东西讲清楚它们解决什么问题、怎么配提示词、踩过哪些坑。文章里每个插件都会附一段可以直接抄的提示词适合正在用 Codex 做日常开发、又不想在插件海洋里迷失方向的人。1. 先分清一件事Codex 的插件到底在哪一层Codex 的核心能力是自然语言改代码但这个能力特别吃上下文。你给它一个清晰的仓库结构、一段明确的变更要求它就能干得又快又准反过来如果你只是在对话框里丢一句帮我优化一下它大概率会给你一份泛泛的建议离真正能落地差很远。所以围绕 Codex 的插件本质上是两类事一类帮它把上下文做得更清楚另一类帮你把指令传达得更准确。搞懂这一点选插件就不会被花哨的名字带偏。1.1 Codex 是重上下文依赖的智能体工具这里简单补一句背景方便刚接触的人对齐。OpenAI Codex 目前的形态有 ChatGPT 内置的 Agent、命令行工具以及集成到 IDE 里的扩展。它可以读取当前代码库、修改文件、执行命令也可以跑测试。但它的推理能力不等于知道你脑子里的正确方案。你给它多少上下文它就能给你多少回报。比如改一个接口的返回结构它需要知道调用方有哪些、测试怎么跑、有没有历史约定。这些信息如果不在对话里它只能靠猜。1.2 我给 Codex 的插件划了三层这里说的插件不只是 VSCode 扩展市场里那类安装包我按用途把它分成三层编辑器层这类插件主要负责让代码里的问题显形比如错误提示、Git 变更展示、注释分类。它们不直接参与 AI 生成但给 Codex 提供了高质量的视觉信息。智能体层包括官方 Codex 边栏、Continue、Cline、Aider 这类工具。它们有些是独立于 Codex 的兄弟产品但在同一个工作流里可以分工一个负责大刀阔斧重构一个负责行内补全一个负责跑 CLI 小任务。提示词层这层最容易被忽略。提示词不是一次性写句聊天开头而是应该沉淀成文件、模板、注释和任务清单让 Codex 每次都能稳定读取。这也是我这篇文章把插件和提示词放在一起讲的原因。1.3 我的选型标准不折腾、不打架、不锁死网上很多插件评测只看功能强不强我自己的标准更朴素装完不卸得满足三条。第一是不折腾安装配置在十分钟内搞定文档齐全不会有莫名其妙的依赖问题。第二是不打架尤其是智能体层的工具绝对不能同时让两个 Agent 去抢同一个文件的写权限否则你就等着看代码被来回覆盖。第三是不锁死插件依赖的模型服务、账号体系尽量可替换这样哪天 Codex 策略变了我还能平滑切到别的工具而不是被某一个插件绑定。这三点说起来容易实际筛选时很费时间。下面这 10 个就是在这么严格的标准下留下来的。2. 我装完就没卸过的 10 个插件清单先放一张总表方便你对照自己缺什么。后面我再把每一类展开讲。插件/工具定位我为什么留它官方 Codex 扩展编辑器内直接对话原厂能力改代码时最顺手Continue多模型补全与对话补 Codex 的空档快速行内补全Cline开源智能体把子任务拆出去省上下文额度AiderCLI 结对编程轻量改文件、自动生成 commitError Lens错误内联展示让 Codex 和人都能一眼看到问题GitLens代码历史与责任人给 Codex 提供为什么这样写的背景Better Comments注释分级高亮把提示词直接写在代码注释里Todo Tree任务清单可视化把 TODO 变成可追踪的提示词卡片Markdown All in One写文档和提示词文件维护 prompt 库和说明文档AI Commit自动提交信息配合 Codex 生成的 diff 快速收尾2.1 编辑体验组让问题先于 Codex 显形先说 Error Lens。装之前我一直觉得 VSCode 自带的问题面板够用了装完之后才发现自己是看不见问题所以不修的典型打开文件只有左下角有个数字根本不知道红线在哪。Error Lens 把错误、警告直接渲染到对应代码行后面红色波浪线加文字说明一眼扫过去就知道哪里有问题。对 Codex 的帮助是间接的你在对话框里让它修当前文件所有报错它能从你的描述里知道范围但更关键的是你自己先看见了错误任务描述才会具体——是类型错误还是空指针描述越具体生成结果越靠谱。GitLens 则是给 Codex 喂背景信息的神器。很多时候 Codex 不知道某段代码为什么长这样哪次提交加的、作者是谁、当时 commit message 写了什么。GitLens 把 blame、历史、分支信息内联在代码里我只要复制一条带 commit 信息的链接或者贴一段历史摘要给 Codex它就能理解为什么要保持兼容这类潜规则。GitLens 功能很重我只用了 blame 和 history 两个模块关掉其他花哨视图保持界面干净。Better Comments 是我私心很重的一个。它把普通注释按类型上色! 开头是红色警告? 是疑问TODO 是橙色* 是高亮关键信息。我习惯在代码注释里直接写提示词片段比如? 这里接口返回结构变更后调用方是否需要同步改Codex 读代码时把这些注释当成上下文。搭配官方扩展的解释代码功能效果比直接让 AI 瞎猜好太多。2.2 AI 协同组一个主刀两个助手官方 Codex 扩展是主刀。现在 OpenAI 官方在 VSCode 里有 Codex 边栏和面板登录账号后可以直接选中代码、描述需求让它在当前项目里执行。我留它是因为原厂协议最稳定——第三方 Agent 经常要猜 Codex 插件内部逻辑官方扩展则能直接读当前工作区、跑命令、生成 diff配合 AGENTS.md 文件也最自然。Continue 是我用来补空档的。Codex 擅长整段任务但行内补全、快速解释某一行、问一个小问题这些轻量操作用 Codex 有点杀鸡用牛刀。Continue 支持多模型我在它里面接到本地模型或便宜的模型上专门处理高频小需求省 Codex 的请求额度也不打断主对话。两者不冲突的关键在于Continue 只负责商量Codex 负责动手写文件。Cline 和 Aider 我归在一起说。Cline 是一个开源智能体可以读文件、执行终端命令、把改动直接写入代码Aider 则是终端里的结对编程工具擅长小步重构和 git 提交。我的用法是遇到一个明确的小任务比如把 utils 里的时间处理函数统一改成 dayjs 写法我把这个任务丢给 Cline 或 Aider 去跑Codex 专心做更难的业务逻辑。这样做的收益是隔离风险——万一小任务跑砸了它只影响一个小 commit不会把 Codex 的大改动一起带崩。2.3 工程辅助组让提示词和任务都长出手脚Todo Tree 是我每个项目必装的。它的机制很简单把代码里的 TODO、FIXME 注释聚合成一个侧边栏列表点一下就能跳到对应位置。我用它做的事是给 Codex 派活之前先建任务清单在代码文件里写TODO: 增加分页参数注意保持旧接口兼容然后让 Codex 读 TODO 列表挨个处理。这样任务描述不在聊天框里丢失而是沉淀在代码里相当于给 AI 做了一个待办队列。Markdown All in One 是维护提示词文档的好帮手。我用它写项目根目录的 PROMPTS.md、操作手册、架构说明因为它支持自动目录、表格、列表格式化写出来的文档 Codex 读起来清晰人看起来也不累。很多提示词失效不是模型不行是文档本身层级混乱模型抓不住重点。Code Runner 则是验证闭环里的一环。Codex 写完一段核心算法或脚本我经常不需要走到启动整个项目直接用 Code Runner 在编辑器里跑一下这段代码看输出对不对。它支持多种语言一键运行省去切终端、配环境的折腾。有了它Codex 的生成质量能被快速反馈我可以马上把报错贴回去让它修。最后是 AI Commit。Codex 改完代码后git diff 往往很长手写 commit message 很费神。AI Commit 能读取当前 diff生成符合 Conventional Commits 风格的提交信息。我配合一个固定提示词模板要求它总结变更意图写清楚影响范围生成的 message 基本不用改。3. 每个插件怎么配提示词10 个可直接抄的模板提示词这东西很多人把它想得太玄。其实本质就三段角色、任务、约束。角色告诉 Codex 按什么身份和语气回应任务说清楚要做什么、范围是什么约束限定输出格式、不要做的事。有了这个框架不管给哪个插件配提示词都不会跑偏太远。3.1 提示词不是聊天是配置文件我的建议是把常用提示词当成代码来看待要版本管理、要写清楚输入输出、要能复用。不要每次在对话框里手打一遍。下面这些模板直接抄进对应插件或提示词文件里就能用。每个模板我都刻意控制长度因为太长反而会让模型抓不住重点后面避坑部分我会详细说这个现象。3.2 十个提示词模板下面这十个模板覆盖了日常最高频的场景前两个是全局型的后面八个是任务型的。你不需要全部用挑和项目最匹配的几份放进去就够。模板1全局角色设定给官方 Codex 或 AGENTS.md 你是一名资深后端工程师熟悉 Python/TypeScript 和当前仓库的技术栈。 在回答任何问题前先阅读项目根目录的 README 和 AGENTS.md。 所有建议都要落到具体文件路径禁止只给泛泛方向。 如果信息不足先提问再动手。模板2代码审查配官方 Codex / Cline 请审查当前 git diff按以下顺序输出 1. 潜在 bug 和边界条件问题 2. 可读性和命名问题 3. 性能隐患 4. 测试覆盖建议。 每条必须带文件路径和行号。不要修改代码只做审查。模板3生成 commit message配 AI Commit 读取当前 git diff用 Conventional Commits 风格生成 3 条提交信息候选项。 要求第一行不超过 50 字正文写清楚变更动机和影响范围。 不要包括update/修改这类无信息量动词。模板4重构指定函数配 Cline 或 Aider 对 src/utils/date.ts 中的 formatDate 函数做以下重构 - 用 dayjs 替换原有 Date 操作 - 保持函数签名不变 - 更新所有调用方 - 运行相关测试确认不破坏。 每次只改一个文件改完输出 diff 摘要。模板5写单元测试配 Continue 或 Codex 为 src/services/userService.ts 新增测试覆盖 - 正常创建用户 - 重复邮箱报错 - 密码过短报错 - 数据库异常时返回 500。 测试使用 vitestmock 掉数据库层断言不要过于琐碎。模板6从 TODO 列表派活配 Todo Tree 读取整个仓库中所有 TODO 注释按严重程度排序 逐个生成处理方案。每一项都要包含 - TODO 所在文件与行号 - 问题说明 - 建议改法 - 改动风险。 先不要直接改等我确认。模板7解释遗留代码配 Continue 解释 src/legacy/order.ts 中 parseOrder 函数的作用 重点说明 - 输入格式和异常情况 - 目前调用了哪些全局变量 - 如果废弃它有哪些替代方案。 用条目输出最后给一段 5 行内的总结。模板8生成接口文档配 Markdown All in One 工作流 根据 src/api 目录下的路由定义生成 OpenAPI 风格接口文档。 每个接口包含路径、方法、请求参数、响应示例、错误码。 文档写入 docs/api.md使用 Markdown 表格。模板9修复当前文件的报错配 Error Lens Codex 请分析当前打开文件中所有 Error Lens 标记的错误 按严重程度从高到低修复。每修完一个说明原因。 对于警告warn只在影响运行结果时处理。模板10写下周计划配 Todo Tree Markdown All in One 根据 PROMPTS.md 中记录的迭代计划把下周要做的功能拆成 - 每个任务一句明确描述 - 关联涉及的文件路径 - 预估难度低/中/高 - 输出为 TODO 注释格式方便 Todo Tree 识别。这些模板看着简单但真正起作用的是固定格式。Codex 这类模型对结构化输入特别敏感你把输出格式规定好了它的回答就不会发散。如果项目里有特定规范比如数据库迁移必须带版本号、接口必须写校验直接在模板里追加约束越具体越稳。还有一个小经验模板里的禁止条款要写得像动作而不是态度比如禁止只给泛泛方向就比不要敷衍有效得多因为模型能对比目标状态。4. 两个关键配置让 Codex 和提示词真正连着干活插件装好了提示词也有了接下来还有两个配置能决定体验上限一个是 Codex 的模型接入一个是提示词文件的组织形式。这两件事不做好前面抄的模板会经常失灵。4.1 config.toml接不同模型的办法Codex CLI 支持通过配置文件切换模型供应商。很多朋友只知道官方模型其实它支持 OpenAI 兼容格式的服务商这样可以用到如 DeepSeek 或其他更便宜、更快的模型。配置文件一般在~/.codex/config.toml我的写法是model deepseek-chat [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat然后在环境变量里配置DEEPSEEK_API_KEYCodex 就会把请求发到对应服务。这里有个坑不同模型的工具调用格式不完全一样官方模型支持的功能最多第三方模型可能对某些复杂操作支持不到位。所以我的建议是日常问答、写小工具、生成文档用第三方模型涉及大规模重构、多文件改动、跑命令这种高风险操作还是切回官方模型。模型切换不会丢失对话历史但切换后建议把关键背景再强调一遍因为不同模型的上下文理解习惯有差异。这里说一句容易误解的点base_url 直接填模型服务商官方给出的接口地址就行Codex 本身就把这个配置设计成填地址即可用的模式不需要额外做任何网络设置也不要去动系统层面的转发工具。4.2 AGENTS.md把提示词变成项目的一部分Codex 和很多智能体工具都支持读项目根目录下的 AGENTS.md有的工具也认 CLAUDE.md 或类似配置文件。我把常用提示词、项目规范、命令清单都写在这里让模型每次一开始就自动吸收。比如我会在 AGENTS.md 里写项目结构说明哪些目录是核心逻辑、哪些是构建脚本命令规范测试用pnpm test构建用pnpm build代码风格约定接口返回统一{ code, data, message }常见提示词入口调用PROMPTS.md里的模板。这样配的好处是你不用每次在对话框里把我们项目用 pnpm测试写法是……重新交代一遍模型自己会读文件。省下来的上下文空间能做更复杂的推理。4.3 上下文瘦身别把插件输出全塞给 Codex插件多了以后最隐蔽的问题是上下文膨胀。GitLens 能贴历史、Todo Tree 能列任务、Error Lens 能显示所有警告如果这些信息一股脑全粘进 Codex 对话很快 token 就超了模型开始丢前面的指令。我自己的处理原则是贴给 Codex 的信息控制在当前任务相关的范围内。比如做接口修复就只贴接口文件、调用方、最近的 git log 三样做全局重构再考虑贴文件树和模块依赖图。少贴多问遇到模型信息不够它会主动问你要这时候你再补充比一次性把仓库全甩给它强得多。5. 避坑实录插件越多越容易翻车的三个典型场景这部分是我实际踩过的坑不是网上抄来的经验。如果你同时装了多个 AI 插件下面几个问题大概率会遇到。5.1 现象Codex 突然只看不动排查链路有一次我让 Codex 改一个接口它回复了一堆建议这样做但一个文件都没改。第一反应是模型傻了后来仔细排查才发现问题不在模型在上下文我在对话前贴了一大段 GitLens 的提交历史里面有一条信息误导了它——它以为那个接口已经有人改过了所以只给我建议而不是执行。排查链路是这样的先看 Codex 面板的完整请求内容确认它看到的上下文是什么把最近粘贴的外部信息逐条排除尤其是 Git 历史、错误列表这种背景信息在对话开头补一句明确指令请直接修改文件不要只给建议如果再不行新开一个对话窗口避免累积上下文干扰。这个案例说明插件提供的信息本身没错但信息过多会让模型产生错误假设。喂给 Codex 的资料一定要和任务目标对齐不能因为看板上有就用。5.2 现象两个 Agent 插件同时抢文件有段时间我同时开着官方 Codex 和 Cline给两边都派了任务。结果 Cline 先改完文件Codex 后写同一段逻辑直接把 Cline 的改动覆盖了。这不是插件 bug而是工作流设计问题。我的解决方案是给它们划清边界官方 Codex 负责大改重构、跨模块、项目级任务Cline/Aider 负责小活格式化、局部修 bug、补测试同一个文件同一时刻只允许一个 Agent 写另一个要用必须先看 git status 确认没有未提交改动。实际操作中我会在提示词里直接加一句修改前先检查目标文件是否有未提交改动若有先报告再操作。这句话成本很低但能挡住一大半冲突。5.3 现象提示词越长Codex 越笨这是一条让我印象很深的教训。一开始我觉得提示词写得越详细越好把历史背景、技术栈、约束条件全都堆进去结果 Codex 反而抓不住重点输出变得啰嗦且经常答非所问。后来我做了个对比实验同一个任务一段 300 字的提示词和一段 60 字的提示词后者完成度反而更高。原因很快想明白模型对长文本里的关键指令是有注意力衰减的尤其是角色约束这类元信息放在最前面真正的任务藏在最后它的执行重点就会偏移。现在的处理方式是任务前置、约束后置、背景按需补充先把任务说清楚再说格式最后补一句背景。 如果模型问起背景你再追加不用提前全部交代。这条经验对上面所有插件提示词都适用——模板是帮助统一的不是让你无脑填满。6. 我现在的工作流插件是辅助提示词是灵魂写了这么多最后分享一下我自己的日常吧。早上打开项目先看 Todo Tree 的侧边栏把今天的任务按优先级排好。需要大动的部分我会复制对应的模板到官方 Codex 面板补充涉及文件和验收标准让它开工。小修小补、加个测试、写个注释这些直接交给 Cline 或者 Continue我不守在旁边等。改完一波代码AI Commit 把提交信息生成好GitLens 确认变更范围没问题就提交。整个流程里没有一步是非某个插件不可但少了它们任何一个我都会明显感觉到效率降一截。6.1 早上先喂 TODO不喂空泛指令不要一上来就打开 Codex 说帮我看看项目。我现在的习惯是前一天晚上把第二天要做的事用 TODO 注释写进代码里第二天直接让 Codex 读 TODO 列表。这样任务有上下文、有位置、有目标模型的完成质量高出很多。提示词也有迭代同一个模板用久了我会根据实际输出效果微调删掉那些模型总是忽略的句子留下真正影响行为的关键句。6.2 晚上花十分钟复盘提示词每天收工前我会花十分钟看今天哪段提示词效果好、哪段失效了。失效的往往不是模板本身而是项目状态变了新增了模块、改了目录结构、换过依赖AGENTS.md 里的描述过时了。这时候更新一下文档比明天临时补救省心得多。插件可以一直稳定地装在那里但提示词必须跟着项目长。最后说一句实在的这 10 个插件不是什么银弹真正让 Codex 好用的是你对项目的理解和你把理解写进提示词的习惯。插件只是把这句话落到编辑器里的载体。我见过不少人装了一堆插件之后反而被工具牵着走每天调试插件的时间比写代码还多。其实稳下心态来把少数几个工具用透再配上一套能迭代的提示词Codex 才能从玩具变成队友。