TL;DR
AI 助手老是搞錯你的意思？問題可能不在 AI，而在你沒給它一份好的「行為守則」。Karpathy 在 30 個程式庫實測 6 週，證明只要在 CLAUDE.md 寫對 12 條規則，錯誤率能從 41% 壓到 3%。本文帶你拆解這套方法，不會寫程式也能學會。
你的 AI 不是笨，是沒憲法
很多人第一次用 AI 編程助手的體驗都差不多：請它改一行程式碼，結果它把整個檔案重寫；請它修一個小問題，它順手「幫你」改了十幾個不相干的地方。你氣得在對話框裡打出一堆大寫字母，但下次它照樣犯。
問題出在哪？想像一下，你新請了一位實習生。你沒告訴他公司的 coding style、專案慣例、哪些檔案絕對不能碰。他不是不認真，而是根本不知道規矩。CLAUDE.md 就是你寫給 AI 助手的那份「公司守則」，更精確地說，它是 AI 行為的憲法。
Karpathy（前 Tesla AI 總監）最早提出了 4 條基本規則，光是這樣就把錯誤率從 41% 砍到 11%。後來有開發者在 30 個不同的 codebase 上花了 6 週反覆驗證，再追加 8 條規則，錯誤率進一步壓到 3%。從快一半出錯，到幾乎零失誤，差別就在那份 CLAUDE.md。
12 條規則拆解：從「態度」到「機制」
前 4 條是 Karpathy 的原始配方，定義 AI 的工作態度：
- 思考先行：動手之前先分析問題，不要急著吐程式碼。
- 簡潔優先：能改一行就不要改十行。
- 外科手術式修改：只碰該碰的地方，其餘一律不動。
- 目標驅動：每次修改都要對應一個明確的目的，不做「順便改一下」的事。
這 4 條聽起來像常識，但 AI 的預設行為恰好相反。它被訓練成「盡可能多做事來展現能力」，所以你必須明確告訴它：少即是多。
後 8 條是實戰中長出來的機制設計，解決更深層的問題：
- 模型只做判斷，不做確定性邏輯：數學計算、精確比對這類工作，交給程式碼處理，別讓 AI 用「猜」的。
- Token 預算硬上限：限制 AI 單次回應的長度，避免它自嗨寫出一篇論文。
- 衝突不取平均：當兩條規則打架時，選一邊站，不要和稀泥。
- 寫前先讀：修改任何檔案之前，必須先讀完現有內容。
- 測試驗證意圖：改完之後跑測試，確認結果符合原本的設計目的。
- 多步驟需檢查點：複雜任務拆成小段，每段做完都要回報。
- 遵循既有慣例：專案裡已經有的風格和模式，照著走就對了。
- 失敗要大聲：遇到做不到的事，立刻說出來，不要默默瞎猜。
少即是多：200 行懸崖
這套方法有個致命的陷阱。許多人嚐到甜頭後，開始瘋狂往 CLAUDE.md 裡堆規則，結果適得其反。
實測資料顯示，當 CLAUDE.md 超過 200 行，AI 的合規率會急劇下降。原因很直覺：塞太多指令，AI 的注意力被稀釋，反而記不住哪些才是真正重要的。
另一個常見錯誤是放太多「範例」。範例比規則佔用更多 token，而且容易讓 AI 過度擬合特定情境，碰到新狀況反而不知變通。
另一個被忽略的真相：告訴 AI「你是一位資深工程師」完全沒用。角色扮演不會改變模型的行為模式，真正有效的是具體的行為指令。
學術研究者其實特別適合這套思維。有人提出用「巢狀 CLAUDE.md」的概念來管理長期研究專案：最頂層的 CLAUDE.md 像憲法，定義跨專案通用的規矩；每個子資料夾裡的 CLAUDE.md 則像地方法規，處理特定任務的細節。這樣既維持整體一致性，又不會讓單一檔案膨脹到失控。
不寫程式的你，也能帶走的 3 件事
就算你從來沒用過 Claude Code，這 12 條規則背後的思維框架，對任何需要「指揮 AI 做事」的人都有價值：
寫「守則」而非「許願」：把你的需求寫成明確的行為規範，而不是模糊的期望。「幫我寫一篇好文章」遠不如「用台灣繁體中文、800 字以內、每段開頭要有小標題」。
少量精準勝過大量模糊：與其列 30 條注意事項，不如挑出最重要的 5 條，並標明優先順序。AI 和人一樣，指令太多就會選擇性遺忘。
要求 AI 主動回報失敗：在你的提示裡加上「如果有任何不確定的地方，請直接告訴我，不要猜測」。這一條就能擋掉大量無聲的錯誤。
AI 不是讀心術士，它是一個需要明確規則的協作者。你給它的守則越精準，它回報你的成果就越可靠。
本文整理自 Karpathy 原始規則及社群 30 個 codebase 的 6 週實測資料。