Claude Fable 5 Field Guide：工程師教你發現自己的盲點
為什麼給 Claude 的提示詞總是差一點？問題可能不在模型，而在你沒說出口的「未知」。本文拆解四類未知，以及在實作前、中、後逐步揭露它們的具體方法與範例提示詞。
Claude Fable 5 的 launch video，是由 Claude Code 剪出來的——負責這項工作的人，甚至不是影片剪輯專家。這件事之所以可能，靠的不是模型多聰明，而是一套「持續揭露自己不知道什麼」的工作方法。
與 Claude Fable 5 一起工作，會讓人重新體會一個經典道理：地圖不是領土。
「地圖」是你交給 Claude 的提示詞、技能與上下文，也就是你對「要完成的工作」的描述；「領土」則是工作真正發生的地方——程式碼庫、真實世界，以及它們的真實限制。
兩者之間的落差，就是本文所說的「未知」（unknowns）。當 Claude 遇到未知，它會根據對你意圖的最佳猜測做決策。工作越龐大，等著被發現的未知就越多。
Fable 是第一個讓工作品質的瓶頸，落在「你能否釐清自己的未知」的 AI 工具。
事前規劃往往不夠。有時要深入實作之後，才會發現真正的未知，甚至意識到問題應該用完全不同的方法解決。與 Fable 合作因此是一個反覆迭代的過程：在實作前、實作中、實作後，不斷揭露自己的未知。
以下整理出一套實際可用的做法與範例提示詞。在套用之前，先理解這個框架本身。
理解你的未知
當你帶著問題找 Claude 時，可以用四種類別拆解自己的狀態：
| 類別 | 說明 | 例子 |
|---|---|---|
| 已知的已知 | 你已經知道、也寫進提示詞裡的部分 | 我要做一個登入功能 |
| 已知的未知 | 你知道自己還沒想清楚的部分 | 還沒決定用哪種認證機制 |
| 未知的已知 | 你其實知道、但覺得太理所當然而沒寫下來的東西，看到結果才會意識到對錯 | 程式碼庫中既有的驗證流程 |
| 未知的未知 | 完全沒考慮過、甚至不知道自己不知道的事 | 認證流程中潛在的安全漏洞 |
其中「未知的已知」最容易被忽略：它不是你不知道，而是你沒說。你腦中有標準、程式碼庫裡有慣例，但因為對你來說太顯而易見，從未寫進提示詞——直到 Claude 交出不符預期的結果，你才發現原來這件事需要講。
最頂尖的 agentic coding 使用者，通常對自己的未知有清楚認知：提示詞明確而細緻，與程式碼庫及模型行為高度同步。他們也會預設未知一定存在，並透過計畫降低未知帶來的風險。這是 agentic coding 的核心能力，而且可以透過與 Claude 的合作持續練出來。
幫助 Claude 幫助你
引導 Claude 是一種微妙的平衡：
- 過於具體：Claude 會照著指令走，可能錯過更適合的替代方案。
- 過於模糊：Claude 會依業界最佳實踐做假設，但未必符合你的任務需求。
當你忽略自己的未知，兩邊都會失敗——你不知道哪條路上滿是障礙，也沒有給 Claude 靈活轉向的空間。
Claude 能快速搜尋你的程式碼庫與網路，對多數主題有平均水準以上的知識，也能迅速從失敗中調整。
關鍵是告訴 Claude 你的起點：你的思考進度、你對問題與程式碼庫的熟悉程度。這會讓它從執行者變成思考夥伴。
以下按照「實作前、實作中、實作後」三個階段，介紹揭露未知的具體模式。
實作前
盲點檢查
開始工作前，最重要的是理解自己的盲點。
在不熟悉的程式碼庫區域開發功能，或請 Claude 協助你不擅長的工作（例如反覆調整視覺設計）時，你手上多半有大量「未知的未知」：不知道該問什麼、不知道好的結果長什麼樣、不了解相關歷史與可能的陷阱。
做法：請 Claude 先做一次盲點檢查（blindspot pass），找出你的未知的未知，並解釋這些盲點。記得提供「你是誰、你已經知道什麼」的上下文。
範例提示詞：
- 「我正在新增一個新的 auth provider，但不熟悉程式碼庫裡的 auth modules。可以幫我做盲點檢查，找出我的未知的未知，並協助我優化提示詞嗎？」
- 「我完全不懂調色，但需要幫影片調色。能先教我這個領域有哪些我沒意識到的未知，再幫我改進提示詞嗎？」
腦力激盪與原型
面對大量「未知的已知」——那些要看到結果才知道標準在哪的事——最好的方法是請 Claude 一起腦力激盪、做原型。
在早期就辨識出這類未知，價值極高，因為等到實作階段才發現，修正成本會高得多。
視覺設計是典型例子：往往難以用語言描述，但看到就知道符不符合需求。Claude 可以做出多種設計方案的 artifact 讓你比較。
範例提示詞：
- 「我想為這批資料做一個 dashboard，但我沒有明確的視覺偏好，也不知道有哪些可能方向。請做一個 HTML 頁面，提供 4 種不同設計方案讓我回饋。」
- 「先用單一 HTML 檔案 mock 新的 editor toolbar，使用假資料。先確認版面效果，再接進 app。」
- 「使用者在 onboarding 後流失。請搜尋程式碼庫，腦力激盪 10 個介入點，從成本最低排到最有野心，我會告訴你我感興趣的方向。」
訪談
腦力激盪之後如果還有模糊地帶，可以反過來，請 Claude 訪談你。給足上下文，它就能問出精準的問題。
範例提示詞：
- 「請一次問我一個問題，針對所有模糊之處訪談我，優先問可能改變架構的問題。」
參考資料
有時你就是無法用語言描述需求——可能缺乏相關詞彙，也可能需求本身太複雜。這時最好的方式是提供參考資料：圖表、文件、圖片，尤其是程式碼。
例如你喜歡某個 library 的實作方式或設計元件，可以直接指向那個資料夾，讓 Fable 閱讀底層程式碼。
範例提示詞：
- 「vendor/rate-limiter 裡的 Rust crate 實作了我想要的 backoff 行為。請讀它，然後在我們的 TypeScript API client 中重新實作相同語義。」
實作計畫
準備好動工時，請 Claude 整理一份實作計畫，把最可能需要你介入決策的部分（data models、type interfaces、UX flows）放在最前面供你審閱；機械性的重構細節放在底部，交給 Claude 處理即可。
範例提示詞：
- 「請用 HTML 寫一份實作計畫，開頭放我最可能想調整的決策（data model 變更、新的 type interfaces、user-facing 內容），重構細節放在底部。」
實作中
實作筆記
對計畫滿意後，開一個新的 session，把前面的 artifacts 放進提示詞，讓 agent 開始實作。
但未知的未知永遠存在——agent 可能撞上程式碼的邊緣案例，被迫偏離計畫。這時可以要求 Claude Code 維護一份 implementation-notes.md，記錄所有決策與偏離，事後你就能快速掌握「實際發生了什麼」。
範例提示詞：
- 「請維護一份 implementation-notes.md。遇到 edge case 導致偏離計畫時，記錄在『Deviations』段落下，然後繼續執行。」
實作後
Pitch 與說明文件
交付成果時，取得團隊的理解與批准至關重要。把成果打包成 pitch 或 explainer artifact，能讓審閱者更快理解你面對過哪些未知，也讓專家能確認你已經考慮過預期中的失敗點，加速批准流程。
範例提示詞：
- 「請把 prototype、spec、implementation notes 打包成單一文件，附上 demo GIF，方便我在 Slack 上取得 buy-in。」
測驗
長時間運行之後，Claude 完成的東西可能比你想像的多。只讀 code diff 往往不夠——改動的實際行為取決於既有的 code paths。
這時可以請 Claude 先給你完整上下文，再用測驗的方式考核你對這次改動的理解，通過之後才 merge。
範例提示詞：
- 「我想確認自己理解這次改動。請用 HTML 報告說明上下文、設計直覺與結果，底部附測驗題目，我通過測驗後才會 merge。」
案例：用 Claude Code 剪出 Fable 的 launch video
回到開頭的例子。Fable 的 launch video 由 Claude Code 完成剪輯，而執行者在影片剪輯上並非專家。整個過程正是上述方法的組合：
- 從已知出發：先請 Claude 解釋 Whisper 轉錄工具的運作方式，以及用 ffmpeg 剪掉語助詞的可行性。
- 原型驗證：請 Claude 用 Remotion 和轉錄稿做出 prototype video，確認整條路走得通。
- 揭露未知：影片調色不理想，但執行者不懂調色——於是請 Claude 做出多個版本供選擇，再請它教學，找出「調色」這個領域裡自己的未知。
不熟悉的領域、大量未知的未知，最後仍能交付成果。差別不在專業知識，而在有沒有系統性地揭露未知。
讓地圖與領土相符
模型越好、方法越對，你能完成的事就越多。
長期任務的結果不如預期，原因通常是二擇一：你沒花足夠時間釐清未知，或者你的計畫沒有留給 Claude 在遇到未知時靈活調整的空間。
每一次盲點檢查、腦力激盪、訪談、原型、參考資料，都是低成本的未知探測器——它們幫你避開的，是高昂的事後修正成本。
下一個專案開始前，先請 Claude 幫你找出未知，讓地圖更貼近領土。
常見問題
如何識別「未知的未知」？
無法直接識別，只能間接逼近：請 Claude 做盲點檢查、讓它反過來訪談你、提供參考資料讓它比對你的描述與實際需求的落差。核心原則是先交代「你是誰、你已經知道什麼」，Claude 才能推測你可能漏掉什麼。
提示詞應該寫多具體？
取決於你的未知分布。已經想清楚的部分（已知的已知）寫具體；還沒想清楚的部分（已知的未知）明確標示出來，請 Claude 提案或訪談你，而不是硬寫一個自己也不確定的答案。最糟的做法是把不確定的事寫得很篤定——這等於把未知藏起來。
這套方法只適用於寫程式嗎？
不是。文中的影片剪輯案例就不是傳統的程式開發。只要是「你對結果有標準、但過程中存在大量未知」的工作——資料分析、設計、內容產製——四類未知的框架都適用。
Claude Fable 5 與其他 AI 模型有什麼不同？
Claude Fable 5 特別強調與使用者協作釐清未知，提供了四類未知數的分類框架，幫助使用者更系統性地識別和管理不確定性。相比其他模型，Fable 5 更注重協作過程中的迭代發現，而不僅僅是最終結果。
如何開始應用這個框架？
在下一個項目開始前，進行盲點檢查，識別你的已知的已知、已知的未知、未知的已知和未知的未知。然後根據這些分類，設計你的提示詞，並讓 Claude 像思考夥伴一樣與你協作。
推薦資源
相關文章推薦
本文引用 Anthropic Claude Code 團隊工程師 Thariq Shihipar 撰寫『A Field Guide to Fable: Finding Your Unknowns』
