Andrej Karpathy Skills 保姆級教程：CLAUDE.md 怎麼約束 Claude Code，4 條規則解決 AI 亂改程式碼問題

症狀：Claude Code 不只完成需求，還順手改了無關檔案。
最快解法：在 CLAUDE.md 寫清楚改動範圍、先計畫、最小修改與驗證要求；但不要把專案指令當成權限隔離或絕對保證。

如果你正在用 Claude Code 開發，想控制 AI 改動範圍，以下規則可以直接作為專案約定的起點。技術負責人也可以用它檢查團隊的 CLAUDE.md 是否具體、可驗證。

先理解 CLAUDE.md 能約束 Claude Code 到哪裡

CLAUDE.md 的用途是提供 Claude Code 專案指令，讓它理解程式庫的規則、慣例與工作方式。官方文件說明，Claude Code 會讀取適用的記憶與指令；但這些內容是提供工作脈絡，不等於作業系統層級的檔案限制。Claude Code 記憶文件

因此，你可以要求它「只改指定檔案」，也可以要求它遇到範圍外問題先詢問；但若要限制哪些操作可以執行，應另外檢查 Claude Code 的權限設定。官方權限文件把允許、詢問與拒絕等規則作為操作控制機制說明，兩者的功能不能混為一談。Claude Code 權限設定說明

把 CLAUDE.md 想成工作約定，而不是防護牆。它能降低越界修改的機率，卻不能代替權限設定、版本控制與人工審查。

注意：若任務要求修改的檔案與既有規則衝突，或執行過程中發現必須改動其他位置，應先要求 Claude Code 停下來說明原因；不要默認它可以自行擴大範圍。

分清 Andrej Karpathy Skills 與專案指令

標題中的 Andrej Karpathy Skills，應與本文提供的 CLAUDE.md 工作規則分開看。Karpathy 的原始貼文可用來核對其本人公開分享的內容；而以此為名的 GitHub 專案則是另一個可追溯來源，不能僅憑名稱就當成 Karpathy 本人撰寫或認可的官方規範。原始貼文

Claude Code 的 Skills 也有自己的概念與文件，不能直接與 CLAUDE.md 畫上等號。Claude Code Skills 文件本文的四條規則是依照「讓改動更容易檢查」這個目標整理的專案工作建議，不是 Karpathy 的原話，也不是 Claude Code 官方保證。

實際設定時，讓指令貼合目前程式庫：寫明本專案採用的慣例、哪些變更需要確認，以及應如何驗證。不要複製一份通用 Skills 說明，便假設它已涵蓋你的目錄結構、測試方式與團隊流程。

第一步：先寫明允許修改的範圍

只有「修好這個問題」這種描述，容易讓任務邊界變得含糊。CLAUDE.md 的規則應分別交代要達成的目標、可修改位置，以及不可順手擴張的工作。

可依你的專案情況改寫：

## 任務範圍
- 只修改本次需求明確涉及的檔案。
- 開始前列出預計修改的檔案與原因。
- 不進行無關重構，不修改其他設定、相依套件或文件。
- 若無法在上述範圍內完成，先說明原因並等待確認。

「明確涉及」仍可能有解讀空間。交辦任務時，最好再指定目標檔案或目錄；如果暫時無法判斷，先要求它列出候選檔案和理由，不要讓它用修改來代替釐清。

若你需要真正限制讀寫或執行操作，應查閱權限設定，而非只加重 CLAUDE.md 的措辭。兩種手段各有用途：一種說明任務應如何進行，另一種用來處理操作許可。Claude Code 權限規則

第二步：要求先計畫，再開始修改

先計畫的價值不在於保證正確，而在於讓你有機會在改檔前發現理解偏差。要求 Claude Code 先用簡短清單交代需求理解、預計修改位置與驗證方式。若它提出的計畫超出任務範圍，就先修正計畫，不要直接進入實作。

例如，你交辦一個明確的小型缺陷修正，可以先要求它：

• 重述預期行為與問題邊界。
• 列出預計查看及修改的檔案，並說明各自用途。
• 說明打算參照哪一種既有測試或檢查方式。
• 若計畫涉及額外檔案、相依套件或介面變更，先詢問你。

這也符合 Claude Code 官方最佳實務中強調的規劃與檢查思路，但你的 CLAUDE.md 應依專案實際流程調整，不必照搬成不適用的固定步驟。Claude Code 官方最佳實務

第三步：把「最小改動」寫成可檢查的要求

最小改動不是單純少改幾行，而是只做完成需求所需的修改。要求沿用現有命名、結構與格式，不因個人偏好換架構、改依賴或整理無關程式碼。

完成後，檢查實際改動是否仍符合原先計畫：查看變更檔案清單，再逐段檢視 diff。若新增檔案、設定變動或重構不在計畫內，請 Claude Code 說明必要性；理由不足，就要求還原無關部分。

不過，最小改動不代表忽略必要修復。若修正需求確實需要更動額外檔案，重點是先交代依賴關係、取得確認，再納入明確的新範圍，而不是假裝它屬於原本計畫。

第四步：驗證結果，並照實回報

CLAUDE.md 可以要求修改後執行適用的驗證，但不要憑空指定專案沒有的命令。先讓 Claude Code 查看程式庫已有的文件、測試設定、腳本或 CI 流程，再選擇能對應本次變更的檢查方式。

回報要區分三件事：實際執行了什麼、結果如何、哪些檢查沒有執行及原因。若環境不完整、命令無法執行或缺少測試，應明確說明，不得將未執行描述成已通過。

如果團隊還需要自動檢查某些條件，可評估 Claude Code 的 hooks；官方文件將 hooks 說明為可設定的事件觸發機制。這與 CLAUDE.md 的文字指引不同，但是否適合、如何設定，仍要依你的工作流程確認。Claude Code hooks 文件

在中段用小任務檢查規則是否有效

不要只看 CLAUDE.md 寫得完整與否。挑一個目標清楚、允許改動位置明確的小任務，實際觀察 Claude Code 是否先提出計畫、是否守住範圍，以及是否如實交代驗證結果。

這樣測試時，先保存當前版本，再記錄它提出的計畫；完成後比對變更檔案清單與 diff，標出計畫外變更，最後核對測試或檢查的實際結果。若同一條規則仍有不同解讀，就補上可觀察的條件；若規則彼此衝突，先釐清優先順序，再重試。

長尾問題整理

要指定只能改某些檔案時：在任務指令與 CLAUDE.md 中明列允許範圍，並規定超出範圍時先停止、說明、等待確認。若你需要技術層面的操作限制，另行設定權限。

要減少 AI 亂改程式碼時：把「先計畫、只改必要部分、沿用既有風格、完成後驗證」改寫成可檢查的行為，而不是籠統要求「小心」。

要防止未確認的操作時：CLAUDE.md 能要求先詢問，但不能單獨保證阻止操作。需要限制權限時，應使用對應的權限機制。

要要求修改後驗證時：指示它先查閱專案現有的測試與檢查依據，再回報實際執行結果；不要要求它猜測不存在的命令。

把四條規則整理成可維護的專案約定

以下對照表可用來檢查你現有的規則是否具體。它不是 Claude Code 的功能保證，而是將工作約定拆成你可以觀察的結果。

再用這份應用前檢查清單，找出規則裡仍可能有不同解讀的地方：

控制方式也要分清楚，否則容易期待錯誤：

按工作需要驗證，不要把指令當成防護牆

CLAUDE.md 是否有效，最終要看實際任務中的計畫、改動與驗證能否互相對照。若 AI 仍反覆越界，先檢查任務描述是否含糊、規則是否互相矛盾，再決定是否需要更嚴格的權限設定或 hooks；不要只是不斷加長指令。

如果你是在現有工作站或伺服器上執行 Claude Code，仍要考慮環境共用、操作範圍與復原流程。需要 macOS 專屬的開發或測試環境時，租用 Mac 可以避免為短期需求先購買設備；但若你需要長期穩定負載、實體介面，或必須自行管理固定設備，應先比較自購與租用的實際需求。你可以查看 Mac mini 租用方案及租用價格資訊，再按工作週期與環境要求選擇。

下一步可以先審閱你目前的 CLAUDE.md，再挑一個範圍明確的小任務，逐項檢查四條規則是否落實。無論用哪種執行環境，CLAUDE.md 都應與程式碼審查、版本控制及必要的權限控制搭配使用。

常見問題