如何建立自己的博客：批量替换文本前怎样构造反例样本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /19056cde6d04.html
📄
如何建立自己的博客：批量替换文本前怎样构造反例样本
构造反例样本的目标，是在执行批量替换之前，先找到那些“看起来该被替换、实际上不该动”的字符串，把它们固定成一份可核对的清单。做法不是凭印象列几个词，而是从待替换文本的上下文出发，为每类反例指定一条能判定的规则，再拿这条规则去扫全站内容，看它能否把正例和反例分开。分开不了，说明规则还不够细，此时不应开始替换。
先看一个矛盾现象：同一批文本，两个人读出的“该换”范围不同
假设博客里要统一某个称呼或术语，一个人认为凡是出现旧写法的位置都应替换，另一个人指出其中一部分位置替换后会改变原意。两人看的是同一批文章，分歧却落在“哪些出现算同一类”上。这个矛盾本身不是谁粗心，而是替换规则没有把上下文条件写清楚。
常见的原因是旧写法在不同语境里承担了不同功能：有时它是正文里的普通表述，有时它出现在代码块、引用原文、图片替代文本或链接文字中。只按字符串匹配，会把这几类一起命中；只按段落位置排除，又会漏掉正文里真正需要改的地方。
两种解释，以及能区分它们的证据
第一种解释：分歧来自样本覆盖不足，只要多抽几篇文章就能达成一致。第二种解释：分歧来自判定标准不同，抽样再多也会各说各话。区分这两种解释的证据不一样。
- 如果是覆盖不足，那么把抽样范围扩大到包含代码块、引用、列表和标题的文章后，双方对同一批命中的判断应逐渐趋同。
- 如果是标准不同，那么扩大抽样后仍会反复出现同一类争执，且争执点集中在某个固定上下文，比如“引号内是否算原文”。
能起区分作用的证据是：把每一处命中连同它前后各一句上下文一起导出，让双方独立标注“应替换/不应替换”，再比对不一致的条目。如果不一致条目集中在少数几类上下文，就说明需要补的是规则，而不是继续加样本。
把反例写成可核对的条目，而不是一句“注意别改错”
反例样本要能被程序或人工逐条核对，至少包含三部分：命中的原始字符串、它所在的上下文类型、以及判定为反例的理由。理由必须是可观察的，例如“该字符串位于 <code> 标签内”“该字符串是外部引文的原话”“该字符串是某篇文章标题的一部分，替换后会与站内其他标题重复”。
一个假设的例子：若要把正文中的“旧称”统一为“新称”，可以先构造这样几条反例——出现在 <code> 示例里的“旧称”、出现在引用块中作为他人原话的“旧称”、以及作为某张图片替代文本的“旧称”。这三类的共同点是替换后会破坏原有语义或可访问性描述，因此应排除在批量替换之外。
构造完成后，先在一份副本上执行替换，再逐条检查反例是否被误改。这个动作的结果直接决定下一步：如果反例全部未被改动，说明排除规则有效，可以进入全量替换；如果仍有反例被改动，说明规则只覆盖了部分上下文，需要回到标注环节补充条件，而不是直接扩大替换范围。
替换前后比较时，别把变化都归给这次改动
批量替换后如果观察到某些页面表现变化，不能直接当作替换造成的。季节、搜索需求波动、数据采集时间差异都会影响同一时间段的对比结果。更稳妥的做法是：保留替换前的基线快照，替换后在同一采集口径下再取一次，并单独标记哪些页面确实被替换命中、哪些没有。这样即使出现差异，也能先排除“未被命中的页面也在变”这类干扰。
如果替换涉及的是站内称呼或术语统一，还要检查站内链接文字和标题是否同步。只改正文而漏改链接文字，会让同一概念出现两种写法，反而增加后续核对成本。
什么时候可以开始替换，什么时候应继续构造反例
可以开始替换的条件是：反例清单已覆盖当前内容中出现的各类上下文，且在一份副本上验证过排除规则有效。应继续构造反例的条件是：仍存在无法用现有规则判定的命中，或双方对同一类命中的判断不一致。
实际操作中，先处理规则明确的部分，把有争议的命中单独留出，等规则补齐后再处理。这样即使替换分批进行，也不会把争议条目混进已确认的批次里，后续核对时能清楚知道每一批改了什么、依据是什么。
