科技
CLAUDE.md這樣寫才對！12條規則一次整理，讓Claude Code錯誤率從41%降至3%
加入為 Google 偏好來源
將 Yahoo 設為首選來源，在 Google 上查看更多我們的精彩報導
重點一：基於前期基礎，開發者將CLAUDE.md規則擴充至12條，使Claude程式碼錯誤率從11%降至3%。 重點二：新增的8條規則主要解決複雜AI代理問題，涵蓋嚴格控管詞元預算、多步驟任務檢查點，以及強制突顯程式碼衝突等。 重點三：實測證明擴充至12條規則並未降低指令遵循度，反而有效彌補舊版規則在處理大型專案與長期任務時的重大盲點。
知名AI研究員安德烈．卡帕西（Andrej Karpathy）於2026年初指出AI模型在編寫程式碼時的常見缺失。隨後，開發者Forrest Chang將其總結為4條CLAUDE.md指令，成功將高達 41% 的 AI 編碼錯誤率大幅降至 11%，在GitHub上斬獲逾12萬顆星。
然而，隨著AI生態系快速演進，有開發者針對30個程式碼庫進行長達六週的實測，發現將原有的AI編碼提示規則擴充至12條後，成功使Claude 的程式碼錯誤率從11%進一步壓縮至3%以下，全面提升了開發效率。
今年 1 月，卡帕西在社群媒體上公開抱怨，他用 AI 寫程式，卻老是出問題。他歸納出3個反覆出現的模式：
AI 遇到不確定的情境時，不會詢問使用者，而是自行假設並繼續執行，導致最終產出與需求不符。
AI 傾向以複雜的架構解決可以用簡單方式處理的問題，引入多餘的抽象層與不必要的功能。
AI 在修改指定程式碼時，常順手「整理」周邊不相關的程式碼、格式或註解，造成難以追蹤的副作用。
總歸來說，以上3個問題的共通點，是AI在沒有明確規範的情況下，會自行填補空白，但內容並非是使用者想要的。
軟體工程師Forrest Chang在讀到卡帕西的貼文後，將這3個問題整理成4條具體的行為規則，以單一純文字檔案的形式發佈於開源平台 GitHub。
這份檔案名為「CLAUDE.md」，是一份放置於程式專案根目錄的純文字說明書，用途是告訴 AI 助理在協作過程中應當遵守哪些行為準則。
其運作原理類似於企業為新進員工準備的工作守則，規定AI在面對模糊指示、遇到衝突情境，或需要自行判斷時，必須依循哪些原則行事。
這份 65 行的檔案在 GitHub 上一天內獲得將近 6,000 人收藏，兩週突破 6 萬，目前已超過 12 萬，成為 2026 年成長最快的單一檔案開源專案。
這4條規則的核心要點分別為：
實作前務必釐清所有假設與模糊地帶，絕不盲目猜測或替使用者做決定；若有更簡單的解法應主動提出，遇到任何不清楚的地方必須立刻停下來發問。
只用最少的程式碼解決當下問題，嚴格拒絕任何過度工程化、推測未來需求的功能或不必要的抽象層，確保產出符合資深工程師眼中的「精簡」標準。
只精準更動與需求直接相關的範圍，絕對不去「順手改善」或重構旁邊未損壞的程式碼及排版，並且只負責清理因本次修改才變成無用的變數或引入。
將任務轉化為「可被驗證的具體目標」（例如：寫出測試並讓它通過），為多步驟任務建立帶有檢查點的計畫，讓 AI 能基於明確的成功標準自主迭代到完成。
原始4條規則雖然有效，但資深AI工程師Mnimiy在進行系統性測試後發現，它們主要針對的是「單次對話中的寫程式錯誤」，但在面對2026年更複雜的多步驟AI代理協作（Agent-orchestration）與大型專案時，會暴露出以下幾個關鍵漏洞：
無法應付長時間運作的多步驟任務 ：原規則預設為單次互動，缺乏 Token 預算與進度檢查點。這導致 AI 在長任務中容易迷失方向、悄悄把錯誤疊加；同時也沒限制 AI 的職責，讓它越界去處理 API 路由等本該由純程式碼執行的確定性邏輯，徒增成本與不穩定性。
在多程式碼庫中會引發風格混亂 ：原規則要求「配合現有風格」，但當專案中同時存在新舊兩種相衝的寫法時，AI 會試圖將兩者「平均融合」，反而寫出更難除錯的四不像程式碼。
產生為通過而通過的無效測試 ：原規則要求 AI 循環執行直到成功，導致 AI 為了交差，寫出毫無業務價值、只為了亮綠燈的淺層測試（例如把數值寫死），掩蓋了真實的邏輯錯誤。
扼殺原型開發的彈性 ：「簡單至上」規則嚴禁任何推測性架構與多餘程式碼，這能有效保護正式環境，但對於需要快速搭建框架、探索方向的原型開發階段，反而會讓 AI 綁手綁腳。
Mnimiy針對這4個缺口，歷經六週、橫跨30個專案，新增了8條規則，填補AI代理時代的系統盲點，讓AI的編寫錯誤率從11%降至 3%。
以下是Mnimiy提出的8條規則，用來補足前4條規則的複雜 AI 代理協作的死角。
將 AI 用於分類、摘要、草擬等主觀判斷工作，嚴禁讓 AI 去處理狀態碼判斷、API 重試或路由分配。
只要能用傳統程式碼以 if-else 邏輯寫死的確定性任務，就應交由純程式碼執行，避免模型產生隨機且不可靠的決策。
明確規範單一任務（如 4,000 tokens）與單次對話（如 30,000 tokens）的消耗上限。當運算資源即將耗盡時，模型必須主動總結當前進度並要求重新啟動對話。
此舉可防止模型在無法解決的錯誤中陷入無限迴圈，造成不必要的資源與成本浪費。
當程式庫中存在兩種相互矛盾的寫法時，AI 傾向「兩種都照顧到」，寫出一個試圖同時滿足兩種規範的程式碼。這比任何一種原始寫法都更難維護。
規則7要求 AI 選擇其中一種（優先選較新或測試較完整的），說明理由，並標記另一種待日後清理。
在新增或修改任何程式碼之前，模型必須先讀取該檔案的輸出 (exports)、直接呼叫者函數以及相關的共用工具程式碼。
不允許模型在未完全理解現有程式碼結構的情況下，以兩者互不相關為由直接寫入新功能。
模型編寫的測試程式碼必須能真實反映商業邏輯的運作。如果一項業務邏輯發生改變，相關的測試卻依然能夠通過（例如模型為了讓測試亮綠燈而將回傳值寫死），即代表該測試無效。
測試的目的是驗證行為為何重要，而非僅驗證程式有在執行。
長時間的重構或功能開發橫跨多個步驟，一旦中途出錯，後續步驟可能全部建立在錯誤的基礎上。
規則10要求 AI 在完成每個重要步驟後，主動回報「已完成事項、已驗證事項、剩餘事項」，若模型在執行過程中遺失上下文，無法精確描述當前狀態，就必須立即中止任務並重新釐清，防止錯誤進度持續疊加。
每個程式庫都有自己的命名規則、元件寫法與錯誤處理模式。AI 即便認為自己的寫法更好，也不應在沒有告知的情況下引入新風格，因為「兩種風格並存」比任何一種風格單獨使用都更難維護。
無論模型是否認為某種新框架或寫法更優良，只要專案既定採用特定的命名規則或舊有架構，模型就必須完全配合，禁止在未經討論的情況下擅自引入新風格。
這是 8 條新規則中最受關注的一條。規則要求 AI 在任何步驟有疑問、有遺漏，或無法完整驗證結果時，必須明確回報異常，絕對不允許回報「執行完成」或「測試通過」。
必須將所有不確定性或未執行的步驟完整呈現給開發者，確保沒有任何錯誤被默默忽略。
這份擴充至 12 條規則的 CLAUDE.md 究竟能帶來多大效益？Mnimiy在 30 個不同的程式碼庫中，針對 50 個具代表性的開發任務進行了為期 6 週的嚴格盲測，而最終的數據結果清楚指出了這套「行為契約」的效用。以下整理3大實測亮點：
實測數據展現了錯誤率（指需要開發者手動修正的比例）的兩階段驟降。在沒有任何規則約束的情況下，AI 處理任務的錯誤率高達 41%。當導入 Forrest Chang 整理的 4 條基礎規則後，成功攔截了絕大多數基礎寫碼錯誤，將錯誤率大幅削弱至 11%。
而進一步套用完整的 12 條擴充規則後，原先針對 AI 代理協作與長任務失控的系統盲點被封鎖，使剩餘的錯誤率被極限壓縮至僅剩 3%。
然而，12 條規則在測試中的整體合規率為 76%，意即仍有約四分之一的情況下 AI 不會主動套用規則。此外，規則的效果因任務性質而異，對結構明確的重構任務效果顯著，對高度創意性或探索性的開發工作則效果有限。
這份測試報告最引人矚目的亮點，在於打破了開發界「規則越多，AI 越不聽話」的迷思。
一般而言，過長的提示詞會導致模型失焦，但實測發現，將規則從 4 條擴充至 12 條後，AI 的指令遵循度（Compliance）僅從 78% 微幅下滑至 76%，意味著開發者幾乎沒有付出額外的遵循度成本，就換取了額外 8% 的錯誤率下降。
其背後的關鍵在於，這 12 條規則涵蓋了完全不同的觸發情境，原有的 4 條規則處理的是基礎寫碼邏輯，而新增的 8 條規則則是為了應對多步驟任務、預算控管與測試無效等進階痛點，兩者並不會在 AI 處理單一任務時互相爭奪注意力預算。
Mnimiy實測發現，網路上流傳的許多寫code提示詞技巧，反而會破壞 AI 的表現：
許多人喜歡在提示詞裡舉例，但實測發現，範例非常消耗上下文預算（3 個範例的詞元消耗量相當於約 10 條抽象規則）。更糟的是，AI 會對範例產生「過度擬合 (Over-fit)」，變得不知變通。因此要使用抽象規則，不要用具體範例。
告訴 AI「請仔細思考」、「你要表現得像個資深工程師」完全沒用。AI 本來就自認是資深工程師，這類無法被驗證的空泛指令，會讓指令遵循度暴跌至 30%。指令必須是具體的動作（例如：明確寫出你的假設），而不是情緒勒索。
規定 AI「永遠使用 ESLINT程式碼檢查工具」是個陷阱，因為一旦專案沒安裝該工具，這條規則就會默默失效。應改用不受工具限制的說法，例如：配合專案強制執行的風格。
Mnimiy也強調，不要盲目套用這 12 條規則，每一條寫進去的規則都必須能回答一個問題：「這能防止我實際遇過的什麼錯誤？」
「一個針對你真實痛點量身打造的 6 條規則，絕對勝過一個塞滿了 6 條你永遠用不到的 12 條規則範本。」Mnimiy說道。
延伸閱讀：AI用錯方式，就算10分鐘也會變笨！研究揭「只問提示、不要答案」一招保住思考力 Claude Code快捷鍵+指令大全！13大類速查不用背，從Ctrl+C到多Agent協作一次整理
資料來源：Mnimiy X
更多報導把壁癌修掉、放進虛擬家具，AI美圖賣屋恐引爆消費糾紛？專家揭2條紅線不能踩執行長都這樣用AI！12位CEO親揭工作術：讓AI當幕僚長、情報蒐集、沙盤推演難關⋯
將 Yahoo 設為首選來源，在 Google 上查看更多我們的精彩報導
重點一：基於前期基礎，開發者將CLAUDE.md規則擴充至12條，使Claude程式碼錯誤率從11%降至3%。 重點二：新增的8條規則主要解決複雜AI代理問題，涵蓋嚴格控管詞元預算、多步驟任務檢查點，以及強制突顯程式碼衝突等。 重點三：實測證明擴充至12條規則並未降低指令遵循度，反而有效彌補舊版規則在處理大型專案與長期任務時的重大盲點。
知名AI研究員安德烈．卡帕西（Andrej Karpathy）於2026年初指出AI模型在編寫程式碼時的常見缺失。隨後，開發者Forrest Chang將其總結為4條CLAUDE.md指令，成功將高達 41% 的 AI 編碼錯誤率大幅降至 11%，在GitHub上斬獲逾12萬顆星。
然而，隨著AI生態系快速演進，有開發者針對30個程式碼庫進行長達六週的實測，發現將原有的AI編碼提示規則擴充至12條後，成功使Claude 的程式碼錯誤率從11%進一步壓縮至3%以下，全面提升了開發效率。
今年 1 月，卡帕西在社群媒體上公開抱怨，他用 AI 寫程式，卻老是出問題。他歸納出3個反覆出現的模式：
AI 遇到不確定的情境時，不會詢問使用者，而是自行假設並繼續執行，導致最終產出與需求不符。
AI 傾向以複雜的架構解決可以用簡單方式處理的問題，引入多餘的抽象層與不必要的功能。
AI 在修改指定程式碼時，常順手「整理」周邊不相關的程式碼、格式或註解，造成難以追蹤的副作用。
總歸來說，以上3個問題的共通點，是AI在沒有明確規範的情況下，會自行填補空白，但內容並非是使用者想要的。
軟體工程師Forrest Chang在讀到卡帕西的貼文後，將這3個問題整理成4條具體的行為規則，以單一純文字檔案的形式發佈於開源平台 GitHub。
這份檔案名為「CLAUDE.md」，是一份放置於程式專案根目錄的純文字說明書，用途是告訴 AI 助理在協作過程中應當遵守哪些行為準則。
其運作原理類似於企業為新進員工準備的工作守則，規定AI在面對模糊指示、遇到衝突情境，或需要自行判斷時，必須依循哪些原則行事。
這份 65 行的檔案在 GitHub 上一天內獲得將近 6,000 人收藏，兩週突破 6 萬，目前已超過 12 萬，成為 2026 年成長最快的單一檔案開源專案。
這4條規則的核心要點分別為：
實作前務必釐清所有假設與模糊地帶，絕不盲目猜測或替使用者做決定；若有更簡單的解法應主動提出，遇到任何不清楚的地方必須立刻停下來發問。
只用最少的程式碼解決當下問題，嚴格拒絕任何過度工程化、推測未來需求的功能或不必要的抽象層，確保產出符合資深工程師眼中的「精簡」標準。
只精準更動與需求直接相關的範圍，絕對不去「順手改善」或重構旁邊未損壞的程式碼及排版，並且只負責清理因本次修改才變成無用的變數或引入。
將任務轉化為「可被驗證的具體目標」（例如：寫出測試並讓它通過），為多步驟任務建立帶有檢查點的計畫，讓 AI 能基於明確的成功標準自主迭代到完成。
原始4條規則雖然有效，但資深AI工程師Mnimiy在進行系統性測試後發現，它們主要針對的是「單次對話中的寫程式錯誤」，但在面對2026年更複雜的多步驟AI代理協作（Agent-orchestration）與大型專案時，會暴露出以下幾個關鍵漏洞：
無法應付長時間運作的多步驟任務 ：原規則預設為單次互動，缺乏 Token 預算與進度檢查點。這導致 AI 在長任務中容易迷失方向、悄悄把錯誤疊加；同時也沒限制 AI 的職責，讓它越界去處理 API 路由等本該由純程式碼執行的確定性邏輯，徒增成本與不穩定性。
在多程式碼庫中會引發風格混亂 ：原規則要求「配合現有風格」，但當專案中同時存在新舊兩種相衝的寫法時，AI 會試圖將兩者「平均融合」，反而寫出更難除錯的四不像程式碼。
產生為通過而通過的無效測試 ：原規則要求 AI 循環執行直到成功，導致 AI 為了交差，寫出毫無業務價值、只為了亮綠燈的淺層測試（例如把數值寫死），掩蓋了真實的邏輯錯誤。
扼殺原型開發的彈性 ：「簡單至上」規則嚴禁任何推測性架構與多餘程式碼，這能有效保護正式環境，但對於需要快速搭建框架、探索方向的原型開發階段，反而會讓 AI 綁手綁腳。
Mnimiy針對這4個缺口，歷經六週、橫跨30個專案，新增了8條規則，填補AI代理時代的系統盲點，讓AI的編寫錯誤率從11%降至 3%。
以下是Mnimiy提出的8條規則，用來補足前4條規則的複雜 AI 代理協作的死角。
將 AI 用於分類、摘要、草擬等主觀判斷工作，嚴禁讓 AI 去處理狀態碼判斷、API 重試或路由分配。
只要能用傳統程式碼以 if-else 邏輯寫死的確定性任務，就應交由純程式碼執行，避免模型產生隨機且不可靠的決策。
明確規範單一任務（如 4,000 tokens）與單次對話（如 30,000 tokens）的消耗上限。當運算資源即將耗盡時，模型必須主動總結當前進度並要求重新啟動對話。
此舉可防止模型在無法解決的錯誤中陷入無限迴圈，造成不必要的資源與成本浪費。
當程式庫中存在兩種相互矛盾的寫法時，AI 傾向「兩種都照顧到」，寫出一個試圖同時滿足兩種規範的程式碼。這比任何一種原始寫法都更難維護。
規則7要求 AI 選擇其中一種（優先選較新或測試較完整的），說明理由，並標記另一種待日後清理。
在新增或修改任何程式碼之前，模型必須先讀取該檔案的輸出 (exports)、直接呼叫者函數以及相關的共用工具程式碼。
不允許模型在未完全理解現有程式碼結構的情況下，以兩者互不相關為由直接寫入新功能。
模型編寫的測試程式碼必須能真實反映商業邏輯的運作。如果一項業務邏輯發生改變，相關的測試卻依然能夠通過（例如模型為了讓測試亮綠燈而將回傳值寫死），即代表該測試無效。
測試的目的是驗證行為為何重要，而非僅驗證程式有在執行。
長時間的重構或功能開發橫跨多個步驟，一旦中途出錯，後續步驟可能全部建立在錯誤的基礎上。
規則10要求 AI 在完成每個重要步驟後，主動回報「已完成事項、已驗證事項、剩餘事項」，若模型在執行過程中遺失上下文，無法精確描述當前狀態，就必須立即中止任務並重新釐清，防止錯誤進度持續疊加。
每個程式庫都有自己的命名規則、元件寫法與錯誤處理模式。AI 即便認為自己的寫法更好，也不應在沒有告知的情況下引入新風格，因為「兩種風格並存」比任何一種風格單獨使用都更難維護。
無論模型是否認為某種新框架或寫法更優良，只要專案既定採用特定的命名規則或舊有架構，模型就必須完全配合，禁止在未經討論的情況下擅自引入新風格。
這是 8 條新規則中最受關注的一條。規則要求 AI 在任何步驟有疑問、有遺漏，或無法完整驗證結果時，必須明確回報異常，絕對不允許回報「執行完成」或「測試通過」。
必須將所有不確定性或未執行的步驟完整呈現給開發者，確保沒有任何錯誤被默默忽略。
這份擴充至 12 條規則的 CLAUDE.md 究竟能帶來多大效益？Mnimiy在 30 個不同的程式碼庫中，針對 50 個具代表性的開發任務進行了為期 6 週的嚴格盲測，而最終的數據結果清楚指出了這套「行為契約」的效用。以下整理3大實測亮點：
實測數據展現了錯誤率（指需要開發者手動修正的比例）的兩階段驟降。在沒有任何規則約束的情況下，AI 處理任務的錯誤率高達 41%。當導入 Forrest Chang 整理的 4 條基礎規則後，成功攔截了絕大多數基礎寫碼錯誤，將錯誤率大幅削弱至 11%。
而進一步套用完整的 12 條擴充規則後，原先針對 AI 代理協作與長任務失控的系統盲點被封鎖，使剩餘的錯誤率被極限壓縮至僅剩 3%。
然而，12 條規則在測試中的整體合規率為 76%，意即仍有約四分之一的情況下 AI 不會主動套用規則。此外，規則的效果因任務性質而異，對結構明確的重構任務效果顯著，對高度創意性或探索性的開發工作則效果有限。
這份測試報告最引人矚目的亮點，在於打破了開發界「規則越多，AI 越不聽話」的迷思。
一般而言，過長的提示詞會導致模型失焦，但實測發現，將規則從 4 條擴充至 12 條後，AI 的指令遵循度（Compliance）僅從 78% 微幅下滑至 76%，意味著開發者幾乎沒有付出額外的遵循度成本，就換取了額外 8% 的錯誤率下降。
其背後的關鍵在於，這 12 條規則涵蓋了完全不同的觸發情境，原有的 4 條規則處理的是基礎寫碼邏輯，而新增的 8 條規則則是為了應對多步驟任務、預算控管與測試無效等進階痛點，兩者並不會在 AI 處理單一任務時互相爭奪注意力預算。
Mnimiy實測發現，網路上流傳的許多寫code提示詞技巧，反而會破壞 AI 的表現：
許多人喜歡在提示詞裡舉例，但實測發現，範例非常消耗上下文預算（3 個範例的詞元消耗量相當於約 10 條抽象規則）。更糟的是，AI 會對範例產生「過度擬合 (Over-fit)」，變得不知變通。因此要使用抽象規則，不要用具體範例。
告訴 AI「請仔細思考」、「你要表現得像個資深工程師」完全沒用。AI 本來就自認是資深工程師，這類無法被驗證的空泛指令，會讓指令遵循度暴跌至 30%。指令必須是具體的動作（例如：明確寫出你的假設），而不是情緒勒索。
規定 AI「永遠使用 ESLINT程式碼檢查工具」是個陷阱，因為一旦專案沒安裝該工具，這條規則就會默默失效。應改用不受工具限制的說法，例如：配合專案強制執行的風格。
Mnimiy也強調，不要盲目套用這 12 條規則，每一條寫進去的規則都必須能回答一個問題：「這能防止我實際遇過的什麼錯誤？」
「一個針對你真實痛點量身打造的 6 條規則，絕對勝過一個塞滿了 6 條你永遠用不到的 12 條規則範本。」Mnimiy說道。
延伸閱讀：AI用錯方式，就算10分鐘也會變笨！研究揭「只問提示、不要答案」一招保住思考力 Claude Code快捷鍵+指令大全！13大類速查不用背，從Ctrl+C到多Agent協作一次整理
資料來源：Mnimiy X
更多報導把壁癌修掉、放進虛擬家具，AI美圖賣屋恐引爆消費糾紛？專家揭2條紅線不能踩執行長都這樣用AI！12位CEO親揭工作術：讓AI當幕僚長、情報蒐集、沙盤推演難關⋯
新聞來源: 原始來源
尚無評論，成為第一個發言的人吧！