本文翻译 OpenAI 官方发布的文章 How we used Codex to build Sora for Android in 28 days。本文介绍了 OpenAI Sora 开发团队如何在短短 28 天内，利用 Codex CLI 成功构建并发布 Sora Android 应用程序的过程。文章中不仅展示了惊人的开发速度和质量，还深入探讨了在 AI 辅助开发时代，软件工程模式的转变以及人机协作的最佳实践。本文由我和 Gemini 3 Pro 共同完成翻译。
我们如何利用 Codex 在 28 天内构建出 Sora Android 版
作者：Patrick Hum 和 RJ Marsan，技术团队成员
11 月，我们向全球推出了 Sora Android 应用，让任何拥有 Android 设备的人都能将简短的提示词转化为生动的视频。发布当天，该应用登上了 Play 商店榜首。Android 用户在首个 24 小时内生成了超过一百万个视频。
在这次发布背后有一个故事：Sora 的 Android 生产级初始版本仅用 28 天就构建完成，这要归功于任何团队或开发者都可以使用的同一个智能体（agent）：Codex。
从 2025 年 10 月 8 日到 11 月 5 日，一个精简的工程团队与 Codex 并肩工作，消耗了大约 50 亿个 token，完成了 Sora Android 版从原型到全球发布的全部过程。尽管规模庞大，该应用仍保持了 99.9% 的无崩溃率，并拥有我们引以为豪的架构。如果你想知道我们是否使用了秘密模型，答案是我们使用了早期版本的 GPT‑5.1-Codex 模型——即任何开发者或企业今天都可以通过 CLI、IDE 扩展或 Web 应用程序使用的同一版本。
拥抱布鲁克斯定律：保持灵活以快速行动
当 Sora 在 iOS 上发布时，使用量呈爆炸式增长。人们立即开始生成源源不断的视频。相比之下，在 Android 方面，我们在 Google Play 上只有少量内部原型和数量不断增加的预注册用户。
对于高风险、时间紧迫的发布，常见的反应是堆积资源和增加流程。这种规模和质量的生产级应用通常涉及许多工程师工作数月，并受制于协调工作而进展缓慢。
美国计算机架构师弗雷德·布鲁克斯（Fred Brooks）曾有一句名言警告说：“向进度落后的软件项目增加人力，只会让进度更加落后。”换句话说，当试图快速交付一个复杂的项目时，增加更多的工程师往往会因为增加沟通开销、任务碎片化和整合成本而降低效率。我们没有忽视这一见解，而是深入贯彻了它；我们组建了一支由四名工程师组成的精干团队——全员配备 Codex，以大幅提高每位工程师的影响力。
通过这种方式工作，我们在 18 天内向员工发布了 Sora Android 的内部构建版本，并在 10 天后公开发布。我们在 Android 工程实践上保持了高标准，在可维护性方面进行了投入，并让该应用达到了我们对更传统项目所期望的同等可靠性标准。（我们今天也继续广泛使用 Codex 来演进应用并带来新功能）。
入职一位新的高级工程师
要理解我们是如何与 Codex 合作的，了解它的长处和需要指导的地方很有帮助。把它当作一位新入职的高级工程师是一个很好的方法。Codex 的能力意味着我们可以花更多的时间指导和审查代码，而不是自己编写代码。
Codex 需要指导的地方
- Codex 尚不擅长推断未被告知的内容（例如，你偏好的架构模式、产品策略、真实用户行为以及内部规范或捷径）。
- 同样，Codex 无法看到应用的实际运行：它无法在设备上打开 Sora，无法注意到滚动感觉不对劲，或者感觉到某个流程令人困惑。只有我们的团队才能覆盖这些体验式任务。
- 每个实例都需要入职培训。分享包含明确目标、约束条件以及“我们会怎么做”的指导背景信息，对于让 Codex 良好执行至关重要。
- 同样，Codex 在深度架构判断上很吃力：如果任其发展，它可能会引入额外的视图模型（View Model），而我们其实是想扩展现有的视图模型，或者将逻辑推入本应属于存储库（Repository）的 UI 层。它的本能是让代码能跑通，而不是优先考虑长期的整洁度。
我们发现让 Codex 在整个代码库中创建和维护大量的 AGENT.md 文件非常有用。这使得在该会话之间应用相同的指导和最佳实践变得容易。例如，为了确保 Codex 按照我们的风格指南编写代码，我们在顶级 AGENTS.md 中添加了以下内容：
纯文本
## Formatting and static checks
- **Always run** `./gradlew detektFix` (or for the affected modules) **before committing**. CI will fail if formatting or detekt issues are present.
Codex 擅长的地方
- 快速阅读和理解大型代码库： Codex 基本通晓所有主流编程语言，这使得在不需要复杂抽象的情况下，更容易在多个平台间复用相同的概念。
- 测试覆盖率： Codex 对编写单元测试以覆盖广泛的用例有着（独特的）热情。并非每个测试都很深入，但拥有广泛的覆盖率有助于防止回归。
- 应用反馈： 同样，Codex 善于对反馈做出反应。当 CI 失败时，我们可以将日志输出粘贴到提示中，并要求 Codex 提出修复建议。
- 大规模并行、一次性执行： 大多数人不会触及他们在同一时间实际运行会话数量的上限。并行测试多个想法并将代码视为可丢弃的是高度可行的。
- 提供新视角： 在设计讨论中，我们使用 Codex 作为生成工具来探索潜在的故障点，并发掘解决问题的新方法。例如，在我们设计视频播放器内存优化时，Codex 筛选了多个 SDK，提出了我们本没有时间去分析的方法。Codex 研究得出的见解对于最大限度地减少最终应用的内存占用证明是无价的。
- 实现更高杠杆率的工作： 在实践中，我们最终花在审查和指导代码上的时间比自己编写代码的时间更多。也就是说，Codex 也非常擅长代码审查，经常在合并之前捕捉到错误，从而提高可靠性。
一旦我们认识到这些特征，我们的工作模式就变得更加直截了当。我们依靠 Codex 在理解透彻的模式和界限清晰的范围内完成大量的繁重工作，而我们的团队则专注于架构、用户体验、系统性变更和最终质量。
手工夯实基础
即使是最优秀的新进高级员工，也无法立即拥有做出长期权衡的正确视角。为了利用 Codex 并确保其工作稳健且可维护，关键在于我们要亲自监督应用的系统设计和关键权衡。这些包括塑造应用的架构、模块化、依赖注入和导航；我们还实现了身份验证和基础网络流程。
在这个基础上，我们端到端地编写了几个具有代表性的功能。我们使用了希望整个代码库遵循的规则，并边做边记录项目范围内的模式。通过指引 Codex 参考这些具有代表性的功能，它能够在我们的标准内更独立地工作。对于一个我们要估计 85% 代码由 Codex 编写的项目来说，精心规划的基础避免了昂贵的返工和重构。这是我们做出的最重要的决定之一。
我们的想法不是尽快做出“能用的东西”，而是要做出“理解我们希望事物如何运作的东西”。编写代码有许多“正确”的方式。我们不需要告诉 Codex 确切要做什么；我们需要向 Codex 展示在这个团队中什么是“正确”的。一旦确立了起点和我们构建的方式，Codex 就准备好开始了。
为了看看会发生什么，我们确实尝试过提示：“基于 iOS 代码构建 Sora Android 应用。开始”，但很快放弃了这条路。虽然 Codex 创建的内容在技术上是可行的，但产品体验欠佳。而且在没有清楚了解端点、数据和用户流程的情况下，Codex 的一次性（single-shot）代码并不可靠（即使不使用智能体，合并数千行代码也是有风险的）。
我们假设 Codex 在一个拥有编写良好的示例沙盒中会如鱼得水；我们是对的。要求 Codex 在几乎没有上下文的情况下“构建这个设置屏幕”是不可靠的。要求 Codex “使用与你刚刚看到的这个屏幕相同的架构和模式构建这个设置屏幕”效果要好得多。人类做出结构性决策并设定不变量；Codex 随后在该结构内填充大量代码。
在编写代码前与 Codex 一起规划
我们最大化 Codex 潜力的下一步是弄清楚如何让 Codex 在无人监管的情况下长时间工作（最近，超过 24 小时）。
在使用 Codex 的早期，我们直接跳到这样的提示：“这是功能。这是一些文件。请构建它。”这有时奏效，但大多生成的代码虽然技术上可以编译，却偏离了我们的架构和目标。
所以我们改变了工作流程。对于任何非微小的更改，我们首先要求 Codex 帮助我们理解系统和代码是如何工作的。例如，我们会要求它阅读一组相关文件并总结该功能是如何工作的；比如，数据是如何从 API 流经存储库层、视图模型并进入 UI 的。然后我们会纠正或完善它的理解。（例如，我们会指出某个特定的抽象实际上属于不同的层，或者给定的类仅用于离线模式，不应被扩展。）
这就好比你可能会与一位新来的、能力很强的队友互动一样，我们与 Codex 一起制定了一个扎实的实施计划。该计划通常看起来像一份微型设计文档，指导哪些文件应该更改，应该引入什么新状态，以及逻辑应该如何流转。只有在那之后，我们才要求 Codex 开始执行计划，一步一步来。有一个有用的小提示：对于非常长的任务，当我们达到上下文窗口的限制时，我们会要求 Codex 将其计划保存到一个文件中，允许我们在不同实例间应用相同的指导。
这个额外的规划循环被证明是值得花时间的。它允许我们让 Codex 长时间“无人监管”地运行，因为我们知道它的计划。这使得代码审查变得更容易，因为我们可以对照我们的计划检查实现，而不是在没有上下文的情况下阅读差异（diff）。当出现问题时，我们可以先调试计划，再调试代码。
这种动态感觉类似于一份好的设计文档给技术负责人带来的项目信心。我们不仅仅是在生成代码：我们是在生产支持共享路线图的代码。
分布式工程
在项目的高峰期，我们要经常并行运行多个 Codex 会话。一个在做播放功能，另一个在做搜索，另一个在做错误处理，有时还有一个在做测试或重构。这感觉不像是使用工具，更像是管理一个团队。
每个会话都会定期向我们报告进度。一个可能会说，“我完成了这个模块的规划；这是我的建议”，而另一个会提供一个新功能的大型代码差异。每一个都需要关注、反馈和审查。这与作为一名技术负责人带领几位新工程师惊人地相似，所有人都在进步，所有人都需要指导。
结果是一种协作流。Codex 强大的编码能力将我们从大量的重复输入中解放出来。我们有更多的时间思考架构，仔细阅读合并请求（Pull Requests），并测试应用。
与此同时，这种额外的速度意味着我们的审查队列中总是有等待处理的内容。Codex 不会因为上下文切换而被阻塞，但我们会。我们开发的瓶颈从编写代码转移到了做决策、提供反馈和整合变更上。
这就是布鲁克斯的见解以一种新的方式落地的地方。你不能简单地增加 Codex 会话并期望线性的速度提升，就像你不能不断向项目增加工程师并期望时间表线性缩短一样。每增加一双“手”，即使是虚拟的手，也会增加协调开销。我们变成了管弦乐队的指挥，而不仅仅是更快的独奏者。
Codex 作为跨平台超能力
我们的项目以一个巨大的垫脚石开始：Sora 已经在 iOS 上发布了。我们经常指引 Codex 参考 iOS 和后端代码库，以帮助它理解关键需求和约束。在整个项目中，我们开玩笑说我们重新发明了跨平台框架的概念。忘掉 React Native 或 Flutter 吧；跨平台的未来就是 Codex。
这句玩笑话背后有两个原则：
- 逻辑是可移植的。 无论代码是用 Swift 还是 Kotlin 编写的，底层的应用逻辑——数据模型、网络调用、验证规则、业务逻辑——都是相同的。Codex 非常擅长阅读 Swift 实现并生成保留语义的等效 Kotlin 代码。
- 具体示例提供了强大的上下文。 一个能看到“这是在 iOS 上确切的工作方式”和“这是 Android 架构”的全新 Codex 会话，远比仅根据自然语言描述工作的会话有效得多。
应用这些原则，我们将 iOS、后端和 Android 仓库放在同一个环境中。我们给 Codex 这样的提示：
“阅读 iOS 代码中的这些模型和端点，然后提出一个计划，利用我们现有的 API 客户端和模型类在 Android 上实现等效行为。”
一个小而有用的技巧是在 ~/.codex/AGENTS.md 中详细说明本地仓库的位置及其包含的内容。这使得 Codex 更容易发现和导航相关代码。
我们实际上是在通过翻译而非共享抽象来进行跨平台开发。因为 Codex 处理了大部分翻译工作，我们避免了双重实施成本。
更广泛的教训是，对于 Codex 来说，上下文就是一切。当 Codex 理解功能在 iOS 中是如何工作的，并结合对 Android 应用结构的理解时，它能发挥出最佳水平。当 Codex 缺乏这种上下文时，它并不是“拒绝合作”；它是在猜测。我们越是把它当作新队友并投入精力给予正确的输入，它的表现就越好。
明天的软件工程，始于今日
在我们为期四周的冲刺结束时，使用 Codex 不再感觉像是一场实验，而成为了我们的默认开发循环。我们用它来理解现有代码、规划变更和实现功能。我们像审查队友的输出一样审查它的输出。这就是我们发布软件的方式。
很明显，AI 辅助开发并没有减少对严谨性的需求；反而增加了这种需求。尽管 Codex 能力强大，但它的目标是立刻从 A 到达 B。这就是为什么 AI 辅助编程离不开人类。软件工程师能够理解并应用系统的现实世界约束、构建软件的最佳方式，以及如何在构建时考虑到未来的开发和产品计划。明天软件工程师的超能力将是深刻的系统理解能力以及在长时间范围内与 AI 协作的能力。
软件工程最有趣的部分是构建引人入胜的产品、设计可扩展的系统、编写复杂的算法，以及利用数据、模式和代码进行实验。然而，过去和现在的软件工程现实往往偏向于平凡琐碎：居中按钮、连接端点和编写样板代码。现在，Codex 让专注于软件工程最有意义的部分以及我们热爱这门手艺的原因成为可能。
一旦将 Codex 设置在一个上下文丰富的环境中，让它理解你的目标和你喜欢的构建方式，任何团队都可以倍增其能力。我们的发布回顾并不是一个放之四海而皆准的秘方，我们也并不声称已经解决了 AI 辅助开发的问题。但我们希望我们的经验能让你更容易找到赋能 Codex 以便更好地为你赋能的最佳方式。
当 Codex 在七个月前作为研究预览版推出时，软件工程看起来截然不同。通过 Sora，我们要探索工程的下一个篇章。随着我们的模型和工具不断改进，AI 将成为构建过程中日益不可或缺的一部分。
你将利用你自己的 Codex 团队创造什么？