本篇內容由倉鼠特報員 AI 協助產出。
倉鼠碎碎念：
這篇很適合留給正在用 Claude Code 或各種 coding agent 的人反覆看。它沒有把問題簡化成「prompt 寫清楚就好」，而是把人和模型之間真正卡住的地方講出來：你自己也還沒命名的未知，會在實作過程中變成模型的猜測。倉鼠讀完最喜歡的是它把 blind spot pass、訪談、原型、實作筆記和事後測驗串成一條工作流，這不是炫技，而是在把模糊感變成可討論、可修正、可交接的材料。模型越強，人的責任反而越像是把地圖畫到足夠接近領土。
元魁：
這篇蠻值得看看的，用 AI 寫程式一定都需要瞭解的，不然寫到後面會迷失在不知道 AI 在做什麼的迷途。
這個作者的 Artifact 真的很棒，推薦大家讓自己的 AI 研究一下，未來需要畫面討論時不再只有繁瑣的 md 檔案，而是更加視覺化的呈現方式。
解讀來源，翻譯自：
https://x.com/trq212/status/2073100352921215386
================= 廣告時間 ================
在進入這週的主題之前，想先跟你分享一個最近讓我覺得「原來如此」的東西。
我認識 VK 好幾年了。她是《VK 科技閱讀時間》Podcast 主持人，每週要消化大量科技資訊做節目，至今累積了超過 350 篇研究、跟 AI 來回協作超過 60 萬字，也曾受邀到 Google I/O 跟 NotebookLM 團隊交流。我一直知道她產量高、寫得快，每週都能穩定交出東西，但她到底怎麼做到的，我以前一直沒真的搞懂。
直到她把整套流程拆開給我看，我才知道那個「穩定」是怎麼來的。
她的方法不是偶然跑出來的，是在真實的大量產出壓力下，一步一步磨出來的。我本來以為她教的是寫作者的事，跟我沒太大關係。但我讀完整個體驗包才發現不是。她給了三套工作流，分別對應內容創作、產業研究、學術研究。只要你的工作需要「快速把陌生資料變成可以用的判斷」，這套流程就對你有用。
真正的卡點在哪裡
行銷在做市場調查是這樣，PM 要整理競品策略是這樣，業務見新客戶前要惡補產業知識也是這樣。卡的不是「做不到」，是「把一堆陌生資料讀懂、整理出全貌」這一段太耗，耗到很多人還沒開始就先放棄了。這才是真正的卡點。
VK 的流程是這樣走的：先用 NotebookLM 的 Deep Research 掃大量來源建資料庫，再手動補它抓不到的（官方檔案、法說會簡報、Podcast 逐字稿）。然後做一張術語表，她說掌握 20% 的關鍵字，就能讀懂 80% 的內容。接著做「全景總覽」，先把地圖看完，刻意不急著問問題。這一步是在對抗一個很常見的陷阱：你一開口就只能問到你以為你知道的答案，確認偏誤就這樣長出來了。
最打動我的是兩個設計。第一個是「驗證提示詞」：你用自己的話把重點整理一遍，再把答案貼回去讓 AI 檢查，它會直接告訴你哪裡其實沒搞懂、哪裡把猜測當成事實。「看過」跟「真的懂了」之間有一條縫，這招是去踩那條縫的。第二個是反幻覺設計：她的提示詞要求 AI 每個論點都附上原文摘句，資料不足的地方標「來源未涵蓋」，不准憑空填答。
這不是把工作外包給 AI。你的判斷、觀點、取捨，還是你自己來。AI 把最耗時的前置整理好，讓你把腦力留給真正該你出手的地方。「能用 30 秒講給朋友聽」是她驗收「你真的理解了」的標準，我覺得這條線設得很對。
先試試這段提示詞
我讀完之後，第一件事是把這套「先把資料整理成全貌、再回頭驗證自己到底懂沒懂」的思路，整理進我自己的工作流裡。底下這段是入門版。先在 NotebookLM 用 Deep Research 匯入資料、勾選你要參考的來源，再把這段貼進去跑（工具免費，手機也能跑）：
請只根據我匯入的來源整理，不要用你自己的背景知識補充，全部用條列、每點簡短好讀：
先給我 3 到 5 句的整體判斷，讓我一眼抓到這批資料的重點。接著再分四塊：
一、發展脈絡：這個主題怎麼一路走到現在，有哪些關鍵節點。
二、主要立場或做法：有哪幾種，各自的核心論點是什麼。
三、還沒定論的爭點：哪些地方目前還沒有共識。
四、下一步該補什麼：列出我最該再找的 2 到 3 類資料，並說明少了它們，我的判斷會有什麼盲點。
三個規則：
1. 每一點都用括號標出來自哪一份來源，如果來源裡有原句，附一句短摘錄。
2. 資料不足以回答的，直接寫「來源未涵蓋」，不要自己編。
3. 不要寫「很重要」「值得關注」這種空話，只給具體內容。
試完之後，你會感覺到「有結構地問」跟「隨便問」差在哪裡。
VK 的完整課程
這段提示詞只是入門。VK 課程的完整版本，是針對寫作、產業研究、學術研究不同情境，一步扣一步的連續流程，告訴你什麼時候建資料庫、什麼時候回頭驗證理解、什麼時候把資料收斂成判斷。兩者的定位本來就不同。
如果你只是想叫 AI 直接幫你生一篇出來，這堂課可能不是你要的。但如果你的工作就是要讀大量資料、整理出自己的判斷，這套會很有感。你卡住的可能不是能力，而是還沒有一套把混亂陌生資料變成清晰全貌的方法。這堂課在解決的，就是這件事。
課程還在集資期，想試的話這陣子入手會比較好。VK 另外還有產業研究、學術研究兩套，這次集資三堂合購會更划算。
折扣碼 CIRCLEGHOST 是給知識倉鼠讀者的專屬福利，結帳折 $80，連結在這：https://pse.is/98dseq
好，這個先分享到這。我們回到這週的正題。
=============== 廣告時間結束 ==============
正文開始
使用 Claude Fable 5 工作，總是不斷讓我重新學到一個老道理：地圖不等於領土。
地圖是待完成工作的表徵，也就是我的 prompts、技能和上下文，是我交給 Claude 的東西。領土則是工作實際發生的地方，也就是程式碼庫、真實世界，以及其中真正的限制。
地圖與領土之間的落差，就是我所說的未知。當 Claude 遇到未知時，它必須根據對我需求的最佳猜測做出決定。要做的工作越多，Claude 可能碰到的未知就越多。
Fable 是第一個讓我感覺工作品質受限於我釐清未知能力的模型。
重要的是，單純事先規劃並不總是足夠。你可能會在實作深處發現未知，或者你的未知可能會指出，其實你應該用完全不同的方式解決問題。
我發現，與 Fable 合作是一個在實作前、實作中、實作後不斷發現未知的迭代過程。
我做了一些用來找出未知的範例 artifacts 在這裡，但記得回來建立判斷何時使用它們的直覺。
瞭解你的未知
你的未知是什麼？當我帶著一個問題來找 Claude 時，我通常會用 4 種方式拆解：
已知的已知：這基本上就是我 prompt 裡的內容。我告訴 Agent 我想要什麼？
已知的未知：有哪些事我還沒弄清楚，但我知道自己還沒弄清楚？
未知的已知：有哪些事明顯到我根本不會寫下來，但只要看到就能認出來？
未知的未知：有哪些事我完全沒考慮過？有哪些知識是我不知道自己不知道的？我知道一件事可以好到什麼程度嗎？
最優秀的 agentic coder 通常相對沒有太多未知。看像 Boris 或 Jarred 下 prompt，我很明顯能看出他們非常細緻地知道自己想要什麼。他們和程式碼庫以及模型行為都高度同步。
但他們也會預設未知的存在。在很多層面上，減少並為你的未知做規劃，就是 agentic coding 的技能。幸運的是，這是一項可以透過與 Claude 合作來提升的技能。
幫 Claude 幫助你
指示 Claude 是一種微妙的平衡。如果你太具體，Claude 即使在轉向更合適時也會照著你的指示走。如果你太模糊，Claude 通常會依照業界最佳實務做出選擇和假設，而那些做法不一定適合你的任務。
當你沒有把未知納入考量時，兩邊都會失敗。你不知道路上什麼時候會充滿障礙，也不知道什麼時候路會很順，但你仍然希望 Claude 能在需要時轉向。
Claude 可以幫你更快發現未知。它能非常快速地搜尋你的程式碼庫和網際網路，而且對一般主題的瞭解遠比你多。它也能更快地從失敗中迭代。
這個過程最重要的一環，是讓 Claude 瞭解你的起點。例如，告訴它你目前思考到哪裡，揭露你對這個問題和程式碼庫的經驗，讓它像思考夥伴一樣和你合作。
我之前寫過關於搭配 Claude 使用 HTML 的文章，在幾乎所有這些情境中，HTML artifact 都是視覺化和呈現它的最佳方式。
在這篇文章中，我會詳細說明一些我用來揭露這些未知的模式。我不會每次都用上每個技巧，但這是一組很有用、值得備著的技巧。
實作前
盲點檢查
開始工作時，最有用的事情之一，就是瞭解自己的盲點。例如，如果你正在程式碼庫的新區域撰寫功能，或是使用 Claude 協助你處理不熟悉的工作，像是反覆調整設計，你很可能會有很多未知的未知。
你可能不知道該問什麼問題、不知道好的成果長什麼樣子、不知道過去做過哪些工作，也不知道該避開哪些坑。
要做到這點，你可以請 Claude 幫你找出未知的未知，並向你解釋。我喜歡直接使用「blindspot pass」和「unknown unknowns」這些字眼。通常，提供它關於你是誰、你知道什麼的上下文很重要。
範例 prompts：
我正在加入一個新的 auth provider，但我完全不瞭解這個程式碼庫裡的 auth 模組。你可以幫我做一次 blindspot pass，找出和我相關的未知的未知，並幫我把 prompt 寫得更好嗎？
我不知道 color grading 是什麼，但我需要替這支影片做 color grading。你可以教我理解自己在 color grading 上的未知的未知，讓我能寫出更好的 prompt 嗎？
腦力激盪和原型
當我在一個有很多未知的已知的領域工作時，標準往往是我只有看到才知道怎麼定義。這種時候，我喜歡請 Claude 和我一起腦力激盪並製作原型。
在原型階段早期識別並說出未知的已知非常有價值，因為等到實作時才發現，成本可能會相對高。功能或規格的一點小變動，就可能造成程式碼中截然不同的實作，而且你的 Agent 要回復先前變更也可能更困難。
例如，你可能只是想看看在一個 frame 上加一顆按鈕看起來如何，而不想接上後端路由，也不想在前端維護額外狀態。
視覺設計對我來說很難用言語清楚表達，但我看到時就知道自己想要什麼。在這些情況下，我會請它為一個 artifact 提出幾種設計方向。
我也幾乎會在每次 coding session 開始時，先進行探索或腦力激盪階段。這幫助我帶著明確意圖開始定義工作範圍。Claude 常常會找出我原本會錯過的高價值做法，有時也會見樹不見林。腦力激盪能避免我把範圍設得太窄或太寬。
範例 prompts：
我想替這些資料做一個 dashboard，但我沒有視覺品味，也不知道有哪些可能。幫我做一個 HTML 頁面，放 4 個差異很大的設計方向，讓我可以對它們做出反應。
在接線之前，先用假資料做一個單一 HTML 檔，模擬新的編輯器工具列。我想先對版面有感覺，再讓你碰真正的 app。
這是我粗略的問題：使用者在 onboarding 後流失。請搜尋程式碼庫，腦力激盪 10 個我們可以介入的地方，從成本最低到最有野心的做法排序。我會告訴你哪些有感。
訪談
完成足夠的腦力激盪後，我很可能仍然還有未知。
在這種情況下，我會請 Claude 就任何未知或模糊之處訪問我。請 Claude 訪問你時，試著提供關於問題的上下文，好引導它提出問題。以下是一些例子。
範例 prompts：
針對任何模糊的地方，一次問我一個問題。優先問那些我的回答會改變架構的問題。
參考資料
有時你無法詳細描述自己想要什麼。例如，你可能沒有足夠的語言來表達，或者它太複雜，會花你相當多時間。
在這種情況下，最好的答案就是參考資料。雖然你可以包含圖表、材料或圖片，但最好的參考資料絕對是原始碼。
如果你有某個函式庫以特定方式實作了某件事，或有一個你非常喜歡的設計元件，就直接把 Fable 指向那個資料夾，並告訴它要看什麼，即使那是用不同語言寫的也沒關係。
這也是 Claude Design 的運作方式。你不一定要交給它一份材料，雖然你也可以這麼做。你可以把它指向你喜歡的網站上的某個模組，它會讀底層程式碼，而不只是看螢幕截圖。這能提供關於 markup、結構，以及該元件實際如何建構的更豐富細節。
範例 prompts：
vendor/rate-limiter 裡這個 Rust crate 實作了我想要的完整 backoff 行為。讀它，然後在我們的 TypeScript API client 裡重做相同語意。
實作計畫
當我覺得準備好實作時，通常會請 Claude 整理一份實作計畫讓我審閱，重點放在最可能變動的部分，例如資料模型、型別介面或 UX 流程。這能讓 Claude 浮現我可能真的需要調整的事項。
範例 prompts：
用 HTML 寫一份實作計畫，但開頭先放我最可能會調整的決策：資料模型變更、新的型別介面，以及任何使用者會看到的東西。機械式重構放到底部就好，那部分我信任你。
實作期間
實作筆記
當我對計畫感到滿意後，我會開一個新的 session，並把任何 artifacts 傳進 prompt。例如，我可能會傳入一份規格檔和一個原型，然後請 Agent 實作它。
但事實是，不管你做了多少規劃，永遠都會有未知的未知潛伏著。Agent 可能會在工作過程中發現，因為程式碼裡某個 edge case，它需要採取不同做法。
我會請 Claude Code 維護一份暫時的 ‘implementation-notes.md’（或 .html 版本），用來記錄它做出的決策，讓我們能從下一次嘗試中學習。
範例 prompts：
維護一份 implementation-notes.md 筆記。如果你碰到迫使你偏離計畫的 edge case，選保守做法，把它記在『Deviations』底下，然後繼續前進。
實作後
提案和解說
交付某個東西時，最重要的環節之一，就是取得認同和核準。在最終說明中建立提案和解說 artifacts 會有幫助：
當審閱者一開始也有和你相同的未知時，加速他們理解
當專家想確認你已經考量他們預期中的未知和常見失敗點時，加速核准
範例 prompts：
把原型、規格和實作筆記整理成一份說明，讓我可以丟到 Slack 裡取得認同。開頭先放 demo GIF。
測驗
經過一段很長的工作 session 後，Claude 可能完成了比我意識到更多的事。閱讀程式碼 diff 只能讓我粗略理解發生了什麼，因為許多行為都取決於既有的程式碼路徑。
請 Claude 在給我一大段上下文後，就這次變更對我出測驗，能幫助我理解實際發生了什麼。只有在我完美通過測驗後，我才會 merge。
範例 prompts：
我想確認自己理解這次變更中發生的一切。給我一份 HTML 報告，說明這次變更，讓我能帶著上下文、直覺、實際做了什麼等等去閱讀和理解，並在底部放一份我必須通過的變更測驗。
這一切如何串起來：發表 Fable
Fable 的發表影片 完全由 Claude Code 剪輯。這對我來說是一個新領域，而我絕對稱不上專家。
所以我從自己確定知道的事開始。我知道 Claude 可以用程式碼剪輯影片並轉錄內容，但我不確定它是否夠準確。接著我請 Claude 向我解釋 Whisper 這類轉錄工具如何運作，以及我是否能用 ffmpeg 準確剪掉像是嗯、啊之類的語助詞或長停頓。
我希望 Claude 建立一個會隨著我說出的字同步顯示的 UI，但不確定它是否做得到，所以我請 Claude 使用 Remotion 和一份轉錄稿建立原型影片，看看能不能行。
最後，影片本身看起來有點灰暗，我知道那是 color grading 的結果，但我其實不太知道 color grading 是什麼。我的第一次嘗試是讓 Claude 做出幾個版本供我挑選，但我發現，在 color grading 這件事上，我不知道「好」看起來是什麼樣子。所以改成請 Claude 教我 color grading，來發現我的未知。
你可以在這裡觀看更深入的說明。
讓地圖與領土對齊
模型越好，只要方法正確，你能完成的事就越多。當一個長程任務回來的結果不對時，很可能是你需要花更多時間定義你的未知，或建立一份允許 Claude 在未知中即興調整的實作計畫。
每一份解說、腦力激盪、訪談、原型和參考資料，都是在修正變得昂貴之前，低成本找出你原本不知道之事的方法。
所以，下一次工作開始時，就先請 Claude 幫你找出你的未知。