百度seo技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a40392eb75bb.html
📄
百度seo技巧：把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成“特殊情况特殊处理”，而要写成可判定的条件分支。人工判断里最值钱的部分，是“什么情况下不按主流程走”。脚本需求必须把这类判断转成明确的触发条件、默认动作和人工接管点，否则脚本只能处理顺利路径，一遇到异常就报错或给出错误结论。
先区分三种例外：可枚举、可探测、只能人工判断
把例外写进需求之前，先给它们分类，因为三类例外的写法完全不同。
- 可枚举的例外：来源固定、取值有限。例如页面类型只有列表页、详情页、聚合页三种，脚本可以按类型走不同规则。
- 可探测的例外：脚本能在运行时发现异常。例如返回内容为空、字段缺失、状态码异常、页面结构与预期不符。
- 只能人工判断的例外：涉及业务意图，脚本无法从数据里看出。例如某页面是否还有保留价值、某次改版是否属于临时活动页。
前两类应该写进脚本逻辑，第三类应该写成“暂停并交给人”的出口。把第三类硬塞进脚本，通常表现为一堆互相冲突的阈值，维护成本比人工处理还高。
例外描述要写成条件、动作、结果三段式
人工经验常以“一般”“大多数情况”“看情况”出现，脚本读不懂这些词。转换时按三段式写：什么条件下触发，触发后执行什么动作，动作产生什么结果供下一步判断。
假设一个场景：脚本负责从一批页面中筛出需要保留的页面，其余进入改写或退出流程。人工经验是“内容还有用的就留着”。这句话无法执行，需要拆成：
- 条件：页面主体内容与当前业务主题相关，且存在可复用的信息块。
- 动作：标记为保留，跳过改写流程。
- 结果：保留清单单独输出，供人工抽查，抽查不通过则退回改写。
这里的关键不是条件写得多细，而是每个例外都有对应的动作和可检查的结果。只有条件没有动作，脚本不知道停下来还是继续；只有动作没有结果，人无法判断这次例外处理是否正确。
用“默认动作 + 例外覆盖”代替层层判断
人工经验往往先讲主流程，再补一句“但有些情况要反过来”。脚本需求如果照这个顺序写，会变成嵌套很深的判断。更稳的写法是先定默认动作，再列出覆盖默认的例外。
例如默认动作是“字段缺失即跳过该页面”。例外覆盖可以写成：缺失的是非核心字段则继续处理，缺失的是核心字段则跳过并记录原因。这样脚本的主路径清晰，例外是附加层，改动时只需动例外清单，不必重写主流程。
一个判断取舍的短例子（假设）：某批页面中约三成缺少更新时间字段。若把“缺更新时间”直接设为跳过，样本量会明显减少；若设为继续但降低优先级，样本量保住，但后续需要人工确认这批页面的时效性。两种处理都成立，区别在于你更需要覆盖量还是更需要结论可靠。选择前先明确这次脚本产出是用于排查还是用于决策。
把“不确定”写成显式出口，而不是默认值
脚本最容易犯的错，是把无法判断的情况归入某个默认类别。人工经验里“拿不准的先放着”被翻译成“归入保留”，结果保留清单里混入大量本应退出的页面，后续人工复核量反而增加。
正确做法是设置一个独立的“待人工确认”出口，并记录触发它的条件。触发条件可以包括：页面同时符合保留和退出的部分特征、关键字段取值互相矛盾、页面结构与已知类型都不匹配。这个出口的数量本身就是信号：如果待确认项持续偏高，说明例外条件写得不够，需要回到需求里补充可探测规则，而不是让人一直兜底。
验证例外逻辑时，先看触发分布再看结论
脚本跑完，不要只看最终保留了多少页面。先看每个例外分支各触发多少次、待人工确认有多少条。如果某个分支触发次数为零，先别急着认为它没用，可能是条件写得太窄，也可能是这批数据里确实没有该情况，需要换一批数据再验证。如果待确认项占比很高，说明脚本承担不了当前的判断复杂度，此时应缩减脚本职责，把更多环节交回人工，而不是继续加阈值。
一次改动前后的比较还要考虑搜索需求本身的波动和数据采集方式的差异，不能把触发次数的变化直接当成逻辑改对了的证据。触发分布稳定、待确认项可控、人工抽查通过率可接受，这三项同时成立，例外描述才算基本可用。
