Codex 必备插件推荐：10款提升AI编程效率的实用工具

Codex 的插件我前前后后装过二十多个，最后留在环境里的就这 10 个。不是说我多克制，而是踩够了"装了一堆、一个没用、还拖慢 Codex"的坑之后，我给自己定了一条规矩：凡是不能让我"日常本来就要做的事"变得更快的插件，一律卸载。这篇文章就把这 10 个插件列出来，每个都讲清楚我为什么装、怎么配置、以及配套的提示词。

先说明一下，Codex 生态里的"插件"不像某些 IDE 那样有个统一插件市场，它实际由三类东西组成：真正的插件/扩展程序、MCP 服务、以及通过 AGENTS.md 或 slash command 固化的规则配置。我在下文统一叫"插件"，但它们本质上可能是这几类中的任意一种。

1. 在谈这 10 个插件之前，先说我定义"没卸过"的三条标准

很多人推荐插件是看功能介绍，我推荐插件只看一件事：它有没有真正嵌入我的日常工作流。为了让这个标准可执行，我给自己定了三条筛选线。

1.1 它是否在改变我的默认工作流，还是只是加了个"可能有用"的功能

判断方法很简单：装完之后，我接下来三天会不会自然而然地用到它。我有一个反面例子——装过一个代码风格美化插件，功能是把每次 Codex 的输出强制套上我预设的格式模板。听起来很美，实际用起来每次对话都要多带一堆约束指令，Codex 把精力花在格式化上，反而把逻辑推理节奏拖慢了。三天后我卸载了，因为它在"改变我的默认工作流"而不是"增强我的默认工作流"。

留下来的 10 个插件，全都是那种"我本来就要手动做的事，它帮我自动化或半自动化"的类型。比如我本来就要检查代码审查意见，那让它自动按我的角色设定跑一遍审查，这就是增强；我本来没打算做的事，装完也不会做。

1.2 能不能单点替换，不能有隐藏依赖

我吃过一次亏。某个全家桶式插件，一个包同时管理 slash command、上下文记忆和输出格式。结果一次更新之后，它自带的规则把我自己定义的命令全部覆盖了，我排查了半天才发现是插件之间的配置优先级冲突。从那次以后，我只选单功能插件，每个插件只管一件事，坏掉一个只影响一件事，不牵连其他。

这 10 个插件之间没有任何隐藏依赖。哪怕 CC Switch 挂了，我的规则管理插件依然正常工作；哪怕记忆库插件要重装，我的代码审查插件也不受影响。你要装插件，也建议按这个思路来，别给自己埋雷。

1.3 使用频率至少要达到"每周一次"

低于这个频率的插件，本质上就是收藏夹里吃灰的链接，除了增加启动负担和规则冲突风险，没有任何价值。我给自己做了个使用频率表，只有高频用的才留：

后面我逐个展开。

2. 底层基础设施：先解决"Codex 连哪个端点"和"重复指令"两个麻烦

2.1 CC Switch：端点切换不折腾

我用 Codex 的时候，经常要在不同服务端点之间切换：本地部署的模型服务、官方标准端点、还有一些项目专用的私有端点。最早我是手动改配置文件，每次都要去翻 JSON、重启会话、验证连通性，一天切个三五次真的会疯。

CC Switch 解决的就是这个问题：它把端点配置集中管理，界面上一键切换，切换完自动重启 Codex 的本地服务进程。装这个插件之前我犹豫过，觉得"不就是改个配置文件吗"，但用了一周之后就离不开了，因为它顺手帮我省掉了每次切换后的验证环节。

配置要点是：先把自己常用的端点都录入，标注好名称和优先级，再设一个默认端点。这样即使偶尔切换出错，Codex 也能回退到默认端点，不会停在半死不活的状态。

2.1.1 我遇过的"local proxy failed"报错排查全过程

这个报错长这样：cc switch local proxy failed while handling codex endpoint /responses，我第一次看到的时候也懵了，以为工具坏了。后来排查多了，发现根因基本都是这几类：

• 切换端点后，本地路由服务的子进程没有正确重启，旧配置还挂在进程里
• 新旧端点配置格式不一致，导致请求在转发层被拒
• 本地网关服务的端口被上一次异常退出占用，新进程起不来

我的排查链路是固定的一套：

1. 先检查本地网关服务是否在运行。执行ps aux | grep cc-switch，如果看不到对应进程，说明切换时子进程没有被拉起。
2. 查看 CC Switch 的日志文件，重点看切换时间点附近的报错记录，一般会明确写出是"端口占用"还是"配置解析失败"。
3. 如果是端口占用，直接找到占用进程并结束它，然后重新执行一次切换操作。
4. 验证连通性，用一条简单请求确认/responses端点能正常返回，确认之后再让 Codex 干活。

处理完之后我给这个流程写了个固定提示词，让 Codex 自己在报错出现时按这个思路排查：

提示词（写入 Slash Commander 配合使用）： 当 Codex 端点的请求失败报 local proxy failed 时，先检查本地路由服务的进程状态，再查看最近切换记录，定位是配置残留还是端口冲突，给出具体修复命令，不要直接让我手动翻日志。

这套流程现在基本不用我动手，报错出现后一条命令就把排查做了，省了很多事。

2.2 Slash Commander：把"每天重复的固定流程"固化成一句话

Codex 的对话模式里，我有一批每天都要用的指令，比如"启动项目环境""检查当前分支与主分支的差异""跑一遍 lint 和测试"。如果没有 Slash Commander，我每天要把这些话原样打一遍，而且每次打出来的措辞不同，Codex 的理解也会有细微偏差。

这个插件就是让我把这些固定指令存成 slash 命令，输入/start就能展开成一大段完整的上下文指令。它的价值不只是少打字，而是让每次执行的标准一致。

拿我最常用的一个命令举例，我在 slash 命令里存了这么一段：

提示词（/review 命令）： 请以资深代码审查者的身份，按照以下顺序检查当前分支的代码变更：

1. 先读取变更文件列表，忽略 lock 文件和生成的产物文件；
2. 检查是否存在未处理的错误分支，例如空指针、资源未释放、异常被吞掉；
3. 检查函数职责划分是否合理，圈复杂度是否明显超出同类代码的平均水平；
4. 给出问题清单，按"必须修复/建议修改/可忽略"分级，必须修复类问题要附带代码位置和修复示例。

这条命令执行完后，我基本不需要再做额外工作，输出直接可以贴到 PR 描述里。Slash Commander 真正的价值在于：它把"我脑子里的经验"变成了"Codex 每次都遵守的标准流程"。

3. 规则与上下文层：让 Codex 记住该记的，忘掉该忘的

这一层解决的是 Codex 最让人头疼的两个问题：项目规则记不住，长对话到后面容易"精神涣散"。

3.1 AGENTS 规则管理：别让规则文件变成一锅粥

Codex 读取项目规则的方式是看规则文件，通常叫 AGENTS.md 或者类似的名字。一开始我很兴奋，把能想到的规则全写进去了：代码风格、目录结构、命名规范、禁止事项……结果就是 Codex 的行为开始漂移，有时候严格遵守命名规范，有时候完全无视。

后来我分析了一下原因，规则文件太长了，Codex 加载后不会真正逐条执行，而是"凭感觉"选取一部分上下文来理解。这就像一个员工入职收到一本五十页的员工手册，他不可能每条都记住，只会挑他觉得重要的几条执行。

为此我装了这个规则管理插件，它的核心能力是把规则文件拆成多层：全局规则（所有项目通用的）、项目规则（当前仓库特有的）、会话规则（本次对话临时启用的）。Codex 加载时按层级合并，优先级从高到低，避免规则互相打架。

顺便分享一个格式技巧：每条规则必须以"条件 + 行为"的形式写，而不是"禁止xxx"这种抽象描述。比如：

• 错误写法：不要在代码里留下调试日志
• 正确写法：当代码包含 console.log 或 debug 输出时，在提交前提醒我并给出去除建议

这比单纯写"禁止调试日志"有效得多，因为 Codex 是生成式模型，给它明确的行为触发条件，它才知道什么场景下要做什么事。

提示词（用于规则审查）： 请审查当前项目的规则文件，找出其中所有不符合"条件+行为"格式的条目，以及两个条目之间可能互相矛盾的描述。输出时按"冲突位置/矛盾内容/修改建议"三列整理，只输出必须修改的部分，不要重复规则原文。

3.2 上下文压缩：长会话的续命手段

Codex 的上下文窗口是有限的，对话超过一定轮数之后，早期的决策信息会被挤出窗口，然后它就开始"失忆"。最典型的表现是下午还在聊某个模块的设计方案，晚上继续对话时它反复问已经确认过的问题。

上下文压缩插件解决的就是这个问题：在对话达到窗口上限之前，自动把早期的对话内容压缩成结构化摘要，把"完整的原始对话"替换成"包含关键决策的摘要"，从而腾出空间给新的对话。

我用它的方法是设一个触发阈值：当预估 token 用量达到窗口的 70% 时，先手动执行一次压缩命令，把已确定的决策固化下来，再继续聊。这样做的好处是，压缩这个动作不会被频繁触发，真正需要的时候它就在那里。

提示词（压缩命令）： 把本次对话到目前为止的内容压缩为结构化摘要，包括以下部分：

1. 已经确认的技术决策（列出决策内容和决策原因）；
2. 当前正在处理的具体任务（包括文件路径和函数名）；
3. 明确被否决的方案（列出方案名称和被否决的理由，避免后续重复提出）；
4. 待办事项和下一步计划。 压缩时不要保留任何寒暄、猜测、中间探索过程的描述。

压缩完之后，新的上下文从摘要开始，Codex 对之前项目的"记忆"就变成了一段精炼的要点，比原始对话可靠得多。

3.3 记忆库：跨项目、跨会话的持久记忆

上下文压缩管的是"当前会话内"，但 Codex 有一个天生缺陷：它不跨会话记忆。你今天告诉它"这个项目禁止用 lodash"，明天新开一个会话它就忘了。最原始的解决办法是每次对话前重新交代一遍项目背景，但是很累，而且容易遗漏。

记忆库插件的思路是：把每次对话中产生的关键决策、用户偏好、技术约束，通过结构化的方式写到一个固定记忆文件里，下次新会话启动时，这个文件会被自动加载进上下文。

我用它存三类信息：

• 项目决策：为什么这个模块用了状态机而不是简单 if-else
• 代码约定：错误处理必须向上抛，不允许吞异常
• 个人偏好：我的函数命名习惯、注释风格、测试目录结构

记忆库插件有个自动提取功能，会在对话到一定阶段时主动问我"这条决策是否要写入长期记忆"，我确认后它自动整理进文件。这个功能很提效。

提示词（写入命令）： 根据本次对话内容，提取应当写入项目记忆的条目。触发条件：

1. 我做了一个明确的技术选型决策，并给出了原因；
2. 我表达了对代码风格的偏好；
3. 我明确否决了某个方案。 提取完成后以列表形式展示，等我确认后再写入记忆文件。不要自动写入，必须经过我确认。

4. 代码质量层的三道闸门：审查、测试、安全执行

这是我最看重的一层。因为 Codex 生成代码的速度快，但生成质量不稳定，如果没有闸门机制，你会在不知不觉间把一堆有问题的代码合并进主干。

4.1 Review Agent：让 Codex 换个角色审视自己的输出

Codex 写代码的时候是"创作者视角"，写完一边跟你说"这段代码很完善，没有明显问题"。事实上它很难在生成代码的同时完成高质量审查，因为两者用的认知模式是冲突的。我的做法是：让它写完后，立刻用另一个独立的审查命令重新审视刚才的变更。

Review Agent 插件的价值在于把"审查"和"生成"完全分开。生成阶段开启创作模式，审查阶段切换成挑刺模式，两者互不干扰。我配置的审查命令包含以下几个维度：

• 安全性：是否有注入、越权、数据泄露风险
• 正确性：边界条件、并发问题、异常路径是否覆盖
• 一致性：全局命名、目录结构、依赖引入方式是否和项目现状一致
• 可维护性：函数长度、职责划分、注释必要性

实际使用下来，这种"让 Codex 自己审自己"的方式并不能替代人工审查，但它能筛掉大约六成低水平问题，比如未处理的空值、明显的逻辑漏洞、冗余代码。剩下四成需要人来判断的，它也会明确指出"这里需要人工确认"。

4.2 Test Runner：先写测试，再写实现

我养成了一个习惯：让 Codex 写新功能之前，先让它把测试用例写出来。这个习惯极大降低了下游返工的概率。Test Runner 插件把这件事流程化：先生成测试，再执行 Codex 参考测试来写实现，然后跑全部测试看是否通过。

听着简单，实际操作里有几个细节：

测试用例必须先报错。如果新功能的测试在实现代码之前就能通过，说明测试用例写得太宽松，没有真正覆盖到行为变化。我要求 Test Runner 先生成"预期会失败的测试"，跑一遍确认失败，再写实现，再跑一遍确认通过。这个"失败-成功"闭环很重要的，因为你可以在最后通过之前先写"预期会失败的测试"，跑一遍确认失败，再写实现，再按约定的行为验证它，再执行实现代码，最后再跑全量测试确认通过。

提示词（测试优先工作流）： 在开始写功能代码之前，先完成以下步骤：

1. 根据需求描述列出行为边界，包括正常输入、边界输入、异常输入；
2. 针对每个行为边界生成对应的测试用例，测试必须具体到函数调用和期望断言；
3. 运行测试，确认新用例全部失败，并说明失败原因符合预期；
4. 写实现代码；
5. 重新运行测试，直到全部通过，并补充说明哪些实现细节是为了让测试通过而添加的。

4.3 Safe Exec：给危险命令装一个确认闸门

Codex 在终端执行命令的能力很强，但这种能力有时候反而是风险。我遇到过它在按我的指令重构代码时，顺手执行了删除旧目录的命令，虽然没有造成破坏，但把我吓了一跳。更不用提那些真实发生过的案例：模型在清理临时文件时误删了项目配置、执行了没预期的 git push 操作。

Safe Exec 插件的原理很简单：匹配命令库里的危险模式，包括删除类命令、强制执行类命令、推送远端分支、权限变更等，遇到这些命令先暂停，把命令内容和影响范围描述出来，等人在终端里确认后才继续执行。

我建议你至少把这几类命令加入拦截名单：

rm -rf 以及指向非临时目录的删除操作 git push --force 以及 reset --hard chmod -R 777 类的高权限修改 dd 类裸设备写入命令 curl 管道直接执行远程脚本

没有这个插件的时候，Codex 执行命令是一路绿灯，缺点是你永远不知道哪条命令会在你不注意的时候闯祸。装上以后虽然多了一个确认步骤，但换来的是"Codex 永远不会在我没注意的情况下做出不可逆操作"，这个安全感值回票价。

提示词（Safe Exec 策略）： 以下命令必须经过我确认后才能执行：

1. 修改或删除任何非临时目录下的文件；
2. 执行 git push、git reset --hard、git clean -f 等影响分支状态的操作；
3. 使用 curl 从外部地址下载脚本并执行；
4. 批量重命名或移动文件。 执行前必须说明命令的完整内容、受影响路径、预期结果，以及如果失败会有什么后果。

5. 提示词与复盘层：让每一轮对话都沉淀成资产

前面几层解决的是"Codex 用得顺不顺手"，这一层解决的是"我的经验有没有越攒越多"。很多人用 Codex 一直停在"用完即走"的状态，代码写完了，对话关闭了，那些花时间调出来的高质量提示词、那些踩坑后总结的指令，全都没留下。

5.1 Prompt Vault：把高频提示词变成可以检索的模板库

我维护自己的提示词模板库很早，最初用备忘录，后来用文档，最终换成了 Prompt Vault 插件。原因是提示词积累到一定数量后，检索比手写更费劲。

Prompt Vault 允许我给每条提示词打标签、写适用场景、记录版本迭代。比如我做代码审查的提示词，从最初一版到现在已经迭代了四次，每次根据 Codex 的实际表现调整措辞和结构。没有版本管理的话，我根本不知道哪个版本最有效。

我沉淀提示词的来源非常简单：每次对话里注意到 Codex 对某类任务的回答质量明显高，我就分析它当时收到的指令结构，把那些有效的结构抽出来存进 Vault。反过来，如果某类对话质量低，我也会把低质量的案例存进去，标注"反面教材"。

提示词（从对话中提取模板）： 从本次对话中识别我提出的指令或问题模式，找出那些引出了高质量回答的指令。对每条有效指令做以下处理：

1. 列出指令原文；
2. 概括它为什么有效（角色设定清晰？步骤分解明确？还是约束条件具体？）；
3. 生成一个替换占位符的通用模板，比如任务名称、目标文件、约束条件。 最后将模板存入提示词库，标签按功能领域归类。

5.2 会话导出与复盘：Codex 对话记录也是项目资产

Codex 对话的价值经常被低估。调试一个疑难 bug 时，Codex 和我们来回确认问题、尝试方案、验证结果的全过程，比最终的修复代码更有参考价值，因为它记录了排查思路。但如果不做导出，关闭会话之后这段思路就丢了。

我用的会话导出插件可以把对话记录整理成结构化文档，自动按"问题描述/排查过程/结论"分层。每个项目阶段结束后，我把这些导出文档汇总成项目知识库，后续遇到类似问题直接查知识库，甚至可以把知识库内容作为 Codex 的参考上下文，让它快速理解历史背景。

导出之后的复盘动作，我会用下面的提示词：

提示词（会话复盘）： 阅读本次导出对话，找出以下内容：

1. 排查过程中走弯路的节点，以及当时造成弯路的原因；
2. 最终解决问题的关键判断是什么；
3. 有哪些做法在未来类似的场景中可以直接复用；
4. 有哪些问题应该在最初的提问方式上改进。 输出为"弯路记录/关键判断/可复用经验/提问改进"四部分，直接追加到项目知识库中。

6. 我推荐的安装顺序，以及一个组合工作流模板

上面这 10 个插件不是一次性装齐的，我经历了三轮迭代才最终定下这套组合。如果你现在是从零开始，建议按下面的顺序分阶段加。

6.1 分三步走，别一口气装完

第一阶段先装基础设施，也就是 CC Switch 和 Slash Commander。这两个解决的是"Codex 能用、用起来省事"的问题，装完就能感受到效率提升，不需要额外学习成本。

第二阶段装规则与上下文层，AGENTS 规则管理、上下文压缩、记忆库。这一阶段解决的问题开始深入了，特别是如果你已经遇到"Codex 忘事""规则不生效"这类现象，这三个插件是直接对症的。

第三阶段再装代码质量层和沉淀层：Review Agent、Test Runner、Safe Exec、Prompt Vault、会话导出。到这个阶段，你的 Codex 已经储备了足够的项目上下文和规则约束，再引入质量闸门才有意义，否则它连项目背景都没搞清楚就开始审查，效果反而差。

6.2 一个真实的组合工作流

我日常一个典型任务流程是这样的：

1. 启动 Codex，开新会话，记忆库插件自动加载项目决策和代码约定；
2. 用 slash 命令让 Codex 读取当前分支的变更概览，确认任务范围；
3. 和 Codex 讨论方案，确定后让 Test Runner 先生成预期失败的测试用例；
4. 执行测试确认失败，让 Codex 写实现代码；
5. 实现完成后跑全量测试，确认通过；
6. 切到 Review Agent 模式重新审查变更，输出分级问题清单；
7. 修复问题后提交，提交前 Safe Exec 确认没有危险命令被误执行；
8. 任务完成后，把关键决策写进记忆库，对话导出到项目知识库。

这套流程跑下来，Codex 基本从"一个会写代码的对话机器人"变成了"一个被嵌入到个人工作流程里的工程助手"。

6.3 踩坑汇总，省得你再走一遍

按这个顺序搭完，你的 Codex 环境应该和我现在用的这套差不多顺手。

我个人的体会是，插件推荐这件事，最怕的是推荐的人自己也没用明白。这 10 个插件是我每天都会真实触达的，不是装完截图就吃灰的那种。最后再说一个小技巧：每三个月我会专门开一个会话，把当前装的插件列表贴给 Codex，让它根据使用记录帮我判断哪些插件的调用频率低于每周一次，然后我手动卸掉。这套"定期瘦身"的习惯，保证了我的 Codex 环境一直是轻量且高效的。