seo实战密码：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fd6386a43a69.html
📄
seo实战密码：把人工经验写成脚本需求时怎样描述例外情况
例外情况写不进去，通常不是脚本能力不够，而是需求把“正常流程”描述得太完整，却把判断分支留在了写需求的人脑子里。更麻烦的是，例外一旦被写成一句笼统的“特殊情况另行处理”，脚本执行者只能猜，最后往往把该拦的放过去，把不该动的改掉。要解决这个问题，得先把例外从“感觉”翻译成可判定的条件、可观察的信号和明确的动作。
先分清两类例外：数据缺失，还是规则冲突
人工处理时，人脑会自动补全信息，所以很多例外在经验里是隐形的。写成脚本需求时，它们会暴露成两种完全不同的东西。
- 数据缺失型例外：某个字段没抓到、某个值空着、某条记录只有一半。人工会凭上下文猜，脚本没有上下文就必须先声明遇到空值怎么办。
- 规则冲突型例外：两条本来都成立的规则同时命中，比如一个页面既符合“需要合并”又符合“需要保留独立入口”。人工会按经验排序，脚本需要你给出优先级。
把这两类混在一起写，需求就会变成一锅粥。更有效的做法是：先列出正常路径，再单独列一张例外表，每一行只回答三件事——什么条件下触发、看到什么信号算触发、触发后做什么。
用“条件—信号—动作”三列描述每个例外
人工经验里最常见的表达是“这种情况一般要小心处理”。这句话对脚本毫无价值，因为“这种情况”和“小心”都不是可执行描述。把它改写成三列，情况会立刻清楚。
条件：什么前提下才需要考虑这个例外
条件要写到能判断真假。例如“标题为空”比“标题质量差”可判定；“同一目标地址被两个栏目引用”比“重复内容”可判定。条件越接近原始数据，脚本越不容易误解。
信号：脚本靠什么发现它
信号必须是脚本能读到的字段或状态，而不是人的主观印象。比如“字段值为空字符串”“两个来源字段值相同”“时间戳早于上次抓取时间”。如果信号只能靠人看，就要在需求里注明这一步需要人工确认，而不是假装脚本能自动判断。
动作：触发后到底做什么
动作要具体到可执行结果：跳过、标记待审、按某条规则改写、还是停止后续步骤。动作含糊，脚本就会自行选择，而它的选择通常和你的经验不一致。
一个假设例子：你希望脚本在发现某条记录缺少关键字段时不要直接丢弃，而是标记为待人工处理。需求里写成“缺字段时标记待审，并保留原始值”，脚本才知道既不能删，也不能补默认值。这里的数字和字段名只是示意，实际以你的数据为准。
两个解释都能成立时，用证据区分
例外没被处理好，常见两种解释：一种是需求描述本身有遗漏，另一种是脚本按需求执行了，但数据在进入脚本前就已经变了。两者表现相似，处理方向却相反。
能区分它们的证据是：把脚本实际收到的输入和人工处理时看到的输入做对照。如果输入一致，但输出仍不符合预期，问题多半在需求描述；如果输入已经不同，比如字段缺失、编码变化、时间窗口错位，那要先修数据链路，而不是继续改需求文字。
还有一种容易被忽略的情况：例外规则写对了，但触发顺序不对。脚本先执行了通用规则，再执行例外规则，例外就被覆盖了。这时要检查的是规则顺序，而不是规则内容。
写完后做一次反向验证：让例外先发生
需求写完不等于描述清楚。更可靠的检验方式，是构造几条必然触发例外的输入，观察脚本是否按你写的那样停下、标记或改写。如果脚本没有触发预期动作，先回到“条件—信号—动作”三列，找出哪一列写得不够具体。
同时要注意，一次改动前后的比较不能只看单次结果。搜索需求会随季节波动，数据采集口径也可能变化，所以判断例外处理是否生效，要结合同一时间窗口内的对照，而不是把某一天的数量变化直接当成规则生效的证据。请求量或抓取量归零，也可能来自采集失败、过滤条件变化或上游数据延迟，不能单独证明例外规则写对了。
把例外写成脚本需求，本质上不是让脚本更聪明，而是把你做判断时依赖的条件、信号和动作显式写出来。条件可判定、信号可读取、动作可执行，例外才不会在交接时变成新的黑箱。做完这一步，下一步才是决定哪些例外需要人工复核、哪些可以完全交给脚本。
