摘要：本文基于对OpenAI工程师的访谈和内部使用数据，汇编了多个用例和最佳实践，展示Codex如何帮助团队更快地行动、提高工作质量，并大规模地管理复杂性

Codex已深入OpenAI各大技术团队的日常工作，包括安全、产品工程、前端、API、基础设施和性能工程等

本文基于对OpenAI工程师的访谈和内部使用数据，汇编了多个用例和最佳实践，展示Codex如何帮助团队更快地行动、提高工作质量，并大规模地管理复杂性

7大核心用法 用法一：代码理解

Codex帮助我们的团队在新员工入职、调试或调查事故时，快速熟悉代码库的陌生部分。

工程师们常用Codex来定位功能的核心逻辑、梳理服务或模块间的关系，并追踪系统中的数据流。它还能揭示架构模式或缺失的文档，而这些通常需要大量手动工作才能生成。

在事故响应期间，Codex通过揭示组件间的交互或追踪故障状态在系统间的传播路径，帮助工程师快速进入新的代码领域

团队成员分享：

这个仓库中的认证逻辑是在哪里实现的？

总结一下请求是如何从入口点到响应流经这个服务的。

哪些模块与 [插入模块名] 交互，故障是如何处理的？

用法二：重构与迁移

Codex常被用于执行跨多个文件或包的变更。例如，当工程师更新API、更改模式实现方式或迁移到新的依赖项时，Codex可以轻松地保证变更的一致性。

当同一更新需要在数十个文件中进行，或者更新需要感知那些无法用正则表达式或查找替换轻松捕捉的结构和依赖关系时，它尤其有用。

工程师们也用它来进行代码清理，比如将过大的模块拆分成小块、用现代模式替换旧模式，或为更好的可测试性准备代码。

团队成员分享：

按功能将此文件拆分为独立的模块，并为每个模块生成测试。

将所有基于回调的数据库访问转换为async/await模式。

用法三：性能优化

Codex被用于识别和解决性能瓶颈。

在性能调优或可靠性工作中，工程师会提示Codex分析缓慢或内存密集型的代码路径，如低效循环、冗余操作或高成本查询，并建议优化方案，这通常会带来显著的效率和可靠性提升

Codex还通过识别仍在使用的高风险或已弃用的模式来支持代码健康。团队依靠它来帮助减少长期技术债务并主动预防回归。

团队成员分享：

优化此循环以提高内存效率，并解释为什么你的版本更快

在此请求处理程序中找到重复的高成本操作，并建议缓存机会

建议一种更快的方式来批量处理此函数中的数据库查询。

用法四：提升测试覆盖率

Codex帮助工程师更快地编写测试，尤其是在覆盖率很低或完全缺失的地方

在修复bug或进行重构时，工程师经常要求Codex建议能够覆盖边缘案例或潜在失败路径的测试。对于新代码，它可以根据函数签名和周围逻辑生成单元测试或集成测试

Codex在识别边界条件方面特别有用，例如空输入、最大长度或不寻常但有效的状态，这些在初步测试中常常被忽略。

团队成员分享：

为此函数编写单元测试，包括边缘案例和失败路径

为此排序工具生成一个基于属性的测试

扩展此测试文件，以覆盖关于null输入和无效状态的缺失场景。

用法五：提升开发速度

Codex通过加速开发周期的开始和结束阶段，帮助团队更快地行动。

在启动新功能时，工程师用它来搭建样板代码——生成文件夹、模块和API存根，从而快速获得可运行的代码，无需手动连接每个部分。

当项目接近发布时，Codex通过处理一些虽小但必不可少的任务来帮助满足紧张的截止日期，例如分类bug、填补最后的实现空白，以及生成部署脚本、遥测钩子或配置文件。

它也被用来将产品反馈转化为初始代码。工程师经常粘贴用户请求或规格说明，让Codex生成一个可以后续返回并完善的草稿。

示例提示：

为 POST /events 搭建一个新的API路由，包含基本的验证和日志记录

为跟踪新用户引导流程的成功/失败生成一个遥测钩子，使用这个模板 [插入你的遥测代码示例]

基于此规格说明创建一个存根实现：[插入规格说明或产品反馈]

用法六：保持心流

当工程师的日程被碎片化和中断填满时，Codex帮助他们保持生产力。

它被用来捕捉未完成的工作、将笔记转化为可工作的原型，或分拆出可供日后回顾的探索性任务。这使得暂停和恢复工作变得更加容易，而不会丢失上下文，尤其是在他们需要值班或会议繁多的时候。

团队成员分享：

生成一个重构此服务的计划，并将其拆分为更小的模块

为重试逻辑创建存根，并添加一个TODO——我稍后会填写退避逻辑

总结这个文件，这样我明天就知道该从哪里继续了

用法七：探索与构思

Codex对于开放式工作也很有用，比如寻找替代解决方案或验证设计决策。你可以提示它提供解决问题的不同方法、探索不熟悉的模式，或对假设进行压力测试。这有助于揭示权衡、扩展设计选项，并使实现选择更加清晰

它还被用来识别相关的bug。给定一个已知问题或已弃用的方法，Codex可以在代码中识别其他地方的类似模式，从而更容易地捕获回归或完成清理工作

团队成员分享：

示例提示：

如果系统是事件驱动而不是请求/响应模式，这个功能会如何工作？

找出所有手动构建SQL字符串而不是使用我们查询构建器的模块

用更函数式的风格重写此代码，避免突变和副作用

最佳实践

当获得结构、上下文和迭代空间时，Codex的效果最好。以下是OpenAI团队为在日常工作中持续获得价值而培养的一些习惯

1.从“提问模式”开始 (Start with Ask Mode)

对于大型变更，先提示Codex生成一个实现计划（使用Ask模式），这个计划随后会成为你切换到Code模式时后续提示的输入。这种两步流程能让Codex的输出更有根据，并有助于避免错误。Codex最适合处理那些需要你或团队成员花费大约一小时或几百行代码来完成的、范围明确的任务。随着模型的改进，它能承担的任务规模有望增加

2.迭代式改进Codex的开发环境

设置启动脚本、环境变量和网络访问能显著降低Codex的错误率。在运行任务时，注意那些可以在Codex环境配置中纠正的构建错误。这可能需要几次迭代，但从长远来看会带来显著的效率提升

3.像写Github Issue一样构建你的提示

当提示模仿你描述PR或Issue的方式时，Codex的响应会更好。这意味着在相关时要包含文件路径、组件名称、diffs和文档片段。使用像“用[模块X]中的同样方式实现这个”这样的模式可以改善结果

4.将Codex任务队列用作轻量级待办事项列表

分派任务来捕捉切题的想法、部分完成的工作或偶然发现的修复。没有必要一次性生成一个完整的PR。Codex可以作为一个暂存区，当你重新集中注意力时可以随时返回。

5.使用 AGENTS.md 提供持久上下文

维护一个AGENTS.md文件，以帮助Codex在你的仓库中跨多个提示更有效地操作。这些文件通常包含命名约定、业务逻辑、已知的怪癖，或Codex无法仅从代码中推断出的依赖关系

6.利用“N选最佳” (Best of N) 提升输出质量

“N选最佳”功能允许你为单个任务同时生成多个响应，以便快速探索多种解决方案并选择最佳方案。对于更复杂的任务，你可以审查多个迭代版本，并结合不同响应的部分来获得更强的结果

source：

来源：新浪财经