📢 转载信息
原文链接：https://openai.com/index/shipping-sora-for-android-with-codex
原文作者：Patrick Hum and RJ Marsan, Members of the Technical Staff
2025年12月12日
我们如何利用 Codex 在 28 天内为 Android 构建 Sora
作者：Patrick Hum 和 RJ Marsan，技术人员
去年 11 月，我们在全球推出了 Sora Android 应用，让任何拥有 Android 设备的用户都能将简短的提示词转化为生动的视频。在发布当天，该应用即登顶 Play 商店榜首。Android 用户在最初的 24 小时内生成了超过一百万个视频。
在这次发布背后有一个故事：Sora 的首个生产级 Android 应用版本仅用了 28 天就构建完成，这得益于与任何团队或开发者都能使用的同一个智能体：Codex。
从 2025 年 10 月 8 日到 11 月 5 日，一个精简的工程团队在 Codex 的协助下，消耗了大约 50 亿个 Token，将 Sora 从原型阶段推向了全球发布。尽管应用规模庞大，但其崩溃率仍保持在 99.9%，并且架构令人满意。如果您好奇我们是否使用了秘密模型，我们使用的是 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 需要指导的地方
- Codex 还不擅长推断未被告知的内容（例如，您偏好的架构模式、产品策略、真实用户行为以及内部规范或捷径）。
- 同样地，Codex 看不到应用实际运行的效果：它无法在设备上打开 Sora、察觉到滚动感觉不对劲，或者感知到某个流程令人困惑。只有我们的团队能够处理这些体验性的任务。
- 每个实例都需要入职培训。提供清晰的目标、约束条件以及关于“我们做事方式”的指导，对于使 Codex 良好执行至关重要。
- 同理，Codex 在处理深入的架构判断时遇到困难：如果任其发展，它可能会引入一个额外的视图模型，而我们其实想扩展现有的模型，或者将逻辑推入到应属于存储库（repository）的 UI 层。它的本能是让某物运行起来，而不是优先考虑长期的整洁性。
我们发现让 Codex 在代码库中创建和维护大量 AGENT.md 文件很有用。这使得在不同会话中应用相同的指导和最佳实践变得容易。例如，为了确保 Codex 遵循我们的代码风格指南，我们在顶层 AGENTS.md 中添加了以下内容：
纯文本
1## 格式设置和静态检查2- 提交前务必运行 ./gradlew detektFix（或针对受影响的模块）。如果存在格式设置或 detekt 问题，CI 将失败。Codex 擅长的方面
- 快速阅读和理解大型代码库：Codex 几乎了解所有主要的编程语言，这使得它更容易在无需复杂抽象的情况下，在多个平台上利用相同的概念。
- 测试覆盖率：Codex 对编写单元测试以覆盖各种情况表现出（独特的）热情。并非每个测试都很深入，但广泛的覆盖面有助于防止回归。
- 应用反馈：同样地，Codex 善于对反馈做出反应。当 CI 失败时，我们可以将日志输出粘贴到提示中，并要求 Codex 提出修复方案。
- 大规模并行、一次性执行：大多数人不会同时推到他们实际可以运行的会话数量的极限。并行测试多个想法并将代码视为一次性使用的（disposable）是完全可行的。
- 提供新视角：在设计讨论中，我们使用 Codex 作为生成式工具来探索潜在的故障点并发现解决问题的新方法。例如，在我们设计视频播放器内存优化时，Codex 筛选了多个 SDK 来提出我们可能没有时间解析的方法。Codex 研究提供的见解对于最小化最终应用的内存占用至关重要。
- 赋能更高杠杆率的工作：实际上，我们最终花在审查和指导代码上的时间比自己编写代码的时间更多。尽管如此，Codex 在代码审查方面也非常出色，通常能在代码合并前发现错误，从而提高可靠性。
一旦我们认识到这些特性，我们的工作模式就变得更加直接。我们依靠 Codex 在理解透彻的模式和界限清晰的范围内完成大量的繁重工作，而我们的团队则专注于架构、用户体验、系统更改和最终质量。
亲手打好基础
即使是最好、最新的高级“员工”，一开始也不会对长期权衡取舍有正确的视角。为了充分利用 Codex 并确保其工作稳健且可维护，我们必须亲自监督应用的系统设计和关键的权衡。这些包括塑造应用的架构、模块化、依赖注入和导航；我们还实现了身份验证和基础网络流程。
在此基础上，我们端到端地编写了几个有代表性的功能。我们采用了希望整个代码库遵循的规则，并在进行过程中记录了项目范围内的模式。通过向 Codex 展示有代表性的功能，它能够在我们的标准范围内更独立地工作。对于我们估计有 85% 代码由 Codex 编写的项目来说，精心规划的基础避免了代价高昂的回溯和重构。这是我们做出的最重要决定之一。
我们的目标不是尽快做出“能工作的东西”，而是做出“符合我们期望的运作方式的东西”。编写代码的方式有很多种“正确”的方法。我们不需要告诉 Codex 具体做什么；我们需要向 Codex 展示在我们团队中什么是“正确的”。一旦我们确立了起点以及我们偏好的构建方式，Codex 就准备好开始了。
为了看看会发生什么，我们确实尝试过直接提示：“基于 iOS 代码构建 Sora Android 应用。开始吧”，但很快就放弃了这条路线。虽然 Codex 创建的内容在技术上可行，但产品体验却不尽如人意。而且在没有对端点、数据和用户流程有清晰理解的情况下，Codex 单次生成的代码是不可靠的（即使不使用智能体，合并数千行代码也是有风险的）。
我们假设 Codex 在一个包含良好代码示例的沙盒环境中会表现出色；事实证明我们是对的。几乎没有背景信息的情况下要求 Codex “构建这个设置屏幕”是不可靠的。而要求 Codex “使用你刚才看到的另一个屏幕的相同架构和模式来构建这个设置屏幕”效果要好得多。人类做出了结构性决策并设定了不变量；然后 Codex 在该结构内填充了大量的代码。
在编码前与 Codex 共同规划
最大化 Codex 潜力的下一步是找到一种方法，使其能够长时间（最近，已超过 24 小时）在无人监督的情况下工作。
在使用 Codex 的早期，我们直接进入了“这是功能。这是些文件。请构建它”之类的提示。这有时有效，但更多时候会产生技术上可以编译但偏离我们架构和目标的 कोड。
因此，我们改变了工作流程。对于任何非微小的更改，我们首先要求 Codex 帮助我们理解系统和代码的工作原理。例如，我们会要求它阅读一组相关文件并总结该功能的工作原理；例如，数据如何从 API 流经存储库层、视图模型并进入 UI。然后我们会更正或完善它的理解。（例如，我们会指出某个特定的抽象应该存在于不同的层级，或者某个类只存在于离线模式而不应被扩展）。
与您与一位新的、能力很强的新队友互动类似，我们与 Codex 合作创建了一个可靠的实施计划。该计划通常看起来像一份微型设计文档，指导哪些文件需要更改、应该引入哪些新状态以及逻辑应如何流动。只有到那时，我们才要求 Codex 一步一步地应用该计划。一个小窍门是：对于非常长的任务，当超出我们的上下文窗口限制时，我们会要求 Codex 将其计划保存到一个文件中，以便我们可以在实例中应用相同的指导。
这个额外的规划循环被证明是值得的。它使我们能够让 Codex 运行很长时间而“无人看管”，因为我们了解它的计划。它使代码审查更容易，因为我们可以根据我们的计划检查实现，而不是在没有上下文的情况下阅读差异（diff）。当出现问题时，我们可以先调试计划，然后再调试代码。
这种动态类似于一份好的设计文档如何让技术负责人对项目充满信心。我们不仅仅是生成代码：我们正在生成支持共同路线图的代码。
分布式工程
在该项目的鼎盛时期，我们经常并行运行多个 Codex 会话。一个负责播放，另一个负责搜索，另一个负责错误处理，有时还有一个负责测试或重构。这感觉不像在使用工具，更像是在管理一个团队。
每个会话会定期向我们报告进度。一个可能会说：“我已经完成了这个模块的规划；这是我的提议”，而另一个可能会提供一个新功能的大量差异（diff）。每个都需要关注、反馈和审查。这与作为技术负责人管理着几位新工程师惊人地相似，他们都在取得进展，都需要指导。
结果是一种协作流程。Codex 的原始编码能力让我们从大量的手动输入中解放出来。我们有更多时间思考架构、仔细阅读拉取请求（pull request）以及测试应用。
同时，额外速度意味着我们的审查队列中总是有内容在等待。Codex 不会因为上下文切换而被阻塞，但我们会。我们在开发中的瓶颈从编写代码转移到了做决策、提供反馈和集成更改。
布鲁克斯的见解正是在这里以新的方式体现出来的。你不能简单地增加 Codex 会话数量并期望获得线性加速，就像你不能不断增加工程师数量并期望时间表线性缩短一样。每一个额外的“帮手”，即使是虚拟的，也会增加协调开销。我们已经从单纯更快的独奏者，变成了交响乐团的指挥。
Codex 作为跨平台超级能力
我们有一个巨大的垫脚石开始了我们的项目：Sora 已经在 iOS 上发布了。我们经常向 Codex 提供 iOS 和后端代码库，以帮助它理解关键需求和约束条件。在整个项目中，我们开玩笑说我们重新发明了跨平台框架的概念。忘掉 React Native 或 Flutter 吧；跨平台的未来就是 Codex。
在这个玩笑背后是两个原则：
- 逻辑是可移植的。无论代码是用 Swift 还是 Kotlin 编写，底层的应用程序逻辑——数据模型、网络调用、验证规则、业务逻辑——都是相同的。Codex 非常擅长阅读 Swift 实现并生成保留语义的 Kotlin 等效代码。
- 具体的例子提供了强大的上下文。一个全新的 Codex 会话如果能看到“这是它在 iOS 上的工作方式”和“这是 Android 架构”，比仅根据自然语言描述工作的会话要有效得多。
将这些原则付诸实践，我们将 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 团队创造什么？
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区