OpenAI Sora for Android: 使用 Codex 在 28 天內構建

OpenAI 在 28 天內使用四名工程師的精簡團隊和 GPT-5.1-Codex 模型，從原型開發到全球發布，開發了 Sora Android 應用程式的生產版本。這個快速開發週期展示了 AI 輔助工程如何在保持高可靠性的同時大幅提升個人影響力，最終產出具有 99.9% 無崩潰率的應用程式。

AI 驅動的開發工作流程

OpenAI 將 Codex 視為「新聘的資深工程師」，專注於指導和審查程式碼，而非手動編寫。團隊發現，雖然 Codex 在有限範圍內的重負荷工作上表現出色，但對於高階架構決策和使用者體驗，仍需要人類的指導。

Codex 的能力與優勢

  • 快速程式碼基礎分析： Codex 能快速讀取並理解多種程式語言的大型程式碼基礎。
  • 測試覆蓋： 該模型在編寫廣泛的單元測試以防止回歸方面非常有效。
  • 回饋整合： 在提供 CI 失敗日誌時，Codex 能快速提出修復方案。
  • 並行執行： 團隊以平行方式運行多個 Codex 會話，同時處理不同模組（例如播放、搜尋、錯誤處理）。
  • 研究與優化： Codex 被用來篩選 SDK，為影片播放器提出記憶體優化方案，以減少最終應用程式的記憶體佔用。

限制與人類需求

  • 缺乏直覺： Codex 無法推斷未明確說明的偏好、產品策略或內部規範。
  • 經驗差距： 模型無法執行應用程式來感覺使用者流程是否令人困惑，或滾動是否感覺「不對」。
  • 架構判斷： 若單獨留下，Codex 傾向於優先考慮即時功能而非長期整潔，可能會引入不必要的視圖模型或放置錯誤的邏輯。

技術實施策略

為確保應用程式保持可維護性，工程團隊在利用 AI 生成之前專注於建立穩固的基礎。

手動基礎與模式設置

工程師手動實作了系統設計，包括架構、模組化、依賴注入、導航、驗證以及基礎網路流程。接著，他們編寫了幾個具代表性的端到端功能，作為「正確」的範例。此方法確保了 Codex 編寫的程式碼約有 85% 遵循團隊既定標準，從而避免了昂貴的重構。

規劃循環

對於非 trivial 的變更，團隊實施了多步驟規劃工作流程，以讓 Codex 能在無監督的情況下工作更長時間：

  1. 系統理解： Codex 被要求總結功能的運作方式（例如，從 API 到 UI 的資料流）。
  2. 細節調整： 人類修正了模型對抽象與層次的理解。
  3. 實施規劃： Codex 建立了一份微型設計文件，詳細說明檔案變更與狀態引入。
  4. 執行： Codex 按步驟套用該計畫，並將計畫儲存至檔案，以在內容視窗限制下保持一致。

透過 AI 進行跨平台翻譯

OpenAI 利用現有的 Sora iOS 應用程式作為 Android 版本的主要真實來源。團隊沒有使用如 Flutter 或 React Native 這樣的共享抽象框架，而是使用 Codex 將邏輯從 Swift 翻譯為 Kotlin。

  • 邏輯可移植性： 團隊利用應用程式邏輯（資料模型、網路呼叫、驗證規則）在不同平台上保持不變的原則。
  • 情境提示： Codex 被提示讀取 iOS 模型與端點，並使用現有的 API 客戶端與模型類別提出等效的 Android 實作。
  • 跨儲存庫導航： 團隊使用 ~/.codex/AGENTS.md 檔案來協助 Codex 在 iOS、後端與 Android 儲存庫間進行發現與導航。

對軟體工程的影響

該專案將開發瓶頸從編寫程式碼轉移到決策制定、提供回饋與整合變更。OpenAI 得出結論，AI 輔助開發提高了對系統理解與架構的人類嚴謹性需求，因為 AI 的主要目標是快速達到功能目標。軟體工程師的角色正在朝著「指揮家」方向發展，負責管理 AI 代理來處理樣板與瑣碎任務，使人類能專注於可擴展的系統與複雜演算法。

Sources