PRD並未過時，AI只是改變產品的工作形態。
智東西7月1日消息，6月28日，Lenny播客最新一期訪談，對話OpenAI Codex產品與工程負責人安德魯·安布羅西諾（Andrew Ambrosino），討論AI正在如何重塑軟體產品的生產方式，諸多觀點值得產品和研發從業者參考。
Codex作為OpenAI旗下的AI程式設計工具，是近一年來該公司活躍使用者數量增長最快的產品之一。近半年來，其使用量增長6倍，周活躍使用者超500萬。
而Andrew則是Codex產品桌面應用開發的負責人同時也是OpenAI的技術團隊的一員。他曾擔任過設計師、軟體工程師，早年還是YC明星金融創業公司Catch的創始人，身兼CEO、CTO、產品負責人多職。
Andrew指出，隨著大模型降低實現成本，軟體開發的核心瓶頸正從“寫出功能”轉向“做出取捨”。在OpenAI內部，同一需求可能同時出現大量平行原型，而產品團隊的主要工作變為篩選與整合，而非實現本身。
他認為，在這一變化下，“品味”成為關鍵能力，包括定義做什麼、如何組織系統以及如何表達產品形態。而傳統以PRD（產品需求文件）與瀑布流程為中心的開發方式正在被解構，文件與原型的作用轉向按問題類型選擇使用。
同時，Andrew透露OpenAI約90%員工正在使用Codex，覆蓋工程及非技術崗位，其外部周活已超過500萬，AI正在從程式設計工具擴展為跨職能的通用工作入口。
以下是本次訪談的核心要點：
1、Codex周活超500萬，超過90%OpenAI員工在用：自2026年1月至今，Codex使用量增長6倍，周活躍使用者超500萬。OpenAI內部90%員工每週使用，涵蓋工程、市場、財務、法務等崗位。
2、產品開發流程倒置：以前是“寫文件→研究→原型→實現”（因為實現貴），現在是“實現成本趨近於零，任何人都能做出任何東西”OpenAI內部一個功能可能有90個不同團隊同時在搞原型。
3、最核心的能力變成“品味”：實現不值錢了，值錢的是“判斷做什麼”、怎麼做好“品味”，哪些功能該合併、用什麼媒介傳遞資訊、什麼才是使用者真正需要的。
4、AI做不好設計的三個原因：設計比程式碼難評分；模型訓練缺乏設計反饋回路；設計需要“新穎性”，而AI擅長學習已有模式。
5、角色正在坍塌：設計師寫程式碼、PM寫程式碼、工程師做產品設計。OpenAI不設固定角色標籤，按“技術成員”劃分，你的角色就是你花時間做的那些事。
6、Codex目標是成為最好的桌面應用：Codex的願景不只是開發者工具，目標是成為“最好的桌面應用”，能寫程式碼、整理檔案、做資料分析、讀郵件、操作瀏覽器，一個應用覆蓋所有知識工作。
7、失敗過10-15年才找到成功：Andrew創業10-15年一直在失敗，直到Codex才找到成功。他給的建議是：“不要固守你的流程，固守你能交付的結果。”
以下是對訪談全程內容的編譯（為最佳化閱讀體驗智東西做了不改變原意的編輯）：
Lenny：OpenAI 90%的人都在用Codex。
Andrew：不是90%的工程師，是90%的整個公司。
Lenny：你前幾天發了條推文，說你想讓Codex成為有史以來最好的桌面應用。
Andrew：對。Codex的質量門檻必須足夠高，高到你在打開這個應用做下一件事的時候不會有任何猶豫，它就是你自然而然的選擇。就像人們現在習慣去打開一個瀏覽器標籤一樣。
Lenny：是的。我知道不斷有資料出來，說你們創下了各種使用量紀錄。
Andrew：我不太確定。再說吧。反正挺多人喜歡這個應用的。
Lenny：你覺得為什麼AI和那些最前沿的模型就是做不好設計？
Andrew：我覺得設計更難評分，因為人類審美的那部分是反饋機制中必需的。用目前的技術來達成那一點，還是有點遙不可及。
Lenny：現在產品團隊的形態跟幾年前相比，是什麼樣的？
Andrew：OpenAI的每個人都非常有主動性，都有很好的想法，所以每個人都在做所有的事。並不是說人們在扮演根本不同的角色，或者專注於不同的事情。而是說現在的流程是倒過來的。實現不再是昂貴的部分了，我敢說，昂貴的是“品味”。
Lenny：你覺得會有這樣一種“坍塌”到來嗎，就是每個人都變成全能型選手，那就是未來？還是你覺得我們還是會主要保持職能分工？
Andrew：有一些事情我是擔心的。我聽說很多公司說我們要取消產品這個角色，每個人都將成為一個“建構者”，然後會發生的是……
01. Andrew：AI時代，產品開發流程已經倒過來了
Lenny：我們在準備這次聊天的時候，我問你你最想讓大家從這次對話中得到什麼，你說的是AI如何改變產品工作的形態。你工作在可能是最前沿的AI軟體團隊。所以你對未來的方向、對其他團隊一兩年後會走到哪裡，有一個非常有趣的視角。那麼現在產品團隊的形態跟幾年前相比，是什麼樣的？
Andrew：現在最難的事情之一，作為一個領導者在建構這些產品時，就是流程的倒置。我想很多人都討論過這一點，就是現在任何人都可以建構任何東西。
我現在確實相信，從零開始，如果你跟這些模型對話，我們的也好，別人的也好，你確實可以搭建出你想要的任何功能。這並不是軟體開發中困難的部分，但這確實很酷。而我認為這創造了一個環境，讓人們可以做所有這些東西。你給人們無限的token。
OpenAI的每個人都非常有主動性，都有很好的想法，所以每個人都在做所有的事。而你看我們運行了很多年的產品流程，它一直是有點相反的，對吧？
它一直是研究、構思，也許有一些原型，但即使我們過了瀑布式開發階段，它還是帶有一種“實現是昂貴的，所以你需要在前面通過文件、通過研究、通過原型來去風險化，因為原型和設計更便宜”的假設。這個假設現在已經變了。現在，我敢肯定，對於某個我們急需做的功能，有90個不同的、沒有協調的團隊在各自實現和嘗試？
所以簡短的回答是，流程是倒過來的。並不是說人們在做根本不同的角色，或者關注不同的事情，也不是說技能消失了，或者角色就這麼沒了。而是流程倒過來了，實現不再是昂貴的部分了，我敢說，昂貴的是品味。
但它是策劃的過程，是那90次嘗試中，哪些是好的？哪些應該融入到其他方面？應該怎麼框定這件事？它應該屬於那個功能的一部分嗎？開關裡應該有幾個分段？。
Lenny：“品味”這個詞已經被說爛了。我想回頭再說這個。關於那90個原型的想法，太有意思了。所以我想確認一下我理解得對不對。OpenAI內部有一個想法在流傳。人們以前的做法是寫文件。
Andrew：對。
Lenny：我們要建構什麼，功能是什麼，策略是什麼，PRD。現在你描述的，完全說得通，人們直接建立一個原型。你是說公司裡不同的人有類似的想法，現在他們不寫文件了，而是建立自己的小原型，這就導致了90個不同的東西，大家可以看看，也許從中選一個方向。是這個意思嗎？
Andrew：這種事兒很多。你已經看到很多產品負責人說PRD已死，原型為王。但我完全不相信這個。我認為現在發生的一件有趣的事情是，因為實現的成本在每一個媒介上都變得非常便宜，直接跳到一個原型是非常誘人的，尤其是如果你不是工程師，如果你從來沒有寫過程式碼，或者從來沒有興趣，或者從來沒有時間，說“PRD已死，讓我直接給你看我的意思”是非常誘人的，對吧？
但我也注意到，對於工程師來說，寫很多文件也是非常誘人的，很多不值得讀的文件。這不是在貶低寫文件的人。而是說如果實現是充裕的，那麼為你想要表達的觀點選擇正確的格式就變得非常重要。
如果那個觀點是在一個模糊區域的產品清晰度，那它可能確實需要一份文件。如果你要做的是把東西放到人們手裡去試用、去壓力測試一個互動模式，那它就是原型。但我覺得現在有趣的一點是，選擇正確的媒介變得非常重要。
Lenny：有一個術語，之前一位播客嘉賓分享過，我聽到你說這個的時候就想到了，叫做“原始標記”。當設計師、畫家或藝術家在一幅畫或一件藝術品上做出第一個標記時，那個標記就是你開始回應的東西，一切都會從你做的第一個標記開始延伸。
所以聽到你說的，有時候原型不是應該做的第一件事，因為那樣你就會只是對這個原型做出反應，而不是對一個不同的想法或者一個更大的想法做出反應。我很喜歡聽到這個。所以不是像大家說的“不再寫文件了，不再寫PRD了”。你說的是它們在特定場景下仍然有用。
Andrew：對。我覺得還有一點是，在以前的世界裡，媒介本身就隱含了很多訊號，表明某件事在流程中的位置。所以如果你看到某樣東西感覺像是在生產環境中的應用，那就意味著它在流程的後期，假設已經被去風險了，設計已經看過了，這是一個好的商業目標。而現在這些東西被解耦了。之所以以前是這樣，是因為在事情被恰當去風險之前，很難獲得資源去建構它。現在這已經完全過時了。
所以我認為非常重要的是要說，我們可以有原型，我們可以有文件，但我們是否清楚這個東西是做什麼的？因為正如你所說，你不想過度錨定在某個本應是探索性的東西上，但它現在看起來已經這麼像生產就緒了，視覺上已經準備好上線了，但它並不是研究方向的正確模型，也不是使用者真正需要的，也不是對業務最有利的。
不是要過度強調品味這件事，但還是一樣，品味——知道做什麼，如何呈現資訊，如何達成目標，用什麼媒介——正在成為最重要的事情。在所有領域都是如此。
02. AI時代，真正稀缺的是“品味”
Lenny：當你談“品味”的時候，你說的好品味是什麼？是你描述的那種決定“這就是我們要投入的事情”嗎？還是說當你有了一個東西之後，判斷“這個對嗎？這個東西能發佈嗎？”當你想到好品味、好判斷的時候，具體來說是什麼？
Andrew：對。挺有意思的。我在網上刷太多了。有一條推文，好像是昨天的，他們用了Paul Graham的例子，說Paul Graham顯然有好品味，但他穿著cargo shorts，對吧？所以我們得把品味的意思稍微拆解一下。這裡面有很多細微差別。我覺得你剛才提到的那些都是其中一部分。
有審美的部分，但也有系統思考的部分，這個東西怎麼融入整個系統？還有我們往哪裡走，這個主題是什麼？怎麼呈現它？很多都是更廣泛的上下文。當然，品味中也有部分是“這個互動動畫在語義意義上不匹配它所試圖傳達的意思”，對吧？它太跳了，和它要表達的意思不符。這非常重要，我可能過度關注這個了。
但是，還有那種“這個東西應該是什麼樣的？如果我們什麼都能造，那目標是什麼？我們怎麼到達那裡？”——我覺得那才是真正品味的問題所在。
Lenny：當我聽到這些的時候，我總是在想，隨著AI越來越強，能做越來越多的工作，人類的大腦還會在哪些地方繼續保持價值？感覺品味是其中一部分。我在這條線上思考的另一點是，AI在真正的設計上仍然非常糟糕。AI的輸出並不好。
Andrew：對。
Lenny：很少能說“就是它了，他們做到了”。而且總是“哦，這是Claude設計，這是Codex設計”。你覺得為什麼AI和最前沿的模型在今天就是做不好設計？你覺得它們最終能達到那個水平嗎？你覺得我們會達到一個“天哪，我們不用再幹了”的狀態嗎？
Andrew：對。我覺得有一些實際的原因導致它滯後了，也有一些更難解決的問題。我不是研究團隊的，我這麼說肯定會被罵的。我覺得設計比軟體更難評分。建立一個反饋回路來訓練模型什麼是好設計、什麼是壞設計，比“程式碼能不能編譯”“它能不能做該做的事”要繁瑣和繁重得多，因為人類審美的那部分是反饋機制中必需的。
我也認為實驗室歷史上更傾向於讓模型擅長那些能加速AI研究的事情。在編碼模型的早期階段，很明顯模型能夠寫出正確的程式碼會加速研究，對吧？而對於設計，你不能真正提出同樣的理由。不是說擅長設計不重要，而是它不直接在那個飛輪裡，對吧？這些是實際的原因，而且這些會消失的——這些模型會在設計上變得相當好。但有一些更模糊的東西會非常棘手。我列了一個簡短的清單。
一是，什麼被認為是好設計，其中有一部分是文化性的。你還記得嗎，大概是去年，每一個新出來的網站都只是Linear網站的複製品。Linear的網站設計很好，品味很好。如果一個模型能做到那樣，我會說“哇，這真是巨大的飛躍”。
如果我有一個模型每次都輸出Linear的網站，那挑戰不在於此。在設計中有一種“新穎性”的成分，它實際上比在軟體工程中更重要。軟體工程中你幾乎希望它過度偏向已知的模式，對吧？而設計不一樣，它需要一些隨機性和新穎性。
二是，對我來說，我花了很多時間寫程式碼，或者在早期Codex應用上監督程式碼，即使模型在設計中變得很好，也存在一個抽象層，是軟體設計和正在寫的程式碼之間的互動。
這邊角落裡的這個東西應該在程式碼庫中與下面的這個東西共享某些內容。這和“模型需要成為一個更好的設計師”是有點不同的，尤其是在視覺方面，但它要深得多。這是關於抽象層的。
比如，如果明天我們公司做了品牌重塑，淺層版本是我們得一個一個更新263個元件。深層版本是，這兩個看起來不同的東西之間的語義——它們都在列表中，擁有某種樣式，向使用者傳達某種互動模式。我覺得在目前的技術下，那個抽象層還是有點遙不可及的，對吧？
所以我認為，當我們經歷這個過程的時候，我們11月開始做Codex應用，一開始我們沒有全職使用它，現在我們用它來做所有事情，這個過程是一段旅程，但現在我們在使用它的時候實際做的事情已經不一樣了。所以問題是什麼來著？
Lenny：沒有，那個回答非常精彩。說到設計和創意，Codex應用剛出來的時候，它是一個全新的東西。以前沒人見過。它不是終端，不是IDE。它是一個能寫程式碼的聊天介面，你還能看到程式碼。聽你這麼說，感覺AI很難“給出一個全新的編碼範式”。而這似乎就是人類大腦目前仍然有價值的地方——幾乎是創造力，想出新的東西，而不是從已有事物的模式中生成。
Andrew：對。我完全同意。讓我們暫時為人類大腦鼓掌。
03. AI沒有殺死設計流程 只是重構了它
Lenny：在我們準備這次對話的時候，你說你在聽Jenny的那一期節目，她是Claude Code和Claude Cowork的設計負責人。她有一個觀點是設計流程已死。沒有時間做設計了，事情發展太快了，直接建構，然後設計在事情推進的過程中引導方向。你暗示你對設計流程有不同的看法。
Andrew：我和Jenny可能在這方面有很多共識。我不是“設計流程本尊”的粉絲。我同意她的觀點，它確實死了。而且在AI之前我就真的不喜歡這個流程。
Lenny：你能快速描述一下那個流程嗎？讓大家知道你說的是什麼。
Andrew：幾年前我創辦一家初創公司的時候，我們做設計招聘，有一篇有點諷刺的文章出來了，關於案例研究工廠的。那是mid-syrup時代的東西。
設計師被教這個流程，並且把它看得高於一切，甚至高於結果。如果某樣東西經過了那個流程，那就兩件事是成立的：一是它會是好的，流程能保證質量和影響力；二是如果某樣東西經過了那個流程，即使你不喜歡它、沒人用它，它也是好的。流程就是使用者研究、發散、收斂。框架是對的，但一直有點學術化。
但我認為這確實暴露了它的短板，尤其是因為實現的速度。而且，再一次，那個流程是建立在“實現是昂貴的，你只能負擔得起建構一次”的假設之上的。所以你需要在實現之前徹底地遍歷問題空間和解決方案空間，對吧？然後我們看到了，像Figma、Origami和所有這些工具，你可以通過把互動原型提前拉到流程中來加速一些洞察，對吧？
你可以模擬生產環境，就是高管們會說“我們能不能做一個原型”，然後期望它能直接工作，對吧？但這東西是真的。這成為了設計流程本尊的一部分。我們把原型拉進了流程裡。
現在的問題是你可以把所有實現都拉進去。在很多假設之間存在不匹配。你看到一個完全打磨好的原型，看起來已經可以發佈了，公司裡有足夠多的人看到它，他們會說“我們現在能發佈這個嗎？”
但實際上我們還在早期設計流程階段，只是沒人說出來，對吧？這就是我們現在的情況，像多人探索一樣。90個人會有這個想法，它會看起來很精緻，但實際上這就是現在的設計流程。把設計流程和媒介繫結在一起，這是可怕的部分。
設計師現在有更多的工具來做這個流程，對吧？你可以把東西放到當前產品中，你可以做AB測試，或者就把它當原型用。很多公司現在都有“產品嬰兒版”的想法，比如Baby Cursor。你在Twitter上見過這個，我們有Baby Codex，對吧？一個大幅簡化的程式碼庫，模擬了生產應用的所有互動，因此在上面進行vibe coding要快得多。
因為你可以說，“如果側邊欄這樣工作會怎樣？”或者“如果一個面板進來，在這裡有一個群聊會怎樣？”“如果XYZ會怎樣？”這是一個巨大的工具，是設計流程的一部分。
所以說設計流程已死，我覺得既對也不對。如果你繫結的是舊的工具、舊的規格、舊的那套日常具體流程，那它確實死了，你會過得很不舒服。但把整個流程扔掉，或者把流程那種“我們在這個階段”的框架扔掉，那比以往任何時候都更重要。
Lenny：這真的很有意思，因為你有各個職能的背景。如果大家看你的領英，上面寫著工程師、設計師、產品經理、創始人。現在你負責桌面應用，而且設計不在你的管轄範圍內，對吧？是有獨立的設計團隊，還是他們在你下面？
Andrew：看每週情況吧。
Lenny：好的。
Andrew：我們合作非常緊密。我們相信大家一起坐在一起、嵌入彼此。匯報線什麼的，我不知道。
Lenny：他們每週都在變。Codex的設計流程是什麼樣的？
Andrew：關於角色坍塌、存在性角色坍塌已經寫了很多了。沒有什麼角色了。我們沒有看到那種情況。我們在Codex組織內看到的角色坍塌比公司其他部門和經濟其他部門要多。我認為部分原因是這是一個面向工程師的技術產品，所以我們的設計師懂工程師的語言，我們的產品經理懂技術語言、會寫程式碼。Alexander有電腦科學碩士學位，而我沒有。所以我們看到了很多角色坍塌。
我覺得我們描述團隊協作方式的一種方式是，角色之間的重疊比過去多得多。每個人不再是由“設計在哪裡停止、工程從哪裡開始”的邊界來定義，而是由他們工作的平均位置來定義。
如果你把設計團隊每個人做的事情平均一下，有很多程式碼相關的工作，有很多產品相關的工作，但平均來看，他們的點在這邊。如果你把它畫成圖的話。
這也跟流程有關。尤其是因為Codex應用的整個開發都是由內部自測（dogfooding）循環驅動的。我們所有人都有一個願望，就是儘可能多地在這個應用裡做事，即使它不是最好的工具，這樣它才能成為最好的工具。
所以很多設計是我們所有人通過使用這個應用來完成的，然後說“這個哪裡有問題？”我們經常做的一件事是我們不改進流程，而是為了讓產品變得更好而去做它，這是一個非常不舒服的處境。但每週都在變化。
Lenny：我特別喜歡你提出的這個觀點：你的角色就是你花時間做的事情的平均值。如果你大部分時間都在做PM的工作，那你現在就是PM。如果是工程，那你現在就是工程師。你覺得是OpenAI第一個把員工叫做“技術成員”的嗎？
Andrew：不是，我相信這可能是從Xerox開始的。我實習的第一家公司，叫Upthere，也是這麼叫的。這個概念一直存在，但現在更常見了。這確實是研究型公司的一個傳統，對吧？
Lenny：好的。它從研究領域出來，但我覺得這可能是未來方向的一個訊號——我們就叫每個人“技術成員”，你的職能不是固定的，你不是被框在PM或設計或工程的格子裡。你覺得長遠來看我們都會走向那個方向嗎？
你覺得職能會繼續存在嗎？仍然有PM的技能、工程的技能、設計的技能，人們會說“我是設計師”。還是你覺得會出現一種“坍塌”，每個人都是全能型選手，那就是未來？還是我們還是會保持職能分工？
Andrew：有一些事情我是擔心的。我覺得有些公司喜歡極端地追隨別人說的趨勢。取消角色概念的部分危險在於，它可能危險地消除“專長有可掌握的最佳實踐”這個觀念。
我聽說很多公司說我們要取消產品角色，我覺得這是個糟糕的主意，然後每個人都將成為一個“建構者”。然後會發生的是，他們不喜歡已經建立起來的產品這個學科，而它是有真實的最佳實踐、有真實嘗試過和失敗過的東西、有真實流程的——這些就被拋棄了，因為人們會說“哦，我寫了幾行程式碼”，對吧？那不是個好狀態。
我覺得像“這不是你的領域”這種邊界，我歡迎它消失。但這裡面有個平衡。不是每個人都能做所有事，無論從廣度還是深度上。這就是為什麼管理者不會消失。不是每個人都能做所有事，而且每個學科都有技能成分，我認為很多工程師沒有認識到這一點——工程有技能成分，而其他角色只是在“憑感覺做事”。
Lenny：對。我覺得還有一點就是“你想做這個工作嗎？”
Andrew：我是不是想做？我覺得現在更多的是，切換角色變得更容易了，學習最佳實踐變得更容易了，你的有效性不再與你使用某個具體工具的能力繫結在一起了，更多的是你能不能讓自己進入這種思維模式，學習哪些東西有效、哪些無效，然後專注於此。
我花了很長時間覺得自己不應該當一個軟體工程師，因為我不關心彙編語言或者背誦TypeScript語法，你知道嗎？這些角色中一直有一些部分是那種“看門人”性質的，說“擅長這個角色就是擅長這個工具”。我覺得那正是開始瓦解的東西。我只是覺得人們把這些事過度誇張了。
Lenny：你的團隊現在是什麼樣的？Codex團隊有多少工程師、設計師、PM？現在團隊的構成大概是什麼樣的？
Andrew：每次有人問我Codex團隊有多少人，我說大概在10到幾千人之間。這是個假答案，但也是真的，因為我們確實把它看作是所有人工作的集大成。所有模型研究的東西，所有讓模型擅長程式碼和瀏覽器使用的東西。所有模型個性的東西。所有前端基礎設施的產品工作，所有使用者相關的東西——全都是這個產品。
但與此同時，我們也不是每天接收成千上萬人的PR。所以我們有一個團隊，工程師是兩位數，設計師大概是一半。有幾個產品人員，雖然產品角色更多是“區域防守”的打法。
我覺得Codex這邊或桌面端所有人都有一個共同點，就是主動性和品味。很多前創始人，或者之前在大公司做創始人風格事情的人，很多有極佳品味的人。在OpenAI我們允許團隊變得很大，所以我們沒有那種“沒有管理層”的情況，但團隊確實相當大，大部分是IC。我覺得這很好。
Lenny：你用了“區域防守”這個詞來形容產品工作，我覺得這很有意思。它跟設計的轉變也有對應關係。就是你在這裡管理和協調。多談一點，那是什麼樣子的？對產品人來說，區域防守是什麼樣子的？
04. Codex在11月上線一定會失敗
Andrew：對，我和Alexander就這個比喻談了很多次。就是說如果兩個產品人合作太緊密，那往往不是一個好訊號。你作為產品人，想做的是某種力導向的活動，就是“哪裡有缺口？”尤其是在這個新世界裡，策展、引導和對齊是很重要的工作。有大量的混亂，人們在到處扔想法。自上而下、長達一年的那種規劃行不通了。
所以現在我們需要品味製造者來引導，從概唸到產品應該是什麼。這就意味著你基本上想要覆蓋整個公司。所以你們分散開，說“誰最擅長什麼？讓我們之間留出一些空間，這樣我們就能覆蓋全面。”就是這樣做的。
然後你們填補缺口。我們說“我們想招有產品思維的工程師。我們不希望一群人寫了一大堆程式碼，需要整個團隊來審查產品一致性。”我們希望每個人都有這些技能，但我覺得人們深入鑽研的東西必須改變。
Lenny：這確實是我在和像你這樣的人交談時反覆注意到的一個主題。現在最有價值的人之一，是那種能把一個想法從概唸到完成、並且有品味知道“這個很棒”的人。就像一個守護者，貫穿整個過程的這種“讓它變得很棒”的執著。就是你說的那種高主動性、高品味的人。這就是你對“我們在招什麼樣的人”和“誰會在新世界裡表現很好”的思考方式嗎？
Andrew：對，我覺得那是現在的核心部分。這也說明了我如何看待IC與管理層的區別。不是說管理層要消失了，不是說每個人都是IC了，而是每個人現在都兩者兼有，對吧？如果你是IC，你不是在逐個字元地敲程式碼，對吧？你在管理一些東西——你在管理Agent，你在管理工作，那些工作彙集在一起做某件事。如果你是團隊管理者，你在做同樣的事情，只是粒度不同。
我通常尋找的，顯然是對本學科的掌握，然後還要有品味，說“你會擁有無限的token，我們不能只是在生產垃圾，你需要能分辨什麼是訊號、什麼是噪音”——在一個無限內容的世界裡。
Lenny：你提到了規劃。以現在的發展速度，做路線圖規劃變得非常困難。我覺得尤其是在你的世界裡。
Andrew：人們對此很沮喪。是的。
Lenny：因為東西在不斷髮布、不斷變化。你們團隊是怎麼做規劃的？你們會想多遠？規劃長什麼樣？是電子表格嗎？是MD檔案嗎？規劃的產物是什麼？
Andrew：我覺得我們沒有做什麼革命性的東西。我們在規劃上並不聰明。基本思路是，時間越短的東西，細節越多。不是說我們不規劃9個月後的事，而是那只能保持非常模糊，因為你給9個月計畫加入的任何精確性都是虛假的精確性，你只是在浪費時間。
你可以說些什麼，但我們在產品側做的任何計畫，在11月能計畫的可能12月還成立，但不是實際發生的。規劃確實非常難。我們一般需要知道我們覺得模型在什麼時間線上能做什麼。
在我上一家公司，我看到了這種轉變，我們開始用模型來驅動功能，產品流程失效了。基本上只能是：列出我們覺得未來一兩年感興趣做的所有事情，全部原型化，決定哪些事情現在準備好了，其他的就放著，然後每次模型有新的飛躍，就用新模型再試一次。因為功能好不好的前提是基於它們是否足夠智能，而不是它們的形態。
這是一個關於Codex應用的好故事。我很確定我們在2月發佈的Codex應用，如果它在11月就準備好了，它在市場上絕對會失敗。唯一的區別就是11月到2月之間的模型。我覺得這很能說明問題——這個產品形狀完全一樣，但結果完全不同，僅僅隔了幾個月。
Lenny：這確實是我這個播客裡反覆出現的一個主題——建構那些“現在還不能用、但模型變強了就能用”的東西。還有另一個主題，就是雄心。對你做的事情要更有雄心。所以這是你們做事的一種方式嗎？就是建構一堆現在可能還不能用的東西，先放著，等模型跟上？
Andrew：對，我們有很多這樣的東西。我覺得有時候挑戰在於，你必須再次非常清楚地說明那在設計流程的哪個階段。人們還是有那種肌肉記憶，覺得“哦，我為這個東西寫了程式碼，所以我們應該把它推出去”。不是的，那意味著你現在有了一個工件，可以用來對未來模型進行測試，對吧？
這事發生在我們應用裡的內建瀏覽器上。我們有一個能用的版本。回到Atlas，我們有Agent在Atlas內部工作，那挺酷的。在那之前我們在ChatGPT裡有Operator，但沒有成功。想法很酷。在Operator、Atlas、Codex、ChatGPT之間可以畫出一條線，它們本質上是同一個功能，但在不同的智能水平下重新發佈，結果完全不同。
所以我推著人們不要固執地說“這個不行，所以這是個壞功能”。不是的，它可能還沒準備好。還有一點，尤其是在研究領域，總是有想成為最雄心勃勃的慾望，說“在極限情況下模型能做到這個”，但在產品側它就是不成立。
如果你回到最初的Codex發佈，基本上就是它說自己是Codex web，但和它互動並不好，你給模型一個任務，它會去做，然後帶著完成的結果回來找你。聽起來沒那麼激進。問題在於它做得沒那麼好。它寫了程式碼，但那個形態太早了。
然後Claude Code出來了，完全是本地的，不連接雲端。它不假裝自己是那麼具有智能體性的，它會問你問題，它會坐在那裡，你不能把你的整個生活都委託給它。那個效果好多了，因為那就是當時模型所處的階段。所以我們當時太“AGI上頭”了。我覺得我經常從這個教訓中思考。
以前是市場行銷告訴你關於產品形態和產品溝通的所有這些東西，現在不是了，你可能需要把一個東西發佈六次，它才能工作，而它的形態可能完全沒有變化。
Lenny：聽到你們在產品建構中要考慮的所有變數，真的很有意思。現在有模型的時間線、研究進展、它變得多聰明。還有人們能否理解“這就是你如何在雲端建構軟體的方式”、這是未來——讓人們為這個新未來做好準備。
然後是你們團隊能建構什麼。我喜歡Codex的例子，因為它回到了“雄心”這個主題。我想知道這對你來說有沒有什麼啟示——就是要更有雄心，因為這些模型能做的事情比你想像的要多得多。有時候它對市場來說太有雄心了，市場還沒準備好。但你會思考這個嗎？就是推動你的團隊更有雄心，因為做那些在過去可能看起來瘋狂困難的事情變得容易多了。
Andrew：對，這是一個核心挑戰。一旦有一個產品或者功能存在了，人們很容易找到各種小毛病並最佳化它們。
Lenny：微最佳化。
Andrew：他們應該這麼做，Twitter上的人也喜歡提醒我們這一點，我感謝他們。人們應該關注已經存在的功能，讓它們更可靠、更好。但這也是為什麼我們有一種自下而上探索的文化，因為有時候就像Codex應用出現並以某種方式顛覆了ChatGPT一樣，這個東西會被未來的某個努力顛覆。這也是設計的一部分，你不能總是一個團隊同時擅長顛覆性的部分和維護產品質量的部分。你需要設計一個能同時容納兩者的流程。
Lenny：稍微拉遠一點看。如果你想想我們一直在經歷的AI影響產品建構方式的處理程序，我們已經走了多遠，從你所說的“我們以前手工寫所有程式碼，像手藝人一樣創造人類程式碼”到“AI寫100%的程式碼”，再到你實際說的“現在編碼就是引導AI”。
當你思考“我的程式碼有多少是AI寫的”這個問題，幾乎變成了“我引導了它多少次”才是編碼的AI版本。現在還有Agent、循環等等這些東西，從你所見的，最新前沿是什麼？那些最AI原生的團隊現在是怎麼運作的？可能人們還不太瞭解。
Andrew：對，循環已經是上週的事了，兄弟。我們討論過這個。一個最大的問題總是“產品有多少是AI寫的？”這個問題總是很難回答，因為如果你用去年的標準，那我們現在產品100%是AI寫的程式碼。所以問題更像是“程式碼是有監督寫的還是無監督寫的？”那是完全不同的事情。我歡迎標準的改變，因為那意味著我們在產品上取得了進展。
在自主開發的軟體方面有很多探索。很多harness工程的東西，很多不同的探索。比如“如果你在夜間運行，對程式碼庫做垃圾回收來清理它，會怎樣？”有一件事我認為所有模型目前都有的問題就是它們通常會增加複雜性。如果研究團隊在聽，請讓模型更擅長刪除程式碼。但現在當你試圖把開發完全放在自動駕駛上時，這就成了一個問題。這在人這一側和程式碼庫那一側都是問題。
比如功能請求，你怎麼教一個模型哪些功能該建構、哪些該忽略、哪些該分組並稍微重新框定？你怎麼教一個模型如何建構正確的抽象？所有這一切都在變好。我不認為我們到了那種“我們只需要設定一個循環來改進應用”的階段，讓它監聽Twitter、監聽Slack、監聽郵件——我們還沒到那一步，但我們正在努力讓它發生。
Lenny：你覺得我們會到那一步嗎？我們會達到那種“增長”然後“獲勝”的狀態嗎？
Andrew：目標賺錢，讓我賺十億美元？
Lenny：贏得市場。
Andrew：我不知道，兄弟。我不是那種說“永不”或“總是”的人。
Lenny：作為產品負責人、工程負責人，你在工作中是怎麼用AI的？有哪些你使用它的方式可能是人們沒意識到可以在應用裡用的？
Andrew：我覺得我現在擁有世界上最好的工作。但讓它變得非常有趣的一點是，當我們在開發最初的Codex應用時，我個人的目標是讓它成為我寫程式碼用的工具。我說“我需要把這個東西做得在開發上足夠好，以至於我可以用它來建構Codex應用本身”。那時的Codex應用是一個開發工具，對吧？
我們很快就進入了個人dogfooding循環，因為你會說“哦，我做不了這個事，我應該修好它，這樣我才能做這個事。現在我能做這個事了，現在我能做更多的事了。”我們發佈了那個。然後下一個挑戰是“嘿，人們開始在用這個東西做一些不同形態的事情了，現在我需要讓它增長，所以我需要招幾個人來幫忙”。
所以我的角色在那時變了，與此同時應用的角色也需要改變。我說“好，我需要做更多的產品發現。我需要找到正確的循環來看到每個人在做什麼，並引導偏離軌道的事情。”所以突然之間，那就是我開始用Codex應用做的事情，對吧？我仍然寫程式碼。我試圖讓我自己的使用方式與我們要解決的問題保持一致。
現在我會說“我需要建立一個電子表格來建模這個。我需要做一個內部深度研究，瞭解所有已經投入這個研究領域的努力，為下一個版本做準備”。在五月份左右的某個發佈或一系列發佈中，我們為Codex應用引入了內建瀏覽器、電腦使用和工件建立功能。那我覺得是我們Codex的“幾乎面向所有人”的發佈。每個人都知道“vibe coding”這個詞。
我覺得那是我們第一次協調發佈的五個功能——我當時有一個Notion文件記錄了所有需要做的事情，然後我在自動化地去從PR、從Slack頻道收集更新，更新狀態追蹤器。現在這已經相當普遍了，但在當時，我覺得自己處於“如何管理一個產品發佈”的最前沿。
簡而言之，我用Codex應用的方式基本上就是“我的工作變成了什麼，我怎麼讓這個東西能做我需要做的一切？”我早上起來，會看到我收到的每日簡報——來自我加入的3000個Slack頻道里的所有內容，哪些需要我的關注。我可以回覆說“給我五個問題，我來回答”，我就能做到。
Lenny：你是怎麼設定那個的？對想設定的人來說，工作流是什麼樣的？因為聽起來太棒了。
Andrew：再說一次，我覺得我們在很多這方面還處於發現階段。所以現在，我是在做一個自動化或者定時任務，說“我過一遍我的Slack頻道，這些是我關心的、認為最重要的事情”。所以我還在定義那些“需要留意的事情”，按不同類別劃分，這裡有一些上下文。然後我會把它設定為一個自動化任務。
前幾次運行可能需要一些引導，幸運的是，用這個應用，我不需要去弄清楚如何編輯指令，我直接說“嘿，下次運行的時候，能不能請你關注這個而不是那個？”或者“你能不能弱化這個工作流？”“嘿，這件事發生了，但它沒有出現在簡報裡，你能不能確保那種形態的東西？”我可以在這個過程中指導它，它會更新它通知我的方式之類的。太棒了。
Andrew：但在未來，這其實是聊天機器人形態的一個核心問題，對吧？我知道怎麼設定這個，我有時間設定這個，因為對我來說這是產品發現。但如果你不在OpenAI工作，不在開發這個，你不想必須搞清楚所有這些東西。我們需要搞清楚那種形態。
Lenny：對。我聽到的是，我覺得人們沒有意識到你們的應用可以很像OpenClaw。人們那麼興奮的是，你只要跟它說，設定這個，每天幫我檢查這個，然後告訴我發生了什麼——它開始成為所有產品的一部分了。這太棒了。所以某人設定這個的方式就是他們在應用裡說“我想設定一個自動化來做這個，看看我的Slack，這些是我想做的事情”。
Andrew：對。應用會說你說的對，它會為你設定。如果它沒有Slack連接器，它會說“我能加入Slack連接器嗎？”是或否？你可以點“是”。我們至少能做到的是，如果你不知道如何在應用裡做某事，你直接問它就行，對吧？我覺得這還不夠，但我覺得至少是我們能做的。
Lenny：對。一個好例子是我在Codex裡建了一個小應用來過濾收件箱裡的垃圾郵件。每封進來的郵件，它會看然後判斷這是不是那種我不想看的未經請求的冷郵件，給它打標籤然後放到別處。為了設定那個，其中一步是你得去Google Cloud控制台設定那些pub/sub、API和觸發器。我不知道你有沒有用過那個介面，真的很煩人很慢，對吧？
Andrew：對。
Lenny：所以我就想“等等，如果我讓你去做呢？”然後我說“好的，酷。幫我做這個。”然後它就描述了電腦使用。我以前從沒真的在我的電腦上見過這個——它就接管了我的電腦，開始去那裡操作。
Andrew：就像“我不管你有沒有連接器，兄弟。我就開始點。”
Lenny：對，然後它自己搞定了。看著它做事太瘋狂了。
Andrew：設計連接器之間的決策邊界——什麼時候用內建瀏覽器，什麼時候用你連接的Chrome擴展，什麼時候用電腦使用——這很有趣，都是靠感覺來摸索。
Lenny：我前幾天看到一條很好的Twitter帖子，他們描述了這三種形態以及各自用途。那個人描述得非常好。
Andrew：這些個人工作流真的很有意思，因為有些真的很受歡迎。人們在嘗試各種東西。每個人都在建立自己的個人系統。你問這裡的每個人他們怎麼做的，每件事都不一樣。然後會出現一些共同的主題，我們會說“你知道嗎，那應該成為應用裡的一流體驗。我們應該把大家似乎都在設定的這個東西直接做出來。”
我覺得記憶就屬於那種形態——我們有很多人，其他公司也有很多人，說“我建了一個Obsidian庫或者Notion區域，我告訴它怎麼建構我的‘思維宮殿’，怎麼放東西”——我不知道是不是每個人都應該那樣做，你不應該非得那樣做，應該有一個記憶功能為你做這件事，那是相當通用的。那是其中之一。
但還有其他東西，比如你的工作流程，有些東西你應該去設定。但我認為我們一直在篩選哪些對個人有效的東西應該進入產品，哪些應該留在“那只是你做你工作的方式”。哪些應該成為基礎元件，哪些不應該。
Lenny：對，這就是你之前說的品味和判斷——篩選這些東西。我想談一下瀏覽器使用這個部分，因為我覺得人們沒有意識到它有多強大，以及它可以用來做什麼。這讓我想起，我不知道你有沒有看Dan Shipper上這個播客的那期，他有一個預測，就是我們開始用Codex來運行我們內部的SaaS應用。
Andrew：對。所以，不用去Chrome裡。我知道他每天給我發消息問這個。
Lenny：你覺得這是未來的方向嗎？我們就在Codex應用裡工作，在裡面用Notion、Linear、Salesforce，有Agent在旁邊幫忙？還是你覺得那是不同的方向？
Andrew：這確實非常有意思，因為顯然我們有過幾次嘗試瀏覽器形態的東西，對吧？Operator、Atlas裡的Agent模式，現在桌面應用裡有內建瀏覽器。我們也可以安裝Chrome擴展讓應用連接Chrome。我們有很多不同的形態。
我覺得我們從中學到了很多不同的東西。有很多因素在起作用。比如，我們最初發佈應用的時候，它是一個Electron應用。內建瀏覽器能做的事情有限，而且有點卡頓。所以我們的內建瀏覽器是為開發準備的，是用來測試前端的。我們說“它真的不適合做別的事情，它是一個開發者工具”。
然後我們切換到了我們的OWL技術堆疊，它驅動了Atlas瀏覽器，所以現在有了多標籤頁，有了企業安全功能，你可以真正登錄到所有網站。我們一直在迭代。我覺得困難的地方一直在於這個瀏覽器的形態應該是什麼樣的？
這是只給Agent用的嗎？你打開Chrome，在Chrome裡做你的事，如果你問桌面應用，它會打開一個它能快速控制的瀏覽器，沒有Playwright那樣的延遲，還是我們想說這個應用是萬能的，我們希望你把它當瀏覽器用？
這兩者有大量的權衡，這不是一條有很多人走過的路，對吧？大多數瀏覽器在頂層就是瀏覽器，有瀏覽器標籤頁。
這創造了很多非常無聊但繁瑣的問題，比如鍵盤快速鍵，對吧？我們是做鍵位對應到VS Code，還是到Chrome，還是到我們自己的東西，還是到Linear？我們想有一些能延續的肌肉記憶，但所有這些在市場上有不同產品子形態的東西，我們該怎麼辦？
Lenny：這正好凸顯了這個應用有多難，你要讓它對從來沒建構過東西的人也能工作，從更基礎的使用者到像Peter——OpenClaw那樣用它來編碼的高級使用者。
Andrew：我不確定我能讓Peter用這個應用。我覺得他可能是最後一個。
Lenny：他是終端的堅守者。
Andrew：但我會繼續嘗試。
Lenny：好。讓我拉遠一點，談談你們要把這一切帶向哪裡的宏觀圖景。你對Codex的願景是什麼？它會走向哪裡？它會是什麼樣子？一兩年、十年後？
Andrew：我們有Codex作為CLI，對吧？然後我們決定建構這個應用。我們對這個應用有點不確定，但對它能成為什麼有很強的信念——作為一個開發者工具。它不會是一個IDE。它會是這個恰到好處的介面，有點像一個聊天機器人，但遠不止於此，你能看到程式碼，但我們不讓你編輯程式碼。
OpenAI在1月、2月發生了一件非常有趣的事，在我們真正發佈Codex應用之前，我們已經開始在內部自測Codex應用了。我們發現我們在工程和研究工作流上已經收斂到相當清晰的內部產品市場契合了。他們很高興，很喜歡它。我們說“我們只需要把質量門檻提上去再發佈給全世界。我們相信這會是個東西。”
但後來在公司裡，我們啟動了一些其他工作流，說“嘿，Codex這個努力在編碼Agent上確實有進展”，我們有來自市場、來自公關、來自財務、來自法務、基本上來自各個領域的人在用這個Codex應用，即使它對這些人是主動不友好的——它在試圖向他們展示程式碼，它在試圖請求批准運行命令，它在做所有這些對它們來說不是正確產品形態的事情。
那我們為什麼不在其他介面上也加入Codex呢？我們把它加到ChatGPT桌面應用裡吧，我們把它加到Atlas瀏覽器裡吧。基本上就是把Codex的經驗教訓拿來，讓它更通用，成為一個通用的知識工作工具。那些努力進行了一段時間，然後最煩人的問題發生了——沒有人願意離開Codex應用去那些據說是為其他使用者群體打造的應用。
我覺得這裡面的教訓是，“開發者工具vs通用知識工作工具”這個二分法有很多細微差別，不是非此即彼。我們非常堅信這一點。就像我們討論“你角色的平均值就是你的角色”一樣，在產品側也是真的，做Excel工作的人不想看到git倉庫資訊。
我們知道這一點，但我們也知道我們可以從他們做的事情中判斷他們做的是什麼樣的工作，我們可以從簡單開始，根據需要讓產品變複雜。
這並不意味著我們沒有模式，你可能想要一些模式來組織你的東西，來標示你進入體驗的方式。但我們堅信我們建構的這個東西有正確的形態來承擔真正深度的、垂直聚焦的事情。
我們與財務團隊、科學團隊、法務團隊深入合作。我們說如果我們可以建構正確的可擴展性原語和正確的通用模型，那你就能用這個東西做任何事，對吧？然後我們的挑戰就是怎麼把它通用化。
但這又回到了“我們能建構的最好的桌面應用是什麼樣的”。所以Codex是開發者工具，ChatGPT是……這些都走向哪裡？我們就是這麼想的。
Lenny：你剛才說的那個點太有意思了——Codex應用做得太好了，讓人們對它有了認知，用起來很好、很有趣，以至於所有人都開始用那個而不是ChatGPT應用。所以很明顯的方向是把它們結合起來，這樣你就不會製造這種混淆，我知道這也是大家一直在討論的，把它們合併在一起的想法。
Andrew：有人叫它“超級應用”，我希望他們沒說過這個詞，因為現在我每天都要聽到“超級應用”這個詞。我們會克服的。很好。
Lenny：好。但那是不是就是——我們別叫它超級應用——但想法是，一個地方讓人們去做所有事情。那是大致的方向還是待定？
Andrew：對。我們看到的是，它是一個很好的大本營。它是一個很好的地方來跟蹤你需要在不同介面上做的所有事情。有些事你在應用裡全部完成，有些事應用會打開其他應用來做。
應用可以連接Excel，所以它有內建的電子表格編輯器。那對在OpenAI做財務建模、募集數十億美元的人來說夠用嗎？大概不夠。所以應用直接和你桌面上的Microsoft Excel外掛對話。
做完之後，你可以關掉Excel，對吧？所以不僅僅是“我們在螢幕上畫一個矩形，所有事情都需要發生在這個矩形裡”。它應該是你工作的起點、終點、自動化的地方，它使用你需要的任何東西。
有一個很好的故事，我們在這間房間裡為Codex應用的首次發佈拍了一些視訊，我們內部的DX視訊剪輯師Brent被安排去剪輯這些視訊，他用Codex剪輯了所有視訊，這是早期的“哇，人們在用這個東西做什麼”的例子之一。
他決定開始用Codex的過程非常有意思。他開始只是因為好奇Codex能不能剪輯視訊。Codex本身並不是視訊編輯器，它沒有那種介面，但它能理解他用的是Premiere Pro。它可以通過編輯Premiere Pro裡支撐螢幕上內容的後台檔案來做一些剪輯，但它不能做所有事情。
所以很自然地，Codex接下來就給自己建構了一個擴展，可以安裝到Premiere Pro裡，然後它就可以和那個擴展對話，說“嘿，Premiere Pro擴展，你能不能幫我把Premiere Pro應用裡的這個標記改一下”。我們當時看到這個的時候覺得太瘋狂了。
這是一個很好的模型，有一些專業工具專門做某些事情。所以我們試圖用Codex和現在的ChatGPT同時做兩件事：一是如何無縫地與你已經在用的這些工具互動，說“我們不需要為你建構一個更好的視訊編輯器”。
但Codex和ChatGPT可以用那個視訊編輯器，它可以互動，可以把東西交給它，對吧？這通常通過連接器、電腦使用，或者在這種情況下的擴展來實現。
還有一種Dan Shipper的模式，就是“嘿，我有這些網頁應用，我可以點來點去用，但我想能在Codex裡打開它們，讓Codex對它們做額外的事情”，這兩種模式幾乎是相反的，我們同時在兩者上都做了很多工作。
05. 2000條"這很爛"： OpenAI的產品打磨方式
Lenny：Premiere這個故事對我來說很有意思，因為它又是一個“對這些AI工作要有更大雄心”的例子。你可能不知道，也許它們能做到這件事。幾乎就是“去試試，看看它能不能搞定”。我要帶我們進入播客的一個固定環節，我叫它“失敗角落”。
問題就是，大家看到像你這樣的人，一路高歌猛進，一切都在贏。Codex做得很棒。這個瘋狂的職業生涯，一切都在向上。
人們可能看不到那些事情不順利的時候，你發佈過但失敗了的東西。這些故事對人們來說很重要，讓他們知道不是一直都贏。有沒有一個你職業生涯中失敗過但教會你很重要東西的故事？
Andrew：聽到那種描述真是有趣。這大概是我第一次覺得自己不是在失敗。我做了很長時間的創業公司創始人。最後基本上是把公司拆解賣了，對吧？那是好幾年。那是一場苦戰。是在高度監管的領域。整個過程感覺像是一直在失敗。
我去了另一家創業公司，我們試圖做一些AI工具，也是在同樣受限的行業裡，感覺是一次又一次地嘗試然後失敗。
所以對我來說，我實際上失敗過很多次。你知道有時候只是時間點到了，技能、熱情、市場時機都對齊了，這個項目我們才能把在Codex應用上學到的東西和ChatGPT結合起來。
我不知道有多少微小的失敗——我們說“這應該是這樣的形態”，然後扔到Slack裡，結果有2000條消息的執行緒說我們有多蠢。
這就是我喜歡OpenAI的地方，人們會直接告訴我們。當我們在內部產品失敗時，他們不會保留意見。這就是為什麼外部產品一直很好的原因，因為它經歷了這些。
Lenny：2000條“這很爛”。
Andrew：我在達到這個點之前失敗了大概10到15年。所以我每天還是對事情進展順利感到驚訝。我知道。
Lenny：我覺得這對人們來說真的很重要——你可以有很多事情沒有成功，然後事情開始變得非常好，就是繼續前進、繼續學習，我想這是一條教訓。
06. 結語：Codex不只是開發者工具 它正在變成“工作的中樞”
AI抹平開發成本，寫程式碼不再稀缺，但統籌規劃、系統抽象、戰略判斷的“審美判斷力”成為行業稀缺能力。Andrew認為，現有大模型缺少原創設計、長週期推演能力，無法獨立完成完整產品經營；同時否定“全員開發者、淘汰產品崗”的激進行業論調。
以Codex為代表的新一代AI應用正在從單一工具，演變為跨應用的工作入口與執行中樞，使軟體逐漸從“被使用的工具”，轉向“執行工作的系統”，也預示下一代AI Agent競爭重心將從基礎執行能力，轉向戰略決策與複雜業務統籌。 (智東西)