seo实战密码 pdf，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /af6682cbcc1e.html
📄
seo实战密码 pdf，把人工经验写成脚本需求时怎样描述例外情况
例外情况必须写成“可判定的条件+指定动作+记录字段”，而不是“视情况而定”。例如把“遇到空值就跳过”改成“当字段为空且该字段属于必填项时，写入待补清单并停止后续依赖该字段的计算”。这样脚本才能在关键前提变化时给出不同结果，而不是把人工经验压缩成一条永远执行的规则。
先看一个矛盾：人工操作顺畅，脚本却频繁误判
人工处理时，操作者会根据上下文临时决定“这次不算例外”。写成脚本后，同样的输入却可能被统一归到某个分支。常见矛盾是：人工觉得只是个别情况，脚本却把它当成高频路径。要解决这个矛盾，先不要急着加更多判断，而要区分两种解释。
两种解释：前提变化，还是例外定义过宽
解释一：关键前提变了。 以前人工操作时，数据源、页面范围或业务口径是稳定的，所以“例外”很少出现；现在前提发生变化，例如字段来源从一个系统变成两个系统，或页面从单一栏目扩展到多栏目，原本的少数情况变成了常见情况。此时应重新划分前提，而不是继续修补原来的例外分支。
解释二：例外定义过宽。 人工写需求时常用“如果异常就处理”这类表述，但“异常”没有边界。脚本执行时只能按最宽泛的条件触发，于是把正常波动也当成例外。此时应把例外拆成可观察的字段，例如空值、重复值、超长文本、缺失关联标识，并分别指定动作。
用来区分两种解释的证据
- 看例外出现的分布。 如果例外集中在新加入的数据源或新扩展的页面类型上，更可能是前提变化；如果例外均匀分布在原有范围内，更可能是定义过宽。
- 看人工复核记录。 如果人工复核时经常说“这个不算问题”，说明例外定义过宽；如果人工复核时经常说“以前不会这样”，说明前提变了。
- 看同一输入在不同时间的结果。 同一批输入在前提变化前后得到不同处理结果，且差异与数据源或业务口径同步出现，更支持前提变化。
需要注意，请求量、抓取量或某项统计归零不能单独证明处理正确。它也可能来自采集延迟、过滤条件变化或上游数据尚未同步。把这些现象与人工复核记录放在一起看，才能避免把相关当成因果。
把例外写成脚本需求的具体动作
假设一个场景：人工经验是“遇到标题缺失就补一个默认标题”。直接写成脚本，可能会给所有缺失标题的页面都补默认标题。更稳妥的写法是先定义前提：if title is empty and page_type in [detail, category]，再指定动作：write to missing_title_list，最后记录字段：source, page_type, timestamp。这样脚本不会越过前提去处理其他页面类型。
这个动作的结果会直接影响下一步：如果缺失标题集中在新增页面类型，下一步应扩展前提范围或增加新的页面类型分支；如果缺失标题分散在原有页面类型，下一步应检查数据采集环节，而不是继续增加默认标题规则。
关键前提变化前后，决策条件不同
前提变化前，例外可以作为低频分支处理，人工复核可以覆盖大部分情况。前提变化后，如果例外开始集中出现，应先把例外拆成独立前提，再决定是否合并回主流程。判断条件可以简化为：例外是否与某个新数据源、新页面类型或新业务口径同步出现。如果是，先处理前提；如果不是，先收窄例外定义。
比较改动前后时，要考虑季节、搜索需求变化和数据采集差异，不能把一次改动前后的数字直接当成脚本效果。更可靠的做法是保留人工复核样本，比较同一批输入在改动前后的处理结果，而不是只看总量变化。
写需求时可直接套用的描述格式
- 前提： 在什么数据源、页面类型或业务口径下。
- 触发条件： 用可判定的字段描述，例如空值、重复值、超长文本。
- 指定动作： 跳过、写入清单、停止计算或转人工复核。
- 记录字段： 来源、页面类型、时间戳、处理结果。
- 复核入口： 哪些结果需要人工确认，确认后如何影响下一步。
这样写出来的脚本需求，才能在人工经验与自动执行之间保留可检查的边界。例外不是越少越好，而是每个例外都要有明确的前提和后续动作。
