對話 Instagram 創始人：Anthropic Fable 5 發佈， 純手工寫代碼的時代一去不復返

整理 & 編譯：深潮 TechFlow

嘉賓：Mike Krieger，Instagram 創始人

主持人：Dan Shipper

播客源：Every

原標題：Mike Krieger Lets Fable 5 Code While He Sleeps

播出日期：2026 年 6 月 11 日

要點總結

Mike Krieger 曾作為 Instagram 的聯合創始人，親手締造了過去二十年裡人類世界最具影響力的消費級應用之一。而今天他正在“智能體原生（AI-native）”產品開發的最前沿，作為 Anthropic Labs 的掌舵人，他帶領團隊死磕一個終極命題：當把世界上最頂尖的 AI 模型交到真正的開發者手中時，技術的能力邊界究竟能被推向何方？

在 Fable 正式發佈前的五個月，當他在內部第一次拿到這款模型的體驗權限時，那種震撼與失速感讓他至今記憶猶新。“得，我覺得自己又成了一個徹頭徹尾的新手，”他當時這樣對團隊自嘲。他突然發現，自己過去幾十年沉澱下來的關於效能提升、研發戰略乃至時間管理的經驗法則，在這一瞬間全部宣告過時。模型的進化速度，已經徹底甩開了他原有的工作流。

在本期節目中，主持人與 Mike Krieger 展開了一場深度對談，帶大家一同窺探：與 Fable 這樣跨時代的硬核模型並肩作戰、共同構建軟件，究竟是一種怎樣的體驗？在這場人機共生的新常態下，又催生出了哪些全新的研發律動、嚴峻挑戰以及充滿想象力的終極可能？

精彩觀點摘要

Fable 如何徹底重塑了 Mike 的工作流

• “真正的認知升級來自幾周高強度的持續使用，而絕非第一天的嚐鮮體驗。……隨著相處時間變長，人們突然意識到：‘我之前對它的壓榨還不夠狠。我得再往前推一步，重新思考這一代模型的能力邊界到底在哪。’”
• “現在的正確姿勢是：向它傳達更宏觀、更充分的意圖，然後徹底放手讓它去跑。它不僅能一次性給出令人驚豔的成果，更可怕的是，它能理解這個功能後續的演進方向以及整個項目的全局上下文。”
• “最讓我被折服的，是它自動閉環的能力。比如它會這樣思考：‘Mike 讓我今晚跑一個複雜任務。但我被卡住了，因為遠程服務器掛了。那好，我先自己寫個 mock 後端頂上去……’對我來說，能夠把這種級別的任務委託出去，並且完全信任它的最終產出，這種體驗極其震撼。”
• “過去我們總把這類模型比作‘助手’或‘伴侶’，但現在，它更像是一個真正可以背鍋、可以交付大量核心工作的‘硬核隊友’。”

什麼時候用 Sonnet，什麼時候用 Fable

• “那完全不是一個量級的體感。這甚至都跟每秒輸出多少 Token 無關，而是這道題到底需要被塞進多少腦容量去思考的問題。有時候，一個簡單的答案根本不需要那麼多加戲的深度思考。”
• “絕大多數時候我扒拉 iOS App，大概率不是為了幹那些需要驚動 Fable 的重活。……那種‘這問題根本配不上 Fable，我應該叫 Sonnet 出來答’的微妙心態，我最近確實深有體會。”
• “Fable 也是我遇到的第一個會讓我主動去調節‘努力程度’（Reasoning Effort，推理力度）的模型。……以前用 Opus 的時候我基本不調這個，因為那時候模型能伸縮的彈性區間沒這麼大，但 Fable 的跨度真的可以拉得很寬。”

Fable 5 催生的 Agent-native 架構

• “所謂的 Agent-native 架構，它的第一階段是：產品裡的每一個核心組件和數據，都必須對 Agent 保持完全開放，並且都有對應的工具調用接口。這正在迅速變成軟件行業的溫飽線——雖然可悲的是，現在市面上絕大多數軟件連這一點都做不到。”
• “在 App 里長按聊天按鈕，就會喚醒我們的託管 Agent 來接收‘代碼修改指令’……我帶娃在外面玩的時候，發現‘這個懸浮按鈕在 iOS 上的位置太靠下了’，我直接在 App 裡對它說一句，它自己就跑去後臺把代碼修了。”
• “Claude 到底該如何嵌入軟件？它不應該只停留在‘使用’層面，它更應該深度嵌進軟件的‘構建’骨髓裡。”

構建成本已經坍縮

• “回顧 Instagram 的 V1 版本——功能確實比我這週末做的媒體追蹤器要多一些，但絕對沒有數量級上的本質差異。而當年做出那個 V1，我和 Kevin 大概連著爆肝了五個通宵……而現在呢？構建時間確實被縮短到了令人髮指的地步。”
• “從‘意圖’到‘執行’之間的那條鴻溝，對於不懂代碼的普通人來說，已經被拉平了。……這是我人生中第一次，感覺到自己腦子裡想的東西，和現實世界裡存在的東西之間，竟然可以毫無距離。我直接就能把它做出來。”
• “人類的創造力是無窮無盡的，而我們今天在做的最了不起的一件事，就是無限地擴大了‘有能力將心中所想變為現實’的群體邊界。”

軟件工程死了嗎？

• “軟件工程的內涵已經完全變了。它正在經歷一場翻天覆地的劇變。……純敲代碼的匠人時代，大概率真的已經一去不復返了。”
• “高級工程師的角色依然不可替代：你需要靠多年的事故響應經驗去保持絕對冷靜、全量收集日誌數據、實施緊急止血，然後再去推演根本性的長效修復方案。”
• “以前硅谷流行一句話叫‘用代碼贏下爭論’（Code wins arguments），我個人其實一直不太感冒，因為它潛臺詞在說誰會寫代碼誰就掌握了話語權。但現在，事情反過來演進得非常有意思：有時候我們對產品的某個走向相持不下，結果經常是某個不寫代碼的 PM 跑過來說：‘我剛才自己動手搓了一個 Demo……’這瞬間就開啟了一個完全不同的高維對話。”
• “最明顯的特徵就是恐怖的開發並行度，以及團隊對工作流進行高階抽象的絕對剛需。但唯獨有一件事從始至終沒有變過，那就是人類對產品的‘所有權與責任感’。”

驗證的機制與價格

• “現在的‘成本’已經進化成了一個多維度的概念——你要算的不僅是‘單次提問的成本’，更是‘徹底把一件事辦妥的綜合成本’。Fable 最讓我驚豔的地方恰恰在於後者：它總是傾向於一次性把事做對，不需要我坐在電腦前跟它大戰八九個回合。”
• “適應這種新常態，搞清楚怎麼跟它共事，是我們所有人都需要學的。……每次我搭東西的時候，我怎麼確保 Claude 的每一個 PR 都附帶了照片或視頻——不管是 iOS PR 還是 UI 層的改動。這幫你獲得了很多信心。”
• “視頻是給 Claude 的一個極度未被充分利用的工具。我最近在做一個原型：把 Claude 構建出來的東西做成視頻錄像交給它，配合 FFmpeg，看著它自己逐幀分析，然後說‘這個動畫有卡頓，我去修’。截圖永遠不會捕捉到這個，因為截圖錯過了那個瞬間。”

動態工作流

• “在前幾代模型的溫飽線裡，項目往往存在一個‘複雜度天花板’。一旦你的業務代碼或者邏輯堆疊到了一定體量，大模型就會開始‘顧頭不顧屁股’……但現在，這位不懂代碼的女同事，在 Fable 這個級別的模型加持下，已經把她的系統在後臺連著養了幾個月。你能清晰地看到那個軟件像一個活生生的有機體一樣，在 AI 的灌溉下持續生長、生長、瘋狂進化。”
• “工作流是一個好的中間地帶，你用 chat 來編排它，但它是用代碼表達的，然後在一個乾淨的 UI 裡面執行，每一步都在展示發生了什麼。我覺得我們以後會用類似的方式來把長視野的工作和 chat 連接起來。”

Fable 如何徹底重塑了 Mike 的工作流

主持人 Dan Shipper： 本期邀請到的嘉賓是 Mike Krieger，他既是 Anthropic Labs 的負責人，也是 Instagram 的聯合創始人。Mike，我特別想聽你聊聊深度使用這個模型後的真實體感。當一個如此強大的模型發佈時，如果有一個每天都在重度使用它的人出來說："它在這些地方強得離譜、在哪些地方切實改變了工作流，而在另一些地方其實也就那麼回事"——這能幫大家真正想明白，技術到底該怎麼融入自己的日常生活。

Mike Krieger:

確實如此。這段經歷本身就很有意思。在 Fable 正式發佈前的幾個月裡，我們內部其實已經用上了幾款 Mythos 級別的模型。當時我很期待看外部開發者會用它們做出什麼，但正如你所說，真正的認知升級來自幾周高強度的持續使用，而絕非第一天的嚐鮮體驗。

我們在之前的模型上也經歷過這種認知重塑。去年十二月底到今年一月初，大家集中使用 Opus 4.5 和 4.6 的時候，隨著相處時間變長，人們突然意識到："我之前對它的壓榨還不夠狠。我得再往前推一步，重新思考這一代模型的能力邊界到底在哪。"

主持人 Dan Shipper： 我們 Every 團隊內部其實已經有一些同事在用了。有人反饋說："我覺得自己需要一套全新的技能樹才能駕馭這個模型"，尤其是那些非技術背景、偏知識工作型的同事，他們甚至有點無從下手；而那些做 Agent（智能體）編排的同學則感嘆："要學的新東西實在太多了。"

Mike Krieger： 你提到"轉換工作流"這一點切中了要害——這不僅是指具體的操作步驟，更指觀念上的轉變。說來也巧，這個模型的出現剛好趕上我工作變動的窗口期：我當時剛從 CPO（首席產品官）轉到 Labs，重新切回了開發者模式。大概轉過去一個半月到兩個月的時候，內部第一次跑通了這類模型。我坐在電腦前心想："得，我又成新手了。"因為我發現自己以前寫 Prompt 的習慣，甚至拆解任務的思維方式，在這個模型面前已經完全過時了。

你的時間尺度感和交互模式都得進化。換作以前，我可能會說："我有個功能想法，咱們先從第一步開始——"現在絕對不能這樣了。現在的正確姿勢是：向它傳達更宏觀、更充分的意圖，然後徹底放手讓它去跑。 我記得在三四月份的時候，它表現出的能力就已經很震撼了——它不僅能一次性給出令人驚豔的成果，更可怕的是，它能理解這個功能後續的演進方向以及整個項目的全局上下文。

而且這種進化完全沒有停止。今天早上我還和人聊起工作——在飛機上時，我意識到"絕大部分工作我其實都可以遠程搞定"。我甚至不再焦慮 Wi-Fi 會不會斷，因為只要我在斷網前給它設定好正確的上下文和指令（比如一個循環執行的命令），它自己就能把事情盯到底。

過去兩個月裡，我經常經歷這樣的高光時刻：睡前跟 Claude 道個晚安，甩給它一個複雜的任務，第二天醒來發現它已經全部搞定了——通常凌晨兩點它就完成了主體，剩下的四小時全花在打磨細節上。

最讓我被折服的，是它自動閉環的能力。比如它會這樣思考："Mike 讓我今晚跑一個複雜任務。但我被卡住了，因為遠程服務器掛了。那好，我先自己寫個 mock 後端頂上去，把這個問題記錄在文檔裡，先把整個流程跑通、存盤，等明天服務恢復了再修好。"對我來說，能夠把這種級別的任務委託出去，並且完全信任它的最終產出，這種體驗極其震撼。

當然，你事後肯定還要去審查結果——這涉及到一個完整的驗證機制，我們一會兒可以展開聊聊，因為那是閉環中至關重要的一環。但這確實逼著我重新思考：面對這樣的模型，到底什麼才叫"高效"？過去我們總把這類模型比作"助手"或"伴侶"，但現在，它更像是一個真正可以背鍋、可以交付大量核心工作的"硬核隊友"。

主持人 Dan Shipper： 那你現在的日常工作流到底長什麼樣？我注意到一個現象：如果你丟給它一個宏大任務，對著它長篇大論，然後讓它自己跑幾個小時甚至過夜——這時候它的表現是最強的。但日常面對一些瑣碎的小任務時，它又顯得太慢、太貴，讓人不太想用。在實際工作中你是怎麼權衡的？它在你的技術棧裡處於什麼位置？

Mike Krieger:

我現在更多把它用在前期的架構規劃和方案對齊上。這是一個很有意思的轉變，也是目前所有模型都需要繼續啃的硬骨頭。

在這方面，我很感激當年做 Instagram 的經歷——從最初在一臺洛杉磯服務器上草草搭起最簡版本，到後來做海量併發、做規模化，再到最後整體併入 Facebook 的基礎設施。這個過程會讓你培養出一種直覺，即"在項目的哪個階段，應該用什麼級別的架構抽象和複雜度"。

所以，我仍然會和 Fable 保持頻繁的來回切磋。有時候它丟出來一個看似完美的實現方案，我會點它一下："我確實計劃近期就把這個推上線——我們得考慮單機以外的承載能力。"這種雙向互動非常重要。但在做架構規劃時，我通常會直接讓它生成一個 HTML 頁面來視覺化我們討論的內容，以便我分享給團隊。哪怕是一份 Markdown 文件也行，但我更喜歡帶圖表的形式。

這就形成了一個很有意思的範式：和它一起把事情想透、規劃好，然後產出一份文檔去對齊團隊。 既然現在大家構建原型的速度被極大地壓縮了，你就更需要前置的共識和對齊——即便你打算先"小步快跑"做個 Demo 出來，再反向推導出更嚴謹的系統架構，前期的溝通也至關重要。而這恰恰也是人類的思考與協作仍然深深嵌入整個流程的地方。

到了執行階段，無論是利用夜間還是大塊的白天時間，讓它去分頭攻克不同的任務模塊，意味著我同時維持著比以前多得多的併發會話。我有時喜歡開著一個長時間掛著的 Claude Code 會話，讓它把任務全部 fork（派生）給後臺的子 Agent 去跑，這樣主線程就能隨時響應我的新指令；有時我乾脆在瀏覽器裡同時開著五六個 Tab 頁，讓它們各自處理長週期的複雜任務。

這種具備長線視野、有一種"別擔心，交給我，需要花點時間"的運作模式，裡面確實大有可為。我們目前也在產品層面琢磨怎麼更好地支持這種體驗——你肯定希望兼顧"即時響應"和"長線掛機"這兩種狀態，它們之間的交互方式非常有意思。我個人的偏好是：手頭至少保留一個高上下文且響應極快的 Claude 窗口，有一種"我隨時待命，你一句話我就能原地啟動或派生子任務"的直覺。

什麼時候用 Sonnet，什麼時候用 Fable

主持人 Dan Shipper： 那比如你正走在路上，突然有個問題——你會去掏出 Fable 嗎？這感覺會不會有點像"拿火箭筒打蚊子"？還是說你會頻繁地在不同模型之間來回切？

Mike Krieger:

前陣子我確實是幹什麼都用 Fable，然後體驗就跟你說的一模一樣——你盯著屏幕，看著它在那兒死命地想啊想。

直到上週，我想查一個讓我都有點不好意思的簡單問題，是關於 NBA 總決賽的。當時我切到了手機移動端的 Sonnet，瞬間反應過來："噢對啊！我以前查這種快問題都是用 Sonnet 的。"那完全不是一個量級的體感。這甚至都跟每秒輸出多少 Token 無關，而是這道題到底需要被塞進多少腦容量去思考的問題。有時候，一個簡單的答案根本不需要那麼多加戲的深度思考。

對我們的產品團隊來說，這同樣是一個非常值得玩味的問題。總的來說，你肯定不希望讓用戶每天在前端糾結該選哪個模型。理想情況下，從長遠來看，我們可以把它們收攏到幾個極其直觀、開箱即用的場景桶裡；或者乾脆直接按交互界面來做分流——因為說實話，絕大多數時候我扒拉 iOS App，大概率不是為了幹那些需要驚動 Fable 的重活。所以在界面端做一層無感的模型固定，可能會是個思路。我們接下來得好好探索這在產品層面上究竟意味著什麼。但那種"這問題根本配不上 Fable，我應該叫 Sonnet 出來答"的微妙心態，我最近確實深有體會。

你說得沒錯，對於那些高頻、細粒度的互動型任務，Fable 會習慣性地自己往深了想。實際上，Fable 也是我遇到的第一個會讓我主動去調節"努力程度"（Reasoning Effort，推理力度）的模型——有時候我坐在那想："我只是想改個 UI 樣式，把它的努力程度調成‘中等’看個效果就行。"以前用 Opus 的時候我基本不調這個，因為那時候模型能伸縮的彈性區間沒這麼大，但 Fable 的跨度真的可以拉得很寬。

Mike 週末做的媒體追蹤器揭示了 agent-native 架構的什麼

主持人 Dan Shipper： 你能給我們看看你用它做過的東西嗎？

Mike Krieger:

這一輪新模型發佈時我們做了一件事——鼓勵團隊全員在自己的個人賬戶上用它，尤其是利用週末時間。這還挺有意思的，因為 Anthropic 內部有很多定製的生產力工具，所以偶爾退一步，回到最純粹的狀態："我就用純粹的 Claude Code，週末給自己做點好玩的小東西。"這種感覺棒極了。

主持人 Dan Shipper： 你是在終端 app 裡還是桌面 app 裡跑的？

Mike Krieger:

好問題。我大部分時間還是泡在終端裡。但好玩的是我太太——她不是專業工程師，背景更偏 UX（用戶體驗）設計師和 PM（產品經理）——她反而是通過桌面 App 徹底愛上了 Claude Code。我覺得桌面 App 幫她屏蔽掉了不少底層高深的抽象概念。不過我自己做這個項目時，用的還是 Ghostty 和終端。

我當時就想要一個完美的"媒體進度追蹤器"——我平時打遊戲、追劇，還會收到朋友各種安利，我需要一個完全符合自己收納習慣的工具。我的兩個核心標準是：一、添加東西要特別容易，直接跟 Claude 語音或打字說一句，它自己去全網搜索、補全信息並分門別類放好；二、主動推送，比如有新一季或者遊戲續作，它能自動去找。

大部分 UI 是 Fable 一次性完成的，這已經很厲害了。但我在 Labs 今年一直在死磕的一條線索是：你怎麼能讓軟件團隊——現在這個團隊就是 Claude——和軟件本身貼得更近？

那是週六的一個早晨，我整個週末其實排滿了帶娃的行程，所以開發基本上全是"斷續式"的：帶孩子去爬山，回來，寫兩句，再出門。有時候在爬山途中我也會忍不住瞄一眼進展——雖然陪孩子時不該看手機，但在手機上遠程盯著它的任務跑到哪一步了，那種感覺真的很爽。

我當時冒出一個想法：能不能順手做個激進的實驗，讓軟件從它內部實現自我修改？

我讓它同時做了移動端和網頁端兩個版本。我本來就做了一個聊天交互界面，可以直接對 Claude 說"幫我把這個 URL 塞進追蹤列表"。但我希望所有的軟件都能進化出這種能力——我再也不想去各種層級複雜的菜單裡翻找功能了。

Dan，在很多層面上，我其實是在嘗試把智能體原生的架構推向最極致的邊界。

所謂的 Agent-native 架構，它的第一階段是：產品裡的每一個核心組件和數據，都必須對 Agent 保持完全開放，並且都有對應的工具調用接口。 這正在迅速變成軟件行業的溫飽線——雖然可悲的是，現在市面上絕大多數軟件連這一點都做不到。

我有一個很好的正面例子：前陣子有人給我安利了一部巴西神劇，講的是戈亞尼亞的放射性物質洩漏事件。那名字巨長巨難記，我當時就對系統含糊地提了一句，Claude 立馬幫我搜出來並精準歸類了。這體驗比我自己憑直覺去 Google 瞎找好太多了。

但我真正痴迷的下一步是：在移動場景下，直接從軟件內部去修改軟件本身，這會演變成什麼樣？

我做的——準確地說是我指使 Claude 做的——是這樣一種交互：在 App 里長按聊天按鈕，就會喚醒我們的託管 Agent 來接收"代碼修改指令"，然後利用 Vercel 的實時預覽（Live Preview）功能直接看效果。整個功能模塊幾乎也是一次性跑通的，非常酷，我後來還陸陸續續加了一些新點子。如果你是硬核玩家，你也可以去拉它的 Diff（代碼差異）視圖，或者點進託管 Agent 的對話歷史裡看它底層到底改了啥——不過我幾乎從來不看，反正對個人玩具項目來說，我根本不在乎它的長期可維護性（笑）。

這玩意兒用起來簡直太上頭了。我帶娃在外面玩的時候，發現"這個懸浮按鈕在 iOS 上的位置太靠下了"，我直接在 App 裡對它說一句，它自己就跑去後臺把代碼修了。配合 Expo 的開發工具鏈，它甚至直接在我的手機上完成了熱重載（Hot Reload），那一瞬間的體驗簡直絕了。

這個東西需要達到能抗住百萬用戶併發的生產級水平嗎？完全不需要。但它帶給我一種極佳的掌控感：你不需要在週末結束、合上電腦那一刻讓項目停擺——你可以一邊重度使用它，一邊在用它的過程中隨時改造它。這種端到端的實時閉環，讓你可以無限地迭代下去。

這不僅是 Fable 硬核工程構建能力的一次絕佳秀肌肉，也是你我一直在探討的那個終極命題的縮影：Claude 到底該如何嵌入軟件？它不應該只停留在"使用"層面，它更應該深度嵌進軟件的"構建"骨髓裡。

構建成本已經坍縮

主持人 Dan Shipper：我特別想讓大家意識到一件事：類似這樣的工具，你在十年、二十年前可能也能折騰出來，但絕對不是用這種方式。軟件的構建成本已經迎來了斷崖式的坍縮。 想想在當年做 Instagram 的時代，要把一個項目推到這種完成度需要砸進多少資源？現在又需要多少？幫我們量化一下這種時代的劇變吧。

Mike Krieger:

我經常會回想起那段日子。在 Instagram 成立早期，我一直覺得自己是一個效率極高的工程師——對移動端開發充滿激情，對產品方向有著極強的直覺。但即便如此，當年從腦海中的一個點子到最終把它完整實現出來，中間依然隔著至少四到五個通宵的死磕。那會兒熬夜就是我的家常便飯：修仙到凌晨四點，然後睡到中午——這種作息完全跟家庭生活絕緣，但那確實就是我當年的" Builder（構建）模式"。

回顧 Instagram 的 V1 版本——功能確實比我這週末做的媒體追蹤器要多一些，但絕對沒有數量級上的本質差異。而當年做出那個 V1，我和 Kevin 大概連著爆肝了五個通宵：我一個人扛下了所有的前端和後端，Kevin 負責搞定初期的圖片濾鏡。而且，這還是建立在我們倆都有著多年 iOS 開發經驗的基礎之上的。

更別提當年的迭代節奏有多憋屈了。產品上線一炮而紅之後，我們腦子裡攢了無數的新想法，但當時的所有精力都只能用來確保服務器別在大流量下掛掉，或者勉強擠出時間加一個微小的增量功能。就拿 Hashtag（標籤）功能來說，當時光寫完它就花了我整整一週，而你手裡其實還有一萬個其他想做的事情被死死卡在排期裡。

所以，這不僅僅是時間被壓縮了——雖然構建時間確實被縮短到了令人髮指的地步——更重要的是硬幣的另一面：你現在可以用一種極其絲滑、極具流動感的方式，去即時迭代你手裡已經有的東西。

而且，這種紅利已經開始外溢，遠遠超出了像我這樣的專業軟件工程師和創始人的圈子。在以前，如果你有一個絕佳的商業點子但自己不會寫代碼，你的選擇只有兩個：要麼找外包——這中間會經歷極其嚴重的信息失真和差強人意的交付；要麼就得去瘋狂融資。但現在，從"意圖"到"執行"之間的那條鴻溝，對於不懂代碼的普通人來說，已經被拉平了。

前幾天我收到內部一位同事的 Ping（消息）。我們幫她配置了一個內部工具，把 Fable 的能力和我們內部一些 MCP（模型上下文協議）的訪問權限打通了。她是做招聘（HR）的，她激動地對我說："這是我人生中第一次，感覺到自己腦子裡想的東西，和現實世界裡存在的東西之間，竟然可以毫無距離。我直接就能把它做出來。"

那一刻對她而言，絕對是一個具有里程碑意義的震撼瞬間。如果換在四五年前，她要是想用一個專屬的業務工具，要麼只能用各種現成的軟件縫縫補補瞎湊合，要麼就得去苦苦哀求內部工具團隊的工程師——而對方的 Jira 需求池裡可能還排著 50 個優先級更高的需求。但現在呢？她自己正樂在其中地在代碼世界裡開疆拓土。

這也是我覺得未來最值得期待的地方：人類的創造力是無窮無盡的，而我們今天在做的最了不起的一件事，就是無限地擴大了‘有能力將心中所想變為現實’的群體邊界。

軟件工程死了嗎？

主持人 Dan Shipper： 我完全贊同你的看法。但我估計現在很多人心裡都懸著一個終極疑問。聽了你剛才描述的這一切：軟件工程這門行當，是不是徹底完蛋了？

Mike Krieger:

應該說，軟件工程的內涵已經完全變了。它正在經歷一場翻天覆地的劇變。

如果你在做 Instagram 的那個年代問我："到底什麼是軟件工程？"我大概會告訴你：把那些棘手的設計難題想透、把系統架構搭好，然後把大把大把的時間消耗在 TextMate 或 Xcode 裡。去死磕 Django ORM（對象關係映射）的底層細節，然後部署上線、苦哈哈地修 Bug。現在這套流程裡的絕大部分環節都已經被顛覆了，並且正在加速向產品管理的邊界靠攏。現在，產品經理和工程師之間的那條楚河漢界，已經變得極為模糊。 這一點在我們自己的研發團隊裡表現得非常明顯。

但如果你能從"軟件工程"這個過於死板的字面定義裡跳出來，去審視更廣義的"軟件生產"或者"軟件開發"——而不是隻盯著純程序員寫代碼的那一小塊盤子——你會發現這個行業不僅活得好好的，而且正處於前所未有的核心地位。

Fable 的出現，真正讓我把對 AI 模型的信任帶到了一個新高度——我開始放手讓它去"跑通全自動閉環，甚至做合理的系統架構設計"。在技術執行這一側，AI 已經走得非常非常遠了。但"把控軟件這門手藝的靈魂"——比如你究竟是在滿足用戶的什麼痛點、你做出來的東西體驗到底夠不夠驚豔——這些頂層的判斷力，依然是極其純粹、無法被機器替代的人類特質。

當然，這種陣痛式的轉型，對很多人來說並不是無痛的。

在這個世界上，有太多人曾深深痴迷於"純手工編寫代碼"的匠人手藝。我自己當年就是這樣。"這個 Bug 憋了我三天，我今天解得真漂亮！"那種爽感是無法替代的。以前你甚至會在夢裡和代碼糾纏——如果你有過那種經歷，夢裡全是正在死磕的邏輯，醒來的一瞬間突然福至心靈抓到了解法。這種純粹的匠人時代，大概率真的已經一去不復返了。

我最近和一些我所認識的、業內最頂尖的硬核工程師聊天，他們都在向我表達一種強烈的複雜情緒：一邊是眼睜睜看著傳統手藝消亡的巨大失落感，另一邊又是"天吶，我現在的併發生產力簡直強到令人髮指"的極度興奮。

Anthropic 工程團隊今天如何工作

主持人 Dan Shipper：既然這個命題成立——軟件工程不僅活著，而且活得很好——那在 Anthropic 內部，你們自己的研發團隊在日常實際中，到底是怎麼開展工作的？

Mike Krieger:

這裡面有幾條非常清晰的線索，我可以結合完整的軟件生命週期以及我每天看到的研發日常來聊聊。

首先，依然有大量的"人肉對齊"。大家會聚在會議室裡，頭腦風暴討論 Cowork 下一步的演進方向，然後把藍圖拆解成不同成員的責任區。這一步依然至關重要，因為很多作為人類才能掌握的全局上下文，是目前的 Claude 無法隔空感知到的——比如這個產品的真實商業意圖、目前的研發暗線，以及有哪些即將下線、或正準備以一種極其微妙的方式整合進來的其他產品線信息。

雖然我們團隊裡給每個人都配備了多尊 Claude 巨塔，但落實到管理上，每個人頭上依然掛著 DRI（Directly Responsible Individual，直接負責人） 的頭銜，各自對產品的某個具體模塊負責。我認為這種機制在短期內絕不會消失，因為讓團隊"分佈式協作，合力把產品打磨好"的宏觀大局觀，與"我今天該怎麼讓 Claude 跑通這個具體任務"的微觀執行之間，存在著本質的鴻溝。我們雖然在極力推行極簡會議制，但這類前置的腦暴和對齊會議依然必不可少。

其次，是大量的"異步委託"。我們這裡的很多工程師都自己魔改出了一套個人儀表盤，用來監控自己的 Claude 軍團都在幹嘛："我的某個 Claude Code 跑到哪一步了？"、"有什麼卡在隊列裡等我審批？"、"有哪些 PR 需要我介入修改——因為被其他同事或者某個大模型的代碼審查給退回來了？"

現在，工程師們很大一部分精力花在了這種對工作的維護上。這裡面的有些協同工具我們正在推進標準化，但大部分還是保留了濃厚的極客個人色彩——就像以前程序員喜歡個性化定製自己的桌面窗口一樣，現在他們正在個性化定製自己的大模型工作流。

再者，是理解代碼在生產環境下的真實運轉狀況。這是目前大模型極力攻克的另一個前沿陣地。Fable 在這方面已經展現出了長足的進步，但還有很長的路要走：比如去深度理解代碼部署上線後，到底會發生什麼。系統會發生崩潰，會出現各種無法預料的怪異故障——說實話，Instagram 叢 2012 年到 2016 年的那幾年裡，我大半條命都折在處理這些線上事故和做架構規模化上了。在應對線上突發時，高級工程師的角色依然不可替代：你需要靠多年的事故響應經驗去保持絕對冷靜、全量收集日誌數據、實施緊急止血，然後再去推演根本性的長效修復方案。

最後我想強調的一點是："工程原型"在今天扮演的角色徹底變了。

你必須極其清醒地界定，手裡這個東西到底是一個 Demo，還是一個準備上線的生產級代碼。以前硅谷流行一句話叫"用代碼贏下爭論"（Code wins arguments），我個人其實一直不太感冒，因為它潛臺詞在說誰會寫代碼誰就掌握了話語權。但現在，事情反過來演進得非常有意思：有時候我們對產品的某個走向相持不下，結果經常是某個不寫代碼的 PM 跑過來說："我剛才自己動手搓了一個 Demo，雖然在 8 個細節上還糙得不忍直視——但你們看，這條路絕對能跑通！"這瞬間就開啟了一個完全不同的高維對話。

回過頭來看，我們現在的幾乎所有研發姿勢，跟六個月前相比都已經面目全非了。最明顯的特徵就是恐怖的開發並行度，以及團隊對工作流進行高階抽象的絕對剛需。

但唯獨有一件事從始至終沒有變過，那就是人類對產品的"所有權與責任感"。

驗證的機制

主持人 Dan Shipper：Fable 也很貴。我在測試它的時候，覺得自己就像是進了一家糖果店的小孩，興奮地喊著："我要這個、這個、還有這個！"但到了該結賬的時候，我每次按回車前都會心裡打鼓："這一下會不會直接燒掉我 100 刀甚至更多？"我覺得這種高昂的價格，實際上會給"誰能用它"以及"拿它來幹什麼"設下一道無形的門檻。你怎麼看它的商業性價比？

Mike Krieger:

在專業的軟件工程領域，這本賬其實算得最清楚。關於定價，內部確實有很多維度的考量。它確實比 Opus 貴不少，但如果你去衡量它單次交付的那些令人驚歎的工作體量，在很多商業層面上，它又便宜得像是在送，當然每個人心裡都有一本經濟賬。

從軟件團隊的角度看，如果第一階段是公司讓員工接受 AI 編程——模型還早，工具還不到位；第二階段是搞排行榜看誰用得最多，這會產生不太理想的激勵機制；那麼第三階段就是搞清楚誰用得最有效，讓這些人儘可能多花，同時有一個清晰的流程不產生浪費。

Fable 這個段位的模型完美契合第三階段的邏輯。如果你能持續拿出硬核的產出、在業務裡真正用它創造出真金白銀的價值，公司內部自然會形成一套正向的飛輪預算機制來無限支持你。

在個人使用這邊，我自己做測試也是用個人信用卡自費掏錢買自家的服務。這時候你確實會變得摳摳搜搜、更加謹慎。但有意思的是，我週末搓出來的那個媒體追蹤器，算下來其實也就比平時多花了一點點錢，做一個個人玩具項目完全沒有到動輒燒掉幾千刀的地步。

現在真正被價格卡住的，其實是那些不在大廠庇護下、對價格極度敏感的開源愛好者或獨立開發者（Indie Hackers）。我給他們的建議是：放手去跑，去看看它在不經歷無休止的"來回拉扯"下究竟能一次性交付多少東西。

現在的‘成本’已經進化成了一個多維度的概念——你要算的不僅是‘單次提問的成本’，更是‘徹底把一件事辦妥的綜合成本’。 Fable 最讓我驚豔的地方恰恰在於後者：它總是傾向於一次性把事做對，不需要我坐在電腦前跟它大戰八九個回合、絕望地喊著："不對！我不是這個意思！"

主持人 Dan Shipper：它最震撼我的一點就是，你甩給它一個宏觀任務，它交卷的時候，你會發現它連每一個犄角旮旯的細節都幫你推演過了，這種窒息的細膩感是以前在任何模型上都沒體驗過的。你能透露一點訓練上的內幕嗎？到底是什麼喂出了這麼恐怖的洞察力？

Mike Krieger:

在很多層面上，它是團隊大量工作的延續——我對我們的預訓練和 RL 團隊只有頂禮膜拜。對我來說最明顯的進化是一種"對整個系統的感知"，而不僅是對當前這段工作的感知。

我經常被它的一些神仙操作震撼到。比如它剛寫完一段代碼，會突然主動彈出一句："大佬，我知道在真實的生產環境裡，這裡的配置可能會不太一樣。你那個功能開關到底開了沒？要是沒開，我剛才寫的這玩意兒上線可不生效。"

或者看它對代碼審查的反饋做出反應——不管是來自人還是來自其他 Claude——它不簡單地說"哦對，這是個問題，我去修"。它真的會去想在當前保真度下要不要接受一個風險，或者反駁另一個審查者——往往就是另一個 Fable 模型——說"我理解你的意思，但我要反駁，我認為不對"。

讓模型有這種判斷力極其重要。如果我要指出它進步最大的地方，就是它不立刻膝蓋反射式地說"對對對，我去修"——它更像"讓我想一想。我還是不同意。"這種能力非常有用。

有 Claude Code 這樣的產品在市場裡是極其寶貴的，因為你有活生生的東西，人們可以說"這是模型做得好的地方，這是模型做得不好的地方"。我們把 Every 的夥伴們在我們最高優先級信任的反饋來源裡排在很靠前的位置，因為他們讓模型經歷反覆的多日高強度任務，這對我們思考下一代需要改進什麼非常關鍵。

主持人 Dan Shipper：Chat 是對這個模型來說最合適的交互界面嗎？它不是那種回合式的，更像是把事委派給某個人。這會怎麼影響你應該怎麼用它、或者你怎麼看這個界面？

Mike Krieger:

發送消息和接收消息這個基本模型不完全錯，但我們需要在一些方向上進化。

第一：你的筆記本電腦是正確的地方嗎？這就是之前我提到那個移動端對個人項目多麼好用的地方。Claude Code 的創造者在這些模型怎麼被使用上總是領先半步，大概九個月前我跟他聊天，他說："我把我大半的 Claude Code 的工作移到移動端了。"我當時持懷疑態度，但特別是到了 Fable 這個級別，因為它可以保持會話進行、我們在 Anthropic 有遠程開發機，所以第一個點是：把工作發生的地方跟我在討論工作的地方解耦。

第二點接著我之前說的：你怎麼拿 Fable 所有討論過、決定了、建議了的東西，讓它變得可以理解？這是我們正在思考的領域。有一些 skill 可以讓它畫圖表，但目前的聊天 UI 不足夠，Fable 有時候會給你超大量的文本，你要出去散個步才能準備好去理解它。我開始做的一件事是："你在這個事上的上下文比我多得多。咱們能不能倒回去——做更多對複雜性的漸進式披露？"

第三個是多人模式，這塊我們還在早期摸索。在某種程度上，因為我們有 DRI 和所有權區域結構，通常一個重要的活是流在一個人和幾個 Claude 之間的。但有些情況下就不那麼明顯——也許是事故響應，多個人在同時思考；或者多個交叉領域匯合的項目。聊天分享能解決一部分，但我覺得未來會有這種需求：你有一個獨立的 Claude，由一個人啟動做了很多工作，但它能不能跟團隊裡所有其他正在做的工作保持同步？這是下一個有趣且發掘不足的前沿。令人興奮的是，模型現在已經有能力成為真正的隊友，而我們幾乎是在因為沒有正確的抽象而拖它們的後腿。

主持人 Dan Shipper：這讓我想到我大部分時間用這個模型都是在搞自己的 vibe coding 項目，但當你在組織內使用它的時候有一個問題：我真的理解模型剛做的所有部分嗎？我怎麼把模型剛做完的東西的上下文轉移到我的腦子裡？這是一個大瓶頸。你怎麼想劃定"我到底需要知道多少"的那條線，以及怎麼確保你有足夠的上下文來感到安心？

Mike Krieger:

兩大塊。第一塊是驗證。我今年初徹底被驗證說服了，這跟以前我全職寫代碼時的一件事相通：找到最緊的開發循環來圍繞你的想法。在 Instagram 時代，有時候意味著在 Xcode 裡做一個新的構建目標，只包含那個屏幕和合成數據，只對這個循環迭代。我會輔導新來的工程師說"如果我只教一樣東西，就是為你的項目搞出這個來，事情會快得多"。

現在的情況是：每次我搭東西的時候，我怎麼確保 Claude 的每一個 PR 都附帶了照片或視頻——不管是 iOS PR 還是 UI 層的改動。這幫你獲得了很多信心。Fable 可能自己跑去工作幾個小時，回來跟你說"我做完了"，然後你看到"這裡是全部 UI 的截圖畫廊"，就非常有用了。你會說"截圖八里那個錯誤狀態——我其實從來沒見過，但我能看出來如果用戶碰到了會怎樣。我們把這個改一下。"做全面的驗證是我們內部一直在大力搞的事情。

第二塊：你最終還是要為你做的工作負責的。很多人每天都在用 Claude，但仍然有種可問責性——"Claude 也許寫了代碼，但你需要理解做了哪些宏觀決策"。我看到相當多的工程師開始了一種實踐：Claude 做完了活，但緊接著有一場後續對話——"我能不能確保我透徹理解了你做的所有取捨？"不管產出的是什麼小寫的 artifact，只要能讓它變得容易理解，就值得做。

開會的時候很有意思——有人會說"這個 PR 我準備好了"，另一個人說"你做了 X 還是 Y？"然後有那一瞬間的停頓："說實話，我不太確定——合入之前我去搞清楚。"適應這種新常態，搞清楚怎麼跟它共事，是我們所有人都需要學的。

主持人 Dan Shipper：你剛才提到的這個"驗證循環"太有想象空間了。除了自動化截圖和屏幕分享，你們還在探索哪些更硬核的思路？

Mike Krieger:

我們的核心切入點是：你能不能做到讓它跑真實的流程，而不是隻注入一個靜態數據？當系統越來越複雜，這變得越來越難。比如，我們必須要讓 Fable 搓出來的 iOS 應用，能夠一鍵登錄到我們的模擬環境裡，調用的全都是最真實的測試賬號和高保真的真實流數據。但同時，我們又不希望它在測試一個區區按鈕的微調時，每次都要苦哈哈地去跑一遍長達 8 步的繁瑣新用戶註冊流程。所以，我們專門為 AI 開發了一套特殊的高級權限和加密共享密鑰體系，讓 AI 能夠一鍵越過前置關卡，直接切入最核心的業務現場，讓它的測試體感和真實用戶在手裡的體驗做到近乎像素級的貼合。

第二塊是已知路徑和當前改動路徑的組合——前者對於迴歸測試非常有價值。我們已經把一些理想化的工作流用文字表達出來，Claude 可以反覆檢查這些。而 Claude 在表達它當前在做的那部分改動的意圖上也做得非常好，所以這部分會被深入演練。這兩者的組合很重要。

視覺驗證也很關鍵，而視頻是給 Claude 的一個極度未被充分利用的工具。我最近在做一個原型：把 Claude 構建出來的東西做成視頻錄像交給它，配合 FFmpeg，看著它自己逐幀分析，然後說"這個動畫有卡頓，我去修"。截圖永遠不會捕捉到這個，因為截圖錯過了那個瞬間。

對於那些不容易端到端測試的部分，讓 Claude 構建一個可靠的模擬後端，或者用現成的，也非常有意思。在 Artifact 的時代，我們在預 LLM 時代就有非常全面的測試。每一塊基礎設施都有一個很好的內存實現，可以在單元測試裡快速運行。現在把這件事延伸到 Claude 的領域：我在做一個有相當穩健後端的東西，在我的開發服務器上不好啟動，它一次性就搞了一個很好的替代品。隨著時間推移，這個替代品隨著代碼本身的演進也在演進。以前我會說"這要同步太費勁了"。現在我只是想"Claude 會讀變更，適配替代品，保持兩邊同步。就行了。"

主持人 Dan Shipper：有一些非常有趣的架構：當你收到一個 bug，一個 agent 自動去修，修完給客戶發消息說"修好了"。你注意到在 Fable 上這種流程有變化嗎？

Mike Krieger:

幾個方面。在人與 Claude 的層面上，有一件事我反覆看到：如果有人在我們 Slack 的反饋頻道里報告了一個 bug，這個線程被傳入 Claude Code 的會話。因為有 Slack MCP，它可以真的拉取那個線程，然後以我的身份發回："這是 Mike 的 Claude，我修好了，這裡是 PR 鏈接。"但然後他它會說："別急——還沒上線。等上線後我會再通知你。"幾個小時之後："這次部署發出去了。你應該去試試修好了嗎？"這種閉環的跟進是相對新的。我有過好幾個長期運行的 Claude Code 會話在以我的身份互動。我在裡面也放了一些免責聲明。

第二塊回到了我們剛才聊的那個品味和判斷。一個層面是"有 bug 反饋，所以我要去修"，另一個層面是有好的判斷力。我週末遇到一個情況，我們有一個內部系統運行了好一陣子沒重啟，出現了內存洩漏。好的判斷是："Mike，這是週末。你重啟一下服務器，現在就能解決，我會異步開一個 PR 做長期修復。"如果你要 Claude 介入這種 bug 到修復的流程，你真的希望它理解任何好的 SRE 或工程師都會理解的東西：解決眼下的問題，至於要不要換平臺重構那另說。理解這個平衡非常重要。

人們應該用這個模型來構建什麼

主持人 Dan Shipper：這一代新模型最讓人熱血沸騰的地方在於，它們不僅僅是抬高了下限，讓任何沒有背景的普通人都能一鍵搓出屬於自己的 App，更重要的是，它們同時掀翻了專家的天花板。如果你現在是一名職業工程師或者創業團隊的創始人，你完全有能力去單槍匹馬搞定以前連想都不敢想的硬核項目。在你看來有哪些可能大家目前還沒緩過神來、但其實完全可以用這一代模型去閉眼衝的前沿領域？

Mike Krieger:

幾個想法，也許可以先從好玩的說起。人們總有很多關於怎麼把他們的世界的複雜性表達出來的創意想法，每個領域都有一個你特別瞭解的東西，而總會有些版本是"我怎麼把它解釋給別人？我能不能把別的地方的技術用到我這上面？"拿我太探來說，她最近正在跨界死磕環境工程——主攻地熱能方向，那裡面充斥著令人頭禿的複雜數學模型和流體力學模擬。但隨著 Fable 這一代推理模型的斷代式升級，她居然成功地把原本完全不屬於她專業範疇的硬核技術，完美地嫁接到了她自己的科研工作中。現在，她甚至能指使 Fable 去幫她搭建一套全量 PyTorch 的端到端深度學習模擬系統——這放在以前，對她一個非計算機專業的學者來說，簡直是天方夜譚。

第二塊是它組合軟件來解決對你自己非常獨特的問題的能力。內部我們做的大量工作是把我們儘可能多的內部系統 MCP 化，配合正確的權限結構和部署設置。外部也有很好的 PaaS 平臺，你直接問 Claude 就行，它會幫你搭好。但我特別喜歡那種"做了一個你一直想要的東西"的感覺。

還有一件事是最近徹底震撼到我的。我們內部有一位商業化團隊的同事，她並非技術出身，但她把 Claude 深度整合到了她日常業務流程的每一個毛細血管裡。最可怕的是，她沒有在完成了 V1 版本後就淺嘗輒止——她就拿著這套工具，在後臺默默跟大模型一起，連著高強度迭代了幾個月。

這恰恰揭示了這一代推理模型最被嚴重低估、也最性感的一點：在前幾代模型的溫飽線裡，項目往往存在一個"複雜度天花板"。一旦你的業務代碼或者邏輯堆疊到了一定體量，大模型就會開始"顧頭不顧屁股"，你再想塞進新功能，它就會瘋狂報錯，直接把你之前的已有架構給活生生改爛。

但現在，這位不懂代碼的女同事，在 Fable 這個級別的模型加持下，已經把她的系統在後臺連著養了幾個月。你能清晰地看到那個軟件像一個活生生的有機體一樣，在 AI 的灌溉下持續生長、生長、瘋狂進化。 如今，她已經開始把這套極其龐大、複雜的自建系統，向我們公司整個商業化部門進行全量部署了。

一個完全沒有程序員背景的普通人，如今能夠憑藉一己之力，把一個長週期軟件的複雜度天花板頂到這種令人窒息的高度——這在人類科技史上，是前所未有的神蹟。

動態工作流

主持人 Dan Shipper：你說的另一個非常強大的東西是動態工作流，跟我展開說說嗎？

Mike Krieger:

我們在內部經常會魔改出一些這類前沿工具，然後我就會在辦公室裡死命去"催更"那些寫工具的工程師："這玩意兒到底什麼時候能公開發布？"有時候確實是因為一些底層的硬核基建限制導致只能內部先跑，但我們正在竭盡全力把這些寶貝早點推向市場。對我來說，動態工作流絕對是屬於驚豔全球的那一款。

Fable 這樣的模型之所以特別強大有兩個大原因。一是它能幫你為深度、有意義的工作創建腳手架。我用它幹過的最瘋狂的一件事，是直接甩給 Fable 一個挺複雜的內部 Python 項目，讓它幫我把一整套核心業務完整地重構成 TypeScript 版本——當時我們有一個非常具體的線上部署考量。

當年在 Instagram 的時候，高層也曾極其嚴肅地討論過："我們要不要把 IG 整個底層的代碼用 Hack 語言全部重寫一遍，從而無縫併入 Facebook 的基礎設施裡？"我們當時的結論是：打死也不幹，這根本不具備現實可操作性。

但就在上週末，我面對一個同樣盤根錯節的核心代碼庫，我直接在後臺丟給它一套動態工作流，然後我就拍拍屁股去過週末了。我給它設定的工作流是：深入理解現有代碼，生成一份很像 spec 的文檔說明一切怎麼運作，然後逐個模塊翻譯，增量測試，做對抗性驗證，檢查遺漏項。等我週一收心回來拉開電腦一看，奇蹟發生了——它已經是一套跑在 TypeScript 和 Bun 開發工具鏈上的嶄新系統了，而且在某些架構層面上，它甚至比我的 Python 原版寫得還要優雅、還要快。

另一個更性感的長遠原因在於：隨著動態工作流的普及，在不久的將來，我們可以把不同難度的子任務，無縫分發給對應複雜度的模型梯隊去跑。

主持人 Dan Shipper：對於沒用過的人，告訴我你是怎麼做出那個工作流的。你是怎麼設計的？怎麼確保它是好的？

Mike Krieger:

整個調教過程其實充滿了極客式的迭代趣味。我最開始只是打開 Claude Code，對它說："兄弟，我手裡現在有個極其棘手的重構大活——來，我們先聯手設計一套全自動的工作流方案。"

它給我展示了計劃，我說"這很接近了，但我需要三到四個額外的驗證層次來檢查遺漏的功能"。然後它就回復："這是你的方案。準備好了嗎？"工作流是代碼表達的，我覺得這一點非常有價值，你能看到它到底準備怎麼做。

在它做了完整移植之後，我有幾個後續的小調整項，我就把它們作為迷你工作流，從上一個工作流的輸出基礎上繼續。這回到了那個問題：chat 是不是正確的界面。工作流是一個好的中間地帶，你用 chat 來編排它，但它是用代碼表達的，然後在一個乾淨的 UI 裡面執行，每一步都在展示發生了什麼。我覺得我們以後會用類似的方式來把長視野的工作和 chat 連接起來。