Anthropic首席產品官萬字分享：AI時代的“現象級產品”為什么難產？

AI時代，難在做減法。

編譯整理 | 莘歆

來源 | 盒飯財經（ID：daxiongfan）

頭圖及封面來源 | AI & I 截圖

Instagram聯合創始人、Anthropic首席產品官Mike Krieger，用Claude，花了兩個小時，重建了他當年花一整年做的產品。不僅功能完整，甚至還多了幾個圖片濾鏡功能。

這本身并不重要，重要的是，你怎么知道自己做的是對的東西？Mike見過太多團隊在AI加速的浪潮里越跑越快，功能越堆越多，產品卻越來越難用，最終造出一堆用戶根本不需要、華而不實的東西。

因此，Mike在《AI & I》播客中反復追問：為什么在AI加速開發的時代，依然沒有出現現象級的產品？

他把問題指向了Vibe Coding（氛圍感編程）帶來的“效率幻象”。AI 帶來的效率狂飆，反而讓開發者更難建立對產品的真實判斷：什么該留，什么該砍，什么時候該推倒重來。

當寫代碼變得像吃飯一樣簡單時，越來越多的產品，成了精心培育的“溫室里的樹”，看似枝繁葉茂，卻從沒經歷過用戶反饋的風吹雨打，非常脆弱。

Mike 給出的解法是，更果斷的“推倒重寫”、更早地將產品扔進真實世界去經受風吹雨打，以及轉向真正的“智能體原生（Agent-native）”設計。也就是說，讓軟件不再是冷冰冰的指令工具，而是能自主調用底層功能、真正理解用戶意圖的協作伙伴。

那么，智能體原生產品到底意味著什么、AI 時代團隊該怎么搭、以及為什么“推倒重寫”和“更早發布”是現在最被低估的產品方法論呢？答案，就在下面這場對話里。

對話人物：

Dan Shipper：AI媒體實驗室Every首席執行官，《AI & I》播客主持人

Mike Krieger： Instagram的聯合創始人，Anthropic首席產品官 (CPO) ，Anthropic Labs負責人之一

圖片來源：《AI & I》截圖

以下是對話全文（已編譯）：

AI時代，效率幻象下的功能冗余

Dan Shipper：就像我們剛才在錄制前聊到的，底層基礎架構或者說我們開發產品的整個過程發生了很大改變。那在產品開發中，哪些事情更容易了，哪些變得更難了，或者說可能保持不變？跟我聊聊現在的經歷，對比你早期在Anthropic或者在Instagram時，現在發生了什么變化？

Mike Krieger：我們都知道Instagram的故事，當時我們有另一個叫做Burbn的產品，我們在這個產品上面花了一年，但行不通。后面我們才轉型到Instagram。Instagram的開發和發布基本上只花了3個月。

我就在想，現在哪些事情是微不足道的，而開發過程中又有哪些本質的東西并沒有變容易？在那一年里，我們本可以更早地發現那些死胡同，但其實這個過程本身也是有價值的。比如，我們一開始把產品搞得太復雜了，后面不得不去簡化它。

我發現，即便是在今天，模型也非常擅長增加功能，但不一定擅長搞清楚該從產品中砍掉什么。因為這需要在現實世界經歷大量的實際應用才能明白。

現在的過程是增量式地添加東西。

在今天，尤其是我們在實驗室開發的一些東西，你可以在幾個小時內讓它實現從0到1，甚至是從0到N。但這個過程中，它自己會做很多決定。哪怕你可以要求它進行后續跟進和反饋，但開發者對“哪些功能是必須的，哪些可以舍棄”的直覺，是需要時間來建立的。

所以我一直在反思，為何在AI加速開發的時代，也還沒有出現很多現象級的產品。

我認為部分原因在于，即使AI能提高效率，但你想對世界做出什么樣的干預，這仍需要時間來磨練，再以此為基礎進行開發。一旦你知道要構建什么，實際的構建過程確實容易多了。我讓Claude重新開發了Burbn，只花了大約兩個小時，功能就完整了。它還添加了Burbn當時沒有的濾鏡，這個濾鏡是我們后面為Instagram開發的。Claude預知了產品的最終走向，所以提前把濾鏡納入進去了。

我記得還有一周，我的合伙人Kevin跑去開發了Instagram第一個版本的所有濾鏡，而我跑去搭建了應用的其余部分。那時我會熬夜到凌晨4點，然后睡到中午，那是我的作息規律。

在這個過程中，你會做出很多決策，比如地理位置應該如何運作？我們必須找到一種方法，既能加速開發，又能幫助人們建立對這些決策的認知。否則，最后得到的要么是非常平庸、不太可能突圍的產品，要么是那些無法反映你對所在領域或產品更深層次認知的產品。

Vibe Coding帶來的“溫室樹木”

Dan Shipper：這讓我想到了兩件事。一是我腦子里一直有一個想法：如果你在室內種一棵樹，不讓它接觸風，它就不會長得那么強壯。因為在生長過程中，它需要這些外力磨練，才能長成一棵真正的樹。如果你把它放在室內沒有風的環境下，你也能種出一棵樹，但它會傾斜，會變得很脆弱，和野外的樹完全不是一回事。

我認為你所說的情況也是如此。

我們如今開發節奏非常快，原本這種通過一次做一件事、然后接觸用戶來反饋的增量式過程，現在你可以直接在室內“種出”一棵完整的樹。你擁有了這個完整的東西，但它每一步都沒有經過相同水平的直覺錘煉和經驗磨練，而后者正是創造偉大產品所必需的。

Mike Krieger：我也很喜歡這個隱喻。剛開始做Instagram時，我們非常迷戀Eric Ries（精益創業方法論締造者）和精益創業，還有整個YAGNI（You Ain't Gonna Need It，你以后不會需要它，即“不要過度設計”）原則。

但我發現，最近實驗室做的一個項目中，在進入早期測試（Early Access）之前，我們就過度開發了V1版本。你會覺得，“哦，既然有這個選項，為什么不把那個也加上呢？”也就是一個PR（Pull Request，合并請求）的工作量。所以要是你在Claude Code中找到了一種非常好的流程，你發出指令，去吃午飯，回來時東西就做好了，你會覺得“太棒了，我們把它加上了”。

圖片來源：profitable processes

但我們意識到，我們雖然創造了一種功能矩陣，但在發布前這是很難進行測試和維護的，甚至很難向剛接觸它的用戶解釋。另一個人給我的隱喻我也很喜歡：這就像是“一集一集地結識電視劇中的角色”。對比“你被直接扔進最后一集”，你會覺得，“等等，這些東西都是干什么的？這些人都是誰？我居然被要求已經掌握了所有的背景信息。”

我在長期開發某種東西時，也有同樣的感受。但樹的隱喻我認為也非常貼切。向某人展示一棵完全長成的樹，信息量確實太大了。這里面肯定有些門道。現今，你如何開發產品并保持簡潔是很重要的，而不是你“能做到”就讓它出現在第一個版本中。

Dan Shipper：我也遇到了同樣的問題。就在昨天，我一直熬到凌晨4點，就為了調試和修復我在Every隨手做的一個叫做Proof的應用。它是一個智能體原生（Agent-native）協作營銷編輯器，你可以和你的團隊或其他智能體快速分享策劃文檔等。

這是我對整個產品端到端的第二次或第三次迭代，這在現在能做到確實很有趣。但在前幾次迭代中，我發現自己因為Vibe Coding（氛圍感編程：開發者不再手寫具體的代碼行，而是通過“傳達意圖、調整情緒、描述感覺”來驅動AI生成整個應用）太好玩、太讓人上癮了，就想“沒錯，我要做這個，還要做那個。”結果就創造出了一個難用的龐然大物。

后來我受到我們另一個產品Monologue的啟發，我不確定你有沒有見過，它是由GM Naveen運營的一個非常簡單的語音轉文字應用。它專注于把一件簡單的事情做得非常出彩。在這里，我看到了這個“任何人都能做產品”的時代，極其精致且擅長其本職工作的東西是多么有效。

于是我扔掉了原來的產品，重新開發了一個非常簡單的版本，它只是一個可分享的Markdown鏈接。然后這個產品開始在Every內部病毒式傳播，每個人都在不停地使用它。

現在我們發布了，它直接爆火了，所以我昨晚整晚沒睡在試著修復它，心里想：“我年紀大了，受不了這罪了，不能再這么干了。”這讓我想起了我20多歲或上大學時鉆研技術、搞開發的日子，那很有趣但也讓人精疲力竭。現在一切皆有可能，我發現我必須真正調整我的心理狀態。那么你是如何處理這個問題的？

花幾天時間推倒重做，好過縫縫補補

Mike Krieger：順便提一下，我記得在做Burbn時，我們最大的錯誤是隨著時間的推移不斷增加功能，而不是刪減功能。你會覺得，八個功能做不出好產品，也許第九個就能成功。結果恰恰相反，這只會讓產品越來越復雜。

我認為處理這個問題有兩點：一是我們現在更愿意進行重寫。按照經典理論，比如Fred Brooks（弗雷德·布魯克斯）在《人月神話》（The Mythical Man-Month）中提到的，你不應該重寫軟件，這樣你會把V1版本中蘊含的所有精髓都搞砸，還有所謂的“第二系統綜合癥”（Second System Syndrome）。

《人月神話》圖片來源：addictbooks

這些理論現在依然很有道理，但不同的是，現在模型可以幫你進行代碼對比（Diff），基本上能幫你查看是否遺漏了第一個版本中的任何內容；其次，這不再是一個可能拖垮公司的、長達一年的重寫計劃，比如著名的Netscape（網景）重寫。現在重寫大概只需要幾天時間，尤其是基于現有的源代碼。

所以我們實際上有好幾個項目，一開始構建了完整的版本，但當我們意識到把它搞復雜了或者做了一些核心假設錯誤之后，我們直接推倒重做V2，并在此基礎上進行迭代。當然，一般都是在發布前重新開始。

你不會覺得“噢，天哪，白建了一年”，而是覺得“噢，那是上周的事，這周我可以重做，而且能砍掉很多沒用的東西”。

在功能層面以及從產品開發的角度，我們正在學習更早地發布。我們擁有強大的企業級客戶群（Enterprise footprint），人們對初始版本是有期望的。

但我們不能因此就假設在發布前知道產品需要添加的每一個連接器或每一項功能，而是要通過用戶的反饋。我們有一群強大的內部試用者，我們稱之為 “Ant foodters”（譯者注：科技圈有一個著名術語叫“吃自己的狗糧”，英文為“Dogfooding”，指公司內部試用自己的產品。Anthropic的員工自稱“Ants”，所以他們把內部試用戲稱為“Antfooding”，即吃螞蟻食），我們可以先進行內部的測試反饋。但在這個產品真正進入到現實世界之前，這也只能帶你走這么遠。

以Co-worker為例，我們打磨這種形態的產品已經很久了。我們一旦決定發布，就會構建一個V1版本，力求以最簡約的方式解決問題，并在10天內推出。這是一個很好的鞭策，讓我們意識到即使V1還可以有100種功能，但它目前沒有。它現在只要足夠有用，可以證明某些東西就可以了。我不確定再開發兩個月、增加50種功能是否會更有用。

事實上，我們可以在那兒構建一棵“室內樹”，但一旦接觸現實世界，用戶會說：“其實沒人想那樣做，他們想做的是另一件事。”所以我認為，精益創業的原始直覺依然適用，只是它們正在以不同的時間尺度和方式表現出來。

“智能體原生”產品設計意味著什么

Dan Shipper：我很想聽聽你對產品設計和產品運作方式的看法。Every的每個人都會告訴你，我在軟件開發中使用最多的詞就是“智能體原生”。也就是說，智能體必須能夠像用戶一樣使用應用中的任何功能。當然，關于“智能體原生”還有一些其他原則，但我基本上是從你們那里偷來的。

我認為Claude Code是教會我一種產品如何高效運作的典范。它是一個智能體，可以做你在電腦上能做的任何事情，而且它是可定制、靈活且可擴展的。它不但容易上手，還能做很多設計師預先都沒想到的事情。我認為這是 AI產品開發的一個非常好的模型，不過這是我觀察你們的做法并加入了自己理解后的想法。我很想知道你是怎么看待它的？你會如何描述這類產品的開發？

Mike Krieger：我很喜歡你們寫的關于“智能體原生”的文章，對我來說，那是對此最權威的探索。謝謝你們把這些想法清晰地表達出來。我想從幾個方面來談。

第一，我最近和一個人聊過，他是個非技術人員。他說：“你們一直在聊智能體之類的東西，其實就是現在的電腦終于能用了。”我一直希望電腦能按我的意愿工作，以前不行，現在行了。這是一個很有趣的現象，如果你以前知道正確的“咒語”，能在命令行（Command line）通過brew install安裝東西，那你就能搞定，但普通人不會這么做。

而現在Claude可以為你做這些，因此電腦現在感覺像是一個陪伴在你身邊的工具。我覺得核心在于，這不僅是為新軟件增加動力和功能，更是解鎖了那些本該存在或可用、但對普通人來說極難操作的功能。

圖片來源：apidog

第二，是對比我們做得好與不好的產品。我認為Claude Code做得很好，但 Claude AI（網頁版/App）仍需要大量進化。舉個例子，我看到有人在使用 Claude的項目（Project）功能，他們構建了一個作品（Artifacts）或一份新文檔，然后說：“太棒了，你能把它添加到我的項目知識庫里嗎？”Claude AI的回答是：“好的，讓我告訴你去哪里點按鈕來把它添加到我的項目知識庫里。”這就錯了，這本該是它能原生完成的一件事。

所以，在這樣的產品中，你也能看到一個2024年的產品在迭代進化，但它從一開始就沒有植入這樣的理念：它應該掌握自己每一個原語（Primitives）的知識并有權修改它們。我認為這在當今的產品中至關重要。

Claude Code算是2025年的版本，當你看一些人正在實驗的“運行框架”（Harness，圍繞模型構建的整套基礎設施，模型負責推理，harness負責動手）時，你會看到更深層次的東西，也就是智能體實際上可以修改“運行框架”本身，這可能達到了下一個層級。這對大多數人來說可能有點深奧，但解鎖這種功能意味著你不必坐在那兒想：“噢，我希望它能有一點點不同，我希望Gmail的運作方式能稍微改一下”，而是直接要求它去改。

我覺得這是巨大的進步。即使在Claude Code內部，教Claude Code認識 Claude Code本身也是一種非常有價值的體驗。比如，我很喜歡你關于“智能體原生”的論述，我想把它作為一個“技能”（Skill）。這樣每當我做原型開發時，它都會以智能體原生的方式思考。于是我讓Claude Code把它打包成一個技能。

整個過程是這樣的：“嘿，Claude，在Claude Code里，你能為此創建一個技能嗎？”它說：“當然，我正在查找我的‘技能開發技能’，我要創建一個關于它的技能，我要安裝它。”我說：“太棒了，現在可用了嗎？還是我需要重啟？”它說：“我認為你需要重啟，我查一下，是的，你需要重啟。”一切都在于它掌握關于自身的知識，這解鎖了巨大的能力。

這也引申出最后一點，我們實驗室一直在思考，如何讓Claude開發的軟件更具“Claude原生”或“開發意識”，使其從一開始就考慮到并以這種方式開發？它現在還不會自發這么做，部分原因是幾十年來軟件開發的慣例并非如此。

Dan Shipper：這正是我要問你的。我非常榮幸你讀了那篇文章并為此創建了技能。另外，你指向了一個我發現的真實問題，我認為Claude模型確實最適合做這件事。一般來說，Codex類型的模型在開發“智能體原生”方面沒那么好，因為模型（除非你逼它們）通常像傳統工程師一樣思考。

傳統工程師追求的是一套完全不同的準則，即你想要護欄（Guardrails）和測試，你想要確保用戶只能走一條路徑。而我們現在創造的是這種超靈活的可擴展體。那么，你如何開發你的產品，去教模型（以及整個框架）以這種方式思考和工作呢？

Mike Krieger：我認為包含兩個部分。一個是比較平淡的部分，第二個是更有趣且正在開發的部分。

第一，是在模型搭建時，為其提供良好的模式（Patterns）和范式（Paradigms）。比如，在“模板化”和“技能化”之間找到平衡，這個平衡點到底在哪。我們現在有一個關于Claude API的技能，它聽起來可能很簡單，但擁有它非常有價值。

因為有時你會發現，我們發布了一個新模型，但它不在模型的內在知識庫里，那么你就會陷入這種滑稽的爭論，你說：“不，不，你寫錯了，應該是 set 45。”它說：“不，我知道……”有了這種技能和良好的模板化示例，會有很大幫助。

第二，有趣的部分在于，這類軟件需要一種完全不同類型的測試。你很難像傳統產品一樣為智能體原生產品編寫端到端的邏輯測試，這是因為它部分魅力就在于那種不可預測性。

所以我們在實驗室反復討論的另一個想法是：你如何提高驗證（Verification）的保真度？

前幾天我正在開發一個智能體原生的iOS應用，我讓Claude與它交互，結果 Claude在應用的聊天功能里開始自言自語。看著Claude對Claude說話非常搞笑，就像有人在假裝人類聊天。那個原型是我做的一個工作日志反思工具，其中一個Claude說：“唉，我老板對我真的很兇，我今天過得很糟。”另一個Claude回復：“噢，聽到這個我很遺憾。”

它們就在那兒聊個沒完。你不會為此寫單元測試，而且它可能會產生一些其他的涌現想法（達到臨界值后，模型會突然獲得了一些原本并不在設計之中、甚至開發者都沒想過它能具備的能力）。

所以我認為，你必須更多地去建立那種能夠盡可能驅動這些智能體原生能力的框架（Harnesses），你不知道事情會如何發展，Claude可能會嘗試做一些你根本沒想過的事，并把你的應用帶入一種全新的狀態。

繞了一大圈回到剛才的話題：什么才是難點？難點在于如何讓底層架構對這種不確定性依然保持健壯。它是智能體原生的，但它也能夠以你意想不到的方式伸縮。我覺得這就是2026年軟件設計的藝術與科學。

Dan Shipper：這非常有趣，我完全同意你的看法。你希望在一個安全的環境中擁有一個游樂場（Playground），但只有當邊緣安全時，游樂場才成立。我認為最初我們把游樂場做得太小、限制太嚴了。現在模型變了，我們可以把它開放很多。但我們還沒完全搞清楚界限在哪里，至少我沒搞清楚。

這讓我想到了另一件事，我在腦子里有一個想法，不知道你有沒有更簡潔的表達方式：現在產品的價值單位（Unit of Value）就像是“工作證明（Proof of Work）”或“使用證明（Proof of Use）”。

當團隊里有人給我提交一個合并請求時，我并不一定想看測試是否通過了，我會默認它已經過了，我更想讓你發一個你使用它或你的智能體使用它的 Loom（錄屏），這樣我就能判斷它到底好不好。你怎么看？

Mike Krieger：是的，我認為這大概分為三個層次。第一層是：“Claude，向我證明你以某種方式運行過這個功能。”

我已經開始在所有的Prompt（提示詞）里這么做了，在它開發功能結束時，我會說：“在提交PR之前，請向你自己也向我證明它按預期工作了，找個合適的方法來展示。”這實際上要求你改變自己的構建和腳手架方式，思考什么才是讓Claude簡潔地測試這種變更的正確方法。否則它最喜歡說：“我看過代碼了，看起來很棒。”我會回它：“代碼是你寫的，我不信你，你得去測一下。”

第二層就是你描述的，對每件事都有某種證明，證明它是否按預期運作，以及是否符合你的意圖。Claude或任何模型都會替你做很多決定。

有時團隊里的工程師提交PR，我會問：“你為什么要選這個方案而不是那個？”很多時候答案是他們沒選，那是模型做的選擇。那個選擇可能還算合理，但它是最優選嗎？它符合我們的范式嗎？我覺得這不只是“工作證明”，更是“深思熟慮的證明（Proof of Thoughtfulness）”——你真的思考過這個問題嗎？

昨天我跟一個工程師聊天，他說：“我知道你會問我很多細節，所以我仔細檢查了Claude做的工作，以免被你問住。”我不會對每個PR都這么苛求，但如果涉及到“我們要重構這個系統，會引入這些新原語”，那我就得確保這些原語是好的，且你已經想通了它們之間的關聯。否則，你很容易構建出一座你自己都沒完全察覺到的“假設之塔”。

Dan Shipper：我今天也有完全相同的經歷。我通過Vibe Coding做了 Proof，它現在增長很快但也經常掛掉。所以我過去12小時一直在修它。我們在Every內部有一個小突擊隊幫我修，我得帶他們上手。

我當時在想，我該怎么解釋這個代碼庫是怎么運作的？為此我不得不跟模型來回溝通好幾次，說：“好吧，幫我定義一下這些術語，幫我弄清楚怎么解釋這些東西，好讓我看起來不像個徹頭徹尾的白癡。”因為我對代碼只有部分理解，遠沒達到以前那種必須了如指掌的程度。這是一個完全不同的課題：我還需要知道得那么細嗎？界限在哪里？這很難說。

Mike Krieger：這可能引出了另一個話題。我還沒試著把這個表達清楚，所以請包容一下。確實，有些產品你用起來覺得底層很魯棒（Robust）（系統的抗干擾能力或穩定性），而有些產品你用起來會覺得只要點錯一個地方，整個東西要么卡死，要么變慢。

在Instagram時，我們的第一版私信（Direct Messaging）功能推出時，誰知道你發出的消息對方能不能收到？我當時自己寫了一套實時系統，結果經常崩掉，你絕對不會放心用那種系統去發重要消息。

但當我們構建V2時，我們非常強調穩定性，我們發一條消息，雖然可能達不到WhatsApp那種你在荒郊野嶺只有一格信號也能發出的水平，但至少我加載消息時它得感覺很扎實。

這只是一個小例子，但我認為這是一個我們需要解決的問題，即讓它成為發布任何東西的必要標準。你建的東西是像建在沙灘上，還是像有一根堅實的樹干？“智能體原生”的部分甚至增加了另一個維度：我能不能推它一把，它會倒嗎？還是它能靈活應對？我覺得這就是2026年軟件設計的藝術與科學。

人人都能開發產品，技術人員是否有必要存在

Dan Shipper：如果那是標準，我完全同意，那是我們要達到的目標。那么隨著模型變得越來越好，你在招聘和團隊架構上做了哪些改變？比如對我們來說，我們的一個產品Spiral，我們剛聘請了一位新的GM（總經理），他技術能力一般，但在產品感和寫作審美上極強。Spiral是一個寫作產品，我們現在能雇這樣的人，而一年前不行，那時的編程模型還不夠好。

圖片來源：msn

但副作用是，如果沒有一個在技術細節上非常鉆研的人，產品可能感覺沒那么穩定。你怎么看現在實驗室團隊里開發產品的人選？隨著時間的推移，這發生了什么變化，未來又會如何變化？

Mike Krieger：我很喜歡這個問題。我認為你其實被拉向了兩個方向，但它們都很重要。一方面是原語（構建復雜系統的最小、最基本單元）和架構的魯棒性，這仍然需要資深技術力量。我跟人開玩笑說，我以為我在分布式系統方面的技能沒用了，但實際上這些可能是最有用的技能——去推理和思考。

上周我還跟Claude辯論了很久，爭論我建的系統是否需要Redis（一個內存數據庫，主要用于緩存、會話管理、消息隊列等），還是只用Postgres（關系型數據庫）就行。那是一場健康的辯論，我曾使用過這些技術，有實戰經驗。

但魯棒性的另一方面是，你是僅僅通過不斷修改系統提示詞和增加指令來掩蓋問題，還是正確地架構了整套工具？后者同樣重要，這可能是GM能發揮巨大價值的地方。

即使是在提示詞方面，我也見過有人陷入這種開發循環：出一個提示詞，系統報錯，改提示詞。

模型的本能傾向是不斷往提示詞里塞東西，最后你會得到一個像給新員工下達了100條指令的東西：“永遠用Markdown回答，除非……”，員工會想：“我只會記得你說的最后一件事。”所以你需要重新思考，這是否應該是兩個不同的工具？是否應該是兩個context（上下文）更小的智能體協同工作？

回到你的問題，我們甚至在實驗室也會招聘有系統專業知識的人，盡管實驗室是以0到1的原型開發為主。但魯棒性很重要，而且誰能幫著理清系統權限、配置和早期測試？這些事情即使對Claude來說也很難，因為它不能修改自己的權限（出于安全原因），但技術人員可以做到。

在魯棒性（系統抗干擾能力）方面，我們讓產品團隊與我們的應用AI團隊（Applied AI teams）合作。應用團隊每天都在一線幫助客戶迭代提示詞，我們發現自己現在是這些努力的“零號客戶”，因為我們自己就有很多AI驅動的產品。

Dan Shipper：那中間層呢？不是底層架構，也不是提示詞，而是UI（用戶界面）和流程（Flow），誰來做這些？

Mike Krieger：這是個好問題。我們發現，有些轉入實驗室的人以前是專注于網站潤色的，他們帶來了一種完全不同的方法。原型可能看起來是“大眾臉”的好看，但他們能讓它看起來有品牌感，有細節。第二點是設計師。我們的設計師現在更多地轉向了“設計師兼構建者（Designer and Builder）”的角色。并非所有人，但大多數是。

我們在實驗室里其實沒有很多全職設計師，但有的那幾位，他們寫的代碼幾乎和工程師一樣多。我們發現這種“聯合創始人模式（Co-founder model）”非常有效，設計師提出原始創意并推進，傳統軟件工程師緊隨其后“鋪路”，確保一切能正常運行。

衡量一個產品項目是否值得投入的最佳信號，是團隊中有人擁有那種“撞破南墻不回頭”的信念（Conviction）。這種信念可以來自設計師，也可以是產品導向的工程師。

如何處理企業需求與AI快速變革之間的矛盾

Dan Shipper：我想問問關于實驗室，以及給創業者的建議。你提到的企業端觀點引起了我的思考，如果你現在向企業銷售AI產品，產品現在很先進，但很快也會過時。而客戶想要那個“過時”的穩定版。但作為創業者，這很冒險，如果你只優化那些大型上市公司的需求，你很容易被競爭者顛覆。你怎么看這個問題？

Mike Krieger：這確實是個好問題。我們現在的做法是：明確這列火車會繼續高速前進，我們會提供企業級開關，但核心產品會不斷演進。這是合作的前提。公司也理解，只有相信我們會持續進化，他們才敢簽一年的合同。

此外，公司應該更愿意重寫技術棧。以前你會為了早期的不同需求而放棄某些客戶，那是按年計算的周期，現在是按月。你必須愿意推出V3、V4版本，對現有邏輯進行大重構。你要么自己顛覆自己，要么被下一家從頭開始思考的公司取代。

老婆吃醋的“數字伴侶”，智能體也有“人設”

Dan Shipper：你對OpenClaw怎么看？

圖片來源：dougvos

Mike Krieger：它有一種獨特的魅力，能讓人們看到一種本來就可能已經實現、但現在是每個人都能嘗試的東西。它就是模型工具化最純粹的表現，給模型工具，讓它自己去跑。這是一個很酷的時刻，人們既看到了潛力，也看到了坑，比如“噢，它做了一件我沒想讓它做的事”。

最搞笑的是我一個朋友說：“我覺得我老婆在嫉妒我的OpenClaw，因為我跟它聊得太多了。”當人們在這些東西里擁有大量上下文并能訪問工具時，會產生非常深刻的個人關系。現在最有趣的產品問題是：在完全開放的“YOLO”（放飛自我）產品和極度受限的產品之間，什么樣的形態既有用又安全？

Dan Shipper：沒錯。另一個有趣的點是它的個人色彩。比如我女朋友的 Claude叫Shelly，我的叫R2C2。它感覺是“我的”，有自己的名字和性格，這種歸屬感很重要。你怎么看？

Mike Krieger：我這周剛跟人聊過，未來的模式是單一入口，還是一個智能體團隊？我認為單一入口更自然，因為它成了你的協調員。這里還有一種“宜家效應”：目前OpenClaw配置起來還挺難的，所以當你搞定了它，你會覺得“是我賦予了Shelly生命”。

而且我發現，在我使用Claude Code時，我強力提示它：“不要自己做太多工作，委托給子智能體（Sub-agents）。”這樣運行循環（Run loop）就始終保持開啟，方便你隨時交流。這讓它感覺更像是一個正在和你交談的人，而不是一個被指派任務后就消失五分鐘去處理復雜工作的工具。

Dan Shipper：完全同意。我們也在Slack里搞這種模式。我們發現一種模式很酷，就是我有我的智能體，我用它做事，別人看我用它，因為他們信任我，而智能體又根據我的反饋進行了調整，所以這種信任轉嫁到了智能體身上。最后公司里會形成一個“影子組織架構圖”，每個人的Claw都因其主人的專長而聞名。

Mike Krieger：這非常有道理。這里面有很多關于隱私和知識共享的研究課題，即我的智能體知道我多少，又會對別人披露多少。

歡迎在評論區留言~如需開白請加微信：YPYP01234567