SEO技术方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /455dcb45ad71.html
📄
SEO技术方法：把人工经验写成脚本需求时怎样描述例外情况
先把例外写成“条件—判断依据—动作—记录”四段式，再写脚本需求。人工经验里最危险的部分不是主流程，而是那些“通常这样，但遇到那种情况就反着来”的分支。如果只把主流程交给开发，脚本会把反常样本一起吞掉，产出的数据反而更难核对。下面以你手里的一份页面清单或抓取结果为例，说明怎么把例外转成可执行、可回退的需求。
先给例外分类，而不是直接写规则
拿到一份人工整理的页面资料后，先逐条问：这条经验在什么条件下不成立。常见的例外可以分成三类，处理方式完全不同。
- 样本例外：某个页面本身结构特殊，比如正文容器里混入了推荐位。它不该改变全局规则，只应进入单独名单。
- 状态例外：同一页面在不同时间返回不同内容，比如登录态、地区差异或活动页切换。脚本需要先判断状态，再决定是否处理。
- 规则冲突例外：两条经验同时命中且结论相反，例如“标题为空就取正文首句”与“标题为空就保留原值”。这类必须由人先裁决，不能让脚本随机选。
分类之后你会得到一个明确结果：哪些例外写成脚本内的分支，哪些写成外部配置名单，哪些必须人工确认。这个结果直接决定下一步需求文档的写法。
用可核对的证据区分不同解释
人工经验里经常出现与直觉相反的结果，例如某类页面处理后抓取量反而下降。此时不要急着改规则，先收集能区分解释的证据。
假设你观察到处理后的页面在采集数据里数量变少。至少存在三种解释：一是脚本过滤掉了本应保留的样本；二是搜索需求本身在这段时间变化；三是采集方式或时间窗口与上次不同。要区分它们，可以固定采集条件后重跑一次，并把被过滤的样本单独导出核对。如果被过滤的样本里大部分确实是无效页，那么数量下降更可能是过滤生效，而不是规则出错。
这里要提醒一点：请求量、抓取量或某项统计归零，不能单独证明处理正确。它也可能是采集故障、页面临时不可达或需求季节性回落。把这些可能解释并列写进需求文档的“验证方法”一节，比只写一句“处理后数量应下降”更有用。
把例外写成脚本需求的四段式
每条例外都用同一结构描述，开发才能准确实现，你也能事后核对。
- 条件：什么情况下触发。写具体字段和判断，例如“标题字段为空且正文首段长度大于零”。
- 判断依据：用什么数据判断。写清字段来源和取值方式，例如“读取页面结构化数据中的标题字段”。
- 动作：命中后做什么。写清是跳过、改写、标记还是进入人工队列。
- 记录：留下什么痕迹。要求脚本输出被命中样本的标识和命中原因，便于回查。
举个假设例子：你发现某栏目页的标题在人工检查时总是取不到，但页面本身正常。写成需求可以是——条件：标题字段为空且页面返回正常；判断依据：结构化数据标题字段为空字符串；动作：不覆盖原值，仅标记为待确认；记录：输出页面标识与命中原因。这样脚本不会擅自填入错误标题，你也拿得到一份待确认清单。拿到清单后，下一步是人工抽查其中若干条，确认是页面本身缺失还是提取逻辑漏读，再决定是否新增分支。
写清适用条件与回退方式
例外规则必须有边界，否则会越用越宽。需求里至少写明三点：规则只适用于哪类页面、遇到未覆盖情况时默认怎么处理、以及出问题后怎么退回上一版。
默认处理建议选保守动作，比如保留原值并标记，而不是自动改写。回退方式要具体到可执行：保留上一版规则文件、记录本次变更涉及的样本范围、明确谁有权决定回退。这样当结果与预期相反时，你能先止损再判断，而不是在脚本里反复试改。
最后，比较改动前后效果时，要把季节、搜索需求变化和数据采集差异一起考虑。同一份资料在不同时间跑出不同结果，未必是规则的问题。把例外描述清楚，本质上是让脚本只做你确认过的事，把不确定的部分留给人来裁决。
