修没修好不看你改了多少，看复检的数字

体检报告放在桌上之后，真正的难题才刚开始。报告上写着七项异常、健康分四十一分、等级 D，这是某企业交换机故障诊断助手的首次体检结论。面对一份报告通常有两种反应：一种是「既然都查出来了，一次都改了吧」；另一种是「先别动」，系统现在好歹能用。两种都能理解，但都不是好的起点——一起改，改完你说不清是哪一项起了作用；而不动，问题不会自己消失，尤其是数据安全和链路类的，拖着只会更贵。第三条路是：按病灶逐项修，每一项独立验收。

为什么不能一把梭？三个理由。单变量原则——一次只改一个病灶，改完复测，这一项的因果关系才成立；依赖序——数据层修复必须排在应用层调优前面，残片没清干净就去调检索参数，调出来的是脏数据的最优；每项独立验收——全部改完再来一次大验收，一旦不过，你面对的是「七项修改加一个失败结论」，排查范围又回到原点。

动手前必须先做一件事：改前快照。因为判断修好了没有，靠的是同口径的前后对比——没有基线，就没有「变好了」这个结论，你只能说感觉快了。然后是门禁：修好了是一个形容词，而形容词不能验收。每类病灶都要提前定出能跑出来、能看数字的判据。备份类要三条同时成立（任务在实际执行、真的做过一次恢复演练、异地有副本），因为「有备份文件」和「备份能恢复」是两件事；用户感知类要构造异常场景，看用户实际收到什么——应该是「服务暂不可用，请重试」，而不是「不在服务范围内」；知识库残片类看三个数字：围栏未配对为零、超上限块数为零、破碎占比低于百分之一。

一个真实案例很说明问题：知识库一千四百零一个段落里三百四十一个是碎的。第一反应是把分段上限调大，但库里存在两万两千零三十四个字符的超长结构块，而真实生效的上限只有八百个 token——差了近三十倍。问题不在参数，在尺寸契约不匹配：不是让分段器适应内容，是让内容先符合分段器的契约。

最后一环是复检：同一套问题集、同一套口径再跑一遍，跟首次体检的基线做前后对比。这张表有一条必须坚持的纪律——还没实测的项就写「待复跑」，绝不写预期达标，因为方案和实测之间隔着一次真实执行。本讲是「验收、体检与修复」系列第三讲（收官）：三讲各守一件事，验收守敢上线、体检守说得准、修复守修到位。