【新智元導讀】Claude Code工程師Thariq親授Fable 5內行心法：模型強到這份上，卡住你的已經不是它，而是你沒想清的那些「未知的未知」。
就在剛剛，Claude Code 團隊核心工程師 Thariq 發了篇乾貨，核心就一句話——
用Fable 5這種等級的模型，卡住你的已經不是模型，是你自己。
瀏覽量很快衝上了幾十萬。
他說，和Fable 5朝夕相處這段時間，自己反覆被同一個老道理教育：地圖，不是領土。
什麼意思？
你寫的prompt、你調的技能、你喂的上下文，這些是「地圖」——你塞給Claude的那份說明書；而真正幹活的地方——程式碼庫、真實世界、那些繞不開的約束，才是「領土」。
地圖和領土之間的差距，他管它叫「未知」。
Claude每撞上一個未知，就只能猜——按它對「你想要什麼」的最佳猜測做決定。
任務越長、干的活越多，撞上的未知就越多，猜錯的機會自然也越多。
以前模型不夠強，瓶頸在模型那邊，你只管拚命把需求寫清楚。
但Fable 5不一樣。Thariq的原話是：這是第一個讓他覺得，工作質量被「我澄清未知的能力」卡住的模型。
模型強到一定程度，瓶頸就悄悄換了位置——從「模型能不能做到」，變成「你能不能說清楚你到底要什麼」。
而給指令這件事，本身就是走鋼絲。
你說得太具體，Claude會死守你的話，那怕當下明明該轉向，它也一條道走到黑。
你說得太模糊，它又會按「行業最佳實踐」自己猜，猜出來的未必對你的路子。
不把未知想在前面，你就兩頭翻車——路上有坑你不知道，路明明是通的你也不知道，還在那兒瞎指揮。
更扎心的是，光提前做計畫還不夠。
有的未知埋在實施深處，挖到一半才冒頭；有的未知一露面，你才發現整個問題都該換個解法。
四類未知
最坑的是最後一類
那怎麼把「未知」說清楚？
Thariq先把它拆成四類，說人話就是：
- 已知已知：寫進prompt裡的，你明確知道自己要什麼；
- 已知未知：你還沒想明白，但你知道自己沒想明白；
- 未知已知：顯而易見到你懶得寫下來、但一看到就知道對不對的東西，比如審美；
- 未知未知：你壓根沒想過、甚至不知道自己不知道的東西。
最坑的就是最後一類。你不知道該問什麼問題，不知道什麼叫好，不知道前人踩過那些坑。
而頂尖的agentic coder，比如Anthropic的Boris、Jarred，未知都很少——看他們寫prompt就知道，要什麼門兒清，對程式碼庫和模型的脾氣葉門兒清。
但他們照樣會給未知留預案。
某種意義上，減少未知、為未知做預案，就是agentic coding這門手藝本身。
好消息是，這不是天賦，是能練的。
而練這門手藝，最好的陪練恰恰是Claude自己：它翻你的程式碼庫和整個網際網路比你快得多，大多數話題它懂得比你多，從失敗裡爬起來也比你快。
你要做的，只是把起點交代清楚——你想到那一步了、對這個問題和這套程式碼有多少經驗，然後讓它像個思考夥伴，陪你把未知一個個挖出來。
多數時候，一個能上手點、能改的HTML頁面，就是把未知擺上檯面的最好方式。
一套閉環SOP
於是Thariq給了一整套流程，分實施前、中、後三段。
實施前，五招。
第一，盲區掃描。進陌生程式碼庫、幹不熟的活，直接對Claude說：「幫我做一次blindspot pass，找出我的unknown unknowns，講給我聽。」讓它把你的盲區挖出來，順便教你怎麼把prompt寫得更好。
第二，頭腦風暴加原型。視覺設計這種「看到才知道要什麼」的東西，別急著接後端，先讓Claude用一個HTML頁面甩你四個截然不同的方向，你挑。
道理很簡單：未知已知在原型期發現，成本幾乎為零；拖到實施期才發現，規格上一個小改動，程式碼可能天翻地覆，回滾都費勁。
第三，採訪。讓Claude一次一個問題地反問你，專挑那些「答案會改變架構」的先問。
第四，給參考。說不清就別硬說，最好的參考是原始碼。
你喜歡某個庫的實現、某個網站上的元件，把Claude指向那個資料夾或模組就行，那怕是另一種語言——它讀的是底層程式碼，不是截圖，拿到的細節比你嘴上描述的豐富十倍。
第五，實施計畫。動手前讓Claude寫份計畫給你審，把最可能變卦的放最前面——資料模型、類型介面、使用者看得見的流程；機械性重構壓到最底下，那部分信它。
實施中，一招：讓Claude維護一個implementation-notes.md。
計畫再周全也有意外，撞上edge case偏離了計畫，就選保守方案，在「Deviations」下記一筆，接著幹——下次復盤全靠它。
實施後，兩招：一是打包推介，把原型、規格、筆記攢成一份能直接丟群裡拿批准的文件——評審的人和你當初有一樣的未知，這份文件替他們省了一遍。
二是做測驗，讓Claude就這次改動出一套題考你，全對才許合併——讀diff只能懂個皮毛，大量行為藏在既有程式碼路徑裡，考一遍才知道自己是不是真懂了。
不懂剪輯，卻用Claude剪出了Fable發佈視訊
最有說服力的是他自己的例子：Fable的發佈視訊，完全是Claude Code剪的，而他壓根不是剪輯出身。
他就從已知開始。
知道Claude能用程式碼剪視訊、能轉錄，但不確定精度夠不夠，就先讓它講講Whisper這類轉錄是怎麼工作的、能不能用ffmpeg把「呃」和長停頓精準剪掉。
想要字幕跟著他說的每個詞同步蹦出來，不確定能不能實現，就讓Claude先拿Remotion加轉錄文字做個原型試試。
成片看著發悶，他知道是調色的鍋，第一反應是讓Claude出幾版讓他挑——挑著挑著才發現，自己根本不知道「調色好」長什麼樣。
於是乾脆掉頭，讓Claude先教他什麼是調色。
先搞清楚自己的未知，再談選擇。
模型越強，「問得準」越值錢
這套方法背後，藏著一個更大的訊號：模型越強，用對方法能達成的就越多，而人的價值，正在從「寫得多快」，悄悄挪到「問得多准」。
前幾天Claude Code團隊的人還在說，他們的工作方式已經從「驗證Claude幹得對不對」，變成「驗證它干的是不是對的事」。
Thariq這篇講的，正是這枚硬幣的另一面——當模型足夠強，你能不能把職責交代明白、能不能提前把未知想清楚，直接決定了它替你幹出來的活是驚豔還是返工。
每一次講解、頭腦風暴、採訪、原型、參考，都是在代價變高之前，廉價地找出你原本不知道的東西。
說到底，長任務返回一個錯誤結果，往往不是模型不行，是你還沒把未知想清楚。 (新智元)