現在最貴的東西，叫“品味”。

編譯 | 王啟隆

出品丨AI 科技大本營（ID：rgznai100）

安德魯·阿姆布羅西諾（Andrew Ambrosino）在硅谷折騰了十幾年，做過設計師、寫過代碼，也自己創過業。但大多數時候，他覺得自己是個失敗者——他的公司最后基本是拆碎了賤賣掉的。

這種在泥潭里摸爬滾打的體驗，直到他接手OpenAI 智能體產品 Codex時才算熬出頭。今年 1 月以來，這個產品的周活暴漲了 6 倍，突破了 500 萬。最夸張的是在 OpenAI 內部，甚至有接近 100% 的員工每周都在用它，包括根本不懂代碼的財務和法務。而四月份左右，潑天的熱度讓 Codex 突然出圈，接上了今年“龍蝦潮”的機遇。

這種爆紅也徹底顛覆了團隊做產品的方法。以前，寫代碼是最貴的，所以大家得先寫一堆需求文檔和原型來規避開發風險。現在，用 AI 寫代碼便宜到近乎不要錢。在 OpenAI 內部，經常有 90 個完全不搭界的團隊，同時手搓出 90 個功能一模一樣的產品原型。當“實現”不再是瓶頸，如何在這 90 個原型里看出哪個有靈氣，哪個能和系統對上，就全憑產品經理和設計師的“品味”（Taste）了。

在與播客 Lenny's Podcast 的最新對話中，安德魯結合自己在泥潭里摸爬滾打十幾年的教訓，聊了聊為什么他們不取消產品經理分工、為什么要在模型還沒變聰明前就提前做功能，以及一個剪輯師用 Codex 給 Premiere 自動寫插件的真實故事。以下是他在實戰中踩出來的幾個最清醒的認知：

• 當寫代碼便宜到近乎不要錢，“品味”（Taste）就成了最值錢的東西。AI 讓任何人都能在幾分鐘內搓出一個高保真的功能原型。但在無限多的原型里，知道哪一個體驗更對、哪一個動效不會和系統起沖突，甚至在 90 個點子里拼湊出一個完美的方案，這考驗的是人真正的審美和判斷。
  

• 以為能用 AI 跑出幾行代碼，就覺得不需要產品常識和管理方法，這只是工程師的自嗨。

• 跟風取消產品經理、讓所有人自稱“建造者”是個非常愚蠢的決定。
  

• 產品的死活不再由外殼決定，而是取決于底層模型的智力什么時候跨過那個坎。同樣的 Codex 應用，在 2 月發布能月月翻倍，但在 11 月發布就注定完蛋，這中間只差了幾個月模型智力的代際升級。

• 做產品的人得學會寬容：有些功能現在跑不通，不代表它是個壞主意，它可能只是在等底層大模型變得更聰明。

• 真正的“高智能”不是讓用戶去適應聊天框，而是讓 AI 順著你既有的工具去摸索。
  

• AI 的終點不是把所有軟件塞進一個黑色的對話框里，而是像水一樣滲透進你習慣的所有工具。

領取地址：https://s.csdn.cn/4nPsOp

人人皆可手搓原型的時代，比拼的不再是開發速度，而是審美

主持人：我們在準備這次聊天時，我問你最希望大家從這場對話中獲得什么，你說是：AI 正在如何改變產品工作的形態。

你所在的團隊，可能是全世界最前沿的 AI 軟件團隊之一，所以你對未來走向有一個特別有意思的觀察視角——其他團隊在一兩年甚至更久之后，大概也會走向那里。

和幾年前相比，現在一個產品團隊的形態是什么樣的？

Andrew Ambrosino：現在，作為一個帶隊做這些產品的人，最難的事情之一，就是我心里所說的那種“流程反轉”。很多人其實都提到過這一點：現在是誰都可以構建任何東西，對吧？

我現在基本相信，如果從零開始，只要你跟這些模型交流——無論是我們的模型，還是別家的——你都能把你想要的功能先搭起來，對吧？這當然不代表軟件開發本來就很難的那部分不存在了，但這件事真的很酷。

而我覺得，這造成了一個環境：所有人都在不斷地做各種東西，對吧？

主持人：你給了大家無限 token。

Andrew Ambrosino：OpenAI 的每個人都非常有主動性，也都有很棒的點子，所以每個人都在構建各種東西。

而回頭看我們長期以來一直在運行的產品流程，它其實是反過來的，對吧？先做研究、再做構思，可能會有一些原型。即便我們已經走出了瀑布式開發，但整體仍然帶著一種底層假設：實現是昂貴的。

所以你要做的是，在前期通過文檔、研究和原型，把實現相關的風險盡可能都消掉，因為原型和設計更便宜——這就是當時的默認前提。

但現在變了。徹底變了。現在，對于某個我們迫切需要推進的功能，我敢肯定有 90 種不同的探索正在發生。我也敢肯定有 90 個彼此沒有協調的團隊，正在各自實現、各自嘗試，對吧？

所以，如果要給一個簡短答案，那就是：一切反過來了。

這并不是說人們在做根本不同的角色，或關注根本不同的事情，也不是說技能集消失了，或角色本身突然不存在了。而是說，一切反過來了，對吧？現在真正不再昂貴的，其實是實現。真正昂貴的，容我這么說，是品味。

更準確地說，是“策展”這個過程。就像：在那 90 次嘗試里，哪些東西是好的？哪些值得融入這個功能的其他部分？我們該如何去定義它？它是不是應該成為另一個功能的一部分？切換開關里到底該有幾個分段？

原型做得太逼真，反而容易讓人不敢跳出框架去思考

主持人：“品味”這個詞現在太熱門了。我們等會兒再回來聊這個。

你剛剛提到“90 個原型”的說法很有意思。我想確認一下我理解得對不對：OpenAI 里有個想法在流動。過去大家會做的事情是寫文檔——“這是我們要做的東西，這是這個功能，這是這項策略。”

而你現在描述的是——而且這聽起來完全說得通——人們直接做一個原型。你的意思是，公司里很多人其實都有相似的想法，現在他們不再寫文檔，而是各自做一個小原型，于是就形成了 90 個不同的東西，大家可以去看、去挑，最后決定：我們想沿著這個方向走。是這個意思嗎？

Andrew Ambrosino：確實有很多這種情況。而且不只是發生在這里。你也看到很多產品負責人說：PRD 已死，原型當立。其實我一點也不認同這個說法。

我覺得現在正在發生的一件有意思的事是：因為在所有媒介上，實現都變得極其便宜，所以人們非常容易直接跳到原型——尤其當你不是工程師的時候，對吧？尤其是當你以前不會寫代碼，或者從沒對寫代碼感興趣，或者根本沒時間時。你就會特別想說：“PRD 已死。讓我直接做給你看。”

但我同時也觀察到，對于工程師來說，現在也很容易去寫大量文檔——大量不值得別人讀的文檔。

這不是在諷刺寫文檔的人。我的意思是：如果實現變得極其充裕，那么更重要的是，你要為你想表達的觀點選對表達形式。

如果你要表達的是：某個模糊領域里的產品清晰度，那么它可能真的應該是文檔。如果你要做的是：把某個東西交到大家手里，讓大家試一試，去驗證某種交互模式是否成立，那它就該是原型。

但我覺得現在有趣的地方恰恰就在于：選對媒介，變得極其重要。

主持人：你這么說的時候，我想到播客里有位嘉賓分享過一個詞，叫 primal mark（原初筆觸）。當設計師、畫家或者藝術家在一幅畫或一件藝術作品上留下第一筆時，那第一筆就會成為你之后不斷回應的對象。之后的很多東西，都會順著那第一筆一路流淌下來。

所以我從你這里聽到的是：有時候原型反而是錯誤的第一步，因為之后你就只是在回應這個原型，而不是回應另一個想法、另一個更大的想法。我很喜歡這個觀點。

所以現在大家都在說：“好吧，算了，不寫東西了，不寫文檔了，不寫 PRD 了。” 但你的意思是，對于特定場景，它們其實依然有價值。

Andrew Ambrosino：對。我覺得還有一點是，在以前那個世界里，媒介本身其實隱含了很多關于“這件事目前處于流程哪個階段”的信號，對吧？

如果你看到一個東西，它看起來已經很像正式上線的應用，那意味著它在流程中已經走得很后面了——意味著前面的假設已經去過風險、設計團隊已經看過它、這個方向符合商業目標，對吧？

而現在，這些事情都被拆開了。

以前之所以會那樣，是因為如果一件事還沒有被充分去風險，你很難拿到資源把它真正做出來。而現在，這一點已經完全被打破了。

所以我覺得現在特別重要的一點是，要開始明確地說：我們可以有原型，也可以有文檔——關鍵是，這個東西到底是在做什么，是否足夠清楚。因為正如你說的，你絕對不想對一個本來只是用來探索的東西產生過度錨定，只因為它看起來太像正式產品了——視覺上它也許已經像是 ready for prod，但實際上，它并不符合研究的方向或用戶的真實需求，對吧？

不僅是審美，這關乎你選擇在什么事情上投入精力，而這種選擇，實際上就是“品味”在起作用。而這就是在任何領域都最關鍵的事情。

主持人：當你談論“好品味”時，所謂的品味到底是什么？是決定我們該投資什么的判斷標準嗎？還是說，當你已經擁有某樣東西時，你會問自己：這合適嗎？這值得推出市場嗎？當我們思考什么是好品味、什么是良好的判斷力時，這些概念具體又體現在哪些方面呢？因為人們聽到這個詞，總會想：“哦，我有好品味，我懂我懂——但實際生活中它到底是什么樣子？”

Andrew Ambrosino：對，這很有意思。前幾天——我實在是太常上網了——有條推文，我記得好像是 Linear 的產品負責人發的，我可能記錯了，如果說錯了先向原作者道歉。他說，人們過于強調“品味”里審美的那一部分。

他舉了 Paul Graham 做例子，說 Paul Graham 顯然有很好的品味，但他穿的是工裝短褲，對吧？所以我們確實得稍微拆解一下，“品味”到底指什么。

這里面有很多細微差別。我覺得你剛才說的那些，其實都算。品味當然包含審美層面，但它也有系統思維的一面：這個東西如何嵌入整個系統？它還涉及“我們要去哪里”“這屬于哪個更大主題的一部分”；還涉及你該如何呈現它。

很多時候，品味其實來自更廣闊的上下文。當然，品味也包括一些更細部的東西，比如：這個交互動效和它本該承載的語義其實并不匹配，對吧？它的節奏太利落了，但它想表達的內容其實不該是這種感覺。

這類判斷非常重要，而我可能在這方面花了過多精力。但還有一個更大的問題是：這個東西本來應該長成什么樣？如果我們現在什么都能做，那這里的目標到底是什么？我們該怎么走到那里？

我覺得，這其實才是真正的“品味問題”。

為什么 AI 仍然不擅長設計？

主持人：當我聽到這樣的討論時，我總會想：隨著 AI 越來越強、越來越好、做的工作越來越多，人類大腦還有哪些地方依然有價值？而我感覺“品味”就是其中之一。

順著這個話題我還會想到一點：AI 現在在真正的設計上還是很差。AI 的輸出并不好。

Andrew Ambrosino：對。

主持人：很少會讓人覺得：“就是這個了，他們做對了。” 更多時候你會說：“哦，這一看就是 Claude 風格的設計，這一看就是 Codex 風格的設計。”

你為什么覺得，AI 和最前沿的大模型今天就是不擅長設計？你覺得它們未來能做到嗎？你覺得我們會不會走到這樣一天：天啊，設計這件事也徹底完成自動化了？

Andrew Ambrosino：對。我傾向于認為，這背后既有一些現實層面的原因，也有一些更難攻克的問題。

我不在我們的研究組織里。我這么說大概會被研究團隊罵。但我覺得，設計確實比軟件更難打分一點。你要建立一個閉環，讓模型知道什么是好設計、什么是壞設計，這件事比起“代碼能不能編譯”，要更繁瑣，也更費勁，對吧？

因為你所需要的反饋機制里，人的“品味”因素是不可或缺的一部分。

我還覺得，實驗室從歷史上看，往往優先投資于那些能加速 AI 研究本身的能力。在早期代碼模型時代，這一點特別明確：模型如果能寫出正確的代碼，就能直接推動研究進展，對吧？而對于設計，你很難提出同樣直接的論證。

這并不是說“設計不重要”，而是說它并不直接處在那個飛輪里。

這些是現實原因，而這些原因會慢慢消失。模型在設計上最終會變得相當不錯。

但還有一些更模糊、更難的問題，解決起來會非常棘手。我腦子里大概有一個簡短列表。

第一，什么算“好設計”，其實帶有文化層面的成分。你應該記得去年吧，那時候每一個新網站都像在抄 Linear 的官網，對吧？Linear 的官網：設計很好，品味很好。如果模型每次都能做出那樣的東西，我會說：哇，這已經非常驚人了，是巨大躍遷，對吧？但如果我的模型每次輸出的都是 Linear 官網，那問題并沒有真正解決。

在軟件工程里，你幾乎反而希望模型更偏向已知模式，對吧？但在設計里，情況恰恰相反：不，你需要一定程度的隨機性和新鮮感。

還有一點，對我來說——我在早期 Codex 應用上花了很多時間寫代碼，或者監督代碼——即使模型變得擅長設計了，軟件設計 and 實際代碼之間仍然存在一個抽象層，它們之間有一種彼此咬合的關系。

比如說：界面這個角落里的東西，在代碼庫里應該和下面另一個地方的東西共享 X、Y、Z 這些抽象，對吧？這和“模型需要成為一個更好的設計師”其實是兩回事。它當然也涉及視覺設計，但深度要大得多。

它關乎抽象本身。如果明天我們公司做了一次品牌重塑，淺層的問題是：我們得把 263 個組件一個個改掉。深層的問題則是：這兩個外觀不同的東西，它們之間的語義關系是什么？它們都出現在列表里，它們都有這種風格，它們都在向用戶傳達某種交互模式。

我覺得，以當前技術來說，這層抽象依然顯得有點遙不可及。

所以我覺得，在整個過程中，我們從 11 月開始做 Codex 應用，那時我們還沒有全天候使用它。現在我們什么都用它做。這中間經歷了一個過程。而如今，我們在使用它時真正做的事情，也已經和以前不一樣了。

所以你剛才的問題是什么來著？

主持人：我知道。我得說，這個回答太精彩了。

說到設計和創造性，Codex 應用剛出來的時候，真的是一種全新的東西。

主持人：以前沒人見過這樣的東西。它不是終端，也不是 IDE，而是一種能寫代碼的聊天界面，而且你還能看到代碼。

就像你剛才說的，這種情況下很難指望 AI 直接說：“來，這是一整套全新的編碼范式。” 這讓我覺得，至少現在，人類大腦依然有價值的地方，就在于創造力，在于提出新的東西，而不只是沿用過去已有模式。

Andrew Ambrosino：對，我完全同意。此刻，我們還是該為人類大腦鼓掌。

主持人：在我們準備這次節目時，你提到你聽了 Jenny 那期節目。她是 Clockwise and Co 的設計負責人之類的角色。她有一個完整觀點：設計流程已經死了。現在已經沒有時間做設計了，事情發展太快了。就是先做出來，設計只是在過程中邊走邊糾偏。

而你似乎暗示，你對“設計流程”這件事有點不一樣的看法。

Andrew Ambrosino：Jenny 和我在很多地方可能其實是有共識的。我本來就不是那種擁護傳統設計流程的人。我認同她說“它已經死了”這個判斷。而且說實話，就算在 AI 出現之前，我也不喜歡那套流程。

主持人：你能不能快速描述一下那個流程？讓大家知道我們說的“設計流程”到底是什么。

Andrew Ambrosino：幾年前我自己創業的時候，我們也做設計招聘。那時候出過一篇有點嘲諷意味的文章，講“case study 工廠”。一到這個階段，設計師們就被灌輸流程本身才是最重要的，過程的工整大過一切，甚至是產出的結果本身。

仿佛只要一件事走過了這套流程，就有兩件事自動成立：第一，它一定是好的；也就是流程本身保證質量，保證影響力。第二，只要它走過那套流程，那它就是好的——哪怕你不喜歡，哪怕沒人用它。

它一直有點學院派意味，但我覺得當下這個時代，正在把它失效的地方暴露得特別清楚，尤其是在實現速度極大提升之后。

而且再說一遍，這套流程其實建立在一個前提上：實現很昂貴，你通常只負擔得起“真正構建一次”。所以你必須在動手實現之前，完整而徹底地遍歷問題空間和方案空間，對吧？

后來，隨著 Figma、Origami 以及各種工具出現，我們看到一種變化：你可以把交互式原型更早地拉進流程，用來提前獲取一些洞察。你可以去模擬生產環境。

后來甚至出現了一種梗：高管們會說，“那我們干脆直接做個原型不就行了？” 然后還期待它真的能跑起來。但這件事又的確是真實發生的，對吧？這逐漸成了設計流程的一部分。我們把原型前移進來了。

而現在的問題是，你甚至可以把整個實現都前移進來。這就導致大量底層假設之間出現錯位。再一次，當你看到一個非常精致的原型，看起來已經像是隨時可以發布了，足夠多的人在公司里看見它，就會說：“那我們現在能發了嗎？” 但實際上，我們還處在非常早期的設計階段，只是沒人明確說出來。

這就是我們現在面對的大量多人并行探索，對吧？90 個人可能都會有這個想法，做出來的東西也都看上去很成熟，但實際上：不，這本身才是現在的設計流程。

真正可怕的，是把設計流程和媒介綁定在一起。如今設計師有了更多工具來跑這個流程。你甚至可以直接把東西放進當前產品里，做 A/B 測試，或者把它就當作一種原型。

現在很多公司都有一個所謂的“baby version（寶寶版）產品”的概念。你在 Twitter 上應該見過，比如 baby Cursor。我們也有 baby Codex，對吧？它是一個被大幅簡化的代碼庫，但能近似還原正式應用中的所有交互，因此更適合快速進行 vibe coding，對吧？因為你可以說：“如果側邊欄這樣工作會怎樣？” “如果這里彈出一個 pane，然后里面有個群聊會怎樣？” 或者“如果 XYZ 會怎樣？” 對吧？

這就是一個非常強大的工具，而且它已經成了設計流程的一部分。

所以說“設計流程死了”，我覺得既對，也不對，對吧？如果你死死綁定于那套流程每天該怎么執行的具體形式，那對，它死了。你不會過得太舒服。但如果你因此就把流程本身徹底扔掉，或者把“我們現在正處于流程的哪個階段”這層覆蓋視角也一起扔掉，那就錯了。因為這件事現在比以往任何時候都更重要。

主持人：這真的很有意思，因為你的背景幾乎涵蓋了所有職能。別人如果去看你的 LinkedIn，就會發現：工程師、設計師、產品經理、創始人。現在你負責這個桌面應用。而我想，設計似乎并不直接歸你管。是這樣嗎？是有單獨的設計團隊，還是他們也歸你——

Andrew Ambrosino：這要看是哪一周。我們合作非常緊密。我們相信要坐在一起、深度嵌入式協作。至于匯報關系，我不太——

主持人：他們每周都在變化。那 Codex 的設計流程具體是什么樣的？

Andrew Ambrosino：關于“角色坍塌”，已經有很多討論了——那種近乎存在主義式的角色坍塌：“已經沒有角色了。” 但我們并沒有看到這一點。

我們確實看到了比公司其他部門、甚至整個經濟里很多其他地方都更多的“角色融合”，尤其是在 Codex 組織里。我覺得其中一部分原因是，這原本就是一個面向工程師的技術產品，所以我們的設計師“會說工程師的語言”，對吧？我們的產品經理也懂技術語言，也會寫代碼。

Alexander 甚至有計算機科學碩士學位，而我都沒有計算機科學碩士。所以我們確實經歷了很多角色融合。

而我們描述這些群體如何協作的一種方式是：如今各角色之間的重疊程度，比以前大得多。大家不再是由“設計做到哪兒結束、工程從哪兒開始”這種邊界來定義，而更像是由“他們平均把時間花在哪些事情上”來定義。

所以，如果你把我們設計團隊里某個人做的所有事情平均一下，里面會有很多寫代碼的內容，也會有很多產品相關的工作。但從平均值來看，如果你把它畫在一張圖上，他們的點大致還是落在“設計”這一側，對吧？

這其實也和流程有關。尤其是因為整個 Codex 應用，都是在 dogfooding（自我試用、自我使用）閉環中逐漸成型的。

我們所有人都有一種強烈愿望：我們故意忍受不舒服的流程，好讓產品本身變得更好。這其實是一個非常不舒服的狀態。但每周都在變化。

主持人：我太喜歡這個觀點了——“你的角色，就是你把時間花在哪里的平均值。” 如果你大部分工作都在做 PM 的事情，那好，你現在就是 PM。

Andrew Ambrosino：對。

主持人：如果你主要在做工程，那你現在就是工程師。

覺得懂兩句 AI 跑通幾行代碼就不需要產品經理，這只是工程師的自嗨

主持人：我一直覺得，OpenAI 是第一個把大家都稱作 Member of Technical Staff 的公司？

Andrew Ambrosino：不是。我印象里這可能最早可以追溯到 Xerox。第一家我實習的公司叫 Up There，也是這么叫的。

這已經存在很久了，只是現在更普遍，尤其是在研究型的公司里。所以，它其實是從研究文化里衍生出來的。但我感覺這其實也是一個信號，預示著未來的方向。所有人都在變成“技術人員（Member of Technical Staff）”，你的崗位邊界不再分明。

你覺得在更長遠的未來，產品經理、設計師和工程師這些專業崗位，還會作為獨立的工種存在嗎？還是說，我們會迎來一個“全民皆為構建者（Builder）”的大坍塌時代？

Andrew Ambrosino：這正是我有些害怕的地方。

因為有些公司特別喜歡盲目跟風，一旦外面吹起什么風，他們就恨不得立刻跳上這班車。我聽過很多公司說他們要干掉產品經理這個崗位，老實說，這簡直是個糟糕透頂的決定。

產品經理是一個有著完整方法論和最佳實踐的專業學科，經歷了無數次的嘗試和失敗才沉淀下來。如果你僅僅因為自己用 AI 寫了兩行代碼，就覺得可以把整個產品紀律扔進垃圾桶，那是極其危險的。

我不喜歡用“別越界”來限制團隊的發揮，也樂于見到崗位邊界變得模糊。但這其中有一個平衡：因為沒人能包攬所有的廣度與深度。這也是為什么管理永遠不會消失。

不同的職能都有極高的專業門檻。很多寫代碼的工程師會有一種傲慢，覺得只有寫代碼才是硬核技術，其他崗位都只是在“隨便混混（Vibe）”。不，絕對不是這樣的。

就像你雖然能用 Excel 算賬，但這絕不意味著你能去干財務。

在 AI 時代，轉崗和學習最佳實踐確實變得容易了。你不需要因為自己不會記 TypeScript 語法或者匯編語言而覺得做不了工程師。AI 正在剝離這些曾經用來劃分階層、制造信息不對稱的“工具看門機制”，但它不應該剝離對崗位底層核心能力的敬畏。

大家沒必要把這件事說得太絕對、太夸張。

主持人：Codex 團隊現在是什么樣的？有多少工程師、設計師、PM？目前團隊的構成是怎樣的？

Andrew Ambrosino：每次別人問我 Codex 團隊到底有多少人——你還記得我的回答吧？

主持人：記得。

Andrew Ambrosino：我會說，大概在 10 人到幾千人之間。我知道這聽起來像個假答案，但某種意義上它又是真的，因為我們確實把這個產品看成這里所有人工作結果的匯聚。

所有和模型研究有關的工作，所有讓模型更擅長編碼和瀏覽器使用的工作，所有和模型人格有關的工作，所有前端基礎設施相關的產品工作，所有用戶側工作——這一切，最終都體現在這個產品里。

但與此同時，我們也不是每天真的接收幾千上萬人隨便往里提 PR。所以我們確實有一個團隊：工程師是兩位數，設計那邊大概是一半，產品人員有幾個——不過在這里，產品更像是一種獨立的防守打法。

我覺得 Codex 這邊，或者說桌面應用這邊，大家身上有一個共同點，就是主動性和品味。很多人以前都是創始人，或者在大公司里做著“創始人形狀”的工作。也有很多人的品味非常強。

在 OpenAI，我們允許團隊做得很大，所以我們并沒有經歷那種“這里沒有管理”的狀態，但團隊確實規模不小。大部分人是 IC（individual contributor，獨立貢獻者），而我覺得這很好。

主持人：你提到一個詞叫“區域聯防（zone defense）”來形容產品工作，我覺得這很有意思。它和設計上的那種轉變也有點映射關系——就像你們更像是在管理和協調。你多講講這個吧。對于一個產品人來說，“區域聯防”是什么樣的？

Andrew Ambrosino：對。我和 Alexander 聊過很多次這個比喻。我們的觀點是：如果兩個產品人貼得太近地一起工作，往往不是一個好信號。

作為一個產品組織，你其實更希望形成一種“受力分布式”的狀態：哪里有空缺？尤其是在這個新的世界里，策展、引導、對齊，才是大量工作的核心；與此同時，周圍又充滿了混亂——人們到處拋點子，對吧？那種自上而下、規劃一整年的方式，已經行不通了。

所以現在更像是：我們需要那些有品味的人，從原初的概念階段一路將產品引導落地。而這意味著，你基本上需要對整個公司形成覆蓋。于是你們就分散開來，說：“好，誰最適合哪一塊？我們彼此之間拉開一些空間，這樣整個版圖就都有人覆蓋。”

大概就是這么運作的。然后你去填補空白，會說：“我們希望招聘的是有產品意識的工程師。”

我們不希望變成這樣：有一堆人在寫一大堆代碼，最后為了保證產品一致性，還得整個團隊一起重新評審，對吧？我們希望每個人都具備這些能力。但我覺得，人們真正深入鉆研的方向，必須發生變化。

主持人：我最近和像你這樣的人交流得越多，越反復注意到一件事：如今最有價值的人之一，就是那種能把一個想法從想法一路帶到落地的人，而且還具有那種知道“這真的很棒”的品味，能一路護送這個東西，癡迷于把它做得足夠出色——就是你剛剛描述的那種高主動性、高品味的人。

這是不是你們在想“我們要招什么樣的人、誰會在這個新世界里表現得特別好”時的核心標準？

Andrew Ambrosino：對。我覺得這就是現在最核心的一塊。它也和我看待 IC 與管理的方式有關：不是說管理要消失了，也不是說每個人都會變成 IC。而是說，現在每個人某種程度上都同時具備兩者，對吧？

如果你是 IC，你現在也不是一個字符一個字符手敲代碼，對吧？你其實是在管理某些東西。你在管理智能體（Agent）。你在管理那些正在發生、正在匯聚起來以完成某個目標的工作。

如果你是團隊管理者，你做的本質上也是同樣的事，只不過顆粒度不同。

我通常會看候選人當然是否真正掌握這門學科，但接下來還要看他們是否有那種品味，能在“你將擁有無限 token”這個前提下，仍然知道：我們不能只是不斷制造垃圾。你必須能夠在無限內容的世界里，分辨什么是信號，什么是噪音。

主持人：你剛才提到規劃。按照現在的發展速度，做 roadmap 規劃已經變得非常困難了。

Andrew Ambrosino：對。很多人總是因為這個對我很不滿。

主持人：對。因為事情一直在發版，一直在變化，對吧？你們團隊怎么做規劃？你們會往前看多遠？一個計劃長什么樣？是一張表格？一個 MD 文件？最終產出通常是什么？

Andrew Ambrosino：對。我不覺得我們在這件事上有什么革命性的做法。我們并沒有在規劃上耍什么聰明。

基本原則是：越短期的事情，越需要細節。任何九個月后的計劃加上的任何精確度，都是虛假的精確，只會浪費時間。

你當然可以說一些方向性的東西，對吧？但我們在 11 月能規劃到的事情——我覺得研究不太一樣，所以我這里不是代表研究團隊發言——至少在應用側、在做產品的時候，11 月制定的任何規劃，也許 12 月還成立，但后來發生的事情就完全不是那個樣子了。

所以規劃真的很難做。

我們通常需要知道的是：我們認為模型會在什么時間線具備什么能力？我在上一家公司時，就已經看到這種轉變了：我們開始用模型能力去驅動功能，而傳統產品流程就崩掉了。我們基本上只能這樣做：把我們覺得未來一兩年可能想做的所有事情全部列出來，把它們都做出原型，判斷哪些是現在就成熟可做的，然后把其他的先放在那里，繼續“燜著”。然后每次模型有新的飛躍，就把那些東西再拿出來，用新模型重新試一遍。

因為決定一個功能好不好用的根本前提，不再是它的形狀，而是模型夠不夠聰明。

Codex 應用就是個很好的例子。我非常確定：我們在 2 月發布的那個 Codex 應用，如果它在 11 月就已經準備好了，那它在市場上絕對會失敗。而這中間唯一的變量，就是模型。

同一個產品、完全相同的形態，僅僅因為時間點差了幾個月，結果就會完全不一樣。

產品的死活不再取決于它的外殼，而是在等底層的模型什么時候變聰明

主持人：這也是這檔播客里一直在反復出現的一條主線：去構建那些現在還不能真正工作，但隨著模型變強，將來就會工作的東西。與此同時還有另一條主線，就是“更有野心一點”：去做更大膽的事。

所以這是不是你們的一種工作方式？比如：我們先做很多現在可能還跑不通的東西，把它們先放在那里，等模型追上來。大致是這樣的思路嗎？

Andrew Ambrosino：對。我覺得我們有很多這樣的做法。不過有時挑戰在于，你必須再次非常明確地知道：這件事目前處于設計流程的哪個階段。

大家還是會有那種肌肉記憶：哦，我已經把這東西的代碼寫出來了，所以我們就應該把它發出去。不，不，不——這只意味著你現在有了一個產物，我們可以用它去測試未來模型的能力。

我們在應用里的 in-app browser（應用內瀏覽器）就是這樣。我們當時已經有一個“差不多能用”的版本了。甚至更早在 Atlas 里，我們就已經讓 agent 在 Atlas 里面工作了。那挺酷的。再往前，我們在 ChatGPT 里還有 Operator，對吧？那次沒有成功，但這個想法本身非常酷。

你可以在 Operator、Atlas、Codex、ChatGPT 之間畫出一條線，它們本質上是同一個功能，但僅僅是換了不同水平的智能重新發布，結果就會完全不同。

所以我會推動大家不要太固執，不要一看到“它現在不好用”，就說“這是個壞功能”。不是——它可能只是還沒到成熟的時候。

還有一點，尤其是在研究領域，總會有一種沖動：要做到最有野心，要說“好吧，如果從極限角度看，模型最終就是能把這件事做完。” 但在產品側，這種思路是不成立的。

如果你回到最初 Codex 發布的時候，本質上它其實就是“Codex web”，而且它在交互上做得并不好。它的形態是：你給模型一個任務，它會離開去做，做完后回來跟你說“finished”。聽上去也沒那么激進。問題在于，它做任務的效果其實沒那么好。

它會寫代碼，也確實不錯。但那種產品形態出現得太早了。

后來 Claude Code 出來了——完全本地運行，不接云端，也不會擺出一副那么 AGI 信仰滿滿的姿態。它會問你問題，它會停在那里，你沒法把整個人生都委托給它。結果它反而更成功，對吧？因為那正是當時模型所處的能力節點。

所以當時我們“太 AGI-pilled 了”，超前于那個時刻了。這是我經常會反復想的一課。

過去，能力和市場會共同告訴你產品該長什么樣、該如何表達。而現在情況變成了：不，你可能需要把同一個東西發六次，它才終于能工作，而它的形狀本身可能一次都不用改。

主持人：現在做產品真的要考慮太多變量了，聽你講特別有意思。你要考慮模型的發展時間線、研究進展、智能會提升到什么程度；還要考慮用戶是否已經能夠理解“原來軟件可以這樣在云端構建，這就是未來”；還要考慮你們團隊本身到底能做什么。

而我很喜歡你用 Codex 舉的這個例子，因為它又回到了“野心”這個主題。我想聽聽你對這一點還有沒有更多想法：

這些模型能做的事情，比你想象的還要多。有時它會比市場準備得更超前，市場還接不住。

但你會刻意去想這個嗎？你會不會推動團隊更有野心，因為現在去做那些過去看來難得瘋狂的事，已經容易太多了？

Andrew Ambrosino：會。這是一個核心挑戰。一旦某個產品已經存在，或者某個功能已經存在，人們就會很容易開始找紙割傷式的小問題去優化，而他們也確實應該這么做。Twitter 上的人也總會提醒我們這一點，我也感謝他們。大家確實應該關注已經存在的功能，讓它們更可靠、更好用。

但這也是為什么我們這里還保留了一種自下而上的探索文化。因為有時，就像 Codex 應用曾某種程度上對 ChatGPT 形成了“顛覆”一樣，未來也會有新的嘗試來顛覆現在這個東西。而這其實也是設計的一部分：你不可能總是讓同一個團隊，同時既擅長做顛覆性探索，又擅長維護現有產品及其質量。到了某個時候，你必須設計出一套流程，讓這兩件事都能發生。

主持人：稍微拉遠一點看，如果你回想我們一路走來的這條線——AI 如何影響我們構建產品的方式，真的太瘋狂了。就像你說的，我們過去是手工一行一行寫代碼，像工匠一樣寫人類代碼；后來變成 AI 寫 100% 的代碼；再到——你是這么描述的——現在“編碼”其實是在引導 AI。

而當你問“我有多少代碼是 AI 寫的”時，新的問題幾乎變成了：我需要把它往正確方向引導多少次？這才是新的“編碼”。

現在又有 agent、loop（循環）、還有這些各種機制。就你所見，如今人們構建產品的最前沿是什么樣？是 loops 嗎？還是別的什么？就是那些最 AI-forward 的團隊，現在到底是怎么運作的，也許很多人還沒意識到。

Andrew Ambrosino：loop 都已經是上周的事了，兄弟。

我們剛才也提過，一個很大的問題總是：“產品里有多少是 AI 寫的？” 但這個問題其實一直很難回答，因為如果你沿用去年的衡量標準，那答案就是：我們現在產品里 100% 的代碼都可以算是 AI 寫的。

所以更有意義的問題是：好，那這些代碼到底是“被監督著寫出來”的，還是“無人監督地寫出來”的？這就是完全不同的問題了。

我很歡迎“球門不斷移動”，因為這意味著我們的產品確實在進步。

我們這里已經做了很多關于 autonomously developed software（自主開發軟件）的探索——自主開發。還有很多 harness engineering（測試與約束框架工程）方向的嘗試。各種不同形態的探索。

比如說：如果 AI 每晚過來對代碼庫做一次 garbage collection（垃圾回收式清理），把它清理得更干凈，會怎樣？我覺得現在所有模型的一個共同問題是：它們通常會讓復雜度上升。請讓模型更擅長刪代碼。

但當你試圖把開發徹底切換成 autopilot（自動駕駛）時，這就會立刻變成一個問題。不時對人而言，對代碼庫本身也是。

比如功能請求，對吧？你怎么教一個模型知道哪些功能該做，哪些該忽略，哪些應該打包到一起然后稍微重新定義一下？你怎么教模型構建正確的抽象？這一切都在變好。

但我覺得我們還沒有走到這樣一個階段：說“好，我們設一個 loop，目標就是 improve the app，它去監聽 Twitter、監聽 Slack、監聽郵件，然后自己改進應用。” 我們還沒到那一步，但我們確實正在努力把它做成。

主持人：你覺得我們會到那一步嗎？你覺得會不會有一天，真的只要說一句：增長、勝利、斜杠目標、賺錢、給我做出十億美元、贏下市場——然后它就自己去實現？

Andrew Ambrosino：我不知道，兄弟。我不是那種會輕易說“永遠不會”或者“肯定會”的人。

AI 的終點不是把所有軟件塞進聊天框，而是像水一樣滲透進你習慣的所有工具里

主持人：對。那你自己作為產品負責人、工程負責人，在工作里是怎么用 AI 的？有哪些你使用它的方式，是很多人可能還沒意識到這個應用居然也可以這么用的？

Andrew Ambrosino：對。我覺得我現在擁有全世界最好的工作。

而它之所以這么有意思，其中一個原因就是：當我們最初開發 Codex 應用時，我個人的目標就是要把它做成“我拿來寫代碼的那個工具”，對吧？我當時想的是，我必須把它做得在開發這件事上足夠強大，強大到我可以用它來構建 Codex 應用本身。

而當時的 Codex 應用，本身就是一個開發工具。

我們很快形成了那個 dogfooding 閉環，因為你會有一種個人級的自我試用閉環：你會說，“哦，這件事我做不了。那我得把它修掉，這樣我才能做這件事。現在我能做這件事了。那我又能做更多事了。” 對吧？

后來我們把它發布出去，接下來的挑戰就變成了：人們開始用它做一些形狀完全不同的事，對吧？而現在我要把這個產品繼續做大，所以我需要招幾個人，我需要幫忙。于是，我自己的角色也發生了變化，同時應用本身需要承擔的角色也在變化。

于是我開始想：好，我需要在這里做更多產品探索。我需要建立更合適的 loop，來觀察每個人在做什么，來糾正那些偏離軌道的東西。突然之間，這就變成了我開始用 Codex 應用去做的事情。

我當然還寫代碼。我一直努力讓自己對它的使用方式，盡量和我們正在解決的問題保持對齊。而現在我會想：我需要做一個 spreadsheet（電子表格）來建模這個問題；我需要對這一研究方向里所有已經發生的嘗試，做一輪內部 deep research（深度研究），以服務下一個版本。

在大約 5 月份那一輪發布里，我們把應用內瀏覽器、computer use（計算機使用）、artifact creation（產物創建）帶進了 Codex 應用。我覺得那是我們“Codex 幾乎適用于所有人”的一次發布。

大家都知道 vibe coding 這個詞。我覺得那是我們第一次做了一次 vibe-coordinated release（憑感覺協調出來的發布）：我在某個 Notion 文檔里列著所有必須發生的事情，然后我在自動化收集來自 pull request、Slack 頻道的更新，自動更新狀態追蹤器。現在這已經很常見了，但在當時，我真覺得自己站在了“如何管理一次產品發布”的最前沿。

簡而言之，我使用 Codex 應用的方式基本就是：我的工作成長成什么樣了，我就推動這個工具具備完成這些事情的能力。

我每天早上起來，會先看一份 daily brief（日報簡報），它匯總了所有東西——我所在的 3000 個 Slack 頻道里，到底有哪些事情需要我注意。我可以直接對它說：“好，給我列 5 個問題，我來回答。” 然后我就可以這么做。

主持人：這個怎么搭？普通人怎么搭出這樣的工作流？因為聽起來太棒了。

Andrew Ambrosino：office 里的自動化還處于探索階段。我現在是寫了一個定時任務去遍歷我的 Slack，把那些我最關心和最重要的事情列出來，然后給它注入足夠多的判定規則和上下文。在剛跑這個任務的幾次，它確實需要不少調校。在這個應用里，我不需要去改底層的代碼，我可以直接對它說：“嘿，下次運行的時候，能不能更關注這個？” 或者“這個工作流麻煩你弱化一點。” 通過這種類似做教練一樣的方式，它就會自我迭代，更新通知我的格式。

未來的瓶頸在于，這種精巧的自動化配置，我能做，是因為我是產品研究，有大把時間去琢磨。但對普通用戶而言，你不能指望他們去鉆研這個。我們得想辦法把這個路徑抹平。

主持人：對。一個很好的例子是，我做了一個小應用，幫人過濾垃圾郵件。每封郵件進來——這個也是我用 Codex 做的——它會判斷：這是不是那種我根本不想看的 unsolicited cold email（不請自來的冷郵件）？然后給它打標簽，放到別的地方去。

而在配置這個東西時，有一步是你得進 Google Cloud Console，去設置一堆 Pub/Sub API 的東西和觸發器。我不知道你有沒有用過那個界面，真的又煩又慢，對吧？所以我就在想，等等，那我能不能讓你幫我做？于是我說，好，你替我弄這個。

Andrew Ambrosino：然后你就在描述 computer use。

主持人：我以前從沒見過有東西會在我的電腦上這么做。它會直接接管我的電腦，然后自己開始進去操作。

Andrew Ambrosino：它就像在說：“我才不管你有沒有 connector，兄弟。我直接點進去就是了。”

主持人：對。而且它真的能自己搞定。看著它自己操作，簡直太瘋狂了。

Andrew Ambrosino：在 connectors、應用內瀏覽器、以及與你的 Chrome extension 相連的方式、還有 computer use 之間，如何設計決策邊界——也就是在什么時候該用什么——這件事非常有意思，而且目前基本都是靠不斷“摸感覺”做出來的。我前幾天看到一個很棒的 Twitter thread，里面就有人把這三種模式解釋得很好，也說了它們分別適合什么場景。

主持人：所以那個人解釋得特別清楚。

Andrew Ambrosino：這些個人工作流真的很有意思，因為其中有些會非常“對味”。大家都在嘗試各種各樣的東西。每個人都在造自己的個人系統。你去問這里的每個人他們怎么用，答案都會不同。然后某些共同主題就會浮現出來，我們就會客觀地將其沉淀為應用中的一級體驗。我們不希望每個人都自己去重復造輪子，比如記憶（Memory）功能。

我們看到很多人都在費勁地自己搭 Obsidian 或者 Notion，來作為個人的“心智宮殿”，這不應該由用戶來費心。這就是我們說的基礎能力（Primitive）。我們要分辨，哪些是個體的工作習慣，哪些才是應該沉淀進底座的基礎功能。

主持人：對。這就是你前面講的那種品味和判斷力——決定這些事。

我還想多聊一點 browser-use（瀏覽器使用）這一塊，因為我覺得很多人并沒有意識到它有多強，或者它到底能拿來做什么。

這讓我想起，之前 Dan Shipper 上播客時曾預測，我們未來會直接在 Codex 應用里去承載和運行其他的 SaaS 軟件。

Andrew Ambrosino：對。

主持人：也就是說，不是去 Chrome 里——

Andrew Ambrosino：我知道。他每天都在 Slack 上給大伙發消息提各種需求。

主持人：你覺得未來真會往那個方向走嗎？我們會在 Codex 應用里直接使用 Notion、Linear、Salesforce，由你的 agent 一路輔助你？還是你覺得那其實是另一條路線？

Andrew Ambrosino：我們在應用內瀏覽器的演進上學到了很多。最初在 Electron 框架里，它的表現其實挺糟糕。所以當時定位很窄，就是個開發者調試前端的輔助工具，它不適合干別的。

后來我們全面切換到了 Atlas 的瀏覽器技術棧，實現了多標簽頁、企業級安全和網站登錄，才算進入正軌。但始終難解決的一點是：這個瀏覽器應該長成什么樣？它是只作為 Agent 快速調用的一個低延遲、可控后臺；還是我們要野心勃勃地告訴用戶，這個應用可以替代一切，它就是你的主瀏覽器。

這是兩條完全不同的路，有很大的取舍。而且因為以前沒人做過，會遇到很多非常無聊但很煩人的細節，比如快捷鍵。我們需要兼容 Chrome、VS Code 還是 Linear 自己的快捷鍵？我們需要讓用戶的肌肉記憶延續下來。

主持人：好，我們往外拉一層，聊聊你們正在把這一切帶向哪里。

Codex 的愿景是什么？它會走向哪里？一年后、兩年后、十年后，它會長成什么樣？

Andrew Ambrosino：Codex 一開始只是個 CLI。后來我們決定做這個應用，雖然當時內部有很多不確定性，但我們對它作為開發者工具的形態有很強的信念。

它不是個 IDE。它是尺寸剛剛好的界面，看著像 chatbot，但它能呈現代碼，只是我們不允許用戶在應用里直接修改代碼。

在正式發布前，我們在內部 dogfood 時就發現，工程和研究團隊對它的喜愛超出了想象，PMF 極度明確。但與此同時，我們去測試另外幾條線：既然 Codex 的代碼智能體跑通了，那財務、法務、市場是不是也能用？結果發現這些非技術人員也在瘋狂使用它。即便這個界面對他們很不友好，不停地跳出代碼和終端提示，但他們就是不肯走。

這說明“技術開發”和“通用知識工作”之間，其實沒有一道絕對的非黑即白的墻。

我們現在最核心的邏輯是：正如一個人的角色是由他做的事情的平均值決定的，產品也是。做 Excel 算賬的人不想看代碼倉庫，這很正常。但我們可以通過他的行為推斷他當前在干什么，從而靈活、自動地調整應用的復雜度，而不需要粗暴地給他們推一個完全不合腳的新界面。

我們希望這個產品能成為用戶的“工作主基地”。

它不只是在屏幕上畫一個黑色的矩形，然后逼著你把所有工作都塞進這個矩形里。它是一個你開始工作、結束工作、自動化工作的起點和終點，而在這個過程中，它會去調用任何你需要的工具。

Andrew Ambrosino：這里有個特別棒的故事。我們曾經在籌備發布素材時，攝影師 Brent 需要剪輯幾條片子。

他是直接用 Codex 剪出來的。在當時這讓我們極度震驚，因為 Codex 連視頻剪輯的 UI 都沒有。但它能理解 Premiere 的底層工程文件，通過改寫這些數據來進行基礎剪輯。在遇到改不動的地方時，Codex 甚至自己給自己寫了一個 Premiere 的專屬擴展插件并安裝了上去，通過這個插件去控制軟件內部的標記（Marker）。

這太離譜了。

它揭示了未來的兩種產品合作模式。第一種是：我們不一定要造一個比別人更好的視頻編輯器，但我們的 AI 可以像手一樣去操作和接管既有的專業軟件；第二種是：直接在 Codex 里打開現有的 Web 軟件，并在其上疊加 AI 帶來的高階能力。我們正在同時高頻地推進這兩件事。

主持人：這個 Premiere 的故事對我來說很有意思，因為它再次說明了一件事：對于這些 AI 工作，應該更有野心一點。你也許根本不知道——說不定它真的能做到這件事。某種意義上幾乎就是：去試，去試試看，看它能不能自己琢磨出來。

主持人：接下來我要帶你進入播客里的一個固定環節，叫作“失敗角落（fail corner）”。

問題是這樣的：大家看到像你這樣的人，會覺得你一路都在大殺四方，不斷成長、一路贏，Codex 表現這么好，職業路徑這么精彩，一切都在一路向上。但人們往往看不到那些沒有成功的時候，以及你推出過但失敗了的東西。

讓大家聽到這些故事非常重要——因為事情并不總是一路贏到底。

你職業生涯里，有沒有哪次失敗，給你帶來了特別重要的教訓？

Andrew Ambrosino：聽你這么描述我自己，真挺有意思。這可能是我第一次沒有感覺自己一直在失敗。

我是說，我做了很長時間創業者。最后公司其實是被拆開賣掉的，基本算是“賣零件”吧，對吧？那是很多年，整個過程非常艱難。我做的是高度監管行業。整個過程都像是一場持續不斷的失敗。

后來我去了另一家創業公司，我們在另一個同樣封閉、同樣受強監管的行業里嘗試做一些 AI 工具，那也一直是反復嘗試、反復不成功。

所以對我來說，我其實失敗過很多次。很多時候只是某個時間點上，技能、熱情、市場，剛好對齊了。

至于現在這個項目，把我們在 Codex 應用里學到的東西和 ChatGPT 結合起來，這里面我都不知道經歷了多少次微型失敗。比如我們會想：這個東西應該長成這種形狀。然后我們把它扔進 Slack，接著就會出現一個 2000 條消息的長線程，大家在里面瘋狂討論我們到底有多蠢。

這也是我喜歡 OpenAI 的地方：如果我們在內部做產品方面失敗了，人們真的會直接告訴我們。沒有人會給你留情面。也正因為如此，我們對外的產品才會這么好，因為它們都經歷過這種“2000 條消息告訴你這玩意兒真爛”的循環。

在到達今天這個位置之前，我大概失敗了 10 到 15 年。所以直到現在，我每天還是會對事情進展順利這件事感到驚訝。

主持人：我覺得這是本期節目最重要的一句格言：你可以失敗很多次，但只要在某個對的時間點技能和市場接上了，你就成了。

AI 產品正在從概念演示走向業務現場，真正的競爭也從“誰更會講故事”轉向“誰更能落地”。

7 月 17-18 日，2026 奇點智能產品大會將在北京金隅喜來登酒店舉辦，圍繞 Agent 智能體、企業級 AI、AI 原生組織、具身智能、軟件生產力、多模態產品、人機協同與行業應用落地等核心議題，邀請 40+ 一線產業實踐者，共同拆解 AI 產品從 0 到 1、從 Demo 到規模化應用的真實路徑。