Claude Code團隊工程師的 Fable 5 的實戰指南
整理版優先睇
Thariq 指出 AI 編程嘅關鍵係辨識同處理「未知」，透過系統性方法讓 Claude Code 幫你更快發現未知。
呢篇文章係 Claude Code 團隊工程師 Thariq 基於 Fable 5 實戰經驗寫嘅指南。佢想解決嘅問題係：點樣先可以更有效咁用 AI 編程工具，尤其係非專業人員同專業人員嘅差別，同埋到底應唔應該睇 AI 寫嘅 code。佢嘅核心結論係：AI 編程嘅瓶頸唔係模型能力，而係你自己「講清楚未知」嘅能力。
Thariq 提出「地圖唔係疆域」呢個比喻——prompt、skill 同上下文只係紙上地圖，真正要處理嘅 code base、現實約束先係疆域，兩者之間嘅落差就係「未知」。佢將未知分做四類：已知已知、已知未知、未知已知、未知未知。佢認為 Vibe coding 已經過時，而家要做嘅係 agentic coder，核心技能係做出假設、減少同規劃未知。
文章詳細講咗一套實施流程：先用盲區掃描、頭腦風暴、訪談同參考嚟提前發現未知，然後整實現計劃，再開新 session 執行，並用 implementation-notes.md 記錄偏離計劃嘅決定。最後要整交付文檔同測驗先 merge code。Thariq 仲用 Fable 發佈視頻剪輯做案例，展示點樣一步步面對未知並解決問題。
- 核心觀點：地圖（prompt、skill）唔係疆域（實際 code base），差距就係「未知」，AI 編程嘅瓶頸係你講清楚未知嘅能力。
- 未知分類：已知已知（寫明嘅）、已知未知（知自己唔清楚）、未知已知（見咗先識判斷）、未知未知（完全冇諗過），而處理未知係 agentic coder 嘅核心。
- 方法流程：實施前做盲區掃描、頭腦風暴、訪談同參考；實施時整實現計劃、開新 session、用 implementation-notes.md；完成後整交付文檔同測驗。
- 差異啟發：非專業人員靠 Vibe coding 亂撞，專業人員應該系統性標識未知；每次頭腦風暴、訪談都係低成本發現未知嘅機會。
- 可行動點：下個項目開始前，先叫 Claude 幫你找出自己嘅未知；遇到陌生領域就做盲區掃描，用參考（源碼、網站）代替長篇描述。
地圖唔係疆域：認清未知先係關鍵
Thariq 提出一個核心比喻：「地圖唔係疆域。」
Claude 嘅 prompt、skill 同上下文只係地圖，真正要處理嘅 code base、現實約束先係疆域。兩者之間嘅落差就係「未知」，而 Claude 每次遇到未知就要靠猜測做決定。
- 1 已知已知：寫喺 prompt 裏面、明確話畀 Claude 嗰部分。
- 2 已知未知：自己知道仲未諗清楚嘅部分。
- 3 未知已知：理所當然唔會寫出嚟，但見到就識認得嘅標準。
- 4 未知未知：完全冇考慮過嘅嘢，包括自己唔知自己唔知。
Agentic Coder：幫 Claude 幫你
Thariq 認為 Vibe coding 已經過時，𠵱家要做嘅係 agentic coder——核心技能係做出假設、減少同規劃未知。指揮 Claude 係微妙平衡：指令太具體會機械執行，太模糊又會按行業慣例做錯假設。
問題癥結在於處理好未知，而 Claude 能幫你更快發現未知。
Claude 搜索 code base 同互聯網好快，對大多數話題瞭解比普通人多，就算失敗重新迭代都快好多。最重要係交代清楚出發點：話畀 Claude 你思考到邊一步、你對問題同 code base 嘅經驗，等佢好似一個真正嘅思考者同你配合。
HTML artifact 係可視化呢類內容最好嘅方式。
實施前：用低成本發現未知
- 1 盲區掃描：喺陌生領域（如新認證模塊或調色）直接叫 Claude 幫你找出未知未知，關鍵係交代清楚你係邊個、你識啲咩。
- 2 頭腦風暴同原型：涉及大量「未知已知」時，叫 Claude 一齊 brainstorm 同做 prototype，例如想看按鈕效果唔使接後端，或者叫 Claude 畀多種設計方向。
- 3 訪談：做完 brainstorm 仲有未知，叫 Claude 就模糊之處 interview 你，一次問一個問題，優先問會改變架構嘅問題。
- 4 參考：如果冇辦法詳細描述，最好畀一個參考——源代碼係最佳，即使語言唔同都得；或者指向網站模塊，Claude 會讀底層 code。
參考源碼比用文字描述更有效。
實施階段：計劃、記錄、交付、測試
- 1 實現計劃：開新 session 前叫 Claude 整一份計劃，重點放喺最可能變化嘅部分（數據模型、類型接口、用戶體驗流程），用 HTML 呈現，先講最可能調整嘅決定。
- 2 實施記錄：喺 Claude Code 維護一份 implementation-notes.md，記錄 agent 做嘅決定；遇到邊緣情況時選保守方案，記低再繼續。
- 3 交付文檔：將 prototype、spec 同筆記打包成一份文檔，開頭放演示 GIF，直接丟去 Slack 爭取認可。
- 4 測驗：長時間會話後叫 Claude 畀背景信息然後測驗，只有完全通過先 merge code。可以用 HTML 報告附帶背景同必須通過嘅測驗。
佢強調每一個長週期任務結果唔啱，往往係需要花更多時間定義未知，或者整一份畀 Claude 即興發揮嘅計劃。
Fable 發佈案例：從零到一嘅未知探索
Thariq 用 Fable 發佈視頻做案例，佢完全唔識剪輯，但逐步用 Claude Code 完成。首先從已知入手：知道 Claude 能用 code 剪輯同轉錄視頻，但唔肯定精度。於是叫 Claude 解釋 Whisper 原理同用 ffmpeg 剪走語氣詞。
佢想整一個跟隨講話時間軸變化嘅 UI，但唔確定做到，就叫 Claude 用 Remotion 同轉錄文本做 prototype 驗證。
最後視頻有啲悶，佢知係調色問題，但唔識調色。第一次叫 Claude 畀幾種方案，但發現自己根本唔知「好」嘅標準，於是轉而叫 Claude 教佢調色知識，藉此發現自己嘅未知。
Claude Code 團隊工程師 Thariq 出咗一篇叫 Find You Unknows 嘅 Fable 5 實戰文章。
雖然係講 Fable 5，但我覺得佢對我哋依家所有嘅 AI 編程都有好好嘅指導意義。
呢篇文章都解答咗好多問題，例如非專業人員同專業人員 AI 編程嘅分別、AI 寫嘅 code 到底仲有無需要睇，以及 Claude Code 入面嘅一啲高級實踐技巧。
文章開頭，佢就直接講，Fable 5 令佢再一次確認咗之前嘅感覺：
「地圖唔係疆域。」
佢覺得 Claude 嘅 prompt、skill 同上下文就係紙上面嘅地圖，真正要處理嘅 codebase、現實世界同實際限制先係疆域。
兩者之間嘅落差就係「未知」。
Claude 每次遇到一個未知，就要靠估嚟做決定，工作量越大，遇到嘅未知亦越多。
佢覺得 Fable 係第一個令佢感覺到，工作質量嘅瓶頸係佢自己「將未知講清楚」嘅能力嘅模型。
單靠提前計劃其實唔夠，有啲未知要等到實現過程中先會暴露。
認識你嘅未知
佢將處理問題時嘅未知分成四類：
- • 已知已知：寫喺 prompt 裏面、明確話畀 Claude 知嘅部分
- • 已知未知：自己知道但未諗清楚嘅部分
- • 未知已知：理所當然到唔會寫出嚟，但見到就識得判斷啱唔啱嘅標準
- • 未知未知：完全冇考慮過嘅嘢，包括唔知自己唔知乜
Vibe coding 呢個詞去到依家其實已經 out 咗。
依家我哋要做嘅係 agentic coder，而 agentic coder 嘅核心技能係做假設、減少同規劃未知，呢項技能係透過同 Claude 合作完成嘅。
幫 Claude 幫你
佢指出指揮 Claude 係一個微妙嘅平衡：
指令太具體太長太多，Claude 會照單全收機械式執行；太模糊呢，Claude 就會按行業慣例做出可能唔啱你心水嘅假設。
所以問題嘅關鍵就在於處理好未知。
佢認為 Claude 可以幫你更快發現未知，佢搜尋 codebase 同互聯網嘅速度好快，對大多數話題嘅瞭解都比普通人多，就算失敗，重新迭代嘅速度都快啲。
呢個過程入面最重要係同 Claude 講清楚你嘅出發點：
話畀佢知你諗到邊一步、你對呢個問題同 codebase 嘅經驗係點，等佢好似一個真正嘅思考者咁同你配合。
佢提過自己之前寫過關於用 HTML 同 Claude 協作嘅內容，認為 HTML artifact 就可以作為呢類可視化同呈現呢類內容最好嘅方式。
實施前階段
1. 盲點掃描
喺陌生領域工作時，例如新 code module 或者唔熟悉嘅設計任務，未知嘅未知會特別多。
呢個時候可以直接叫 Claude 幫你揾出呢啲未知未知，解釋畀你聽，佢強調同 Claude 講清楚你係邊個、你識啲乜好重要。
佢舉咗兩個例子：
一個係加新嘅認證方式但完全唔瞭解認證 module，另一個係完全唔識調色但需要幫影片調色。
2. 腦力激盪同原型
喺涉及大量「未知已知」，即係見到先知啱唔啱嘅標準嘅領域，佢鍾意叫 Claude 一齊腦力激盪同做原型。
佢認為喺原型階段盡早將呢啲標準講出嚟好划算，因為等到實現階段先發現代價會高好多，一個細微嘅功能或需求變化，可能會令 code 實現相差好遠，agent 撤銷之前嘅改動都會更難。
舉例來講，你可能只係想睇下一個掣加落界面係咩效果，唔需要真係駁後端路由或者維護額外嘅前端狀態。
視覺設計對佢嚟講好難用語言描述，但係見到就知道要唔要，所以佢會叫 Claude 畀出多種設計方向。
幾乎每次寫 code 前都會先做探索或者腦力激盪階段，咁樣有助於一開始就明確項目範圍，Claude 成日都會揾到佢會漏咗嘅高價值思路。
3. 訪談
做完腦力激盪之後如果仲有未知，佢會叫 Claude 就任何模糊嘅地方訪問佢，並強調要同 Claude 講清楚問題背景嚟引導佢提問嘅方向。
例如叫 Claude 一次問一個問題，優先問啲答案會改變架構嘅問題。
4. 參考
有時你冇辦法詳細描述想要啲乜，可能係缺乏合適嘅語言，或者太複雜要講清楚要花好耐。
呢種情況下最好嘅答案係畀一個參考。可以用圖表、文件或圖片，但最好嘅參考係源碼。
如果有個 library 用某種方式實現咗你想要嘅嘢，或者你好鍾意某個設計 component，直接將 Fable 指向嗰個 folder，話畀佢知要睇乜，就算語言唔同都冇問題。
Claude Design 都係呢個思路。
唔一定要畀文件，可以直接指向一個網站上面嘅某個 module，佢會讀底層 code 而唔止係 screenshot，咁樣可以得到關於 markup、結構同 component 實際構建方式嘅更豐富細節。
5. 實現計劃
準備開始實現之前，佢會叫 Claude 整理一份實現計劃畀佢睇，重點放喺最可能變化嘅部分，例如數據 model、type interface 或用戶體驗流程，咁樣 Claude 就可以將佢可能真係需要調整嘅地方展示出嚟。
例如用 HTML 寫實現計劃，但先講佢最可能想調整嘅決定，數據 model 變化、新嘅 type interface、以及任何用戶可見嘅部分，將機械式嘅重構內容放喺最後，因為嗰部分佢信 Claude 可以處理好。
6. 實施階段
對計劃滿意之後，佢會開一個新 session，將相關 artifact 傳入去，例如一份 spec 文件加一個原型，等 agent 根據呢啲嚟實現。
但無論計劃做得幾充分，agent 可能喺工作入面發現需要因為 code 裏面嘅邊緣情況而採取唔同做法。
叫 Claude Code 維護一份臨時嘅 implementation-notes.md 文件，記錄佢做出嘅決定，方便下次學習。
如果遇到迫令偏離計劃嘅邊緣情況，揀保守方案，將佢記喺對應條目下面，然後繼續。
7.實現之後：
交付工作裏面最重要嘅一環係取得認可同批准。製作 pitch 同講解類嘅最終文件有幫助。
令評審者同你一樣嘅起點開始理解，加快理解速度，等專家見到你已經考慮到佢哋會預料到嘅未知同常見失敗點，從而加快批准速度。
將原型、spec 同實現筆記打包成一份文件，可以直接掉入 Slack 爭取認可，開頭放 demo GIF。
8. 測試
經過一段長時間嘅工作 session，Claude 完成嘅工作量可能比想像中多好多。
淨係睇 code diff 只能對發生咗嘅事有個模糊瞭解，因為好多行為取決於現有嘅 code path。
佢會叫 Claude 喺畀佢足夠背景信息之後對呢次改動進行測試，只有完全通過測試先會 merge code。
可以畀出一份 HTML 報告，附帶背景信息、直覺判斷、做咗啲乜等內容，尾尾附一個關於呢次改動必須通過嘅測試。
Fable 發佈案例
佢提到 Fable 嘅發佈影片完全係由 Claude Code 剪輯嘅，呢個對佢嚟講係個全新領域。
佢由自己已知嘅部分入手，知道 Claude 可以用 code 剪輯同轉錄影片，但唔肯定精度夠唔夠。
於是佢叫 Claude 解釋好似 Whisper 咁嘅轉錄原理，同埋能否用 ffmpeg 精確剪走「嗯啊」呢類語氣詞同長停頓。
之後想要一個跟住佢講嘢時間軸變化嘅 UI，但唔肯定做唔做到，於是叫 Claude 用 Remotion 同轉錄文本做咗個原型影片先驗證可行性。
最後，影片整體睇起嚟有啲悶，知道係調色嘅問題，但唔太識調色係乜。
第一次嘗試係叫 Claude 做幾種調色方案畀佢揀，但發現自己根本唔知「好」嘅調色標準係點樣，於是轉而叫 Claude 教佢調色知識，嚟發現自己嘅未知，佢提到有一個更詳細嘅影片講解咗呢部分內容。
最後總結
當一個長週期任務嘅結果唔啱時，往往說明你需要花更多時間定義自己嘅未知，或者做一份令 Claude 喺遇到未知時都可以即興發揮嘅實現計劃。
每一次講解、腦力激盪、訪談、原型同參考，都係一種平靚正嘅方式，可以喺代價變得高昂之前，提前發現你本來唔知嘅嘢，所以佢都建議，下一個項目開始之前，先叫 Claude 幫你揾出自己嘅未知。
所以由頭睇到尾你會發現佢講嘅就係點樣去發現自己嘅未知領域，並協同 Claude Code 去挖掘呢個未知知道自己知道，比知道自己唔知道更難。
Claude Code 團隊工程師 Thariq 發表了一篇Find You Unknows 的Fable 5實戰文章。
雖然是講 Fable 5 的，但是我覺得它對於我們目前所有的 AI 編程都有非常好的指導意義。
這篇文章也解答了很多的問題，像是非專業人員與專業人員 AI 編程的區別，AI 寫的代碼到底還要不要去看，以及在 Claude Code 當中的一些高級實踐技巧。
在文章的開篇，他就直抒胸臆，Fable 5 讓他再一次驗證了之前的感受：
“地圖不是疆域。”
他認為Claude 的 prompt、skill 和上下文就是紙面上的地圖，真正要處理的代碼庫、現實世界和實際約束才是疆域。
兩者之間的落差就是"未知"。
Claude 每碰到一個未知，就得靠猜測來做決定，工作量越大，遇到的未知也越多。
他認為 Fable 是第一個讓他感覺到，工作質量的瓶頸是他自己"把未知講清楚"的能力的模型。
光靠提前規劃其實並不夠，有些未知只有到實現過程中才會暴露。
認識你的未知
他把處理問題時的未知拆成四類：
- • 已知已知：寫在 prompt 裏、明確告訴 Claude 的部分
- • 已知未知：自己知道還沒想清楚的部分
- • 未知已知：理所當然以至於不會寫出來，但見到了就能認出對不對的標準
- • 未知未知：完全沒考慮過的東西，包括不知道自己不知道什麼
Vibe coding這個詞語放到現在其實已經過時了。
現在我們要做的是 agentic coder，而 agentic coder的核心技能是做出假設，減少和規劃未知，這項技能是通過與 Claude合作完成的。
幫 Claude 幫你
他指出指揮 Claude 是個微妙的平衡：
指令太具體太長太多，Claude會照單全收機械性地執行，太模糊吧，Claude 會按行業慣例做出可能不合你意的假設。
所以問題的癥結就在於處理好未知。
他認為 Claude 能幫你更快發現未知，它搜索代碼庫和互聯網的速度極快，對大多數話題的瞭解也比普通人多，即便失敗，重新迭代的速度也更快。
這個過程裏最重要的是給 Claude 交代清楚你的出發點：
告訴它你思考到了哪一步、你對這個問題和代碼庫的經驗如何，讓它像一個真正的思考者一樣和你配合。
他提到自己之前寫過關於用 HTML 和 Claude 協作的內容，認為 HTML artifact 就可以作為這類可視化和呈現這類內容最好的方式。
實施前階段
1. 盲區掃描
在陌生領域工作時，比如新代碼模塊或不熟悉的設計任務，未知的未知會特別多。
這時可以直接讓 Claude 幫你找出這些未知未知並解釋給你聽，他強調給 Claude 交代清楚你是誰、你懂什麼很關鍵。
他舉了兩個例子：
一個是加新的認證方式但完全不瞭解認證模塊，另一個是完全不懂調色但需要給視頻調色。
2. 頭腦風暴和原型
在涉及大量"未知已知"，就是那種見了才知道對不對的標準的領域，他喜歡讓 Claude 一起頭腦風暴和做原型。
他認為在原型階段儘早把這些標準說出來非常划算，因為等到實現階段才發現代價會高得多，一個小的功能或需求變化，可能導致代碼實現天差地別，agent 撤銷之前的改動也會更難。
舉例來說，你可能只是想看看一個按鈕加到界面上是什麼效果，不需要真的接後端路由或維護額外的前端狀態。
視覺設計對他來說很難用語言描述，但看到了就知道要不要，所以他會讓 Claude 給出多種設計方向。
幾乎每次寫代碼前都會先做探索或頭腦風暴階段，這有助於一開始就明確項目範圍，Claude 常常能找到他會漏掉的高價值思路。
3.訪談
做完頭腦風暴之後如果還有未知，他會讓 Claude 就任何模糊之處對他進行訪談，並強調要給 Claude 交代問題背景來引導它提問的方向。
比如讓 Claude 一次問一個問題，優先問那些答案會改變架構的問題。
4. 參考
有時候你沒法詳細描述想要什麼，可能是缺乏合適的語言，或者太複雜講清楚要花很久。
這種情況下最好的答案是給一個參考。可以用圖表、文檔或圖片，但最好的參考是源代碼。
如果有個庫用某種方式實現了你想要的東西，或者你很喜歡某個設計組件，直接把 Fable 指向那個文件夾，告訴它要看什麼，哪怕語言不同也沒關係。
Claude Design 也是這個思路。
不一定要給文件，可以直接指向一個網站上的某個模塊，它會讀底層代碼而不只是截圖，這樣能得到關於標記、結構和組件實際構建方式的更豐富細節。
5. 實現計劃
準備開始實現前，他會讓 Claude 整理一份實現計劃供他審閲，重點放在最可能變化的部分，比如數據模型、類型接口或用戶體驗流程，這樣 Claude 能把他可能真正需要調整的地方展示出來。
比如用 HTML 寫實現計劃，但先講他最可能想調整的決定，數據模型變化、新的類型接口、以及任何用戶可見的部分，把機械性的重構內容放到最後，因為那部分他信任 Claude 能處理好。
6. 實施階段
對計劃滿意後，他會開一個新會話，把相關 artifact 傳進去，比如一份 spec 文件加一個原型，讓 agent 據此實現。
但無論計劃做得多充分，agent 可能在工作中發現需要因為代碼裏的邊緣情況而採取不同做法。
讓 Claude Code 維護一份臨時的 implementation-notes.md文件，記錄它做出的決定，方便下次學習。
如果遇到迫使偏離計劃的邊緣情況，選保守方案，把它記在對應條目下，然後繼續。
7.實現之後：
交付工作裏最重要的一環是拿到認可和批准。製作 pitch 和講解類的最終文檔有助於。
讓評審者從和你一樣的起點開始理解，加快理解速度，讓專家看到你已經考慮到了他們會預料到的未知和常見失敗點，從而加快批准速度。
把原型、spec 和實現筆記打包成一份文檔，可以直接丟進 Slack 去爭取認可，開頭放演示 GIF。
8. 測驗
經過一段長時間的工作會話，Claude 完成的工作量可能比意識到的要多得多。
只看代碼 diff 只能對發生了什麼有個模糊瞭解，因為很多行為取決於已有的代碼路徑。
他會讓 Claude 在給他足夠背景信息之後對這次改動進行測驗，只有完全通過測驗才會合併代碼。
可以給出一份 HTML 報告，附帶背景信息、直覺判斷、做了什麼等內容，末尾附一個關於這次改動必須通過的測驗。
Fable 發佈案例
他提到 Fable 的發佈視頻完全是由 Claude Code 剪輯的，這對他來說是個全新領域。
他從自己已知的部分入手，知道 Claude 能用代碼剪輯和轉錄視頻，但不確定精度夠不夠。
於是它讓 Claude 解釋像 Whisper 這樣的轉錄原理，以及能否用 ffmpeg 精確剪掉"嗯啊"之類的語氣詞和長停頓。
之後想要一個跟隨他說話時間軸變化的 UI，但不確定能不能做到，於是讓 Claude 用 Remotion 和轉錄文本做了個原型視頻先驗證可行性。
最後，視頻整體看起來有點發悶，知道這是調色的問題，但不太懂調色是什麼。
第一次嘗試是讓 Claude 做幾種調色方案供他挑選，但意識到自己根本不知道"好"的調色標準是什麼樣，於是轉而讓 Claude 教他調色知識，來發現自己的未知，他提到有一個更詳細的視頻講解了這部分內容。
最後的總結
當一個長週期任務的結果不對時，往往說明你需要花更多時間定義自己的未知，或者做一份能讓 Claude 在遇到未知時也能即興發揮的實現計劃。
每一次講解、頭腦風暴、訪談、原型和參考，都是一種便宜的方式，能在代價變得高昂之前，提前發現你原本不知道的事情，所以他也建議，下一個項目開始前，先讓 Claude 幫你找出自己的未知。
所以通篇看下來你會發現他講的就是如何去發現自己的未知領域，並協同 Claude Code去挖掘這個未知知道自己知道和比知道自己不知道更難。