构建Sora竟然只要四名工程师？
近日，OpenAI发布了一篇名为《如何在28天内用Codex构建Android版Sora》的播客，讲述了一个四人工程师团队与OpenAI的编程智能体Codex，从今年的10月8日到11月5日，花费28天时间，消耗约50亿个Token，将安卓版Sora从原型阶段推向全球发布，其中85%的代码由Codex编写。
同时，OpenAI表示，至今也仍在广泛使用Codex来演进应用并增加Sora的新功能。
OpenAI截图
OpenAI称，当Sora在iOS平台发布时，使用量激增。相比之下，在安卓平台只有一个小型的内部原型，而预注册用户数量却在不断攀升。面对高风险、时间紧迫的发布，公司组建了一个由四名工程师组成的团队——所有人都配备了Codex。
以这种方式工作，团队在18天内向内部员工发布了安卓版Sora的内部构建版本，并在10天后公开发布。
OpenAI表示，将Codex视为一位新聘用的高级工程师是个好方法，工程师可以花更多时间指导和审查代码，而不是亲自编写。比如，Codex不太擅长推断它尚未被告知的事情（偏好的架构模式、产品策略、真实的用户行为，以及内部规范或快捷方式等），Codex也无法看到应用实际运行（无法在设备上打开Sora，注意到滚动感觉卡顿，或感知到某个流程令人困惑），这些体验性任务只有工程师团队才能处理。同样，Codex在深层次的架构判断上也存在困难，“它的本能是让某样东西运行起来，而不是优先考虑长期的整洁性”。
对于Codex这名新工程师，OpenAI的要求是，每个“实例”都需要“入职”，用清晰的目标、约束条件和关于“如何做事”的指导来共享上下文，使得Codex能够良好地去执行。
相较于工程师，Codex更擅长快速阅读和理解大型代码库，热衷于编写单元测试以覆盖广泛多样的场景，擅于对反馈做出反应，还擅于大规模并行、可丢弃的执行，提供新的视角，实现更高杠杆率的工作。
团队的工作模式也因此变为：Codex在已有明确模式和严格限定范围内完成大量繁重工作，工程师则专注于架构、用户体验、系统性变更和最终质量。
OpenAI表示：“我们的目标不是尽快做出‘能工作的东西’，而是做出‘理解我们期望如何工作的东西’。编写代码有很多‘正确’的方法。我们不需要告诉Codex具体做什么；我们需要向Codex展示在我们团队中什么才是‘正确’的。一旦我们确立了起点和构建偏好，Codex就准备好开始了。”
团队坦言，确实尝试过提示：“根据iOS代码构建Sora安卓应用。开始吧。” 但团队很快放弃了这条路。虽然Codex生成的东西在技术上可行，但产品体验不佳。而且，在没有清晰理解端点、数据和用户流程的情况下，Codex一次性生成的代码是不可靠的（即使不使用智能体，合并数千行代码也是有风险的）。
此后，团队又继续让Codex帮助理解系统和代码的工作原理，让Codex可以长时间根据计划“无人监督”运行。在项目高峰期，团队也会并行运行多个Codex会话，一个处理播放功能，另一个处理搜索，还有一个处理错误处理，有时还会有一个处理测试或重构。
该团队表示，对Codex来说，上下文就是一切。当Codex理解了功能在iOS上如何工作，并结合了对安卓应用结构如何的理解时，它的表现最好。当Codex缺乏这种上下文时，它并非“拒绝合作”，而是在猜测。越是将其视为新队友，并投入精力为其提供正确的输入，它的表现就越好。“在我们为期四周的冲刺结束时，使用Codex不再感觉像是一项实验，而成为我们的默认开发流程。我们用它来理解现有代码、规划变更和实现功能。我们审查其输出的方式与审查队友代码的方式相同。这就是我们交付软件的方式”。
团队指出，“很明显，AI辅助开发并不会降低对严谨性的需求，反而增加了需求。尽管Codex能力强大，但它的目标是从A点到B点，而且要快。这就是为什么没有人类，AI辅助编码就无法工作。软件工程师能够理解并应用系统的现实约束、架构软件的最佳方法，以及如何结合未来的开发和产品计划进行构建。未来软件工程师的超能力将是对系统的深刻理解，以及能够与AI在长时间跨度上协作的能力”。
