seo手段，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /96ea621dee0e.html
📄
seo手段，把人工经验写成脚本需求时怎样描述例外情况
先给结论：例外情况不要写成“特殊情况另行处理”，而要写成可判定的条件分支。人工判断时，你能凭感觉决定停手、跳过还是换策略；脚本没有这种感觉，它只能识别你写清楚的输入特征。因此，写需求时最该先定的是：哪些情况必须中止，哪些情况可以降级执行，哪些情况只能记录后继续。
先分清两类例外：可判定与不可判定
人工经验里最容易被忽略的，是“我看到这个页面就不想动它”。这句话对人是有效指令，对脚本不是。要把经验转成脚本需求，先做一个分类动作：把每条经验拆成观察项和处置项。观察项必须是脚本能读到的信号，例如状态码、标题长度、正文与模板的重复比例、链接是否指向站外、页面是否包含特定结构化数据。处置项则是脚本要执行的动作，例如跳过、仅记录、降低优先级、进入人工复核队列。
可判定的例外，条件是明确的。例如“当页面返回正常状态码，但正文段落数量低于某个阈值时，不自动改写标题，只写入待复核清单”。这里阈值可以按站点历史数据设定，动作也明确。不可判定的例外，往往依赖人的语义理解，例如“看起来像凑数的内容”。这类条件不要硬塞进脚本，而应转化为代理指标，例如正文与导航文本的比例、同一模板下正文相似度、页面内链数量是否异常偏低。代理指标不完美，但比“看起来像”可执行。
实施动作：拿一份近期人工处理记录，逐条标注“观察项”和“处置项”。如果一条记录里观察项无法用现有字段表达，就把它移入人工复核范围，而不是强行写成脚本规则。这个动作的结果会直接决定下一步：可判定例外进入自动化分支，不可判定例外进入抽样复核，避免脚本把人的犹豫误判为确定指令。
两种条件下的不同选择：中止还是降级
条件一：例外会影响整批任务的方向。比如脚本准备批量调整页面标题，但抽样发现某类页面的标题与正文主题明显不一致。此时应选择中止整批任务，先输出差异清单，而不是继续执行。理由是，如果方向本身错了，后续动作越多，回退成本越高。中止的结果是得到一份可核对的差异样本，下一步是人工确认这类页面是否属于同一模板或同一栏目，再决定是否缩小任务范围。
条件二：例外只影响个别页面，且不会污染其他页面。比如脚本逐页检查内链时，遇到一个页面没有可用锚文本。此时可以选择降级执行：跳过该页的内链改写，只记录页面标识和原因，继续处理其余页面。降级的结果是任务整体完成，但留下待处理清单。下一步是根据清单判断是模板缺少锚文本字段，还是编辑习惯导致，再决定改模板还是补内容。
这两种选择的分界不是例外数量多少，而是例外是否改变任务假设。改变假设就中止，不改变假设就降级。把这条判断写进需求，脚本才能在遇到意外输入时保持行为一致。
用可核对证据区分“直觉相反”的解释
人工经验写成脚本后，常出现与直觉相反的结果：原本以为会提升页面质量的改动，执行后某些指标反而下降。不要急着归因于脚本写错，也不要直接认定策略无效。先收集三类可核对证据：改动前后的页面集合是否一致、统计周期内搜索需求是否发生季节变化、数据采集口径是否因脚本运行时间而不同。
假设一个短例子：某次脚本给一批页面补充了内部链接，随后观察到这些页面的平均点击量下降。这里至少有三种合理解释。第一，被链接的页面集合中混入了本就不应获得流量的页面，平均点击被拉低。第二，统计周期恰好覆盖了搜索需求下降的时段。第三，脚本运行时间与数据采集时间重叠，导致部分数据未完整计入。要区分它们，动作是固定同一批页面，分别对比改动前一个完整周期和改动后一个完整周期，同时记录搜索需求变化和采集时间。这个动作的结果会决定下一步：如果是页面集合问题，就缩小链接范围；如果是周期问题，就延长观察；如果是采集问题，就调整统计窗口。
这里的关键不是证明某个原因一定成立，而是排除明显不成立的解释。请求量或抓取量归零，也不能单独证明处理正确，它可能来自采集失败、屏蔽规则变化或任务未实际运行。只有把多个证据放在一起，才能判断例外处理是否按预期生效。
把例外写成脚本可执行的分支结构
描述例外时，推荐用固定结构：触发条件、判定依据、执行动作、记录字段、后续归属。触发条件写脚本能读到的字段；判定依据写阈值或比较方式；执行动作写跳过、中止、降级还是继续；记录字段写页面标识、原因码、时间；后续归属写进入人工队列还是自动重试。
例如，把“标题与正文主题不一致时不改标题”写成需求，可以落成：当页面正文与标题的词汇重叠低于设定阈值时，不执行标题改写，记录页面标识和重叠值，进入人工复核队列。阈值需要注明假设，例如“按历史人工复核通过率反推”，而不是拍一个固定数字。脚本运行后，人工复核队列的长度和原因分布，就是下一步调整阈值的依据。
还要写明例外不适用的情况。例如，当页面本身是聚合页或列表页时，正文与标题重叠低可能是正常现象，不应触发同一分支。这类边界条件如果不写，脚本会把正常结构误判为例外，导致大量无效记录。记录字段里保留页面类型，能帮助后续区分。
上线前用抽样验证例外分支是否真的被触发
需求写完不等于例外处理正确。上线前做一个抽样动作：从目标页面集合中抽取包含已知例外和已知正常页面的样本，运行脚本，检查例外分支是否按预期触发，正常页面是否被误伤。样本要覆盖至少两种页面类型，避免只测单一模板。
检查结果会影响下一步。如果例外分支没有触发，先确认触发条件里的字段是否在数据源中存在，而不是直接放宽阈值。如果正常页面被误判，先检查判定依据是否缺少页面类型过滤，而不是删除整个例外分支。只有确认分支触发正确、误判可解释，才进入更大范围运行。
最后，把每次例外处理的结果记录下来，包括触发次数、人工复核结论和后续调整。这些记录不是额外负担，而是下一次写脚本需求时最可靠的依据。例外情况描述得越具体，脚本行为越可预测，人工经验才真正变成可复用的操作规则。
