Instagram 共同創辦人 Mike Krieger，現在在 Anthropic 共同領導 Labs 團隊，上了 Dan Shipper 的 Podcast，聊了將近一個小時。
聊的核心問題是：AI 讓造東西變簡單了，但為什麼好產品反而更難做了？
這集 Podcast 的資訊密度相當高，很多觀點是從實戰中長出來的，跟上週我們聊的 Anthropic PM Cat Wu 那篇文章《Anthropic 產品經理：PRD 已死，原型萬歲》形成了很好的互補。
Cat Wu 講的是 PM 角色的變化，而 Krieger 講的是更底層的東西：產品本身應該怎麼被建造。
室內的樹
Krieger 開場講了個故事。
他讓 Claude 重建了 Bourbon，就是他和 Kevin Systrom 在做 Instagram 之前花了將近一年開發的那個產品。
結果，僅兩個小時後，功能齊全，做完了。
Claude 甚至還自己加了濾鏡功能，因為它知道 Bourbon 後來變成了 Instagram，所以提前把濾鏡做進去了。
但 Krieger 的感慨倒不是「好快好厲害」。他說的是：
當年我們花了一年做 Bourbon，最大的收穫其實是發現它太複雜了，然後花三個月簡化出了 Instagram。如果兩小時就能做完，你根本不會經歷那個「發現該砍什麼」的過程。
Dan Shipper 接了一個比喻，相當精準。
他說，樹在室內長大，如果沒有風吹，就不會長得結實。因為樹幹需要風力反覆推拉才會變粗變強。在室內種出來的樹，看著是棵樹，但它是歪的、脆弱的。
AI 加速開發，就像把樹種在了室內。
你可以幾小時就長出一棵完整的樹，但它沒有經歷過風吹雨打。沒有用戶回饋的打磨，沒有一步步疊代建立起來的直覺，整棵樹看著完整……其實一推就倒。
Krieger 特別認同這個比喻，還補了一個更具體的：
就像一部電視劇，你是一集一集看下來的，慢慢認識角色、理解關係。但如果有人直接把你扔進最後一集，你會一臉懵：這些人是誰？他們之間什麼關係？為什麼大家都在哭？
產品也是一樣的。 一個功能接一個功能地加，用戶和開發者都在過程中建立理解。但如果一夜之間冒出來一個「完整」的產品，所有都會迷失。
Vibe coding 的坑
Dan Shipper 自己也踩過這個坑。
他做了一個叫 Proof 的產品，一個 agent native 的協作行銷編輯器。第一版完全是 vibe coding 做出來的。
Vibe coding 太好玩了，太上癮了。我就一直加功能，做這個，做那個……最後做出來一個怪物，不好用。
後來他看到另一個產品 Monologue，一個極簡的語音轉文字 App，只做一件事，做得極好。他受到啟發，把整個產品推翻重來，只留了一個核心功能：可分享的 Markdown 連結。
結果這個極簡版本在公司內部開始病毒式傳播，上線後直接爆了。然後他熬了一整晚修 bug，感嘆自己太老了扛不住了。
Krieger 說他在 Anthropic Labs 也遇到了一樣的問題：
我們最近有個專案，V1 之前就過度建設了。因為你可以嘛。哦，這個功能？一個 PR 就搞定了。那加上吧。然後你去吃個午飯回來，發現 Claude 又做完一個，那也加上吧。
最後我們搞出了一個功能矩陣，測試起來極其困難，給用戶解釋也講不清楚。
「你可以」和「你應該」之間，差距從來沒有這麼大過。
重寫成了日常
但 Krieger 並沒有因此變得保守。相反，他說 Anthropic Labs 的做法是：接受重寫，把它當成常態。
以前軟體產業有個經典教條：不要重寫。Fred Brooks 在《人月神話》裡說過，重寫會丟失第一版裡累積的所有隱性知識。
Krieger 承認這話有道理，但時代變了。
以前重寫意味著一年的工程投入可能付諸流水。現在呢？上週做的，這週重來。重寫的代價已經不是過去那個量級了。
他們在 Labs 裡已經有好幾個專案經歷了這個過程：做出完整的 V1，發現核心假設有問題，推翻，幾天之內做出 V2。
這和 Cat Wu 說的「模型升級即產品升級」是同一個邏輯。 每隔三到六個月，你可能就得扔掉一半的程式碼。如果團隊太大，協調成本就會讓這件事變得不可能。如果只有一兩個人，反而能迅速轉向。
Dan Shipper 也有同感：
每三到六個月扔掉一半產品。如果是一個人的 GM 意識到這件事，馬上就能動手。但如果要協調一大群人……就卡住了。
Agent native
這集 Podcast 裡反覆出現的一個詞是 agent native。
Dan Shipper 說他從 Claude Code 身上學到了什麼叫 agent native：一個 agent 能做用戶能做的一切事情。產品可客製、可擴展，設計者沒有預設所有用途，用戶和 agent 自己去發現怎麼用。
Krieger 對這個概念做了更深一層的拆解。
他說 Claude Code 做到了這一點，但 claude.ai 還沒有。他舉了個例子：有人在 claude.ai 的 Project 裡建了個文件，然後說「幫我把這個加到專案知識庫裡」。Claude 的回覆是……給了一堆手動操作步驟。
這應該是它原生就能做的事情。一個 2024 年的產品，還沒有把「agent 能操作自身所有組件」這個原則刻到骨子裡。
而 Claude Code 是 2025 年的產物，從一開始就內建了這種思維。
測試 agent native 產品也完全不同。 你沒法寫傳統的端對端測試，因為 agent 的行為是不可預測的。Krieger 有一次讓 Claude 去測試一個 agent native 的 iOS App，結果 Claude 跟 App 裡的聊天功能聊了起來，自己跟自己對話：
「我今天過得不太好，老闆對我很兇。」
「哦，很遺憾聽到這個。」
來來回回聊了好幾輪。
你不可能為這種場景寫單元測試。但這恰恰就是 agent native 產品會遇到的真實狀況。
2026 年軟體設計的核心藝術，就是在開放性和穩健性之間找到平衡。
兩人一組
Anthropic Labs 的團隊結構也值得細看。
每個新專案通常只有兩個人：一個有強烈信念的人（設計師或產品向的工程師），加一個能把原型變成穩健系統的工程師。
Krieger 說，他們發現了一個反直覺的規律：團隊擴張太快，反而是淨負面。
當想法還能裝在一個人腦子裡的時候，加人只會帶來協調成本。我做 Instagram 的時候就兩個人，光兩個人對齊就已經夠難了。
後來做 Artifact（他的第二個創業專案），他們一上來就招了八個人。結果還沒找到 PMF 就陷入了八個人開會討論「下一步做什麼」的困境。
Labs 的做法是：每兩週評估一次每個專案，決定加倍投入還是釋放人員回池子。 沒有人永遠綁定在一個專案上。
而那些被關掉的專案，復盤時往往有一個共同特徵：
團隊裡沒有人真的覺得這件事是「非做不可」的。大家都覺得「嗯，這個方向還行」。這種「還行」就是專案的死刑判決。
必須有一個人願意「撞穿牆壁」。 不一定對具體方案有執著，但對問題本身有近乎偏執的熱情。
這和 Cat Wu 描述的 Side Quest 文化異曲同工：功能並非來自路線圖，它從某個人「這事我非做不可」的衝動裡長出來的。
企業客戶的拉扯
做 toB 的產品在 AI 時代還面臨一個獨特的張力。
Krieger 講了個親身經歷。他當 CPO 時做了一次 claude.ai 的大改版，團隊挺得意的，發布了，也收到了不少好評。
然後就收到了一封憤怒的郵件：
我剛為公司錄了 20 小時的 Claude 培訓影片，現在介面全變了，我得全部重錄。
這件事給了他一個教訓：企業客戶的節奏和 AI 產品的演化速度，天然存在矛盾。
Anthropic 的應對策略是：
這輛火車會持續往前開，我們會在沿途提供企業級開關。你買的不只是今天的產品，而是我們會持續演化這個承諾。
對於創業公司，Krieger 的建議更激進：
以前你可能幾年才需要「解僱」一批老客戶來追求新方向。現在這個週期壓縮到了幾個月。三個月前的產品和三年前的產品，在 AI 領域可能差距一樣大。
這跟 Cat Wu 說的「PM 的 spec 成了易腐品」完全是一個道理。 六週前的需求，今天已經有了完全不同的解法。但企業客戶簽的可能是一年的合約。
OpenClaw 和個人 agent
聊到 OpenClaw 的時候，兩人明顯都來了精神。
Krieger 說 OpenClaw 的價值在於：讓人們第一次真正體驗到 agent 的可能性。 就像 Replit、Lovable 讓人體驗到「AI 能寫程式」一樣，OpenClaw 讓人體驗到「AI 能替你做事」。
但也有意想不到的副作用：
我朋友說他老婆開始吃 OpenClaw 的醋了，覺得他跟 OpenClaw 聊得太多了。
Dan Shipper 說他給自己的 Claw 取名叫 R2C2，女朋友的叫 Shelly。他說了一個很微妙的感受：
Claude 知道我，我也喜歡 Claude，但它不是「我的」。而 Claw 感覺是真正屬於我的，它有自己的名字，有反映我個性的性格。
Krieger 認為這觸及了 2026 年上半年最核心的產品問題：
在完全開放的 OpenClaw 和現在大多數產品的受限 MCP 呼叫之間，存在一個巨大的空白地帶。找到那個既強大又安全的中間形態，可能是今年最重要的產品問題。
「證明你想過」
Podcast 最後，Krieger 提了一個概念，我覺得值得單獨拿出來說。
他說現在 code review 的標準變了。以前看 PR，主要看測試有沒有過、程式碼品質行不行。現在還多了一層：proof of thoughtfulness，你有沒有認真想過 Claude 替你做的那些決策。
我會問工程師：為什麼選了這個方案而不是那個？很多時候答案是「這不是我選的，是模型選的」。可能還算合理，但它是最優的嗎？它符合我們的架構範式嗎？
有個工程師跟他說：
我知道你會問我很多問題，所以我提前把 Claude 寫的程式碼都過了一遍。
Krieger 不是每個 PR 都這樣較真。但涉及架構重構的時候，他會追問。因為……
太容易堆出一座「假設的塔」了。 每一層看起來都合理，但你不知道地基是誰打的、打的時候在想什麼。
這其實呼應了 Cat Wu 說的「eval 成為 PM 新的核心產出」。當程式碼越來越多地由模型生成，人的價值就在於判斷：這些決策對不對？方向有沒有偏？
「建造鴻溝」再看
上週聊 Cat Wu 文章的時候，我提過一個概念叫「建造鴻溝」：以前從想法到產品之間隔著一條寬寬的河，現在河被抽乾了，但目的地變多了。
Krieger 這集 Podcast，其實是從另一個角度補充了這個畫面。
河確實被抽乾了。兩小時重建 Bourbon，幾天推翻重來 V2，一個 GM 從零到上線。但 Krieger 說的「室內的樹」告訴我們：快速抵達不等於真正抵達。
你可以一夜之間種出一棵樹，但那不是一棵好樹。
你可以一天做出一個產品，但那不是一個好產品。
好的產品需要風吹，需要用戶回饋，需要一次次「該砍什麼」的痛苦決策。AI 能幫你種樹，但不能幫你造風。
造風，依然是人的活兒。
相關連結：
• Podcast 影片：https://youtu.be/KRv9GpJYrUA
• Every 文章：https://every.to/context-window/instagram-s-cofounder-on-why-great-products-are-still-hard-to-build
• Dan Shipper 推文：https://x.com/danshipper/status/2036827118915485942
• 關聯閱讀：Anthropic 產品經理：PRD 已死，原型萬歲