阻止AI編碼代理破壞已有程式碼的規則

AI編碼代理（如Claude Code、Cursor和Codex）在專案初期可能表現出色，但隨著程式碼庫規模增長，它們常常在修復一個問題時引入了另一個問題。這並非技能缺陷，而是結構性問題——僅靠更精準的提示無法解決，需要明確的約束。

最直接的一步是在專案根目錄建立CLAUDE.md檔案（Cursor對應.cursorrules，Codex/Copilot對應AGENTS.md），並貼上以下內容：

• 專案一句話描述
• 當前狀態（什麼已工作，什麼尚未工作）
• 禁止修改的檔案/資料夾及原因
• 具體規則：不修改未要求修改的檔案；不被要求時不做重構；不確定時說“我不知道”；不驗證就不報告完成。

文中特別強調“禁止”比“請”更有效。例如，“寫乾淨的程式碼”沒有明確閾值，而“不要修改我沒有要求修改的檔案”邊界清晰、立竿見影。

五條防止破壞的提示：

1. 修改前先獲取計劃：讓AI先說出將接觸哪些檔案以及風險點。
2. 擔心破壞時：詢問哪些其他功能會受影響。
3. 收到“完成”宣告時：要求編寫測試並展示透過結果。
4. 開始新會話前：總結已完成、下一步和已放棄的方案，避免重複嘗試失敗的方法。
5. 規則檔案中最重要的一條：“不要修改我沒有要求你修改的檔案”。

此外，隨著會話增長，上下文會退化。建議每3-5個任務開始新會話，並在關閉前執行第4條提示。如果同一問題要求三次，應更換會話而非繼續施壓。

可逆性至關重要：使用git或簡單的狀態儲存/恢復命令。建立許可權分級：允許閱讀、搜尋、分析和本地編輯，但對部署、傳送郵件、支付等操作要求確認。在規則檔案中設定“STOP.txt”檔案作為緊急停止開關。

每次AI犯錯時，將相關句子追加到規則檔案中。預先想象的規則多數無用，從實際故障中提取的規則才有效。已知陷阱示例包括：stock deduction在事務外、測試檔案誤觸等。

總結要點：將解釋儲存在CLAUDE.md中；先計劃後編碼；儲存狀態以便回滾；構建者不能給自己評分；只限制不可逆操作；“完成”意味著證據而非宣告。立即建立CLAUDE.md檔案即可改變明天的工作方式。

如需更深入的內容，有一本25頁的實地手冊（付費）涵蓋審批門、鉤子、終止開關、技能管理、成本控制等。投稿歡迎提供經過真實程式碼庫驗證的規則。