全網(wǎng)爆火！Claude Code核心工程師放出Fable 5使用心法

　　新智元報道

　　【新智元導讀】Claude Code工程師Thariq親授Fable 5內行心法：模型強到這份上，卡住你的已經(jīng)不是它，而是你沒想清的那些「未知的未知」。

　　就在剛剛，Claude Code 團隊核心工程師 Thariq 發(fā)了篇干貨，核心就一句話——

　　用Fable 5這種級別的模型，卡住你的已經(jīng)不是模型，是你自己。

　　瀏覽量很快沖上了幾十萬。

　　他說，和Fable 5朝夕相處這段時間，自己反復被同一個老道理教育：地圖，不是領土。

　　什么意思？

　　你寫的prompt、你調的技能、你喂的上下文，這些是「地圖」——你塞給Claude的那份說明書；而真正干活的地方——代碼庫、真實世界、那些繞不開的約束，才是「領土」。

　　地圖和領土之間的差距，他管它叫「未知」。

　　Claude每撞上一個未知，就只能猜——按它對「你想要什么」的最佳猜測做決定。

　　任務越長、干的活越多，撞上的未知就越多，猜錯的機會自然也越多。

　　以前模型不夠強，瓶頸在模型那邊，你只管拼命把需求寫清楚。

　　但Fable 5不一樣。Thariq的原話是：這是第一個讓他覺得，工作質量被「我澄清未知的能力」卡住的模型。

　　模型強到一定程度，瓶頸就悄悄換了位置——從「模型能不能做到」，變成「你能不能說清楚你到底要什么」。

　　而給指令這件事，本身就是走鋼絲。

　　你說得太具體，Claude會死守你的話，哪怕當下明明該轉向，它也一條道走到黑。

　　你說得太模糊，它又會按「行業(yè)最佳實踐」自己猜，猜出來的未必對你的路子。

　　不把未知想在前面，你就兩頭翻車——路上有坑你不知道，路明明是通的你也不知道，還在那兒瞎指揮。

　　更扎心的是，光提前做計劃還不夠。

　　有的未知埋在實施深處，挖到一半才冒頭；有的未知一露面，你才發(fā)現(xiàn)整個問題都該換個解法。

　　四類未知

　　最坑的是最后一類

　　那怎么把「未知」說清楚？

　　Thariq先把它拆成四類，說人話就是：

　　已知已知：寫進prompt里的，你明確知道自己要什么；

　　已知未知：你還沒想明白，但你知道自己沒想明白；

　　未知已知：顯而易見到你懶得寫下來、但一看到就知道對不對的東西，比如審美；

　　未知未知：你壓根沒想過、甚至不知道自己不知道的東西。

　　最坑的就是最后一類。你不知道該問什么問題，不知道什么叫好，不知道前人踩過哪些坑。

　　而頂尖的agentic coder，比如Anthropic的Boris、Jarred，未知都很少——看他們寫prompt就知道，要什么門兒清，對代碼庫和模型的脾氣也門兒清。

　　但他們照樣會給未知留預案。

　　某種意義上，減少未知、為未知做預案，就是agentic coding這門手藝本身。

　　好消息是，這不是天賦，是能練的。

　　而練這門手藝，最好的陪練恰恰是Claude自己：它翻你的代碼庫和整個互聯(lián)網(wǎng)比你快得多，大多數(shù)話題它懂得比你多，從失敗里爬起來也比你快。

　　你要做的，只是把起點交代清楚——你想到哪一步了、對這個問題和這套代碼有多少經(jīng)驗，然后讓它像個思考伙伴，陪你把未知一個個挖出來。

　　多數(shù)時候，一個能上手點、能改的HTML頁面，就是把未知擺上臺面的最好方式。

　　一套閉環(huán)SOP

　　于是Thariq給了一整套流程，分實施前、中、后三段。

　　實施前，五招。

　　第一，盲區(qū)掃描。進陌生代碼庫、干不熟的活，直接對Claude說：「幫我做一次blindspot pass，找出我的unknown unknowns，講給我聽?！棺屗涯愕拿^(qū)挖出來，順便教你怎么把prompt寫得更好。

　　第二，頭腦風暴加原型。視覺設計這種「看到才知道要什么」的東西，別急著接后端，先讓Claude用一個HTML頁面甩你四個截然不同的方向，你挑。

　　道理很簡單：未知已知在原型期發(fā)現(xiàn)，成本幾乎為零；拖到實施期才發(fā)現(xiàn)，規(guī)格上一個小改動，代碼可能天翻地覆，回滾都費勁。

　　第三，采訪。讓Claude一次一個問題地反問你，專挑那些「答案會改變架構」的先問。

　　第四，給參考。說不清就別硬說，最好的參考是源代碼。

　　你喜歡某個庫的實現(xiàn)、某個網(wǎng)站上的組件，把Claude指向那個文件夾或模塊就行，哪怕是另一種語言——它讀的是底層代碼，不是截圖，拿到的細節(jié)比你嘴上描述的豐富十倍。

　　第五，實施計劃。動手前讓Claude寫份計劃給你審，把最可能變卦的放最前面——數(shù)據(jù)模型、類型接口、用戶看得見的流程；機械性重構壓到最底下，那部分信它。

　　實施中，一招：讓Claude維護一個implementation-notes.md。

　　計劃再周全也有意外，撞上edge case偏離了計劃，就選保守方案，在「Deviations」下記一筆，接著干——下次復盤全靠它。

　　實施后，兩招：一是打包推介，把原型、規(guī)格、筆記攢成一份能直接丟群里拿批準的文檔——評審的人和你當初有一樣的未知，這份文檔替他們省了一遍。

　　二是做測驗，讓Claude就這次改動出一套題考你，全對才許合并——讀diff只能懂個皮毛，大量行為藏在既有代碼路徑里，考一遍才知道自己是不是真懂了。

　　不懂剪輯，卻用Claude剪出了Fable發(fā)布視頻

　　最有說服力的是他自己的例子：Fable的發(fā)布視頻，完全是Claude Code剪的，而他壓根不是剪輯出身。

　　他就從已知開始。

　　知道Claude能用代碼剪視頻、能轉錄，但不確定精度夠不夠，就先讓它講講Whisper這類轉錄是怎么工作的、能不能用ffmpeg把「呃」和長停頓精準剪掉。

　　想要字幕跟著他說的每個詞同步蹦出來，不確定能不能實現(xiàn)，就讓Claude先拿Remotion加轉錄文本做個原型試試。

　　成片看著發(fā)悶，他知道是調色的鍋，第一反應是讓Claude出幾版讓他挑——挑著挑著才發(fā)現(xiàn)，自己根本不知道「調色好」長什么樣。

　　于是干脆掉頭，讓Claude先教他什么是調色。

　　先搞清楚自己的未知，再談選擇。

　　模型越強，「問得準」越值錢

　　這套方法背后，藏著一個更大的信號：模型越強，用對方法能達成的就越多，而人的價值，正在從「寫得多快」，悄悄挪到「問得多準」。

　　前幾天Claude Code團隊的人還在說，他們的工作方式已經(jīng)從「驗證Claude干得對不對」，變成「驗證它干的是不是對的事」。

　　Thariq這篇講的，正是這枚硬幣的另一面——當模型足夠強，你能不能把職責交代明白、能不能提前把未知想清楚，直接決定了它替你干出來的活是驚艷還是返工。

　　每一次講解、頭腦風暴、采訪、原型、參考，都是在代價變高之前，廉價地找出你原本不知道的東西。

　　說到底，長任務返回一個錯誤結果，往往不是模型不行，是你還沒把未知想清楚。

　　參考資料：https://x.com/trq212/status/2073100352921215386

　　編輯：所羅門