seo实战教程：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a857be9e9f34.html
📄
seo实战教程：把人工经验写成脚本需求时怎样描述例外情况
结论先说：例外情况不能写成“遇到特殊情况再处理”，而要写成“当某个可观测条件成立时，脚本走哪条分支、留下什么记录、由谁接下一步”。前提是你能把人工判断拆成可观测字段；如果判断依赖的是“感觉这个页面不太对”，那更适合先保留人工复核，不要急着写进脚本。
先区分两类例外：可判定的和只能人工兜底的
可判定的例外，指脚本能读到明确信号。例如抓取某个列表页时，如果返回内容里出现了登录表单、验证码提示或空结果容器，这属于可判定例外，脚本应当停止翻页并记录原因，而不是继续请求下一页。
只能人工兜底的例外，指判断依赖语境。例如一个页面标题看起来偏短，但它是否真的偏离用户问题，需要结合页面正文、搜索意图和同站其他页面比较。这类情况在脚本需求里应写成“标记待复核”，而不是“自动判定不合格”。
把两者混在一起，是人工经验转脚本时最常见的失败点：脚本会把模糊判断当硬规则执行，结果要么误伤正常页面，要么把真正的问题淹没在大量标记里。
描述例外时要写清楚四个字段
一条可执行的例外描述，至少包含触发条件、判定依据、处理动作和记录内容。缺任何一项，开发和后续复核都会反复猜测。
- 触发条件：在什么步骤、读到什么值、处于什么状态时触发。例如“在解析第2页之后，若连续两次返回的条目ID与第1页完全一致”。
- 判定依据：用哪个字段或哪几个字段组合判断。例如“以条目ID集合是否新增为准，不以页面文字长度为准”。
- 处理动作：停止、跳过、重试、降级还是转人工。例如“停止翻页并保留已抓到的条目，不重试”。
- 记录内容：留下什么证据供下一步判断。例如“记录触发时的页码、请求地址、返回状态和条目ID集合摘要”。
这四项写全之后，脚本的行为才是可预测的。否则“例外情况”只是把人工的犹豫原样搬进了代码。
一个假设例子：列表页翻页遇到重复内容
假设你有一个商品列表页，人工操作时发现翻到后面几页会出现重复条目，于是凭经验知道“翻到重复就停”。把这条经验写成脚本需求时，可以这样描述：
当第N页解析出的条目ID集合与已记录集合的交集比例达到全部条目的多数时，判定为重复页，停止翻页，并把该页页码和交集数量写入日志。这里用“多数”而不是固定数字，是为了避免把某个具体比例当成通用规则；实际阈值应结合该列表页的正常分页规模来确定。
这个动作的结果会直接影响下一步：如果日志显示重复发生在第3页，说明该列表的有效深度有限，后续做页面收录判断时应以有效深度为准；如果重复发生在很靠后的页码，则更可能是分页参数或排序不稳定，需要先检查请求参数，而不是直接判定内容重复。
反例也要写进去：如果列表本身允许同一商品因不同规格多次出现，那么“ID重复”不等于“翻页异常”。此时触发条件应改为“同一ID且同一规格标识同时重复”，否则脚本会把正常展示误判为异常。
哪些前提一变，原来的例外描述就失效
例外描述依赖前提。前提变化后，原来的分支可能不再成立，需要重新判断，而不是继续沿用。
- 页面结构改版：原来靠某个容器判断空结果，改版后容器名称变化，脚本可能把正常页面判成空页。此时应先更新判定依据，再恢复运行。
- 业务规则调整：原来允许重复展示，后来改为去重展示，重复条目的含义就变了，原来的例外条件需要重写。
- 数据采集方式变化：从直接请求改为经过中间层，返回状态和内容结构可能不同，原来基于状态码的判断需要重新验证。
判断是否失效，不能只看“脚本有没有报错”。更可靠的做法是对比改动前后同一批样本的处理结果，并注意季节、搜索需求变化和数据采集差异带来的波动。一次改动前后数量变化，不能单独证明例外处理正确，还需要看触发记录是否指向同一类原因。
下一步动作：先跑一批样本，再决定是否自动化
在把例外写进正式脚本之前，先选一批有代表性的页面或列表，手工记录触发条件和处理结果，再让脚本以“只记录不执行”的方式跑同一批样本。比较两者差异：如果脚本标记的例外与人工判断基本一致，就可以把处理动作接上；如果差异集中在某一类页面，说明判定依据还不够具体，应先补充字段或缩小适用范围。
这个动作的结果决定下一步是扩大自动化范围，还是继续保留人工复核。例外描述写得再完整，也要经过样本对照才能确认它对应的是真实业务变化，而不是一次采集波动。
