seo实战案例：人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d2ef2aa70fb6.html
📄
seo实战案例：人工经验写成脚本需求时怎样描述例外情况
结论是：例外情况不能只写“遇到异常就跳过”，而要写成可判定的条件、触发后的动作和判定不了时的默认走向。缺少完整数据或权限时，仍可以先写最小可执行版本：每条规则只处理一种可观察信号，并明确它不负责什么。若例外条件依赖人工目测、页面类型判断或登录后才可见的数据，脚本在无人值守时就会失效，这时应把该条件降级为待确认项，而不是硬编码成规则。
先分清三种例外，再决定写进脚本还是留给人
把人工经验转成脚本需求时，最常见的失误是把所有“特殊情况”塞进同一段描述。实际应先分成三类。
- 可枚举例外：例如URL带特定参数、页面返回状态码属于某一组、标题为空。这类可以写成条件分支，脚本能自行判断并执行对应动作。
- 需上下文例外：例如某个页面是否属于活动页、是否允许被替换。判断依赖业务归属，脚本只能读取标记或清单，不能自行推断。
- 无法判定例外：数据缺失、权限不足、接口超时。此时要规定默认动作，例如“保持原样并记录”，而不是“继续处理”。
假设一个场景：你要把人工处理标题的规则写成脚本，人工经验是“标题明显重复或不符合主题时改写，但重要页面不动”。这里“明显”和“重要”都不是脚本可判定条件。可执行的最小写法是：仅当标题与同目录另一页标题完全一致时标记待改写；若页面带有“保护”标记则跳过；两者都不满足时保持原样。这个版本覆盖面窄，但不会误改。
例外描述要包含四个字段，缺一个就容易返工
每条例外建议写成下面这组字段，而不是一句自然语言备注。
- 判定信号：脚本实际能读到什么，例如状态码、字段是否为空、清单中是否存在该URL。
- 成立条件：信号满足什么组合才算例外，避免“或”“且”混用导致歧义。
- 触发动作：跳过、记录、改写、通知，只能选一个主动作。
- 兜底走向：条件无法判断时做什么，通常是保持原样并写入日志。
例如写成：if 标题为空 and 页面不在保护清单: 记录并跳过。这里的“不在保护清单”必须由外部清单提供，脚本不负责判断页面重要性。若清单缺失，兜底动作应是全部跳过，而不是全部改写。动作结果会直接影响下一步：如果日志里大量出现“清单缺失”，说明先补权限或补清单，再谈批量执行；如果日志干净，才适合扩大规则范围。
一个反例：把“页面类型”当成例外条件，脚本会失效
有一种写法看起来合理，实际很容易让结论失效：把“详情页不改、列表页可改”直接写成规则，但脚本拿不到可靠的页面类型字段。它可能通过URL结构猜测，也可能通过页面上的某个元素判断。只要URL规则调整或页面模板变化，判断就会漂移。
此时不能推出“脚本判断页面类型不可靠，所以所有例外都该人工处理”。更准确的说法是：在缺少稳定页面类型来源的前提下，这条例外不具备可执行条件，应改为读取人工维护的URL清单，或先只处理能明确识别的子集。若你观察到某次执行中例外数量突然归零，也不能直接证明规则正确，合理解释还包括：清单没加载、权限失效、抓取范围缩小、页面本身减少。需要先核对输入数据是否完整，再判断规则是否生效。
缺数据缺权限时的最小动作与不能推出的结论
没有完整数据或后台权限时，仍可执行的最小动作是：选一小批已知页面，只写一条例外规则，运行后检查日志中的判定结果。动作的结果决定下一步：若例外判定与人工预期一致，可以增加第二条规则；若不一致，先修正判定信号，不要急着扩大范围。
这个动作不能推出的结论包括：不能证明全站规则成立，不能证明改动带来效果，也不能用一次执行前后的差异归因于脚本。前后比较还要考虑季节、搜索需求变化和数据采集差异。例外描述写得越接近可判定条件，脚本越不容易在无人值守时做出错误动作；反过来，把人工判断直接翻译成“视情况处理”，等于没有写需求。
