seo实战经验：把人工经验写成脚本需求时怎样描述例外情况，先区分三类例外，写法完全不同
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /fb1cd43aa863.html
📄
seo实战经验：把人工经验写成脚本需求时怎样描述例外情况，先区分三类例外，写法完全不同
能直接落地的写法是：把例外写成“触发条件 + 判定证据 + 脚本动作 + 人工接管点”，而不是写一句“特殊情况人工处理”。如果例外只存在于你的脑子里，脚本执行者就只能按正常路径跑，最终把本该保留的页面改错。下面这个结论有一个前提：你手里已经有一份能复现的人工操作记录；如果记录本身只有结论没有过程，先补记录，不要急着写需求。
先区分三类例外，写法完全不同
人工经验里的“例外”往往混在一起，写进脚本前必须先分类，否则需求会自相矛盾。
- 数据缺失型：该抓的字段没抓到、返回空值或格式异常。脚本动作应是“跳过并记录”，而不是用默认值补齐。
- 规则冲突型：同时命中两条处理规则，比如既符合合并条件又符合保留条件。脚本动作应是“按优先级表判定”，优先级必须由人写死。
- 判断依赖型：需要看语义、看上下文才能决定，比如某段内容是否与主题真正相关。脚本动作应是“标记待审”，不要试图用阈值硬判。
把这三类分开写，需求文档的篇幅不会变长，但执行时的歧义会明显减少。判断依赖型尤其容易被写成规则，结果脚本跑得越勤，错得越多。
描述例外时必须给出的四个字段
每一个例外条款，至少写清这四项，缺一项就会在联调时返工。
- 触发条件：用可观测的信号描述，例如“标题字段为空且正文长度低于阈值”，不要写“看起来不正常”。
- 判定证据：脚本要留下什么记录，供人事后复核。例如输出原始字段值、命中的规则编号、处理时间。
- 脚本动作：跳过、降级处理、还是进入待审队列。动作要唯一，不能写“视情况而定”。
- 人工接管点：什么条件下必须由人接手，以及接手时需要看到哪些信息。
一个假设的例子：假设你的人工经验是“栏目页缺少有效内容时先不处理”。写成需求时可以这样表达——触发条件是正文可见字符数低于设定阈值且无有效内链；证据是记录该页 URL、字符数、内链数；动作是跳过本次批量处理并写入待审清单；接管点是待审清单每日由人工抽查，确认是模板问题还是内容问题。这里的阈值是假设值，需要你用自己的数据回测后再定，不能直接照搬。
一个会让上述写法失效的反例
如果例外条款的触发条件依赖的字段本身不稳定，整套写法就会失效。例如你按“内链数为零”判定页面需要跳过，但抓取工具在某些时段返回的内链数本身就是零——不是页面没有内链，而是采集没完成。这时脚本会把大量正常页面误判为例外，待审清单被灌满，人工反而更累。
识别方法不是看单次结果，而是看同一批页面在多次采集中的字段波动。如果某个字段在短时间内反复在零和非零之间跳动，它就不适合作为例外触发条件，应先修采集，再写规则。请求量或抓取量突然归零，也不能单独证明页面真的出了问题，还可能是采集中断、权限变化或目标站临时响应异常。
写完后先用小样本回放，再决定是否扩大
需求写完不等于可以全量跑。实际动作是：挑一批你人工处理过的页面，让脚本在只读模式下回放，对比脚本判定结果与你当初的人工判定是否一致。
重点看不一致的那几条：是触发条件写宽了，还是证据字段没取到，还是优先级排错了。每修正一处，重新回放同一批样本，直到不一致项收敛到你愿意人工兜底的数量。这个动作的结果直接决定下一步——不一致项集中在判断依赖型，就扩大人工待审比例；集中在数据缺失型，就先修采集链路，暂缓上线。
需要提醒的是，回放一致不代表上线后效果一定变好。改动前后的对比要放在同一时间窗口、同一批页面类型上做，并考虑季节和搜索需求本身的波动；否则你看到的差异可能来自外部变化，而不是脚本处理正确。脚本上线后仍要保留人工抽查通道，尤其是判断依赖型例外，它的比例会随内容结构变化而漂移，需要定期重新校准。
