阻止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頁的實地手冊（付費）涵蓋審批門、鈎子、終止開關、技能管理、成本控制等。投稿歡迎提供經過真實代碼庫驗證的規則。