SEO优化方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /44e1e5fd5000.html
📄
SEO优化方法：把人工经验写成脚本需求时怎样描述例外情况
例外情况要写成“触发条件 + 判断依据 + 动作 + 记录字段”，而不是一句“特殊情况特殊处理”。如果例外无法用可观察的数据表达，就应该保留人工确认；只有当例外有稳定信号、明确兜底动作，并且出错后能回滚，才适合交给脚本自动执行。
先分清三类例外，再决定保留还是改写
人工经验里的例外，通常不是同一种东西。把它们混在一起写进需求，脚本要么过度触发，要么在关键节点沉默。
- 数据型例外：字段缺失、格式异常、数值超出常见区间。这类例外通常可以改写为脚本规则，前提是你能说清缺失时是跳过、标记还是转人工。
- 判断型例外：需要结合业务意图才能决定，例如某类页面是否值得继续投入。这类例外适合保留人工确认，脚本只负责把候选和证据整理出来。
- 流程型例外：上游数据未就绪、发布窗口冲突、审批未完成。这类例外应写成状态检查，而不是让脚本猜测。
区分方法是问一句：这个例外发生时，执行人看的是同一组数据吗？如果不同的人会看不同信号，说明判断依据还没收敛，此时改写为自动化规则风险较高。
描述例外时，四个字段缺一不可
脚本需求里最常见的失败写法是“遇到异常就跳过”。跳过之后没有记录，后续无法判断是数据问题还是规则问题。可执行的写法至少包含四部分：
- 触发条件：用可观察的字段描述，例如“目标字段为空且来源标记为待补”。
- 判断依据：说明为什么这算例外，而不是正常分支。
- 动作：跳过、标记待确认、转人工、使用默认值，四选一并写清优先级。
- 记录字段：留下触发时间、命中规则、原始值和处理结果，便于回查。
假设一个场景：你原本靠人工检查页面标题是否与正文主题一致，现在想把这步写成脚本。可以写成“当标题字段为空时，标记为待确认并输出页面地址；当标题非空但与正文首段重合度低于设定阈值时，只记录不修改”。这里阈值是假设值，作用是把“明显不一致”和“可能不一致”分开，而不是承诺任何效果。
保留人工的边界：信号不稳定时不要硬写成规则
有些例外看起来能写成条件，实际上信号不稳定。例如同一类页面，有的因为业务调整暂时不处理，有的因为数据延迟看起来异常。如果脚本只根据单一字段判断，就会把两类情况混在一起。
判断是否保留人工，可以看三个条件是否同时成立：
- 例外出现的频率足够低，人工处理不会成为瓶颈；
- 每次判断需要的上下文超出脚本能稳定获取的范围；
- 误判的代价高于多一次人工确认的成本。
三个条件都成立时，保留人工更合理。脚本的职责改为收集证据、排序和提示，而不是替人做决定。反过来，如果例外频繁出现、判断依据固定、误判可回滚，就可以改写为自动规则，并设置抽样复查。
改写为脚本后，怎样验证例外处理没有跑偏
验证不是看脚本有没有报错，而是看例外是否被分到了正确的分支。可以先跑一批历史数据，比较脚本判定与人工判定不一致的条目，逐条确认是规则问题还是人工当时有额外背景。
这里要注意一个容易误判的现象：某段时间例外数量突然归零，不一定说明规则变准了。也可能是上游字段口径变了、采集范围缩小，或者脚本在更早的分支就拦截了。遇到归零，先检查触发条件的覆盖范围和上游数据量，再判断规则是否有效。
比较改动前后时，还要考虑季节和搜索需求变化。同一批页面在两个时间点的表现差异，可能来自需求波动而不是例外处理改动。更稳妥的做法是固定一批样本，分别用旧流程和新脚本处理，比较判定结果和处理动作，而不是直接比较流量或排名。
退出一种例外处理方式的条件
不是所有例外都值得长期维护。出现以下情况时，可以考虑退出当前处理方式：
- 例外触发后长期无人处理，记录字段只增不减；
- 触发条件频繁调整，说明判断依据本身不稳定；
- 兜底动作反复造成返工，且无法通过抽样复查收敛。
退出的方式可以是合并到正常分支、改为定期人工巡检，或者直接取消该例外规则并把资源移到更稳定的环节。决定退出前，先确认这个例外是否仍在保护某个关键前提；如果前提已经变化，继续保留只会增加维护成本。
把例外写清楚的目的，不是让脚本覆盖所有情况，而是让每个分支都有明确的适用条件和可回查的结果，这样下一次调整时才知道该改哪里。
