你的社交媒體或許曾被 Sora 生成的各種抽象視頻刷屏過。

大家拿著這款新出的應(yīng)用玩得不亦樂乎，一會(huì)兒是花樣滑冰運(yùn)動(dòng)員頭上頂著一只貓表演三周跳，一會(huì)兒是一個(gè)人雙腿張開站在兩匹馬上。

但是，這款登頂應(yīng)用商店榜首、體驗(yàn)絲滑、功能完備的應(yīng)用，并不是什么龐大的移動(dòng)端團(tuán)隊(duì)熬夜肝出來的。

作為一家處于風(fēng)暴眼中的 AI 巨頭，要為旗艦產(chǎn)品 Sora 開發(fā)安卓版應(yīng)用，通常需要一支完整的移動(dòng)端團(tuán)隊(duì)耗費(fèi)數(shù)月打磨。但在 OpenAI，故事有了新版本：4 名工程師，僅用 18 天完成內(nèi)部版，28 天正式上線。

他們是怎么做到的？答案是他們擁有第五位「成員」——Codex。

Codex 的產(chǎn)品負(fù)責(zé)人 Alexander，將這位 AI 隊(duì)友描述為「一位超級(jí)聰明的實(shí)習(xí)生」 。它不是普通的自動(dòng)補(bǔ)全工具，它是一個(gè)真正的開放式編程智能體。它不會(huì)主動(dòng)去刷 Slack 或者看監(jiān)控?cái)?shù)據(jù)（除非你要求它這么做），極其專注。

Sora 團(tuán)隊(duì)這次發(fā)現(xiàn)了一個(gè)特別取巧的辦法：

因?yàn)?Sora 的 iOS 版已經(jīng)發(fā)布，邏輯是可移植的。無論是 Swift 還是 Kotlin，底層的數(shù)據(jù)模型、網(wǎng)絡(luò)調(diào)用、驗(yàn)證規(guī)則都是一樣的。加之 Codex 非常擅長閱讀 Swift 代碼，轉(zhuǎn)手就生成了語義完全一致的 Kotlin 代碼。

不像人類工程師，Codex 對(duì)寫單元測(cè)試有著「獨(dú)樹一幟的熱情」 。它會(huì)不厭其煩地編寫覆蓋各種邊緣情況的測(cè)試用例。雖然深度可能差點(diǎn)意思，但架不住它量大，廣泛的覆蓋范圍直接把代碼回歸的風(fēng)險(xiǎn)降到了最低。

當(dāng)持續(xù)集成（CI）失敗時(shí)，工程師只需把報(bào)錯(cuò)日志丟給 Codex，它就能分析并提出修復(fù)方案。這種反饋循環(huán)極大地解放了人類的精力。

OpenAI 聯(lián)合創(chuàng)始人 Andrej Karpathy 曾遇到過讓他束手無策的 Bug，最終他將問題拋給 Codex，讓它跑了一個(gè)小時(shí)，結(jié)果真的解決了問題。

到了項(xiàng)目最忙的時(shí)候，工程師可以使用「分身術(shù)」，同時(shí)啟動(dòng)多個(gè) Codex 會(huì)話（Session）。一個(gè)負(fù)責(zé)播放器優(yōu)化，一個(gè)負(fù)責(zé)搜索功能，另一個(gè)在重構(gòu)錯(cuò)誤處理模塊。

這下，工程師不用「做完你的做你的」了，而是讓 Codex 「好好做你的」。

每個(gè)「分身」都會(huì)定期匯報(bào)進(jìn)展。一個(gè)可能會(huì)說：「我已經(jīng)完成了這個(gè)模塊的規(guī)劃；這是我的方案」，而另一個(gè)則會(huì)提出一個(gè)關(guān)于新功能的改進(jìn)方案。

值得一提的是，Codex 甚至開始參與自身訓(xùn)練的值守工作。很多用于管理訓(xùn)練流程、搭建核心基礎(chǔ)設(shè)施的代碼，都是 Codex 自己寫的。它的代碼審查機(jī)制使得它能發(fā)現(xiàn)很多錯(cuò)誤，甚至揪出過一些相當(dāng)關(guān)鍵的配置問題，做到了「三省吾身」。

如果代碼都讓 AI 敲了，工程師干什么？

OpenAI 的工程師 Aaron Friel 說道：「現(xiàn)在的工程師都變成 Manager 了，甚至可以說變成了 Director。」工程師可以給 Codex 分配任務(wù)，甚至讓 Codex 創(chuàng)建子代理去干活，而你負(fù)責(zé)審核產(chǎn)出。

Sora 團(tuán)隊(duì)最初嘗試過直接讓 Codex「基于 iOS 代碼構(gòu)建 Sora Android 應(yīng)用，開始」，結(jié)果很快就放棄了。雖然 Codex 生成的代碼在技術(shù)上可以運(yùn)行，但產(chǎn)品體驗(yàn)糟糕透了。這讓他們意識(shí)到，Codex 雖然強(qiáng)大，但它不是魔法，也不是可以對(duì)著許愿的阿拉丁神燈。

為了讓 Codex 能無人值守地運(yùn)行長達(dá) 24 小時(shí)，工程師必須先與它溝通，制定一份詳細(xì)的「實(shí)施計(jì)劃」 。這就像一份小型設(shè)計(jì)文檔，指明哪些文件要改、邏輯流向如何。工程師必須先想清楚了，再讓 AI 動(dòng)手。

在 OpenAI 內(nèi)部，92% 的技術(shù)人員都在使用 Codex，使用它的工程師比不使用的產(chǎn)出的 PR 多出了 70%。甚至連 OpenAI 的非技術(shù)團(tuán)隊(duì)，比如產(chǎn)品經(jīng)理和銷售，也開始直接通過 Codex 查詢代碼庫細(xì)節(jié)，不再需要找工程師開會(huì)了。

今年 2 月， Andrej Karpathy 發(fā)了一條推文，造了一個(gè)新詞叫 Vibe Coding。但很快就對(duì)它「祛魅」了，因?yàn)?Vibe Coding 適合的是 Throwaway Weekend Projects（一次性周末項(xiàng)目），帶來的很可能是指數(shù)級(jí)增長的代碼屎山。

與隨性的 Vibe Coding 不同，Vibe Engineering 強(qiáng)調(diào)的是一種「帶著責(zé)任感的提速」。也就是說，資深工程師利用 LLM（大語言模型）加速工作，但會(huì)為最終的代碼負(fù)責(zé)。

這時(shí)，一名工程師的技能和經(jīng)驗(yàn)越多，與 LLM 和 Coding Agent 協(xié)作時(shí)獲得的結(jié)果就會(huì)越快、越好。

OpenAI 開發(fā)者體驗(yàn)負(fù)責(zé)人 Romain Huet 指出，未來的能力瓶頸將轉(zhuǎn)移到三個(gè)方向：設(shè)計(jì)與品味、判斷力以及清晰的溝通。

正如 Alexander 所設(shè)想的，未來的開發(fā)模式或許是「對(duì)話驅(qū)動(dòng)開發(fā)」（Chatter-driven development）。這有點(diǎn)像是在玩 Tinder、TikTok 和 Codex 的結(jié)合體，AI 拋出一堆想法和代碼實(shí)現(xiàn)（Best of N），你左滑否定，右滑采納。

被低估的瓶頸：你的打字速度

關(guān)于通用人工智能（AGI）何時(shí)到來，Alexander 給出了一個(gè)有趣的視角。他認(rèn)為，目前阻礙 AI 爆發(fā)式增長的一個(gè)被低估的因素是人類的打字速度，以及人類同時(shí)處理多項(xiàng)任務(wù)、編寫提示詞（Prompt）的速度。

現(xiàn)在的情況是：「人類寫提示詞→ AI 寫代碼→人類檢查代碼?！?/p>

你可以讓四個(gè) Codex 會(huì)話同時(shí)工作，但你能同時(shí)清晰地描述四個(gè)不同的任務(wù)需求嗎？你能同時(shí)審查四份代碼變更并給出有價(jià)值的反饋嗎？

為了突破這個(gè)瓶頸，OpenAI 正在嘗試重構(gòu)系統(tǒng)，讓 Agent 能夠主動(dòng)提供幫助，而不是被動(dòng)等待人類敲擊鍵盤輸入指令。

就像他們所暢想的，未來的 Codex 不再是那個(gè)需要你抽一鞭子才動(dòng)一下的被動(dòng)工具，而是能主動(dòng)走過來對(duì)你說：「嘿，我看你正在寫這個(gè)模塊，我有幾個(gè)更好的優(yōu)化方案，你要不要看看？」

在這個(gè)新世界里，不論你是寫代碼的工程師，還是做設(shè)計(jì)的產(chǎn)品經(jīng)理，我們都在變得「更技術(shù)」。

博客＆播客鏈接：

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

h

ttps://shortcast.me/DOnfxtgupvJdrCeAm0Zi

歡迎加入 APPSO AI 社群，一起暢聊 AI 產(chǎn)品，獲取，解鎖更多 AI 新知

我們正在招募伙伴

簡歷投遞郵箱hr@ifanr.com

?? 郵件標(biāo)題「姓名+崗位名稱」（請(qǐng)隨簡歷附上項(xiàng)目/作品或相關(guān)鏈接）