由 2026 年 4 月 26 日起，Sora 產品已停止提供。
在 11 月，我們在全球推出了 Sora Android 應用程式，讓任何使用 Android 裝置的用戶都能將短提示詞轉換成生動的影片。在發佈當天，應用程式在 Play 商店中排名第一位。Android 用戶在首 24 小時內生成了超過 100 萬部影片。
這次推出背後有一段故事：Sora 生產環境 Android 應用程式的初始版本，是在 28 天內由 Codex 建立而成。這正是任何團隊或開發人員都可以使用的同一個智能代理。
由 2025 年 10 月 8 日至 11 月 5 日，一支精簡工程團隊與 Codex 協作，消耗約 50 億個 token，將 Sora Android 版由原型推進至全球推出。儘管規模龐大，該應用程式仍達到 99.9% 的無崩潰率，並具備令我們引以為傲的架構。如果你想知道我們是否使用了秘密模型，答案是我們使用了 GPT‑5.1‑Codex 模型的早期版本，也就是任何開發人員或企業今天都可透過 CLI、IDE 擴充功能或網頁應用程式使用的同一版本。
Prompt: figure skater performs a triple axle with a cat on her head
Sora 在 iOS 推出後，使用量迅速飆升。用戶隨即開始源源不絕地生成影片。相較之下，Android 方面當時只有一個小型內部原型，以及 Google Play 上越來越多的預先登記用戶。
面對高風險、時間緊迫的產品推出，常見做法是投入更多資源並增加流程。這種規模和質素的生產環境應用程式，通常需要多名工程師花數月時間開發，並因協調工作而放慢進度。
美國電腦架構師 Fred Brooks 曾有一句著名警示：「為已經延誤的軟件項目增加人手，只會令項目更加延誤。」換言之，當團隊試圖快速推出複雜項目時，加入更多工程師往往會增加溝通成本、令任務更分散，並提高整合成本，反而拖慢效率。我們沒有忽視這項分析見解，而是順勢而行，組成一支由四名工程師構成的強大團隊，並讓每位工程師都配備 Codex，大幅提升個人影響力。
透過這種工作方式，我們在 18 日內向員工推出 Sora Android 版的內部構建版本，並在 10 日後公開推出。我們在 Android 工程實踐上維持高標準，投入於可維護性，並要求應用程式達到與較傳統項目相同的可靠性標準。（時至今日，我們仍然廣泛使用 Codex 持續改進應用程式並加入新功能。）
要理解我們如何與 Codex 協作，首先要知道它在哪些方面最擅長，以及哪些地方需要指引。把它視為新加入的資深工程師，是一個有效做法。Codex 的能力讓我們可以把更多時間用於指導和審查程式碼，而不是親自編寫。
Codex 需要指引之處
- Codex 目前仍不擅長推斷未曾明確提供的資訊（例如你偏好的架構模式、產品策略、真實用戶行為，以及內部規範或慣用做法）。
- 同樣地，Codex 亦無法實際看到應用程式運行：不能在裝置上開啟 Sora、察覺捲動手感是否不順，或判斷某個流程是否令人困惑。這些體驗層面的工作，仍需由我們團隊負責。
- 每個實例都需要完成入門引導。提供清晰目標、限制條件，以及關於「我們做事方式」的指引，對於讓 Codex 有效執行任務至關重要。
- 同樣地，Codex 在深層架構判斷方面亦較吃力：如果完全由它自行處理，它可能會新增一個額外的視圖模型，而我們其實希望擴展現有的視圖模型；又或者把明顯應放在程式碼庫的邏輯推到 UI 層。Codex 的本能是先讓功能可運作，而不是優先考慮長遠的整潔度。
我們發現，讓 Codex 在整個程式碼庫中建立並維護較多的 AGENTS.md 檔案十分有用。這樣可以輕鬆在不同工作階段套用相同指引和最佳實踐。例如，為了確保 Codex 按照我們的風格指引編寫程式碼，我們在頂層的 AGENTS.md 中加入以下內容：
Codex 的優勝之處
- 快速閱讀並理解大型程式碼庫：Codex 基本上掌握所有主要編程語言，因此更容易在多個平台上運用相同概念，而毋須建立複雜抽象層。
- 測試覆蓋率：Codex 特別熱衷於編寫單元測試，會涵蓋各種不同情況。並非每項測試都很深入，但廣泛的覆蓋範圍有助防止迴歸問題。
- 套用意見：同樣地，Codex 亦擅長回應意見。當 CI 失敗時，我們可以將記錄輸出貼到提示詞中，請 Codex 提出修正方案。
- 大規模並行且可棄用的執行：大多數人未必會真正測試同一時間可運行的工作階段數量上限。實際上，可以同時並行測試多個構想，並將程式碼視為可隨時棄用。
- 提供全新視角：在設計討論中，我們把 Codex 當作生成工具，用來探索潛在失效點，並發掘新的解決方法。例如，在設計影片播放器的記憶體優化時，Codex 會瀏覽多個 SDK，提出我們未必有時間逐一分析的方案。這些研究所得的分析見解，對於在最終應用程式中減低記憶體佔用極為重要。
- 促進更高槓桿的工作：在實際操作中，我們花在審查和指導程式碼的時間，往往多於親自編寫。不過，Codex 在程式碼審查方面亦表現出色，經常能在合併前發現錯誤，提升整體可靠性。
當我們理解這些特性後，工作模式便變得更清晰。我們讓 Codex 在清楚定義的模式和範圍內承擔大量核心工作，而團隊則專注於架構、用戶體驗、系統層面的變更，以及最終品質把關。
即使是再優秀的新資深工程師，也不會一開始就具備作出長遠取捨的最佳視角。為了善用 Codex 並確保其產出穩健且具可維護性，我們必須親自負責應用程式的系統設計及關鍵取捨，包括整體架構、模組化、依賴注入及導覽設計；同時亦實作了身份驗證及基礎網絡流程。
在這個基礎之上，我們先完整實作了數個具代表性的功能。我們按希望整個程式碼庫遵循的規則編寫，並在過程中記錄全局模式。透過讓 Codex 參考這些範例功能，它便能在我們的標準下更獨立地工作。對於一個我們估計有 85% 程式碼由 Codex 撰寫的項目而言，精心規劃的基礎可避免日後高成本的回溯與重構，這是我們作出的其中一項最重要決定。
我們的目標不是盡快做出「能運作的東西」，而是建立「理解我們如何運作的東西」。編寫程式碼的方法有很多種「正確答案」。我們毋須逐一告訴 Codex 該怎樣做，而是要讓它理解在我們團隊中何謂「正確」。當起點和建構方式確立後，Codex 便可以開始發揮。
我們亦曾嘗試直接下指令：「根據 iOS 程式碼建立 Sora Android 應用程式。開始吧。」但很快便放棄這條路。雖然 Codex 生成的內容技術上可運作，但產品體驗未如理想；而且在缺乏對端點、資料及用戶流程的清晰理解下，這種單次生成的大量程式碼亦不可靠（即使不使用智能代理，一次合併數千行程式碼本身亦具風險）。
我們推測 Codex 在有良好範例的「沙盒」環境中表現會更佳，而事實亦證明如此。單純要求它「建立這個設定頁面」而缺乏上下文，結果並不可靠；但若要求它「按照剛才看到的頁面所採用的架構和模式建立這個設定頁面」，效果則大為提升。人類負責結構決策並設定不變條件，Codex 則在這些結構內填充大量程式碼。
我們的下一步是充分發揮 Codex 的潛力，研究如何讓 Codex 在無人監督下長時間工作，最近更可持續超過 24 小時。
在初期使用 Codex 時，我們經常直接下指令：「這是功能、這些是檔案，請建立。」此方法間中有效，但多數只會產生可編譯卻偏離架構與目標的程式碼。
因此，我們調整了工作流程。對於任何非簡單變更，我們會先讓 Codex 協助理解系統及程式碼。例如要求它閱讀相關檔案，並總結功能如何運作，例如資料如何由 API 經程式碼層、視圖模型，再流向 UI。之後我們會修正或補充其理解（例如指出某個抽象其實應屬另一層，或某個類別只用於離線模式，不應延伸）。
就如與一位能力強的新同事合作，我們會與 Codex 一同制定穩健的實作計劃。該計劃通常類似精簡設計文件，指明哪些檔案需修改、需新增哪些狀態，以及邏輯如何流動。直至此時，我們才讓 Codex 開始逐步執行。一個實用技巧是：對於非常長的任務（接近上下文限制），可要求 Codex 將計劃寫入檔案，以便在不同實例中沿用同一方向。
這個額外的規劃步驟非常值得。它讓我們能在長時間內讓 Codex「無人監督」地運作，因為我們已掌握其計劃；亦讓程式碼審查更容易，因為可對照計劃檢視實作，而非單看差異；當出現問題時，亦可先檢查計劃，再檢查程式碼。
這種互動方式，與良好設計文件帶給技術負責人的信心非常相似。我們不只是生成程式碼，而是在建立一套支援共同路線圖的程式碼。
在項目高峰期，我們經常同時運行多個 Codex 工作階段：一個處理播放功能、一個處理搜尋、一個處理錯誤處理，有時還有其他負責測試或重構。這種感覺更像是在管理一個團隊，而非單純使用工具。
每個工作階段會定期回報進度。有的會說「我已完成此模組的規劃，這是建議」，有的則提交大型變更差異。每一項都需要關注、意見反饋與審查，此情況技術主管帶領多位新工程師非常相似，大家取得進展的同時亦需要指導。
最終形成的是一種協作式流程。Codex 的程式碼生成能力讓我們免去大量手動輸入，使我們有更多時間思考架構、仔細審閱 PR，以及測試應用程式。
同時，這種速度亦意味著審查佇列總是滿載。Codex 不會受上下文切換影響，但我們會。開發瓶頸由編寫程式碼，轉移至決策、回饋及整合。
這正是 Brooks 定律在新情境下的體現：增加 Codex 工作階段，並不會帶來線性提速，就如增加工程師人手亦不會線性縮短時程。每增加一個「虛擬人手」，都會增加協調成本。我們的角色由個人貢獻者，轉為像指揮家般協調整體。
我們的項目有一個重要優勢：Sora 已在 iOS 推出。我們經常讓 Codex 參考 iOS 及後端程式碼，以理解關鍵需求及限制。我們甚至半開玩笑地說，這像是重新發明跨平台框架別再提 React Native 或 Flutter；未來的跨平台，就是 Codex。
背後有兩個原則：
- 邏輯是可移植的。無論使用 Swift 還是 Kotlin，應用程式的核心邏輯（資料模型、網絡請求、驗證規則、業務邏輯）都是一致的。Codex 很擅長將 Swift 實作轉換為語意一致的 Kotlin。
- 具體範例提供強大上下文。能同時看到「iOS 如何實作」及「Android 架構」的全新 Codex 工作階段，遠比單單依賴自然語言描述的工作階段更為有效。
我們將 iOS、後端及 Android 程式碼庫置於同一環境，並給 Codex 如下指令：
「閱讀 iOS 中的模型及端點，並提出在 Android 中使用現有 API 客戶端及模型類別實現相同行為的計劃。」
一個實用技巧是，在 ~/.codex/AGENTS.md 中說明本地程式碼庫的位置及內容，方便 Codex 發掘和導覽相關程式碼。
我們其實是在透過「轉譯」而非「共享抽象」來進行跨平台開發。由於 Codex 負責大部分轉譯工作，我們避免了重複實作的成本。
更重要的教訓是：對 Codex 而言，上下文至關重要。當它同時理解功能在 iOS 中的實際運作，以及 Android 應用程式的架構時，表現最佳；缺乏上下文時，它並非不合作，而是在猜測。越把它當作新同事，並投入提供正確輸入，其表現便越好。
在四週衝刺結束時，使用 Codex 已不再像實驗，而成為我們的預設開發流程。我們用它理解程式碼、規劃變更及實作功能，並以審查同事的方式審查其輸出，這正是我們發佈軟件的方式。
我們亦清楚看到：AI 輔助開發並不減少對嚴謹性的要求，反而更高。Codex 的目標是快速由 A 到 B，這就是為甚麼 AI 協助的編碼在無人監督的情況下無法運作。軟件工程師能夠理解和應用系統的現實世界限制、最佳的軟件架構方法，以及如何在考慮未來開發和產品計劃的情況下進行構建。未來工程師的超能力，將是深厚的系統理解能力，以及與 AI 長期協作的能力。
軟件工程最有趣的部分，是打造吸引人的產品、設計可擴展系統、撰寫複雜演算法，以及探索資料與模式。然而，現實往往是較為繁瑣的工作，例如對齊按鈕、連接端點及撰寫樣板程式碼。現在，Codex 讓我們能專注於真正重要、也是我們熱愛的部分。
當 Codex 在一個具備豐富上下文的環境中運作，理解你的目標及建構方式後，任何團隊都可以放大自身能力。我們的發佈經驗並非公式，我們亦不會宣稱已經解決了 AI 協助開發的問題。但我們希望我們的經驗能讓你更容易找到最佳方法，令 Codex 更為強大，從而令你更強大。
當 Codex 在七個月前以研究預覽推出時，軟件工程仍大不相同。透過 Sora，我們得以探索工程的下一個階段。隨著模型與框架持續進步，AI 將成為建構過程中不可或缺的一部分。
你會如何運用屬於你自己的 Codex 團隊？
