智搜宝优化方法：批量替换文本前怎样构造反例样本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /819fa75b8e60.html
📄
智搜宝优化方法：批量替换文本前怎样构造反例样本
反例样本的目标不是证明替换规则正确，而是用少量故意“不该被替换”的文本，提前暴露边界条件。做法是：从真实内容中挑出与目标模式形似但语义不同的片段，连同替换前后对照一起跑一遍规则，凡是反例被改动的，就回到模式定义而不是继续扩大批量。
先明确反例要拦住的三种误伤
批量替换出错，通常不是规则没生效，而是生效范围过宽。构造反例前先想清楚要拦住什么，样本才有方向。
- 同形不同义：字面与目标词一致，但处在品牌名、专有名词或引用原文中，改动后语义被破坏。
- 跨边界匹配：目标模式跨越标签、标点或换行，替换后把相邻结构一起吞掉。
- 局部与全局冲突：某处需要替换，另一处形态相同却必须保留，单一全局规则无法同时满足。
把这三类各写成一条反例，比随机抽几十条正文更能定位问题。
用假设情境走一遍构造过程
以下情境为假设，仅用于说明比较方法，不代表任何真实项目结果。
假设某站点要把正文中旧产品名“星轨盒”统一改为“星轨盒Pro”，但页面里还存在“星轨盒Pro已上线”这类已经写对新名称的句子，以及“星轨盒Pro版对比”这种把旧名当词根使用的标题。如果直接全局替换“星轨盒”，新名称会被二次改写为“星轨盒ProPro”，词根标题也会被破坏。
此时反例样本至少包含三条：
- 已经写对的句子：“星轨盒Pro已上线”。期望结果：不变。
- 词根型标题：“星轨盒Pro版对比”。期望结果：不变或按单独规则处理。
- 引号内原文：“他说‘星轨盒’只是代号”。期望结果：不变。
把这三条与一条必须替换的普通正文放在同一份对照表中，先跑规则再逐条核对。若第1条被改成“星轨盒ProPro”，说明模式缺少“后面不能紧跟Pro”的约束；若第3条被改动，说明规则没有排除引号区间。每发现一处，就补充一条对应反例，而不是先修规则再补样本。
反例样本的挑选顺序
样本不必多，但要覆盖不同来源，避免全从同一类页面抽取。
- 先从替换范围里最“像”的片段找，即与目标模式共享前缀或后缀的词。
- 再从结构边界找，包括标题、列表项、链接锚文本和代码片段。
- 最后从必须保留的例外找，如引用、术语表、用户生成内容中的原话。
每类挑一到三条即可。样本过多会拖慢核对，样本过少则容易漏掉某一类边界。
执行动作与结果如何决定下一步
具体动作是：把反例样本、必须替换的正例、以及规则表达式放在同一份清单里，先在小范围副本上运行，逐条比对期望结果与实际结果。
结果分三种走向：
- 反例被改动：说明模式过宽，应回到模式定义收窄条件，再重跑同一批样本，不要直接进入全量替换。
- 正例未被替换：说明模式过窄，需检查是否被转义、大小写或标点差异挡住，补充对应正例后重跑。
- 全部符合期望：可以把这批样本固化为回归清单，后续每次调整规则都重跑一遍，再考虑扩大范围。
这个顺序的意义在于：先让规则在已知边界上稳定，再让它接触未知内容。反过来做，等于用未验证的规则去改动大量页面。
比较前后差异时要排除的干扰
替换完成后对比数据，不能只看单次变化就下结论。搜索需求本身会随季节波动，采集时间不同也会带来差异，这些都可能让一次改动看起来有效或无效。比较时应尽量固定采集口径和时间窗口，并把替换范围外的页面作为参照，而不是把任何变化都归因于这次文本替换。
反例样本解决的是“规则会不会误伤”的问题，不解决“改完是否更好”的问题。两者要分开验证，前者在替换前完成，后者在替换后用可对照的方式观察。
