OpenAI 如何使用 Codex
关于本文
本文译自 OpenAI 官方文档 How OpenAI uses Codex，介绍 Codex 在 OpenAI 内部各技术团队的真实使用场景与最佳实践。译文完整保留原文内容（仅省略了 PDF 中重复出现的页眉/页脚与页码等排版元素），并按 Obsidian 风格重新排版，便于阅读。
封面标注：
Merged +217 −196
目录
引言
在 OpenAI，Codex 已成为众多技术团队的日常工具，涵盖安全、产品工程、前端、API、基础设施和性能工程等团队。各团队用它来加速各类工程任务——从理解复杂系统、重构大型代码库，到在紧迫的截止时间下交付新功能、处理线上事故。
我们结合对 OpenAI 工程师的访谈和内部使用数据，整理出一批使用场景与最佳实践，展示 Codex 如何帮助团队提速、提升工作质量，并在规模化的复杂度下从容应对。
场景一 · 代码理解
无论是新人上手、调试问题还是排查事故，Codex 都能帮助团队快速熟悉陌生的代码区域。
工程师经常用 Codex 定位某个功能的核心逻辑、梳理服务或模块之间的关系、追踪数据在系统中的流转。它还能帮助揭示架构模式，或补全那些原本需要大量人工才能整理出的缺失文档。
在事故响应中，Codex 能揭示组件之间的交互、追踪故障状态如何在系统间传播，帮助工程师迅速进入陌生领域。
性能工程师 · 检索系统（Retrieval Systems）
修完一个 bug 后，我会用 Ask 模式查一查代码库里还有哪些地方可能存在同样的问题。
站点可靠性工程师（SRE）· API 平台
值班时，我把调用栈（stack trace）贴进去，问 Codex 认证流程在哪。它直接跳到对应文件，让我能快速定位、分流问题。
DevOps 工程师 · 基础设施服务
对于”这事该在哪儿改？“这类跨 Terraform 和 Python 的仓库问题，Codex 回答得比 grep 快得多。
试试这些提示词
- 这个仓库的认证逻辑在哪里实现？
- 总结请求在这个服务里从入口到响应的完整流转过程。
- 哪些模块与 [模块名] 有交互？它们如何处理失败情况？
场景二 · 重构与迁移
Codex 常被用来做跨多个文件或包的改动。比如更新 API、调整某种模式的实现方式，或迁移到新的依赖时，Codex 能让这些改动保持一致、轻松落地。
当同样的修改需要应用到几十个文件，或者改动需要理解那些靠正则（regex）或查找替换难以捕捉的结构和依赖关系时，它尤其好用。
工程师也用它做代码清理：拆分过大的模块、用现代写法替换旧模式，或为提升可测试性而重整代码。
后端工程师 · ChatGPT Web
Codex 把所有遗留的
getUserById()都替换成了我们新的服务模式，还顺手开了 PR。几分钟就搞定了原本要花几个小时的活儿。
产品工程师 · ChatGPT Enterprise
为了清掉发布阻塞项，我让 Codex 扫描出旧模式的每一处用法，用 Markdown 总结影响范围，然后开 PR 把它们一并修掉。
试试这些提示词
- 按关注点把这个文件拆成独立的模块，并为每个模块生成测试。
- 把所有基于回调（callback）的数据库访问改写成 async/await。
场景三 · 性能优化
Codex 被用来定位并解决性能瓶颈。
在调优或提升可靠性的工作中，工程师会让 Codex 分析缓慢或占用内存大的代码路径——比如低效的循环、冗余的操作或开销高昂的查询——并给出优化方案，往往能在效率和可靠性上带来实打实的提升。
Codex 还被用来维护代码健康度：找出仍在使用的高风险或已废弃写法。团队依靠它来削减长期技术债（tech debt），并主动预防回归问题（regression）。
基础设施工程师 · API 可靠性
我用 Codex 扫描重复的高开销数据库调用。它很擅长标记出热点路径（hot path），并草拟出批量查询，我之后再做微调。
平台工程师 · 模型服务（Model Serving）
Codex 非常擅长快速发现性能问题——我花 5 分钟写个提示词，就能省下 30 分钟的工作量。
试试这些提示词
- 优化这个循环的内存效率，并解释你的版本为什么更快。
- 找出这个请求处理器中重复的高开销操作，并提出可以缓存的地方。
- 为这个函数提出一种更快的数据库查询批处理（batch）方式。
场景四 · 提升测试覆盖率
Codex 帮助工程师更快地编写测试——尤其是在覆盖率薄弱或完全缺失的地方。
在修 bug 或重构时，工程师常让 Codex 给出覆盖边界情况（edge case）或潜在失败路径的测试。对于新代码，它能根据函数签名和上下文逻辑生成单元测试或集成测试。
Codex 尤其擅长识别边界条件，比如空输入、最大长度，或那些虽然合法却不常见、容易在初版测试中被遗漏的状态。
前端工程师 · ChatGPT Desktop
我让 Codex 在夜里盯着那些低覆盖率的模块跑，第二天醒来就有了可直接运行的单元测试 PR。
后端工程师 · 支付与计费
当切换 monorepo（单体仓库）分支很麻烦时，我让 Codex 去写测试、触发 CI，自己则继续在当前分支上干活。
试试这些提示词
- 为这个函数编写单元测试，覆盖边界情况和失败路径。
- 为这个排序工具生成一个基于属性的测试（property-based test，自动生成大量输入来验证性质，而非逐个手写用例）。
- 扩展这个测试文件，补上围绕空值输入和非法状态的缺失场景。
场景五 · 提升开发速度
Codex 在开发周期的起点和终点两端同时发力，帮助团队加速。
开启新功能时，工程师用它来搭建样板代码（boilerplate）——生成文件夹、模块和 API 桩（stub），快速跑起一份可运行的代码，而不必手动拼接每一个部件。
当项目临近发布，Codex 会接手那些琐碎却必要的任务来帮助赶上紧张的工期，比如分类处理 bug、补齐”最后一公里”的实现缺口，以及生成发布脚本、遥测埋点（telemetry hook）或配置文件。
它还被用来把产品反馈转化为起步代码。工程师常把用户需求或规格说明粘贴进去，让 Codex 生成一份初稿，之后再回头打磨。
产品工程师 · ChatGPT Enterprise
我开了一整天的会，却还是合并了 4 个 PR——因为 Codex 一直在后台帮我干活。
全栈工程师 · 内部工具
Codex 帮我完美交付了 3~4 个低优先级的修复——这些活儿本来会一直烂在待办清单里，这种感觉真的很爽。
试试这些提示词
- 为
POST /events搭建一个新的 API 路由，带上基本的校验和日志。- 用这个模板 [粘贴你的遥测代码示例] 生成一个遥测埋点，用于跟踪新引导流程的成功/失败情况。
- 根据这份规格说明创建一个桩实现：[粘贴规格说明或产品反馈]。
场景六 · 保持心流
当日程被切得零碎、又频频被打断时，Codex 帮助工程师保持高效。
它被用来记录尚未完成的工作、把笔记变成可运行的原型，或派生出之后可以再回头处理的探索性任务。这让人更容易在不丢失上下文的情况下暂停和恢复工作——尤其是在值班或会议很多的时候。
后端工程师 · ChatGPT API
如果我顺手发现一个可以修的小问题（drive-by fix），我会丢一个 Codex 任务过去，而不是去切分支，等空下来再看它的 PR。
API 工程师 · 基础设施可观测性
我习惯把 Slack 讨论串、Datadog 追踪、issue 等等都转给 Codex，这样我就能专注在高优先级的工作上。
试试这些提示词
- 生成一份重构这个服务的计划，把它拆分成更小的模块。
- 先把重试逻辑打个桩并加上 TODO——退避（backoff）逻辑我之后再补。
- 总结一下这个文件，方便我明天接着上次的进度继续。
场景七 · 探索与构思
Codex 同样适合开放式的工作，比如寻找替代方案或验证设计决策。你可以让它给出解决某个问题的不同思路、探索陌生的模式，或对假设进行压力测试。这有助于暴露权衡取舍、拓宽设计选项，并让实现方案的选择更加清晰。
它还被用来发现关联的 bug。给定一个已知问题或一个已废弃的方法，Codex 能在代码的其他地方找出类似的模式，让捕捉回归问题或收尾清理工作变得更容易。
产品工程师 · ChatGPT Desktop
Codex 帮我解决”从零起步”的冷启动难题——我把规格和文档粘贴进去，它就搭好代码骨架，或者提醒我漏掉了什么。
性能工程师 · 检索系统
修完一个 bug 后，我会问 Codex 哪里可能潜藏着类似的 bug，然后派生出后续任务。
试试这些提示词
- 如果系统改成事件驱动（event-driven），而不是请求/响应模式，它会如何运作？
- 找出所有手动拼接 SQL 字符串、而非使用我们查询构建器（query builder）的模块。
- 用更偏函数式的风格重写这段代码，避免可变状态（mutation）和副作用。
最佳实践
当你给到 Codex 结构、上下文和迭代空间时，它的表现最好。以下是 OpenAI 各团队正在养成的一些习惯，帮助他们在日常工作中持续从中获益。
从 Ask 模式开始
对于较大的改动，先用 Ask 模式让 Codex 给出一份实现计划，这份计划再作为你切换到 Code 模式后续提示词的输入。这种两步走的流程能让 Codex 保持”脚踏实地”，避免输出出错。Codex 最擅长范围明确的任务——大致是你或同事约一小时能完成、或几百行代码能实现的工作量。随着模型不断进步，它能承担的任务规模也会随之增大。
持续打磨 Codex 的开发环境
配置好启动脚本、环境变量和网络访问，能显著降低 Codex 的出错率。在运行任务的过程中，留意那些可以通过调整 Codex 环境配置来解决的构建错误。这可能需要几轮迭代，但从长远看会带来可观的效率提升。
把提示词写得像在写 GitHub Issue
当提示词的写法贴近你在 PR 或 issue 中描述改动的方式时，Codex 的响应会更好。也就是说，在相关处带上文件路径、组件名称、diff 和文档片段。用”像 [模块 X] 里那样来实现这个”之类的句式，能改善结果。
把 Codex 任务队列当作轻量级待办清单（backlog）
随手丢出任务，用来记录临时冒出的想法、做了一半的工作或顺带发现的修复。不必非得一次就生成一个完整的 PR。Codex 很适合当作一个暂存区，等你重新专注时再回来处理。
用 AGENTS.md 提供持久化的上下文
维护一个 AGENTS.md 文件，能帮助 Codex 在你的仓库中跨多次提示词更高效地工作。这类文件通常包含命名约定、业务逻辑、已知的”怪脾气”，或那些 Codex 仅凭代码无法推断出的依赖关系。如何组织 AGENTS.md 文件，可在官方文档中了解更多。
借助"Best of N"提升输出质量
Best-of-N 功能让你为同一个任务同时生成多个回答，从而快速探索多种方案并挑出最优的那个。对于更复杂的任务，你可以审阅多个版本，并把不同回答中的部分组合起来，得到更强的结果。
展望未来
Codex 仍处于研究预览（research preview）阶段，但它已经实实在在地改变了我们的构建方式——帮助我们提速、写出更好的代码，并承担那些原本永远不会被排上日程的工作。
我们对未来的潜力感到兴奋——随着模型不断变强、Codex 越来越深地融入我们的工作流，我们期待用它解锁更强大的软件开发方式。我们也会持续分享一路上的所学所得。