你的 AI agent 老犯錯？問題不在 prompt，在配置文件
整理版優先睇
Claude.md 係操作系統唔係說明書：十條規則令 AI agent 少犯錯
呢篇文章係由重度AI研究愛好者竇竇分享嘅實戰經驗。佢發現好多人以為 claude.md 只係說明書，跑個 init 命令就算，但其實呢個文件係操作系統——寫得爛嘅話，你同 AI 就會一直打架。整體結論係：檔案寫得越精確，AI 就越少同你扯皮。
作者整合咗 Andrej Karpathy 公開 repo 同大量項目經驗，總結出 10 條實測有效嘅規則。包括強制 AI 先諗清楚先做、逼佢寫簡單代碼、手術式改動（每行改動都要追溯到用戶要求）、目標驅動執行（定義可驗證嘅成功標準）等等。呢啲規則嘅核心係減少 agent 嘅猜測同多餘動作。
另外，文章強調檔案要精簡（300行內），按優先級排序：硬規則放最前，參考信息放最後。仲要讓 agent 自己更新知識庫，每次糾正後將教訓寫入獨立文件，慢慢累積「唔應該做」嘅記憶。最終目標係令 AI agent 更聽話，減少無謂嘅糾正時間。
- claude.md 係操作系統唔係說明書；寫得差就會一直同 AI 打架。
- 強制 AI 先諗再寫：要佢列出假設俾你揀，唔好直接衝。
- 逼佢寫簡單代碼：200行搞得掂嘅事，重構到50行先算合格，唔準加功能。
- 手術式改動：每行改動都要可追溯，唔相關嘅嘢唔準鬱。
- 讓 agent 自己更新知識庫：每次糾正後寫入教訓，累積記憶減少重複錯誤。
Claude.md 係操作系統，唔係說明書
好多人都輕視咗 claude.md 嘅作用，以為跑個 init 命令就夠。
呢個文件係操作系統，唔係說明書
如果你寫得爛，你同 AI 就會一直打架。
核心規則：減少猜測同多餘動作
以下係四條實測有效嘅核心規則：
先諗再動手
簡單代碼標準
手術式改動
目標驅動執行
- 1 強制 Claude 喺寫 code 之前將假設列曬出嚟，俾你揀。呢一條可以砍掉大量來回糾正嘅時間。
- 2 設定硬標準：200行搞得掂嘅事，如果重構到50行先算正確，否則必須重寫。唔準加需求之外嘅功能。
- 3 每一行改動必須追溯到用戶要求；如果發現咗唔相關嘅問題，報告俾你，由你決定修唔修，唔可以擅自改。
- 4 每個任務都要定義可驗證嘅成功標準，例如加輸入校驗就要自己寫測試用例，跑通先算完成。UI 改動可以接瀏覽器 MCP 睇截圖判斷。
效率與安全：只寫差異、問準危險操作
除咗核心規則，仲有幾點提升效率同避免災難嘅指引：
只寫 Claude 唔知嘅工具
危險命令必須問你
用路徑作用域拆分規則
Monorepo 每個子目錄一個 claude.md
- init 生成嘅啟動命令 Claude 已經識，唔使寫。真正要寫嘅係你用嘅特殊工具，例如 GitHub CLI、pnpm 呢啲差異點。
- git push --force、rm -rf 呢啲不可逆操作，寫明要請求許可。唔確定就當有破壞性處理。
- 唔好將所有指令塞一個文件，按目錄分開，每個文件第一句聲明作用域。咁樣 Claude 做前端時就唔會被 API 規則幹擾。
- 全局文件放通用規則，子應用放自己嘅規則，避免文件太長分散注意力。
結構與維護：排序同自我更新
項目描述要放第一段，等 Claude 建立全局理解。
項目描述放最前面
成個文件按優先級排序：硬規則放最前，參考放最後，總行數唔好超過 300 行。
另外，叫 agent 自己更新知識庫：每次你糾正咗佢嘅做法，改完 code 之後，要佢將教訓寫入一個獨立文件。
讓 agent 自己更新知識庫
呢個 idea 來自 Claude Code 作者本人，可以慢慢累積「咩唔應該做」嘅記憶，降低下次犯同樣錯誤嘅機會。
總結：做一個精確嘅操作系統
操作系統越精確，AI 越少扯皮
AI 能做嘅嘢愈嚟愈多，但識得判斷邊條路值得行、將技術變成可用嘅嘢，呢啲先係 AI 時代真正值錢嘅能力。
claude.md 唔係說明書，而係操作系統。
喺我未意識到呢點之前，用 Claude Code 寫代碼就不停喺度同 AI 打架。
喺 Claude Code，呢個配置文件叫claude.md，其他工具叫 agents.md，個名唔重要。重要嘅係：呢個文件寫得差，你就會成日同 agent 打架。好多人以為行個 init 命令就夠——唔夠，差好遠。
下面係實測有效嘅 10 條規則，來源包括 Andrej Karpathy 嘅公開 repo 同大量實際項目經驗。
1. 強制佢先諗再鬱手
喺文件度加一句：叫 Claude 喺寫代碼之前，先將假設講清楚，如果有多種理解方式，全部列曬出嚟俾你揀。
Claude 會先問你一組問題，你嘅回答決定佢點做。佢唔再喺訓練數據度估一個「最常見嘅實現方式」然後直接衝，而係確認你想要嘅係邊種。
呢一條就可以慳返大量來回糾正嘅時間。
2. 逼佢寫簡單代碼
AI agent 天生就鍾意寫「大方案」。一個小問題佢都可以俾你搞出一大堆抽象層。呢個唔止係慢嘅問題——後面加功能、改 bug 都會俾呢啲冗餘代碼阻住。
解法係俾佢一個硬標準：如果 200 行搞得掂嘅事，可以重構到 50 行，即係話佢嘅方案由頭就錯，要重寫。
仲有一點：唔好加需求以外嘅功能，唔好「順手優化」。
3. 手術式改動
我見過最多嘅伏。你叫 Claude 修一個 bug，佢順手就將隔籬嘅代碼都「改進」咗——可能係格式化，可能係刪咗佢覺得冇用嘅代碼。
問題係：嗰啲代碼可能係你特登留低第時用嘅。
規則好簡單：每一行改動都一定要追溯到用戶嘅要求。追溯唔到？唔準掂。發現咗無關嘅問題？報告俾你，由你決定整唔整。
4. 目標驅動執行
Agent 唔知「正確嘅輸出」係點樣，呢個係根本問題。
解決方法：叫 Claude 對每個任務定義可以驗證嘅成功標準。例如你叫佢加輸入驗證，佢應該自己寫測試用例，覆蓋非法輸入，然後 run 曬所有 case 先算完成。
有個伏：呢個對邏輯功能好用，但 UI 改動冇辦法靠測試驗證。呢個時候可以接一個瀏覽器 MCP（例如 Puppeteer），叫 agent 自己睇頁面截圖嚟判斷效果。
5. 只寫 Claude 唔知嘅工具
init 生成嘅文件會話俾 Claude 知點樣啟動 dev server、點樣 build。但呢啲佢訓練數據入面已經有，寫咗等於浪費行數。
真正應該寫嘅係：你裝咗邊啲佢唔知嘅工具。例如你用 GitHub CLI 而唔係原生 git 指令，例如你個項目用 pnpm 而唔係 npm。只寫呢啲差異點。
6. 叫佢自己更新知識庫
claude.md 唔係寫一次就唔鬱嘅嘢。
加一條規則：如果你糾正咗 Claude 嘅實現方式，佢改完代碼之後，仲要將今次教訓寫入一個專門嘅文件。咁樣佢會慢慢累積「乜嘢唔應該做」嘅記憶，後面犯同樣錯誤嘅機會率會低啲。
呢個思路嚟自 Claude Code 嘅作者本人。
7. 危險指令一定要問你
git push --force、git reset --hard、rm -rf、分支合併——呢啲操作係不可逆。
喺文件度明確寫：執行任何不可逆指令之前一定要請求許可。如果唔肯定一個指令有冇破壞性，默認當作有破壞性嚟處理。
8. 用路徑作用域拆開規則
唔好將所有指令塞入一個文件。俾唔同目錄建立各自嘅規則文件，第一行聲明作用域。
例如 API 相關嘅規則只喺寫 API 時加載，唔會喺寫前端組件時幹擾 Claude 嘅注意力。喺主 claude.md 度註明呢啲文件嘅位置就得。
9. Monorepo 每個子目錄一個 claude.md
全局文件放通用規則，每個子應用放自己嘅具體規則。
將所有指令堆曬喺全局文件係錯嘅——文件膨脹之後，Claude 處理當前任務時會俾無關嘅規則分散注意力。
10. 項目描述放喺文件最前
呢一條決定咗後面所有指令嘅執行效果。
將項目描述放喺 claude.md 嘅第一段：呢個應用係做乜嘅，架構係點樣，依賴咗邊啲服務，點樣運行。Claude 讀到第一段就可以建立全局理解，而唔係先睇代碼再估。
更狠嘅係排序規則：硬規則（絕對唔可以違反嘅）放最前，中等優先級嘅放中間，參考資訊放最後。成個文件控制在 300 行以內——超過呢個數，agent 嘅表現會明顯變差。
仲有一個：叫 Claude 唔止「檢查功能存在」，而係用測試、lint、類型檢查等多種手段驗證功能真係行到，確認通過咗先可以報告任務完成。
操作系統寫得越精準，AI就越少同你拗。今日打開你嘅 claude.md，刪咗所有 init 生成嘅內容，只留低佢唔知嘅嘢。
end.
識得認清代碼入面嘅伏、識得判斷邊條路值得行、可以將技術變成可用嘅嘢——呢啲先係 AI 時代真正值錢嘅能力。
「AI Native 實戰」訂閲說明
適合邊個：
想持續瞭解 AI 工具、Claude / Codex / Agent 實戰更新嘅人
你可以得到：
1. 每星期篩一次值得睇嘅 AI 工具同更新
2. 遇到部署、揀選、使用問題可以直接問我
3. 幫你少啲踩伏，節省自己揾資料同試錯時間
價格：
體驗價 19.9 元 /年
訂閲方式：
加我微信 kbhero21 / 直接私信我
備註：AI Native
更加鍾意分享 我自己試過、踩過伏、最後覺得真係有用嘅嘢
關注我，一齊將複雜嘅 AI，變成普通人都用得上嘅日常。
claude.md 不是說明書，是操作系統。
在我沒有意識到這點之前，用 Claude Code寫代碼就是一直在跟 AI 打架。
在Claude Code，這個配置文件叫claude.md，其他工具叫 agents.md，名字不重要。重要的是：這個文件寫得爛，你就會一直和 agent 打架。很多人覺得跑個 init 命令就夠了——不夠，差得遠。
下面是實測有效的 10 條規則，來源包括 Andrej Karpathy 的公開 repo 和大量實際項目經驗。
1. 強制它先想再動手
在文件里加一句：讓 Claude 在寫代碼之前，先把假設說清楚，如果有多種理解方式，全部列出來讓你選。
Claude 會先問你一組問題，你的回答決定它怎麼做。它不再從訓練數據裏猜一個"最常見的實現方式"然後直接衝，而是確認你要的到底是哪種。
這一條就能砍掉大量來回糾正的時間。
2. 逼它寫簡單代碼
AI agent 天然喜歡寫"大方案"。一個小問題它能給你搞出一堆抽象層。這不只是慢的問題——後面加功能、改 bug 都會被這些冗餘代碼絆住。
解法是給它一個硬標準：如果 200 行能搞定的事，能重構到 50 行，那說明它的方案從頭就錯了，必須重寫。
還有一點：不要加需求之外的功能，不要"順手優化"。
3. 手術式改動
我見過最多的坑。你讓 Claude 修一個 bug，它順手把旁邊的代碼也"改進"了——可能是格式化，可能是刪了它覺得沒用的代碼。
問題是：那些代碼可能是你故意留着以後用的。
規則很簡單：每一行改動都必須能追溯到用戶的要求。追溯不到？不準碰。發現了不相關的問題？報告給你，由你決定要不要修。
4. 目標驅動執行
Agent 不知道"正確的輸出"長什麼樣，這是根本問題。
解決辦法：讓 Claude 對每個任務定義可驗證的成功標準。比如你讓它加輸入校驗，它應該自己寫測試用例，覆蓋非法輸入，然後跑通所有 case 才算完。
有個坑：這對邏輯功能好使，但 UI 改動沒法靠測試驗證。這時候可以接一個瀏覽器 MCP（比如 Puppeteer），讓 agent 自己看頁面截圖來判斷效果。
5. 只寫 Claude 不知道的工具
init 生成的文件會告訴 Claude 怎麼啓動 dev server、怎麼 build。但這些它訓練數據裏已經有了，寫了等於浪費行數。
真正該寫的是：你裝了哪些它不知道的工具。比如你用 GitHub CLI 而不是原生 git 命令，比如你的項目用 pnpm 而不是 npm。只寫這些差異點。
6. 讓它自己更新知識庫
claude.md 不是寫一次就不動的東西。
加一條規則：如果你糾正了 Claude 的實現方式，它改完代碼後，還要把這次教訓寫進一個專門的文件。這樣它會慢慢積累"什麼不該做"的記憶，後面犯同樣錯誤的概率會降下來。
這個思路來自 Claude Code 的作者本人。
7. 危險命令必須問你
git push --force、git reset --hard、rm -rf、分支合併——這些操作不可逆。
在文件裏明確寫：執行任何不可逆命令之前必須請求許可。如果不確定一個命令是否有破壞性，默認當作有破壞性來處理。
8. 用路徑作用域拆分規則
別把所有指令塞進一個文件。給不同目錄建各自的規則文件，第一行聲明作用域。
比如 API 相關的規則只在寫 API 時加載，不會在寫前端組件時干擾 Claude 的注意力。在主 claude.md 裏註明這些文件的位置就行。
9. Monorepo 每個子目錄一個 claude.md
全局文件放通用規則，每個子應用放自己的具體規則。
把所有指令堆在全局文件裏是錯的——文件膨脹後，Claude 處理當前任務時會被不相關的規則分散注意力。
10. 項目描述放在文件最前面
這一條決定了後面所有指令的執行效果。
把項目描述放在 claude.md 的第一段：這個應用是幹什麼的，架構是什麼樣的，依賴了哪些服務，怎麼運行。Claude 讀到第一段就能建立全局理解，而不是先看代碼再猜。
更狠的是排序規則：硬規則（絕對不能違反的）放最前，中等優先級的放中間，參考信息放最後。整個文件控制在 300 行以內——超過這個數，agent 的表現會明顯變差。
還有一個：讓 Claude 不只是"檢查功能存在"，而是用測試、lint、類型檢查等多種手段驗證功能真的能跑，確認通過了才能報告任務完成。
操作系統寫得越精確，AI就越少跟你扯皮。今天打開你的 claude.md，刪掉所有 init 生成的內容，只留它不知道的。
end.
能識別代碼裏的坑、能判斷哪條路值得走、能把技術變成可用的東西—這些才是 AI 時代真正值錢的能力。
「AI Native 實戰」訂閲說明
適合誰：
想持續瞭解 AI 工具、Claude / Codex / Agent 實戰更新的人
你能得到：
1. 每週篩一遍值得看的 AI 工具和更新
2. 遇到部署、選型、使用問題可直接問我
3. 幫你少踩坑，節省自己找資料和試錯時間
價格：
體驗價 19.9 元 /年
訂閲方式：
加我微信kbhero21 / 直接私信我
備註：AI Native
更喜歡分享 我自己試過、踩過坑、最後覺得真有用的東西
關注我，一起把複雜的 AI，過成普通人也能用上的日常。