博客搭建方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2ad6168372ba.html
📄
博客搭建方法：把人工经验写成脚本需求时怎样描述例外情况
直接把人工经验翻译成脚本需求，最常见的结果不是脚本跑不起来，而是它跑得太顺——把本该保留的旧内容、旧链接、旧合作关系一并清掉。描述例外情况的关键，不是列更多“不要动”的清单，而是给每条例外写清触发条件、判断依据和退出动作，让脚本在遇到边界时停下来交给人决定。
为什么“清理旧内容”的脚本一上线就误删
假设你让脚本批量处理三年前的文章：删除没有内链指向、半年无更新、正文少于三百字的页面。脚本执行后，页面数量确实下降，但一些仍在带来咨询的旧教程也被删了。这个现象有两种合理解释。
第一种解释是规则本身太粗。脚本只看内链、更新时间和字数，而人工判断时还会看这篇文章是否被外部引用、是否是某条业务线的唯一说明、是否有人仍在邮件里转发。规则没有覆盖这些维度，误删是必然的。
第二种解释是执行顺序有问题。脚本先删页面，再处理跳转和保留清单，导致被删页面的链接变成死链，原本可以保留的价值也一起消失。这种情况下，规则可能没错，错的是动作的先后。
区分两种解释的证据
要判断是规则粗还是顺序错，可以看误删页面的特征分布。如果被误删的页面普遍有外部引用或人工标记，说明是规则维度缺失；如果被误删的页面本身特征符合规则，但删除后产生了大量死链和重复内容，说明是执行顺序问题。
另一个可区分的证据是回滚成本。规则粗导致的误删，恢复时需要重新判断每篇内容的价值；顺序错导致的误删，恢复时只需要重跑跳转和保留逻辑。前者更贵，后者更便宜。先做一次小范围试跑，记录误删页面的共同特征，比争论哪种解释更对更有用。
把例外写成脚本能识别的条件
人工经验里的“这篇先别动”，对脚本来说是不可执行的。需要把它拆成可判断的条件。例如：
- 如果页面被至少一个外部域名引用，则标记为保留，不进入删除队列。
- 如果页面是某条业务线的唯一说明页，则标记为保留，并输出到人工复核列表。
- 如果页面正文包含特定合作方名称，则暂停处理，等待人工确认合作关系是否仍然有效。
- 如果页面被删除后会产生指向它的内链，则先改写内链，再执行删除。
每条例外都要有明确的判断依据和后续动作。判断依据可以是外部引用、人工标记、页面类型或合作关系状态；后续动作可以是保留、跳过、输出复核或先改链接再删。没有后续动作的例外，等于没有例外。
一个注明假设的短例子
假设你有一个旧博客，其中二十篇教程来自已停止合作的作者。你的脚本需求原本写的是“删除所有作者已离职的文章”。执行前，你把例外改成：如果文章仍在过去九十天内被外部页面引用，则保留并输出到复核列表；如果文章没有被引用，但页面内有指向当前产品页的链接，则保留链接目标，删除文章主体。
这个动作的结果是：脚本不会一次性清空所有旧作者内容，而是把有外部引用和内部链接价值的部分留下来。下一步你可以只复核被标记的页面，而不是重新浏览全部二十篇。这样既保留了仍然有价值的部分，也让退出动作变得可回滚。
退出旧系统时，例外描述要覆盖哪些对象
旧内容、旧系统或旧合作关系需要退出时，例外描述至少要覆盖三类对象：内容、链接和关系。内容层面要说明哪些页面保留、哪些页面改写、哪些页面删除；链接层面要说明删除前如何处理指向它的内链和外链；关系层面要说明合作方名称、联系方式或授权说明是否仍然有效。
这三类对象的处理顺序会影响结果。先处理关系，再处理内容，最后处理链接，通常比反过来更安全。因为关系状态决定内容是否保留，内容是否保留决定链接是否需要改写。顺序错了，脚本会把仍然有效的关系也一起退出。
比较改动前后效果时，要考虑季节、搜索需求变化和数据采集差异。某段时间内页面访问量下降，可能是脚本处理的结果，也可能是搜索需求本身在变化。不要用单次前后对比直接判断脚本处理是否正确。
最后，例外描述不是一次写完就固定的。每次脚本试跑后，把新发现的边界情况补进例外条件，并记录触发条件和处理动作。这样下一次处理旧内容时，脚本能识别更多人工经验里已经明确的情况，而不是每次都靠人重新判断。
