博客SEO技巧，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /705fa666a4d7.html
📄
博客SEO技巧，把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成“其他情况照常处理”，而要把触发条件、判断依据、处理动作和退出后的状态各写一层。脚本执行时遇到不满足主规则的输入，才知道该跳过、降级、标记还是交回人工，否则自动化会把旧内容里仍然有价值的部分一起删掉。
先看一个反常现象：脚本跑得越顺，旧内容越容易受伤
把人工整理博客的经验写成脚本时，主流程通常先被描述清楚：读取页面、判断是否过期、决定是否更新或下线。问题出在脚本对“例外”的处理。假设某批旧文章因为主题收缩需要退出，人工做法是逐篇判断——有的只替换过时段落，有的保留原文只改内部链接，有的整篇下线。脚本如果只写“不满足保留条件的全部删除”，运行日志会显示处理数量稳定、错误为零，但结果可能把仍有引用价值的段落一并清掉。
这个现象有两种解释。第一种是规则本身写得太粗，例外没有被单独描述，脚本只能按主规则兜底。第二种是例外描述存在，但触发条件依赖人工才能判断的字段，脚本读不到，于是走了默认分支。两者都会让脚本“顺利跑完”，却产生不同性质的损失。
区分两种解释的证据：看脚本在哪一步做了默认动作
要区分是规则太粗还是条件不可读，可以检查脚本的决策日志，而不是只看最终处理数量。具体做法是：在脚本里为每个例外分支加一条标记，记录“哪条规则命中、依据哪个字段、走了哪个动作”。
- 如果日志里大量输入落到同一个兜底分支，且这些输入在人工记录中本应属于不同处理方式，说明规则描述太粗，例外没有被拆开。
- 如果日志显示脚本在读取某个字段时反复取到空值，随后进入默认动作，说明例外条件依赖的信息在旧系统里不存在或格式不一致，问题在数据可读性，不在规则数量。
这两种证据指向的动作不同。前者要回到需求描述，把例外按处理结果分类；后者要先补字段映射或改判定入口，否则继续细化规则也不会被执行。
描述例外时，把“什么情况”和“怎么办”分开写
人工经验里常把判断和处理混在一句话里，例如“这篇太旧了，删掉”。写成脚本需求时，需要拆成可判定的条件和可执行的动作。一个可用的结构是四段：触发条件、判断依据、处理动作、退出后状态。
- 触发条件：说明在什么输入下进入例外，例如“发布时间早于某个阈值，且没有外部引用记录”。
- 判断依据：说明脚本读取哪些字段来判断，字段缺失时算不算命中例外。
- 处理动作：明确是跳过、降级保留、标记待审还是整篇下线。
- 退出后状态：说明处理完后这条内容处于什么状态，后续流程是否还会再次处理它。
第四段最容易被省略。如果脚本把内容标记为“已处理”但实际只是跳过，下一轮流程可能不再检查它，等于用一次默认动作把例外永久固化。写明退出后状态，才能让后续判断有依据。
假设一个短例子：保留有价值部分时，例外怎么落成条件
假设有一批旧博客文章需要退出主导航，但其中部分段落仍被其他页面引用。人工经验是“还有用的留下，没用的下线”。直接写成脚本会失败，因为“有用”不可判定。
可以改成这样的假设条件：当页面存在来自站内其他页面的链接，且这些链接不是导航或页脚模板产生时，脚本不删除正文，只移除主导航入口并标记为“待人工复核”；当页面没有这类链接时，脚本将其下线。这里的数字和阈值只用于说明比较方法，不代表任何实际统计结果。动作执行后，下一轮流程只处理“待人工复核”状态的内容，不再重复扫描已下线页面。
这个例子的关键是：例外不是“其他”，而是一组有明确字段可查的条件。脚本能读到链接来源，就能区分模板链接和正文引用；读不到，就应该把这条输入交回人工，而不是走删除默认分支。
改动前后比较时，别把一次变化当成规则生效
例外规则上线后，处理数量、抓取量或某项统计出现变化，不能单独证明规则写对了。季节变化、搜索需求波动、数据采集口径调整，都可能造成同样的现象。要判断例外描述是否有效，可以固定一批已知属于例外的输入，单独观察它们在脚本中的分支命中情况，而不是只看整体处理量的涨跌。如果这批输入的分支命中与人工判断一致，才说明例外描述至少在这批样本上可执行；不一致时，先修条件或字段，再谈扩大范围。
