Claude工程師終於交出Fable 5焚訣，教你打破和模型之間的信息差

# Claude 工程師公布 Fable 5 實戰心法：破解人機協作中的「信息差」難題

自 Fable 5 發布以來，這款被譽為「AI 封神時刻」的模型經歷了從萬眾期待到美國政府禁令強制下線、再到限制非美國人訪問的戲劇性轉折。如今風波漸平，模型終究要回歸生產力本身。近日，Anthropic 旗下 Claude Code 工程師 Thariq Shihipar 在社交媒體上發表長篇博客，首度披露使用 Fable 5 的核心技巧，為困擾用戶已久的「模型能力強大但任務執行不佳」問題給出了系統性解答。 ## 問題根源：地圖與疆域之間的鴻溝

Thariq 在博客中指出，當前人機協作最大的瓶頸並非模型本身的能力不足，而是用戶與模型之間存在著深刻的「信息差」。他提出了一個精妙的比喻：「地圖並不等於疆域。」所謂地圖，是指人們交給模型的工作表徵——提示詞、技能文件和上下文；而疆域則是真正需要發生工作的地方——代碼庫、現實世界以及其中真實存在的約束條件。這個地圖和疆域之間的差距，Thariq 將其定義為「未知項」。當 Claude 遇到未知項時，就必須根據對用戶意圖的最佳猜測做出決定。工作越是複雜，可能遇到的未知項就越多。

Fable 5 之所以特別，是因為它首次讓使用者明顯感覺到：工作質量的瓶頸，已經取決於自己釐清未知項的能力，而非模型的理解極限。Thariq 強調，單純依靠提前規劃遠遠不夠。你很可能在實現的深處才發現未知項，也可能會發現這些未知項指向一個事實——你其實應該用完全不同的方式來解決問題。因此，與 Fable 5 協作的本質，是一個在實現前、實現中、實現後不斷發現未知項的迭代過程。## 四類未知項：重新審視你的思考框架

為了幫助用戶系統性地理解問題，Thariq 將使用模型時的認知狀態拆解為四個層次：

已知的已知，即直接寫在提示詞裡的內容，明確告訴模型想要什麼；已知的未知，指那些還沒有弄清楚、但知道自己尚未釐清的事情；未知的已知，是自己覺得顯而易見以至於根本不會寫下來、但看到就能認出來的事情；未知的未知，則是那些完全沒有考慮過的可能性。 根據 Thariq 的觀察，最優秀的智能體式程序員往往擁有相對更少的未知項。他們非常清楚自己想要什麼，細節充分，與代碼庫和模型行為保持高度同步。但他們也會預設未知項的存在，並將減少和提前規劃未知項作為智能體式編程的核心能力。 ## 幫助 Claude 就是幫助你自己

Thariq 認為，給 Claude 下指令是一種微妙的平衡。過於具體，即使轉向其他方案可能更合適，模型也會嚴格照著指令執行；過於模糊，模型往往會基於行業最佳實踐做出選擇和假設，卻不一定適合特定任務。當你沒有充分考慮自己的未知項時，兩種情況都會失敗。 Claude 其實可以幫助用戶更快發現未知項。它能夠極快地搜索代碼庫和互聯網，在大多數主題上掌握的通用知識也比用戶更多，並且能更快從失敗中迭代。過程中最重要的一點，是給模型足夠的起點上下文：告訴它你目前思考到哪一步，說明你對問題和代碼庫的熟悉程度，讓它像一個思考夥伴一樣與你協作。 ## 實戰方法：實現前的關鍵準備

在正式開始工作之前，Thariq 推薦了幾種發現未知項的模式。首先是盲點掃描，直接讓模型幫助找出「未知的未知」。例如告訴模型：「我正在添加新的身份認證提供方，但我對這個代碼庫裡的認證模塊一無所知，請幫我找出相關的未知項。」這種方法特別適合在陌生領域工作的場景。其次是頭腦風暴與原型製作。對於那些只有看到之後才能定義標準的事情，Thariq 會讓 Claude 一起頭腦風暴、製作原型。視覺設計就是一個典型例子——他很難清楚表達設計需求，但看到之後就知道自己是否滿意。在這種情況下，他會要求模型針對一個工件給出幾種不同的設計方向。

幾乎每次編碼會話一開始，他都會先進行探索或頭腦風暴，防止一開始就把範圍設得過窄或過寬。第三種方法是反問。在完成足夠的頭腦風暴後，用戶仍然會存在未知項。這時可以讓 Claude 圍繞任何不明確或有歧義的地方進行訪談式提問，一次只問一個問題，優先提出那些回答會改變架構設計的問題。第四是提供參考資料。當用戶無法詳細描述想要什麼時，最好的答案就是參考資料。這可以是圖表、文檔或圖片，但最有效的其實是源代碼。Thariq 指出，即使參考代碼是另一種語言寫的也沒有關係，Claude 可以直接讀取對應文件夾，理解底層標記結構和組件組織方式。

最後，在準備開始實現之前，Thariq 建議讓 Claude 先整理一份實現計劃，重點關注那些最可能發生變化的部分，如數據模型、類型接口或用戶體驗流程，讓模型提前暴露出可能需要調整的地方。## 實現中與實現後的持續發現

即使規劃再充分，未知項仍然會潛伏在實現過程中。Thariq 會要求 Claude Code 維護一個臨時的實現筆記文件，記錄做出的決策。當遇到邊界情況導致必須偏離原計劃時，選擇保守方案，記錄原因後繼續推進。 實現完成後，Thariq 會讓 Claude 將原型、規格說明和實現筆記打包成一個文檔，用於向團隊爭取支持和理解。更重要的是，他會讓模型圍繞這次變更測試自己，只有在完美通過測驗後才會合併代碼。這種做法確保了對變更內容的深度理解，而非僅停留在代碼 diff 的淺層認知。 ## 從實戰中總結：讓地圖與疆域匹配

Thariq 以 Fable 5 的發布視頻剪輯為例，展示了如何串聯這些方法。他當時完全不懂視頻剪輯，但從自己已知的部分開始：知道 Claude 可以用代碼編輯視頻、進行轉錄，但不確定準確度是否足夠。於是他讓模型解釋轉錄技術的工作原理，請它用 Remotion 和轉錄文本創建視頻原型，最後在視頻調色環節，他讓 Claude 教自己什麼是調色，而非盲目生成版本。 Thariq 最後總結道，模型越強，越能通過正確的方法完成更多事情。當一個長週期任務返回錯誤結果時，很可能說明需要花更多時間定義自己的未知項，或者創建一份能夠靈活應對未知項的實現計劃。每一份解釋文檔、頭腦風暴、訪談、原型和參考資料，都是一種低成本的方法，可以在修復代價變高之前，先發現那些原本不知道的事情。