或許是知道大家這周末都要奮戰狂戰 Fable 5，Anthropic 的 Claude Code 開發者 Thariq 放出了一篇長文，分享他使用 Fable 5 模型的方法論。
Thariq 在文中表示：Fable 5 的能力上限，取決於你能發現多少自己還不知道的東西。
下為 Thariq 全文：
用 Claude Fable 5 寫程式碼，反覆教給我一個老道理：地圖不是疆域。
地圖，也就是對工作的描述，是我的 prompt、skills 和 context，是我交給 Claude 的東西。
疆域，則是工作真正發生的地方：程式碼庫，現實世界，以及它真實的約束條件。
地圖和疆域之間的差距，就是我所說的「未知」。當 Claude 遇到一個未知時，它得根據對你意圖的最佳猜測來做決策。工作量越大，Claude 可能碰到的未知也就越多。
Fable 是第一個讓我覺得，工作質量的瓶頸其實在於我自己澄清「未知」的能力的模型。
這裡有個關鍵點：光靠提前規劃，往往還不夠。你可能在實現過程中才挖出深層的未知，也可能發現這些未知其實指向了一個完全不同的解法。
我發現，用 Fable 工作其實是一個迭代的過程：在實現之前、之中和之後，持續地發現自己的未知。
我做了一些用於發現未知的示例 artifact [1]，不過建議先看完這篇文章，建立起直覺之後再去看。
01. 四種「未知」
你的未知到底有那些呢？當我帶著一個問題來找 Claude 時，我傾向於從四個維度來拆解：
- 已知的已知（Known Knowns）：這基本就是你 prompt 裡寫的東西，你告訴 agent 你想要什麼了。
- 已知的未知（Known Unknowns）：你還沒想清楚的部分，但你至少知道自己還沒想清楚。
- 未知的已知（Unknown Knowns）：那些你覺得太顯而易見、根本不會寫進 prompt 的東西，但看到了你就能認出來。
- 未知的未知（Unknown Unknowns）：你壓根沒考慮過的東西。你不知道自己不知道什麼，甚至不知道一個東西能好到什麼程度。
最厲害的 agentic coding 高手，未知都相對較少。看 Boris 或者 Jarred 寫 prompt，你能明顯感覺到他們對自己想要什麼瞭如指掌，和程式碼庫、和模型行為之間高度同步。
但他們也會假設未知的存在。
某種意義上，減少和規劃你的未知，就是 agentic coding 這件事的核心技能。 好消息是，這個技能通過和 Claude 一起工作就能不斷提升。
02. 幫它幫你
給 Claude 下指令，其實是個微妙的平衡。
你太具體了，Claude 會嚴格執行你的指令，那怕換條路更合適。你太模糊了，Claude 往往會基於行業最佳實踐做選擇，而這些選擇未必適合你的場景。
如果你沒處理好自己的未知，兩邊都會踩坑。你不知道什麼時候路上全是障礙，也不知道什麼時候其實一路暢通……但你還是想讓 Claude 靈活調整方向。
Claude 能幫你更快地發現你的未知。 它可以飛速搜尋你的程式碼庫和網際網路，它在大多數話題上知道的比你多，它還能從失敗中更快地迭代。
這個過程中最重要的一件事，是給 Claude 關於你出發點的上下文。比如，告訴它你的思考進展到了那一步，坦誠你對這個問題和程式碼庫的熟悉程度，讓它像一個思考夥伴一樣跟你合作。
我之前寫過一篇關於用 HTML artifact 和 Claude 協作 [2]的文章，在幾乎所有的場景下，HTML artifact 都是可視化和呈現資訊的最佳方式。
下面我會詳細介紹我用來發現這些未知的方法。我並非每次都全部用到，但作為一個工具箱放在手邊，確實挺趁手的。
03. 盲區掃描
開始一項工作時，最有用的事情之一就是瞭解你的盲區。比如你要在程式碼庫的一個陌生角落寫功能，或者用 Claude 幫你做一些你不熟悉的事（比如迭代一個設計方案），那你很可能有大量「未知的未知」。
你可能不知道該問什麼問題，不知道「好」的標準長什麼樣，不知道有那些歷史工作已經做過了，也不知道有那些坑要避開。
這時候，你可以讓 Claude 幫你找到你的「未知的未知」，然後解釋給你聽。我喜歡在 prompt 裡直接用「blindspot pass」和「unknown unknowns」這兩個詞。給 Claude 關於你是誰、你已經知道什麼的上下文，通常也至關重要。
示例 prompt：
“ 我在給項目加一個新的認證提供商，但我對這個程式碼庫裡的 auth 模組一無所知。你能做一次盲區掃描（blindspot pass），幫我找到相關的「未知的未知」，讓我能更好地給你寫 prompt 嗎？
我不知道什麼是調色（color grading），但我需要給這個視訊調色。你能教我理解調色領域裡我的「未知的未知」，讓我能寫出更好的 prompt 嗎？
04. 先做原型
當我面對大量「未知的已知」時，也就是那些只有看到了才知道自己想要什麼的東西，我喜歡讓 Claude 和我一起頭腦風暴、做原型。
在原型階段就把「未知的已知」找出來並說清楚，價值不小。因為在實現階段才發現它們，成本會高得多。規格上的一個小改動，可能導致程式碼實現截然不同，而讓 agent 回滾已有的改動也會更費勁。
比如，你可能只是想看看在一個 frame 上加個按鈕的效果，而不想去接後端路由或者在前端維護額外的狀態。
視覺設計這塊，對我來說是一個很難用語言描述、但看到了就知道自己想要什麼的領域。這種情況下，我會讓 Claude 給我做幾個不同的設計方向。
我基本上每次寫程式碼前，都會先來一輪探索或頭腦風暴。這幫我在一開始就有意識地確定項目的範圍。Claude 經常能找到我會錯過的高價值方案，也偶爾會見樹不見林。頭腦風暴能防止我把範圍定得太窄或太寬。
示例 prompt：
“ 我想給這些資料做個儀表板，但我沒什麼視覺審美，也不知道有那些可能性。做一個 HTML 頁面，給我 4 個完全不同的設計方向，讓我看看那個感覺對。
在接任何東西之前，先做一個 HTML 檔案，用假資料模擬新的編輯器工具列。我想先感受一下佈局，再動真正的應用。
我的大致問題是：使用者在 onboarding 之後流失了。搜尋程式碼庫，頭腦風暴 10 個我們可以介入的點，從最便宜到最大膽排列。我來告訴你那些方向靠譜。
05. 讓它面試你
做完足夠的頭腦風暴之後，你可能仍然有未知。
這時候，我會讓 Claude 就任何模糊的地方來「面試」我。讓 Claude 面試你的時候，儘量給它關於你問題的上下文，引導它提問的方向。
示例 prompt：
“ 每次問我一個問題，問那些有歧義的地方，優先問那些「我的回答會改變架構設計」的問題。
06. 給它看參考
有時候你確實難以描述清楚自己想要什麼。可能你沒有合適的語言來表達，也可能這東西太複雜了，描述起來得花不少時間。
這時候，最好的答案就是給一個參考。雖然你可以給圖表、文件或截圖，但最好的參考……其實是原始碼。
如果你有一個庫按照某種特定方式實現了某個行為，或者你很喜歡某個設計元件，直接把 Fable 指向那個資料夾，告訴它看什麼就行，那怕是另一種語言也沒關係。
這也是 Claude Design 的工作方式。你不一定要給它一個檔案（雖然你也可以這麼做）。你可以把它指向一個你喜歡的網站上的某個模組，它會去讀底層程式碼，而不只是看截圖。這能提供關於標記、結構和元件實際建構方式的豐富細節。
示例 prompt：
“ vendor/rate-limiter 裡的這個 Rust crate 實現了我想要的退避行為。讀一下它，然後在我們的 TypeScript API 客戶端中重新實現相同的語義。
07. 先出方案
當我覺得差不多可以開始寫了，我通常會讓 Claude 先給我出一個實現方案來審閱，重點放在那些最可能改動的部分，比如資料模型、類型介面或者 UX 流程。這能讓 Claude 把我可能真正需要調整的東西浮上來。
示例 prompt：
“ 寫一個 HTML 版的實現方案，但把我最可能要調整的決策放在最前面：資料模型變更、新的類型介面、以及任何使用者可見的東西。那些機械性的重構放到最後，那部分我信你。
08. 邊做邊記
對方案滿意之後，我會開一個新的 session，把之前的 artifact 傳進去。比如，我可能會把一個 spec 檔案和一個原型一起傳進去，讓 agent 來實現。
但事實上，不管你做了多少規劃，總有「未知的未知」在暗處等著你。Agent 可能在工作過程中發現程式碼裡的一個邊界情況，需要換個思路。
我會讓 Claude Code 維護一個臨時的 implementation-notes.md（或 .html）檔案，記錄它做的決策，這樣我們下次迭代的時候能從中學習。
示例 prompt：
“ 維護一個 implementation-notes.md 檔案。如果你碰到一個邊界情況迫使你偏離方案，選擇保守的方案，把它記在「偏差」部分，然後繼續。
09. 交付說明
交付一個東西，很重要的一步是獲得認同和審批。建構 pitch 和 explainer 類的 artifact 能幫你：
- 當審閱者和你當初有相同的「未知」時，加速他們的理解
- 當專家想確認你考慮到了他們預期的風險和常見失敗點時，加速審批
示例 prompt：
“ 把原型、spec 和實現筆記打包成一個文件，讓我可以丟到 Slack 裡爭取支援。把 demo GIF 放在最前面。
10. 驗收考試
一個長時間的工作 session 結束後，Claude 完成的東西可能比我意識到的要多得多。光看程式碼 diff 只能讓我對發生了什麼有個粗淺的瞭解，畢竟很多行為取決於已有的程式碼路徑。
讓 Claude 先給我上下文，然後出一套關於這次改動的測驗題，幫我真正理解到底發生了什麼。
我只有把測驗全做對了才會合併程式碼。
示例 prompt：
“ 我想確保自己理解了這次改動的所有內容。給我做一個 HTML 報告，包含改動的上下文、直覺、做了什麼等資訊供我閱讀理解，然後在底部出一套測驗題，我必須通過。
11. 一次實戰
Fable 的發佈視訊 [3]完全是用 Claude Code 剪輯的。視訊製作對我來說是一個全新的領域，我絕對算不上什麼專家。
所以我從自己已知的東西開始。我知道 Claude 可以用程式碼來編輯視訊和做轉錄，但精度夠不夠呢？於是我讓 Claude 給我解釋 Whisper 這類轉錄工具的原理，以及我能不能用 ffmpeg 精準地剪掉「嗯」和長停頓之類的東西。
我想讓 Claude 做一個和我說話節奏同步的 UI，但不確定它能不能做到。那……先做個原型試試呢？我讓 Claude 用 Remotion 和一段轉錄做了個原型視訊，看看效果。
最後，視訊看起來有點灰濛蒙的。我知道這是調色的問題，但我其實不太瞭解調色到底是什麼。第一次嘗試是讓 Claude 做幾個版本讓我挑，但後來發現一個問題：我根本不知道調色做到什麼程度算「好」。於是換了個思路，讓 Claude 先教我調色的基礎知識，來發現我在這個領域的未知。
你可以在這裡 [4]看到更詳細的講解。
12. 縮小差距
模型變得越強大，用對了方法你能做到的事就越多。當一個長周期的任務結果不對時，你大機率需要花更多時間來定義你的未知，或者制定一個允許 Claude 靈活應變的實現方案。
每一次頭腦風暴、面試、原型和參考，都是一次低成本的試探，相當於在問題變得昂貴之前先去探探路。
所以，下一個項目開始的時候，先讓 Claude 幫你找到你的未知吧。 (AGI Hunt)