OpenAI 上周整理了一篇文章，介绍内部是怎么用 Codex 的。使用 Codex 的团队包括安全、产品、前端、API、基础设施和性能工程。
从接手的任务来看，Codex 主要的使用场景为：理解复杂代码库、重构和迁移、性能优化、补测试、交付新功能，以及在紧急情况下排查故障等等。
下面是 7 个 Codex 典型的使用场景：
场景 1：代码理解
Codex 的一个典型用法，就是让工程师快速看懂不熟悉的代码库。
像是新人刚接手项目，或是工程师在调试、排查事故时，一般要先搞清楚：核心逻辑在哪、服务之间的调用关系、数据是怎么流转的。工程师们会先用 Codex 做些背景信息梳理，尤其是在文档不完整、系统关系比较复杂时，Codex 可以帮他们迅速了解上下文。
在事故响应时，Codex 也会用来追踪组件之间的交互，或是分析故障状态是怎么在系统里扩散的。
团队反馈：
一名内部的检索系统性能工程师说，每次修复 bug 时，他都会先用 Codex 的询问（Ask）模式，检查代码库里是否还有同类问题。
如果你要让 Codex 帮忙理解代码，试试这样问：
这个仓库里的登录 / 鉴权逻辑是在哪里实现的？
一个请求从入口进来，到最后返回响应，中间大概经过了哪些流程？
[某个模块名]会和哪些模块打交道？出错的时候一般是怎么处理的？
场景 2：重构与迁移
Codex 也很适合处理那种“改一处不够，得改一片”的任务。
比如更新 API、调整某种代码模式，或是把项目迁移到新的依赖，相关改动通常会分散在多个文件、多个包里。这时，普通的查找替换会不太稳，因为它不一定理解代码结构，也看不懂依赖关系，容易改挂了。
Codex 可以帮工程师先把这类改动统一跑一遍，尽量保证不同地方的写法一致。OpenAI 内部也会用它做一些代码清理工作，比如拆分过大的模块、替换旧写法，或是提前整理代码，方便后面补测试。
团队反馈：
一位 ChatGPT 网页版后端工程师说，Codex 曾把旧版 getUserById() 调用替换为新的服务模式，并创建了 PR。原本需要数小时的工作，只要几分钟就完成了。
如果你要让 Codex 帮忙做重构，试试这样问：
这个文件有点太大了，帮我按不同职责拆成几个模块，并给每个模块补上测试。
把代码里基于 callback 的数据库访问方式，统一改成 async/await。
场景 3：性能优化
在做性能调优，或是处理可靠性问题时，工程师们会让 Codex 先看一遍那些比较慢、比较吃内存的代码路径。常见的情况包括：循环写得不够高效、重复做同一件事，或者数据库查询成本太高。
这时，Codex 会先指出可能的问题点，再给出一些更合适的写法。除此之外，它也会用来检查代码里是否存在一些高风险、过时但还在使用的写法，帮助团队减少后续的维护成本，也降低改代码时引入新问题的概率。
团队反馈：
一位 API 可靠性基础设施工程师说，他会用 Codex 扫描代码中重复的高开销数据库调用。Codex 能识别热点路径，并生成批量查询语句，方便后面继续调优。
如果你要让 Codex 帮忙做性能优化，试试这样问：
这段循环有点吃内存，帮我优化一下，并说明为什么你的写法会更快。
帮我看看这个请求处理逻辑里，有没有重复执行、成本比较高的操作，哪些地方适合加缓存。
这个函数里有多次数据库查询，帮我看看能不能改成更高效的批量查询。
场景 4：测试覆盖率
Codex 也适合用来补测试，尤其是那些测试覆盖不够，甚至还没写测试的地方。
比如在修 bug 或者重构代码时，让 Codex 先想下：这里应该补哪些测试？哪些边界情况容易出问题？哪些失败路径需要覆盖？
如果是新写的代码，Codex 也可以根据函数签名和周围代码，先生成一版单元测试或集成测试。
它比较有用的地方，是能提醒你一些容易漏掉的情况，比如空输入、最大长度，或者一些不常见但合法的状态。上面这些情况，人写第一版测试时容易忘掉。
团队反馈：
一位 ChatGPT 桌面版前端工程师说，他晚上会让 Codex 处理覆盖率偏低的代码模块，第二天醒来就能拿到可直接运行的单元测试 PR。
如果你要让 Codex 帮忙补测试，试试这样问：
帮这个函数写一组单元测试，重点覆盖边界情况和可能失败的路径。
给这个排序工具写一组 property-based test，看看不同输入下排序结果是不是稳定。
帮我扩充这个测试文件，把 null 输入、非法状态这些漏掉的场景补上。
场景 5：提升开发速度
Codex 也会被用在功能开发的前期和收尾阶段。
比如一个新功能刚开始做时，先让 Codex 搭一版基础框架：生成目录、模块、API stub，让代码先跑起来，这样就不用每个基础文件都手动从头写。
到项目快发布的时候，它也可以帮忙处理一些小但必要的工作，比如排查 bug、补齐最后一点实现、生成发布脚本、埋点代码或者配置文件。
此外，还有一种用法，就是直接把用户反馈或者产品需求贴给 Codex，让它先生成初始代码。到后面，工程师再回来 review、修改和完善。
团队反馈：
一位内部工具团队的全栈工程师说，Codex 帮他们完成了 3 到 4 个低优先级修复。它们本来很可能会一直躺在 backlog 里，很久都排不上期，但 Codex 处理得不错，让这些小问题终于被解决掉了。
如果你要让 Codex 帮忙加快功能开发，试试这样问：
帮我搭一个新的
POST /eventsAPI 路由，先加上基础参数校验和日志记录。参考这段埋点代码模板，帮我生成一个新的 telemetry hook，用来记录新用户引导流程的成功和失败状态。
根据这份产品需求 / 用户反馈，先帮我写一版 stub 实现，后面我再来补细节。
场景 6：保持专注高效
Codex 也适用那些容易被打断的工作场景。
比如工程师一天里会议很多，或者正在值班，很难一直专注在同一件事上。这时候可以把没做完的工作、临时记下来的想法，或者一些探索性任务交给 Codex 先“接住”，等有空的时候再继续看、继续改。
团队反馈：
一位负责基础设施可观测性的 API 工程师说，他平时会把 Slack 讨论、Datadog trace、issue 这类信息丢给 Codex，让它先帮忙整理和推进，自己则继续处理优先级更高的事情。
场景 7：探索与创意构思
在一些没那么确定的探索性工作里，Codex 也很好用。
比如你想比较几种实现方案，看看某个设计决策是否合理，或者试试自己不太熟悉的代码模式，都可以让 Codex 先给一版思路。它不一定直接给最终答案，但可以帮工程师把不同方案的取舍、潜在问题和实现方向先列出来。
此外，还有一个很实用的用法：找类似问题。比如已经修了一个 bug，或者发现某个旧方法不该继续用了，就可以让 Codex 顺着这个模式去代码库里找一找，看看其他地方是不是也有类似写法。这样，方便后面的清理和防回归。
团队反馈：
一位检索系统性能工程师说，他每次修完一个 bug 后，都会问 Codex：代码库里还有哪些地方可能藏着类似问题？然后再把这些发现拆成后续任务。
如果你要让 Codex 帮忙做方案探索，试试这样问：
如果这个系统不走 request / response 模式，而是改成事件驱动，大概会怎么设计？
帮我找一下项目里还有哪些模块在手写 SQL 字符串，没有使用统一的 query builder。
帮我把这段代码改成更偏函数式的写法，尽量避免直接修改数据和产生副作用。
最佳实践
OpenAI 也总结了一些内部使用经验。简单来说，就是 Codex 更适合有结构、有上下文、可以反复调整的任务。
1. 大任务先用 Ask Mode
比较大的改动，不要一上来就让 Codex 直接写代码。
可以先让它在 Ask Mode 里给出实现方案，确认要改哪些文件、分几步做、可能有什么风险。方向没问题后，再切到 Code Mode 执行。
2. 把开发环境配好
Codex 的效果和开发环境关系很大。
启动脚本、环境变量、网络权限、测试命令这些信息越清楚，它越不容易卡在依赖、构建或测试错误上。
3. 像写 GitHub Issue 一样写提示词
给 Codex 下任务时，尽量写得像一个 GitHub Issue。
比如要改哪些文件、涉及哪些组件、参考哪个模块、预期行为是什么。信息越具体，结果越稳。
4. 把任务队列当成轻量 backlog
一些临时想到的小修复、探索性任务、没做完的工作，可以先丢进 Codex 的任务队列。
它不一定每次都要直接生成完整 PR，也可以先把事情推进一版，等你有空再回来 review。
5. 用 AGENTS.md 留长期上下文
如果一个仓库会长期用 Codex，可以维护一份 AGENTS.md。
里面可以放命名规范、业务规则、特殊约定、已知问题和依赖关系，减少 Codex 每次重新猜项目背景。
6. 多生成几版再比较
对于不确定怎么做的任务，可以让 Codex 同时生成几版方案。
然后从里面挑一版更合适的，或者把几版里有价值的部分合在一起。
小结
整体来看，OpenAI 内部使用 Codex 的方式并不复杂。一般是用在边界比较清楚、可以验证、可以 review 的工程任务里：读懂代码、做迁移、补测试、查性能问题、生成初始实现，或者处理一些暂时不想打断当前工作的零散任务。
所以 Codex 的重点不只是“写代码”，而是把明确的工程任务先推进到一个可以检查、可以继续修改的状态。
