機器之心編輯部

Fable 5 從發布之日起，命運就像模型的名字一樣玄幻。

從萬眾期待的「AI 封神時刻」，到美國政府一紙禁令強制下線，再到禁止非美國人訪問，可以說是吸引了全球的目光。

到現在，風波逐漸歸于平靜。模型終歸是要回歸到生產力里去的。

為此，Claude Code 工程師 Thariq Shihipar 在社交媒體上發布了長博客，詳細地說明了使用 Fable 5 的技巧。

這篇文章解決了一個大家長久以來的疑惑。明明現在的模型能力已經進化到如此強大的地步了，為什么我在使用模型的時候依舊感覺它做不對任務？

Thariq 的博客讓人豁然開朗。簡而言之：人和模型之間存在著信息差，也就是用戶提供的提示詞、Skill、上下文和實際任務執行之間的差異。

為此，整篇博客正是在教你如何打破這種信息差。下面，機器之心將附上博客全文，以饗讀者。

• 博客標題：A Field Guide to Fable: Finding Your Unknowns
• 博客鏈接：https://x.com/trq212/status/2073100352921215386

與 Claude Fable 5 一起工作，不斷讓我重新意識到一個老道理：地圖并不等于疆域。

所謂「地圖」，是對待完成工作的表征，也就是我的提示詞、技能和上下文，是我交給 Claude 的東西。所謂「疆域」，則是真正需要發生工作的地方：代碼庫、現實世界，以及其中真實存在的約束。

我把地圖與疆域之間的差距稱為「未知項」。當 Claude 遇到一個未知項時，它就必須根據自己對我意圖的最佳猜測來做決定。工作越復雜，Claude 可能遇到的未知項就越多。

Fable 是第一個讓我明顯感覺到工作質量的瓶頸，取決于我澄清其未知項能力的模型。

重要的是，僅僅提前規劃并不總是足夠的。你可能會在實現深處發現未知項；也可能發現這些未知項指向一個事實：你其實應該用完全不同的方式來解決這個問題。

我發現，與 Fable 協作，本質上是一個在實現前、實現中和實現后不斷發現未知項的迭代過程。

作者提供了一些發現「未知項」的示例，讀者可以與全文共同查看。

• 示例鏈接：https://thariqs.github.io/html-effectiveness/unknowns/

了解你的未知項

什么是未知項？當我帶著一個問題來找 Claude 時，通常會從四個角度拆解它：

• 已知的已知：這基本上就是我寫在提示詞里的內容。我告訴智能體，我想要什么？
• 已知的未知：有哪些事情我還沒有弄清楚，但我知道自己還沒有弄清楚？
• 未知的已知：有哪些東西對我來說顯而易見，以至于我根本不會寫下來，但一旦看到就能認出來？
• 未知的未知：有哪些事情是我完全沒有考慮過的？有哪些知識是我還不知道自己不知道的？我是否知道一件事可以做到多好？

最優秀的智能體式程序員往往擁有相對更少的未知項。他們非常清楚自己想要什么，而且細節非常充分。他們與代碼庫和模型行為都保持著高度同步。

但他們也會預設未知項的存在。從很多意義上說，減少并提前規劃你的未知項，就是智能體式編程的核心能力。幸運的是，這是一項可以通過與 Claude 協作不斷提升的技能。

幫助 Claude 以幫助你自己

給 Claude 下指令是一種微妙的平衡。如果你過于具體，即使轉向另一種方案可能更合適，Claude 也會嚴格照著你的指令執行。如果你過于模糊，Claude 往往會基于行業最佳實踐做出選擇和假設，而這些選擇不一定適合你的任務。

當你沒有充分考慮自己的未知項時，兩種情況都會失敗。你不知道前方道路何時會布滿障礙，也不知道什么時候道路其實很順暢，但你仍然希望 Claude 能在必要時做出調整。

Claude 可以幫助你更快發現未知項。它能夠極快地搜索你的代碼庫和互聯網，并且在大多數主題上掌握的通用知識比你更多。它也能更快地從失敗中迭代。

這個過程中最重要的一點，是給 Claude 足夠的起點上下文。例如，告訴它你目前思考到哪一步；說明你對這個問題和代碼庫的熟悉程度；讓它像一個思考伙伴一樣與你協作。

我之前寫過關于如何用 Claude 生成 HTML 的內容。在幾乎所有這些場景中，HTML 工件都是最適合用來可視化和表達想法的方式。

在這篇文章中，我會詳細介紹一些自己用來發現這些未知項的模式。我并不是每次都會使用所有技巧，但把它們作為一組可調用的方法儲備起來，會非常有用。

實現前

盲點掃描

開始工作時，最有用的事情之一，就是理解自己的盲點。例如，如果你正在代碼庫中一個新的模塊里編寫功能，或者讓 Claude 幫你處理某種你不熟悉的工作，比如迭代一個設計方案，那么你很可能會有大量「未知的未知」。

你可能不知道該問什么問題，不知道什么才算好，不知道過去已經做過哪些歷史工作，也不知道有哪些坑應該避免。

要做到這一點，你可以讓 Claude 幫你找出「未知的未知」，并向你解釋。我喜歡直接使用「blindspot pass」和「unknown unknowns」這些字眼。通常來說，告訴它你是誰、你知道什么，也很重要。

示例提示詞：

• 「我正在添加一個新的身份認證提供方，但我對這個代碼庫里的認證模塊一無所知。你能不能做一次 blindspot pass，幫我找出相關的 unknown unknowns，并幫助我更好地給你寫提示詞？」
• 「我不了解調色，但我需要給這個視頻做調色。你能不能教我理解自己在調色方面的 unknown unknowns，這樣我就能寫出更好的提示詞？」

頭腦風暴與原型

當我在一個有很多「未知的已知」的領域工作時，也就是那些只有看到之后我才知道如何定義標準的事情，我會讓 Claude 和我一起頭腦風暴、做原型。

在原型階段盡早識別并表達這些「未知的已知」非常有價值，因為如果到了實現階段才發現它們，代價往往會相對更高。功能或規格中的一些小變化，可能會導致代碼實現發生巨大差異，而且讓智能體回退之前的修改也會更困難。

例如，你可能只是想看看在某個框架里加一個按鈕是什么效果，而并不想真正接入后端路由，也不想在前端維護額外狀態。

視覺設計對我來說就是一種很難清楚表達的東西，但我看到之后會知道自己想要什么。在這種情況下，我會要求 Claude 針對一個工件給出幾種不同的設計方向。

我幾乎也會在每次編碼會話一開始，都先進行探索或頭腦風暴。這能幫助我帶著明確意圖來定義項目范圍。Claude 經常會發現一些我本來會錯過的高價值方案，但它有時也會只見樹木不見森林。頭腦風暴可以防止我一開始就把范圍設得過窄或過寬。

示例提示詞：

• 「我想為這組數據做一個儀表盤，但我沒有什么視覺品味，也不知道可以做到什么程度。幫我做一個 HTML 頁面，給出 4 種風格差異很大的設計方向，好讓我根據結果做反饋。」
• 「在真正接線之前，先用假數據做一個單獨的 HTML 文件，模擬新的編輯器工具欄。我想先對布局做反饋，然后你再去動真實應用?！?/li>
• 「這是我的粗略問題：用戶在完成 onboarding 后流失。搜索代碼庫，頭腦風暴 10 個我們可以介入的地方，從最低成本到最有野心的方案都列出來。我會告訴你哪些方向更有感覺。」

反問

在完成了足夠的頭腦風暴之后，我通常仍然會有未知項。

這種情況下，我會讓 Claude 圍繞任何不明確或存在歧義的地方來采訪我。讓 Claude 采訪你時，盡量提供關于問題的上下文，以便它提出更有針對性的問題。下面是一些例子。

示例提示詞：

• 「請一次只問我一個問題，圍繞任何存在歧義的地方采訪我。優先提出那些我的回答會改變架構設計的問題?！?/li>

參考資料

有時候，你無法詳細描述自己想要什么。比如，你可能沒有對應的表達語言，或者這件事太復雜，要完整描述會花很長時間。

在這種情況下，最好的答案就是參考資料。你可以提供圖表、文檔或圖片，但最好的參考資料其實是源代碼。

如果你有一個庫用某種特定方式實現了某個功能，或者有一個你非常喜歡的設計組件，那就直接把 Fable 指向對應文件夾，并告訴它該看什么。即使參考代碼是另一種語言寫的，也沒有關系。

這也是 Claude Design 的工作方式。你不一定非要給它一個文件，當然你也可以這么做。你可以把它指向你喜歡的某個網站模塊，它會讀取底層代碼，而不僅僅是截圖。這樣可以提供更豐富的細節，包括標記結構、組件組織方式，以及這個組件實際上是如何構建的。

示例提示詞：

• 「vendor/rate-limiter 里的這個 Rust crate 實現的正是我想要的回退重試行為。請閱讀它，并在我們的 TypeScript API 客戶端中重新實現相同的語義。」

實現計劃

當我覺得已經準備好開始實現時，我通常會讓 Claude 先整理一份實現計劃供我審閱，并重點關注那些最可能發生變化的部分，例如數據模型、類型接口或 UX 流程。這樣可以讓 Claude 提前暴露出一些我可能確實需要調整的地方。

示例提示詞：

• 「用 HTML 寫一份實現計劃，但開頭先呈現我最可能會修改的決策點：數據模型變更、新的類型接口，以及任何面向用戶的內容。機械性的重構放在最下面，那部分我相信你可以處理?！?/li>

實現中

實現筆記

當我對計劃滿意后，會開啟一個新的會話，并把相關工件傳入提示詞。例如，我可能會傳入一份規格文件和一個原型，然后讓智能體來實現它。

但事實是，無論你做了多少規劃，總會有未知的未知潛伏著。智能體在工作過程中可能會發現，由于代碼中的某個邊界情況，它必須換一種思路。

我會要求 Claude Code 維護一個臨時的 implementation-notes.md 文件，或者 .html 文件，用來記錄它做出的決策，這樣我們就能從下一次嘗試中學習。

示例提示詞：

• 「請維護一個 implementation-notes.md 文件。如果你遇到某個邊界情況，導致你必須偏離原計劃，請選擇保守方案，在 ‘Deviations’ 下面記錄原因，然后繼續推進?！?/li>

實現后

推介與解釋文檔

發布某個東西時，最重要的事情之一，是獲得他人的理解、支持和批準。在最終文檔中構建推介和解釋類工件，有助于：

• 當評審者一開始也帶著和你相同的未知項時，加速他們理解。
• 當專家想確認你已經考慮到他們本來會預見的未知項和常見失敗點時，加速審批。

示例提示詞：

• 「把原型、規格說明和實現筆記打包成一個單獨的文檔，我可以直接發到 Slack 里爭取支持。開頭先放演示 GIF。」

測驗

經過一次漫長的工作會話后，Claude 可能已經完成了比我意識到的更多工作。只看代碼 diff 往往只能讓我對發生了什么有一個淺層理解，因為很多行為都取決于既有代碼路徑。

讓 Claude 在給我大量上下文之后，再圍繞這次變更來測試我，可以幫助我真正理解發生了什么。我只有在完美通過測驗之后，才會合并代碼。

示例提示詞：

• 「我想確保自己理解了這次變更里發生的一切。請給我一份 HTML 報告，幫助我閱讀和理解這些變更，包括上下文、直覺解釋、具體做了什么等等，并在底部附上一份我必須通過的測驗。」

串聯方法：以發布 Fable為例

Fable 的發布視頻完全是由 Claude Code 剪輯完成的。這對我來說是一個全新的領域，而我絕不是這方面的專家。

所以我從自己已知的部分開始。我知道 Claude 可以用代碼來編輯視頻并進行轉錄，但我不確定它的準確度是否足夠。于是我讓 Claude 向我解釋 Whisper 這類轉錄技術是如何工作的，以及我是否能夠用 ffmpeg 準確剪掉「嗯」這樣的語氣詞或較長的停頓。

我希望 Claude 創建一個 UI，并讓它與我說出的詞語在時間上同步，但我不確定它是否能做到。于是我讓 Claude 使用 Remotion 和轉錄文本創建一個視頻原型，看看這個想法是否可行。

最后，視頻本身看起來有些灰暗。我知道這是調色問題，但我并不真正了解什么是調色。我第一次嘗試時，是想讓 Claude 做幾個版本讓我來選，但我意識到，當涉及調色時，我并不知道什么才算「好」。于是，我沒有繼續讓它盲目生成版本，而是讓 Claude 教我調色，以此發現自己的未知項。

讓地圖與疆域匹配

模型越強，你就越能通過正確的方法完成更多事情。當一個長周期任務返回了錯誤結果時，很可能說明你需要花更多時間定義自己的未知項，或者創建一份實現計劃，讓 Claude 能夠在這些未知項中靈活應對。

每一份解釋文檔、頭腦風暴、訪談、原型和參考資料，都是一種低成本的方法，可以在修復代價變高之前，先發現那些你原本不知道的事情。

所以，在開始下一個項目時，先讓 Claude 幫你找到自己的未知項。

【ICML 2026首爾 · 云帆AI Talent Meetup】最后報名中，快來晚宴現場Pick你感興趣的同行者～

7月9日晚，首爾ICML會場旁，上海人工智能實驗室、上海科技大學、上海創智學院、階躍星辰、Sharpa Robotics等20余家上海頂尖AI單位現場設展，開放100+崗位。專場招聘、學術分享、圓桌交流、自由Networking、晚宴一站式搞定。

報名鏈接：https://www.feishu.cn/share/base/form/shrcncJn0AtC2NwSJJQTNYbo3yh?share_link_type=qrcode&ccm_open_type=form_qrcode