# 策展 · X (Twitter) 🔥🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Thariq (@trq212) · 平台：X (Twitter) · 日期：2026-07-05

> 原始來源：https://x.com/trq212/status/2073100352921215386

## 中文摘要

# Fable 實戰指南：發掘你的未知數

在使用 Claude Fable 5 的過程中，我不斷地被提醒一個老道理：地圖不等於疆域。

地圖是待辦工作的呈現，也就是我的 Prompt、skill 以及 context，這是我給予 Claude 的資訊。而疆域則是工作實際發生的場域，包含程式庫、真實世界，以及它實際的限制。

![這張圖透過「地圖」與「領土」的對比，說明了模型預測與現實世界之間存在的落差與未知數。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/77ea74c11a8e5125.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片由左右兩個方框組成，中間以雙向箭頭連接，並標註文字「your unknowns」。
左側標題為「The map」，顯示一個帶有網格的平面，其中有一條連接實心圓點與空心圓點的虛線路徑，並包含一個三角形與一個圓形符號。
右側標題為「The territory」，顯示同樣的起點與終點，但路徑變為彎曲的實線，背景有波浪線條，並散佈著圓圈、三角形、鳥形符號以及問號，象徵現實環境的複雜性。</div></details>

地圖與疆域之間的差異，就是我所謂的「未知數」。當 Claude 遇到未知數時，它必須根據對我需求的最佳猜測來做出決定。工作量越大，Claude 可能遇到的未知數就越多。

Fable 是第一個讓我發現工作品質受限於「我釐清未知數能力」的模型。

重點在於，僅僅提前規劃是不夠的。你可能會在實作深處發現未知數，或者這些未知數會顯示出你其實應該用完全不同的方式來解決問題。

我發現與 Fable 合作是一個迭代的過程，需要在實作前、實作中以及實作後不斷發掘自己的未知數。

我在此製作了一些用於發掘未知數的 Artifact 範例，但請務必回頭練習，以培養何時該使用它們的直覺。

## 認識你的未知數

什麼是你的未知數？當我帶著問題找 Claude 時，我傾向於將其拆解為四個面向：

- **已知已知 (Known Knowns)**：這基本上就是我的 Prompt 內容。我告訴 Agent 我想要什麼？

- **已知未知 (Known Unknowns)**：有哪些是我還沒搞清楚，但我知道自己還沒搞清楚的？

- **未知已知 (Unknown Knowns)**：有哪些事情顯而易見到我從未寫下來，但如果看到了，我就會認得出來？

- **未知未知 (Unknown Unknowns)**：有哪些是我完全沒考慮到的？有哪些知識是我所不知道的？我知道某件事可以做到多好嗎？

![這張圖表以四象限矩陣形式，解釋了在與 AI 代理互動時，關於知識與認知的四種分類概念。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/c4e922ecd9f869c4.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片將知識與認知的狀態分為四個象限：
1. **Known knowns (已知已知)**：標註為「what's in your prompt」，並說明是「What you tell the agent you want.」（你告訴代理你想要什麼）。
2. **Known unknowns (已知未知)**：標註為「questions you know to ask」，並說明是「What you haven't figured out yet — and know it.」（你還沒弄清楚，但你知道自己還沒弄清楚的問題）。
3. **Unknown knowns (未知已知)**：標註為「"I'll know it when I see it"」，並說明是「Too obvious to write down, but you'd recognize it.」（太顯而易見而無需寫下，但當你看到時會認出來）。
4. **Unknown unknowns (未知未知)**：標註為「what you never considered」，並說明是「The pothole you didn't know the road could have.」（你不知道道路上可能存在的坑洞）。</div></details>

最優秀的 Agentic 程式開發者通常擁有的未知數相對較少。觀察像 Boris 或 Jarred 這樣的人下 Prompt，很明顯他們對自己想要的東西有非常詳細的了解。他們與程式庫以及模型的行為深度同步。

但他們也會假設未知數的存在。在許多方面，減少並規劃你的未知數正是 Agentic 程式開發的 skill。幸運的是，這是一項你可以透過與 Claude 合作來提升的 skill。

## 協助 Claude 協助你

![這張圖表以冰山模型隱喻「尋找未知」的過程，展示了從充滿未知數的狀態轉變為釐清資訊的過程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1cf926606cc6a4a7.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖表由兩個冰山示意圖組成，中間以箭頭連接並標註「finding your unknowns」。
左側標示為「before」，冰山水面下的部分散佈著多個問號（?）。
右側標示為「after」，冰山水面上的部分出現了橫線紋路，水面下的問號數量減少，象徵未知資訊已被轉化或釐清。</div></details>

指導 Claude 是一種微妙的平衡。如果你太過具體，即使在需要轉向時，Claude 也會執著於你的指令。如果你太過模糊，Claude 往往會根據業界最佳實踐做出選擇與假設，而這些可能並不適合你的任務。

當你沒有考慮到自己的未知數時，這兩種情況都會失敗。你不知道路徑何時會充滿障礙，也不知道何時路徑會暢通，但你仍然希望 Claude 能帶領你前進。

Claude 可以幫助你更快地發掘未知數。它能極快地搜尋你的程式庫和網路，而且它對一般主題的了解遠勝於你。它也能從失敗中更快地進行迭代。

這個過程中最重要的部分，是提供 Claude 關於你起點的 context。例如，告訴它你目前的思考進度；揭露你對該問題和程式庫的經驗；並讓它像思考夥伴一樣與你合作。

我之前寫過關於在 Claude 中使用 HTML 的文章，在幾乎所有這些情況下，HTML Artifact 都是視覺化和呈現這些內容的最佳方式。

在本文中，我將詳細介紹我用來揭露這些未知數的一些模式。我不會每次都使用每一種技巧，但這是一套很有用的技巧集合。

![這是一張關於專案執行流程的示意圖，將過程分為實作前、實作中與實作後三個階段。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/a659d3ec4ded9479.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表以時間軸形式呈現專案執行的三個階段，並包含各階段的重點項目：

1. **Before implementation（實作前）**
   - Blind spot pass
   - Brainstorms &amp; prototypes
   - Interviews
   - References
   - Implementation plan

2. **During implementation（實作中）**
   - Implementation notes
     - log deviations, keep going

3. **After implementation（實作後）**
   - Pitches &amp; explainers
   - Quizzes
     - merge only when you pass

圖表底部註記：「what you learn becomes the map for next time」（你所學到的將成為下一次的指引地圖）。右側有一條虛線箭頭，從「After implementation」指向「Before implementation」，象徵循環優化的過程。</div></details>

# 實作前

## 盲點檢查 (Blind Spot Pass)

開始工作時，你能做的最有用的事情之一就是了解自己的盲點。例如，如果你正在程式庫的新區域編寫功能，或者使用 Claude 協助處理不熟悉的任務（如迭代設計），你很可能會遇到大量的「未知未知」。

你可能不知道該問什麼問題、什麼才算好、過去做過什麼，或者該避開哪些坑。

為了做到這一點，你可以請 Claude 協助你找出你的「未知未知」並向你解釋。我喜歡直接使用「blindspot pass」和「unknown unknowns」這些字眼。提供關於你是誰以及你了解什麼的 context，通常對此很重要。

範例 Prompt：

- 「我正在加入一個新的驗證提供者 (auth provider)，但我對這個程式庫中的驗證模組一無所知。你能進行一次盲點檢查，幫我找出相關的未知未知，並協助我更好地對你下 Prompt 嗎？」

- 「我不知道什麼是色彩校正 (color grading)，但我需要校正這部影片。你能教我了解關於色彩校正的未知未知，好讓我能下更好的 Prompt 嗎？」

## 腦力激盪與原型製作

當我在一個充滿「未知已知」的領域工作時（包含那些我只有在看到時才知道如何定義的標準），我喜歡請 Claude 與我一起腦力激盪並製作原型。

在原型製作階段儘早識別並說出「未知已知」非常有價值，因為在實作過程中才發現它們可能會（相對）昂貴。功能或規格上的微小變更可能會導致程式碼中截然不同的實作方式，而且對你的 Agent 來說，要撤銷之前的變更可能會更困難。

例如，你可能只是想看看加到視窗上的按鈕看起來如何，而不需要連接後端路由或在前端維護額外的狀態。

視覺設計對我來說很難用言語表達，但我知道自己想要什麼樣的感覺。在這些情況下，我會要求為同一個 Artifact 提供幾種不同的設計方案。

我也幾乎會在每個程式開發階段開始時進行探索或腦力激盪。這有助於我帶著明確的意圖開始，以定義專案的範圍。Claude 經常能找到我會錯過的高價值方案，有時也會有「見樹不見林」的情況。腦力激盪能防止我將範圍設定得太窄或太寬。

範例 Prompt：

- 「我想要為這些資料製作一個儀表板，但我沒有視覺品味，也不知道有哪些可能性。請製作一個包含 4 種截然不同設計方向的 HTML 頁面，讓我能對它們做出反應。」

- 「在連接任何東西之前，請製作一個單一的 HTML 檔案，用假資料模擬新的編輯器工具列。在觸碰真實應用程式之前，我想先對版面配置做出反應。」

- 「這是我的粗略問題：使用者在新手引導後流失。搜尋程式庫並腦力激盪出 10 個我們可以介入的地方，從成本最低到最雄心勃勃的方案。我會告訴你哪些方案能引起我的共鳴。」

## 訪談

一旦我完成了充分的腦力激盪，我可能仍然存在未知數。

在這種情況下，我會請 Claude 針對任何未知數或模糊之處對我進行訪談。當要求 Claude 訪談你時，試著提供關於你問題的 context 來引導它的提問。以下是一些範例。

範例 Prompt：

- 「請針對任何模糊不清的地方一次問我一個問題，如果我的回答會改變架構，請優先詢問這些問題。」

## 參考資料

有時你無法詳細描述你想要什麼。例如，你可能沒有相關的語言能力，或者它太過複雜，以至於需要花費你很長的時間。

在這種情況下，最好的答案是參考資料。雖然你可以包含圖表、文件或圖片，但絕對最好的參考資料是原始程式碼。

如果你有一個以特定方式實作某些功能的函式庫，或者你非常喜歡的設計元件，只需將 Fable 指向該資料夾並告訴它要尋找什麼，即使它是用不同的語言編寫的也沒關係。

這也是 Claude Design 的運作方式。你不必手動交給它一個檔案（雖然你也可以這樣做）。你可以將它指向你喜歡的網站上的模組，它會讀取底層程式碼，而不僅僅是截圖。這能提供關於標記、結構以及元件實際建構方式的更豐富細節。

範例 Prompt：

- 「vendor/rate-limiter 中的這個 Rust crate 實作了我想要的確切退避 (backoff) 行為。請閱讀它，並在我們的 TypeScript API 客戶端中重新實作相同的語意。」

## 實作計畫

當我認為準備好實作時，我傾向於請 Claude 擬定一份實作計畫供我審閱，重點放在最可能變更的部分，例如審閱資料模型、型別介面或 UX 流程。這讓 Claude 能夠浮現出我可能確實需要修改的事項。

範例 Prompt：

- 「請用 HTML 撰寫一份實作計畫，但要先列出我最可能調整的決策：資料模型變更、新的型別介面，以及任何使用者面對的部分。機械式的重構請放在最後，那部分我信任你。」

# 實作中

## 實作筆記

一旦我對計畫感到滿意，我就會開啟一個新的對話並將任何 Artifact 傳遞給 Prompt。例如，我可能會傳入一個規格檔案和一個原型，並要求 Agent 進行實作。

但事實是，無論你做多少規劃，總是有「未知未知」潛伏著。Agent 可能會在工作中發現，由於它在程式碼中發現的邊緣案例 (edge case)，它需要採取不同的策略。

我會要求 Claude Code 維持一個暫時的 `implementation-notes.md`（或 `.html`）檔案，記錄它所做的決策，這樣我們就能從下一次嘗試中學習。

範例 Prompt：

- 「請維護一個 implementation-notes.md 檔案。如果你遇到迫使你偏離計畫的邊緣案例，請選擇保守的選項，將其記錄在『Deviations』下方，然後繼續進行。」

# 實作後

## 提案與說明文件

![這張圖表展示了如何透過整合原型、規格與筆記至單一文件中，並以演示影片作為開頭，來有效獲得審閱者的支持。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/22abeaf160f90d7c.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片標題為「PITCHES &amp; EXPLAINERS」。圖表左側列出了三個輸入項目：「prototype」、「spec」與「notes」，這些項目皆指向中間的「one doc」。該文件內包含一個帶有播放按鈕的區塊，下方標註「lead with the demo」。右側顯示兩個人像圖示，旁邊有綠色勾選符號，下方標註「buy-in」。底部文字說明：「reviewers start with the same unknowns you did — answer them up front」。</div></details>

交付成果最重要的部分之一就是獲得認可與核准。在最終文件中建立提案與說明 Artifact 有助於：

- 當審閱者與你從相同的未知數開始時，加速理解。

- 當專家希望看到你已經考慮到他們預期的未知數和常見失敗點時，加速核准。

範例 Prompt：

- 「將原型、規格和實作筆記打包成一份我可以丟到 Slack 上以獲得認可的單一文件。開頭請放上 Demo GIF。」

## 測驗

經過長時間的工作會議後，Claude 可能已經完成了比我意識到的還要多的工作。閱讀程式碼差異 (diffs) 只能讓我對發生的事情有淺顯的了解，因為大部分的行為將取決於現有的程式碼路徑。

在提供大量 context 後，要求 Claude 對變更內容對我進行測驗，有助於我了解發生了什麼。我只會在通過測驗後才進行合併。

範例 Prompt：

- 「我想確保我了解這次變更中發生的所有事情。請給我一份關於變更的 HTML 報告，讓我能結合 context、直覺、已完成的工作等來閱讀與理解，並在底部附上關於變更的測驗，我必須通過測驗。」

## 這一切是如何整合的：發布 Fable

Fable 的發布影片完全由 Claude Code 編輯。這對我來說是一個新的領域，我絕非專家。

所以我從我所知道的開始。我知道 Claude 可以使用程式碼來編輯影片並進行轉錄，但我並不確定它是否足夠精確。接著，我請 Claude 向我解釋像 Whisper 這樣的轉錄是如何運作的，以及我是否能夠使用 ffmpeg 精確地剪掉像「嗯」或長時間停頓之類的片段。

我希望 Claude 建立一個與我說話內容同步的 UI，但我並不確定它是否做得到，所以我請 Claude 使用 Remotion 和轉錄內容製作一個原型影片，看看是否可行。

最後，影片本身看起來有點暗沉，我知道這是色彩校正的結果，但我並不真正知道什麼是色彩校正。我的第一次嘗試是試圖讓 Claude 做幾個變體讓我挑選，但我意識到在色彩校正方面，我根本不知道什麼才叫「好」。所以，我轉而請 Claude 教我關於色彩校正的知識，以發掘我的未知數。

你可以在這裡觀看更深入的解釋。

## 地圖與疆域的匹配

模型越強大，你透過正確的方法所能達成的成就就越多。當一個長期的任務結果不如預期時，很可能是因為你需要花更多時間定義你的未知數，或者建立一個允許 Claude 在過程中進行即興發揮的實作計畫。

每一次的說明、腦力激盪、訪談、原型製作和參考資料，都是在問題變得難以修復之前，以低成本找出你所不知道的事物的途徑。

所以，在開始下一個專案時，請先請 Claude 協助你找出你的未知數。

## 標籤

Skills, 教學資源, Claude, Anthropic, Claude
