SEO方法写脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f403262ff919.html
📄
SEO方法写脚本需求时怎样描述例外情况
把人工经验写成脚本需求，例外情况不能只写“特殊情况特殊处理”，而要写成可判定的条件、可执行的取舍和可回退的边界。核心做法是：先区分哪些例外必须保留人工判断，哪些可以改写成脚本分支，哪些应当直接退出自动化范围。判断依据不是“这个样本能不能跑通”，而是“同类样本规模化后，脚本能否稳定识别并做出不伤害结果的决策”。
先给例外分类：保留、改写还是退出
人工处理样本时，经验往往藏在“看一眼就知道”的直觉里。写脚本需求时，要把这种直觉拆成三类。
- 保留：例外依赖语义判断、业务上下文或跨部门确认，脚本无法稳定复现。这类例外应保留人工入口，脚本只负责标记和转交。
- 改写：例外有可观察的触发条件，只是人工没有把它写成规则。这类可以改写成脚本分支，但必须写清判定字段、阈值和命中后的动作。
- 退出：例外一旦出现，继续自动化会放大错误，且没有可靠的自动回退方式。这类应直接退出自动化范围，不做兜底猜测。
三类不是按难度分，而是按“错误代价”分。一个例外即使很容易识别，如果误判后会影响大量页面或对外展示，也应优先考虑退出，而不是硬写成脚本分支。
把例外写成条件句，而不是形容词
脚本需求里最常见的失败描述是“标题过短时跳过”“内容质量差时人工处理”。短、差、异常、不相关，这些词对写脚本的人没有可执行含义。需要改成条件句：
如果 title 字段为空，或去除空格后字符数小于 N，则标记为待人工确认，不自动改写。
这里的 N 不是拍脑袋定的，而要从人工样本中反推：把已经人工处理过的样本按字段值排序，找到那批被人工判定为“不能自动处理”的样本集中在哪个区间。这个区间边界就是候选阈值。阈值只用于标记，不直接用于改写，可以显著降低误伤。
另一个动作是给每个例外条件配一个反例检查：拿一批正常样本跑同一条件，看会不会被误命中。如果正常样本也被大量标记，说明条件写得太宽，需要收窄字段或增加组合条件。这个动作的结果直接决定下一步：误命中低，才值得把该分支接入自动流程；误命中高，就退回人工标记，不继续自动化。
写清例外不能被照搬的边界
个别样本成立，不代表规则可以复制到全部同类对象。写需求时要显式写出边界，而不是等脚本跑出问题再补。
假设一个例子：人工发现某类列表页在字段缺失时，手动补一个默认值效果可以接受。把这个经验写成脚本后，如果脚本对所有页面都补默认值，那些本来字段完整、只是采集延迟的页面也会被覆盖。这里的边界是：默认值只适用于字段确认缺失且页面类型匹配的样本，不适用于字段暂时为空但可能恢复的样本。
边界描述至少包含三项：适用对象范围、不适用对象范围、以及当对象落入灰色地带时的动作。灰色地带的动作建议统一写成“不处理并记录”，而不是让脚本自行选择。记录的作用是后续可以统计灰色地带出现的频率，再决定是否值得为它单独写规则。
用一次小规模对照决定是否扩大
例外规则写完后，不要直接全量上线。先选一批包含例外和正常样本的集合，按同一时间窗口做前后对照。对照时要注意，改动前后的差异可能来自季节、搜索需求变化或数据采集口径不同，不能只看一个指标的变化就归因于脚本。
可操作的做法是：把样本分成“命中例外规则”和“未命中例外规则”两组，分别看两组在改动前后的表现差异。如果只有命中组出现预期变化，未命中组基本稳定，才说明规则可能在起作用。如果两组同时变化，优先怀疑外部因素，而不是继续扩大规则。
这一步的结果决定下一步取舍：命中组表现符合预期且未命中组稳定，可以把规则扩大到更多同类对象；命中组没有明显变化，说明规则可能没有触及真正原因，应回到例外分类重新判断；未命中组也出现波动，应先排查数据采集和需求变化，暂缓扩大。
需求文档里必须留下的回退信息
例外处理最怕的是脚本执行后无法还原。写需求时，至少保留三类信息：命中例外的原始字段值、脚本做出的动作、以及该动作对应的规则编号。这样当结果异常时，可以按规则编号回查是哪条例外判断出了问题，而不是重新人工翻样本。
如果例外规则涉及改写内容或调整字段，回退信息还要包含改写前的值。没有改写前值的记录，就无法判断是规则本身错了，还是上游数据已经变了。这个动作看起来增加存储和日志成本，但它决定了例外规则能不能被安全地迭代。没有回退信息的规则，一旦出问题只能整体停用，之前积累的判断边界也会一起丢失。
