防止 AI 越改越乱：Claude Code 的 3 层约束机制 + 2 类验收点 + 1 键回滚实操

1. 问题结论先行：大多数人用 Claude Code 改代码，改到第三轮就失控了

我上周在重构一个 12 万行的 Java 微服务模块时，让 Claude Code 基于同一份 PRD 连续做了 7 次“优化”——第一次加了 Builder 模式，第二次抽离了 Validation 逻辑，第三次把 DTO 转换塞进了 Controller 层，第四次突然把所有Optional全删了，第五次开始往 Service 方法里硬塞日志埋点……第七次提交里，它把一个核心幂等校验的if (idempotentKey != null)改成了if (!idempotentKey.isEmpty())，而这个字段是 UUID 字符串，根本不可能为空字符串。CI 直接挂掉，线上灰度流量出现重复扣款。

这不是模型变蠢了。是我在第 4 轮之后，彻底放弃了对上下文的主动管理，把它当成了“会写代码的实习生”，而不是“需要被约束的协作者”。

Claude Code 的默认行为模式，天然倾向渐进式发散：它不记得自己上一轮改了什么，只看到你当前给它的 prompt 和当前文件快照。没有显式约束，它就会像没装刹车的推土机——越推越深，越改越偏。

这篇文章不讲怎么让它“更聪明”，只讲三件事：
- 怎么用3 层硬性约束把它的修改框死在安全区；
- 怎么设置2 类验收点，让它每改一步都必须“交卷”；
- 怎么实现1 键回滚，不是靠 Git log 手动找 commit，而是改错后 0.8