使用 Claude Fable 5 持續教會我一個老道理：地圖不等同於實地。
地圖是對待完成工作的描述，也就是我的提示詞、技能和背景資訊，是我提供給 Claude 的內容。而實地則是工作實際發生的地方，也就是程式碼庫、真實世界及其實際限制。
地圖與實地之間的差異，我稱之為「未知因素」。當 Claude 遇到未知因素時，它必須根據它對我想法的最佳猜測來做出決定。需要完成的工作越多，Claude 可能遇到的未知因素也越多。
Fable 是第一個讓我發現，工作品質的瓶頸取決於我釐清其未知因素能力的模型。
重要的是，僅僅事先規劃並不總是不夠的。你可能在實作過程中發現未知因素，或者這些未知因素會讓你知道，你其實應該用完全不同的方式來解決問題。
我發現與 Fable 合作是一個迭代的過程，需要在實作之前、期間和之後不斷發現我的未知因素。
我製作了一些用於尋找未知因素的範例 artifacts，但請務必回來，建立何時使用它們的直覺。
了解你的未知因素
你的未知因素是什麼？當我帶著問題來找 Claude 時，我傾向於將其分解成 4 個面向：
- 已知的已知： 這基本上就是我提示詞中的內容。我告訴 Agent 我想要什麼？
- 已知的未知： 我還沒有弄清楚，但我意識到自己還沒弄清楚的事情？
- 未知的已知： 那些明顯到我不會寫下來，但如果看到就會認出來的東西？
- 未知的未知： 我完全沒有考慮到的是什麼？我不知道哪些知識？我知道事情可以好到什麼程度？
最優秀的 Agent 編碼者，其未知因素相對較少。看著像 Boris 或 Jarred 這樣的人下提示詞，我明顯感受到他們非常清楚自己想要什麼細節。他們對於程式碼庫和模型行為都有深刻的同步理解。
但他們也會假設未知因素的存在。從很多方面來看，減少並規劃未知因素，正是 Agent 編碼的 技能。但幸運的是，這是一項可以透過與 Claude 合作來提升的技能。
幫助 Claude 幫助你
指導 Claude 是一種微妙的平衡。如果你過於具體，Claude 會遵循你的指示，即使轉換方向可能更合適。如果你過於模糊，Claude 通常會根據業界最佳實務做出選擇和假設，但這些可能不適合你的任務。
當你沒有考慮到自己的未知因素時，你會在這兩個方向上失敗。你不知道什麼時候路徑會充滿障礙，也不知道什麼時候路徑會暢通無阻，但你仍然希望 Claude 能夠靈活應變。
Claude 可以幫助你更快地發現你的未知因素。它可以極快地搜尋你的程式碼庫和網路，並且對一般主題的了解遠多於你。它也能更快地從失敗中迭代。
這個過程中最重要的部分是，讓 Claude 了解你的起點背景。例如，告訴它你在思考過程中的進度；說明你對問題和程式碼庫的熟悉程度；讓它像一個思考夥伴一樣與你合作。
我之前寫過關於使用 HTML 與 Claude 合作的文章，在幾乎所有這些案例中，HTML artifact 都是視覺化和呈現問題的最佳方式。
在這篇文章中，我將詳細說明我用來發現這些未知因素的一些模式。我並非每次都會用到每一種技巧，但這是一個有用的技巧集合。
實作之前
盲點掃描
開始工作時，最有用的事情之一就是了解你的盲點。例如，如果你在程式碼庫的新部分編寫功能，或者使用 Claude 來幫助你處理不熟悉的工作（例如迭代設計），你很可能會有很多的「未知的未知」。
你可能不知道該問什麼問題、不知道什麼是好的標準、不知道過去做過哪些工作，也不知道該避開哪些陷阱。
為此，你可以請 Claude 幫助你找到這些未知的未知，並向你解釋。我喜歡直接使用「盲點掃描」和「未知的未知」這幾個字。提供它關於你是誰以及你知道什麼的背景資訊通常很重要。
範例提示詞：
- 「我正在新增一個新的認證提供者，但我對這個程式碼庫中的認證模組一無所知。你能幫我做一次盲點掃描，幫我找出相關的未知的未知，並幫助我更有效地向你提問嗎？」
- 「我不知道什麼是調色，但我需要為這部影片調色。你能教我了解我在調色方面的未知的未知，以便我能更好地提出提示詞嗎？」
腦力激盪與原型設計
當我在一個充滿「未知的已知」的領域工作時，涉及那些我只有看到時才能定義的標準，我喜歡請 Claude 與我一起進行腦力激盪和原型設計。
在原型設計階段早期就識別並說出未知的已知非常有價值，因為在實作過程中才發現它們的代價（相對）高昂。功能或規格上的微小改變可能導致程式碼中截然不同的實作，而你的 Agent 更難還原先前的變更。
例如，你可能只是想看看按鈕在框架中的樣子，而無需連接後端路由或在前端維護額外的狀態。
對我來說，視覺設計是難以具體說明的東西，但我看到時就知道我想要什麼。在這些情況下，我會要求為一個 artifact 提供幾種設計方法。
我也幾乎每次編碼會話都以探索或腦力激盪階段開始。這幫助我從一開始就帶著意圖來定義專案範圍。Claude 經常會發現我可能忽略的高價值方法，但有時也會見樹不見林。腦力激盪可以防止我設定過於狹窄或過於寬泛的範圍。
範例提示詞：
- 「我想要一個用於這些數據的儀表板，但我沒有視覺品味，也不知道有什麼可能性。為我製作一個 HTML 頁面，包含 4 種風格迥異的設計方向，讓我可以對它們做出反應。」
- 「在連接任何東西之前，先製作一個單一的 HTML 檔案，用假數據模擬新的編輯器工具欄。我希望在你碰觸真實應用程式之前，先對佈局做出反應。」
- 「這是我粗略的問題：用戶在入職後流失。搜尋程式碼庫，腦力激盪 10 個我們可以介入的地方，從最便宜到最雄心勃勃的方案。我會告訴你哪些方案引起了我的共鳴。」
訪談
一旦我進行了足夠的腦力激盪，我可能仍然有未知因素。
在這種情況下，我請 Claude 就任何未知因素或模糊之處對我進行訪談。當要求 Claude 訪談你時，盡量提供它關於你的問題的背景資訊，以引導它的提問。以下是一些範例。
範例提示詞：
- 「一次一個問題地訪談我，針對任何模糊的地方，優先詢問那些你的答案會改變架構的問題。」
參考資料
有時候你無法詳細描述你想要什麼。例如，你可能沒有相應的語言，或者它太過複雜以至於需要花費很多時間。
在這種情況下，最好的答案是提供參考資料。雖然你可以包含圖表、文件或圖片，但最好的參考資料是原始碼。
如果你有一個以某種方式實作某個功能的函式庫，或者一個你非常喜歡的設計元件，只需將 Fable 指向該資料夾，告訴它要找什麼，即使它是用不同的語言寫成的。
這也是 Claude Design 的運作方式。你不必提供檔案（雖然你也可以這樣做）。你可以將它指向你喜歡的網站上的一個模組，它會讀取底層的程式碼，而不僅僅是螢幕截圖。這提供了關於標記、結構以及元件實際構建方式的更豐富細節。
範例提示詞：
- 「vendor/rate-limiter 中的這個 Rust crate 實作了我想要的確切退避行為。讀取它，並在我們的 TypeScript API 客戶端中重新實作相同的語義。」
實作計劃
當我認為自己準備好要實作時，我傾向於請 Claude 整理一份實作計劃供我審查，重點放在那些最可能發生變化的部分，例如審查數據模型、型別介面或用戶體驗流程。這讓 Claude 能夠浮現出我可能實際上需要修改的東西。
範例提示詞：
- 「用 HTML 寫一份實作計劃，但首先列出我最可能調整的決策：數據模型變更、新型別介面，以及任何面向使用者的內容。把機械性的重構工作埋在最後，這部分我信任你。」
實作期間
實作筆記
一旦我對計劃感到滿意，我會開啟一個新的會話，並將任何 artifacts 傳遞給提示詞。例如，我可能會傳遞一個規格檔和一個原型，然後請 Agent 來實作它。
但事實是，無論你做多少規劃，總會潛藏著未知的未知。Agent 可能會在工作的過程中，因為在程式碼中發現了邊緣案例而需要採取不同的策略。
我要求 Claude Code 保留一個暫時的 [implementation-notes.md](https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359369&usg=AOvVaw1Iqvg51JpzkrkRtHHIjyOL)（或 .html）檔案，在其中記錄它所做的決策，以便我們能從下一次嘗試中學習。
範例提示詞：
- 「保留一個
implementation-notes.md檔案。如果你遇到一個邊緣案例，迫使你偏離計劃，請選擇保守的方案，將其記錄在「偏離」部分下，然後繼續。」
實作之後
提案與說明
推出某個東西最重要的部分之一是獲得認可和批准。在最終文件中建立提案和說明的 artifacts 有助於：
- 當審查者從你當初的未知因素開始時，加速他們的理解
- 當專家想確認你已經考慮到他們預期的未知因素和常見失敗點時，加速批准流程
範例提示詞：
- 「將原型、規格和實作筆記打包成一個文件，我可以放到 Slack 中來獲得認可。以演示 GIF 開頭。」
測驗
在一次長時間的工作會話之後，Claude 可能完成了比我意識到的要多得多的工作。閱讀程式碼差異只能讓我對發生的事情有一個粗略的了解，因為許多行為將取決於現有的程式碼路徑。
在 Claude 給了我大量背景資訊後，請它針對變更內容對我進行測驗，可以幫助我了解發生的事情。只有在我完美通過測驗後，我才會合併程式碼。
範例提示詞：
- 「我想確保我完全理解這次變更中發生的一切。給我一份 HTML 報告，包含背景、直覺、已完成的工作等內容，讓我可以閱讀和理解，並在底部附上一個我必須通過的關於變更的測驗。」
這些如何結合起來：推出 Fable
Fable 的推出影片完全由 Claude Code 剪輯。這對我來說是一個全新的領域，我絕非專家。
所以我從我已知的部分開始。我知道 Claude 可以使用程式碼來剪輯影片和進行轉錄，但我不確定它是否足夠準確。然後我請 Claude 向我解釋像 Whisper 這樣的轉錄技術是如何運作的，以及我是否能使用 ffmpeg 準確地剪掉像「嗯」這樣的口頭禪或較長的停頓。
我希望 Claude 建立一個與我所說的話同步的 UI，但不確定它是否做得到，所以我請 Claude 使用 Remotion 和轉錄文字建立一個原型影片，看看是否可行。
最後，影片本身看起來有點暗淡，我知道這是調色的結果，但我實際上並不知道什麼是調色。我的第一次嘗試是讓 Claude 提供幾個變體供我選擇，但我意識到，在調色方面，我不知道什麼是「好」。所以，我反過來請 Claude 教我關於調色的知識，以發現我的未知因素。
你可以觀看更深入的說明，請參閱此處。
讓地圖與實地相符
模型越好，使用正確的方法能達到的成就就越多。當一個長週期的任務回傳錯誤結果時，很可能你需要花更多時間來定義你的未知因素，或者建立一個允許 Claude 在其中即興發揮的實作計劃。
每一次的說明、腦力激盪、訪談、原型和參考，都是一種低成本的方式，讓你在需要高成本修復之前，發現自己不知道的事情。
所以，開始你的下一個專案時，先請 Claude 幫助你找到你的未知因素。
