网页提速方法：批量替换文本前怎样构造反例样本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4b278d956a29.html
📄
网页提速方法：批量替换文本前怎样构造反例样本
核心做法是：在批量替换前，先构造一组“应该保持不变”的反例样本，用它们检验替换规则是否误伤不该改的内容。反例样本的价值不在于证明规则正确，而在于暴露规则的边界。如果多个角色对“哪些文本该被替换”理解不一致，反例样本能把分歧变成可逐条核对的清单。
先明确两种条件：规则边界清晰 vs 规则边界模糊
是否值得花时间构造反例样本，取决于替换规则的边界是否清晰。两种条件对应不同选择。
条件一：替换目标有唯一标识。例如只替换某个固定模板中带特定类名的文本，其他位置一律不动。此时反例样本可以很少，重点放在“同名字但不该改”的位置上，通常几条即可。
条件二：替换目标靠语义或上下文判断。例如替换所有指向旧路径的链接文字、统一某类表述。此时边界模糊，必须扩大反例样本，覆盖同词不同义、同结构不同用途的位置。
判断依据很简单：如果两个角色对“这条要不要替换”能给出不同答案，就属于条件二，反例样本必须覆盖这个分歧点。
反例样本要覆盖哪几类“不该动”的内容
构造反例样本时，按以下类别收集，每类至少保留一条真实片段作为核对基准。
- 同形不同义：文本字面相同，但语义或用途不同，替换后会改变含义。
- 结构相似但层级不同：嵌套结构里外层和内层都含目标文本，只应改其中一层。
- 已特殊处理的位置：已被单独标记、单独维护或属于例外清单的片段。
- 边界字符：目标文本前后紧邻标点、空格或标签，替换后可能粘连或断句。
- 大小写与变体：同一表述的不同写法，规则是否应一并覆盖，需要事先约定。
每类样本都注明“期望结果”：保持不变，或按规则替换。期望结果由提出规则的人确认，而不是由执行替换的人单方面决定。
把分歧转成可核对项目的具体动作
当多个角色对同一事实理解不同时，不要继续讨论，而是把分歧写成条目。动作如下：
- 列出所有存在分歧的文本片段，每条只写原文和位置，不写结论。
- 让每个角色分别标注“应替换”或“应保留”，并写一句理由。
- 把标注不一致的条目单独抽出，作为必须优先覆盖的反例样本。
- 用这些样本先跑一次替换，只观察它们的变化，不检查其他内容。
这个动作的结果决定下一步：如果分歧条目在试跑后仍无法达成一致，说明规则本身需要拆分，而不是继续扩大替换范围。如果分歧条目全部通过，才可以把规则应用到更大范围。
一个注明假设的短例子
假设某页面有多处“查看详情”链接，其中一部分指向产品页，另一部分指向帮助文档。若规则是“把所有‘查看详情’改为‘了解更多’”，反例样本应至少包含一条指向帮助文档的链接。
试跑后可能出现两种结果。第一种：帮助文档链接也被替换，说明规则没有区分链接目标，需要先按目标路径拆分规则。第二种：只有产品页链接被替换，说明规则边界有效，可以继续扩大范围。这里的关键不是替换本身，而是反例样本提前暴露了“同词不同目标”这一分歧。
例外与适用条件
反例样本不能替代完整回归检查。它只覆盖已知分歧点，无法发现无人预料到的情况。因此，在规则边界清晰、改动范围极小时，可以用少量反例样本加快流程；在规则边界模糊、涉及多个角色时，反例样本必须配合小范围试跑和改动前后对照。
比较改动前后效果时，要考虑季节、搜索需求变化和数据采集差异，不能把某次统计波动直接归因于替换动作。反例样本的作用是判断规则是否误伤，而不是判断提速是否见效。两者要分开核对，否则容易把“没改错”误当成“改得有效”。
