摘要
OpenAI的一个4人工程团队在28天内成功构建并发布了安卓版Sora应用，其中约85%的代码由AI智能体Codex完成。该项目消耗了约50亿Token，实现了99.9%的无崩溃率，并在上线24小时内由安卓用户生成了超100万条视频。这一案例展示了AI在软件开发中的颠覆性潜力，通过小型精英团队与AI协作，能够以极高的效率和质量交付复杂产品，改变了传统的软件工程模式。
线索
此次事件揭示了AI辅助开发领域的重大机遇与潜在风险。机遇在于：1）生产力革命，AI编码工具可大幅缩短开发周期、降低人力成本，使企业能更快响应市场；2）新商业模式，如Codex这类AI智能体正从工具演变为“数字队友”，与项目管理软件深度集成，催生平台化服务；3）竞争壁垒重构，掌握AI原生开发流程的企业将获得显著的速度和创新优势。风险在于：1）过度依赖可能导致开发者核心技能退化，面对AI无法解决的深层架构问题时束手无策；2）代码同质化，广泛使用相同AI模型可能扼杀技术方案的多样性；3）安全与质量控制的“黑箱”问题，AI生成的复杂代码可能隐藏难以察觉的漏洞，对长期维护构成挑战。
正文
项目概述
10月初，OpenAI发布了迭代后的Sora 2及首个AI视频应用Sora APP。11月，安卓版Sora上线后登上了谷歌Play Store榜首。时隔两个月，OpenAI团队披露了这款应用（首个安卓版）的构建细节。该应用由一个4人工程团队在28天内完成，从10月8日到11月5日。项目背后最大的功臣是AI智能体Codex，它完成了约85%的编码工作，消耗了约50亿Token。尽管应用规模较大，但实现了99.9%的无崩溃率。团队使用的是GPT-5.1-Codex模型的早期版本，该模型在发布仅5个月时，已承担了OpenAI内部每周70%的PR（Pull Request）任务。
团队策略与布鲁克斯定律
当Sora在iOS上发布时，用户量激增，而安卓版当时只有一个简陋的内部原型，但Google Play上的预注册用户却在持续增长。面对高压的发布任务，传统做法是增加人手和流程。然而，美国计算机架构师Fred Brooks提出的“布鲁克斯定律”指出，向一个延期的软件项目增加人手，只会让它延期得更厉害，因为这会增加沟通成本和集成难度。为此，OpenAI组建了一支4名工程师的精锐小队，全员配备Codex，以提升个人战斗力。团队在18天内发布了内部构建版本，10天后正式向公众发布。
AI的自我迭代
在OpenAI内部，绝大部分工程师都在使用Codex。Codex产品负责人Alexander Embiricos透露，Codex会监控自己的训练过程并处理用户反馈，以“决定”下一步的行动。OpenAI正在尝试让Codex编写大量用于自身训练的研究测试框架，并监控自己的训练过程。这种“AI迭代AI”的模式形成了一个递归循环，类似于历史上电子设计自动化（EDA）软件的发展路径：第一代工具创造的能力，会反哺到下一代工具中。这个系统能自主运行进程、处理反馈、管理子进程，并生成最终产品代码。员工通过Linear、Slack等工具向Codex分配任务，视其为“队友”。
Codex的角色定位：高级工程师
为了理解工程师与Codex的协作方式，可以将Codex定位为一个“刚入职的高级工程师”。这意味着工程师的角色从亲手编写代码，转变为指挥和审查代码。这种模式被称为“氛围流工程”，即人类仍然保持在决策循环中，与AI共同制定计划、讨论并迭代。开发者会先让Codex制定计划，然后一起讨论，确保开发者与模型保持在同一个循环中，并能仔细审查代码。
Codex的能力边界
Codex目前存在一些局限性。它不擅长推断未知信息，如个人偏好的架构模式、产品策略、真实用户行为或内部潜规则。它也无法感知应用的实际运行体验，例如界面滚动是否流畅或交互流程是否别扭。这些体验层面的工作仍需由人工完成。每个Codex实例都需要“入职培训”，即提供充分的上下文、明确的目标、约束条件和规则。在深层架构判断上，Codex可能会偏离最优解，例如创建多余的ViewModel或将逻辑放在错误的层级。它的本能是让功能跑通，而非优先考虑代码的长期整洁度。为了解决这个问题，OpenAI团队在代码库中放置了大量AGENT.md文件，用于在不同会话中复用指导和最佳实践。
Codex的优势则体现在多个方面：
1. 理解大型代码库：精通主流编程语言，能轻松在不同平台间复用概念。
2. 测试覆盖率：热衷于编写单元测试，能覆盖各种边缘情况，有效防止Bug回归。
3. 响应反馈：当CI（持续集成）失败时，可以直接将日志粘贴给它，以获得修复方案。
4. 大规模并行：开发者可以并行运行多个会话测试不同想法，将代码视为可随意丢弃的消耗品。
5. 提供新视角：在设计讨论中，可作为生成式工具挖掘潜在故障点或发现新的解决方案。
6. 解放人力：团队将更多时间用于代码审查、架构设计和用户体验优化，Codex本身也具备代码审查能力。
人机协作的核心：规划与地基
为了用好Codex并确保代码的稳健性和可维护性，开发者需要亲自把控系统的设计和关键权衡，包括应用架构、模块化、依赖注入和导航等。对于一个85%代码由AI完成的项目，一个精心规划的基础架构避免了昂贵的返工。团队认为，手动构建地基是“最正确的决定之一”。核心思路是构建一个“懂规矩的东西”，而非仅仅是一个“能跑的东西”。开发者不需要告诉Codex每一步怎么做，但需要向它展示什么是“正确”的。团队曾尝试直接让Codex参照iOS代码构建安卓应用，但结果因产品体验不达标而失败。正确的做法是，人类做出结构性决策并设定规则，Codex负责在此框架内填充大量代码。
工作流程的变革
为了最大化Codex的潜力，团队改变了工作流程。对于任何复杂改动，首先让Codex帮助理清系统和代码的运作方式，例如阅读相关文件并总结功能流程，然后由人工纠正或细化其理解。接着，团队与Codex共同制定一份类似微型设计文档的实施计划，指明需要修改的文件、引入的新状态和逻辑走向。只有在这一步完成后，才让Codex开始执行计划。对于超长任务，当上下文窗口即将溢出时，团队会让Codex将计划保存到文件中，以便在不同会话中延续指导。这种“先规划，再编码”的流程让代码审查变得更容易，因为可以对照计划检查实现。
在项目高峰期，团队会并行运行多个Codex会话，分别处理播放、搜索、错误处理或测试等不同任务。每个会话都需要关注、反馈和审查，这种模式类似于管理一个由多名新人组成的团队。开发者的工作流从编写代码转变为做决策、给反馈和集成变更。这也印证了布鲁克斯定律的新形式：不能简单地增加Codex会话就期望速度线性提升，因为每一双额外的“手”都会增加协调成本。
跨平台开发能力
该项目的一个优势是Sora已在iOS上发布。团队经常将Codex指向iOS和后端代码库，以帮助其理解关键需求和约束。团队开玩笑说，他们“重新发明了跨平台框架，跨平台的未来就是Codex”。这基于两个原则：1）逻辑是可移植的，无论用Swift还是Kotlin编写，底层的应用逻辑都是相同的，Codex擅长读取一种语言的实现并生成语义一致的另一种语言的代码；2）具体示例提供强大的上下文，让Codex看到iOS代码的实际运行方式，远比纯语言描述更高效。团队将iOS、后端和Android仓库放在同一环境中，通过提供丰富的上下文，获得了非常好的开发效果。
结论与未来展望
28天的冲刺结束后，使用Codex已成为OpenAI默认的开发闭环：理解代码、规划变更、实现功能、审查输出。AI辅助开发并未降低工程的严谨性，反而提升了它。Codex已与项目管理工具Linear和通讯平台Slack打通，团队成员可以直接在Slack中@Codex指派任务或修复Bug，Codex会提交PR，团队成员可在同一帖子里审查和迭代代码，模拟了同事间的协作关系。尽管Codex能力很强，但其目标是快速完成任务，因此离不开人类的指导。未来软件工程师的“超能力”将是深刻的系统理解能力和与AI长期协作的能力。Codex让开发者能专注于软件工程中最有意义的部分。OpenAI希望以自身经验启发更多开发者，更好地利用AI工具。
发布时间
2025-12-15T14:39:54+00:00
评论 ( 0 )