在 OpenAI，从安全、产品工程、前端、API、基础设施到性能工程，许多技术团队每天都在使用 Codex。
无论是理解复杂系统、重构大型代码库，还是在新功能上线、处理紧急故障时，各个团队都在利用 Codex 来加速各类工程任务。
这篇文章是我们采访了 OpenAI 的工程师，并结合内部使用数据后，总结出的一系列真实用例和最佳实践。从中，你可以看到 Codex 是如何帮助我们的团队提高效率、提升工作质量，并从容应对大规模系统复杂性的。
应用场景 1 —— 理解代码
当我们的团队成员刚接触项目、调试代码或排查故障时，Codex 能帮助他们快速熟悉代码库中陌生的部分。 他们经常使用 Codex 来定位某个功能的核心逻辑，梳理不同服务或模块间的关系，以及追踪系统中的数据流。 有时，一些架构模式或者缺失的文档需要耗费大量人力去梳理，而 Codex 可以轻松地将它们呈现出来。
在应急响应期间，Codex 能够揭示组件间的相互作用，或追踪故障在系统间的传导路径，从而帮助工程师迅速进入新的工作领域。
听听我们团队怎么说
我在修复一个 bug 时，会用“提问模式” (Ask mode) 来检查代码库里其他地方是否可能出现同样的问题。
— 性能工程师, 检索系统
我值班的时候，会把堆栈跟踪 (stack trace) 粘贴给 Codex，然后问它身份验证的流程在哪里。它能直接跳转到正确的文件，让我可以快速进行分类处理。
— 网站可靠性工程师, API 平台
当我想知道‘某个功能该在哪里实现？’这类问题时，无论是在 Terraform 还是 Python 的代码仓库 (repo) 里，Codex 都比
grep命令快得多。— DevOps 工程师, 基础设施服务
试试用 Codex 来理解代码，你可以这样问：
• ☐ 这个代码仓库里的身份验证逻辑是在哪里实现的？ • ☐ 总结一下，请求从入口到返回响应，在整个服务中是如何流转的。 • ☐ 哪些模块和 [模块名]有交互？它们是如何处理失败情况的？
应用场景 2 —— 重构与迁移
当一项改动需要跨越多个文件或程序包时，我们通常会使用 Codex。 比如，在更新 API、改变某个设计模式的实现方式，或是迁移到新的依赖库时，Codex 能确保所有修改保持一致。 特别是当同一个更新需要在几十个文件中重复进行，或者改动涉及复杂的代码结构和依赖关系，无法通过简单的正则表达式 (regex) 或“查找替换”轻松搞定时，Codex 就显得格外有用。
工程师们也用它来清理代码，比如拆分过于臃肿的模块、用更现代的模式替换老旧的写法，或是为代码进行重构以便更好地进行测试。
听听我们团队怎么说
Codex 把我们代码里所有旧版的
getUserById()函数都换成了新的服务模式，还自动提交了 PR (合并请求)。这事儿本来要花好几个小时，它几分钟就搞定了。— 后端工程师, ChatGPT Web
为了扫清发布障碍，我让 Codex 扫描所有旧模式的实例，用 Markdown 格式总结出影响范围，然后直接提交 PR 把它们都修复了。
— 产品工程师, ChatGPT 企业版
试试用 Codex 来重构和迁移代码，你可以这样说：
• ☐ 把这个文件按功能拆分成独立的模块，并为每个模块生成测试。 • ☐ 将所有基于回调的数据库访问方式，转换为 async/await异步模式。
应用场景 3 —— 性能优化
Codex 常被用来识别和解决性能瓶颈。 在进行性能调优或提升系统可靠性时，工程师们会让 Codex 分析那些运行缓慢或消耗大量内存的代码，比如低效的循环、冗余的操作或开销大的查询。Codex 会提出优化建议，这些建议常常能显著提升效率和可靠性。
Codex 也被用来维护代码的健康度，它可以找出那些仍在被使用但存在风险或已过时的代码模式。 我们的团队依靠它来减少长期的技术债，并主动预防性能衰退。
听听我们团队怎么说
我用 Codex 扫描代码里那些重复且开销大的数据库调用。它很擅长标记出热点路径，并帮我起草批量查询的初稿，之后我再进行微调。
— 基础设施工程师, API 可靠性
Codex 在快速发现性能问题上表现出色——我只要花 5 分钟写一个提示，就能省下 30 分钟的工作量。
— 平台工程师, 模型服务
试试用 Codex 来优化性能，你可以这样说：
• ☐ 优化这个循环，提升内存效率，并解释为什么你修改后的版本更快。 • ☐ 找出这个请求处理器中重复的高开销操作，并提出可行的缓存方案。 • ☐ 针对这个函数，提出一个更快的方式来批量处理数据库查询。
应用场景 4 —— 提升测试覆盖率
Codex 能帮助工程师更快地编写测试——尤其是在那些测试覆盖率很低甚至完全没有测试的地方。 当修复一个 bug 或进行代码重构时，工程师们常常让 Codex 针对边缘案例或可能的失败路径提出测试建议。 对于新代码，Codex 能够根据函数签名和上下文逻辑，生成单元测试或集成测试。
在识别边界条件方面，Codex 特别有用，比如空输入、最大长度限制，或者那些不常见但有效的状态。这些情况在初期的测试中常常被忽略。
听听我们团队怎么说
我会让 Codex 在夜间处理那些测试覆盖率低的模块，第二天早上醒来，就能看到可以直接运行的单元测试 PR 了。
— 前端工程师, ChatGPT 桌面版
在我们庞大的代码仓库里切换分支很痛苦。所以，我会让 Codex 帮我写测试并触发 CI (持续集成)，而我自己则可以继续在当前分支上工作。
— 后端工程师, 支付与账单
试试用 Codex 来提升测试覆盖率，你可以这样说：
• ☐ 为这个函数编写单元测试，要包含边缘案例和失败路径。 • ☐ 为这个排序工具生成一个基于属性的测试。 • ☐ 扩展这个测试文件，覆盖缺失的场景，比如 null输入和无效状态。
应用场景 5 —— 加快开发速度
无论是在开发周期的开始还是收尾阶段，Codex 都能帮助团队提速。 启动一个新功能时，工程师会用它来搭建脚手架代码 (boilerplate)——自动生成文件夹、模块和 API 接口桩，从而快速得到可运行的代码，省去了手动配置的麻烦。
当项目临近发布、时间紧迫时，Codex 会处理那些琐碎但必要的任务，比如初步筛选 bug、填补最后阶段的实现空白、生成部署脚本、遥测埋点或配置文件。
它还能将产品反馈直接转化为初始代码。 工程师们常常会把用户请求或产品规格文档粘贴进去，让 Codex 生成一个粗略的草稿，之后再回来完善。
听听我们团队怎么说
我虽然开了一整天的会，但还是合并了 4 个 PR，因为 Codex 在后台帮我干活。
— 产品工程师, ChatGPT 企业版
Codex 完美地帮我修复了 3-4 个低优先级的 bug，这些问题本来可能会在待办事项里积压很久。这种感觉真是太棒了！
— 全栈工程师, 内部工具
试试用 Codex 来加快开发速度，你可以这样说：
• ☐ 为 POST /events搭建一个新的 API 路由，包含基本的验证和日志记录功能。• ☐ 根据这个模板 [在此插入你的遥测代码示例]，为新的用户引导流程生成一个遥测埋点，用来追踪成功或失败。• ☐ 基于这份规格文档 [在此插入规格或产品反馈]，创建一个桩实现。
应用场景 6 —— 保持心流
当工程师的日程被各种会议和干扰打得支离破碎时，Codex 能帮助他们保持高效。 他们会用 Codex 来记录未完成的工作，把笔记变成可运行的原型，或者开启一些探索性的任务留待日后处理。 这让他们即使在值班或会议缠身时，也能轻松地暂停和恢复工作，而不会丢失上下文。
听听我们团队怎么说
如果我发现一个可以顺手修复的小问题，我会直接发给 Codex 一个任务，而不是自己切换分支去修改。等我有空了，再回来审查它提交的 PR 就行。
— 后端工程师, ChatGPT API
我经常把 Slack 的讨论串、Datadog 的追踪日志、工单等等都转发给 Codex，这样我就可以专心处理更重要的事情。
— API 工程师, 基础设施可观测性
试试用 Codex 来保持心流，你可以这样说：
• ☐ 制定一个计划来重构这个服务，并把它拆分成更小的模块。 • ☐ 先把重试逻辑的框架搭起来，加个 TODO标记，我稍后再来填充具体的退避策略。• ☐ 总结一下这个文件，方便我明天能接着今天的工作继续。
应用场景 7 —— 探索与构思
对于一些开放式的工作，比如寻找替代方案或验证设计决策，Codex 也很有用。 你可以向它征求解决问题的不同方法，探索不熟悉的设计模式，或者对你的假设进行压力测试。 这有助于你权衡利弊，拓宽设计思路，并作出更精准的实现选择。
它还能用来识别相关的 bug。只要给它一个已知的问题或一个已废弃的方法，Codex 就能在代码库的其他地方找出类似的模式，让我们更容易发现潜在的衰退或完成清理工作。
听听我们团队怎么说
Codex 帮我解决了“冷启动”难题——我把规格文档粘贴给它，它就能帮我搭建好代码框架，或者指出我遗漏了什么。
— 产品工程师, ChatGPT 桌面版
我修复完一个 bug 后，会问 Codex 类似的问题还可能潜藏在哪里，然后把这些作为后续任务跟进。
— 性能工程师, 检索系统
试试用 Codex 来进行探索与构思，你可以这样说：
• ☐ 如果把系统从“请求/响应”模式改成事件驱动模式，会怎么样？ • ☐ 找出所有手动拼接 SQL 字符串的模块，而不是使用我们推荐的查询构建器。 • ☐ 用函数式编程的风格重写这段代码，避免变量突变和副作用。
最佳实践
要想让 Codex 发挥最大效用，你需要给它清晰的结构、充足的上下文，以及迭代的空间。 以下是 OpenAI 团队在日常工作中总结出的一些习惯，能帮你稳定地从 Codex 中获得价值。
• 从“提问模式” (Ask Mode) 开始
对于大型改动，可以先在“提问模式”下让 Codex 生成一个实现计划，然后再切换到“代码模式” (Code Mode)，将这个计划作为后续提示的输入。 这种两步走的方式能让 Codex 的思路更清晰，减少输出错误。• 像写 Github Issue 一样组织你的提示
当你像描述一个 PR 或 issue 一样给出提示时，Codex 的表现会更好。 这意味着，在必要时，你需要提供文件路径、组件名称、代码差异 (diff) 和文档片段。 使用像“按照[模块 X]的方式来实现这个功能”这样的提示，也能得到更好的结果。• 逐步完善 Codex 的开发环境
Codex 最适合处理那些范围明确的任务——比如一个你或同事花一小时左右就能完成，或者需要写几百行代码就能实现的任务。 随着模型的进步，它能处理的任务规模也会越来越大。
为 Codex 设置启动脚本、环境变量和网络访问权限，可以显著降低它的错误率。 在运行任务时，留意那些可以通过调整 Codex 环境配置来解决的构建错误。 这可能需要几次迭代，但从长远来看，能带来巨大的效率提升。• 把 Codex 任务队列当作一个轻量级待办清单
随时把想到的点子、未完成的工作，或是顺手发现的小问题都交给 Codex。 不用非得一次性生成一个完整的 PR。 Codex 是一个很好的“暂存区”，等你重新集中精力时，可以随时回来处理。• 使用 AgentS.md提供持久化上下文
在你的代码仓库中维护一个AGENTS.md文件，这能帮助 Codex 在处理不同提示时，更高效地理解你的项目。 这些文件通常包含命名规范、业务逻辑、已知的“坑”，或者那些 Codex 无法仅从代码中推断出的依赖关系。 你可以查阅文档，了解如何更好地组织AGENTS.md文件。• 利用 "Best of N" 功能提升输出质量
"Best of N" 功能允许你针对同一个任务同时生成多个版本的回复，这样你就可以快速探索不同的解决方案，并挑选出最好的一个。 对于更复杂的任务，你可以审查多个版本，并将不同回复的优点结合起来，得到一个更强的结果。
展望未来
Codex 目前仍处于研究预览阶段，但它已经实实在在地改变了我们的构建方式，帮助我们加快开发速度、编写更高质量的代码，并有余力去处理那些在过去可能永远不会被优先考虑的工作。
随着我们的模型越来越强大，Codex 也将更深度地融入我们的工作流中。我们对未来的潜力感到无比兴奋，并期待着用它解锁更多强大的软件开发方式。
我们也会继续分享一路走来的所学所得。
