自 2026 年 4 月 26 日起，Sora 產品已停止提供。
在 11 月，我們向全球推出了 Sora Android 應用程式，讓任何擁有 Android 裝置的人都能將簡短的提示轉換成生動的影片。推出當天，此應用程式便在 Play 商店登上第一名。Android 使用者在第一個 24 小時內就產生了超過 100 萬支影片。
這次推出的背後有一個故事：Sora 的生產 Android 應用程式初始版本是在 28 天內建立完成的，這歸功於任何團隊或開發人員都能夠使用相同的代理程式：Codex。
2025 年 10 月 8 日到 11 月 5 日，一個精簡的工程團隊與 Codex 合作，消耗了約 50 億個 Token，將 Android 版的 Sora 從原型推向全球發佈。儘管規模龐大，該應用程式的無崩潰率達到 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 上預先註冊的使用者數量卻在不斷增加。
在高風險、時間緊迫的情況下，常見的反應是投入更多資源和增加流程。如此規模和品質的生產應用程式通常需要許多工程師耗時數月，，而協調工作會導致開發進度變緩。
美國電腦架構師弗雷德布魯克斯曾發出著名的警告：「在已經落後的軟體專案中增加更多人手，只會讓專案拖得更久。」換句話說，當嘗試快速完成一個複雜的專案時，增加工程師的數量往往會因為溝通負擔增加、任務分散和整合成本，而降低效率。我們沒有忽視這項見解，而是採納它；我們組建了一個由四名工程師組成的強大團隊，每一位都配備了 Codex，以大幅提升所有工程師的影響力。
以這種方式工作，我們在 18 天內便向員工發佈 Android 版 Sora 的內部組建，並在 10 天後公開發佈。我們在 Android 工程實踐上保持高標準，注重可維護性，並要求應用程式達到與我們對傳統專案所期望的相同可靠性標準。(我們今天也繼續廣泛使用 Codex 來發展應用程式並導入新功能。)
若要理解我們如何與 Codex 合作，了解其擅長的領域以及需要指導的地方會很有幫助。將其視為新聘的資深工程師是一個不錯的方法。Codex 的能力意味著我們可以花更多時間指導和審查程式碼，而不是親自編寫程式碼。
Codex 需要指導的地方
- Codex 還不擅長推斷未被告知的內容 (例如，你偏好的架構模式、產品策略、真實使用者行為，以及內部規範或捷徑）。
- 同樣地，Codex 也無法看到應用程式實際運作：它無法在裝置上開啟 Sora，無法注意到捲動有異樣，也無法感覺到流程令人困惑。只有我們團隊才能完成這些實踐性任務。
- 每個單位都需要進行培訓。分享具有明確目標、限制條件和「我們如何做事」指導的背景資訊，對於讓 Codex 良好執行至關重要。
- 同樣地，Codex 在深層架構判斷上也遇到困難：如果放任其自行決定，則可能會在我們真正想要擴展現有模型的地方引入一個額外的檢視模型，或者將明顯屬於儲存庫的邏輯推到 UI 層。其本能是讓事情運作，而不是優先考慮長期的整潔度。
我們發現讓 Codex 在程式碼庫中建立和維護大量的 AGENT.md 檔案是很有用的。這讓你能輕鬆地在不同工作階段之間應用相同的指導和最佳做法。例如，為了確保 Codex 撰寫的程式碼符合我們的風格指南，我們在最上層的 AGENT.md 中新增了以下內容：
Codex 的卓越之處
- 快速閱讀和理解大型程式碼庫：Codex 基本上知道所有主要的程式語言，這使得在多個平台之間運用相同的概念變得更容易，無需複雜的抽象化。
- 測試涵範範圍：Codex 對撰寫單元測試以涵蓋各種情況有著獨特的熱情。並非每項測試都很深入，但廣泛的涵蓋範圍有助於防止回歸。
- 應用回饋：同樣地，Codex 在回應回饋方面表現出色。當 CI 失敗時，我們可以將日誌輸出貼到提示中，並要求 Codex 提出修正建議。
- 大規模的並行一次性執行：大多數人不會達到其實際同時執行工作階段數量的限制。並行測試多個想法，並將程式碼視為一次性，是非常可行的。
- 提供新觀點：在設計討論中，我們使用 Codex 作為生成工具來探索潛在的故障點，並發現解決問題的新方法。例如，在我們設計影片播放器記憶體最佳化時，Codex 篩選了多個 SDK，提出我們原本沒有時間分析的方法。Codex 的研究成果對於在最終應用程式中最大限度地減少記憶體佔用量，經證明非常有價值。
- 實現更高槓桿效應工作：實際上，我們花更多時間在審查和指導程式碼上，而不是自己編寫程式碼。話雖如此，Codex 在程式碼審查方面也非常出色，經常能在合併前抓出漏洞，而提升可靠性。
一旦我們認識這些特徵，我們的工作模型就變得更加簡單明瞭。我們依靠 Codex 在已充分理解的模式和界限明確的範圍內完成大量繁重工作，而我們的團隊則專注於架構、使用者體驗、系統性變更以及最終品質。
即使是最優秀的新進資深員工，也無法立即從正確的角度做出長期的權衡取捨。為了充分運用 Codex 並確保其其強大且易於維護，我們親自監督應用程式的系統設計和關鍵的權衡取捨，這至關重要。這些包括塑造應用程式的架構、模組化、依賴注入和瀏覽；我們還實施了身分驗證和基本網路流程。
從這個基礎開始，我們撰寫了一些具有代表性的端到端功能。我們使用了我們希望整個程式碼庫遵循的規則，並在過程中記錄整個專案的模式。透過將 Codex 指向具有代表性的特徵，便能在我們的標準內更加獨立地運作。據估計，Codex 為該專案編寫了 85% 的程式碼，避免了昂貴的回溯和重構。這是我們做出的最重要決定之一。
這個想法不是要盡快做出「能用的東西」，而是要做出「能按照我們想要的方式運作的東西。」有許多「正確」的方法來編寫程式碼。我們不需要告訴 Codex 具體應該怎麼做；我們需要向 Codex 展示在我們團隊中什麼是「正確」的。一旦我們確立了起點和喜歡的建構方式，Codex 就準備好開始了。
為了看看會發生什麼，我們嘗試提示：「根據 iOS 程式碼建構 Sora Android 應用程式。開始吧」，但很快就放棄了這條路。雖然 Codex 建立的項目在技術上是可行的，但產品體驗卻不如預期。在缺乏對端點、資料和使用者流程清晰理解的情況下，Codex 的一次性程式碼是不可靠的 (即使不使用代理程式，合併數千行程式碼也是有風險的)。
我們假設 Codex 在一個有良好編寫範例的沙盒中會表現出色；結果證明我們是對的。在幾乎沒有任何背景的情況下，要求 Codex 「建構這個設定畫面」是不可靠的。要求 Codex「使用與你剛剛看到的另一個畫面相同的架構和模式來建構此設定畫面」，效果要好得多。人類做出結構上的決策，並設定不變量，然後 Codex 在該結構內填入了大量的程式碼。
為了充分發揮 Codex 的潛力，下一步是找出方法，讓 Codex 在無需監督的情況下長時間運作（最近已可持續超過 24 小時）。
在早期使用 Codex 時，我們就開始使用像「這是該功能。這裡有一些檔案。請加以建構」這樣的提示。有時這樣有效，但大多數情況下產生的代碼雖然技術上可以編譯，卻偏離了我們的架構和目標。
所以我們改變了工作流程。對於任何非微不足道的變更，我們首先要求 Codex 協助我們理解系統和程式碼的運作方式。例如，我們會要求它讀取一組相關檔案，並總結該功能的運作方式，例如，資料如何從 API 流經儲存庫層、檢視模型，然後進入 UI。接著我們會修正或微調其理解。(例如，我們會指出某個抽象概念實際上屬於不同的層級，或某個給定的類別僅用於離線模式，不應加以擴展。)
就像你可能會與一位新加入且能力出眾的隊友合作一樣，我們與 Codex 合作建立了一個穩固的執行方案。這個方案通常看起來像是一份微型設計文件，指導哪些檔案需要更改，應引入什麼新狀態，以及邏輯應如何運作。直到那時，我們才要求 Codex 開始一步步地應用方案。一個有用的技巧：對於非常長的任務，當我們達到上下文視窗的限制時，我們會要求 Codex 將其方案儲存到檔案中，讓我們能夠在不同的執行個體中應用相同的指示。
結果證明，這額外的規劃環節是值得的。這使我們能夠讓 Codex 長時間在「無監督」的狀況下執行，因為我們理解其方案。這使程式碼審查更為容易，因為我們可以根據方案檢查實施狀況，而不是在沒有上下文的情況下解讀差異。當出現問題時，我們可以先偵錯方案，再偵錯程式碼。
這種動態感覺就像一份好的設計文件能夠讓技術主管對專案充滿信心。我們不僅僅是在產生程式碼：我們是在產生支援共同路線圖的程式碼。
在專案的高峰期，我們經常會同時執行多個 Codex 工作階段。一個處理播放，另一個處理搜尋，還有一個處理錯誤，有時候還會有一個處理測試或重構。感覺不像是在使用工具，更像是在管理一個團隊。
每個工作階段會定期向我們回報進度。有人可能會說：「我已經完成了這個模組的規劃，以下是我的提案」，而另一個人則會提出一個可大幅改進新功能的提案。每一項都需要關注、回饋和審查。這情況和擔任技術主管帶領幾位新工程師，大家都在進步，都需要指導，簡直如出一轍。
結果是一個協作流程。Codex 的原始編碼能力讓我們不需要大量的手動輸入。我們有更多時間來思考架構，仔細閱讀提取要求，並測試應用程式。
同時，這種額外的速度意味著我們的審核行列中總是有項目在等待審核。Codex 沒有因上下文切換而受阻，但我們卻被卡住了。我們在開發過程中遇到的瓶頸，已經從編寫程式碼轉移到決策、提供回饋和整合變更上。
這是布魯克斯的洞察以全新方式呈現的地方。你不能只是新增 Codex 工作階段，就期望能呈線性加速，就像你不能期望在專案中一直增加工程師後，就能線性縮短進度。每增加「一雙手」，即使是虛擬的，也會增加協調的負擔。我們已經成為樂團的指揮，而不只是速度較快的獨奏者。
我們的專案一開始就有優勢的起點：Sora 已經在 iOS 上發佈了。我們經常將 Codex 指向 iOS 和後端程式碼庫，幫助其理解關鍵需求和限制條件。在整個專案過程中，我們開玩笑說我們重新發明了跨平台架構的概念。忘掉 React Native 或 Flutter；跨平台的未來就是 Codex。
這句俏皮話背後蘊含著兩個原則：
- 邏輯是可攜的。無論程式碼是用 Swift 還是 Kotlin 編寫，底層的應用程式邏輯 (資料模型、網路呼叫、驗證規則、業務邏輯) 都是相同的。Codex 非常擅長解讀 Swift 實作，並在 Kotlin 中產生保留語意的等同實作。
- 具體範例提供強而有力的上下文。一個能夠看到「這就是在 iOS 上的具體運作原理」和「這是 Android 架構」的新 Codex 工作階段，比僅僅依賴自然語言運作的工作階段有效得多。
運用這些原則，我們已讓 iOS、後端和 Android 儲存庫可以在相同的環境中使用。我們給 Codex 的提示如下：
「解讀 iOS 程式碼中的這些模型和端點，然後提出一個方案，使用我們現有的 API 用戶端和模型類別在 Android 上實作等效行為。」
一個小但實用的技巧是在 ~/.codex/AGENTS.md 中詳細記錄本機儲存庫的位置及其內容。這讓 Codex 更容易發現和瀏覽相關的程式碼。
我們實際上是透過翻譯進行跨平台開發，而不是透過共享抽象概念。因為 Codex 處理了大部分的翻譯，讓我們避免實作成本的加倍。
更廣泛的教訓就是，對於 Codex 而言，上下文就是一切。Codex 在理解 iOS 中功能的運作方式，再加上對我們 Android 應用程式結構的理解時，才能發揮最佳水準。當 Codex 缺乏上下文時，並不是「拒絕合作」，而是在猜測。我們越是把其當作新隊友來對待，並投入正確的輸入，其表現越好。
在四週的衝刺結束時，Codex 的使用不再像是一個實驗，而是成為我們的預設開發循環。我們用於理解現有的程式碼、方案變更，並實作功能。我們像審查隊友一樣審查其輸出。這就是我們部署軟體的方式。
很明顯，AI 輔助開發不會減少對嚴謹性的需求，反而是增加。儘管 Codex 的能力很強，但其目標是立即從 A 到 B。這就是為什麼 AI 輔助編碼離不開人類的原因。軟體工程師可以理解並應用現實的系統限制條件、最佳的軟體架構方式，以及如何在考慮未來開發和產品方案的情況下進行建構。未來軟體工程師的超能力將是對系統的深入理解，以及能夠長期與 AI 協作的能力。
軟體工程中最有趣的部分是建構出引人入勝的產品、設計可擴展的系統、撰寫複雜的演算法，以及實驗資料、模式和程式碼。然而，過去和現在的軟體工程現實往往更為平淡無奇：置中按鈕、連接端點以及撰寫樣板程式碼。現在，Codex 讓我們能夠專注於軟體工程中最有意義的部分，以及我們熱愛這門技能的理由。
一旦 Codex 在一個上下文豐富的環境中設置好，並理解你的目標和建構方式時，任何團隊的能力都可以倍增。我們的推出回顧並不是一個放之四海皆準的配方，我們也未聲稱已經解決 AI 輔助開發的問題。但我們希望我們的經驗能讓你更容易找到強化 Codex 來強化你的最佳方法。
七個月前，當 Codex 以研究預覽版推出時，軟體工程與現在截然不同。透過 Sora，我們得以探索工程學的下一個篇章。隨著我們的模型和駕馭能力不斷進步，AI 將成為建設中越來越不可或缺的一部分。
你將會與自己的 Codex 團隊創造些什麼？
