CLAUDE.md爆紅內幕：AI寫程式四鐵律，我親自驗證過
**CLAUDE.md 是一份放進專案根目錄的 Markdown 規則檔（rules file），2026 年初開始在 GitHub 上累積驚人星數，因為它把「為什麼 AI 代理（AI agent）寫程式常常失控」這個困擾全球工程師的問題，濃縮成四條可以直接照做的原則。**這篇文章會拆解這四條原則，順手查證一下這個爆紅故事裡有哪些數字被誇大了，最後告訴你：就算你不寫程式，這套邏輯一樣用得上。
一、CLAUDE.md 到底是誰寫的？
CLAUDE.md 不是 Andrej Karpathy 親手寫的檔案，而是另一位開發者依照他的公開觀察整理出來的。 Karpathy 是 OpenAI 創始團隊成員、特斯拉前 AI 總監，也是「氛圍寫程式（vibe coding）」一詞的提出者，2026 年 1 月 26 日他在 X 上公開分享了自己長期觀察到的 AI 代理寫程式時的幾種壞習慣。隔天，開發者 Forrest Chang 把這些觀察整理成一份結構化、AI 可以直接遵守的 Markdown 檔案，發布到 GitHub 上的 andrej-karpathy-skills 專案，這才是後來爆紅的那份 CLAUDE.md。
這個區別看似小事，但值得指出：多篇英文報導都直接把這份檔案寫成「Karpathy 的 CLAUDE.md」，省略了 Forrest Chang 這個關鍵角色。觀念確實源自 Karpathy，但動手寫成可執行規則的人不是他——這正好示範了這篇文章要講的第一條原則：動手前先把事實搞清楚，別把「聽起來合理」當成「已經查證」。
二、AI 代理寫程式最常翻車的三種方式
Karpathy 觀察到的失敗模式，大致可以歸納成三種，而且不只工程師會遇到——任何人交辦任務給 AI 代理，多半都中過其中一種。
- **沉默猜測：**需求有模糊地帶時，AI 不問，自己選一個解釋就動手，結果做出來的不是你要的東西。
- **過度設計：**你只要一個簡單功能，AI 卻自動加上各種「可能用得到」的彈性與例外處理，程式碼膨脹三倍，維護成本也跟著膨脹。
- **越界修改：**你只請它改一個地方，它卻順手「優化」了旁邊沒被要求動的程式碼或格式，事後很難追蹤到底改了什麼。
這三種壞習慣的共同點是：AI 把「我覺得這樣比較好」放在「你實際要求的範圍」之前。CLAUDE.md 的四條原則，就是針對這三種壞習慣逐一設下邊界。
三、四條原則拆解：從思考到驗收
以下是 CLAUDE.md 的核心四條原則，原文是英文，這裡第一次出現時用中英對照呈現，方便之後查資料對得上。
1. 思考優先（Think Before Coding） 遇到模糊或有多種理解方式的需求，AI 應該明確說出自己的假設、列出可能的解讀方式，甚至主動發問——而不是默默選一個答案就開始動手。換成人話：先確認題目，再回答，別自己腦補題目。
2. 簡潔優先（Simplicity First） 能解決問題的最簡單做法，就是正確的做法。不替「可能會用到」的情境預先加彈性、加可設定項、加沒被要求的容錯機制。換成人話：夠用就好，不要先幫未來的問題買保險。
3. 精準修改（Surgical Changes） 只動被要求修改的部分，旁邊沒被指名的程式碼、格式、注釋一律不碰，就算看到「順手就能改好」的地方也先提出來讓人決定，不要自己動手。換成人話：手術範圍以外的地方，連碰都不要碰。
4. 目標驅動執行（Goal-Driven Execution） 把命令式的指令（「做這個、做那個」）轉換成有清楚成功標準與驗證方式的目標，讓 AI 知道「做到什麼程度才算完成」，而不是機械式地照單全收。換成人話：先講清楚怎麼算過關，再開始做。
四、爆紅數字查證：星星數到底是多少？
關於這份檔案累積了多少 GitHub 星，各家報導的數字差距很大，從 8 萬到超過 20 萬都有人引用，而且還在持續攀升。 原因之一是這份規則檔有兩個版本在同時計數：Forrest Chang 個人帳號下的原始版本，以及組織鏡像版本（multica-ai/andrej-karpathy-skills），兩邊星數分開累積，各篇報導抓的時間點與版本也不一致。
據 Tech Times 在 2026 年 5 月的報導，當時個人版約 9 萬 1 千星、組織鏡像版超過 13 萬星，合計突破 22 萬。換句話說，「100K」「110K」「157K」這些數字大概都「曾經是真的」——只是不同時間點、不同版本的快照，被後續文章直接當成固定事實一路轉載，愈滾愈大。這正是典型的網路爆紅故事會發生的事：數字會被簡化成一個好記的整數，然後一路被引用、疊加、誇大。源頭的具體說法是「持續攀升中」，不是某個固定終值。
另一個常被引用、但缺乏第三方驗證的說法，是「程式碼準確度從某個百分比提升到另一個百分比」這類精確統計數字。這類數字多半來自單一開發者的個人實測，沒有獨立第三方覆核，這篇文章選擇不重複轉述，只留下方向性的結論：多位獨立開發者實測後，普遍回報「AI 亂改範圍外程式碼」的情況明顯變少。
真正有公開調查數據支持的，是開發者對 AI 工具的信任落差。據 Stack Overflow 2025 年開發者調查，超過八成的工程師已經在使用或計畫使用 AI 工具，但表示信任 AI 生成程式碼準確性的比例卻不到三成。這個落差，正是 CLAUDE.md 這類規則檔會被搶著用的根本原因——大家想用，但不放心，所以才需要一份「邊界說明書」。
| 項目 | 查證後的說法 |
|---|---|
| 原作者 | Forrest Chang（依 Karpathy 公開觀察整理） |
| 發布時間 | 2026 年 1 月 27 日 |
| GitHub 星數 | 2026 年 5 月合計突破 22 萬，持續成長中（非單一定值） |
| 核心結構 | 四條行為原則：思考優先、簡潔優先、精準修改、目標驅動執行 |
五、我自己工作流裡的對照：原來早就在用類似的邏輯
看到這四條原則時，我第一個動作不是讚嘆，而是回頭檢查自己現有的 AI 工作環境設定有沒有漏洞——結果發現，我自己日常用 Claude Code 的全域設定檔裡，已經有一段邏輯幾乎對應到這四條規則。 差別只是我當時的措辭比較囉嗦，沒有 Karpathy 這四個詞這麼精煉。
具體來說，我的設定檔裡有「動手前確認」（遇到不確定的假設就先說出來，不自己腦補）、「程式碼最小化」（只做被要求的功能，不加可能有用的彈性）、「手術式修改」（只動被要求的部分，旁邊不碰）、「目標驅動執行」（先講成功標準再開始動手）四段規則——跟 CLAUDE.md 的四條原則幾乎一一對應。這不是我抄它，時間點上我的規則更早就存在，純粹是因為我們在處理同一個問題：AI 代理一旦沒有邊界，翻車的方式就那幾種，有經驗的人歸納出來的規則自然會長得很像。
除了寫程式的規則，我也把「目標驅動執行」這條原則延伸到非程式碼的任務上——任何交給 AI 代理的工作，我會先定義「做到什麼程度算完成、用什麼標準驗收」，再讓它動手，而不是丟一句模糊的要求就期待它自己猜對。這套習慣，本質上就是把目標驅動執行，套用到寫程式以外的場景。
六、不只工程師能用：四條原則的非工程師版本
這四條原則的真正價值，不是「讓 AI 寫程式更聽話」，而是「讓任何人跟 AI 代理協作時都有一套可依循的邊界」。 不管你是用 AI 寫文案、整理會議記錄、規劃行銷活動，還是處理報表，同樣的失敗模式都會發生——AI 自己亂猜你的意思、給你一份過度複雜的方案、或是動了你沒要求它動的部分。
| 原則 | 工程師版本 | 一般人版本 |
|---|---|---|
| 思考優先 | 模糊需求先問、列假設 | 請 AI 先說「我理解你要的是……對嗎？」再開始做 |
| 簡潔優先 | 不過度設計程式碼 | 先要最簡單版本，夠用再加，不要一次要「完整方案」 |
| 精準修改 | 只改被要求的程式碼 | 請 AI 只改你指定的段落，其他文字保持原樣 |
| 目標驅動執行 | 定義成功標準再執行 | 先講「完成的樣子長怎樣」，再讓 AI 動手 |
換句話說，CLAUDE.md 真正在教的不是程式語法，而是怎麼跟一個會自己腦補的合作對象劃清楚邊界——這件事，任何用 AI 代理做事的人都需要學。
重點回顧
如果這篇你只想記四句話：
- 查證來源，別照單全收：CLAUDE.md 源自 Karpathy 的公開觀察，但實際整理成檔案的是開發者 Forrest Chang。
- 四條原則的本質是劃邊界：思考優先、簡潔優先、精準修改、目標驅動執行，針對的是「沉默猜測、過度設計、越界修改」三種翻車方式。
- 爆紅數字沒有單一定值：各篇報導引用的是不同時間點、不同版本的快照，從 8 萬到 22 萬都「曾經是真的」。
- 這套邏輯不限工程師：任何交辦任務給 AI 代理的人，都該有一份屬於自己的「規則檔」。
常見問題（FAQ）
Q：CLAUDE.md 是什麼？
CLAUDE.md 是一份放在專案根目錄的 Markdown 規則檔，用來告訴 Claude Code 這類 AI 代理該怎麼寫程式、怎麼下決定。它不是程式碼，而是一份寫給 AI 看的工作守則，核心是四條行為原則。
Q：這份檔案是 Karpathy 自己寫的嗎？
不完全是。Karpathy 在 2026 年 1 月於 X 上公開分享他對 AI 代理常見壞習慣的觀察，開發者 Forrest Chang 隔天把這些觀察整理成可執行的 CLAUDE.md 並發布到 GitHub，才是真正爆紅的那份檔案。
Q：CLAUDE.md 真的累積了多少 GitHub 星？
依不同統計時間點與版本（個人帳號版、組織鏡像版）而不同，2026 年 5 月各方報導從約 8 萬到超過 20 萬都有，且持續攀升，沒有一個單一公定數字，這也是這類爆紅故事常見的灰色地帶。
Q：沒有寫程式背景的人，可以用這四個原則嗎？
可以。四個原則的本質是「跟 AI 協作前先把話講清楚、要求最小化、改動有邊界、用結果驗收」，任何請 AI 代理做事的人都能直接套用，不限工程師。
Q：一個規則檔案真的能改變 AI 的輸出品質嗎？
能改變，但不是魔法。規則檔的作用是把模糊的期待變成 AI 可以遵守的明確邊界，減少「自己亂猜」與「過度設計」這兩種最常見的失敗模式，效果因任務複雜度與下指令的精準度而有落差。
本文方法與案例為本人實作，草稿由 AI 協助整理。