我们如何在28天内借助Codex发布Android版Sora

# 我们如何借助 Codex 在 28 天内为 Android 构建 Sora 来源：https://openai.com/index/shipping-sora-for-android-with-codex/ 去年 11 月，我们面向全球发布了 Sora Android 应用，让任何拥有 Android 设备的用户都能将简短的提示词转化为生动的视频。上线当天，该应用在 Play Store 登顶第一。Android 用户在头 24 小时内生成了超过 100 万个视频。 这次发布背后有一个故事：Sora 生产级 Android 应用的初始版本是在 28 天内构建完成的，这得益于同一个对所有团队和开发者开放的工具：Codex。 从 2025 年 10 月 8 日到 11 月 5 日，一个精简的工程团队与 Codex 协同工作，消耗了约 50 亿个 token，将 Sora for Android 从原型变成了全球发布。尽管规模庞大，该应用的崩溃率仅为 0.1%，并且我们对其架构感到自豪。如果你想知道我们是否使用了某个秘密模型，我们使用的是 GPT-5.1-Codex 模型的早期版本——正是任何开发者或企业今天都可以通过 CLI、IDE 扩展或 Web 应用使用的同一个版本。 提示词：花样滑冰运动员头顶一只猫完成三周跳 当 Sora 在 iOS 上发布时，使用量激增。人们立刻开始生成源源不断的视频。相比之下，在 Android 上，我们只有一个小的内部原型，以及 Google Play 上越来越多的预注册用户。 面对高风险、时间紧迫的发布，常见的反应是堆砌资源并增加流程。一个具有如此规模和质量的成品应用，通常需要多名工程师花费数月时间，并且会因协调而减慢速度。 美国计算机架构师 Fred Brooks 曾有名言：“向一个已经延期的软件项目增加人手，只会让它更延期。”换句话说，当试图快速交付一个复杂项目时，增加更多工程师往往会增加沟通开销、任务碎片化和集成成本，从而降低效率。我们接受了这一洞见，而不是忽略它；我们组建了一个由四名工程师组成的强大团队——每个人都配备了 Codex，以大幅提升每位工程师的影响力。 通过这种方式工作，我们在 18 天内向员工交付了 Sora for Android 的内部构建，并在 10 天后公开发布。我们保持了 Android 工程实践的高标准，投资于可维护性，并让应用达到了我们期望的传统项目同等的可靠性标准。（今天，我们仍然广泛使用 Codex 来演进应用并带来新功能。） 要理解我们如何与 Codex 合作，了解它的优势所在以及需要引导之处会很有帮助。把它当作一位新入职的高级工程师是一个不错的方法。Codex 的能力意味着我们可以花更多时间进行指导和审查代码，而不是自己编写。 **Codex 需要引导的方面** 1. Codex 还不擅长推断未被告知的信息（例如，你偏好的架构模式、产品策略、真实的用户行为、内部惯例或捷径）。 2. 同样，Codex 无法看到应用实际运行：它无法在设备上打开 Sora，注意到滚动感觉不对，或感觉到某个流程令人困惑。只有我们的团队能够覆盖这些体验性任务。 3. 每个实例都需要引导。分享清晰的上下文、目标、约束以及“我们做事的方式”的指导，对于让 Codex 良好执行至关重要。 4. 同理，Codex 在深度架构判断方面存在困难：如果放任不管，它可能在我们真正想扩展现有视图模型的地方引入一个额外的视图模型，或者将逻辑推到显然属于仓库层的 UI 层。它的本能是让东西跑起来，而不是优先考虑长期的整洁性。 我们发现，让 Codex 在整个代码库中创建并维护大量的 AGENT.md 文件非常有用。这使得在不同会话中应用相同的指导和最佳实践变得容易。例如，为了确保 Codex 按照我们的风格指南编写代码，我们在顶层 AGENTS.md 中添加了以下内容： **Codex 表现出色的方面** 1. 快速阅读和理解大型代码库：Codex 基本上了解所有主流编程语言，这使得在不使用复杂抽象的情况下，轻松地在多个平台上利用相同的概念。 2. 测试覆盖：Codex（独特地）热衷于编写单元测试以覆盖各种情况。并非每个测试都很深入，但覆盖广度有助于防止回归。 3. 反馈应用：类似地，Codex 善于对反馈做出反应。当 CI 失败时，我们可以将日志输出粘贴到提示中，让 Codex 提出修复方案。 4. 大规模并行、可抛弃的执行：大多数人不会推动在任何给定时间实际可以运行的会话数量上限。同时测试多个想法并将代码视为可抛弃的是非常可行的。 5. 提供新视角：在设计讨论中，我们将 Codex 用作生成工具，探索潜在的失败点并发现解决问题的新方法。例如，在我们设计视频播放器内存优化时，Codex 筛选了多个 SDK，提出了我们没有时间分析的方法。Codex 研究的见解在最小化最终应用的内存占用方面被证明是无价的。 6. 实现更高杠杆的工作：实际上，我们最终花更多时间审查和指导代码，而不是自己编写。尽管如此，Codex 也非常擅长代码审查，经常在合并之前捕获错误，从而提高可靠性。 一旦我们认识到这些特征，我们的工作模式就变得更加直接。我们依靠 Codex 在众所周知的模式和界限明确的范围内完成大量繁重的工作，而我们的团队则专注于架构、用户体验、系统性变更和最终质量。 即使是最优秀的新高级员工，也没有合适的视角来立即做出长期的权衡。为了利用 Codex 并确保其工作健壮且可维护，关键在于我们自己监督应用的系统设计和关键权衡。这包括塑造应用的架构、模块化、依赖注入和导航；我们还实现了认证和基本网络流程。 基于这个基础，我们从头到尾编写了几个代表性功能。我们使用了希望整个代码库遵循的规则，并在过程中记录了项目范围内的模式。通过将 Codex 指向代表性功能，它能够更独立地按照我们的标准工作。对于一个我们估计 85% 由 Codex 编写的项目，精心规划的基础避免了代价高昂的返工和重构。这是我们做出的最重要的决定之一。 这个想法不是尽可能快地做出“能用的东西”，而是做出“理解我们希望如何工作的东西”。有许多“正确”的代码编写方式。我们不需要精确地告诉 Codex 该做什么；我们需要向 Codex 展示在我们团队中什么是“正确”的。一旦我们确定了起点和我们喜欢的构建方式，Codex 就可以开始工作了。 为了看看会发生什么，我们确实尝试了这样的提示：“基于 iOS 代码构建 Sora Android 应用。开始。”但很快放弃了那条路。虽然 Codex 创建的内容技术上可行，但产品体验不佳。而且，在没有清晰理解端点、数据和用户流程的情况下，Codex 的一次性代码不可靠（即使不使用智能体，合并数千行代码也是有风险的）。 我们假设 Codex 在一个充满良好编写示例的沙盒中会表现出色；我们是对的。让 Codex 在几乎没有上下文的情况下“构建这个设置屏幕”是不可靠的。让 Codex “使用你刚刚看到的另一个屏幕的相同架构和模式来构建这个设置屏幕”效果要好得多。人类做出结构决策并设定不变量；然后 Codex 在该结构内填充大量代码。 我们最大化 Codex 潜力的下一步是弄清楚如何让 Codex 长时间（最近超过 24 小时（https://openai.com/index/gpt-5-1-codex-max/)）无人监督地工作。 在早期使用 Codex 时，我们直接扔出这样的提示：“这是功能。这是些文件。请构建它。”这有时有效，但大部分产生的代码技术上能编译，却偏离了我们的架构和目标。 所以我们改变了工作流程。对于任何非简单的更改，我们首先让 Codex 帮助我们理解系统和代码的工作原理。例如，我们让它读取一组相关文件并总结该功能的工作原理；例如，数据如何从 API 流经仓库层、视图模型并进入 UI。然后我们纠正或完善它的理解。（例如，我们会指出某个特定抽象实际上属于不同的层，或者某个类只用于离线模式，不应被扩展。） 类似于你可能如何与一位新来的、能力很强的队友合作，我们与 Codex 一起制定一个扎实的实现计划。那个计划通常看起来像一个小型设计文档，指示哪些文件应该更改，应该引入哪些新状态，以及逻辑应该如何流动。只有在那之后，我们才让 Codex 开始逐步应用计划。一个有用的提示：对于非常长的任务，当我们达到上下文窗口的限制时，我们会让 Codex 将其计划保存到一个文件中，这样我们就可以在不同实例中应用相同的方向。 这个额外的计划循环结果证明是值得花时间的。它允许我们让 Codex 长时间“无人监督”运行，因为我们知道它的计划。它使代码审查更容易，因为我们可以对照计划检查实现，而不是在没有上下文的情况下阅读差异。而且当出现问题的时候，我们可以先调试计划，再调试代码。 这种动态感觉类似于一份好的设计文档能让技术负责人对项目充满信心。我们不仅仅是在生成代码：我们是在生产支持共享路线图的代码。 在项目的高峰期，我们经常并行运行多个 Codex 会话。一个在处理播放，另一个在搜索，还有一个在错误处理，有时还有一个在测试或重构。这感觉不像在使用工具，更像是管理一个团队。 每个会话都会定期向我们报告进度。一个可能会说：“我完成了这个模块的计划；这是我的提议。”而另一个可能会为一个新功能提供一个大的差异。每个都需要关注、反馈和审查。这与作为几个新工程师的技术负责人惊人地相似，所有人都在取得进展，都需要指导。 结果是协作的流程。Codex 原始的编码能力让我们从大量的手动打字中解脱出来。我们有更多的时间思考架构，仔细阅读拉取请求，并测试应用。 同时，这种额外的速度意味着我们的审查队列中总是有东西在等待。Codex 不会被上下文切换阻塞，但我们会。我们开发的瓶颈从编写代码转移到了做出决策、提供反馈和整合更改。 这就是 Brooks 的见解以一种新的方式发挥作用的地方。你不能简单地增加 Codex 会话并期望线性加速，就像你不能不断向项目增加工程师并期望时间表线性缩减一样。每增加一双“手”，即使是虚拟的，都会增加协调开销。我们变成了乐队的指挥，而不仅仅是更快的独奏者。 我们的项目有一个巨大的垫脚石：Sora 已经在 iOS 上发布了。我们经常将 Codex 指向 iOS 和后端代码库，帮助它理解关键需求和约束。在整个项目中，我们开玩笑说我们重新发明了跨平台框架的概念。忘掉 React Native 或 Flutter；*跨平台的未来就是 Codex*。 在这个玩笑背后有两个原则： 1. 逻辑是可移植的。无论代码是用 Swift 还是 Kotlin 编写，底层应用逻辑——数据模型、网络调用、验证规则、业务逻辑——都是相同的。Codex 非常擅长阅读 Swift 实现并生成语义等价的 Kotlin 版本。 2. 具体示例提供了强大的上下文。一个能看到“这是如何在 iOS 上实现的”和“这是 Android 架构”的全新 Codex 会话，比仅从自然语言描述工作的会话要有效得多。 将这些原则付诸实践，我们将 iOS、后端和 Android 仓库放在同一个环境中。我们给 Codex 提示如： “读取 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 赋能您。 当 Codex 在七个月前以研究预览版发布时，软件工程看起来大不相同。通过 Sora，我们得以探索工程的下一个篇章。随着我们的模型和工具不断改进，AI 将日益成为开发中不可或缺的一部分。 您将用您自己的 Codex 团队创造什么？