淘宝SEO方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ad9c6cfdee99.html
📄
淘宝SEO方法：把人工经验写成脚本需求时怎样描述例外情况
例外情况要写成“触发条件＋判定依据＋执行动作＋记录字段”四段式，而不是只写一句“特殊情况特殊处理”。人工操作时，人靠上下文判断；脚本没有上下文，只能靠你明确写出的条件分支。缺少完整数据和权限时，仍可先写出可执行的判定规则和人工兜底动作，但只能验证流程能否跑通，不能据此推断流量或排名变化。
矛盾现象：规则写得越细，脚本反而越容易误判
把人工经验转成脚本需求时，常见一个反常现象：你把判定条件写得非常具体，脚本上线后却频繁把正常页面判成例外，或者把真正的例外放过。原因通常有两种，需要分开看。
- 解释一：条件本身不完整。人工判断时依赖多个信号，你只把其中一个写进了脚本，比如只按标题相似度判断重复，忽略了类目、价格区间、上下架状态等同样影响判断的因素。
- 解释二：条件的优先级没有定义。多个规则同时命中时，脚本按什么顺序执行没有写明，导致后写的规则覆盖了先写的规则，或者兜底规则被提前触发。
这两种解释对应不同的修正动作：前者要补信号，后者要排优先级。如果误判集中在某一类页面，更可能是条件不完整；如果误判随机分布、和页面类型无关，更可能是优先级缺失。
能区分两种解释的证据从哪里来
缺少完整数据或权限时，你仍然可以收集一类证据：把脚本判定结果和人工判定结果逐条对照，记录不一致的样本。
- 取一批已经人工处理过的页面，覆盖不同类目、不同状态，数量不必多，但要包含你已知的边界情况。
- 让脚本对这批页面跑一遍，输出每条规则的命中情况和最终判定。
- 对比人工结论，把不一致的样本单独列出，标注是“脚本多判了例外”还是“脚本漏判了例外”。
- 看多判和漏判分别集中在哪些规则上。
如果多判集中在某一条具体规则，说明该规则的条件过宽，需要补充限定；如果多判分散在几乎所有规则上，说明缺少统一的优先级或前置过滤条件。这个对照动作不需要后台权限，只需要你手头已有的处理记录和页面样本。
例外情况在脚本需求里的写法：四段式模板
每条例外都按下面四段写，缺一段就会给后续执行留下歧义。
- 触发条件：什么情况下进入例外分支。写清楚是“满足全部条件”还是“满足任一条件”。
- 判定依据：用哪个字段、哪个来源的数据来确认这个条件成立。如果该字段可能缺失，要写明缺失时算不算命中。
- 执行动作：命中例外后脚本做什么——跳过、标记待人工、还是走另一套处理流程。动作要具体到“输出什么、输出到哪里”。
- 记录字段：例外被触发时留下什么信息，供后续核对。至少记录触发时间、命中规则、相关页面标识和当时的字段值。
举个假设的例子：某条规则是“标题相似度超过阈值时判为重复”。例外写法可以是——触发条件：相似度超阈值但两个页面属于不同类目；判定依据：类目字段，字段缺失时不命中该例外；执行动作：不自动合并，标记为待人工确认；记录字段：两个页面标识、类目值、相似度数值。这样写，脚本在字段缺失时不会误入例外分支，人工也能从记录里快速复核。
数据和权限不足时，哪些结论不能下
用人工对照样本验证流程，能确认的是规则逻辑是否自洽、例外分支是否按预期触发。不能确认的包括：
- 不能确认改动后搜索流量会上升或下降。样本只覆盖你手头已有的页面，不代表整体页面的分布。
- 不能确认某条规则一定优于另一条。对照样本里表现好，可能只是因为样本恰好偏向该规则擅长的页面类型。
- 不能把“例外数量归零”当作处理正确的证据。例外归零也可能是规则被写得过宽、把本该走例外的页面直接放进了主流程，需要回到对照样本里检查漏判。
如果要比较改动前后的效果，要注意季节、搜索需求变化和数据采集口径的差异，不能把同期波动直接归因于脚本改动。
一个可执行的最小动作
如果现在只能做一件事：挑出你最近处理过的十到二十个页面，为每个页面写一行判定记录，包含页面标识、你当时判断的理由、最终处理动作。然后把这些记录当成脚本需求的验收样例——脚本跑出来的结果和这行记录不一致的地方，就是你需要补充或修改的例外描述。这个动作的结果会直接决定下一步：不一致集中在条件描述上，就先改需求文档；不一致集中在优先级上，就先定义规则执行顺序，再谈其他规则的新增。
