快照优化方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3dccc2ac0dd0.html
📄
快照优化方法：把人工经验写成脚本需求时怎样描述例外情况
先给结论：例外情况不要写成“特殊情况特殊处理”，而要写成“可判定的条件 + 指定动作 + 记录要求”。条件必须能用页面字段、响应状态、URL 规则或数据字段判断，动作要明确脚本该跳过、降级还是交给人工。做不到这一点，脚本上线后就会把原本靠人判断的边界情况批量做错。
先分清两类例外：可判定例外与不可判定例外
写需求前，先把人工经验里的例外分成两类，这决定脚本该不该接管。
- 可判定例外：能用已有字段或规则判断。例如 URL 命中某类目录、页面返回状态异常、字段为空、同一模板下页面结构不一致。这类例外适合写进脚本，用条件分支处理。
- 不可判定例外：需要看内容语义、需要业务背景、需要临时判断。例如某页文案是否涉及敏感表述、某栏目是否即将下线。这类例外应写成“触发人工复核”，而不是硬塞判断规则。
把不可判定例外伪装成规则，是脚本出错最常见的原因。判断依据很简单：如果两个有经验的人看同一份数据会得出不同结论，它就不该由脚本自动决定。
两种写法怎么选：条件分支还是人工队列
同一批例外，通常有两种合理写法，取舍取决于例外出现的频率和判断成本。
选择一：写进脚本条件分支
适用条件是例外出现频率高、判断标准稳定、误判代价可控。动作是：在脚本里显式写出条件，命中后执行跳过或降级，并输出日志。代价是规则会随页面结构变化而失效，需要定期回归检查。
例如，假设某批页面的快照需要按模板统一处理，但其中一部分页面缺少关键字段。可以写成：字段为空时跳过该页并记录 URL，而不是用默认值强行处理。这个动作的结果是：处理量略降，但避免了用错误默认值污染结果，后续只需针对被跳过的 URL 单独处理。
选择二：转入人工队列
适用条件是例外出现频率低、判断依赖语义、误判代价高。动作是：脚本识别出候选例外后写入待处理清单，由人工逐条决定。代价是处理速度受人力限制，清单积压时可能拖慢整体进度。
取舍的判断点不是“哪个更先进”，而是误判一次的成本是否高于人工处理一次的成本。误判成本高、频率低，选人工队列；误判成本低、频率高，选条件分支。
例外描述要写到什么颗粒度
需求文档里，每条例外至少包含四项，缺一项就会在执行时产生歧义。
- 触发条件：用哪个字段或哪条规则判断，写明字段名、比较方式和取值。避免“看起来不对”这类描述。
- 命中动作：跳过、降级、标记还是转人工，只选一种，不要写“视情况而定”。
- 记录内容：记录 URL、命中条件、时间或批次标识，便于事后核对。
- 退出条件：什么情况下这条例外规则可以取消，例如页面结构修复后。
颗粒度以“换一个人照文档执行能得到相同结果”为准。达不到这个标准，说明还停留在经验描述，没有变成需求。
一个假设例子：字段缺失时的两种处理
假设有一批页面需要按统一规则处理，人工经验是“大部分页面直接处理，少数缺字段的先放着”。把它写成需求时，可以有两种写法。
写法 A：if 字段为空 then 跳过并记录。结果是处理量下降，但被跳过的页面清晰可查，下一步只需处理这批 URL。
写法 B：if 字段为空 then 使用默认值继续。结果是处理量不变，但默认值可能让后续判断偏离真实情况，排查成本转移到下游。
两种写法都成立，区别在于你更愿意把成本放在当下的人工复核，还是放在下游的结果排查。如果缺字段的页面占比很低，写法 A 更稳；如果占比很高且默认值可靠，写法 B 才值得考虑。
上线后怎样验证例外规则是否写对
不要用一次改动前后的整体数据直接下结论。搜索需求本身会随季节波动，数据采集口径也可能变化，这些都会影响观察结果。更可靠的做法是：先看被例外规则命中的页面清单是否符合预期，再看这批页面的后续处理是否按文档执行。
如果命中量突然归零，不能直接判定规则生效正确。可能的解释包括：页面结构已变化导致条件不再匹配、数据源字段改名、采集范围缩小。需要逐项排除，而不是把归零当成成功信号。
把例外写成可判定条件、指定动作和记录要求，脚本才能稳定接管重复工作，人工只处理真正需要判断的部分。下一步可以先挑一条频率最高的例外，按上述四项补全描述，再决定它进脚本还是进人工队列。
