我们如何使用 Codex 在 28 天内构建 Android 版 Sora

原文：How we used Codex to build Sora for Android in 28 days 作者：Patrick Hum 和 RJ Marsan，技术人员

11月，我们面向全球发布了Sora安卓应用，让所有安卓设备用户都能将简短的提示信息转化为生动的视频。应用上线首日便荣登Play商店榜首。安卓用户在短短24小时内就创作了超过一百万个视频。

此次发布背后有一个故事：Sora 的 Android 生产应用的初始版本仅用了 28 天就构建完成，这要归功于任何团队或开发者都可以使用的同一个 Agent：Codex。

从 2025 年 10 月 8 日到 11 月 5 日，一支精干的工程团队与 Codex 紧密合作，耗费约 50 亿个 tokens，成功将安卓版 Sora 从原型开发推向全球发布。尽管规模庞大，该应用的无崩溃率却高达 99.9%，其架构也令我们引以为傲。如果您好奇我们是否使用了什么秘密模型，答案是：我们使用的是 GPT-5.1-Codex 模型的早期版本——任何开发者或企业如今都可以通过 CLI、IDE 扩展或 Web 应用使用该版本。

提示：花样滑冰运动员头上顶着一只猫表演三周跳

践行布鲁克斯定律：保持灵活才能快速行动

Sora 在 iOS 上线后，用户数量呈爆炸式增长。用户立即开始大量上传视频。相比之下，在 Android 平台上，我们当时只有一个小型内部原型，以及在 Google Play 上不断增长的预注册用户数量。

面对高风险、时间紧迫的项目发布，常见的应对措施是投入大量资源并增加流程。开发如此规模和质量的生产级应用通常需要众多工程师耗时数月，而协调工作会大大降低效率。

美国计算机架构师弗雷德·布鲁克斯曾发出著名的警告：“在已经延期的软件项目中增加人手只会让项目延期。“换句话说，当试图快速交付一个复杂的项目时，增加工程师人数往往会因为增加沟通开销、任务碎片化和集成成本而降低效率。我们没有忽视这一洞见，而是积极采纳；我们组建了一支由四名工程师组成的强大团队——所有成员都配备了Codex，以大幅提升每位工程师的影响力。

通过这种方式，我们仅用了 18 天就向员工交付了 Sora 的内部 Android 版本，并在 10 天后正式发布。我们始终坚持高标准的 Android 工程实践，注重可维护性，并要求该应用达到与传统项目相同的可靠性标准。（如今，我们仍然广泛使用 Codex 来不断改进应用并添加新功能。）

为新入职的高级工程师进行培训

为了更好地理解我们与 Codex 的合作方式，了解它的优势和需要改进的地方至关重要。将其视为一位新聘的高级工程师是一个不错的策略。Codex 的强大功能意味着我们可以将更多时间用于指导和审查代码，而不是自己编写代码。

Codex 需要指导的地方

我们发现让 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 指向这些代表性功能，它能够在我们的标准范围内更加独立地工作。据估计，该项目 85% 的代码都是由 Codex 编写的，因此，精心规划的基础架构避免了代价高昂的返工和重构。这是我们做出的最重要的决定之一。

我们的目标不是尽快做出”能用的东西”，而是做出”能按我们预期方式运行的东西”。编写代码有很多种”正确”的方法。我们不需要告诉 Codex 具体该怎么做；我们需要向 Codex 展示我们团队认为什么是”正确”的方法。一旦确定了起点和我们喜欢的开发方式，Codex 就可以开始了。

为了探究其后果，我们尝试执行了”基于 iOS 代码构建 Sora Android 应用。开始”的 Prompt，但很快就放弃了。虽然 Codex 开发的代码在技术上可行，但产品体验却差强人意。而且，由于对接口、数据和用户流程缺乏清晰的理解，Codex 的一次性代码运行起来很不可靠（即使不使用 Agent，合并数千行代码也存在风险）。

我们假设 Codex 会在精心编写的示例环境中茁壮成长；事实证明我们是对的。在几乎没有任何上下文的情况下让 Codex “构建这个设置界面”是不可靠的。而让 Codex “使用与你刚才看到的那个界面相同的架构和模式来构建这个设置界面” 则效果好得多。人类负责构建结构并设定不变式；然后 Codex 在该结构中填充大量代码。

在编码之前先使用 Codex 进行规划

为了最大限度地发挥 Codex 的潜力，我们的下一步是弄清楚如何让 Codex 能够在无人监督的情况下长时间运行（最近超过 24 小时）。

在使用 Codex 的早期阶段，我们直接给出类似这样的 Prompt：“这是功能描述。这是一些文件。请构建它。” 这种方法有时有效，但大多数情况下生成的代码虽然技术上可以编译，却偏离了我们的架构和目标。

因此，我们改变了工作流程。对于任何非微不足道的更改，我们首先会请 Codex 帮助我们理解系统和代码的工作原理。例如，我们会让它读取一组相关文件，并总结该功能的工作原理；例如，数据如何从 API 流经存储库层、视图模型，最终进入 UI。然后，我们会纠正或完善它的理解。（例如，我们会指出某个特定的抽象实际上应该放在不同的层，或者某个类仅存在于离线模式下，不应该被扩展。）

就像你如何与一位能力出众的新队友合作一样，我们与 Codex 共同制定了一份完善的实施计划。这份计划通常就像一份小型设计文档，详细列出了需要修改的文件、需要引入的新状态以及逻辑流程。只有完成这些步骤，我们才会要求 Codex 开始逐步执​​行计划。一个小技巧：对于耗时很长的任务，当 Context Window 达到极限时，我们会要求 Codex 将计划保存到一个文件中，这样我们就可以在不同的实例中应用相同的方向。

事实证明，这个额外的规划流程非常值得。它让我们能够让 Codex 长时间”无人值守”地运行，因为我们了解它的规划。它也简化了代码审查，因为我们可以根据规划检查实现，而不是在缺乏上下文的情况下阅读差异。而且，当出现问题时，我们可以先调试规划，然后再调试代码。

这种感觉就像一份优秀的设计文档能让技术负责人对项目充满信心一样。我们不仅仅是在编写代码，我们编写的代码能够支持共同的路线图。

分布式工程

项目高峰期，我们经常同时运行多个 Codex 会话。一个在处理回放，一个在处理搜索，一个在处理错误处理，有时还会有一个在做测试或重构。感觉与其说是在使用工具，不如说是在管理团队。

每个小组都会定期向我们汇报进展。有人可能会说：“我已经完成了这个模块的规划；这是我的方案”，而有人则会提出一个关于新功能的大幅改进方案。每个方案都需要我们关注、反馈和审核。这与技术主管带领几位新工程师的情况惊人地相似，他们都在取得进展，也都需要指导。

最终实现了高效的协作流程。Codex 强大的原生编码功能让我们摆脱了大量手动输入工作。我们有更多的时间思考架构、仔细阅读 pull request 并测试应用。

与此同时，速度的提升也意味着我们的审核队列里总是有待处理的内容。Codex 不会因为上下文切换而卡顿，但我们却会。开发过程中的瓶颈从编写代码转移到了决策、提供反馈和整合变更。

这就是布鲁克斯的洞见以一种全新的方式呈现。你不能简单地增加 Codex 会议次数就指望速度线性提升，就像你不能不断地给项目增加工程师就指望工期线性缩短一样。每一”人手”，即使是虚拟的，都会增加协调的开销。我们不再只是速度更快的独奏者，而是变成了交响乐团的指挥。

Codex 作为一种跨平台超级大国

我们的项目起步就拥有一个巨大的优势：Sora 已经发布了 iOS 版本。我们经常让 Codex 参考 iOS 和后端代码库，以帮助他们理解关键需求和限制。在整个项目过程中，我们经常开玩笑说，我们重新定义了跨平台框架的概念。别提 React Native 或 Flutter 了；跨平台的未来就是 Codex。

这句俏皮话背后蕴含着两个原则：

  1. 逻辑具有可移植性。无论代码是用 Swift 还是 Kotlin 编写的，底层应用程序逻辑——数据模型、网络调用、验证规则、业务逻辑——都是相同的。Codex 非常擅长读取 Swift 实现，并生成语义一致的 Kotlin 等效代码。
  2. 具体的例子能提供强有力的背景信息。一个全新的 Codex 课程，如果能展示”这是 iOS 上的具体实现方式”和”这是 Android 的架构”，其效果远胜于仅仅依靠自然语言描述的课程。

为了实践这些原则，我们将 iOS、后端和 Android 的代码仓库放在了同一个环境中。我们还提供了 Codex 的 Prompt，例如：

“请阅读 iOS 代码中的这些模型和端点，然后提出一个方案，使用我们现有的 API 客户端和模型类在 Android 上实现等效行为。“

一个虽小但很实用的技巧是详细说明 ~/.codex/AGENTS.md 本地代码库的位置及其包含的内容。这使得 Codex 更容易发现和浏览相关代码。

我们实际上是通过代码翻译而非共享抽象来进行跨平台开发。由于 Codex 承担了大部分翻译工作，我们避免了实现成本翻倍。

更广泛的启示是，对于 Codex 而言，上下文至关重要。当 Codex 理解 iOS 中已有的功能运作方式，并了解我们 Android 应用的架构时，它才能发挥最佳性能。当 Codex 缺乏这些上下文信息时，它并非”拒绝合作”，而是在猜测。我们越是像对待新队友一样对待它，并投入精力为它提供正确的输入，它的表现就越出色。

面向未来的软件工程，就在今天

经过四周的迭代开发，使用 Codex 不再像是一项实验，而是成为了我们默认的开发流程。我们用它来理解现有代码、规划变更并实现新功能。我们审查 Codex 的输出结果，就像审查团队成员的代码一样。这已经成为我们交付软件的固定方式。

很明显，AI 辅助开发并不会降低对严谨性的要求，反而会提高。尽管 Codex 功能强大，但它的目标仍然是快速实现从 A 到 B 的转换。正因如此，AI 辅助编码离不开人类的参与。软件工程师能够理解并应用系统的实际约束，掌握最佳的软件架构方法，并能在构建过程中充分考虑未来的发展和产品规划。未来软件工程师的超能力将是深刻的系统理解以及与 AI 进行长期协作的能力。

软件工程最有趣的部分在于构建引人入胜的产品、设计可扩展的系统、编写复杂的算法以及对数据、模式和代码进行实验。然而，过去和现在软件工程的现实往往更加枯燥乏味：按钮居中、连接接口、编写样板代码。现在，Codex 让软件工程中最具意义的部分以及我们热爱这份工作的理由成为可能。

一旦 Codex 被部署在一个能够理解您的目标和构建方式的、包含丰富上下文信息的环境中，任何团队都能倍增其功能。我们的发布回顾并非万能方案，我们也并不声称已经解决了 AI 辅助开发的问题。但我们希望我们的经验能够帮助您更轻松地找到赋能 Codex 的最佳方法，从而更好地赋能于您。

七个月前，Codex 以研究预览版的形式发布时，软件工程的面貌与现在截然不同。通过 Sora，我们得以探索工程的下一个篇章。随着我们的模型和工具不断改进，AI 将成为构建过程中不可或缺的一部分。

你打算用你自己的 Codex 团队做出什么？