Anthropic內部人員撰寫！Fable 5使用硬核指南：搞定未知盲區，AI 編程效率直接起飛
整理版優先睇
想用好Claude Fable 5？先學識發現自己嘅未知數，呢個先係效率起飛嘅關鍵。
呢篇文章係Anthropic內部Claude Code團隊成員Thariq根據自己親身經驗寫嘅指南，主要講點樣更有效咁用Claude Fable 5。佢反覆得到一個教訓：你畀Claude嘅prompt、技能設定、上下文（即係「地圖」），同實際嘅代碼庫、現實限制（即係「疆域」）之間，永遠有落差。呢啲落差就係佢所講嘅「未知數」。當Claude碰到未知數，佢就要靠估你嘅意圖，做得越多，偏差就越大。Thariq認為Fable係第一個令佢明顯感覺到，工作質素嘅瓶頸在於自己能唔能夠講清楚未知數嘅模型。
整體結論係：要駕馭好Fable 5，發現未知領域係一個核心技能，而且呢個技能可以透過同Claude一齊工作嚟提升。Thariq提出咗一系列實用方法，包括盲區掃描、頭腦風暴、提問式訪談、參考物、實施計劃、實施筆記、說明文檔同測驗。呢啲方法嘅共同目標，就係喺代價變得高昂之前，低成本咁發現自己唔知道乜嘢。
最重要嘅係，Thariq強調呢個過程唔係一次過嘅規劃，而係一個喺實施前、中、後不斷迭代發現未知數嘅循環。模型越強，你越需要花時間講清楚未知數，或者整一份能讓Claude自行應變嘅實施計劃。每一次解釋、頭腦風暴、訪談、原型同參考物，都係幫你嘅「地圖」更貼近「疆域」。
- 核心概念：地圖（prompt/技能）≠ 疆域（實際代碼），中間嘅落差就係未知數；發現未知數係提升AI編程效率嘅關鍵技能。
- 四類未知數：已知嘅已知（已寫喺prompt）、已知嘅未知（清楚自己唔清楚）、未知嘅已知（見到先認得嘅標準）、未知嘅未知（完全冇諗過嘅嘢）；最擅長agentic coding嘅人未知數最少。
- 實戰方法一：盲區掃描同頭腦風暴——直接叫Claude幫你挖出「未知嘅未知」，或者一齊整原型，盡早確認「未知嘅已知」避免後期大改。
- 實戰方法二：提問式訪談同參考物——叫Claude反問你模糊位，或者俾個參考源代碼（唔限語言），等佢讀完再實現相同語義。
- 實戰方法三：實施計劃同筆記——開工前叫Claude寫計劃，將易改決策放前面；實施時自動記低偏離（deviations），最後叫Claude出測驗考你，確保你完全理解改動。
地圖 vs 疆域：未知數就係效率瓶頸
Thariq反覆得到一個教訓：「地圖」係你交畀Claude嘅prompt、技能設定同上下文，「疆域」係代碼庫、現實世界同佢哋本身嘅限制。兩者之間嘅落差，就係「未知數」。
地圖唔等於疆域
當Claude喺工作中碰到未知數，佢就要根據自己對你意圖嘅猜測做決定。要做嘅嘢越多，Claude可能碰到嘅未知數就越多。Thariq覺得，Fable係第一個令佢明顯感覺到「工作質素嘅瓶頸在於自己能唔能夠講清楚未知數」嘅模型。
認識你嘅未知數：四類認知
Thariq習慣將自己對問題嘅認知拆成四類：已知嘅已知（寫喺prompt嘅嘢）、已知嘅未知（知道自己未諗清楚）、未知嘅已知（見到先認得但唔會主動寫嘅標準）、未知嘅未知（完全冇考慮過嘅嘢）。
未知嘅已知
未知嘅未知
佢觀察到最擅長agentic coding嘅人，好似Boris同Jarred，未知數往往最少，但佢哋同樣假設未知數嘅存在。減少同規劃未知數，就係agentic coding嘅核心技能。
挖掘未知數嘅實戰工具箱
Thariq分享咗幾種具體方法，唔係次次全部用，但作為一套工具集好實用。
盲區掃描
頭腦風暴與原型
提問式訪談
參考物（最好係源代碼）
- 1 盲區掃描：直接叫Claude幫你挖出「未知嘅未知」，例如「我對呢個codebase嘅auth模塊唔熟，做一次盲區掃描」。
- 2 頭腦風暴與原型：喺未知嘅已知特別多嘅領域，叫Claude出幾個HTML原型等你揀，避免後期大改。
- 3 提問式訪談：叫Claude反問模糊位，優先問會改變整體架構嘅問題。
- 4 參考物：俾個源碼檔案或網站，叫Claude讀完實現相同語義，唔限程式語言。
- 5 寫實施計劃：叫Claude將最可能改嘅決策放前面，機械式重構放底。
- 6 實施筆記：開新session後叫Claude維護implementation-notes.md，紀錄偏離原計劃嘅決定。
- 7 說明文檔與彙報材料：將原型、規格、筆記打包成方便Slack分享嘅文檔，加快審批。
- 8 測驗：完結前叫Claude出HTML測驗考你，答啱先合併代碼。
案例：Fable發佈視頻係點樣出嚟
Fable嘅發佈視頻完全由Claude Code剪輯，對Thariq嚟講係全新領域。佢從自己已知嘅嘢入手：先叫Claude解釋Whisper轉錄技術同ffmpeg點樣剪走語氣詞同停頓。
用Remotion做原型
然後叫Claude用Remotion同轉錄文本做原型驗證可行性。最後視頻太悶，佢知道係調色問題但唔識，第一次叫Claude出幾個版本揀，發覺自己根本唔知好嘅調色係點。
反過來叫Claude教自己認識調色
於是佢改叫Claude教佢認識調色，從而發現呢方面嘅未知數。呢個案例正好示範咗點樣用文章介紹嘅方法逐步縮細地圖同疆域嘅差距。
點樣先用得Fable 5用得更好？claude code團隊成員Thariq呢篇文章《A Field Guide to Fable: Finding Your Unknowns》可能會俾你啲啓發，一句講曬，想駕馭好Fable 5，發現未知領域係一個重要技能。好值得睇。
用Claude Fable 5呢段時間，claude code團隊成員Thariq反覆得到同一個教訓：地圖唔等於疆域。
地圖，即係你俾Claude嘅嘢，包括你嘅prompt、技能設定同上下文，代表你對要做嘅嘢嘅描述。疆域，就係工作真正發生嘅地方：代碼庫、現實世界，同埋佢哋本身嘅各種限制。
地圖同疆域之間嘅落差，就係Thariq所講嘅未知數。當Claude喺工作入面碰到一個未知數，佢就要根據自己對你意圖嘅猜測去做決定。要做嘅工作越多，Claude可能碰到嘅未知數就會越多。
Thariq認為，Fable係第一個令到佢明顯感覺到，工作質量嘅瓶頸在於自己係咪可以將未知數講得清楚嘅模型。
需要講明嘅係，提早計劃好曬唔一定夠用。有啲未知數要到咗實現階段先會浮出嚟，甚至呢啲未知數會話俾你知，應該轉用完全唔同嘅思路去解決問題。
Thariq將同Fable一齊工作嘅過程，描述成一個喺實施之前、之中、之後不斷發現自己未知數嘅迭代過程。
認識你嘅未知數
面對一個問題，Thariq習慣將自己嘅認知拆成四類：
已知嘅已知：話俾agent知我想要啲乜，基本上就係寫喺prompt入面嘅內容。
已知嘅未知：自己仲未諗清楚，但清楚知道自己未諗清楚嘅部分。
未知嘅已知：自己見到先會認出嚟，但從來唔會主動寫低嘅標準同要求。
未知嘅未知：完全冇考慮過嘅嘢，包括唔知自己唔知嘅知識，同埋唔知一件事究竟可以做得好到咩程度。
Thariq觀察到，最擅長做agentic coding嘅人，未知數往往最少。好似Boris同Jarred呢啲人，明顯對自己想要啲乜嘢一清二楚，佢哋同代碼庫、同模型行為都好高度同步。
但佢哋同樣都有假設未知數嘅存在。喺好大程度上，減少同規劃自己嘅未知數，正正係agentic coding呢件事本身嘅核心技能。好消息係，呢項技能可以透過同Claude一齊工作嚟提升。
等Claude幫你發現未知數
指揮Claude係個精細活。指令太具體，Claude會嚴格照做，就算換個方向明顯更合適。指令太模糊，Claude又成日按行業最佳實踐去估，而呢啲猜測未必適合你嘅具體任務。
如果你冇將自己嘅未知數考慮在內，兩頭都會出問題：你唔知前面嘅路幾時會佈滿障礙，亦都唔知幾時會一路暢通，但你仍然希望Claude可以喺適當嘅時候轉彎。
Claude可以幫你更快發現未知數。佢可以極快咁搜索你嘅代碼庫同互聯網，對大多數話題嘅瞭解亦都比你多好多，失敗之後迭代嘅速度亦都更快。
呢個過程入面最重要嘅一步，係將你嘅起點話俾Claude知，例如：
• 話俾佢知你而家思考進展到咗邊步 • 講明你對呢個問題同呢個代碼庫嘅熟悉程度 • 等佢好似一個思考夥伴咁，同你一齊工作
Thariq提到，自己之前寫過關於用HTML同Claude協作嘅內容，喺幾乎所有場景入面，HTML artifact都係視覺化同呈現呢啲內容嘅最佳方式。
接下來佢詳細介紹咗自己用嚟挖掘呢啲未知數嘅幾種方法，唔係每次都會全部用曬，但作為一套工具集好實用。
實施之前
盲區掃描
啱啱開始做一件事嘅時候，搞清楚自己嘅盲區往往係最有用嘅一步。例如你要喺代碼庫一個陌生嘅部分寫新功能，或者等Claude幫你做設計迭代呢類唔熟悉嘅工作，你好大機會會有好多的未知嘅未知。
你可能唔知應該問咩問題，唔知咩叫做好，唔知之前做過邊啲相關工作，亦都唔知應該避開邊啲陷阱。
呢種情況下，Thariq會直接叫Claude幫佢揾出未知嘅未知，並解釋清楚。佢習慣直接用盲區掃描同未知嘅未知呢兩個講法，同時話俾Claude知自己係邊個、瞭解幾多，呢點通常好關鍵。
例如可以咁問Claude：我喺畀一個新嘅auth provider做接入，但對呢個代碼庫入面嘅auth模塊完全唔瞭解，可唔可以做一次盲區掃描，幫我理清楚相關嘅未知嘅未知，令我之後可以問得更準。
再例如：我唔明調色係啲乜，但需要幫呢段視頻調色，可唔可以教我理解調色裏面我唔知嘅部分，令我問得更好。
腦震盪同原型
喺一個未知嘅已知特別多嘅領域入面，即係啲你只有見到先知道啱唔啱嘅標準，Thariq會叫Claude同自己一齊腦震盪、做原型。
喺原型階段盡早將呢啲未知嘅已知講清楚好有價值，因為等到實施階段先發現，代價會高好多。一個功能或規格上嘅小改動，可能導致代碼實現差天共地，agent想撤回之前嘅改動亦都會更困難。
例如你可能淨係想睇下畀一個框加個按鈕會係點樣，並唔需要真係去接後端路由，亦唔需要喺前端維護額外嘅狀態。
視覺設計對Thariq嚟講係好難用語言描述嘅嘢，但佢見到就知自己想唔想要。呢種情況下，佢會叫Claude俾出幾種唔同嘅設計方向。
Thariq幾乎每次都寫代碼前會先做一輪探索或腦震盪，呢個可以幫佢一開始就明確項目範圍。Claude經常可以揾到連佢自己都會漏咗嘅高價值方案，但有時候亦會只見樹木不見森林。腦震盪可以防止佢將範圍定得太窄或太寬。
示例問法包括：我想幫呢份數據做個儀錶板，但我完全冇審美判斷，亦都唔知可以做成點樣，俾我做一個HTML頁面，展示4種風格完全唔同嘅設計方向，我嚟揀。
或者：唔好咁急接後端，做一個獨立嘅HTML文件，將新嘅編輯器工具欄用假數據模擬出嚟，我想先睇下佈局，再俾你鬱真正嘅應用代碼。
又或者：我遇到嘅問題係，用戶喺完成新手引導之後就走咗。去代碼庫入面搜一搜，俾我腦震盪10個可以介入嘅地方，由成本最低到最有野心排序，我嚟話俾你知邊啲方向有得搞。
提問式訪問
做完足夠嘅腦震盪之後，Thariq可能仲會剩低一啲未知數。
呢陣時佢會叫Claude反過嚟訪問自己，針對任何模糊或唔確定嘅地方提問。叫Claude做呢種訪問時，最好俾啲背景資訊佢，幫佢將問題問到點子上。
示例問法：一次只問我一個問題，針對任何有歧義嘅地方，優先問啲答案會改變整體架構嘅問題。
參考物
有時候你冇辦法將想要嘅嘢講得清楚，可能係因為你缺少合適嘅表達方式，亦可能係因為件事太複雜，講清楚要花好長時間。
呢種情況下，最好嘅做法係俾一個參考物。雖然圖表、文檔、圖片都可以做參考，但最好嘅參考物係源碼。
如果有個庫用某種方式實現咗你想要嘅嘢，或者有一個你好鍾意嘅設計組件，直接將Fable指去嗰個文件夾，話俾佢知要揾乜就得，就算係用另一種語言寫嘅都得。
Claude Design嘅工作方式都係咁。你唔一定要上傳文件，都可以直接將佢指去你鍾意嘅某個網站模塊，佢讀嘅係底層代碼，而唔係得截圖，咁樣可以攞到關於標記、結構以及呢個組件具體係點樣搭出嚟嘅更豐富資訊。
示例問法：vendor/rate-limiter呢個Rust crate實現嘅退避行為正正係我想要嘅，睇一睇佢，然後喺我哋嘅TypeScript API客戶端入面實現相同嘅語義。
寫實施計劃
當Thariq覺得可以開始實施喇，佢會叫Claude先做一份實施計劃俾自己審閲，並且重點放喺最可能發生變化嘅部分，例如數據模型、類型接口、用戶體驗流程呢啲。咁樣Claude就可以將佢真正可能需要調整嘅地方擺出嚟。
示例問法：用HTML寫一份實施計劃，但將我最可能想改嘅決策放喺最前面，例如數據模型嘅變化、新嘅類型接口，以及任何面向用戶嘅部分。將啲機械式嘅重構放喺最底，呢部分我信得過你。
實施過程中
實施筆記
計劃確定之後，Thariq會開一個新會話，將之前嘅artifact都傳入去，例如一份規格文件加一個原型，然後叫agent去實現。
但事實係，無論前期規劃做得幾充分，實施過程入面總會匿埋一啲未知嘅未知。agent可能喺工作中發現，代碼入面有個邊界情況逼到佢要換第二種做法。
Thariq會叫Claude Code維護一份臨時嘅implementation-notes.md（或者html版本）文件，記錄佢做出嘅各種決定，方便之後覆盤。
示例問法：維護一份implementation-notes.md文件。如果遇到某個邊界情況，一定要偏離原計劃，就揀保守嗰個方案，喺Deviations呢一節入面記低，然後繼續做落去。
實施完成之後
說明文檔同彙報材料
要將一件事順利上線，攞到人哋嘅認可同批准係好重要嘅一環。喺最終文檔入面加上說明性嘅artifact有兩個好處：
• 可以令評審者由同你一樣嘅起點理解件事，加快理解速度 • 可以令專家見到你已經將佢哋會預料到嘅未知數同常見失敗點都考慮在內，加快審批速度
示例問法：將原型、規格文檔同實施筆記打包成一份文檔，方便我直接掟入Slack去爭取大家嘅認可，將演示動圖放喺最前面。
測驗
一段長時間嘅工作會話結束之後，Claude完成嘅嘢可能比Thariq意識到嘅多好多。淨係睇代碼diff只能俾佢一個模糊嘅瞭解，因為好多行為其實取決於現有嘅代碼路徑。
俾夠背景資訊之後，叫Claude嚟考嚇自己，可以幫佢真正搞明發生咗啲乜。佢只有完全答啱測驗先會合併代碼。
示例問法：我想確定自己完全理解呢次改動嘅所有內容。俾我一份關於呢次改動嘅HTML報告，包含背景、直覺判斷、具體做咗啲乜，最後再加一個關於呢次改動嘅測驗，我必須要答啱。
案例：Fable發佈視頻係點樣做出嚟嘅
Fable嘅發佈視頻完全由Claude Code剪輯完成。呢個對Thariq嚟講係個全新嘅領域，佢唔係呢方面嘅專家。
所以佢由自己已經知道嘅嘢入手。佢知道Claude可以用代碼剪輯視頻、做轉錄，但唔肯定精度夠唔夠，於是叫Claude同自己講清楚好似Whisper呢啲轉錄技術係點樣運作嘅，以及可唔可以用ffmpeg準確咁將嗯啊之類嘅語氣詞同大段停頓剪走。
佢希望做一個可以同自己講話節奏對得埋嘅界面，但唔肯定Claude做唔做到，於是叫Claude先用Remotion同一段轉錄文本做一個原型視頻，驗證係咪可行。
最後，視頻本身睇起嚟有啲悶，佢知道係調色嘅問題，但唔係真係瞭解調色係啲乜。佢第一次嘗試係叫Claude做幾個唔同版本俾自己揀，但好快意識到自己根本唔知好嘅調色係咩樣。於是我改咗叫Claude教佢認識調色，嚟發現呢方面嘅未知數。
等地圖匹配疆域
模型能力越強，用啱方法可以做到嘅嘢就越多。當一個長週期任務嘅結果唔對路，往往係話你需要花更多時間將自己嘅未知數講清楚，或者做一份可以令Claude喺遇到未知數時自行應變嘅實施計劃。
每一次說明、腦震盪、訪問、原型同參考物，都係喺件事變得代價高昂之前，提早發現自己唔知啲乜嘅低成本方式。
所以，下一個項目開始之前，不妨先叫Claude幫你將未知數揾出嚟。
參考：
https://x.com/trq212/status/2073100352921215386
--end--
最後記得⭐️我，每日都有更新：如果覺得文章仲唔錯嘅話可以點讚轉發推薦評論
/...@作者：你講嘅完全正確（YAR師）
如何更好的使用Fable 5？claude code 團隊內部成員Thariq的這篇文章《A Field Guide to Fable: Finding Your Unknowns》可能會給你一些啓發，一句話來說，要駕馭好Fable 5，發現未知領域是一個重要技能。非常值得一讀。
在使用Claude Fable 5的這段時間裏,claude code 團隊成員Thariq反覆得到同一個教訓:地圖不等於疆域。
地圖,是你交給Claude的東西,包括你的prompt、技能設定和上下文,代表你對要做的事情的描述。疆域,則是工作真正發生的地方:代碼庫、現實世界,以及它們本身的各種限制。
地圖和疆域之間的落差,就是Thariq所說的未知數。當Claude在工作中碰到一個未知數,它就得根據自己對你意圖的猜測做出決定。要做的工作越多,Claude可能碰到的未知數也就越多。
Thariq認為,Fable是第一個讓他明顯感覺到,工作質量的瓶頸在於自己能不能把未知數講清楚的模型。
需要說明的是,提前把計劃做足並不總是夠用。有些未知數只有深入到實現階段才會暴露出來,甚至這些未知數會告訴你,應該換一種完全不同的思路去解決問題。
Thariq把和Fable一起工作的過程,描述成一個在實施之前、之中、之後不斷髮現自己未知數的迭代過程。
認識你的未知數
面對一個問題,Thariq習慣把自己的認知拆成四類:
已知的已知:告訴agent我想要什麼,基本就是寫在prompt裏的內容。
已知的未知:自己還沒想清楚,但清楚地知道自己沒想清楚的部分。
未知的已知:自己見到才會認出來、但從來不會主動寫下來的標準和要求。
未知的未知:完全沒有考慮過的東西,包括不知道自己不知道的知識,以及不知道一件事到底能做到多好。
Thariq觀察到,最擅長做agentic coding的人,未知數往往最少。像Boris和Jarred這樣的人,明顯對自己想要什麼瞭如指掌,他們和代碼庫、和模型行為都高度同步。
但他們同樣也在假設未知數的存在。在很大程度上,減少並規劃自己的未知數,正是agentic coding這件事本身的核心技能。好消息是,這項技能可以通過和Claude一起工作來提升。
讓Claude幫你發現未知數
指揮Claude是個精細活。指令太具體,Claude會嚴格照做,哪怕換個方向明顯更合適。指令太模糊,Claude又常常按行業最佳實踐去猜,而這些猜測未必適合你的具體任務。
如果你沒有把自己的未知數考慮進去,兩頭都會出問題:你不知道前面的路什麼時候佈滿障礙,也不知道什麼時候一路暢通,但你仍然希望Claude能在恰當的時候轉向。
Claude能幫你更快地發現未知數。它能極快地搜索你的代碼庫和互聯網,對大多數話題的瞭解也比你多得多,失敗後迭代的速度也更快。
這個過程裏最重要的一步,是把你的起點告訴Claude,比如:
• 告訴它你現在的思考進展到了哪一步 • 說明你對這個問題和這個代碼庫的熟悉程度 • 讓它像一個思考夥伴一樣,和你一起工作
Thariq提到,自己之前寫過關於用HTML和Claude協作的內容,在幾乎所有場景裏,HTML artifact都是可視化和呈現這些內容的最佳方式。
接下來他詳細介紹了自己用來挖掘這些未知數的幾種方法,不是每次都會全部用上,但作為一套工具集非常實用。
實施之前
盲區掃描
剛開始做一件事的時候,搞清楚自己的盲區往往是最有用的一步。比如你要在代碼庫一個陌生的部分寫新功能,或者讓Claude幫你做設計迭代這類不熟悉的工作,你大概率會有很多未知的未知。
你可能不知道該問什麼問題,不知道什麼算好,不知道之前做過哪些相關工作,也不知道該避開哪些坑。
這種情況下,Thariq會直接讓Claude幫他找出未知的未知,並解釋清楚。他習慣直接用盲區掃描和未知的未知這兩個說法,同時告訴Claude自己是誰、瞭解多少,這一點通常很關鍵。
比如可以這樣問Claude:我在給一個新的auth provider做接入,但對這個代碼庫裏的auth模塊完全不瞭解,能不能做一次盲區掃描,幫我理清楚相關的未知的未知,讓我之後能問得更準。
再比如:我不懂調色是什麼,但需要給這段視頻調色,能不能教我理解調色裏我不知道的部分,讓我能問得更好。
頭腦風暴與原型
在一個未知的已知特別多的領域裏,也就是那些你只有看到才知道對不對的標準,Thariq會讓Claude和自己一起頭腦風暴、做原型。
在原型階段儘早把這些未知的已知說清楚非常有價值,因為等到實施階段才發現,代價會高得多。一個功能或規格上的小改動,可能導致代碼實現天差地別,agent想要撤回之前的改動也會更困難。
比如你可能只想看看給一個框加個按鈕長什麼樣子,並不需要真的去接後端路由,也不需要在前端維護額外的狀態。
視覺設計對Thariq來說是很難用語言描述的東西,但他看到了就知道自己想不想要。這種情況下,他會讓Claude給出幾種不同的設計方向。
Thariq幾乎每次寫代碼前都會先做一輪探索或頭腦風暴,這能幫他一開始就明確項目範圍。Claude經常能找到他自己都會漏掉的高價值方案,但有時候也會只見樹木不見森林。頭腦風暴能防止他把範圍定得過窄或過寬。
示例問法包括:我想給這份數據做個儀表盤,但我完全沒有審美判斷,也不知道能做成什麼樣,給我做一個HTML頁面,展示4種風格完全不同的設計方向,我來挑。
或者:先別急着接後端,做一個單獨的HTML文件,把新的編輯器工具欄用假數據模擬出來,我想先看看佈局,再讓你動真正的應用代碼。
又或者:我遇到的問題是,用戶在完成新手引導後就流失了。去代碼庫裏搜一搜,給我頭腦風暴10個可以介入的地方,從成本最低到最有野心排序,我來告訴你哪些方向有戲。
提問式訪談
做完足夠的頭腦風暴之後,Thariq可能還是會剩下一些未知數。
這時他會讓Claude反過來採訪自己,針對任何模糊或不確定的地方提問。讓Claude做這種訪談時,最好給它一些背景信息,幫它把問題問到點子上。
示例問法:一次只問我一個問題,針對任何有歧義的地方,優先問那些答案會改變整體架構的問題。
參考物
有時候你沒辦法把想要的東西講清楚,可能是因為你缺少合適的表達方式,也可能是因為這件事太複雜,講清楚要花很久時間。
這種情況下,最好的辦法是給一個參考物。雖然圖表、文檔、圖片都可以作為參考,但最好的參考物是源代碼。
如果有一個庫用某種方式實現了你想要的東西,或者有一個你很喜歡的設計組件,直接把Fable指向那個文件夾,告訴它要找什麼就行,哪怕那是用另一種語言寫的。
Claude Design的工作方式也是這樣。你不需要一定上傳文件,也可以直接把它指向你喜歡的某個網站模塊,它讀的是底層代碼,而不只是截圖,這樣能拿到關於標記、結構以及這個組件具體是怎麼搭出來的更豐富的信息。
示例問法:vendor/rate-limiter這個Rust crate實現的退避行為正是我想要的,讀一下它,然後在我們的TypeScript API客戶端裏實現相同的語義。
寫實施計劃
當Thariq覺得可以開始實施了,他會讓Claude先做一份實施計劃給自己審閲,並且重點放在最可能發生變化的部分,比如數據模型、類型接口、用戶體驗流程這些。這樣Claude就能把他真正可能需要調整的地方擺出來。
示例問法:用HTML寫一份實施計劃,但把我最可能想改的決策放在最前面,比如數據模型的變化、新的類型接口,以及任何面向用戶的部分。把那些機械式的重構放在最底下,這部分我信得過你。
實施過程中
實施筆記
計劃確定之後,Thariq會開一個新會話,把之前的artifact都傳進去,比如一份規格文件加一個原型,然後讓agent去實現。
但事實是,不管前期規劃做得多充分,實施過程裏總會藏着一些未知的未知。agent可能在工作中發現,代碼裏有個邊界情況迫使它必須換一種做法。
Thariq會讓Claude Code維護一份臨時的implementation-notes.md(或者html版本)文件,記錄它做出的各種決定,方便之後覆盤。
示例問法:維護一份implementation-notes.md文件。如果遇到某個邊界情況,必須偏離原計劃,就選保守的那個方案,在Deviations這一節裏記下來,然後繼續往下做。
實施完成之後
說明文檔與彙報材料
要把一件事情順利上線,拿到別人的認可和批准是很重要的一環。在最終文檔里加上說明性的artifact有兩個好處:
• 能讓評審者從和你一樣的起點理解這件事,加快理解速度 • 能讓專家看到你已經把他們會預料到的未知數和常見失敗點都考慮進去了,加快審批速度
示例問法:把原型、規格文檔和實施筆記打包成一份文檔,方便我直接丟進Slack去爭取大家的認可,把演示動圖放在最前面。
測驗
一段長時間的工作會話結束後,Claude完成的東西可能比Thariq意識到的要多得多。光看代碼diff只能給他一個模糊的瞭解,因為很多行為其實取決於既有的代碼路徑。
給足夠的背景信息之後,讓Claude來考考自己,能幫他真正搞懂發生了什麼。他只有完全答對測驗才會合併代碼。
示例問法:我想確認自己完全理解這次改動的所有內容。給我一份關於這次改動的HTML報告,包含背景、直覺判斷、具體做了什麼,最後再加一個關於這次改動的測驗,我必須答對。
案例:Fable發佈視頻是怎麼做出來的
Fable的發佈視頻完全由Claude Code剪輯完成。這對Thariq來說是個全新的領域,他不是這方面的專家。
所以他從自己已經知道的東西入手。他知道Claude能用代碼剪輯視頻、做轉錄,但不確定精度夠不夠,於是讓Claude給自己講清楚像Whisper這樣的轉錄技術是怎麼工作的,以及能不能用ffmpeg準確地把嗯啊之類的語氣詞和大段停頓剪掉。
他希望做出一個能和自己說話節奏對上的界面,但不確定Claude能不能做到,於是讓Claude先用Remotion和一段轉錄文本做一個原型視頻,驗證是否可行。
最後,視頻本身看起來有點發悶,他知道這是調色的問題,但並不真的瞭解調色是什麼。他第一次嘗試是讓Claude做幾個不同版本供自己挑選,但很快意識到自己根本不知道好的調色是什麼樣子。於是他改成讓Claude教自己認識調色,來發現這方面的未知數。
讓地圖匹配疆域
模型能力越強,用對方法能做到的事情就越多。當一個長週期任務的結果不對勁,往往說明你需要花更多時間把自己的未知數講清楚,或者做一份能讓Claude在遇到未知數時自行應變的實施計劃。
每一次說明、頭腦風暴、訪談、原型和參考物,都是在事情變得代價高昂之前,提前發現自己不知道什麼的低成本方式。
所以,下一個項目開始前,不妨先讓Claude幫你把未知數找出來。
參考：
https://x.com/trq212/status/2073100352921215386
--end--
最後記得⭐️我，每天都在更新：如果覺得文章還不錯的話可以點贊轉發推薦評論
/...@作者：你說的完全正確（YAR師）