Codex 用久了你会发现它真正的威力不完全来自那几条核心命令更多是来自你允许它接入多少上下文。我刚开始用 Codex 时也是从终端裸敲开始的那时候它像个很聪明的实习生指令听得懂可对项目里乱七八糟的历史、约定、依赖关系完全没有概念。后来我装了一圈插件又卸了一圈最终留下来的就是标题里这 10 个——它们有个共同特点装完就再也没想过卸。这篇文章把我自己的筛选标准、这 10 个插件以及每个场景对应的提示词模板完整写出来你可以直接照抄。1. 我选插件的标准什么样的插件才配留在我的 Codex 工作流里1.1 Codex 的定位插件是补齐动手干活的外围能力先理清一个前提Codex 不是一个聊天机器人它是一个动手干活的 AI 代理。它原生就能读文件、跑命令、改代码、执行测试这已经很厉害了。但真实项目里光有这些远远不够。举个例子你让它优化一下搜索接口它如果不知道这个接口背后连的是哪张表、索引建在哪几列、最近的提交改过什么逻辑、团队规定新增查询必须带迁移脚本那它只能凭经验猜。猜对是运气猜错是常态。所以我一直把 Codex 的能力分成两部分一部分是它自己天生自带的思考与写码能力另一部分是项目喂给它的上下文情报。插件解决的就是后者——把 IDE 实时诊断、Git 历史、文件访问边界、数据库表结构、issue 讨论这些情报用结构化方式灌给 Codex。判断一个插件值不值得装就一句话它能不能让 Codex 在动手之前获得更准确的项目上下文。能就留着不能再炫酷也是摆设。1.2 我的筛选条件稳定、真实、一次配置、能被提示词固化我卸载过很多插件原因各异但留下来的这 10 个基本都满足四个条件。第一是必须解决真实痛点不装看起来炫的。很多插件演示视频很好看但真实开发里一个月用不到一次这种我直接卸。第二是必须稳定。Codex 迭代非常快插件跟着版本升级挂掉是常有的事。如果一个插件每次升级都要重新折腾配置它就不适合留在工作流里。第三是配置一次之后不用反复调。我比较反感那种配置文件写得比业务代码还长的插件。好的插件应该能一次配置、长期使用。第四是它的用法能沉淀成提示词。这点最容易忽略但恰恰最重要。Codex 的使用方式高度依赖提示词如果一个插件的功能没法用提示词驱动那它就没法被复用也没法教给别人。这 10 个插件每个我都能给出对应的提示词模板这才是它们能长期留下来的核心原因。2. 先看清格局Codex 周围到底有哪几类插件可以装2.1 三种集成方式IDE 扩展、MCP Server、规则/提示词文件在开始逐个介绍之前我觉得有必要先把插件这个词的边界说清楚。很多人以为插件就是装进 VSCode 里那种扩展其实围绕 Codex 能装的东西大致分成三类。第一类是 IDE 扩展。以 VSCode 生态为主装进编辑器里比如官方 Codex 扩展、Error Lens、GitLens 这些。它们的共性是人坐在编辑器前可以用鼠标选区、看 diff、点按钮交互体验很好。第二类是 MCP Server。MCP 是 Model Context Protocol 的缩写简单理解就是一个标准化接口让 Codex 能把外部工具接进来用。比如文件系统工具、GitHub 工具、数据库工具都可以通过 MCP 暴露给 Codex。这类东西的配置方式通常是写在mcp.json或者 Codex 的配置文件里。第三类是规则/提示词文件。比如项目根目录下的AGENTS.md、.codex目录里的规则以及用户目录下的自定义 prompt 文件。它们不产生交互界面但作用不小——相当于给 Codex 定行为准则。我把它当成软插件因为它们能用很小的成本改变 Codex 的工作方式。这三种类型的适用场景差异很大我做了个表方便你按需取用。类型代表适用场景配置位置IDE 扩展Codex 扩展、Error Lens、GitLens人在 IDE 里交互式开发编辑器扩展市场MCP Serverfilesystem、GitHub、PostgreSQLCodex 需要读取外部工具数据mcp.json / .codex 配置规则/提示词文件AGENTS.md、.codex/rules长期约束 AI 行为统一团队规范项目根目录 / 用户目录2.2 我保留的架构IDE 扩展 CLI MCP Server 三层我目前的日常配置是三层结构缺一不可。第一层是 IDE 扩展。平时写代码、做改动、看 diff全部在编辑器里完成靠的是 Codex 官方扩展加几个辅助插件。这一层负责交互体验。第二层是 CLI。跑自动化批处理、在 CI 里执行代码审查、处理跨仓库任务我用codex命令行配合脚本完成。这一层负责批处理与自动化。第三层是 MCP Server。凡是 Codex 需要读取项目之外的数据比如 GitHub 上的 issue、本地数据库的表结构我不手动复制粘贴而是通过 MCP Server 让它直接拉取。这一层负责外部数据接入。三层配合的好处是日常小改动全程不离开编辑器重活累活用命令行跑需要外部信息时 MCP 自动补齐上下文。这样 Codex 既不会因为缺信息乱猜也不会因为信息太多导致决策变慢。3. 第一梯队让 Codex 从能对话变成能干活的五个插件3.1 官方 IDE 扩展一切插件的入口这是整个工作流的底座没有它其他插件都少了一个载体。Codex 官方 IDE 扩展把 Codex 直接嵌进编辑器里选中代码就能作为上下文它建议的改动以 diff 形式展示接受或回滚都在一个界面内完成比在终端里看纯文本直观得多。配置上有两个细节值得注意第一把工作目录明确指向当前项目根目录不要让 Codex 把整个用户目录当上下文否则它容易读到无关文件污染判断第二执行模式按需设置不确定的改动用半自动模式让它先提计划你确认后再动手如果项目已经磨合得很熟了再开全自动。我自己的习惯是新项目先用手动确认模式跑通两三个流程、摸清 Codex 的脾气之后再根据情况放宽。别一上来就全自动AI 改代码的速度快但方向错了纠错成本也不低。3.2 错误诊断增强让 AI 先看到红线再动手这一类我目前用的是 Error Lens它能把 TypeScript、ESLint、Python 这类诊断信息直接显示在代码行内哪里有报错一眼就能看到红线。很多人以为这只是给人看的其实对 Codex 更重要。Codex 在修改代码之前如果能直接看到编辑环境里的实时错误它就不需要先跑一遍编译器也能知道当前哪些地方是坏的、哪些改动可能引入新错误。它给出的修复方案会更有针对性而不是改完一个错误、再引出三个新错误。有一点要提醒尽量把 IDE 里的报错级别设置成和 CI 一致。很多人本地 IDE 把某个规则设为 warningCI 里却是 errorCodex 依据本地严重度判断容易觉得这不是大事然后带着 warning 提交最后被 CI 拦下来。让本地和 CI 的标准一致能省掉不少无意义的往返。3.3 Git 上下文插件让 AI 知道你怎么改过来的我用的 Git 插件是 GitLens它最实用的几个能力是 blame、提交历史、分支对比。这些能力用在 Codex 场景里作用相当直接。最典型的一个场景是你从一个改了一半的分支继续开发Codex 需要快速了解这个分支和 main 的差异哪些文件是新增的、哪些是重构的、最近几次提交的意图是什么。没有 Git 上下文Codex 会把整个项目当成白纸从头开始理解效率低且容易误判。我实际使用时会这样告诉 Codex先对比当前分支和 main 的差异列出最近 5 次提交涉及的文件和改动目的再开始实现新需求。这个提示词几乎每次都能让 Codex 的回答更贴合实际状态因为它一开始就站在理解历史的起点上而不是从零开始猜。3.4 文件系统 MCP告诉 AI 哪些文件可以动、哪些不能动Codex 本身有读写文件的能力但我也额外接了一个文件系统 MCP Server主要目的不是让它多干活而是给它划边界。MCP 的文件系统 server 可以指定一个根目录Codex 只能在这个目录范围内读写根目录之外的任何文件它都碰不到。我配置的时候会把项目根目录设为允许访问范围同时明确排除.env、密钥文件、构建产物这些敏感目录。这样即使提示词里出现什么意外指令它也不会往不该去的地方乱写。配置示例大致长这样放在项目级的 mcp 配置文件里{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /path/to/your/project, /path/to/shared/assets ] } } }这里有个实际教训权限边界要写得比你以为的够用更窄。Codex 是工具提示词是使用者写的如果使用者自己都不清楚项目哪些目录是敏感区AI 更不清楚。划好边界再让它干活出错概率会低很多。3.5 GitHub MCP把 Issue/PR 拉进对话Codex 的任务很多都来自 GitHub 上的 issue 或 PR review手动把 issue 内容复制粘贴进对话又慢又容易漏掉最新评论。我接了一个 GitHub MCP Server 之后Codex 可以直接读取 issue 讨论、PR 的 diff、评论甚至创建 PR。用法也很直接比如让它处理某个 issue提示词会明确告诉它读取 issue 编号 123 的完整讨论总结需求再开始实现。它拉取的数据一定是实时的不会像人肉复制那样你复制完之后别人又补了条评论你还不知道。用 GitHub MCP 有一个安全习惯密钥 token 只放在本地环境变量里不要写进任何仓库配置文件。不管项目是公开还是私有token 一旦提交上去风险都不小。4. 第二梯队把 Codex 从写代码升级成做工程的四个插件4.1 项目规则文件团队约定先于 AI 自由发挥如果说前面几个插件是给 Codex 补充信息那规则文件就是给它立规矩。我每个项目根目录都会维护AGENTS.md以及.codex目录下的规则文件。里面写的是代码风格偏好、目录结构约定、提交信息规范、哪些操作必须提供配套内容、哪些行为明确禁止。比如新增 API 必须同步更新 OpenAPI 文档修改数据库表结构必须附带迁移脚本禁止直接改动 lockfile这些规则写清楚之后Codex 每次对话都会自动加载。写规则文件有个技巧只写可检查的事项不要写应该好好写代码这种虚话。AI 无法执行好好写这种抽象要求但它完全可以执行每次提交前检查数据库迁移目录是否存在新文件。规则越具体约束力越强。还有一个优先级问题后面会在踩坑章节细说全局用户级规则、项目级规则、当前会话内的指令这三者的加载优先级不一样搞混了就会出现规则打架。4.2 测试生成插件改动之后的第一道闸门我的工作流里Codex 改完代码之后测试环节是强制性的。测试生成这块我常用的做法是接一个测试相关的 MCP 工具或者在 IDE 里配合测试插件使用。Codex 可以直接生成单测、跑测试、看覆盖率报告然后把失败原因反馈出来。提示词的使用上有个反直觉的点不要让它自动修复失败的测试而是让它列出失败原因和堆栈摘要不要直接改任何代码。为什么要这样因为 AI 有一个常见的坏习惯——测试失败了它会试图改测试来配合代码而不是改代码来配合测试。一旦测试文件被修正 那这个测试就失去了拦截问题的意义。先让它报告你看完原因再决定下一步这个流程更可靠。我实际用下来Codex 生成单测的能力是够用的特别是骨架测试、边界值测试、异常路径测试质量相当稳定。关键是把生成测试和修复代码两个动作拆开别让它同时干。4.3 数据库 MCP让 AI 能看到表结构而不是猜涉及数据库相关的需求Codex 比较可靠的做法是让它直接查表结构而不是在代码里反推 Schema。我本地开发环境接了一个 PostgreSQL MCP Server它可以直接读取表结构、索引、外键关系甚至可以用 EXPLAIN 看查询计划。这个插件最典型的应用场景是排查慢查询。以前我需要手动把建表语句、索引信息复制给 Codex现在只需要在提示词里说明查看某张表的索引和外键分析当前查询缺什么索引它自己就能完成任务。配置数据库 MCP 时我的原则是只授予只读权限。允许它执行 SELECT 和 EXPLAIN禁止 DDL 和 DML 写操作。AI 分析数据没问题写操作还是留给人来做更稳妥。毕竟是连数据库的事多一道防线少一堆麻烦。4.4 提示词管理插件把高频指令变成可复用资产如果前面九个插件解决的是Codex 能接触什么那提示词管理解决的是Codex 值得被怎么驱使。我所谓的提示词管理不是非要装一个复杂的第三方插件。用 IDE 的自定义命令功能、或者维护一个提示词 markdown 库、甚至是在用户级配置里放一个常用 prompt 文件都算。关键在于把高频指令模板化、参数化避免每次手动敲一大段话。比如我的提示词库里固定存着代码评审补测试生成 CHANGELOG分析慢查询初始化新项目这几套模板。用的时候把参数填进去就行一个模板反复用半年每次产生的效果都差不多稳定。这个插件是我认为最容易被低估的一种资产。因为代码是 Codex 写的但提示词是你写的。一套经过验证、反复打磨的提示词库才是你真正积累下来的生产力工具。换一台电脑、换一个团队这套提示词库跟着走Codex 的工作方式就不会变。5. 第三梯队装完你也会不想卸的两个沉淀型插件5.1 会话历史时间线每次改动都有回放Codex 每次会话过程本身是会记录成日志的但我加了一个自己的小脚本把这些日志按时间线整理成可视化的记录什么时刻执行了哪条命令、改了哪些文件、执行结果是什么、有没有报错。这个东西的价值在于复盘。过了两周以后你准备把那次改动整理成文档或者想复盘一下当时为什么做那个技术决策回看会话时间线比翻聊天记录高效得多。它还能帮你提炼经验哪些提示词效果好、哪些提示词经常把 Codex 带偏时间线一拉一目了然。我也把这个能力用在了跟团队协作上。交接任务时直接把一次完整会话的时间线记录丢给同事比十句话交代场景都清楚。Codex 干的活整个过程可视化之后就不再是一个黑箱而是可以被审阅、被复盘的工程记录。5.2 命令面板/终端联动不用在 IDE 和终端之间来回切这个严格说不是一个独立插件而是用 IDE 的 Tasks 功能和终端别名做的一套快捷命令。核心目的只有一个让固定的 Codex 任务一键触发不用每次都开终端敲长命令。我建了几个固定任务比如评审当前分支跑全量检查生成新功能的测试。点一下它自动执行对应的codex exec命令把标准提示词带进去跑完之后输出结果。这件事看起来简单但它改变了使用习惯。以前要跑评审我得先想提示词怎么写、再想命令怎么敲现在按钮就在手边随时都可以跑一次评审使用频率至少翻了一倍。工具这东西使用频率上来了价值才会体现出来。6. 可以直接抄走的 10 组提示词按插件场景分类下面这些提示词都是从我自己实际用的模板里整理出来的。参数部分我用花括号标出来了你替换成自己的项目信息就能直接用。每个提示词都对应前面提到的某个插件组合起来效果更自然。1. 初次进项目理解配合官方扩展、文件系统 MCP你被分配到项目 {repo}。先依次读取 README、AGENTS.md、package.json或 pyproject.toml 再浏览 src 目录结构。用 500 字以内输出简报技术栈、目录结构、关键脚本、测试命令。 只做分析不要修改任何文件。2. 错误诊断与分析配合 Error Lens 类插件当前文件 {file} 存在以下错误{error list}。 请逐个说明根因、影响范围并给出最小修复方案。先输出修复计划经确认后再改动。 不要顺手格式化代码只处理列出的问题。3. 分支差异检查配合 GitLens请对比当前分支与 main 的分支差异。 列出所有变更文件分组为新增、修改、删除、重构。 检查是否存在未提交的 schema 变更、缺失的测试、缺失的文档更新。 输出检查清单不要改动代码。4. 文件操作边界声明配合文件系统 MCP你的操作范围严格限定在 {project_root} 目录内。 禁止读写该目录之外的任何文件尤其禁止读取 .env、密钥、构建产物等敏感路径。 当前任务{task description}。开始前先确认涉及的文件路径。5. Issue 转实现与 PR配合 GitHub MCP读取 issue 编号 {number} 的完整讨论总结原始需求和当前实现之间的差距。 在分支 {branch} 上实现该需求用 {test_command} 验证通过后创建 PR。 PR 标题包含 issue 号描述里列出改动摘要和测试结果。6. 生成单元测试配合测试生成插件为 {file} 中的函数 {func} 生成单元测试。 要求覆盖正常路径、边界值、异常分支使用项目现有测试框架 不 mock 内部私有逻辑。测试写完直接执行报告通过/失败项 失败时只输出失败用例的堆栈摘要不要自动修改被测代码。7. 数据库结构分析配合数据库 MCP使用数据库连接查看 {table} 的表结构、索引和外键。 针对当前查询 {query} 判断是否缺少索引给出优化建议。 如内置 EXPLAIN 能力则输出执行计划摘要。只允许读操作禁止执行 DDL 或写操作。8. 代码评审配合 GitHub MCP 和 GitLens以资深 reviewer 身份评审 {pr_number} 的 diff。 按正确性、可读性、安全、性能四个方面输出问题列表 每个问题标注严重级别阻断 / 建议 / 可选。附修改建议但不要直接改代码。9. 会话复盘配合会话历史时间线阅读会话记录文件 {session_log}按时间线列出执行过的命令、修改过的文件、失败的步骤。 找出失败率最高的命令或提示词分析原因并给出改进建议。10. 一键检查流程配合命令面板/终端联动对当前项目按顺序执行完整检查lint → typecheck → test → build。 每一步失败时输出摘要并停止后续步骤。全部通过后输出通过列表。 不做任何代码修改。7. 组合实战一个真实需求从 Issue 到 PR 的完整链路单独列插件容易让人觉得每个功能都是孤立的我讲一个真实的需求流程把整套工作流串起来。假设仓库里有人提了一个 issue搜索接口在数据量大的时候经常超时请优化并补充测试。以前处理这种任务要打开 issue 复制内容、定位接口代码、理解数据模型、排查慢查询、改代码、补测试、写 PR至少折腾半天。现在这套工作流下步骤大致是这样第一步用 GitHub MCP 把 issue 的完整讨论拉出来让 Codex 先输出一个任务摘要我确认它理解的方向没有偏。第二步用文件系统 MCP 和项目规则文件让它定位搜索接口所在的代码目录列出相关依赖和潜在瓶颈位置。规则文件在这里的作用是约束它的搜索范围不至于满项目乱翻。第三步接上数据库 MCP让它查看搜索涉及的表结构和索引情况。实际发生过的情况是它发现某个核心查询缺了一个联合索引命中率低导致全表扫描。这个结论不是猜出来的而是它直接看了索引信息和执行计划之后得出的。第四步让 Codex 基于分析结果修改代码。这一步我通常用官方 IDE 扩展完成因为 diff 展示和逐段确认比较方便。改完之后它自动补了一个迁移脚本创建索引。第五步让测试插件为新搜索逻辑生成一组回归测试包括大数据量下的边界情况和超时兜底逻辑。测试跑一遍通过才算是改完。第六步用提交前自检提示词过一遍 diff列出是否缺文档、缺迁移脚本、缺测试。这个步骤就是前面说的可检查事项规则每次都会把检查清单输出给我。最后用 GitHub MCP 创建 PR描述里自动带上分析摘要、改动文件列表和测试结论。整个过程里没有一个环节是单打独斗的。GitHub MCP 负责来料规则文件负责约束数据库 MCP 负责查证测试插件负责兜底最后再回到 GitHub MCP 交付。插件之间本质上是在做上下文接力——Codex 每进入一个新阶段都能拿到前一个阶段沉淀下来的信息不用重复解释需求背景。这也是我坚持用这 10 个插件组合的原因它们单独拿出来都能用但整合在一起效率提升是乘法级别的。8. 踩坑记录插件装多之后的配置冲突、性能下降与最终取舍8.1 规则文件到底听谁的全局 vs 项目 vs 会话这个坑我踩了好几次才彻底搞明白。最开始我在用户级配置里写了一条代码风格统一使用 2 空格缩进然后某个项目的AGENTS.md里又写着本仓库约定 4 空格缩进。结果就是同一次会话里Codex 一会儿按 2 空格改一会儿按 4 空格改提交记录里缩进风格混乱复盘的时候根本没法看。排查之后发现Codex 加载规则的优先级是固定的会话内临时指令大于项目级规则项目级规则大于用户级全局配置。问题就在于我项目级规则没有统一清理而全局配置又有自己的偏好两个规则叠在一起AI 每次判断的标准不一致行为自然飘。解决办法很简单全局配置里只放普适性规则比如禁止修改 lockfile提交前必须跑测试这类放哪都不会错的项目级规则放项目特有的约定会话里再给临时指令。层级越清晰规则越不容易打架。如果你现在也遇到 AI 行为时好时坏先检查规则文件是不是重复定义、优先级冲突了。8.2 插件膨胀的排查链路谁拖慢了 Codex有一阵子我插件装得太爽一口气加了二十多个结果发现 Codex 启动越来越慢响应也开始迟钝。排查过程倒是可以分享照着这个思路走能快速定位拖后腿的元凶。第一步先看启动日志或 IDE 的扩展加载日志找加载耗时的排行榜看哪些扩展加载时间特别长。这一步通常能筛掉大半嫌疑对象。第二步逐个禁用可疑扩展再实际跑一次 Codex 请求对比响应速度。注意一次只禁一个不然你根本不知道是谁的锅。第三步对 MCP Server 做同样排查。我那次发现响应变慢的元凶就是两个 MCP Server 在启动时做了全量目录扫描每次启动都要扫一遍大目录自然拖慢整体。解决办法是把它们的启动方式从启动即扫描改成按需调用配置完之后响应立刻恢复正常。还有一个更隐蔽的问题MCP Server 数量越多Codex 在做决策时的候选工具列表就越长选择成本会随之上升。工具不是越多越好够用就好。十几个工具和四个工具后者让 Codex 选错工具的概率明显更低。8.3 我现在保留的最终清单经历了几轮加加减减现在稳定保留的就是前面介绍过的这 10 个。整理成一份清单供你参考。插件类型作用优先级Codex 官方 IDE 扩展IDE 扩展编辑器内核心入口、diff 管理必装Error LensIDE 扩展行内实时错误展示必装GitLensIDE 扩展Git 历史与分支上下文强烈建议文件系统 MCPMCP Server文件访问范围控制必装GitHub MCPMCP Serverissue/PR/代码评审数据接入强烈建议AGENTS.md / 规则文件规则文件项目约定与行为约束必装测试生成工具MCP/IDE测试生成与回归验证建议数据库 MCPMCP Server表结构与查询计划分析按需装会话时间线脚本自定义操作记录回放与复盘建议命令面板/终端联动自定义高频任务一键触发建议这份清单里真正非装不可的只有四个Codex 官方扩展、Error Lens、文件系统 MCP、规则文件。其余六个按项目类型和个人习惯添加。装完没用上的插件该卸就卸别舍不得。插件这玩意儿留着的意义是融入日常而不是躺在列表里吃灰。最后说一句我的切身体会。插件最怕的不是不会配而是配完不用。提示词这个领域最值钱的不是某个炫酷功能而是你慢慢沉淀下来的那套告诉 AI 怎么干活的方式。我装完这 10 个就没再换过不是说它们完美而是它们已经融进了我每天的流程。你如果刚开始折腾建议从必装的四个开始完整跑通一个需求再逐步加。跑着跑着你自己的那份清单自然就会成形。