它说「已修复」，我只认这 4 个证据

「已修复」通常只说明页面不那么难看了

后台文章列表加了分类筛选之后，同一篇文章出现两行。我把现象交给模型，它回了一句已修复，改动是查询里加了 DISTINCT。刷新之后，重复真的没了。

这不是修复。分类和文章是一对多之外又多了一张关联，连接条件少写了一截，一行文章配上两条分类关系就变两行。DISTINCT 把多出来的那行藏起来了。列表好看了，旁边的计数接口还在数连接之后的行，于是页面写着 20 条，角标写着 27。

我现在只收四个证据

1. 同一组参数还能复现旧问题。把当时的分类编号、页码、排序原样再请求一次。修复前能稳定出现两行，修复后这组参数只剩一行。不能复现的问题，模型只会给你一个看起来相关的改动。
2. 只撤回那一处，问题会回来。我把 DISTINCT 留下、连接条件改回去，重复立刻出现。再把连接条件改对、DISTINCT 拿掉，重复消失，计数也和列表一致。这样才知道是哪一行在起作用。
3. 原来正确的邻居还是正确的。不带分类筛选的第一页、空分类、只有一篇文章的分类，这三组以前就是对的。修完要再点一遍。修列表把计数修坏，不算修完。
4. 日志里该出现的那条只出现一次。这次我让查询在调试日志里打出最终 SQL。修复前能看到连接条件里缺了文章编号，修复后每篇文章只连接一次。没有这条日志，就只能相信刷新之后的眼睛。

模型很会把症状处理掉

重复、报错、空白、超时，它都有一套最常见的挡法：去重、加空判断、加 try、把超时调大。这些改动经常让演示通过。它们也会把真正的原因留在下一张表、下一个接口里。

下次它说已修复，把这四样要过来再合。少一样，就还是一份演示。