我大概是2025年初开始重度使用Codex CLI的到现在大半年过去装过的插件不下二十个真正留下来每天都用的就这10个。这篇文章就是一个含提示词的插件清单我会按用途拆开讲清楚每个插件解决什么问题、怎么配、配合什么提示词用最后再把我平时高频使用的那批提示词直接贴出来。正在用Codex或者准备入坑AI编程工具的开发者应该都能从这里捞到点能直接抄的东西。先把概念对齐一下这里的Codex指的是OpenAI出的那个跑在终端里的AI编程代理你让它修一下登录页的样式问题它会自己定位代码、执行命令、改完文件给你一份变更说明。但原生Codex默认很裸比如它不会记住上次聊到哪也默认只能连官方模型端点。插件的作用就是把这些缺失的能力补上。1. 为什么我给Codex装了这么多插件以及怎么选1.1 Codex原生能力边界缺的到底是什么拿我自己最常用的四个场景举例。上下文管理Codex每次会话都是新开的它不知道你上周和它讨论过什么决策除非你把文件内容或prompt反复粘贴进去。模型绑定默认只能接OpenAI官方端点想试试更便宜的国产模型或者公司内部模型原生不支持一键切换。命令安全Codex默认会尝试执行终端命令比如rm -rf这种命令理论上它也可能帮你跑原生没有确认和拦截机制。工程习惯自动代码审查、生成规范commit信息、更新文档这些事Codex默认不做需要你每次写prompt反复交代。所以插件存在的意义就是把这些缺的能力补上。说得生活化一点Codex像是一个底盘很好的助理插件就是给他的工具箱和记事本有的负责让他记住事情有的负责让他动手之前先请示有的负责按团队规范办事。没有这些辅助件助理再聪明也只能靠你一遍遍重复交代。1.2 Codex的插件机制到底是什么聊插件之前得先知道Codex到底通过哪些点扩展能力。我实际用下来的感受是Codex的扩展主要走四条路hook脚本在会话启动、命令执行前、会话结束这些事件节点触发外部脚本很多上下文注入和安全拦截插件本质就是hook。配置文件~/.codex/config.toml以及项目根目录下的codex.md可以塞系统提示词、模型参数、权限规则。MCPModel Context Protocol通过MCP server给模型增加外部工具和数据源适合接入知识库、数据库、内部API。命令包装器像cc-switch这类工具本质是在Codex外层包一层配置管理切换完模型端点再启动Codex。理解这四条路之后你再看插件就不会被花哨的名字迷惑了。说到底它们只是在不同的扩展点上做了封装。1.3 插件选型的三个原则装了二十来个插件又卸了一半之后我总结出三个原则源码可见是底线。能给Codex加能力的插件必然会拿到你的代码库访问权和命令执行权所以你至少要看得到它的源码、看star数量和issue响应速度。没有开源仓库的插件再方便我也不装。作用域越小越稳。插件之间一旦冲突排查的时间可能比省下的时间还多。所以宁可多拆几个干一件事的小插件也别装一个什么都管的全家桶。跟上Codex版本更新。Codex迭代非常快一个月可能发好几个版本插件作者如果跟不上你升级Codex之后插件就会静默失灵。我一般在升级前先看一眼关键插件的release时间。这三个原则也正好是下面这份清单的筛选标准能留下不为别的就是真的解决了某个高频痛点而且维护状态稳定。2. 我装完就没卸过的10个插件按用途分组按用途分四组模型与端点管理、上下文与记忆、工程效率、提示词与文档。开头放一张速览表后面逐个说。插件/工具用途对应章节cc-switch切换Codex模型端点2.1endpoint-health端点健康检查与降级2.1codex-memoryCodex长期记忆2.2context-builder代码库上下文聚合2.2session-compressor会话摘要与续接2.2codex-review自动代码审查2.3commit-helper生成commit信息2.3safe-exec危险命令拦截确认2.3prompt-kit提示词统一管理2.4codex-docs自动更新文档2.4这个清单以我自己的实际配置为基准有些是社区开源项目有些其实是我自己写的hook脚本。你按功能关键词去搜基本都能在社区里找到类似方案。2.1 模型与端点管理cc-switch和endpoint-health第一个要推荐的是cc-switch解决的是怎么让Codex在多个模型端点之间自由切换的问题。官方模型虽然好用但很多场景你希望走别的端点比如在DeepSeek、通义、Kimi这些兼容模型里选一个更便宜的或者某个端点出问题时切回官方。cc-switch就是干这个的——你维护好几套endpoint配置一键切换它会帮你把配置写进Codex的config。实际用起来操作路径大概是这样的先安装工具社区常见的是通过npm或brew安装然后在界面里添加配置填一个base_url和api key。这里值得注意base_url一定要填兼容OpenAI接口的完整地址填错后面全废。配置保存后选择某一套配置再回终端发起请求。切换完我习惯新开一个Codex会话而不是在旧会话里继续因为配置可能不会重新加载。这个插件能帮我日常省下的成本挺直观。探索性任务用便宜模型写代码的关键路径切回官方强模型一个月下来token开销能降不少。再说一个我同样没卸过的小工具endpoint-health。它会定期给当前端点发一个极小的探针请求统计响应时间和错误率。配置里可以设置阈值比如响应超过2秒算异常连续3次失败就提示切到备用端点。这东西本身不写代码但它能避免你在一个已经挂掉的端点上反复消耗时间。模型端点偶尔抽风是常态自动降级比人工发现快得多。2.2 上下文与记忆增强记住上次聊到哪第三个插件codex-memory解决的是Codex不记事的问题。它会在本机维护一个很小的知识库可以是一堆markdown文件也可以是SQLite。每次Codex完成一个重要任务后我让它把结论、团队约定、坑点追加到记忆文件里下一次会话开始插件会把这些记忆自动塞进system prompt的上下文。用了一阵子你会发现Codex越来越像一个熟悉项目的老同事而不是每次都是新来的实习生。它的实现并不复杂本质上是在Codex会话启动事件上挂一个hook脚本读取~/.codex/memory/目录下与当前项目同名的md文件把内容拼进上下文。我会按项目拆分记忆文件避免不同项目的内容互相污染。顺便说一句记忆文件一定要定期清理否则塞满了过时结论反而会让Codex输出质量下降。第四个插件context-builder解决的是大型代码库上下文塞不下的问题。它扫描整个仓库生成一份精简版的聚合上下文文件里面只保留目录结构、关键模块、外部接口、配置说明。然后让Codex基于这份文件工作而不是让它自己去翻几百个文件。多模块工程里这比直接甩整个仓库路径给Codex要高效得多。我通常把context-builder做成一个仓库级扫描脚本跑完输出一份context.md文件大小控制在1000字以内。超出就说明摘要还不够精炼。每次会话开头我先让Codex读取这份文件再开始派任务。配合的上下文聚合提示词我也固定在用了放在第三章。第五个session-compressor是我每天都会用的。它在会话结束时自动生成一份结构化摘要包括任务目标、已完成、待办、坑点、下一步建议。下一次会话直接引用这份摘要进度不会断。虽然每个任务都开新会话但整体是连贯的token花费也降了不少。长会话是最烧钱的能省则省。2.3 工程效率增强审查、提交、安全执行这一组要说的三个插件基本都是把Codex从写代码的小工升级成带规范意识的队友。codex-review是我最喜欢的插件之一。它基于当前的git diff调起Codex做一次代码审查输出结构化评审意见阻塞问题、建议优化、风格问题、安全隐患。我一般会在提交PR之前跑一次把明显问题提前解决掉。它提供的价值不光是多一双眼睛更重要的是让评审意见稳定在一个固定标准上而不是每次看心情输出。commit-helper更轻量但作用很实在。它读取git diff --staged让Codex总结变更再按conventional commit规范生成提交信息。我配置了两套模板正式项目用英文的fix: xxx、feat: xxx格式个人项目用简洁中文。用久了之后提交历史干净很多后面追问题也方便。safe-exec这一类命令执行守门插件我强烈建议每个人都装。Codex为了干活需要执行终端命令但默认全信任的模型有时候会提出非常危险的操作比如直接删目录、强制推送。这个插件做的事很简单拦截命令执行请求命中危险规则就要求你二次确认。别嫌弹窗烦一次误操作可能让你后悔一晚上。我见过有人因为嫌麻烦把它卸了结果一个周末的改动被git reset --hard清空教训太深刻了。2.4 提示词与文档让常用能力即取即用第九个是提示词管理器prompt-kit。它把高频使用的prompt模板集中管理你在终端里通过快捷命令把测试生成、代码解释、Bug定位、重构这些模板一键插入当前会话。它不改变Codex本身但它能把你从反复输入同样长段prompt里解放出来。我自己的prompt-kit里大概躺着20多条固定模板每条都打磨过好几轮。一条好提示词有时候比多装三五个功能插件更能提升输出质量。这套插件用起来很轻核心就是一个纯文本目录每条prompt是一个独立的.md文件文件名就是快捷键。新增一条提示词直接往目录里丢一个文件就行。第十个codex-docs让我省下了不少写文档的时间。每次代码变更之后它对比变更内容生成或更新对应的README、API文档章节。要注意的是它不负责重写大文档只在接口或行为变化时精准更新对应章节。配置里要设置好文档范围否则它会跑到无关文件里乱改。3. 附上我常用的8个高频提示词可直接抄这一章是全文最抄作业的部分。下面8条提示词都是我自己项目里打磨过的可以直接复制到Codex会话里用也可以按需删减。3.1 代码审阅提示词你现在是一名资深代码审查专家请基于我提供的git diff进行审查。 请按以下格式输出 1. 【阻塞问题】会导致bug、性能或安全隐患的问题 2. 【建议优化】不具备阻塞性但值得改进的点 3. 【风格/规范】不符合项目约定的地方 要求 - 优先关注变更内的问题不延伸讨论无关代码 - 每个问题必须说明原因给出修改建议 - 如果问题不存在直接写无3.2 重构提示词请对目标函数/模块进行重构约束如下 - 保持对外接口完全不变所有现有调用方不受影响 - 拆分单函数职责单个函数体控制在30行内例外需说明 - 优先选择标准库和项目已有依赖不新增不必要依赖 - 重构完成后给出核心路径的测试建议 - 输出要展示变更前后的关键代码片段3.3 测试生成提示词请为目标代码生成一组单元测试 - 覆盖正常输入、边界值、异常输入三类场景 - 每个测试用例必须包含明确的断言 - 对涉及外部依赖的部分使用mock不发起真实网络请求 - 使用项目已有的测试框架和风格 - 测试文件名与被测文件对应放在同一目录 输出请直接给出完整测试代码不解释过程。3.4 Bug定位提示词我的模块出现了以下问题{粘贴报错信息或错误表现} 请按以下顺序排查 1. 从报错栈定位到具体文件和函数 2. 分析最可能的三类原因并分别说明证据 3. 建议在代码中加一个最小可复现的验证步骤 4. 不要直接给出最终修复先确认原因后再动手3.5 上下文聚合提示词请基于我提供的项目结构信息生成一份聚合上下文文件 - 保留目录树中与业务核心相关的部分省略构建产物和第三方依赖 - 列出所有对外暴露的函数、API、配置项 - 标注模块之间的依赖关系 - 内容控制在1000字以内供另一个会话的Codex快速理解项目3.6 会话摘要提示词请将当前会话的关键内容整理为结构化摘要包含 - 任务目标本次要解决的问题 - 已完成已经确认的改动与决策 - 待办尚未完成的事项 - 坑点本次踩到的关键问题及规避方法 - 下一步建议下次会话应该从哪里继续 摘要控制在300字以内后续会直接注入新会话。3.7 模型自检提示词请执行一次基础能力自检 1. 用一句话说明你当前使用的模型和配置端点 2. 解析一段包含中英文混合的复杂markdown检查返回格式是否稳定 3. 读取项目里任意一个核心配置文件说明其作用 4. 如果上述任一步骤异常请明确说出异常现象3.8 文档更新提示词请对比git diff更新对应模块的文档 - 修改/新增的公开接口必须在文档中体现 - 变更行为的地方标注行为变更并说明原因 - 保持原有文档风格和结构不做无关重写 - 只输出需要更新的文档片段给出对应文件名这几条提示词的使用技巧是不要一次性把所有约束都堆进去按任务类型选2到4条关键约束就够了。我踩过的坑是刚开始喜欢把提示词写到几百字结果模型表现反而平均更差因为无关信息干扰了它对核心目标的理解。4. 常见问题与排查技巧实录插件装得多了踩坑是免不了的。这一章记录几个我实际遇到、而且社区里经常被问到的典型问题。4.1 cc-switch切换后local proxy报错的完整排查流程用cc-switch时社区里很多人会遇到这条报错local proxy failed while handling codex endpoint /responses。我第一次看到也被吓了一跳以为是什么大问题后来一步步排查发现这个报错只是在说本地配置的转发层在处理/responses接口时挂了跟外网通不通没有任何关系纯粹是本地开发环境配置层面的问题。排查按下面四步走第一步看本地转发层的进程是否在运行。很多时候是切完配置后转发服务崩了重启一下就好。第二步检查base_url配置。最常见的坑是地址末尾少了版本路径或者多写了一层路径导致/responses接口404。第三步查端口占用。本地转发服务默认监听某个端口如果被其他进程占了请求会全部失败。第四步确认配置里没有混入冲突项比如同时写了两套api key、同时启用了旧版completions和新版responses接口。我自己的习惯是把base_url、api key和模型名三项单独抄在一个文本里每次切换后逐项核对。一分钟的事省得反复查日志。4.2 插件装了但没生效这类问题九成是三个原因配置文件路径不对、hook脚本没有可执行权限、插件输出被其他插件覆盖。我见过有人装好插件后忘记chmod在macOS或Linux上脚本根本没有执行权限Codex静默忽略了它。排查方法很简单在终端手动跑一遍插件脚本看报错就知道问题在哪。4.3 Codex升级后插件失灵次数遇到不少。我的处理方案是升级前先看一眼生产环境里关键插件的repo分支确认它们是否已经适配新版本升级后第一时间跑一遍最常用的三个场景也就是上下文注入、代码审查、提交信息生成。有问题就回滚Codex版本等插件更新再升。别为了追新版本把工作流搞挂。4.4 模型输出质量明显变差大多不是模型本身退化而是上下文被污染或记忆文件塞满了低质量内容。我的排查顺序是先清掉当次会话的记忆注入跑一次独立会话对比再检查记忆文件里是不是混入了错误结论如果还不行再考虑切换端点。很多AI变笨了的抱怨最后查下来都是自己的prompt或记忆库出了问题。4.5 费用太高怎么办Codex这类工具如果用默认配置跑大任务token消耗真的惊人。我的办法有三条一是用session-compressor拆分任务避免一个会话聊太久二是用全局上下文体替换完整代码库减少重复输入三是在探索需求的时候用便宜端点到真正动手改代码时再切回强模型。下面把这一章的问题整理成一张速查表方便随时翻。问题现象常见原因优先检查项切换端点后报local proxy错误本地转发层未启动/端口占用/base_url错误转发服务日志、base_url配置插件装了像没装脚本无执行权限/config路径不对手动运行插件脚本、检查config目录Codex升级后插件失效插件未适配新版本插件repo的release记录输出质量变差上下文污染/记忆文件问题独立会话对比、清记忆费用突然暴涨长会话/重复注入大段上下文用摘要续接、压缩上下文5. 装插件这件事我的一些体会5.1 什么样的插件值得长期留我自己的标准有三条第一每周至少用三次否则就是伪需求。第二出了问题你能在30分钟内定位到原因源码混乱的插件果断换。第三它解决的是你真实踩到的坑而不是你想象中会踩的坑。用这个标准判断很多花里胡哨的插件自然就淘汰了。5.2 给刚开始接触Codex的人几点建议如果你刚开始接触Codex建议先别急着装插件。先用一两个星期的原生Codex把你的真实工作流跑通记下痛点。然后按这篇文章第二章的清单挑对应的插件装。装的时候一个接一个来每装一个就用两天确认没问题再加下一个。我见过有人一上来就装十几个插件结果整个下午都在配插件、调prompt真正的代码一行没写。最后分享一个我的习惯每周五下午花二十分钟翻一遍Codex的会话记录和记忆文件看看哪些任务反复出现、哪些提示词效果不好该改的改该删的删。工具永远是服务干活效率的别让配工具变成逃避写代码的理由。