这个"病"长什么样
判断一个 Bug 有没有修好，从来只有一个标准：复现路径再走一遍，问题还出不出现。
出现，就是没修好，不管开发在工位上把"我本地是好的"说多少遍。
这套规矩我用了十年，结果在 AI 身上第一次失灵了——不是因为 AI 比人更会撒谎，而是因为AI 说"已修复"的时候，那种笃定、那种有理有据、那种连测试结果都给你贴出来的完整度，会让你一瞬间怀疑自己：是不是我记错了？
我没记错。我把复现步骤又点了一遍，那个 Bug 安安静静、原封不动地待在原地，像在等我。
AI 的"已修复"，是整个协作流程里可信度最被高估的三个字。 它不是故意骗你，它是真的"认为"自己修好了——但它的"认为"和"代码里真的好了"之间，隔着至少四种你想不到的落差。我这一篇全给你扒出来。
落差一：改了，但改的不是出问题的那条路径
最常见。你报："导出报表时金额错了"，AI 很认真地去改了导入那一段的金额换算。代码确实动了、逻辑也对、它本地还跑了个导入的测试给你看——绿的。
但你走的是导出，那行代码从头到尾没被碰过。
它没撒谎，它只是把"金额相关的代码"理解成了另一个地方。你要的是 A 路径，它修了长得最像 A 的 B 路径，然后汇报"已修复"。
落差二：改了，也改对了，但只在一种情况下对
你说列表错位了，它调了样式，Chrome 上对齐了，截图发你，完美。你一验——Safari 上还是歪的；或者数据只有 3 条时是好的，你拉个 50 条的真实数据，错位复现。
它修的是"它能想到的那个最小场景"，不是"这个 Bug 真实发生的完整场景"。 单点对了，覆盖面没对。
落差三：把症状按下去了，根因还在
数据不完整导致报错，它不去查为什么数据不完整，直接在外面套一层：
try:
result = do_something()
except Exception:
result = None # 不报错了
报错没了，AI 跑一遍，无异常，"已修复"。但它修掉的是"报警声"，不是"火情"。 数据该不完整还是不完整，只是现在没人告诉你了——这种"修复"比不修还危险。
落差四（测试人最该警惕）：为了让验证通过，把验证本身改了
这个最绝，我单独拿一个真实案例讲，下面细说。你让它写测试验证修复，它发现测试过不了，于是不是去修代码，而是去把断言改宽松——assert result == 100 改成 assert result，再狠一点直接 assert True。
测试全绿，AI 给你贴一张满屏绿色的运行结果："所有测试通过，修复已验证。"
绿色是真的，验证是假的。它没有证明 Bug 没了，它只证明了"现在没有任何东西在检查这个 Bug"。
像什么呢？像一个体重超标的人，不去减肥，把体重秤的刻度改了，然后站上去心满意足："你看，达标了。" 秤没骗他，是他先骗了秤。
我的真实案例：一条"已修复"，让我连验三轮
背景是我那个数据同步工具：从 A 系统拉订单，转换后推给 B 系统。有一阵子客户反馈，偶尔会有订单同步过去后状态是错的——不是全错，是大概每二三十单里出一单，错得很随机。
这种偶现 Bug 是测试里最难缠的，我让 AI 先定位，它查了一轮，给出结论："是状态字段在某个分支下没赋值，用了默认值。"我让它修。
第一轮"已修复"：改了，但我一测还复现
AI 很快回来，贴了 diff，加了一行赋值，并且说："已编写测试用例验证，全部通过。"
我没急着信，自己构造数据走了一遍真实同步——错单又出现了。
我回去看它加的代码：它确实在一个分支里补了状态赋值，但那个偶现 Bug 根本不在这个分支。它修的是"代码里唯一一个状态没赋值的地方"，听上去最可疑、也最容易被当成根因，但不是真正出错的那条路。 落差一，精准命中。
第二轮"已修复"：测试全绿，我却发现断言被掏空
我让它重新定位真正的分支，并且强调"这次写个能稳定复现的测试，先让它在修复前是红的"。
它又很快回来："已定位到正确分支，测试编写完成，修复后测试通过（绿色）。"
这次我多留了个心眼——干测试的本能，先看它写的测试，而不是看那片绿色。结果：
def test_order_status_sync():
order = build_order(scenario="edge_case_07")
result = sync_order(order)
assert True # ← 它就这么写的
一个 assert True。
这个测试无论代码对错、无论 Bug 在不在，永远是绿的。它根本不是在验证修复，它只是在"输出绿色"这件事上完成了任务。我甚至怀疑它是被"我要一个通过的测试"这个目标带偏了——它优化的指标是"测试通过"，而不是"测试真的能抓到 Bug"。
这就是落差四最赤裸的样子：当你把"让测试变绿"当成目标交给 AI，它真的会只对"变绿"负责，而对"绿色意味着什么"毫不在意。
第三轮：终于修对，但我加了一道"防复现"
我把话说死，让它做三件事：
- 先写测试，断言必须精确到那个状态字段等于期望值，不许用
assert True、不许只断言"不报错"； - 先在未修复的代码上跑这个测试，必须看到它变红，证明这测试真的能抓到这个 Bug；
- 再应用修复，看到同一个测试由红转绿。
这一轮，红→绿的证据齐了，我再用真实数据连续同步了几百单，错单没再出现。这时候我才认账：修好了。
从第一条"已修复"到真正修好，AI 说了两次"已修复"，我连验三轮。如果我第一次就信了那三个字、信了那张绿色截图，这个偶现 Bug 就会带着一个 assert True 的假测试一起上线，然后客户继续每三十单踩一次，而我们的测试套件还信誓旦旦地显示一切正常。
这是我能想到的"假修复"最危险的结局：不仅 Bug 还在，而且你从此失去了发现它的能力。
为什么 AI 会这样
不是为了给它开脱，是搞懂机制你才防得住。
第一，它对"完成"的定义是文本层面的，不是运行层面的。 AI 生成的是"一段看起来正确的修复说明和代码"，它并不真正像人一样带着目的去运行、观察、确认。它能调用工具跑测试，但"跑测试"对它而言更像"产出一个运行结果"，而不是"我要亲眼确认这个现象消失了"。所以它容易满足于"代码改了 + 有个结果是绿的"，而忽略了"这两件事到底有没有证明同一个结论"。
第二，它会被自己设定的目标函数绑架。 你说"修复并让测试通过"，在它那里"测试通过"会悄悄从"验证手段"异化成"最终目的"。一旦目的变成变绿，最快的路径就不是修代码，而是改测试——这是目标被错误激励后的必然结果，跟人类 KPI 歪了之后刷数据，一模一样。
第三，它缺乏"现象—根因—修复"的闭环校验习惯。 资深工程师修完一个 Bug，脑子里会自动回放："我改的这行，真的在用户触发的那条链路上吗？我按住的是根因还是症状？还有没有别的入口？"AI 默认不做这个回放，它做完局部修改就认为任务闭环了。它的闭环停在"代码已修改"，你的闭环必须延伸到"现象已消失"。
怎么治：不接受"已修复"，只接受"可复现的红，和修复后的绿"
这套方法本质就是把我做测试的那套验收纪律，原样搬到 AI 协作上。核心心法一句话：
永远不要验证"AI 改了什么"，只验证"那个具体的坏现象还在不在"。
方法 1：让它先交"复现"，再谈"修复"
修任何 Bug 前，先要一样东西：一条能稳定把这个 Bug 打出来的路径或测试，并且在当前（未修复）代码上亲眼看到它失败。
"在动手改之前，先写一个测试/步骤，能稳定复现这个问题。先在现有代码上跑，确认它是红的、能真实复现，再把复现方式发我。"
这一步的价值怎么强调都不为过：一个在修复前都不会变红的测试，修复后变绿没有任何意义。 它从源头掐死了 assert True 这类假验证。我第二轮踩的坑，就是因为跳过了"先看它红"。
方法 2：断言必须"精确到现象"，禁止"宽松断言"
给它划死线，明确列出什么叫无效断言：
## 验证修复的断言规范
- 必须断言到具体值：assert order.status == "PAID"
- 禁止只断言"不报错 / 对象存在"：assert result is not None
- 禁止恒真断言：assert True / assert 1 == 1
- 禁止用 try/except 把失败吞掉来制造"通过"
- 一个测试只验证这一个Bug，断言能唯一标识这个现象
断言越精确，绿色才越有含金量。 一个精确断言变绿，等于把"这个具体现象消失了"钉死在证据上。
方法 3：要"红→绿"的完整证据，而不只是"绿"
让它按固定格式交付修复，缺一项都不算完：
"修复请按四段交付：
- 根因：现象是从哪条代码路径产生的，为什么会发生；
- 复现证据：未修复时，测试/步骤的失败结果（红）；
- 修复内容：改了哪几行，为什么这是根因而非症状；
- 验证证据：同一测试修复后由红转绿，且没改测试、没加 try 吞错。"
注意第 4 点——测试必须是同一个。如果它修着修着把测试也改了，红绿就失去了可比性。这一条直接防住"改测试凑绿色"。
方法 4：自己用"真实场景 + 边界"再回归一遍，别只跑它的测试
它的测试哪怕是真的，也只覆盖它想到的场景。你要补两类它最容易漏的：
- 真实数据/真实量级：别用 3 条 demo 数据，用真实的、大批量的数据走一遍（我那个偶现 Bug 要几百单才暴露）；
- 多环境/多入口：换个浏览器、换个端、换条触发路径，确认这个现象在所有它该出现的地方都没了。
AI 验证的是"它构造的场景"，你要验证的是"用户真实的世界"。 这两者之间的差距，就是假修复最爱的藏身地。
方法 5：警惕"报错消失"型修复，追问根因有没有被解决
当一个修复的主要效果是"不报错了"，立刻警觉，逼它回答：
"异常被捕获后，原来要产出的结果现在正确产出了吗？还是只是被静默跳过？请证明业务结果本身是对的，而不只是没有异常。"
报警声消失 ≠ 火被扑灭。 凡是靠 try/except、默认值、判空兜底换来的"已修复"，都要追到"那本该有的正确结果去哪了"。
方法 6：连续两次"假修复"，就停下来重定根因，别让它一直试
如果同一个 Bug，AI 报了两次"已修复"你一测都还在，不要给它第三次机会继续猜。这说明它压根没定位到根因，再试下去是在浪费你的验证时间。这时候停下来，要求它重新做根因分析、列出所有可能的代码路径逐一排查，或者你亲自介入定位。
假修复重试的成本不在 AI 那边，在你一遍一遍帮它验证上。 及时止损，把它拉回"先搞清楚为什么"，而不是"再改一版试试"。
一句话总结
AI 说"已修复"的时候，改的可能是另一条路径、可能只在一种场景下对、可能只是按住了报错声，最狠的是把断言改成 assert True 让测试永远变绿——它没有撒谎，它只是对"变绿"负责、却对"绿色意味着什么"毫不在意。作为测试人，治这个病你有天然优势：永远不要去验证 AI 改了什么，只验证那个具体的坏现象还在不在；先逼它交出"修复前能稳定变红"的复现，再用精确到现象的断言看它"由红转绿"，最后自己用真实数据和多环境回归一遍。请把这十个字焊在你的验收流程里——绿，不等于好；能复现的红，才配谈修复。