Andrew Ambrosino 是 OpenAI Codex 團隊負責人。設計師出身，做過工程師，也做過產品，還創過業，現在負責的 Codex 週活躍用戶已經超過 500 萬。他大概是當下最適合回答「AI 時代產品該怎麼做」的人之一。
在他看來，當公司裡幾乎每個人都能快速搭出一個功能原型，真正的難題就不再是「能不能做出來」，而是「該不該做這個」。
在與 Lenny 的對談中，Andrew Ambrosino 詳細介紹了 OpenAI 內部的開發流程：當實現成本被 AI 大幅壓縮後，產品開發的每一個環節，從立項、文檔、原型、設計到角色分工、團隊協作、產品規劃，都在發生變化。哪些舊規則在失效？哪些新標準正在成形？當實現不再稀缺，什麼才是真正稀缺的資源？
一些核心觀點：
當 90 個人都能做出 90 個看起來能上線的產品原型時，最寶貴的是 taste。
Codex 團隊招人的硬標準之一是品味，能從海量內容中分辨訊號與噪音。在一個「擁有無限 tokens」的世界裡，他們不想生產垃圾內容。
Codex 如果早三個月發布會徹底失敗，唯一的變量是模型進步了。不要輕易判定一個功能不好，它可能只是還沒到時候。
一個功能最終是否足夠好，前提往往不是功能本身的型態，而是模型到底夠不夠聰明。
就像 Codex 曾顛覆 ChatGPT 一樣，Codex 也可能被新的嘗試顛覆。要保留自下而上的探索文化，不能指望同一個團隊既打磨細節又顛覆自己。
以下是對談的精華內容。
實現的成本降低了， taste 就變得更重要了
Lenny：你說過 AI 正在改變產品工作的型態。你現在在可能是全球最前沿的 AI 產品團隊工作。具體來說，產品團隊的工作方式和兩年前比有什麼變化？
Andrew Ambrosino： 現在作為一個團隊負責人，最難的事情就是流程倒過來了。
過去怎麼做產品，大家都很熟悉：先調研、出想法、做原型。即使我們早就過了瀑布式開發時代，底層邏輯還是一樣的，實現是昂貴的。所以你要在實現之前，通過文檔、調研、原型把所有風險提前排除。因為原型和設計比開發便宜，這是過去的基本假設。
現在這個假設完全變了，任何人都可以做出任何東西。我真的相信，你從零開始跟這些模型對話，不管是我們的模型還是其他公司的，你都能搭出你想要的任何功能。這不一定是軟體開發中最難的部分，但確實很酷。
你給人們無限的 tokens，OpenAI 的每個人都很有主動性、都有好想法。所以每個人都在做各種各樣的東西。現在公司裡有個我們急需做的功能，我確信同時有 90 個不同的、沒有協調過的小團隊在各自實現和嘗試。在那 90 個嘗試裡，哪些是好的？應該把哪些部分折疊到其他方面？應該怎麼定義它？它應該是另一個功能的一部分嗎？開關裡應該有幾個選項？是這些事情。
所以簡短的答案就是：倒過來了。不是人們在做根本不同的角色，也不是技能消失了、角色不存在了。實現不再是最貴的部分了，我斗膽說一句，最貴的是品味（taste）。
Lenny：所以以前大家會寫 PRD、策略文檔，現在大家直接做原型。公司裡很多人有類似的想法，就出現了 90 個不同的東西，然後從中選方向？
Andrew Ambrosino： 是的，這種事情大量發生。不只是在 OpenAI，你已經看到很多產品負責人說「PRD 已死，原型當道」，但我實際上完全不同意這個觀點。
因為實現在每個媒介上都變得便宜了，跳過思考直接做原型就變得非常誘人。尤其是如果你不是工程師，如果你從來沒寫過代碼、沒有興趣或者沒有時間，你就會忍不住說：「PRD 已死，讓我直接給你看我想要什麼。」
但我也注意到一個反過來的現象。對工程師來說，寫大量文檔反而變得很誘人，大量不值得讀的文檔。這不是在說寫文檔的人不好，而是說當實現變得充裕時，選對你要表達觀點的格式，變得真正重要了。
如果你要表達的是一個模糊領域的產品清晰度，那可能確實應該寫文檔。如果你想讓人們上手試用、壓力測試一個交互模式，那就做原型。關鍵是選對媒介。
Lenny：有個概念叫 primal mark（原始標記），畫家在畫布上落的第一筆，後面所有東西都從那一筆延伸出來。你的意思是，有時候原型是錯誤的第一筆？因為大家會錨定在上面，而不是去想更大的方案？
Andrew Ambrosino： 對。過去有一種隱含的信號，一個東西看起來像什麼樣子，就意味著它處於流程的什麼階段。如果你看到一個東西看起來像正式上線的產品，那意味著它已經是後期了，風險已經被排除了、設計看過了、商業目標是合理的。
現在這些東西脫鉤了。原因是過去要獲得資源來構建，你得先充分降低風險，現在這個門檻沒了。所以一個本來只是探索階段的東西，看起來已經可以上線了，視覺上它已經準備好了。但它可能根本不是正確的方向，不符合調研結論，不是用戶真正需要的，也不是對業務最優的選擇。
不是要過度強調品味這件事。但再說一次，知道該做什麼、怎麼呈現、怎麼達成目標、用什麼媒介，這正在成為每個領域裡最重要的能力。
Lenny：品味這個詞現在是個流行詞。具體來說，你說的「好的品味」到底是什麼？
Andrew Ambrosino： 品味得拆開來看。
確實有審美的部分，但也有系統思維的部分，這個東西在整個系統裡怎麼放；有方向性的部分，我們要去哪、這件事是哪個主題的一部分；有表達的部分，怎麼呈現這個資訊；還有一部分品味是交互層面的，這個動畫不符合它要傳達的語義，它太急促了，跟它要表達的含義不匹配。
這些確實非常重要，但真正的品味問題是，如果我們什麼都能做，目標是什麼？怎麼到達那裡？
Lenny：當 AI 越來越強、做越來越多的事，人類大腦在哪些地方會繼續有價值？品味感覺是其中之一。但 AI 的設計產出還是不太行，為什麼頂尖模型做不好設計？
Andrew Ambrosino： 有一些實際原因，也有一些更難解決的問題。設計比軟體更難評分，創建一個反饋循環來訓練模型什麼是好設計，比訓練代碼能不能編譯要繁瑣得多，因為人的品味是反饋機制的一部分。
另外，實驗室歷史上優先讓模型擅長能加速 AI 研究的東西。模型能寫正確代碼顯然能加速研究，設計就沒法做同樣的論證。不是說設計不重要，而是它不在那個飛輪裡。
這些是實際原因，它們會消失。模型會在設計上變得相當好，但有一些更難搞的東西。
第一，設計有文化屬性。你還記得去年每個新網站都在抄 Linear 的設計。如果模型每次都輸出 Linear 的網站，那不是挑戰所在。設計中新穎性的重要程度，遠高於軟體工程。軟體工程你恨不得模型完全按已知模式來，但設計需要一定的隨機性和新穎性。
第二，是視覺設計和代碼之間的相互作用。如果明天公司換品牌，淺層的做法是逐個更新 263 個元件。深層的做法是理解這兩個看起來不一樣的東西，其實都屬於一個列表樣式，傳達的是同一種交互模式。這個抽象層，目前的技術還夠不到。
Lenny：Jenny Wen（Anthropic Claude Code 設計負責人）說設計流程已經死了，直接構建就好，你怎麼看？
Andrew Ambrosino： 我跟 Jenny 在很多事上可能是一致的。正規的設計流程，我同意她說的，它死了。而且我在 AI 之前就不是那個流程的粉絲。
多年前我做創業公司的時候，有篇文章叫「案例研究工廠」，說的就是設計師被訓練去遵循一套固定流程，並且逐漸把這套流程本身看得比結果更重要。如果一個東西經過了這個流程，就會默認得到兩個結論：第一，它會是好的，流程保證了品質；第二，即使沒人用，它也是好的，因為它走了流程。
用戶調研、發散、收斂，框架是對的，但一直有點學術化。那個流程的前提是實現很貴，你只造得起一次，所以必須在做之前窮盡所有問題空間和方案空間。
後來 Figma 和 Origami 出現了，我們把交互原型拉進了流程。現在的問題是，你可以把全部實現拉到流程的最前面。一個完全精致的原型，看起來可以直接上線。公司裡足夠多的人看到之後就問：「我們現在能發嗎？」但實際上，你們還處於早期設計探索階段，只是沒人明說。
所以說設計流程死了，既對又不對。如果你綁定在特定工具和特定日常操作上，那它確實死了。但「我們現在處於流程的哪個階段」這個認知，比以往任何時候都更重要。
把設計流程綁定在特定媒介上，那才是危險的地方。設計師現在有更多工具了，你可以把東西直接放進現有產品裡，可以做 A/B 測試。很多公司都有產品的 baby 版本，baby Cursor、baby Codex，一個大幅簡化的代碼庫，能模擬正式產品的所有交互。你可以拿它來 vibe code（氛圍編程），說「如果側邊欄變成這樣呢？如果彈出一個面板呢？」這是設計師的新工具，但它需要配合舊的認知：你現在在流程的哪個位置。
崗位和角色在融合，但 PM 不會消失
Lenny：很多公司在說「角色消亡」。你覺得 PM、工程師、設計師的分工會徹底消失嗎？
Andrew Ambrosino：一些公司很喜歡趕潮流，走極端。消滅角色概念的危險在於，它可能同時消滅掉「這些領域是有可以學習的最佳實踐的專業」這一認知。
我聽到很多公司說「我們要取消產品角色」，我覺得這是個很糟糕的主意，然後說「每個人都是 builder」。結果是產品管理這個已經積累了真正最佳實踐、真正踩過坑的學科，被直接拋棄了。因為有人寫了幾行代碼，就覺得萬事大吉了，那可不是個好狀態。
我歡迎「這不是你的領域、你不能碰」這種邊界消失，但需要平衡。不是每個人都能做所有事，不論是從廣度還是深度來說，這也是為什麼管理者不會消失。
而且每個學科都有技能成分。很多工程師不承認這一點，覺得工程是有技能的，其他崗位角色都是「氛圍」。不是這樣的，你會用 Excel 不代表你能去財務團隊工作。
我覺得現在發生的更多是，人們跨角色協作變得更容易了，學習其他領域最佳實踐也變得更容易了，不用把你在某個角色上的效率跟使用特定工具的能力綁在一起了。
我花了很多時間覺得自己不應該做軟體工程師，因為我不關心組合語言，也不想記住 TypeScript 的類型系統。這些角色一直存在一些門檻，彷彿「做好這個角色等於熟練掌握這個工具」。我覺得這正開始消解，但人們把它誇大了。
Lenny：你們 Codex 團隊裡確實有更多角色融合，具體是什麼樣的？
Andrew Ambrosino： 我們在 Codex 團隊裡，確實看到了比公司其他團隊和其他行業更多的角色融合。部分原因在於，這是一個面向工程師的技術產品。所以我們的設計師說工程師的語言，我們的產品經理說技術語言、會寫代碼。
我們內部有一種描述協作方式的說法：如今角色之間的重疊比過去大得多。定義一個人，不再是看「設計到哪裡結束、工程從哪裡開始」這樣的職責邊界，而是看他所有工作內容的平均分佈。
如果把設計團隊裡某個人做的所有事情攤開來看，其中可能包含大量寫代碼的工作，也包含大量產品相關的工作。但把這些工作取一個「平均值」，他最終仍然會落在某個更偏設計的區域。
Lenny：你提到產品經理的工作更像 zone defense（區域防守），具體是什麼意思？
Andrew Ambrosino： 如果兩個產品經理合作得過於緊密，通常不是一個好信號。你更應該像力導向佈局那樣把團隊展開來看，哪裡存在空缺，哪裡還沒人覆蓋？
在今天這個世界裡，策展、引導和對齊變成了最重要的工作。每個人都在不斷拋出想法，整個環境充滿噪聲，過去那種自上而下、按年度制定計劃的方式已經行不通了。我們需要有人作為品味的把關者，引導一件事從概念走向產品，而這意味著你必須覆蓋公司的各個角落。
所以，你需要把團隊舖開來看，誰擅長什麼？讓彼此保持一定距離，確保覆蓋面足夠全面。然後再去填補缺口，比如：「我們想招一位產品思維很強的工程師。」我們不希望出現這樣的情況，一群人先寫出大量代碼，最後還需要整個產品團隊來審核和校準產品的一致性。我們希望每個人都具備這些能力，只是各自深入鑽研的方向需要發生變化。
Lenny：所以現在最有價值的人，是能從想法到完成全程推動、並且有品味知道「這個很棒」的人？
Andrew Ambrosino： 對，我覺得這就是當下最核心的變化。這也反映了我對 IC（個人貢獻者）和管理者關係的理解。不是說管理會消失，也不是說每個人都只是 IC，而是現在每個人在某種程度上同時承擔著這兩種角色。
如果你是 IC，你已經不再是一個字符一個字符地敲代碼。你其實是在管理某些東西，管理 agents，管理那些被組織起來共同完成任務的工作。如果你是團隊管理者，本質上做的也是同樣的事，只不過管理的粒度不同。
我通常尋找的人，除了具備紮實的專業能力之外，還必須有品味。因為在一個「擁有無限 tokens」的世界裡，我們不能生產垃圾內容。你必須具備從海量內容中分辨信號與噪音的能力。
每次有人問 Codex 團隊有多少人，我的回答都是：「大概在 10 到幾千人之間。」聽起來像句玩笑話，但實際上，所有人的工作都會匯聚到這個產品裡，模型研究、瀏覽器使用、模型人格、前端基礎設施、用戶體驗，這些都構成了產品的一部分。
但與此同時，我們也不是每天都在接收幾千個人提交的 PR（代碼提交請求）。團隊有兩位數規模的工程師，設計師數量大約是工程師的一半，再加上幾位產品經理，絕大多數人都是 IC。團隊的影響範圍很大，但管理層級並不厚。這裡有很多曾經創辦過公司的人，也有很多在大公司裡以「創始人心態」做事的人，還有許多品味極佳的人。
整個 Codex 應用都是被 dogfooding 的循環塑造出來的。我們所有人都有一种共同的願望，盡可能多地在應用裡完成自己的工作，即便它暫時還不是最好的工具，因為只有這樣，它最終才有機會成為最好的工具。我們經常會刻意不去改進某些內部流程，而是讓產品自己變得更好，從而能夠支撐這些流程。這其實是一种非常不舒服的狀態。但一周又一周地，它確實在持續發生變化。
Codex 早發三個月會死，唯一區別是模型進步了
Lenny：在事情變化這麼快的節奏下，你們怎麼做規劃？看多遠？
Andrew Ambrosino： 我們在規劃上有什麼革命性的做法。基本原則就是，越接近當下的事情，規劃就需要越具體。不是不做九個月的計劃，而是那個計劃必須保持非常模糊。因為你現在在九個月計劃上加的任何精度，都是虛假精度，只會浪費時間。
在應用產品這邊，你在 11 月能規劃的東西，到 12 月可能還是對的，但到了 2 月就完全不是那回事了。
在我上一家公司，當我們開始基於模型能力來驅動功能開發時，原有的產品流程基本上崩潰了。後來變成了把所有感興趣的方向都列出來，給它們做原型，判斷哪些現在已經可行，然後把其他的暫時擱置。每當模型能力出現新的躍升，就把那些擱置的東西重新拿出來再試一遍。因為一個功能最終是否足夠好，前提往往不是功能本身的型態，而是模型到底夠不夠聰明。很多人一直對我的規劃方式感到不滿。但這件事確實非常難。
Lenny：有沒有一個具體的例子說明時機有多重要？
Andrew Ambrosino： 關於 Codex 有個很好的故事。我非常確定，我們 2 月發布的那個 Codex 應用，如果在 11 月準備好了就發布，它會在市場上徹底失敗。唯一的區別就是 11 月到 2 月之間模型進步了。 同一個產品，完全相同的型態，結果完全不同，就差幾個月。
Lenny：所以現在不行的東西以後可能行？要保持更大的野心？
Andrew Ambrosino： 對。我推薦人們不要輕易認定「這個東西現在不行，所以它就是個壞功能」，它可能只是還沒到時候。
回到 Codex 最初的發布，Codex web。基本上你給模型一個任務，它去幹，幹完了回來給你結果。聽起來不激進，但問題是它幹得不夠好，那個型態太超前了。
然後 Claude Code 出來了，完全本地化，不連雲端，不假裝自己多 AGI。它會問你問題，會在那裡等著，你不能把整個人生委託給它。它好用太多了，因為它匹配了當時模型的能力水平。
我們當時太「AGI 了」，我經常想這個教訓。過去，一個產品在市場上的失敗，往往能告訴你很多關於產品型態或溝通方式的問題。現在不一樣了，你可能需要把同一個東西發布六次，直到它成功，型態可能完全不變。
應用內瀏覽器也是這樣的情況。我們曾經有一個可以工作的版本，回到 Atlas 時期，我們就已經有 agent 在瀏覽器裡執行任務了。再往前是 ChatGPT 裡的 Operator，那個沒成功。但如果把 Operator、Atlas、Codex 和 ChatGPT 串起來看，你會發現它們之間其實可以畫出一條連續的演進路線。本質上是同一個功能，只是隨著智能水平的變化，被不斷重新發布，而結果也因此徹底改變。
一旦一個產品或功能已經存在，人們很容易把注意力放在各種細節問題和微優化上，而且他們確實應該這麼做。但這也是為什麼我們始終保留一种自下而上的探索文化。因為有時候，就像 Codex 應用曾以某種方式顛覆 ChatGPT 一樣，Codex 自己未來也可能被新的嘗試所顛覆。你不能指望同一個團隊既持續產出顛覆性的創新，又始終專注於產品品質和細節打磨。在某個階段，你必須設計出一種機制，讓這兩種能力能夠同時存在。
Lenny：Codex 的願景是什麼？你要把它帶到哪裡？
Andrew Ambrosino： 今年 1 月和 2 月，我們在內部自用測試的過程中發現工程和研究工作流上形成了很清晰的 PMF。但同時，市場、傳播、財務、法務的人也都在用 Codex，哪怕這個應用對他們來說並不友好，它會給他們展示代碼，讓他們批准命令行搜索工具的執行。
我們試過把 Codex 的能力加到其他產品裡，ChatGPT 桌面應用、Atlas 瀏覽器。結果最煩人的事情發生了，沒人願意離開 Codex 應用，去用那些據說專門為他們打造的產品。
這給我們的啟發是，開發者工具和通用知識工作工具之間，其實存在很多微妙的共通之處。我們確實相信，我們正在構建的這種產品型態，是承載各種深度垂直場景的正確型態。從簡單開始，再根據需要逐步增加複雜度。
它不是那種「在螢幕上畫一個矩形，然後所有事情都必須在裡面完成」的產品。更像一個大本營，你在這裡開始工作、結束工作、管理自動化流程，而它會調用你所需要的一切工具。有人把這種型態稱作「super app」，我真希望他們當時沒這麼叫，因為現在我幾乎每天都得聽到這個詞。
Dan Shipper 有個很有意思的想法，他覺得未來我們會在 Codex 裡面「由內而外」地使用 SaaS 工具，Notion、Linear、Salesforce 都不是你去瀏覽器裡打開的，而是 agent 在 Codex 裡幫你操作的。我們也確實在做這些，應用內瀏覽器、Chrome 擴展、computer use，所有這些都是讓 Codex 能跟外部工具交互的方式。
一個最好的例子，我們內部的視頻製作人 Brent 用 Codex 剪輯了 Codex 的發布視頻。Codex 不是視頻編輯器，沒有那些 UI。但它理解 Brent 在用 Premiere Pro，能通過編輯 Premiere Pro 背後的文件做一些修改。當它發現不能做所有事的時候，它自己寫了一個 Premiere Pro 擴展插件，安裝到 Premiere Pro 裡，然後通過這個插件跟 Premiere Pro 對話。看到這個的時候我們都震驚了。
這是一個很好的模式，有專業工具做專業的事。Codex 不需要成為更好的視頻編輯器，它能無縫地跟專業工具交互就行了。
會寫代碼不重要了，會刪代碼才重要
Lenny：從手寫代碼到 AI 寫 100% 的代碼，再到現在的 agents 和循環。最前沿的團隊現在到底怎麼工作？
Andrew Ambrosino： Loops（循環）？那是上周的事了。
我們一直在討論「產品有多少比例是 AI 寫的代碼」這個問題。用去年的標準來看，我們現在 100% 的代碼都是 AI 寫的。所以問題不再是「多少是 AI 寫的」，而是「代碼是在監督下寫的還是無監督寫的」，這是一個完全不同的維度。我歡迎這種標準不斷被刷新，因為這意味著我們在取得產品進展。
我們在自主開發軟體方面做了很多探索，比如大量的 harness engineering，比如「如果模型在夜裡自動做代碼庫的垃圾回收和清理呢？」
但目前所有模型都有一個問題，它們總是在增加複雜度。如果做研究的人在聽：拜託，讓模型學會刪代碼吧。 當你嘗試把開發完全交給自動駕駛的時候，這就成了一個嚴重的問題，不管是在人的層面還是在代碼庫的層面。
Feature requests（功能請求）也是如此。你該如何教會模型判斷哪些功能值得做、哪些應該被忽略、哪些應該合併後重新定義？又該如何教會模型構建正確的抽象？
這些能力都在持續進步。但我並不認為我們已經發展到這樣一個階段，設置一個循環，讓模型自動「改進應用」，持續監聽 Twitter、Slack 和郵件，然後自主完成迭代。雖然，我們確實正在嘗試把這件事變成現實。
Lenny：你覺得我們會到那一步嗎？就是設置一個目標：「贏」？
Andrew Ambrosino：「/goal 給我賺十億美元。」我不知道。我不會說永遠不會或者永遠會怎樣。
Lenny：你作為產品和工程負責人，自己是怎麼用 AI 工作的？
Andrew Ambrosino： 我覺得我現在可能擁有世界上最好的工作。
一開始做 Codex 的時候，我個人的目標就是讓它好到我可以用它來寫 Codex 的代碼。那是一個超級緊密的自用產品循環，我不能做某件事，那就修好它，然後我能做了，然後能做更多的事。
後來我的角色變了。我需要做更多產品發現、搞清楚團隊在做什麼、糾正偏離方向的東西。於是 Codex 變成了我做這些事的工具。「幫我建一個電子表格把這些數據整理出來。」「幫我做一個內部深度調研，看看過去在這個方向上做過哪些探索。」
5 月的一系列發布，應用內瀏覽器、計算機使用（computer use）、工件創建（artifact creation），那是我們第一次用 vibe coordination（氛圍式協調）管理發布。我有一個 Notion 文檔記錄所有待辦事項，然後用 Codex 自動去 PR、Slack 頻道收集進展，更新狀態跟踪器，當時覺得這是管理產品發布方式的最前沿。
現在我每天早上起來，會看 Codex 幫我生成的日報，從我加入的 3000 個 Slack 頻道裡篩選出需要我關注的事。我可以回覆說「給我五個問題，我來回答」。它會自我調整，我說「下次跑的時候，少關注這個工作流」或者「這件事發生了但沒出現在日報裡，確保以後能抓到」，它會更新通知方式、調整關注重點。
Lenny：這怎麼設置的？工作流是什麼？
Andrew Ambrosino： 現在還在發現階段。就是做一個定時任務：「過一遍我的 Slack 頻道，這些是我關心的事情，按這些分類整理，這裡有些上下文。」頭幾次跑可能需要引導。好在我不需要去找怎麼編輯指令，我直接對話說「下次幫我改一下這個」，它就更新了。
但我覺得這也是聊天機器人型態的核心問題，我知道怎麼設置，因為對我來說這就是產品發現。但如果你不在 OpenAI 工作、不在開發這個東西，你不會想去搞清楚這些。我們需要想清楚怎麼讓這些對普通人也能用的型態。
Lenny：我自己也用 Codex 做了一個過濾垃圾郵件的自動化。其中一步要去 Google Cloud 控制台設置一堆 API 觸發器，那個界面特別煩。我就讓 Codex 幫我做，它直接接管了我的電腦，用計算機使用功能操作。
Andrew Ambrosino： 它就是：「我不管你有沒有連接器，老兄，我直接開始點擊。」
如何劃分連接器、應用內瀏覽器、Chrome 擴展以及計算機使用之間的邊界，是一件非常有意思的事情。很多時候，這些邊界其實都是憑感覺摸索出來的。
我覺得這些個人工作流特別有意思。大家都在嘗試各種各樣的東西，每個人都會搭建出完全不同的系統。但慢慢地，一些共同模式會浮現出來。然後我們就會意識到：「這個應該成為產品裡的一級體驗。」
比如記憶（memory），很多人在設置 Obsidian 知識庫或 Notion 空間來構建自己的心智宮殿。你不應該需要自己做這個，應該有一個足夠通用的記憶功能替你做。我們一直在篩選，什麼對個人有效但應該留在個人層面、什麼應該進入產品成為基礎元件。
Lenny：外面的人看到的都是你在贏。但肯定有事情沒成功過的時候？
Andrew Ambrosino： 聽你這麼描述挺搞笑的。這其實是我第一次覺得自己沒在失敗。
我之前創業做了很多年，最後基本上是把公司拆了賣掉的。在高度監管的行業裡做，整個過程就像持續的失敗。後來去了另一家創業公司，在另一個封閉的受管制行業裡做 AI 工具，也是一次又一次地不行。我實際上失敗了很多。有時候只是一個時間點，技能、熱情和市場窗口恰好對齊了。
就算是現在這個把 Codex 和 ChatGPT 結合的項目裡，也有數不清的小失敗。我們說「應該長這樣」，發到 Slack 裡，下面就是 2000 條消息說我們有多蠢。這是我喜歡 OpenAI 的地方，人們會直接告訴我們，對內部產品的失敗毫不留情，這也是為什麼外部產品做得不錯。我在到達現在這個位置之前，失敗了大約 10 到 15 年。所以我每天都還覺得有點驚訝，事情竟然在順利進行。
Lenny：對讀者有什麼最後的建議？
Andrew Ambrosino： 不要和你現在的工作流程「綁定終身」。真正應該堅持的，是那些只有你能夠獨特交付的成果。然後，持續嘗試改變你的流程。如果你最引以為豪的技能是「我最懂 Figma 的 auto layout（自動佈局）」，那你在幹什麼？AI 也會變得比你更好。找到值得做的事，然後想辦法去做那些事。
54.44萬 熱度
417萬 熱度
16.81萬 熱度
12.19萬 熱度
92.19萬 熱度
Codex 負責人：「所有人都是 builder」是個很糟糕的主意
Andrew Ambrosino 是 OpenAI Codex 團隊負責人。設計師出身，做過工程師，也做過產品，還創過業，現在負責的 Codex 週活躍用戶已經超過 500 萬。他大概是當下最適合回答「AI 時代產品該怎麼做」的人之一。
在他看來，當公司裡幾乎每個人都能快速搭出一個功能原型，真正的難題就不再是「能不能做出來」，而是「該不該做這個」。
在與 Lenny 的對談中，Andrew Ambrosino 詳細介紹了 OpenAI 內部的開發流程：當實現成本被 AI 大幅壓縮後，產品開發的每一個環節，從立項、文檔、原型、設計到角色分工、團隊協作、產品規劃，都在發生變化。哪些舊規則在失效？哪些新標準正在成形？當實現不再稀缺，什麼才是真正稀缺的資源？
一些核心觀點：
當 90 個人都能做出 90 個看起來能上線的產品原型時，最寶貴的是 taste。
Codex 團隊招人的硬標準之一是品味，能從海量內容中分辨訊號與噪音。在一個「擁有無限 tokens」的世界裡，他們不想生產垃圾內容。
Codex 如果早三個月發布會徹底失敗，唯一的變量是模型進步了。不要輕易判定一個功能不好，它可能只是還沒到時候。
一個功能最終是否足夠好，前提往往不是功能本身的型態，而是模型到底夠不夠聰明。
就像 Codex 曾顛覆 ChatGPT 一樣，Codex 也可能被新的嘗試顛覆。要保留自下而上的探索文化，不能指望同一個團隊既打磨細節又顛覆自己。
以下是對談的精華內容。
實現的成本降低了， taste 就變得更重要了
Lenny：你說過 AI 正在改變產品工作的型態。你現在在可能是全球最前沿的 AI 產品團隊工作。具體來說，產品團隊的工作方式和兩年前比有什麼變化？
Andrew Ambrosino： 現在作為一個團隊負責人，最難的事情就是流程倒過來了。
過去怎麼做產品，大家都很熟悉：先調研、出想法、做原型。即使我們早就過了瀑布式開發時代，底層邏輯還是一樣的，實現是昂貴的。所以你要在實現之前，通過文檔、調研、原型把所有風險提前排除。因為原型和設計比開發便宜，這是過去的基本假設。
現在這個假設完全變了，任何人都可以做出任何東西。我真的相信，你從零開始跟這些模型對話，不管是我們的模型還是其他公司的，你都能搭出你想要的任何功能。這不一定是軟體開發中最難的部分，但確實很酷。
你給人們無限的 tokens，OpenAI 的每個人都很有主動性、都有好想法。所以每個人都在做各種各樣的東西。現在公司裡有個我們急需做的功能，我確信同時有 90 個不同的、沒有協調過的小團隊在各自實現和嘗試。在那 90 個嘗試裡，哪些是好的？應該把哪些部分折疊到其他方面？應該怎麼定義它？它應該是另一個功能的一部分嗎？開關裡應該有幾個選項？是這些事情。
所以簡短的答案就是：倒過來了。不是人們在做根本不同的角色，也不是技能消失了、角色不存在了。實現不再是最貴的部分了，我斗膽說一句，最貴的是品味（taste）。
Lenny：所以以前大家會寫 PRD、策略文檔，現在大家直接做原型。公司裡很多人有類似的想法，就出現了 90 個不同的東西，然後從中選方向？
Andrew Ambrosino： 是的，這種事情大量發生。不只是在 OpenAI，你已經看到很多產品負責人說「PRD 已死，原型當道」，但我實際上完全不同意這個觀點。
因為實現在每個媒介上都變得便宜了，跳過思考直接做原型就變得非常誘人。尤其是如果你不是工程師，如果你從來沒寫過代碼、沒有興趣或者沒有時間，你就會忍不住說：「PRD 已死，讓我直接給你看我想要什麼。」
但我也注意到一個反過來的現象。對工程師來說，寫大量文檔反而變得很誘人，大量不值得讀的文檔。這不是在說寫文檔的人不好，而是說當實現變得充裕時，選對你要表達觀點的格式，變得真正重要了。
如果你要表達的是一個模糊領域的產品清晰度，那可能確實應該寫文檔。如果你想讓人們上手試用、壓力測試一個交互模式，那就做原型。關鍵是選對媒介。
Lenny：有個概念叫 primal mark（原始標記），畫家在畫布上落的第一筆，後面所有東西都從那一筆延伸出來。你的意思是，有時候原型是錯誤的第一筆？因為大家會錨定在上面，而不是去想更大的方案？
Andrew Ambrosino： 對。過去有一種隱含的信號，一個東西看起來像什麼樣子，就意味著它處於流程的什麼階段。如果你看到一個東西看起來像正式上線的產品，那意味著它已經是後期了，風險已經被排除了、設計看過了、商業目標是合理的。
現在這些東西脫鉤了。原因是過去要獲得資源來構建，你得先充分降低風險，現在這個門檻沒了。所以一個本來只是探索階段的東西，看起來已經可以上線了，視覺上它已經準備好了。但它可能根本不是正確的方向，不符合調研結論，不是用戶真正需要的，也不是對業務最優的選擇。
不是要過度強調品味這件事。但再說一次，知道該做什麼、怎麼呈現、怎麼達成目標、用什麼媒介，這正在成為每個領域裡最重要的能力。
Lenny：品味這個詞現在是個流行詞。具體來說，你說的「好的品味」到底是什麼？
Andrew Ambrosino： 品味得拆開來看。
確實有審美的部分，但也有系統思維的部分，這個東西在整個系統裡怎麼放；有方向性的部分，我們要去哪、這件事是哪個主題的一部分；有表達的部分，怎麼呈現這個資訊；還有一部分品味是交互層面的，這個動畫不符合它要傳達的語義，它太急促了，跟它要表達的含義不匹配。
這些確實非常重要，但真正的品味問題是，如果我們什麼都能做，目標是什麼？怎麼到達那裡？
Lenny：當 AI 越來越強、做越來越多的事，人類大腦在哪些地方會繼續有價值？品味感覺是其中之一。但 AI 的設計產出還是不太行，為什麼頂尖模型做不好設計？
Andrew Ambrosino： 有一些實際原因，也有一些更難解決的問題。設計比軟體更難評分，創建一個反饋循環來訓練模型什麼是好設計，比訓練代碼能不能編譯要繁瑣得多，因為人的品味是反饋機制的一部分。
另外，實驗室歷史上優先讓模型擅長能加速 AI 研究的東西。模型能寫正確代碼顯然能加速研究，設計就沒法做同樣的論證。不是說設計不重要，而是它不在那個飛輪裡。
這些是實際原因，它們會消失。模型會在設計上變得相當好，但有一些更難搞的東西。
第一，設計有文化屬性。你還記得去年每個新網站都在抄 Linear 的設計。如果模型每次都輸出 Linear 的網站，那不是挑戰所在。設計中新穎性的重要程度，遠高於軟體工程。軟體工程你恨不得模型完全按已知模式來，但設計需要一定的隨機性和新穎性。
第二，是視覺設計和代碼之間的相互作用。如果明天公司換品牌，淺層的做法是逐個更新 263 個元件。深層的做法是理解這兩個看起來不一樣的東西，其實都屬於一個列表樣式，傳達的是同一種交互模式。這個抽象層，目前的技術還夠不到。
Lenny：Jenny Wen（Anthropic Claude Code 設計負責人）說設計流程已經死了，直接構建就好，你怎麼看？
Andrew Ambrosino： 我跟 Jenny 在很多事上可能是一致的。正規的設計流程，我同意她說的，它死了。而且我在 AI 之前就不是那個流程的粉絲。
多年前我做創業公司的時候，有篇文章叫「案例研究工廠」，說的就是設計師被訓練去遵循一套固定流程，並且逐漸把這套流程本身看得比結果更重要。如果一個東西經過了這個流程，就會默認得到兩個結論：第一，它會是好的，流程保證了品質；第二，即使沒人用，它也是好的，因為它走了流程。
用戶調研、發散、收斂，框架是對的，但一直有點學術化。那個流程的前提是實現很貴，你只造得起一次，所以必須在做之前窮盡所有問題空間和方案空間。
後來 Figma 和 Origami 出現了，我們把交互原型拉進了流程。現在的問題是，你可以把全部實現拉到流程的最前面。一個完全精致的原型，看起來可以直接上線。公司裡足夠多的人看到之後就問：「我們現在能發嗎？」但實際上，你們還處於早期設計探索階段，只是沒人明說。
所以說設計流程死了，既對又不對。如果你綁定在特定工具和特定日常操作上，那它確實死了。但「我們現在處於流程的哪個階段」這個認知，比以往任何時候都更重要。
把設計流程綁定在特定媒介上，那才是危險的地方。設計師現在有更多工具了，你可以把東西直接放進現有產品裡，可以做 A/B 測試。很多公司都有產品的 baby 版本，baby Cursor、baby Codex，一個大幅簡化的代碼庫，能模擬正式產品的所有交互。你可以拿它來 vibe code（氛圍編程），說「如果側邊欄變成這樣呢？如果彈出一個面板呢？」這是設計師的新工具，但它需要配合舊的認知：你現在在流程的哪個位置。
崗位和角色在融合，但 PM 不會消失
Lenny：很多公司在說「角色消亡」。你覺得 PM、工程師、設計師的分工會徹底消失嗎？
Andrew Ambrosino：一些公司很喜歡趕潮流，走極端。消滅角色概念的危險在於，它可能同時消滅掉「這些領域是有可以學習的最佳實踐的專業」這一認知。
我聽到很多公司說「我們要取消產品角色」，我覺得這是個很糟糕的主意，然後說「每個人都是 builder」。結果是產品管理這個已經積累了真正最佳實踐、真正踩過坑的學科，被直接拋棄了。因為有人寫了幾行代碼，就覺得萬事大吉了，那可不是個好狀態。
我歡迎「這不是你的領域、你不能碰」這種邊界消失，但需要平衡。不是每個人都能做所有事，不論是從廣度還是深度來說，這也是為什麼管理者不會消失。
而且每個學科都有技能成分。很多工程師不承認這一點，覺得工程是有技能的，其他崗位角色都是「氛圍」。不是這樣的，你會用 Excel 不代表你能去財務團隊工作。
我覺得現在發生的更多是，人們跨角色協作變得更容易了，學習其他領域最佳實踐也變得更容易了，不用把你在某個角色上的效率跟使用特定工具的能力綁在一起了。
我花了很多時間覺得自己不應該做軟體工程師，因為我不關心組合語言，也不想記住 TypeScript 的類型系統。這些角色一直存在一些門檻，彷彿「做好這個角色等於熟練掌握這個工具」。我覺得這正開始消解，但人們把它誇大了。
Lenny：你們 Codex 團隊裡確實有更多角色融合，具體是什麼樣的？
Andrew Ambrosino： 我們在 Codex 團隊裡，確實看到了比公司其他團隊和其他行業更多的角色融合。部分原因在於，這是一個面向工程師的技術產品。所以我們的設計師說工程師的語言，我們的產品經理說技術語言、會寫代碼。
我們內部有一種描述協作方式的說法：如今角色之間的重疊比過去大得多。定義一個人，不再是看「設計到哪裡結束、工程從哪裡開始」這樣的職責邊界，而是看他所有工作內容的平均分佈。
如果把設計團隊裡某個人做的所有事情攤開來看，其中可能包含大量寫代碼的工作，也包含大量產品相關的工作。但把這些工作取一個「平均值」，他最終仍然會落在某個更偏設計的區域。
Lenny：你提到產品經理的工作更像 zone defense（區域防守），具體是什麼意思？
Andrew Ambrosino： 如果兩個產品經理合作得過於緊密，通常不是一個好信號。你更應該像力導向佈局那樣把團隊展開來看，哪裡存在空缺，哪裡還沒人覆蓋？
在今天這個世界裡，策展、引導和對齊變成了最重要的工作。每個人都在不斷拋出想法，整個環境充滿噪聲，過去那種自上而下、按年度制定計劃的方式已經行不通了。我們需要有人作為品味的把關者，引導一件事從概念走向產品，而這意味著你必須覆蓋公司的各個角落。
所以，你需要把團隊舖開來看，誰擅長什麼？讓彼此保持一定距離，確保覆蓋面足夠全面。然後再去填補缺口，比如：「我們想招一位產品思維很強的工程師。」我們不希望出現這樣的情況，一群人先寫出大量代碼，最後還需要整個產品團隊來審核和校準產品的一致性。我們希望每個人都具備這些能力，只是各自深入鑽研的方向需要發生變化。
Lenny：所以現在最有價值的人，是能從想法到完成全程推動、並且有品味知道「這個很棒」的人？
Andrew Ambrosino： 對，我覺得這就是當下最核心的變化。這也反映了我對 IC（個人貢獻者）和管理者關係的理解。不是說管理會消失，也不是說每個人都只是 IC，而是現在每個人在某種程度上同時承擔著這兩種角色。
如果你是 IC，你已經不再是一個字符一個字符地敲代碼。你其實是在管理某些東西，管理 agents，管理那些被組織起來共同完成任務的工作。如果你是團隊管理者，本質上做的也是同樣的事，只不過管理的粒度不同。
我通常尋找的人，除了具備紮實的專業能力之外，還必須有品味。因為在一個「擁有無限 tokens」的世界裡，我們不能生產垃圾內容。你必須具備從海量內容中分辨信號與噪音的能力。
每次有人問 Codex 團隊有多少人，我的回答都是：「大概在 10 到幾千人之間。」聽起來像句玩笑話，但實際上，所有人的工作都會匯聚到這個產品裡，模型研究、瀏覽器使用、模型人格、前端基礎設施、用戶體驗，這些都構成了產品的一部分。
但與此同時，我們也不是每天都在接收幾千個人提交的 PR（代碼提交請求）。團隊有兩位數規模的工程師，設計師數量大約是工程師的一半，再加上幾位產品經理，絕大多數人都是 IC。團隊的影響範圍很大，但管理層級並不厚。這裡有很多曾經創辦過公司的人，也有很多在大公司裡以「創始人心態」做事的人，還有許多品味極佳的人。
整個 Codex 應用都是被 dogfooding 的循環塑造出來的。我們所有人都有一种共同的願望，盡可能多地在應用裡完成自己的工作，即便它暫時還不是最好的工具，因為只有這樣，它最終才有機會成為最好的工具。我們經常會刻意不去改進某些內部流程，而是讓產品自己變得更好，從而能夠支撐這些流程。這其實是一种非常不舒服的狀態。但一周又一周地，它確實在持續發生變化。
Codex 早發三個月會死，唯一區別是模型進步了
Lenny：在事情變化這麼快的節奏下，你們怎麼做規劃？看多遠？
Andrew Ambrosino： 我們在規劃上有什麼革命性的做法。基本原則就是，越接近當下的事情，規劃就需要越具體。不是不做九個月的計劃，而是那個計劃必須保持非常模糊。因為你現在在九個月計劃上加的任何精度，都是虛假精度，只會浪費時間。
在應用產品這邊，你在 11 月能規劃的東西，到 12 月可能還是對的，但到了 2 月就完全不是那回事了。
在我上一家公司，當我們開始基於模型能力來驅動功能開發時，原有的產品流程基本上崩潰了。後來變成了把所有感興趣的方向都列出來，給它們做原型，判斷哪些現在已經可行，然後把其他的暫時擱置。每當模型能力出現新的躍升，就把那些擱置的東西重新拿出來再試一遍。因為一個功能最終是否足夠好，前提往往不是功能本身的型態，而是模型到底夠不夠聰明。很多人一直對我的規劃方式感到不滿。但這件事確實非常難。
Lenny：有沒有一個具體的例子說明時機有多重要？
Andrew Ambrosino： 關於 Codex 有個很好的故事。我非常確定，我們 2 月發布的那個 Codex 應用，如果在 11 月準備好了就發布，它會在市場上徹底失敗。唯一的區別就是 11 月到 2 月之間模型進步了。 同一個產品，完全相同的型態，結果完全不同，就差幾個月。
Lenny：所以現在不行的東西以後可能行？要保持更大的野心？
Andrew Ambrosino： 對。我推薦人們不要輕易認定「這個東西現在不行，所以它就是個壞功能」，它可能只是還沒到時候。
回到 Codex 最初的發布，Codex web。基本上你給模型一個任務，它去幹，幹完了回來給你結果。聽起來不激進，但問題是它幹得不夠好，那個型態太超前了。
然後 Claude Code 出來了，完全本地化，不連雲端，不假裝自己多 AGI。它會問你問題，會在那裡等著，你不能把整個人生委託給它。它好用太多了，因為它匹配了當時模型的能力水平。
我們當時太「AGI 了」，我經常想這個教訓。過去，一個產品在市場上的失敗，往往能告訴你很多關於產品型態或溝通方式的問題。現在不一樣了，你可能需要把同一個東西發布六次，直到它成功，型態可能完全不變。
應用內瀏覽器也是這樣的情況。我們曾經有一個可以工作的版本，回到 Atlas 時期，我們就已經有 agent 在瀏覽器裡執行任務了。再往前是 ChatGPT 裡的 Operator，那個沒成功。但如果把 Operator、Atlas、Codex 和 ChatGPT 串起來看，你會發現它們之間其實可以畫出一條連續的演進路線。本質上是同一個功能，只是隨著智能水平的變化，被不斷重新發布，而結果也因此徹底改變。
一旦一個產品或功能已經存在，人們很容易把注意力放在各種細節問題和微優化上，而且他們確實應該這麼做。但這也是為什麼我們始終保留一种自下而上的探索文化。因為有時候，就像 Codex 應用曾以某種方式顛覆 ChatGPT 一樣，Codex 自己未來也可能被新的嘗試所顛覆。你不能指望同一個團隊既持續產出顛覆性的創新，又始終專注於產品品質和細節打磨。在某個階段，你必須設計出一種機制，讓這兩種能力能夠同時存在。
Lenny：Codex 的願景是什麼？你要把它帶到哪裡？
Andrew Ambrosino： 今年 1 月和 2 月，我們在內部自用測試的過程中發現工程和研究工作流上形成了很清晰的 PMF。但同時，市場、傳播、財務、法務的人也都在用 Codex，哪怕這個應用對他們來說並不友好，它會給他們展示代碼，讓他們批准命令行搜索工具的執行。
我們試過把 Codex 的能力加到其他產品裡，ChatGPT 桌面應用、Atlas 瀏覽器。結果最煩人的事情發生了，沒人願意離開 Codex 應用，去用那些據說專門為他們打造的產品。
這給我們的啟發是，開發者工具和通用知識工作工具之間，其實存在很多微妙的共通之處。我們確實相信，我們正在構建的這種產品型態，是承載各種深度垂直場景的正確型態。從簡單開始，再根據需要逐步增加複雜度。
它不是那種「在螢幕上畫一個矩形，然後所有事情都必須在裡面完成」的產品。更像一個大本營，你在這裡開始工作、結束工作、管理自動化流程，而它會調用你所需要的一切工具。有人把這種型態稱作「super app」，我真希望他們當時沒這麼叫，因為現在我幾乎每天都得聽到這個詞。
Dan Shipper 有個很有意思的想法，他覺得未來我們會在 Codex 裡面「由內而外」地使用 SaaS 工具，Notion、Linear、Salesforce 都不是你去瀏覽器裡打開的，而是 agent 在 Codex 裡幫你操作的。我們也確實在做這些，應用內瀏覽器、Chrome 擴展、computer use，所有這些都是讓 Codex 能跟外部工具交互的方式。
一個最好的例子，我們內部的視頻製作人 Brent 用 Codex 剪輯了 Codex 的發布視頻。Codex 不是視頻編輯器，沒有那些 UI。但它理解 Brent 在用 Premiere Pro，能通過編輯 Premiere Pro 背後的文件做一些修改。當它發現不能做所有事的時候，它自己寫了一個 Premiere Pro 擴展插件，安裝到 Premiere Pro 裡，然後通過這個插件跟 Premiere Pro 對話。看到這個的時候我們都震驚了。
這是一個很好的模式，有專業工具做專業的事。Codex 不需要成為更好的視頻編輯器，它能無縫地跟專業工具交互就行了。
會寫代碼不重要了，會刪代碼才重要
Lenny：從手寫代碼到 AI 寫 100% 的代碼，再到現在的 agents 和循環。最前沿的團隊現在到底怎麼工作？
Andrew Ambrosino： Loops（循環）？那是上周的事了。
我們一直在討論「產品有多少比例是 AI 寫的代碼」這個問題。用去年的標準來看，我們現在 100% 的代碼都是 AI 寫的。所以問題不再是「多少是 AI 寫的」，而是「代碼是在監督下寫的還是無監督寫的」，這是一個完全不同的維度。我歡迎這種標準不斷被刷新，因為這意味著我們在取得產品進展。
我們在自主開發軟體方面做了很多探索，比如大量的 harness engineering，比如「如果模型在夜裡自動做代碼庫的垃圾回收和清理呢？」
但目前所有模型都有一個問題，它們總是在增加複雜度。如果做研究的人在聽：拜託，讓模型學會刪代碼吧。 當你嘗試把開發完全交給自動駕駛的時候，這就成了一個嚴重的問題，不管是在人的層面還是在代碼庫的層面。
Feature requests（功能請求）也是如此。你該如何教會模型判斷哪些功能值得做、哪些應該被忽略、哪些應該合併後重新定義？又該如何教會模型構建正確的抽象？
這些能力都在持續進步。但我並不認為我們已經發展到這樣一個階段，設置一個循環，讓模型自動「改進應用」，持續監聽 Twitter、Slack 和郵件，然後自主完成迭代。雖然，我們確實正在嘗試把這件事變成現實。
Lenny：你覺得我們會到那一步嗎？就是設置一個目標：「贏」？
Andrew Ambrosino：「/goal 給我賺十億美元。」我不知道。我不會說永遠不會或者永遠會怎樣。
Lenny：你作為產品和工程負責人，自己是怎麼用 AI 工作的？
Andrew Ambrosino： 我覺得我現在可能擁有世界上最好的工作。
一開始做 Codex 的時候，我個人的目標就是讓它好到我可以用它來寫 Codex 的代碼。那是一個超級緊密的自用產品循環，我不能做某件事，那就修好它，然後我能做了，然後能做更多的事。
後來我的角色變了。我需要做更多產品發現、搞清楚團隊在做什麼、糾正偏離方向的東西。於是 Codex 變成了我做這些事的工具。「幫我建一個電子表格把這些數據整理出來。」「幫我做一個內部深度調研，看看過去在這個方向上做過哪些探索。」
5 月的一系列發布，應用內瀏覽器、計算機使用（computer use）、工件創建（artifact creation），那是我們第一次用 vibe coordination（氛圍式協調）管理發布。我有一個 Notion 文檔記錄所有待辦事項，然後用 Codex 自動去 PR、Slack 頻道收集進展，更新狀態跟踪器，當時覺得這是管理產品發布方式的最前沿。
現在我每天早上起來，會看 Codex 幫我生成的日報，從我加入的 3000 個 Slack 頻道裡篩選出需要我關注的事。我可以回覆說「給我五個問題，我來回答」。它會自我調整，我說「下次跑的時候，少關注這個工作流」或者「這件事發生了但沒出現在日報裡，確保以後能抓到」，它會更新通知方式、調整關注重點。
Lenny：這怎麼設置的？工作流是什麼？
Andrew Ambrosino： 現在還在發現階段。就是做一個定時任務：「過一遍我的 Slack 頻道，這些是我關心的事情，按這些分類整理，這裡有些上下文。」頭幾次跑可能需要引導。好在我不需要去找怎麼編輯指令，我直接對話說「下次幫我改一下這個」，它就更新了。
但我覺得這也是聊天機器人型態的核心問題，我知道怎麼設置，因為對我來說這就是產品發現。但如果你不在 OpenAI 工作、不在開發這個東西，你不會想去搞清楚這些。我們需要想清楚怎麼讓這些對普通人也能用的型態。
Lenny：我自己也用 Codex 做了一個過濾垃圾郵件的自動化。其中一步要去 Google Cloud 控制台設置一堆 API 觸發器，那個界面特別煩。我就讓 Codex 幫我做，它直接接管了我的電腦，用計算機使用功能操作。
Andrew Ambrosino： 它就是：「我不管你有沒有連接器，老兄，我直接開始點擊。」
如何劃分連接器、應用內瀏覽器、Chrome 擴展以及計算機使用之間的邊界，是一件非常有意思的事情。很多時候，這些邊界其實都是憑感覺摸索出來的。
我覺得這些個人工作流特別有意思。大家都在嘗試各種各樣的東西，每個人都會搭建出完全不同的系統。但慢慢地，一些共同模式會浮現出來。然後我們就會意識到：「這個應該成為產品裡的一級體驗。」
比如記憶（memory），很多人在設置 Obsidian 知識庫或 Notion 空間來構建自己的心智宮殿。你不應該需要自己做這個，應該有一個足夠通用的記憶功能替你做。我們一直在篩選，什麼對個人有效但應該留在個人層面、什麼應該進入產品成為基礎元件。
Lenny：外面的人看到的都是你在贏。但肯定有事情沒成功過的時候？
Andrew Ambrosino： 聽你這麼描述挺搞笑的。這其實是我第一次覺得自己沒在失敗。
我之前創業做了很多年，最後基本上是把公司拆了賣掉的。在高度監管的行業裡做，整個過程就像持續的失敗。後來去了另一家創業公司，在另一個封閉的受管制行業裡做 AI 工具，也是一次又一次地不行。我實際上失敗了很多。有時候只是一個時間點，技能、熱情和市場窗口恰好對齊了。
就算是現在這個把 Codex 和 ChatGPT 結合的項目裡，也有數不清的小失敗。我們說「應該長這樣」，發到 Slack 裡，下面就是 2000 條消息說我們有多蠢。這是我喜歡 OpenAI 的地方，人們會直接告訴我們，對內部產品的失敗毫不留情，這也是為什麼外部產品做得不錯。我在到達現在這個位置之前，失敗了大約 10 到 15 年。所以我每天都還覺得有點驚訝，事情竟然在順利進行。
Lenny：對讀者有什麼最後的建議？
Andrew Ambrosino： 不要和你現在的工作流程「綁定終身」。真正應該堅持的，是那些只有你能夠獨特交付的成果。然後，持續嘗試改變你的流程。如果你最引以為豪的技能是「我最懂 Figma 的 auto layout（自動佈局）」，那你在幹什麼？AI 也會變得比你更好。找到值得做的事，然後想辦法去做那些事。