快速SEO技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d296d4ac731.html
📄
快速SEO技巧：把人工经验写成脚本需求时怎样描述例外情况
结论是：例外情况不要写成“如果有问题就跳过”，而要写成“当某个可观测条件成立时，执行哪个替代动作，并留下哪条记录”。只有条件、动作和记录三者齐全，脚本才能在出现与直觉相反的结果时帮你定位原因，而不是把异常悄悄吞掉。人工经验里最容易被省略的，恰恰是“我为什么这次不按常规做”，这正是脚本最需要的那部分。
先区分两类例外：数据缺失与判断冲突
人工操作时，很多决定是凭上下文临时做出的。写成脚本需求时，要把它们拆成两类。第一类是数据缺失，比如某个页面没有可用的标题字段、某个URL返回的响应码不在预期集合内。第二类是判断冲突，比如页面看起来该被纳入处理范围，但它的更新时间又表明它刚被改过。两类例外的处理方式不同：数据缺失通常对应“跳过并记录”，判断冲突通常对应“暂缓并标记待人工确认”。
如果你把两类混成一句“异常则忽略”，脚本跑完后你只会得到一份数量变化，却不知道变化来自哪里。可核对的证据是：日志里能不能区分“没有取到值”和“取到了值但不满足条件”。这两种情况在后续排查中指向完全不同的动作。
例外描述的最小结构：条件、替代动作、记录字段
一条可执行的例外，建议写成这样的三段式：
- 条件：用脚本能直接判断的表达式描述，例如“标题字段为空字符串”或“响应码不等于200”。
- 替代动作：明确是跳过、保留原值、写入待确认队列，还是用上一版数据兜底。
- 记录字段：至少包含URL、触发条件、时间、以及脚本当时取到的原始值。
假设一个场景：你要求脚本把一批页面里过短的标题补长。人工经验是“太短就改”，但真正的例外是“标题短、可正文里已经有一个明确的核心词，只是没放进标题”。这时条件应写成“标题长度低于阈值且正文核心词未出现在标题中”，替代动作是“生成候选标题但不直接写入”，记录字段是“原标题、候选标题、正文核心词”。这样下一步动作就清楚了：先抽查候选标题，再决定是否批量写入，而不是一次性覆盖。
用可核对证据区分“脚本没生效”和“结果本来就会这样”
出现与直觉相反的结果时，常见的第一反应是脚本写错了。但至少有两种合理解释：一是脚本确实没执行到目标范围，二是执行了，但外部条件在这段时间发生了变化。区分方法不是看总量，而是看分层证据。
可以比较同一批URL在改动前后的字段值分布，而不是只看平均值。如果分布整体移动，说明处理覆盖了大部分对象；如果只有少数对象变化，可能是例外规则把多数对象挡在了外面。同时要检查采集时间是否一致，采集时间不同会引入需求波动，不能直接归因于脚本动作。
这里有一个容易犯的错：某个统计从有到无，被当成“处理正确”的证明。实际上它也可能是采集口径变了、页面结构变了，或者数据源本身在那段时间不可用。归零只能说明“按当前口径没观察到”，不能单独证明动作有效。
一个会使结论失效的反例
上面的三段式写法有一个前提：例外条件在脚本运行期间是稳定的。如果条件本身依赖一个会频繁变化的字段，比如“最近更新时间”，那么同一条规则在不同时间跑会得到不同结果。此时“跳过并记录”可能把本该处理的对象反复排除，而日志看起来一切正常。
反例是：你把“更新时间在近七天内”设为暂缓条件，本意是避免动刚改过的页面。但如果这个字段的更新并不总代表内容实质变化，那么大量页面会被长期挡在队列外，脚本每次都产出“暂缓若干条”的记录，你却误以为它们在等待人工确认。这种情况下，需要把条件改成更具体的信号，比如“正文主体字数发生变化”，或者给暂缓记录加一个复查时间，避免无限期堆积。
下一步动作：先跑只记录不写入的版本
在正式写入之前，先让脚本按最终例外规则跑一遍，但只输出记录、不修改任何内容。拿到记录后，重点看三件事：触发例外的URL是否集中在你预期的类型上；记录里的原始值是否完整；有没有同一URL在多次运行中反复触发同一条例外。如果反复触发，说明条件太宽，需要收紧或增加复查机制。确认记录能解释绝大多数被排除的对象后，再把替代动作从“仅记录”切换为“执行”。这一步的结果直接决定你要不要调整条件，而不是决定要不要上线。
