「【新智元导读】OpenAI 爆款 APP，只动用了四员悍将。他们在短短 28 天内，完成了从 0 搭建安卓版 Sora。这背后，竟是 AI 完成了 85% 的编码。」
4 人 28 天手搓 Sora APP，约 85% 代码竟是 AI 写的！
10 月初，OpenAI 重磅发布迭代后 Sora 2，以及首个 AI 视频应用 Sora APP。
直到 11 月，安卓版 Sora 一经上线，就登上了谷歌 Play Store 榜首。
安卓用户在 24h 内，生成了超 100 万条视频
时隔两个月，OpenAI 团队揭秘这款爆火应用（首个安卓版），如何构建的背后故事。
让人意外的是，这款 APP 仅在 28 天内完成，背后最大功臣便是 AI 智能体------Codex。
从 10 月 8 日到 11 月 5 日，4 人工程团队与 Codex 协作，消耗约 50 亿 Token，就把 Sora Android 推向全球。
尽管应用规模虽大，却实现了 99.9% 无崩溃率。
而且，他们还使用的是 GPT-5.1-Codex 模型的早期版本。
发布仅 5 个月的时间，Codex 已经承包了 OpenAI 内部每周 70% 的 PR 了。
「拥抱 「布鲁克斯定律」：保持灵活，唯快不破」
当 Sora 在 iOS 上发布时，用户量直接原地爆炸。
相比之下，安卓当时只有一个简陋的内部原型，而在 Google Play 上预注册的用户却在越堆越多。
面对这种高压、火烧眉毛的发布任务，通常的反应就是疯狂堆人、加流程。
像这种规模和质量的生产级应用，通常得一大帮工程师干好几个月，而且还会被各种协调工作拖慢进度。
美国计算机架构师 Fred Brooks 曾有一句名言，「向一个已经延期的软件项目增加人手，只会让它延得更厉害」。
换句话说，想要快速交付一个复杂项目时，堆人往往增加了沟通成本、任务碎片化和集成难度，反而会降低效率。
为此，OpenAI 组建了一支只有四名工程师的「精锐小队」------全员配备 Codex，极大地把每个人的战斗力拉满。
靠着这种打法，在 18 天内就向员工发布了 Sora Android 的内部构建版本，仅仅 10 天后就向公众正式发布。
「AI 迭代 AI，自我进化」
在 OpenAI 内部，绝大部分工程师都在用 Codex，即开源版 CLI。
Codex 产品负责人 Alexander Embiricos 透露，「它会监控自己的训练过程，并处理用户反馈，「决定」下一步该做什么。
Codex 正在给自己的训练运行编写大量的研究测试框架（research harness），OpenAI 甚至在尝试让 Codex 去监控自己的训练过程。
这种「套娃」式的开发模式，可以让 Codex 自我迭代。
这种用工具造更好工具的递归循环，在计算历史上其实由来已久。
1960 年代，工程师们在纸上手工设计了第一批集成电路，然后根据图纸造出了物理芯片。
接着，这些芯片又驱动了运行第一批电子设计自动化（EDA）软件的电脑，而这些软件反过来又让工程师能设计出人类手绘根本搞不定的复杂电路。
现代处理器包含数十亿个晶体管，这种排列模式之所以能存在，全靠软件。
OpenAI 用 Codex 来造 Codex 似乎也是这个路子：每一代工具创造的能力，都会反哺到下一代中。
这个系统能自主运行许多进程，处理反馈，衍生并管理子进程，还能生成最终发布在实际产品里的代码。
OpenAI 员工管它叫「队友」，并且用诸如 Linear、Slack 等工具来给它派活儿。
Codex 处理的任务，到底算不算真正的「决策」？
但无可否认的是，这里形成了一个半自主的反馈循环：
Codex 在人类的指导下写代码，这些代码变成了 Codex 的一部分，结果就是下一个版本的 Codex 会写出不一样的代码。
「一位刚入职的「高级工程师」」
为了理解工程师是如何跟 Codex 配合的，需得先知道它哪里强、哪里需要人带。
把它当成一个「刚入职的高级工程师」是个很好的切入点。
这个定位，意味着工程师可以把更多时间花在指挥和 Review 代码上，而不是自己在那儿敲代码。
与「氛围编程」不同的是，让 Codex 编码属于「Vibe engineering」（氛围流工程）的领域。
前者是指，开发者不怎么细看就直接接受 AI 生成的代码，而后者是 AI 研究员 Simon Willison 提出的概念，指人类仍保持在循环中。
一般来说，让 Codex 干活 / 制定计划，再一起讨论，迭代计划，这样开发者就和模型保持在一个「循环」里，还能仔细审查代码。
「
」
「Codex 需要指导的地方」
目前，Codex 还不擅长推断未知的事。
比如，个人喜欢的架构模式、产品策略、真实用户行为，以及内部的潜规则或捷径。
同样，Codex 也看不到 App 实际跑起来的样子：
它没法在真机上打开 Sora，感觉不到滚动条是不是不丝滑，或者察觉到某个交互流程很别扭。
这些体验层面的活儿，只能靠 OpenAI 团队自己来。
每一个实例都需要「入职培训」。给出上下文，明确目标、约束条件，以及明确的规矩，对于让 Codex 把活儿干漂亮至关重要。
还有，Codex 在深层架构判断上也容易跑偏：如果放任不管，它可能会搞出一个多余的 ViewModel，实际上团队只想扩展现有的那个；或者把本该属于 Repository 层的逻辑硬塞进 UI 层。
它的本能是把功能跑通就行，而不是优先考虑长期的代码整洁度。
OpenAI 发现，在整个代码库里到处放大量的 AGENT.md 文件非常有用。
这能让工程师在不同的会话里，轻松复用相同的指导和最佳实践。
举个例子，为了确保 Codex 按照风格指南写代码，OpenAI 团队在顶层的 AGENTS.md 里加了这么一段：
markdown
## 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 对写单元测试有着独特的热情，能覆盖各种边缘情况。虽说不是每个测试都很深，但这广撒网的覆盖率对防止 Bug 回归特别有用。
- **响应反馈：**同样，Codex 很听劝。当 CI 挂了的时候，可以直接把日志甩给它（粘贴到 prompt 里），让它给个修复方案。
- **大规模并行、用完即弃：**大多数人根本没试探过并行会话数量的极限。开发者可以并行测试好几个想法，把代码当成一次性用品，不行就扔。
- **提供新视角：**在设计讨论中，团队会把 Codex 当成一个生成式工具，用它来挖掘潜在的故障点，或者发现解决问题的新路子。比如，在设计视频播放器内存优化时，Codex 翻遍了多个 SDK，提出了一些团队根本没时间去细究的方案。Codex 调研出的这些见解，对于将最终 App 内存占用降到最低简直价值连城。
- **腾出手做高杠杆工作：**实际上，团队最后花在 Review 和指挥代码上的时间，比自己写的时间还要多。话虽如此，Codex 在代码审查（Code Review）方面也很牛，经常能在合并代码前就揪出 Bug，提高了可靠性。
一旦摸清了 Codex 的能力，团队的工作模式就变得很直接了。
在模式清晰、范围明确的地方，让 Codex 去干那些繁重的苦力活；而团队则专注于架构、用户体验、系统性变更和把控最终质量。
「立规矩，手动打地基」
为了用好 Codex 并确保出活稳健、好维护，关键在于，开发者要亲自把控系统的设计和关键权衡。
这包括定好 App 的架构、模块化、依赖注入和导航；甚至身份验证和基础网络流程也是自己搞定的。
对于一个估算有 85% 的代码都是 Codex 写的项目来说，一个精心规划的地基避免了昂贵的返工和重构。
OpenAI 团队表示，「这绝对是我们做过的最正确的决定之一」。
一定要形成这样一个思路------
不是为了尽快搞个「能跑的东西」，而是要搞个「懂规矩的东西」。
写代码有很多种「正确」的方式：
- 不需要告诉 Codex 具体每一步怎么做；
- 但需要向 Codex 展示什么是「正确」的。
一旦定好了起点和团队喜欢的构建方式，Codex 就可以开工了。
为了看看会发生什么，OpenAI 团队确实试过直接给 Prompt：
照着 iOS 代码构建 Sora Android App。开始干。
结果，很快就翻车了。
虽然 Codex 写出来的东西技术上能跑，但产品体验完全不达标。
而且如果不懂端点、数据和用户流，Codex 这种「一锤子买卖」（Zero-shot）写出来的代码根本不可靠。哪怕不用 AI，一次性合并几千行代码也是作死。
OpenAI 的假设是，如果给 Codex 一个写满好范例的沙盒，它就能如鱼得水；事实证明，他们是对的。
光秃秃地让 Codex「做个设置页面」基本不靠谱。
但如果你让它「参考你刚才看到的那个页面的架构和模式，做个设置页面」，效果就好太多了。
人类做结构性的决策并定下硬性规矩；Codex 负责在这个框架里填充大量的代码。
「」
「先规划，再编码」
为了最大化 Codex 的潜力，团队下一步是搞清楚------怎么让 Codex 长时间在无人监督的状态下干活。
为此，4 人团队改了工作流。
对于任何稍微复杂点的改动，先让 Codex 帮理清系统和代码是怎么运作的。
比如，让它读一组相关文件，总结这个功能是怎么跑的；比如数据怎么从 API 流经 Repository 层、ViewModel，最后到 UI，然后人工纠正或细化它的理解。
这就像带一个能力很强的新队友一样，团队会跟 Codex 一起制定一个扎实的实施计划。
这个计划通常像一份微型设计文档，指明哪些文件要改，要引入什么新状态，逻辑该怎么走。
只有到了这一步，团队才让 Codex 开始执行计划，一步步来。
此处，有个非常实用的小技巧：
对于那种超长任务，当上下文窗口快爆了的时候，他们会让 Codex 把计划保存到一个文件里，这样就能在不同的会话里延续同样的指导思路。
这个额外的规划循环证明，磨刀不误砍柴工。
团队可以放心地让 Codex 长时间「无人监督」地跑，这也让 Code Review 变得更容易，因为可以对照计划来检查实现，而不是一脸懵逼地看 Diff。
而且万一出问题了，可以先调试计划，再调试代码。
「」
「多 AI 并行， 分布式工程」
在项目最忙的时候，OpenAI 团队经常并行跑着好几个 Codex 会话。
一个在做播放功能，另一个在做搜索，另一个在处理错误，有时候还有一个在写测试或重构。
这感觉不像是用工具，更像是「管团队」。每个会话都会定期汇报进度。
一个可能会说，「我已经规划好这个模块了；这是我的建议」，而另一个会为一个新功能甩出一个巨大的 Diff。
每一个都需要关注、反馈和 Review。
这跟做一个带着好几个新人的 Tech Lead 简直一模一样，大家都在推进，大家都需要指导。
结果就是形成了一种协作流。Codex 这种暴力的编码能力，把团队从大量的手工打字中解放出来了。
因此，他们有更多的时间思考架构，仔细读 PR，测试 App。
Codex 不会有上下文切换的瓶颈，但开发者有。开发工作流，从写代码变成了做决定、给反馈和集成变更。
这就是「布鲁克斯的定律」以一种新方式应验的地方。
你不能简单地增加 Codex 会话就指望速度线性提升，就像你不能往项目里无限加人一样。
每一双额外的「手」，哪怕是虚拟的，都会增加协调成本。
「Codex：跨平台超能力」
OpenAI 这一项目起步时有一个巨大的先发优势：Sora 已经在 iOS 上发布了。
他们经常把 Codex 指向 iOS 和后端代码库，帮它理解关键需求和约束。
在整个项目过程中，OpenAI 开玩笑说「重新发明了跨平台框架，忘掉 React Native 或 Flutter，跨平台的未来就是 Codex」。
这句玩笑背后有两个原则：
「1. 逻辑是可移植的」
无论代码是用 Swift 还是 Kotlin 写的，底层的应用逻辑------数据模型、网络调用、验证规则、业务逻辑------都是一样的。Codex 非常擅长读取 Swift 实现并生成语义一致的 Kotlin 代码。
「2. 具体示例提供强大的上下文」
一个全新的 Codex 会话，如果能看到「这就是它在 iOS 上究竟是怎么跑的」以及「这是 Android 的架构」，那效率远比光听自然语言描述要高得多。
基于这些原则，团队把 iOS、后端和 Android 仓库都放到了同一个环境中。
给 Codex 一个这样的 Prompt：
阅读 iOS 代码里的这些模型和端点，然后出一个计划，用现有的 API Client 和模型类在 Android 上实现同样的行为。
此处，也有一个实用的小技巧：
在~/.codex/AGENTS.md 里详细写明本地仓库在哪儿以及里面有啥。这能让 Codex 更容易地找到和跳转到相关代码。
更广泛的经验是，对于 Codex 来说，上下文就是一切。
当 Codex 理解了功能在 iOS 里是怎么跑的，再结合对 Android App 结构的理解，就能获得非常好的结果。
「一场复盘 ，开发者「超能力」觉醒」
28 天冲刺结束时，用 Codex 已成为 OpenAI 默认的开发闭环------理解代码、规划变更、实现功能、Review 输出。
显然，AI 辅助开发并没有降低工程的严谨性，反而提升了它。
Codex 团队设计师 Ed Bayes 描述了，这个工具如何改变了自己的工作流。
如今，Codex 已与项目管理工具 Linear、以及通讯平台 Slack 打通，团队成员可以直接把编程任务派给 AI 智能体。
他表示，「你可以把 Codex 拉进来，基本上可以直接给 Codex 指派 issue。Codex 简直就是你工作区里的一个队友」。
这种集成意味着，当有人在 Slack 里发反馈时，可以直接 @Codex 让它修 bug；它还会提一个 PR，团队成员可以在同一个帖子里审查代码并进行迭代。
「它基本上就是在模拟这种同事关系，不管你在哪工作它都在」。
尽管 Codex 能力很强，但它的目标是立刻从 A 到 B。这就是为什么离了人，AI 辅助编程就玩不转。
明日软件工程师的「超能力」，将是深刻的系统理解能力，以及在长时间跨度上与 AI 协作的能力。
现在，Codex 让开发者能专注于软件工程最有意义的部分，回归他们热爱这门手艺的初心。
一旦 Codex 在一个上下文丰富的环境中配置好，懂你的目标和你喜欢的构建方式，任何团队都能让战斗力翻倍。
这一次，OpenAI 的发布复盘不是一个万能药方，也不敢说已经彻底搞懂了 AI 辅助开发。
但他们希望，能以自己的经验启发更多的开发者，让 Codex 更好地为人们所用。
参考资料：