Codex 提效 10 个必备插件：从上下文接入到工程实践

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 的工作方式。

这三种类型的适用场景差异很大，我做了个表，方便你按需取用。

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 把某个规则设为 warning，CI 里却是 error，Codex 依据本地严重度判断，容易觉得"这不是大事"，然后带着 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 官方扩展、Error Lens、文件系统 MCP、规则文件。其余六个按项目类型和个人习惯添加。装完没用上的插件，该卸就卸，别舍不得。插件这玩意儿，留着的意义是融入日常，而不是躺在列表里吃灰。

最后说一句我的切身体会。插件最怕的不是不会配，而是配完不用。提示词这个领域最值钱的不是某个炫酷功能，而是你慢慢沉淀下来的那套"告诉 AI 怎么干活"的方式。我装完这 10 个就没再换过，不是说它们完美，而是它们已经融进了我每天的流程。你如果刚开始折腾，建议从必装的四个开始，完整跑通一个需求再逐步加。跑着跑着，你自己的那份清单自然就会成形。