近期，OpenAI发布了一篇工程博客，详细阐述了其工程团队如何利用Codex，在短短28天内，从零开始成功开发并上线了Sora的安卓版本。
这款应用在上线首日便登顶Google Play下载榜，并在24小时内生成了超过100万个视频。值得注意的是，整个开发过程消耗了约50亿tokens，而应用的崩溃率被控制在极低的0.1%水平。
这篇由OpenAI工程师Patrick Hum和RJ Marsan撰写的文章，分享了他们在此次高压、快速开发项目中的核心方法论与实践经验。
背景：高压下的快速响应
当Sora在iOS平台发布并引发用户热潮时，其安卓版本仅有一个内部原型，却已面临Google Play上大量的用户预注册需求。
面对紧迫的发布时间线，常规做法通常是增加人手、强化流程。但团队反其道而行，组建了一个仅4名工程师的精干团队，并为每位成员配备了Codex以大幅提升个人效率。他们引用了计算机科学家Fred Brooks的观点：“给一个已经延期的项目加人，只会让它更晚交付”，因为人员增加会带来更高的沟通与协调成本。
最终，该团队仅用18天完成了内部版本，并在10天后成功全球发布。
将Codex视为资深工程师：明确分工
团队发现，将Codex视为一位新入职的资深工程师进行协作，效果最佳。这要求明确它的优势与局限。
Codex的局限与所需指导
- 缺乏特定上下文：它不了解团队内部的架构偏好、产品策略或具体规范。
- 无法感知用户体验：Codex不能打开应用感受流畅度或交互困惑点，这部分工作必须由人来完成。
- 需要清晰的“入职培训”：每次交互都需要明确目标、约束和团队的工作方式。
- 架构判断力有限：若缺乏引导，它可能倾向于实现功能而非优化长期代码结构，例如在不必要时创建新的ViewModel。
为此，团队在代码库中创建并维护了AGENT.md文件，用于在不同会话间保持指导的一致性。例如，为确保代码风格，他们会明确要求Codex在提交前运行格式化检查。
Codex的卓越优势
- 快速理解大型代码库：精通多种编程语言，便于跨平台概念复用。
- 热衷于编写测试：能广泛覆盖各种场景，有效防止回归。
- 高效响应反馈：可将CI构建失败的日志直接粘贴给它，让其提出修复方案。
- 支持大规模并行探索：可以同时测试多个想法，并将代码视为可丢弃的原型。
- 提供新颖视角：在设计讨论中，可作为生成工具探索潜在方案。例如，在优化视频播放器内存时，它通过查阅多个SDK提出了关键建议。
- 解放工程师：使团队能将更多时间投入于代码审查、架构设计和产品规划等高杠杆工作。
核心策略：先打好地基，再让AI填充
团队认为，最关键的决定之一是先由人类奠定坚实的基础。这包括确定应用架构、模块划分、依赖注入方案、导航逻辑，并实现认证与基础网络层。
在此基础上，他们亲自端到端地手写了几个代表性功能，以此作为高质量范例和模式标准。当Codex在清晰、具体的范例指导下工作时，其产出更加可靠和可维护。
他们尝试过直接命令Codex“基于iOS代码构建安卓应用”，但结果并不理想——虽然能运行，但体验糟糕且代码不可靠。
核心理念： 目标不是尽快做出“能跑的东西”，而是做出“符合我们期望方式的东西”。人类负责结构性决策，Codex则在这个框架内高效填充大量代码。
工作流进化：从即时指令到“规划-执行”
为了让Codex能长时间（甚至超过24小时）无人值守地可靠工作，团队改进了工作流程。
对于任何复杂的任务，他们不再直接要求“构建这个功能”，而是首先引导Codex阅读相关代码并总结系统工作原理，例如梳理数据从API到UI的完整流转路径。在纠正和完善其理解后，双方共同制定一个详细的实施计划。
这个计划类似于小型设计文档，明确需要改动的文件、新引入的状态以及逻辑流程。此后，才让Codex按计划逐步执行。对于超长任务，一个实用技巧是让Codex将计划保存到文件中，以便在不同会话间传递上下文。
这个额外的“规划循环”极大地提升了效率。它让团队可以放心地让Codex自主运行，并使代码审查变得更容易——审查者可以对照计划来检查实现，而非漫无目的地阅读代码差异。当出现问题时，调试顺序变为先调试计划，再调试代码。
管理Codex：像指挥一个团队
在开发高峰期，团队经常同时运行多个Codex会话，分别处理播放、搜索、错误处理等不同模块。这种感觉不像使用工具，更像管理一个团队。每个“虚拟成员”都会定期产出提案或代码变更，需要工程师给予关注、反馈和审查。
这种模式将开发的瓶颈从“编写代码”转移到了“做出决策、提供反馈和集成改动”。这也印证了Brooks定律在AI时代的体现：不能简单地通过增加Codex会话来线性提升速度，每一个额外的“协作者”都会带来协调开销。工程师的角色从“独奏者”转变为乐队的“指挥家”。
跨平台开发新范式：基于翻译而非抽象
团队拥有一个巨大优势：Sora的iOS版本已经上线。他们经常让Codex直接阅读iOS和后端代码，以理解业务逻辑和约束。
他们半开玩笑地提出了一个观点：未来的跨平台开发可能就是Codex。其背后的两个原则是：
- 逻辑是可移植的：业务逻辑（数据模型、网络调用、验证规则）不依赖具体语言。Codex擅长阅读Swift代码并生成语义对等的Kotlin实现。
- 具体示例提供强大上下文：向Codex展示“iOS功能如何工作”和“安卓架构是什么”，远比单纯的自然语言描述更有效。
他们通过提示词引导Codex：“阅读iOS中的这些模型和端点，然后提出一个计划，在安卓上使用现有API客户端实现同等行为。” 这实质上是一种通过智能翻译而非强制共享抽象层的跨平台开发方式，避免了重复实现的成本。
核心教训：对Codex（AI编程助手）而言，上下文就是一切。为它提供丰富的、结构化的上下文，其表现就越接近一位能力强大的合作伙伴。
未来展望：AI成为软件工程不可或缺的部分
在为期四周的冲刺结束后，使用Codex已从实验转变为团队的默认开发流程。审查它的输出与审查人类队友的代码变得没有区别。
这一经历也表明，AI辅助开发并未降低对工程严谨性的要求，反而提高了标准。Codex的目标是“现在”解决问题，而工程师的价值在于理解系统性的真实约束、进行架构权衡，并为未来做规划。
软件工程中那些最具挑战和吸引力的部分——构建引人注目的产品、设计可扩展的系统、实验算法与数据——将变得更加突出。而大量重复、琐碎的编码工作将由AI承担。一旦在上下文丰富的环境中设置得当，任何团队都能借助此类工具显著提升其能力。
随着模型与协作框架的持续演进，AI将成为构建软件过程中越来越不可或缺的一部分。
发表于 前天 04:48
|
查看: 7|
回复: 0
