阻止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页的实地手册（付费）涵盖审批门、钩子、终止开关、技能管理、成本控制等。投稿欢迎提供经过真实代码库验证的规则。