前 Tesla AI 總監、前 OpenAI 聯合創始人 Andrej Karpathy，大概是全世界最懂 AI 寫代碼會出什麼問題的人。
他觀察到 LLM（大型語言模型）寫代碼有三個致命毛病：猜而不問、寫得太複雜、改了不該改的東西。如果你用過 Claude Code、Cursor、或任何 AI 程式助手，你一定知道這種痛——你叫它改一個 bug，它順手「幫」你重構了半個專案。
現在有人把 Karpathy 的這些觀察，濃縮成了一個檔案。
一個叫 CLAUDE.md 的純文字檔案，貼進你的專案根目錄，Claude Code 的行為立刻不一樣。GitHub 上線不到一週，47,800 顆星，單日新增 8,000 顆——這個數字放在任何 AI 專案裡都是炸裂級的。
我拆解了這個檔案裡到底寫了什麼，為什麼有效，以及你該怎麼用。
CLAUDE.md 是什麼？為什麼一個文字檔能改變 AI 的行為？
先解釋背景。Claude Code（Anthropic 出品的 AI 程式助手）會在啟動時自動讀取專案根目錄下的 CLAUDE.md 檔案，把裡面的內容當成「工作守則」。你可以把它理解成給 AI 寫的員工手冊——告訴它這個專案的規矩是什麼、你的偏好是什麼、哪些事絕對不能做。
這個機制本身不新。但問題是：大多數人不知道該在裡面寫什麼。
GitHub 用戶 forrestchang 做了一件聰明的事：他把 Karpathy 公開分享過的 AI 編程觀察和最佳實踐，整理成一套結構化的 CLAUDE.md 指南。不是什麼花俏的框架，就是一個檔案，四條原則，每條配具體的規則。
結果這個 repo 爆了。截至 2026 年 4 月 16 日，47,800 星，還在漲。
四條鐵律拆解：Karpathy 到底教了 Claude 什麼？
我把這四條原則翻譯成人話，配上你馬上能用的場景。
原則一：想清楚再動手（Think Before Coding）
LLM 最常犯的錯是默默猜測你的意圖，然後按照猜測寫了一堆代碼。你說「幫我加個登入功能」，它猜你要 OAuth，花了 200 行寫好了——但你其實只要一個簡單的密碼登入。
Karpathy 的解法：強制 Claude 在動手前先說出自己的假設。
具體規則包括：
- 碰到模糊需求時，必須先提問，不能猜
- 如果有多種理解方式，把每種都列出來讓你選
- 搞不清楚的時候，拒絕繼續而不是硬寫
聽起來簡單？但加了這條之後，你會發現 Claude 變得像一個會先確認需求的資深工程師，而不是一個急著交作業的實習生。
原則二：簡單至上（Simplicity First）
這條打中了所有 AI 程式助手用戶的痛點。
你叫 AI 寫一個簡單的函數，它給你一個帶有三層抽象、可擴展配置、完整錯誤處理的「企業級」解決方案。200 行能搞定的事，它寫了 800 行。不是因為它笨，是因為訓練數據裡充滿了過度設計的代碼。
Karpathy 的規則很直接：
- 只實現你要求的功能，多一行都不寫
- 不加你沒要求的抽象層和配置選項
- 不為不可能的場景寫錯誤處理
- 如果 200 行能搞定，但寫了 500 行，重寫
我自己測試的感受：加了這條之後，Claude Code 產出的代碼量大概減少了 40-60%，但功能完全沒少。代碼短了，bug 也少了。因為 bug 藏在複雜度裡，代碼越少，能出錯的地方就越少。
原則三：精準手術（Surgical Changes）
這是我個人認為最關鍵的一條。
AI 程式助手有個壞習慣：你讓它改 A 函數，它順便「改進」了 B 函數的命名、重新排版了 C 檔案的 import、還刪了它認為「多餘」的舊代碼。改完之後你的 git diff 一看——天，改了 15 個檔案，你只想改一行。
Karpathy 的規則：
- 只改任務需要的代碼，一行都不多碰
- 不要「順便改進」旁邊的代碼
- 保持現有的程式風格，不要按自己的偏好重新格式化
- 只刪除你這次修改造成的多餘 import，原本就存在的「死代碼」不要動
說白了就是：你是來做手術的，不是來做全身健檢的。開刀開到哪就到哪，別順手摘了病人的扁桃腺。
原則四：目標導向執行（Goal-Driven Execution）
最後一條解決的是 AI「只做字面意思」的問題。
你說「幫我修這個 bug」，它可能修了語法錯誤就停了，但 bug 的根本原因（邏輯錯誤）還在。它完成了你的「指令」，但沒達成你的「目標」。
Karpathy 的做法是讓 Claude 把模糊指令轉換成明確的成功標準，然後自己驗證有沒有達標：
- 收到任務後，先定義「做完長什麼樣」
- 先寫測試，再寫代碼（Test-Driven）
- 多步驟任務要包含驗證步驟
- 沒達標就自己繼續改，不要扔半成品回來
加了這條之後，Claude 交回來的東西完成度明顯提高。以前經常需要兩三輪來回修改的任務，現在一次到位的比例大增。
怎麼用？兩分鐘搞定
安裝方式有兩種，都很快：
方法 A（推薦）：用 Claude Code 插件市場安裝
如果你已經在用 Claude Code，直接在終端輸入安裝指令，它會自動把 CLAUDE.md 加到你的專案裡。具體指令在 GitHub repo 的 README 裡寫得很清楚。
方法 B：手動下載
去 repo 頁面，下載 CLAUDE.md 檔案，扔到你專案的根目錄。沒了。下次啟動 Claude Code 時它會自動讀取。
不需要改任何設定，不需要裝額外工具。一個檔案，複製貼上，完事。
實際效果如何？我的體感和社群反饋
我用了大約兩天，主觀感受：
改善最明顯的：精準手術（原則三）。以前 Claude Code 改一個函數動輒波及十幾個檔案，現在 git diff 乾淨很多。Code review 的時間砍了至少一半。
其次是：簡單至上（原則二）。產出的代碼明顯精簡了，不再動不動就搞三層封裝。
效果較微妙的：原則一和四。這兩條更像是改變了互動方式——Claude 會多問幾個問題，任務完成度提高了，但不像前兩條那樣立竿見影。
GitHub 上的評價也蠻一致的。高星數（48K）說明這不是曇花一現。多數開發者的回報都集中在「代碼更乾淨」和「不再亂改我的檔案」這兩點。
局限性：它不是萬能藥
講完好話，講幾個要注意的地方。
第一，這只對 Claude Code 有效。CLAUDE.md 是 Claude Code 特有的機制，Cursor、Copilot、Windsurf 有各自的設定方式。不過這四條原則本身是通用的，你可以把概念搬到其他工具的系統提示詞裡。
第二，它治標不治本。這些規則是在模型外部加限制，不是讓模型本身變聰明了。碰到真正複雜的架構決策，AI 還是會犯錯——只是犯錯的方式更可控了。
第三，可能導致 Claude 變得太保守。特別是原則一（想清楚再動手），有時候你就是想讓它先寫個草稿出來再說，結果它一直問你問題。這時候你可能需要手動告訴它「別問了，先寫」。
更大的趨勢：CLAUDE.md 生態正在爆發
karpathy-skills 不是唯一一個在做這件事的專案。看看今天 GitHub Trending 上還有什麼：
- claude-mem（59K 星）：讓 Claude Code 擁有跨 session 的長期記憶，每次開新對話不用重新解釋上下文
- Claude Code Routines（Anthropic 官方，2026-04-14 發布）：設定排程讓 Claude Code 自動在雲端執行任務，關掉電腦也能跑
一個趨勢正在形成：AI 程式助手的戰場不再只是「模型誰比較聰明」，而是「誰的生態系統更完整」。CLAUDE.md 相當於 Claude Code 的「App Store」——社群可以分享最佳實踐，讓同一個 AI 在不同場景下表現完全不同。
這對我們普通用戶來說是好事。以前想讓 AI 程式助手聽話，你得自己摸索 prompt 的寫法，靠反覆試錯。現在你只要找到一個好的 CLAUDE.md，複製貼上就行。門檻歸零了。
結論：該不該用？
如果你在用 Claude Code，沒有任何理由不試。零成本、兩分鐘安裝、立即見效。最差的結果也就是刪掉一個檔案。
我的建議是先用原版試一週，體驗 Karpathy 的四條原則在你的專案裡效果如何。然後根據你自己的需求，在這個基礎上加減規則。每個人的程式風格不同，最好的 CLAUDE.md 永遠是你自己調過的那一份。
畢竟，AI 程式助手的未來不是「模型自己變完美」——是你學會怎麼調教它。Karpathy 只是幫你開了個好頭。
專案連結：github.com/forrestchang/andrej-karpathy-skills
⚠️ 免責聲明：本文為工具介紹與使用心得，不構成任何投資或技術決策建議。AI 工具更新極快，文中資訊截至 2026 年 4 月。請自行評估風險。
發表迴響