僅4人28天！OpenAI首曝Sora內(nèi)幕：85%代碼竟由AI完成

新智元報(bào)道

編輯：好困 桃子

【新智元導(dǎo)讀】OpenAI爆款A(yù)PP，只動(dòng)用了四員悍將。他們?cè)诙潭?8天內(nèi)，完成了從0搭建安卓版Sora。這背后，竟是AI完成了85%的編碼。

4人28天手搓Sora APP，約85%代碼竟是AI寫的！

10月初，OpenAI重磅發(fā)布迭代后Sora 2，以及首個(gè)AI視頻應(yīng)用Sora APP。

直到11月，安卓版Sora一經(jīng)上線，就登上了谷歌Play Store榜首。

安卓用戶在24h內(nèi)，生成了超100萬條視頻

時(shí)隔兩個(gè)月，OpenAI團(tuán)隊(duì)揭秘這款爆火應(yīng)用（首個(gè)安卓版），如何構(gòu)建的背后故事。

讓人意外的是，這款A(yù)PP僅在28天內(nèi)完成，背后最大功臣便是AI智能體——Codex。

從10月8日到11月5日，4人工程團(tuán)隊(duì)與Codex協(xié)作，消耗約50億Token，就把Sora Android推向全球。

盡管應(yīng)用規(guī)模雖大，卻實(shí)現(xiàn)了99.9%無崩潰率。

而且，他們還使用的是GPT-5.1-Codex模型的早期版本。

發(fā)布僅5個(gè)月的時(shí)間，Codex已經(jīng)承包了OpenAI內(nèi)部每周70%的PR了。

擁抱 「布魯克斯定律」：保持靈活，唯快不破

當(dāng)Sora在iOS上發(fā)布時(shí)，用戶量直接原地爆炸。

相比之下，安卓當(dāng)時(shí)只有一個(gè)簡(jiǎn)陋的內(nèi)部原型，而在Google Play上預(yù)注冊(cè)的用戶卻在越堆越多。

面對(duì)這種高壓、火燒眉毛的發(fā)布任務(wù)，通常的反應(yīng)就是瘋狂堆人、加流程。

像這種規(guī)模和質(zhì)量的生產(chǎn)級(jí)應(yīng)用，通常得一大幫工程師干好幾個(gè)月，而且還會(huì)被各種協(xié)調(diào)工作拖慢進(jìn)度。

美國計(jì)算機(jī)架構(gòu)師Fred Brooks曾有一句名言，「向一個(gè)已經(jīng)延期的軟件項(xiàng)目增加人手，只會(huì)讓它延得更厲害」。

換句話說，想要快速交付一個(gè)復(fù)雜項(xiàng)目時(shí)，堆人往往增加了溝通成本、任務(wù)碎片化和集成難度，反而會(huì)降低效率。

為此，OpenAI組建了一支只有四名工程師的「精銳小隊(duì)」——全員配備Codex，極大地把每個(gè)人的戰(zhàn)斗力拉滿。

靠著這種打法，在18天內(nèi)就向員工發(fā)布了Sora Android的內(nèi)部構(gòu)建版本，僅僅10天后就向公眾正式發(fā)布。

AI迭代AI，自我進(jìn)化

在OpenAI內(nèi)部，絕大部分工程師都在用Codex，即開源版CLI。

Codex產(chǎn)品負(fù)責(zé)人Alexander Embiricos透露，「它會(huì)監(jiān)控自己的訓(xùn)練過程，并處理用戶反饋，「決定」下一步該做什么。

Codex正在給自己的訓(xùn)練運(yùn)行編寫大量的研究測(cè)試框架（research harness），OpenAI甚至在嘗試讓Codex去監(jiān)控自己的訓(xùn)練過程。

這種「套娃」式的開發(fā)模式，可以讓Codex自我迭代。

這種用工具造更好工具的遞歸循環(huán)，在計(jì)算歷史上其實(shí)由來已久。

1960年代，工程師們?cè)诩埳鲜止ぴO(shè)計(jì)了第一批集成電路，然后根據(jù)圖紙?jiān)斐隽宋锢硇酒?/p>

接著，這些芯片又驅(qū)動(dòng)了運(yùn)行第一批電子設(shè)計(jì)自動(dòng)化（EDA）軟件的電腦，而這些軟件反過來又讓工程師能設(shè)計(jì)出人類手繪根本搞不定的復(fù)雜電路。

現(xiàn)代處理器包含數(shù)十億個(gè)晶體管，這種排列模式之所以能存在，全靠軟件。

OpenAI用Codex來造Codex似乎也是這個(gè)路子：每一代工具創(chuàng)造的能力，都會(huì)反哺到下一代中。

這個(gè)系統(tǒng)能自主運(yùn)行許多進(jìn)程，處理反饋，衍生并管理子進(jìn)程，還能生成最終發(fā)布在實(shí)際產(chǎn)品里的代碼。

OpenAI員工管它叫「隊(duì)友」，并且用諸如Linear、Slack等工具來給它派活兒。

Codex處理的任務(wù)，到底算不算真正的「決策」？

但無可否認(rèn)的是，這里形成了一個(gè)半自主的反饋循環(huán)：

Codex在人類的指導(dǎo)下寫代碼，這些代碼變成了Codex的一部分，結(jié)果就是下一個(gè)版本的Codex會(huì)寫出不一樣的代碼。

一位剛?cè)肼毜摹父呒?jí)工程師」

為了理解工程師是如何跟Codex配合的，需得先知道它哪里強(qiáng)、哪里需要人帶。

把它當(dāng)成一個(gè)「剛?cè)肼毜母呒?jí)工程師」是個(gè)很好的切入點(diǎn)。

這個(gè)定位，意味著工程師可以把更多時(shí)間花在指揮和Review代碼上，而不是自己在那兒敲代碼。

與「氛圍編程」不同的是，讓Codex編碼屬于「Vibe engineering」（氛圍流工程）的領(lǐng)域。

前者是指，開發(fā)者不怎么細(xì)看就直接接受AI生成的代碼，而后者是AI研究員Simon Willison提出的概念，指人類仍保持在循環(huán)中。

一般來說，讓Codex干活/制定計(jì)劃，再一起討論，迭代計(jì)劃，這樣開發(fā)者就和模型保持在一個(gè)「循環(huán)」里，還能仔細(xì)審查代碼。

Codex需要指導(dǎo)的地方

目前，Codex還不擅長(zhǎng)推斷未知的事。

比如，個(gè)人喜歡的架構(gòu)模式、產(chǎn)品策略、真實(shí)用戶行為，以及內(nèi)部的潛規(guī)則或捷徑。

同樣，Codex也看不到App實(shí)際跑起來的樣子：

它沒法在真機(jī)上打開Sora，感覺不到滾動(dòng)條是不是不絲滑，或者察覺到某個(gè)交互流程很別扭。

這些體驗(yàn)層面的活兒，只能靠OpenAI團(tuán)隊(duì)自己來。

每一個(gè)實(shí)例都需要「入職培訓(xùn)」。給出上下文，明確目標(biāo)、約束條件，以及明確的規(guī)矩，對(duì)于讓Codex把活兒干漂亮至關(guān)重要。

還有，Codex在深層架構(gòu)判斷上也容易跑偏：如果放任不管，它可能會(huì)搞出一個(gè)多余的ViewModel，實(shí)際上團(tuán)隊(duì)只想擴(kuò)展現(xiàn)有的那個(gè)；或者把本該屬于Repository層的邏輯硬塞進(jìn)UI層。

它的本能是把功能跑通就行，而不是優(yōu)先考慮長(zhǎng)期的代碼整潔度。

OpenAI發(fā)現(xiàn)，在整個(gè)代碼庫里到處放大量的AGENT.md文件非常有用。

這能讓工程師在不同的會(huì)話里，輕松復(fù)用相同的指導(dǎo)和最佳實(shí)踐。

舉個(gè)例子，為了確保Codex按照風(fēng)格指南寫代碼，OpenAI團(tuán)隊(duì)在頂層的AGENTS.md里加了這么一段：

- **Always run** `./gradlew detektFix` (or for the affected modules) **before committing**. CI will fail if formatting or detekt issues are present.

Codex擅長(zhǎng)的地方

接下來，再來看看Codex最擅長(zhǎng)什么？

• 秒懂大型代碼庫：Codex精通所有主流編程語言，不需要搞復(fù)雜的抽象，就能輕松地在不同平臺(tái)間復(fù)用相同的概念。

• 測(cè)試覆蓋率：Codex對(duì)寫單元測(cè)試有著獨(dú)特的熱情，能覆蓋各種邊緣情況。雖說不是每個(gè)測(cè)試都很深，但這廣撒網(wǎng)的覆蓋率對(duì)防止Bug回歸特別有用。

• 響應(yīng)反饋：同樣，Codex很聽勸。當(dāng)CI掛了的時(shí)候，可以直接把日志甩給它（粘貼到prompt里），讓它給個(gè)修復(fù)方案。

• 大規(guī)模并行、用完即棄：大多數(shù)人根本沒試探過并行會(huì)話數(shù)量的極限。開發(fā)者可以并行測(cè)試好幾個(gè)想法，把代碼當(dāng)成一次性用品，不行就扔。

• 提供新視角：在設(shè)計(jì)討論中，團(tuán)隊(duì)會(huì)把Codex當(dāng)成一個(gè)生成式工具，用它來挖掘潛在的故障點(diǎn)，或者發(fā)現(xiàn)解決問題的新路子。比如，在設(shè)計(jì)視頻播放器內(nèi)存優(yōu)化時(shí)，Codex翻遍了多個(gè)SDK，提出了一些團(tuán)隊(duì)根本沒時(shí)間去細(xì)究的方案。Codex調(diào)研出的這些見解，對(duì)于將最終App內(nèi)存占用降到最低簡(jiǎn)直價(jià)值連城。

• 騰出手做高杠桿工作：實(shí)際上，團(tuán)隊(duì)最后花在Review和指揮代碼上的時(shí)間，比自己寫的時(shí)間還要多。話雖如此，Codex在代碼審查（Code Review）方面也很牛，經(jīng)常能在合并代碼前就揪出Bug，提高了可靠性。

一旦摸清了Codex的能力，團(tuán)隊(duì)的工作模式就變得很直接了。

在模式清晰、范圍明確的地方，讓Codex去干那些繁重的苦力活；而團(tuán)隊(duì)則專注于架構(gòu)、用戶體驗(yàn)、系統(tǒng)性變更和把控最終質(zhì)量。

立規(guī)矩，手動(dòng)打地基

為了用好Codex并確保出活穩(wěn)健、好維護(hù)，關(guān)鍵在于，開發(fā)者要親自把控系統(tǒng)的設(shè)計(jì)和關(guān)鍵權(quán)衡。

這包括定好App的架構(gòu)、模塊化、依賴注入和導(dǎo)航；甚至身份驗(yàn)證和基礎(chǔ)網(wǎng)絡(luò)流程也是自己搞定的。

對(duì)于一個(gè)估算有85%的代碼都是Codex寫的項(xiàng)目來說，一個(gè)精心規(guī)劃的地基避免了昂貴的返工和重構(gòu)。

OpenAI團(tuán)隊(duì)表示，「這絕對(duì)是我們做過的最正確的決定之一」。

一定要形成這樣一個(gè)思路——

不是為了盡快搞個(gè)「能跑的東西」，而是要搞個(gè)「懂規(guī)矩的東西」。

寫代碼有很多種「正確」的方式：

• 不需要告訴Codex具體每一步怎么做；

• 但需要向Codex展示什么是「正確」的。

一旦定好了起點(diǎn)和團(tuán)隊(duì)喜歡的構(gòu)建方式，Codex就可以開工了。

為了看看會(huì)發(fā)生什么，OpenAI團(tuán)隊(duì)確實(shí)試過直接給Prompt：

照著iOS代碼構(gòu)建Sora Android App。開始干。

結(jié)果，很快就翻車了。

雖然Codex寫出來的東西技術(shù)上能跑，但產(chǎn)品體驗(yàn)完全不達(dá)標(biāo)。

而且如果不懂端點(diǎn)、數(shù)據(jù)和用戶流，Codex這種「一錘子買賣」（Zero-shot）寫出來的代碼根本不可靠。哪怕不用 AI，一次性合并幾千行代碼也是作死。

OpenAI的假設(shè)是，如果給Codex一個(gè)寫滿好范例的沙盒，它就能如魚得水；事實(shí)證明，他們是對(duì)的。

光禿禿地讓Codex「做個(gè)設(shè)置頁面」基本不靠譜。

但如果你讓它「參考你剛才看到的那個(gè)頁面的架構(gòu)和模式，做個(gè)設(shè)置頁面」，效果就好太多了。

人類做結(jié)構(gòu)性的決策并定下硬性規(guī)矩；Codex負(fù)責(zé)在這個(gè)框架里填充大量的代碼。

先規(guī)劃，再編碼

為了最大化Codex的潛力，團(tuán)隊(duì)下一步是搞清楚——怎么讓Codex長(zhǎng)時(shí)間在無人監(jiān)督的狀態(tài)下干活。

為此，4人團(tuán)隊(duì)改了工作流。

對(duì)于任何稍微復(fù)雜點(diǎn)的改動(dòng)，先讓Codex幫理清系統(tǒng)和代碼是怎么運(yùn)作的。

比如，讓它讀一組相關(guān)文件，總結(jié)這個(gè)功能是怎么跑的；比如數(shù)據(jù)怎么從API流經(jīng)Repository層、ViewModel，最后到UI，然后人工糾正或細(xì)化它的理解。

這就像帶一個(gè)能力很強(qiáng)的新隊(duì)友一樣，團(tuán)隊(duì)會(huì)跟Codex一起制定一個(gè)扎實(shí)的實(shí)施計(jì)劃。

這個(gè)計(jì)劃通常像一份微型設(shè)計(jì)文檔，指明哪些文件要改，要引入什么新狀態(tài)，邏輯該怎么走。

只有到了這一步，團(tuán)隊(duì)才讓Codex開始執(zhí)行計(jì)劃，一步步來。

此處，有個(gè)非常實(shí)用的小技巧：

對(duì)于那種超長(zhǎng)任務(wù)，當(dāng)上下文窗口快爆了的時(shí)候，他們會(huì)讓Codex把計(jì)劃保存到一個(gè)文件里，這樣就能在不同的會(huì)話里延續(xù)同樣的指導(dǎo)思路。

這個(gè)額外的規(guī)劃循環(huán)證明，磨刀不誤砍柴工。

團(tuán)隊(duì)可以放心地讓Codex長(zhǎng)時(shí)間「無人監(jiān)督」地跑，這也讓Code Review變得更容易，因?yàn)榭梢詫?duì)照計(jì)劃來檢查實(shí)現(xiàn)，而不是一臉懵逼地看Diff。

而且萬一出問題了，可以先調(diào)試計(jì)劃，再調(diào)試代碼。

多AI并行， 分布式工程

在項(xiàng)目最忙的時(shí)候，OpenAI團(tuán)隊(duì)經(jīng)常并行跑著好幾個(gè)Codex會(huì)話。

一個(gè)在做播放功能，另一個(gè)在做搜索，另一個(gè)在處理錯(cuò)誤，有時(shí)候還有一個(gè)在寫測(cè)試或重構(gòu)。

這感覺不像是用工具，更像是「管團(tuán)隊(duì)」。每個(gè)會(huì)話都會(huì)定期匯報(bào)進(jìn)度。

一個(gè)可能會(huì)說，「我已經(jīng)規(guī)劃好這個(gè)模塊了；這是我的建議」，而另一個(gè)會(huì)為一個(gè)新功能甩出一個(gè)巨大的Diff。

每一個(gè)都需要關(guān)注、反饋和Review。

這跟做一個(gè)帶著好幾個(gè)新人的Tech Lead簡(jiǎn)直一模一樣，大家都在推進(jìn)，大家都需要指導(dǎo)。

結(jié)果就是形成了一種協(xié)作流。Codex這種暴力的編碼能力，把團(tuán)隊(duì)從大量的手工打字中解放出來了。

因此，他們有更多的時(shí)間思考架構(gòu)，仔細(xì)讀PR，測(cè)試App。

Codex不會(huì)有上下文切換的瓶頸，但開發(fā)者有。開發(fā)工作流，從寫代碼變成了做決定、給反饋和集成變更。

這就是「布魯克斯的定律」以一種新方式應(yīng)驗(yàn)的地方。

你不能簡(jiǎn)單地增加Codex會(huì)話就指望速度線性提升，就像你不能往項(xiàng)目里無限加人一樣。

每一雙額外的「手」，哪怕是虛擬的，都會(huì)增加協(xié)調(diào)成本。

Codex：跨平臺(tái)超能力

OpenAI這一項(xiàng)目起步時(shí)有一個(gè)巨大的先發(fā)優(yōu)勢(shì)：Sora已經(jīng)在iOS上發(fā)布了。

他們經(jīng)常把Codex指向iOS和后端代碼庫，幫它理解關(guān)鍵需求和約束。

在整個(gè)項(xiàng)目過程中，OpenAI開玩笑說「重新發(fā)明了跨平臺(tái)框架，忘掉React Native或Flutter，跨平臺(tái)的未來就是 Codex」。

這句玩笑背后有兩個(gè)原則：

1. 邏輯是可移植的

無論代碼是用Swift還是Kotlin寫的，底層的應(yīng)用邏輯——數(shù)據(jù)模型、網(wǎng)絡(luò)調(diào)用、驗(yàn)證規(guī)則、業(yè)務(wù)邏輯——都是一樣的。Codex非常擅長(zhǎng)讀取Swift實(shí)現(xiàn)并生成語義一致的Kotlin代碼。

2. 具體示例提供強(qiáng)大的上下文

一個(gè)全新的Codex會(huì)話，如果能看到「這就是它在iOS上究竟是怎么跑的」以及「這是Android的架構(gòu)」，那效率遠(yuǎn)比光聽自然語言描述要高得多。

基于這些原則，團(tuán)隊(duì)把iOS、后端和Android倉庫都放到了同一個(gè)環(huán)境中。

給Codex一個(gè)這樣的Prompt：

閱讀iOS代碼里的這些模型和端點(diǎn)，然后出一個(gè)計(jì)劃，用現(xiàn)有的API Client和模型類在Android上實(shí)現(xiàn)同樣的行為。

此處，也有一個(gè)實(shí)用的小技巧：

在~/.codex/AGENTS.md里詳細(xì)寫明本地倉庫在哪兒以及里面有啥。這能讓Codex更容易地找到和跳轉(zhuǎn)到相關(guān)代碼。

更廣泛的經(jīng)驗(yàn)是，對(duì)于Codex來說，上下文就是一切。

當(dāng)Codex理解了功能在iOS里是怎么跑的，再結(jié)合對(duì)Android App結(jié)構(gòu)的理解，就能獲得非常好的結(jié)果。

一場(chǎng)復(fù)盤 ，開發(fā)者「超能力」覺醒

28天沖刺結(jié)束時(shí)，用Codex已成為OpenAI默認(rèn)的開發(fā)閉環(huán)——理解代碼、規(guī)劃變更、實(shí)現(xiàn)功能、Review輸出。

顯然，AI輔助開發(fā)并沒有降低工程的嚴(yán)謹(jǐn)性，反而提升了它。

Codex團(tuán)隊(duì)設(shè)計(jì)師Ed Bayes描述了，這個(gè)工具如何改變了自己的工作流。

如今，Codex已與項(xiàng)目管理工具Linear、以及通訊平臺(tái)Slack打通，團(tuán)隊(duì)成員可以直接把編程任務(wù)派給AI智能體。

他表示，「你可以把Codex拉進(jìn)來，基本上可以直接給Codex指派 issue。Codex簡(jiǎn)直就是你工作區(qū)里的一個(gè)隊(duì)友」。

這種集成意味著，當(dāng)有人在Slack里發(fā)反饋時(shí)，可以直接@Codex讓它修bug；它還會(huì)提一個(gè)PR，團(tuán)隊(duì)成員可以在同一個(gè)帖子里審查代碼并進(jìn)行迭代。

「它基本上就是在模擬這種同事關(guān)系，不管你在哪工作它都在」。

盡管Codex能力很強(qiáng)，但它的目標(biāo)是立刻從A到B。這就是為什么離了人，AI輔助編程就玩不轉(zhuǎn)。

明日軟件工程師的「超能力」，將是深刻的系統(tǒng)理解能力，以及在長(zhǎng)時(shí)間跨度上與AI協(xié)作的能力。

現(xiàn)在，Codex讓開發(fā)者能專注于軟件工程最有意義的部分，回歸他們熱愛這門手藝的初心。

一旦Codex在一個(gè)上下文豐富的環(huán)境中配置好，懂你的目標(biāo)和你喜歡的構(gòu)建方式，任何團(tuán)隊(duì)都能讓戰(zhàn)斗力翻倍。

這一次，OpenAI的發(fā)布復(fù)盤不是一個(gè)萬能藥方，也不敢說已經(jīng)徹底搞懂了AI輔助開發(fā)。

但他們希望，能以自己的經(jīng)驗(yàn)啟發(fā)更多的開發(fā)者，讓 Codex更好地為人們所用。

參考資料：

https://arstechnica.com/ai/2025/12/how-openai-is-using-gpt-5-codex-to-improve-the-ai-tool-itself/

https://openai.com/index/shipping-sora-for-android-with-codex/

秒追ASI

?點(diǎn)贊、轉(zhuǎn)發(fā)、在看一鍵三連?

點(diǎn)亮星標(biāo)，鎖定新智元極速推送！