当防护栏尖叫时：先分诊，再修

防护栏只有在你好好回应时才有用，而失败模式是可预料的：构建变红了，你有点慌，然后把报错贴给 AI，附上"修一下"。有时这管用。但更多时候，它会造出一个修复——让红字消失，却没有处理真正出错的地方：AI 把测试削弱了、把类型放宽了，或者把那个失败的调用包进一个会吞掉问题的 try/catch 里。

在你放任它去"修"任何东西之前，花十秒做个分诊。防护栏的失败其实只有三类：

• 一个你刚刚引入的真 bug。 检查正在尽职。去修代码，而不是修检查。
• 一个现在已经过时的测试。 你是故意改了行为，旧的断言不再匹配了。把测试更新为断言新的正确行为——是经过深思的，而不是条件反射式的。
• 一个不稳定或本身就错的检查。 真的很罕见。在这里要怀疑你自己；这正是人们用来倾倒真 bug 的那个桶，因为它是唯一一个能让你蒙混过关、继续往前走的桶。

那条能让 AI 保持诚实的指令，是逼它在改任何东西之前先做诊断：

"never discounts below zero" 这个测试失败了。
首先，告诉我它为什么失败——代码现在做了什么，对比
测试期望什么。然后告诉我哪个才是对的：代码，还是测试。
在我确认之前，什么都别改。

那一次停顿，就是"一个保护你的防护栏"和"一个被你悄悄训练 AI 去攻克的防护栏"之间的区别。一个红色的检查是信息；你能做的最糟的事，就是在没读懂它想告诉你什么之前，就花代价把它弄绿。