AI修Bug是真修复还是在掩耳盗铃？

很多时候AI回复一句“Bug已修复”，其实最坑人的地方就在这。因为它所谓的“修复”可能只是把报错信息给屏蔽了，或者绕过了报错路径，甚至是以牺牲另一个功能的稳定性为代价。

我现在养成了个习惯：把AI给的修复方案当成一个“待验证的假设”，而不是结论。

要判断Bug是否真的消失，不能只看界面上是不是不报错了，得走一套简单的回归验证流程。分享一下我总结的实操指南，尤其是怎么给AI喂信息，能极大提高修复成功率。

一、在改代码前，先写一份“证据清单”

直接告诉AI“保存功能坏了”太模糊，很容易被它用某种诡异的补丁给糊弄过去。我会用下面这个结构记录 Bug，然后发给它：

初始状态：[当前必须满足的条件]
操作步骤：
1. [具体动作]
2. [具体动作]
预期结果：[用户应该看到什么]
实际结果：[实际发生了什么]
证据：[报错文本、控制台日志或截图描述]

举个例子：

初始状态：已登录，且有一个已保存的任务。
操作步骤：打开任务 -> 修改标题 -> 点击保存 -> 刷新页面。
预期结果：刷新后标题应为修改后的内容。
实际结果：页面提示“保存成功”，但刷新后还是旧标题。
证据：网络请求返回200，但数据库记录未更新。

二、验证修复的四个维度

当AI给出补丁后，我绝对不会直接合入代码，而是强制执行这四项检查：

• 原路径复现： 严格按照上面的步骤跑一遍。如果AI说“现在无法复现了”，这不代表修好了，得问清楚为什么无法复现，防止它只是把触发条件给删了。
• 底层状态核实： 界面提示“保存成功”是会骗人的。必须通过刷新页面、重新登录或直接查数据库，确认数据确实在底层发生了变化。
• 边界压力测试： 尝试输入非法值或断网，看看它是否依然能正确报错。如果AI把所有的报错都变成了空的成功响应，那它其实是在隐藏 Bug。
• 周边功能扫描： 重点检查与该改动相关的相邻模块。很多时候 AI 修复了 A 屏，却在不经意间搞崩了 B 屏。

这种验证方式虽然慢一点，但比在生产环境踩坑要高效得多。