AI助手修的是报错，不是病根——同一个问题会换个地方再犯

AI助手优化的是回答“如何停止报错”，而非“系统为何产生此状态”

给定一个堆栈跟踪，AI 助手在局部范围内最合理的回应，就是给出一个让特定崩溃行不再崩溃的修复。这是对一个真实问题的真实、站得住脚的答案。但它和“为什么我的系统中会存在这种状态”是两个不同的问题——第二个问题通常需要查看错误信息从未指向过的代码，也就是距离崩溃实际发生地点好几个文件之外的上游逻辑。

这会产生一种特定且可辨识的失败模式：同一个根本问题在不同的地方被“修复”多次。因为每次修复都确实正确解决了它被展示的那一个调用点，却没有触及那个真正持续制造这种状态、并在它可到达的所有地方不断复现的条件。每个修复都有效，却没有一个能解决让所有修复都有必要存在的那件事。

这算不上对工具的批评——它只是在尽可能高效地完成实际交给它的任务：阻止这个特定的失败。差距之所以存在，是因为“停止这个错误”和“修复这个 bug”被当成同一个请求来对待，而它们往往不是。一个把前者回答得很好的助手，表面上看就像是也回答了后者。判别方法是问：如果输入以某种仍然合理的方式略微变化，这个修复是否依然成立？还是说它只是把同样的失败转移到了修复没有关注的地方？

高票评论（帖子共 6 条讨论）

[+2] u/ConventionalScissors：这就是为什么代码审查比最初的修复重要得多。AI 会修补症状，因为你交给它的就是症状；但人类必须坐下来问：不变量最初为什么被破坏？“如果 x 变了，这个修复还成立吗”这个测试就是全部工作。

[+2] u/alaattincagil：烦人的地方在于，错误消失是如此有说服力的成功信号😄 分析领域也有同样的陷阱：如果转化事件触发了两次，滤除其中一个可以让仪表盘看起来正确，但重复触发的根源还在原地。我希望助手在改动任何东西之前，先解释有什么证据能把它的推断原因与其他替代可能区分开来。然后再测试修复是否真的阻止了坏状态，而不仅仅是隐藏了它最显眼的症状。更干净的输出作为“修好了”的定义，实在太弱了。错误消失会让人觉得很有说服力，即使原因还在那里😄 分析领域也有同样的陷阱：如果转化事件触发了两次，滤除其中一个可以让仪表盘看起来正确，但重复触发的根源还在原地。我希望助手在改动任何东西之前，先解释有什么证据能把它的推断原因与其他替代可能区分开来。然后再测试修复是否真的阻止了坏状态，而不仅仅是隐藏了它最显眼的症状。更干净的输出作为“修好了”的定义，实在太弱了。

[+1] u/FlightSimCentralYT：是的，这就是经典的循环。模型在调用点修补症状，因为堆栈跟踪指向那里，然后同样的坏状态又出现在别处。

真正有用的是迫使智能体复现失败、检查上游状态，并且在真实测试覆盖这个 bug 之前不要停下来。那些只是重写文件的沙盒演示永远走不到那一步。

我建了 Fixa.dev 正是为了填补这个空白。它运行在真实的云虚拟机上，所以它可以深入仓库、运行应用、读取日志，并持续迭代直到测试通过，而不是再交给你一个本地补丁。

[+1] u/Blando-Cartesian：我离开编程有一阵子了，但以前非常在意让无效状态不可表示，或者在出错时尽快崩溃。

模型最终生成的修复，会不会是那种悄悄吞掉错误的类型？比如检查空指针，然后添加一段让进程继续运行的代码，却从不解决为什么会出现意外的空指针。

[+1] u/ceyhunkarslan：大多数助手优化的是下一个命令，而不是导致命令的系统状态。
只有先强迫模型梳理输入、输出和不变量，你才能得到根本原因。
你是先让它解释状态，再让它打补丁吗？

[+1] u/EightyNineMillion：会发生这种情况是因为堆栈跟踪对 AI 来说信息不够。它需要更多上下文，就像人类一样。