周二，OpenAI 发布了用于编程任务的 GPT-5-Codex 模型，Codex 具备能够与开发者即时协作，以及能长时间独立完成冗长复杂任务等特点。
OpenAI Codex 团队在一场线上活动中提到，他们也在积极地使用 Codex 来构建 Codex 产品本身。
设计师甚至直接用 Codex 合并代码，有位工程师表示目前自己 99%的改动都依靠 Codex 完成，目标是明年完全不再手写一行代码。
产品经理用 Codex 写不熟悉的语言（如 Rust），经常在开会间隙用手机先启动任务，之后再通过 VS Code 插件接着完成。
工程师在规划新功能时，会通过 5 轮左右的提示词快速生成多个原型，以便快速理解项目的复杂程度和技术需求。
团队也用 Codex 快速构建内部工具，包括可视化监控、数据生成工具等。有设计师表示 70%的工作依靠 Codex，极大缩短了想法到实现的距离。
总结来说，Codex 已经全面融入到了 OpenAI 内部开发流程当中。
这篇博客文章，详细地介绍了内部工程师们在日常工作中是如何使用 Codex 的，同时结合内部使用数据，给出了一份真实用例和实践指南。
文章很详细，不止是针对使用 Codex，实际上是总结了一套方法论：如何通过提供精准的上下文、结构化的指令以及优化的环境等，将 AI Ccoding 工具从一个「代码补全玩具」 训练成一个可以深度融入专业开发流程的「初级工程师」 。
本篇文章来自「宝玉老师」编译版本。
超 13000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
最新、最值得关注的 AI 新品资讯；
不定期赠送热门新品的邀请码、会员码；
最精准的AI产品曝光渠道
无论是理解复杂系统、重构大型代码库，还是在新功能上线、处理紧急故障时，各个团队都在利用 Codex 来加速各类工程任务。
这篇文章是我们采访了 OpenAI 的工程师，并结合内部使用数据后，总结出的一系列真实用例和最佳实践。从中，你可以看到 Codex 是如何帮助我们的团队提高效率、提升工作质量，并从容应对大规模系统复杂性的。
01
应用场景
应用场景 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 字符串的模块，而不是使用我们推荐的查询构建器。
用函数式编程的风格重写这段代码，避免变量突变和副作用。
02
最佳实践
要想让 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」功能允许你针对同一个任务同时生成多个版本的回复，这样你就可以快速探索不同的解决方案，并挑选出最好的一个。 对于更复杂的任务，你可以审查多个版本，并将不同回复的优点结合起来，得到一个更强的结果。
03
展望未来
Codex 目前仍处于研究预览阶段，但它已经实实在在地改变了我们的构建方式，帮助我们加快开发速度、编写更高质量的代码，并有余力去处理那些在过去可能永远不会被优先考虑的工作。
随着我们的模型越来越强大，Codex 也将更深度地融入我们的工作流中。我们对未来的潜力感到无比兴奋，并期待着用它解锁更多强大的软件开发方式。
我们也会继续分享一路走来的所学所得。
