Instagram 創辦人 Mike Krieger 談 Fable 5 與 AI 驅動的軟體開發未來

嘉賓：Mike Krieger，Instagram 創始人

主持人：Dan Shipper

播客源： Every

Mike Krieger 讓 Fable 5 在他睡覺時編碼

播出日期：2026 年 6 月 11 日

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

在 Fable 正式發布前五個月，當他首次在內部獲得該模型的體驗權限時，那種震撼與失速感至今令他記憶猶新。「好吧，我覺得自己又變回了一個徹頭徹尾的新手，」他當時這樣對團隊自嘲。他突然發現，自己過去幾十年累積下來的關於效能提升、研發策略乃至時間管理的經驗法則，在這一瞬間全部宣告過時。模型的進化速度，已經徹底甩開了他原有的工作流程。

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

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

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

Fable 5 催生的 Agent-native 架構

建造成本已經坍縮

軟體工程死了嗎？

驗證的機制與價格

Dynamic Workflow

主持人 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 視窗，有一種「我隨時待命，你一句話我就能原地啟動或派生子任務」的直覺。

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

Mike Krieger：

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

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

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

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

主持人 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 的對話歷史裡看它底層到底改了什麼——不過我幾乎從不看，反正對個人玩具項目來說，我根本不在乎它的長期可維護性（笑）。

This thing is incredibly addictive. While I was out with my kid, I noticed that “the floating button is positioned too low on iOS,” so I simply spoke to it within the app, and it went straight to the backend to fix the code. Integrated with Expo’s development toolchain, it even performed a hot reload directly on my phone—the experience at that moment was absolutely incredible.

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

這不僅是 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：

The essence of software engineering has completely changed. It is undergoing a monumental transformation.

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

但如果你能跳出「軟體工程」這個過於死板的字面定義，去審視更廣義的「軟體生產」或「軟體開發」——而不僅僅盯著純程式設計師寫代碼的那一小塊領域——你會發現這個行業不僅活得好好的，而且正處於前所未有的核心地位。

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

Of course, this painful transformation is not painless for many people.

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

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

主持人 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：對於這個模型來說，聊天是最合適的互動界面嗎？它並非那種回合制的，更像是把任務委派給某個人。這會如何影響你應該如何使用它，或你對這個界面的看法？

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 完成工作後，緊接著進行一場後續對話——「我能否確保自己徹底理解了你所做的所有權衡？」無論產出的是什麼小寫的 artefact，只要能讓它變得容易理解，就值得去做。

開會時很有趣——有人會說「這個 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 這樣的模型之所以特別強大，主要有兩個原因。一是它能幫你為深度且有意義的工作建立架構。我曾用它做過最瘋狂的一件事，就是直接把一個相當複雜的內部 Python 專案丟給 Fable，讓它幫我把整套核心業務完整重構為 TypeScript 版本——當時我們有非常明確的線上部署考量。

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

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

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

主持人 Dan Shipper：對於沒用過的人，請告訴我你是如何做出那個工作流程的？你是如何設計的？如何確保它是優秀的？

Mike Krieger：

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

它向我展示了計劃，我說：「這很接近了，但我需要三到四個額外的驗證層次來檢查遺漏的功能」。然後它回覆：「這是你的方案。準備好了嗎？」工作流程是用代碼表達的，我覺得這一點非常有價值，你能看到它到底會如何執行。

在完成完整移植後，我有幾個後續的小調整，我會把它們作為迷你工作流，基於上一個工作流的輸出繼續進行。這又回到了那個問題：chat 是否是正確的介面。工作流是一個良好的中間地帶，你用 chat 來編排它，但它是以代碼表達的，並在一個乾淨的 UI 中執行，每一步都展示正在發生的事情。我認為我們以後會以類似的方式將長視野的工作與 chat 連接起來。

整理 & 編譯：深潮 TechFlow