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

大家拿著這款新出的應用玩得不亦樂乎，一會兒是花樣滑冰運動員頭上頂著一只貓表演三周跳，一會兒是一個人雙腿張開站在兩匹馬上。

但是，這款登頂應用商店榜首、體驗絲滑、功能完備的應用，并不是什么龐大的移動端團隊熬夜肝出來的。

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

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

Codex 的產品負責人 Alexander，將這位 AI 隊友描述為「一位超級聰明的實習生」 。它不是普通的自動補全工具，它是一個真正的開放式編程智能體。它不會主動去刷 Slack 或者看監(jiān)控數(shù)據(jù)（除非你要求它這么做），極其專注。

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

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

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

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

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

到了項目最忙的時候，工程師可以使用「分身術」，同時啟動多個 Codex 會話（Session）。一個負責播放器優(yōu)化，一個負責搜索功能，另一個在重構錯誤處理模塊。

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

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

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

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

OpenAI 的工程師 Aaron Friel 說道：「現(xiàn)在的工程師都變成 Manager 了，甚至可以說變成了 Director?！构こ處熆梢越o Codex 分配任務，甚至讓 Codex 創(chuàng)建子代理去干活，而你負責審核產出。

Sora 團隊最初嘗試過直接讓 Codex「基于 iOS 代碼構建 Sora Android 應用，開始」，結果很快就放棄了。雖然 Codex 生成的代碼在技術上可以運行，但產品體驗糟糕透了。這讓他們意識到，Codex 雖然強大，但它不是魔法，也不是可以對著許愿的阿拉丁神燈。

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

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

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

與隨性的 Vibe Coding 不同，Vibe Engineering 強調的是一種「帶著責任感的提速」。也就是說，資深工程師利用 LLM（大語言模型）加速工作，但會為最終的代碼負責。

這時，一名工程師的技能和經驗越多，與 LLM 和 Coding Agent 協(xié)作時獲得的結果就會越快、越好。

OpenAI 開發(fā)者體驗負責人 Romain Huet 指出，未來的能力瓶頸將轉移到三個方向：設計與品味、判斷力以及清晰的溝通。

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

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

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

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

你可以讓四個 Codex 會話同時工作，但你能同時清晰地描述四個不同的任務需求嗎？你能同時審查四份代碼變更并給出有價值的反饋嗎？

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

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

在這個新世界里，不論你是寫代碼的工程師，還是做設計的產品經理，我們都在變得「更技術」。

博客＆播客鏈接：

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

h

ttps://shortcast.me/DOnfxtgupvJdrCeAm0Zi

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

我們正在招募伙伴

簡歷投遞郵箱hr@ifanr.com

?? 郵件標題「姓名+崗位名稱」（請隨簡歷附上項目/作品或相關鏈接）