自今年 1 月以來，Codex 成了最明星的 AI coding 產品之一，用量增長 6 倍，目前超過 500 萬周活用戶。在 OpenAI 內部，近 90% 員工每周使用 Codex——不是 100% 的工程師，是 100% 的整個公司，包括法務、財務、市場、傳播，都在用。
負責 Codex 的 Andrew Ambrosino，是設計師出身，轉工程師，再做 PM，多次創業。最近他作客播客節目，分享了 Codex 及其背後的一系列產品理念和哲學，以及更重要的問題：當 AI 讓實現變得幾乎免費，「該做什麼」這件事，到底誰說了算？
一個老問題：為什麼 AI 至今做不好設計
不久前，Codex 的競品 Claude Code 的設計負責人 Jenny Wen 提出過一個觀點：設計流程已經死了，東西動得太快，沒時間按傳統流程走。
這個觀點引發不少討論，Andrew 也看到了，他同意設計流程死了，但理由不一樣。他回憶起早年在創業公司做設計招聘時，行業里流行一篇文章叫「案例工廠」，是一篇 2019 年發表在 UX Collective 上的著名文章，核心觀點是設計師被教成了一套流程至上的人，從用戶研究、發散、收斂、原型驗證，只要走過這套流程，結果就一定好。
「我在 AI 出現之前就不喜歡那個流程。」Andrew 說，並非流程本身有什麼問題，但執著於流程，會把它本身凌駕在了結果之上。
AI 出現之後，任何人都能快速做出一個看起來非常精緻的原型。過去，你看到一個東西長得像產品，你默認它已經走到流程晚期，「假設已經被消除、設計已經看過、業務目標已經對齊」。如今，這種「精緻」和「真正準備上線」之間的關聯已經斷了，Andrew 的描述是：
「現在你可以把完整的實現拉進設計流程的最早期。一個打磨得無比精緻的原型看起來就像能上線，但它實際上還在設計流程的探索階段——只是沒有人告訴你這一點。九十個人都會有同一個想法，每個人都做出來了，看起來很精緻，但這不是產品——這就是現在的設計流程。」
Codex 團隊內部的解法是一個叫「baby Codex」的極簡代碼庫，專門用來快速探索交互方案，不做生產級代碼。
「我們有個叫 baby Codex 的內部版本——一個極度簡化的代碼庫，用來快速探索交互方案。『側邊欄能不能這樣？面板能不能加個群聊？』這本身就是設計流程。」
那麼設計流程到底死了嗎？Andrew 給了一個兩面回答：
「說設計流程死了，既對也不對。如果你跟流程的具體工具綁死了，那你完了。但把『我們現在在流程的哪個階段』這個框架扔掉，那才是最大的錯誤。」
至於為什麼 AI 在設計這個具體任務上表現尤其差，Andrew 的答案很直接：設計比代碼更難評分。
「設計比代碼更難『評分』。創造一個訓練循環來區分好設計和壞設計，比判斷代碼能不能編譯，要囉嗦得多、困難得多。因為品味中的人的部分，是這個反饋機制必需的東西。」
他還補充了兩個更深的問題。第一是文化維度——AI 可以完美複製 Linear 的網站，但每次都出 Linear，而設計需要的恰恰是新東西多於已知模式。第二是抽象層——如果一個公司明天改品牌色，淺層做法是手動改 263 個組件，深層做法是讓所有視覺元素之間共享同一套語義關係，而這個抽象能力，目前的模型還夠不著。
「給人類大腦鼓個掌吧，」他說。
同一個產品，模型換了，就改命了
Codex 的前身可以拉出一條線：Operator → Atlas → Codex Web → Codex 桌面端。Andrew 認為這本質上就是同一個功能，在不同的時間點、搭配不同的模型能力，反覆重新發布。
「這些其實都是同一個功能，一次又一次地重新發布。只不過每次搭配的智能水平不同。」
他給了一個非常有說服力的例子：
「我非常確定，Codex 桌面端如果去年 11 月發布，在市場上絕對會失敗。而唯一的變量就是 11 月到 2 月之間的模型進步。同一個產品形態，結果完全取決於幾個月的模型時間差。」
這裡他還提到一個教訓，他們曾經「在 AGI 這條路上走得太快了」。
「最初的 Codex Web 太 AGI-pilled 了——你給模型一個任務，它跑去做完回來告訴你，問題是它做得不夠好。Claude Code 反過來——完全本地、不接雲端、不強求全自動，它會問你問題、等著你。那個形態才適合當時的模型水平。我們在 AGI 這條路上走得太快了。」
這個說法聽著有些為自己挽尊的意思，但不重要，及時調轉船頭就行。 Andrew 現在的邏輯是：不要因為一個功能現在不行就判它死刑。列出未來一兩年所有想做的事，全部做成原型，哪些現在夠成熟就上，剩下的交給時間。每次模型有一次飛躍，把那件事再拿出來試一遍。功能好不好，很多時候不在於功能本身的形態，而在於它背後那個模型夠不夠聰明。
他怎麼用 Codex 工作
Andrew 每天早上打開 Codex，首先看到的是一份每日簡報。
「我每天早上醒來，看到 Codex 給我的每日簡報——從我加入的 3000 個 Slack 頻道里提取出來的。哪些需要我注意。我可以回復，『給我五個問題，我來回答』。」
這個簡報是怎麼養出來的？不是靠寫多麼精確的指令。
「每次 Codex 自動任務跑了，如果不對，我不需要去改指令。我直接對它說：『下次跑的時候注意這個』，『這個東西沒出現在簡報里，能不能確保類似的東西以後出現』。它自己會更新通知方式。」
他最近一次產品發布的協調方式也很有意思：
「我有一個 Notion 文檔列了所有要做的事。Codex 自動從 Pull Request、Slack 頻道收集進度更新，更新我的狀態追蹤表——這是我們第一次『用 vibe 協調』的發布。」
整體來看，他的工作流並不局限在 Codex 當中，而是通過 MCP 等方式協同各個外部資源。可以參考，但不一定要借鑑，畢竟，他可是不用操心 token 計費的人吶……
Codex 不是超級應用，是一個 home base
外界一直有人把 Codex 和 ChatGPT 的關係往「超級應用」上靠——所有工具塞進一個窗口。Andrew 明確不喜歡這個叫法，他用的詞是 home base。
「Codex 不該是把你所有事都鎖在一個矩形里的超級應用。它應該是一個 home base——你在上面開始工作、結束工作、自動工作。它用各種連接器、瀏覽器、擴展跟你已經用的工具對話。你做重度財務建模時，它直接跟 Excel 桌面端交互，算完你就關掉 Excel。」
最能說明這個理念的，是一個 Premiere Pro 的故事。OpenAI 內部的影片編輯試著用 Codex 剪片子。
Codex 不是影片編輯器，但它理解 Premiere Pro 的工作方式——能直接編輯 Premiere 背後的項目文件，做不了的操作，它做了一件更驚人的事：
「Codex 自己給自己寫了個 Premiere Pro 的擴展插件，然後通過擴展告訴 Premiere：請把這裡的時間標記移到那裡。」
產品開發流程，已經被重塑
整個對話中，Andrew 反覆回到一個核心觀察：AI 把產品開發流程完全倒轉了。
「任何人都能做出任何東西。你給人們無限 token，每個人都在做東西。回頭看看我們過去跑的產品流程——研究、構思、原型，所有這些都是建立在一個假設上：實現是昂貴的。所以你要用文檔、研究、原型把所有實現風險提前消除。這個假設已經消失了。」
舊流程的邏輯是「實現貴 → 先寫 PRD、做研究、畫原型來降風險 → 再動手」。新流程里實現便宜到幾乎免費，於是同一個功能可能有 90 個團隊在同時做原型。難事不再是「要不要做這個」，而是「做了這麼多，哪個最好、哪些該合併、怎麼收束」。
但是，這意味著 PRD 已經死了嗎？
「因為實現變得極其便宜，非工程師特別容易直接跳進原型。但對工程師來說，現在反而很容易寫一堆沒人想讀的文檔。關鍵不是扔了文檔或扔了原型，而是選對媒介。」
Andrew 收束整場對話的那句話，大概也是給所有在 AI 時代重新定位自己的人的一句建議：
「別跟你的具體流程結婚。跟你唯一能交付的結果結婚，然後該改流程就改流程。如果你最擅長的還是『Figma 自動布局』，那就該幹嘛還是幹嘛。」
既然工具會變、模型會變、流程會過時，唯一不變的，應該是你交付獨特結果的能力。
