直接回答:不要先抽样“看起来像”的页面,而要先构造一批“看起来不像”的反例样本——也就是那些表面上符合替换规则、但替换后会破坏语义、结构或意图的页面。只有当反例样本被识别并排除后,批量替换规则才具备规模化前提。
假设你准备把全站正文里的“下载”统一替换为“获取”。手工挑十个页面测试,十个都通顺,于是你认为规则成立。但推到全站后,出现三类例外:教程页里“下载配置文件”被替换成“获取配置文件”,动作对象变了;页面标题被替换后与正文首句重复;代码示例里的字符串被误伤。小样本没有暴露这些问题,不是因为样本太少,而是因为样本挑选方式偏向“典型页”,天然排除了边界页。
第一种解释是替换规则的范围定义过宽,没有限定替换位置,比如只在正文段落替换、跳过标题和代码块。第二种解释是规则没问题,但样本构造只覆盖了高频模板,漏掉了低频但语义敏感的区域。
区分这两种解释的证据不同:如果是规则太宽,那么在同一类页面内,只要替换位置不同,结果就会分化,例如正文替换正常、标题替换异常;如果是样本有偏,那么同一替换位置在不同页面类型上表现不一致,例如文章页正常、产品页异常。前者指向收窄替换范围,后者指向扩充反例样本集。
按这三个维度各挑五到十个页面,组成反例样本集。它不追求代表性,而追求“最可能出错”。
假设某站点有 200 个页面,规则是把正文中的“免费”替换为“无需付费”。先构造反例样本:包含“免费试用”“免费额度”“免费声明”的页面各三个。执行替换后检查发现,“免费试用”变成“无需付费试用”,语义尚可;“免费额度”变成“无需付费额度”,读起来别扭;“免费声明”变成“无需付费声明”,意思完全相反。此时不应继续扩大替换,而应先把“免费声明”这类固定搭配加入排除清单,再重新在反例样本上验证。这个动作的结果决定下一步:排除清单生效后,才考虑扩大替换范围。
把反例样本单独跑一遍替换,记录每个样本的替换结果和判断结论。如果所有反例样本都通过,说明当前规则在这批边界上成立,可以进入小范围灰度;如果出现失败,先修规则或加排除项,不要直接全量。这个动作的关键是:反例样本的通过与否,决定的是“规则能否扩大”,而不是“规则是否正确”。规则正确性由语义判断负责,规模化可行性由反例样本负责。
最后提醒:改动前后比较时,要考虑季节、搜索需求变化和数据采集差异,不能把一次替换后的数据波动直接归因于替换本身。反例样本的作用是提前暴露结构性风险,而不是预测效果。