别被 AI 的“Bug 已修复”给骗了，一套完整的回归验证流程才是关键

很多开发者在使用 AI 辅助编程时，最容易掉进的坑就是对 AI 结论的盲从。当 AI 给出一段补丁并自信地回复“Bug 已修复”时，这其实是一个极具误导性的信号。在实际工程经验中，AI 所谓的“修复”往往分为三种情况：第一种是真正的逻辑修正；第二种是掩耳盗铃，比如通过 try-catch 强行屏蔽了报错信息，让界面看起来不再崩溃，但底层逻辑依然失效；第三种则是“拆东墙补西墙”，解决了当前路径的报错，却在不经意间破坏了另一个模块的稳定性。

为了避免在生产环境踩坑，我建议将 AI 提供的所有修复方案视为一个“待验证的假设”，而非最终结论。要判断 Bug 是否真正消失，不能仅凭界面上不再弹出红字，而必须建立一套严谨的回归验证机制。

首先，在将问题交给 AI 之前，必须通过一份结构化的“证据清单”来定义 Bug。如果只是模糊地告诉 AI “保存功能坏了”，AI 很容易通过某种诡异的补丁将其糊弄过去。我目前采用的标准化描述结构如下：

1. 初始状态：明确当前必须满足的前提条件。
2. 操作步骤：详细记录触发 Bug 的具体动作序列。
3. 预期结果：定义用户在正常逻辑下应该看到什么。
4. 实际结果：客观描述当前发生了什么。
5. 关键证据：提供具体的报错文本、控制台 Log 或网络请求状态。

举个具体的实操例子：如果一个任务修改功能失效，我的输入会是：“初始状态：已登录且存在已保存任务；操作步骤：打开任务 → 修改标题 → 点击保存 → 刷新页面；预期结果：刷新后标题应为修改后的内容；实际结果：页面提示‘保存成功’，但刷新后仍为旧标题；证据：网络请求返回 200 OK，但数据库记录未更新。” 这种高精度的输入能强迫 AI 关注数据流的真实状态，而不是简单地去修补前端的提示语。

其次，在 AI 给出补丁后，必须强制执行四个维度的验证，绝不能直接合入代码。

第一是原路径复现。严格按照之前的证据清单跑一遍。这里有个细节：如果 AI 声称“现在无法复现了”，这绝不代表修好了。此时必须追问 AI 具体的修改逻辑，防止它通过删除触发条件（比如删掉了某个校验逻辑）来掩盖问题。

第二是底层状态核实。界面提示“保存成功”或“操作完成”是极具欺骗性的。验证者必须通过刷新页面、重新登录，甚至直接在数据库中执行 SELECT 查询，确认数据在持久层确实发生了变化。

第三是边界压力测试。尝试输入非法值、极长字符串或模拟断网环境。如果 AI 将所有的报错响应都改成了空的成功响应，那么它其实是在隐藏 Bug，而非修复 Bug。

最后是周边功能扫描。重点检查与改动点相关的相邻模块。很多时候 AI 修复了 A 模块的逻辑，却因为对上下文依赖理解不深，导致 B 模块在特定条件下崩溃。

这种验证流程虽然在单次修复上增加了时间成本，但它将 Bug 的拦截点提前到了开发阶段，远比在生产环境通过用户反馈来定位问题要高效得多。