為什麼最強的模型會叫你「走路去洗車」，而真正會用 AI 的人都在做同一件事。
我前陣子丟了一個問題給 Claude、Gemini、Grok 和 ChatGPT：「我要去洗車，洗車場在 50 公尺外，我應該走路還是開車過去？」
四個模型，異口同聲叫我走路。理由還講得頭頭是道：「50 公尺很近，走路比較環保、省油、又能運動。」
乾，車子要洗欸，人走過去是要用舌頭舔嗎？
這個例子是 Andrej Karpathy（前 Tesla AI 負責人、OpenAI 創始成員）在 2026 年的演講裡拿出來打臉所有人用的。我本來不信，自己試了一輪——它們全錯。有人後來拿這題去測 53 個主流模型，結果只有 5 個能穩定答對，33 個從頭錯到尾（Opper 的 Car Wash Test）。
同一個 Claude，可以幫你重構一份十萬行的程式碼庫——資深工程師要做好幾週的工作——卻在「洗車要不要開車」這種國小生都會的常識上翻車。這不是 bug，這是整支影片的地基。搞懂它，你才會明白為什麼你一直在用錯誤的方式 prompt AI。
為什麼 AI 是天才又是白痴：可驗證性
Karpathy 在 Sequoia 的年度 AI 活動上給了我看過最乾淨的解釋，他稱之為「可驗證性論題」（Verifiability Thesis）：
傳統電腦自動化的是「你能用程式碼明確指定的東西」；LLM 自動化的是「你能驗證的東西」。
程式碼有單元測試、有編譯器、有明確的對錯，所以 AI 在這個領域是超人。但「洗車要不要開車」沒有 verifier——沒有任何一個單元測試在檢查「關於洗車的交通常識」。對能被衡量的東西，AI 是天才；對需要脈絡、無法被衡量的東西，它沒有任何訊號可以依靠，於是自信滿滿地胡說（MindStudio 對 Verifiability Thesis 的整理）。
那問題來了：你腦袋裡的脈絡跟理解，怎麼餵給只懂計算的 AI？Karpathy 的答案可以拆成三層：
你的理解（目標・脈絡・品味） → Layer 1 Spec 規格 → Layer 2 Verifier 驗證者 → Layer 3 Environment 環境 → 10x 的產出 →（持續回饋）→ 你的理解
把它想成一個工作坊：規格是釘在牆上的藍圖，驗證者是門邊的品檢站，環境就是工作坊本身。大多數人每次用 AI 都從一個空蕩蕩的工作坊重新開始——這就是問題所在。
Layer 1：Spec（規格）——別再丟一句話就要它蓋房子
很多人聽過 Claude 的 plan mode，覺得「先讓它做個計畫再動工」就很厲害了。但 Karpathy 直接說他不喜歡 plan mode：
我其實不太喜歡 plan mode……當然它很有用，但我覺得這裡有更通用的東西：你應該跟你的 agent 一起設計一份非常詳細的 spec。
注意他不是說 plan mode 爛，而是說那層級太高、太淺。真正該做的是跟 AI 一起把規格挖到底。怎麼挖？三個動作。
一、先逼出「目標」，不是「任務」
如果你說「幫我做一份月底報告」，那是任務。但真正的目標是「這份報告要導出什麼結論、要驅動什麼決策」——而這件事 AI 永遠無法替你決定。最有效的招數反過來：讓 AI 來訪談你。
在開始之前，請先訪談我，以釐清這個專案真正的目標。
一次問我一個問題，根據我的回答再追問，直到你能用一段話
總結出「成功長什麼樣子」為止。二、敏捷地切，不要瀑布式地塞
完成任何任務有兩種方式：瀑布式（一次做完整包，最後才給你看成品）跟敏捷式（切成小塊，過程中一直給你看、隨時校正方向）。人類用 AI agent 時超容易掉進瀑布式陷阱——因為很爽，一次把所有事丟給它。但這正是產出歪掉的主因。正確做法是敏捷規格：範圍收緊、檢查點清楚、看產出、調整、重複。
請傾向把工作拆成更小、更模組化的 spec。
每個 spec 完成一個可獨立檢查的小塊，做完就停下來讓我 review，
不要一口氣把整個功能做完。三、精確，然後動你的腦
你愈精確，AI 要去「假設」的東西就愈少；而每一個假設，都是它偏離你真正想要的東西的機會。當 AI 幫你生出一份 spec，你必須動腦去批判性地讀它到底寫了什麼，而不是看都不看就按下去。
在關鍵決策點，請明確讓我逐一確認，確保沒有任何遺漏被你默默帶過。把這三招合起來，你會得到一份範圍收緊、想清楚、而且真正對齊你目標的規格。Karpathy 把這整套叫做「現代工程」（modern engineering）——他認為每個想在 AI 時代成功的人都得變成這種人。
Layer 2：Verifier（驗證者）——你唯一真正握得住的把手
用 AI 最煩的事情之一，就是 review 跟驗證它的產出。要解這題，得先搞懂一個心智模型，Karpathy 用「動物 vs 鬼魂」（animals vs ghosts）來講。
我們不是在打造動物，我們是在召喚鬼魂。
聽起來很玄，我幫你翻譯。我們習慣跟「人」互動——Karpathy 把人叫做動物——動物有內在動機跟情緒。你跟一個人說「14 天內變成 SEO 專家，不然你就被開除」，他真的會想辦法生出來，因為他有內在驅力。
但 AI 不是。Karpathy 說它是鬼魂——「人類文件的統計蒸餾物，上面再灑一點調味」，他甚至打了個比方：鬼魂之於動物，就像飛機之於鳥——是根本不同的智慧形態，不是同一條路上的兩個階段。
我覺得「鬼魂」還是太抽象，換個更好懂的：把它想成一個機器人圖書館員。你問它 SEO，它只能根據館內藏書給你答案；沒那本書，它幫不了你。更麻煩的是，它不知道自己缺哪本書，所以常常一臉自信地當場編一個給你。這就是 AI 數學神準、脈絡卻翻車的真相。
關鍵結論來了：既然它是鬼魂不是動物，那你用對待人的方式對它就完全沒用——對它吼、拜託它、丟一句「做得更好一點」，統統沒效。你唯一真正握得住、而且大部分人根本沒想到要用的把手，就是驗證。三個著力點：
一、事前就把評分標準講死
在 Claude 動手之前，先用「精確」定義出「好」長什麼樣子。模糊版：「把這份報告弄得好看一點。」精確版：「報告必須有三個區塊，每個區塊結尾都要有一條具體建議。」有沒有發現？這跟 Layer 1 的精神一模一樣——你事前愈精確，Claude 之後能犯錯的空間就愈小。
請先列出你將用來確保最終產出品質的評分標準。要精確。
然後依照這份標準自評，不通過就重做。二、用第二個 AI 當 critic
想像第二個來自不同圖書館的機器人館員——它有一整套不同的藏書，可能因此看出第一個館員哪裡對、哪裡錯。實作上，如果你用 Claude Code，可以裝 Codex 外掛，直接在 session 裡問 Codex：
如果這變成一個複雜的 build，最後請把產出丟給 Codex 跑一遍，
確認兩邊系統的判斷一致，不一致的地方列出來給我。三、盡可能拉進外部訊號
- 技術場景：你不確定 app 有沒有部署成功？把 Claude session 接上你的部署系統，讓它直接去查。它說成功，那就是真的成功。
- 非技術場景：在做月報？把歷史報告丟進去當參考，讓最終格式直接對齊過去的版本。
這就是把外部資料拉進來，強化你的驗證層。Claude Code 的作者 Boris Cherny 把這件事的重要性講得最白：
要從 Claude Code 拿到好結果，最重要的一件事，就是給 Claude 一個能驗證自己工作的方式。只要 Claude 有這個回饋迴路，最終結果的品質會提升到 2～3 倍。
這句話出自他在 X 上的貼文（原文為英文，此處為意譯）。整理他工作流的文章也提到，這個回饋迴路被視為團隊最大的生產力解鎖之一——claude.ai/code 的每一次改動，Claude 都會開瀏覽器自己測過 UI 才算數（How Boris Uses Claude Code）。我自己的體感完全一致：有沒有讓 AI 能自己跑測試、自己看結果，產出品質根本是兩個世界。
Layer 3：Environment（環境）——別每次都從空白工作坊重來
Spec 跟 Verifier 需要一個地方住，那就是 Layer 3：你建構的環境。重點是——大多數人每次用 AI 都重開一個空工作坊。注意，「一個 chat 開著完整對話紀錄」不算。怎麼蓋一個會隨時間變強的工作坊？四步。
一、寫好你的 CLAUDE.md
每次你 prompt Claude，CLAUDE.md 都會被自動注入——它幾乎是 Claude 開工前讀的第一份文件，決定它該怎麼運作。比方說你可以加一條：
# 工作規則
- 在動手任何多步驟的任務之前，先附上一份驗證計畫（怎麼確認做對了）。這樣一來，驗證就被強制寫進每一次 build，而不是你每次都要記得去講。一句話：這是你的世界，AI 住在裡面，不該反過來。
二、建你自己的 LLM 知識庫
這是 Karpathy 2026 年 4 月在 X 上爆紅的概念——他稱之為 LLM Knowledge Base。本質上就是在你機器上開一個資料夾系統，把你自己的「訓練資料」用一種讓 Claude 容易理解、容易定位的方式餵進去。常見做法是開一個資料夾，底下兩個子資料夾：raw/（你的原始素材：論文、repo、文章、會議記錄、截圖）跟 wiki/（讓 LLM 自己整理、自己維護的互連 Markdown 筆記）（Medium 的整理）。為什麼這麼重要？因為你的資料就是你的護城河。
三、開始累積你的 skill
我自己的判斷準則：任何你打算重複做的事，就替它做一個 skill。 把它想成完成特定任務的一本手冊。而且用得愈多，它會愈好——我常講一句話：「找出水管漏洞最好的方法，就是讓水流過去。」skill 也一樣，跑得愈多，你愈知道哪裡要修、哪裡很猛。持續讓水流過去，你的系統就會隨時間複利成長。
四、立下「能做 / 不能做」的規則
依「做錯的代價」設不同等級的護欄。這裡有個關鍵差異——guide（指引）不等於 rule（規則）。你可以在 CLAUDE.md 寫「不要碰某個資料夾」，這能幫你達成 80%……但它本質上是個請求，Claude 還是碰得到。真正關鍵、絕對不能錯的事，要用規則級的護欄：加一個 pre-tool-use hook，在 Claude 使用 write 或 edit 工具之前，先檢查它要改的檔案——在保護資料夾內就在工具層級擋下，其他放行。這才是 agent 繞不過去的硬規則。把事情分成三桶：
| 分類 | 意義 | 實作層級 |
|---|---|---|
| Always do（永遠做） | AI 可以自動駕駛的事 | 自動執行 |
| Ask first（先問） | 你想再確認一下的事 | prompt／互動確認 |
| Never do（絕不做） | 跨過去就完蛋的紅線 | hook 等規則級護欄 |
三層怎麼疊起來用：一張對照表
| 層 | 核心問題 | 招數 | 一句話心法 |
|---|---|---|---|
| Spec 規格 | AI 不知道你「真正」要什麼 | 讓 AI 訪談你、敏捷切小塊、關鍵點要你確認 | 把理解灌進規格 |
| Verifier 驗證者 | AI 是鬼魂，不會自己知道對錯 | 事前定評分標準、第二模型當 critic、拉外部訊號 | 唯一握得住的把手是驗證 |
| Environment 環境 | 每次都從零開始、規則無法強制 | CLAUDE.md、LLM 知識庫、skill、hook 護欄 | 這是你的世界，AI 住裡面 |
踩坑提醒：新手最容易做錯的兩件事
坑一：把 spec 當成一次性的長 prompt 塞爆。 很多人聽到「要詳細的 spec」就寫一篇兩千字的需求一次丟進去，然後等一個完美成品——這就是瀑布式。結果 AI 在第三段就開始假設、到第十段已經飄到外太空。解法：spec 再詳細也要敏捷地切，做一塊、檢查一塊。
坑二：用 guide 假裝成 rule，然後怪 AI 不聽話。「我明明在 CLAUDE.md 寫了不要動那個資料夾，它還是改了！」——因為那只是請求，不是規則。解法：代價高的事一律上 hook，在工具層級擋下。別在 prompt 裡拜託一個鬼魂自律。
最後，那唯一一件事
走完整套方法，還有個問題沒回答：在智慧變得便宜的 AI 時代，Karpathy 認為我們唯一該專注學的是什麼？他用一句話回應，而這句他其實是引用別人的、最近一直掛在嘴邊的話，我覺得是整篇最重的一句：
你可以外包你的思考，但你無法外包你的理解。（You can outsource your thinking, but you can't outsource your understanding.）
這句話他最近反覆引用（Karpathy 本人說「這是我最近一直在引用的話」），也被不少人拿來談 AI 時代的「理解瓶頸」（Understanding Bottleneck）。回頭看，整套三層架構——spec、verifier、environment——全都繞著你對大局的理解在轉。你得懂你的目標、懂什麼叫做對，才有辦法指揮 AI 替你工作。
所以下次你又想丟一句「幫我做個 X」然後祈禱的時候，停一下。先問自己：我的目標到底是什麼？我要怎麼驗證它做對了？我有沒有一個會愈長愈強的環境？把這三件事想清楚，你不是在 prompt 一個鬼魂——你是在當一個現代工程師。
參考資料
- Animals vs Ghosts — Andrej Karpathy：鬼魂 vs 動物心智模型的原文
- Car Wash Test on 53 leading AI models — Opper：53 個模型的洗車題實測
- Karpathy's Verifiability Thesis — MindStudio：可驗證性論題整理
- Boris Cherny 談 feedback loop（X）：「2～3 倍品質」的原始貼文
- How the Creator of Claude Code Uses Claude Code：Boris 工作流詳解
- Karpathy 的 LLM Knowledge Base 原貼（X）：知識庫概念來源
- Andrej Karpathy's LLM Wiki — Medium：知識庫實作教學
- The Understanding Bottleneck — Sébastien Dubois：「外包思考但不外包理解」的延伸思考（第三方文章，非 Karpathy 本人所寫）
沒有留言:
張貼留言