单页面优化技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /53f11ecadc31.html
📄
单页面优化技巧：把人工经验写成脚本需求时怎样描述例外情况
把人工优化经验写成脚本需求，例外情况不能只写一句“其他情况照常处理”，而要写成可判定的条件分支：先说明正常路径，再列出触发例外的可观察信号，最后规定脚本遇到例外时是跳过、降级还是停止并报告。判断标准是执行脚本的人或程序能否在不询问原作者的情况下做出同一个决定。
先假设一个短情境：单页优化脚本要自动处理标题和描述
假设你负责一个已有实际业务的产品站，单页面优化一直由人工完成。现在关键前提变了：页面数量增加，人工逐页检查标题、描述和内链锚文本的成本太高，于是要把经验写成脚本需求。人工操作时的习惯是“标题太长就改短，描述重复就重写”，但这句话交给脚本执行会立刻卡住：多长算太长，重复到什么程度算重复，改短之后是否还要保留品牌词，脚本无法从这句话里得到答案。
例外情况要解决的正是这类空白。它不是补充说明，而是需求的一部分。缺少例外描述的脚本，遇到边界数据时只能按默认逻辑处理，结果往往与人工判断相反。
例外要写成可判定的条件，而不是感受描述
人工经验里最常见的表达是“看起来不合适”“明显重复”“感觉太生硬”。这些描述对人有效，对脚本无效。转写时要把感受替换成可观察的信号，并且给每个信号规定阈值来源。
- 长度类例外：不写“太长”，而写“超过某个字符数上限时进入待处理队列”，上限值来自当前模板的展示约束，而不是凭印象设定。
- 重复类例外：不写“重复”，而写“与同站其他页面的描述文本相似度超过设定比例时标记”，并说明相似度按什么单位计算。
- 缺失类例外：不写“没有关键词”，而写“目标字段为空或只含标点时，不自动生成，直接输出待补清单”。
- 冲突类例外：不写“互相矛盾”，而写“两个规则同时命中且修改方向相反时，停止执行并记录冲突规则编号”。
这样写的好处是，脚本遇到边界数据时行为可预测。更实际的动作是：先拿一批已经人工处理过的页面做回放，让脚本在只读模式下输出它会标记哪些例外，再与人工当时的判断逐条对照。对照结果直接决定下一步是放宽阈值还是增加分支，而不是直接上线改数据。
变化前后要采取不同决策：什么条件下继续自动化，什么条件下退回人工
例外描述写完后，还需要规定例外出现时的处置方式。这里存在一个明确的分界：例外是偶发的个别现象，还是集中出现在某一类页面上。
如果回放结果显示例外分散、每条都能对应到具体字段问题，可以继续自动化，把例外输出成清单交人工复核。如果例外集中出现在同一模板、同一栏目或同一批历史页面上，说明规则本身没有覆盖这类页面，此时应暂停对该类页面的自动修改，先补充规则或改为人工处理。判断依据不是例外数量多少，而是例外是否成簇。成簇意味着存在未被描述的页面类型，继续自动执行会把同一类错误批量放大。
这个分界也适用于前提变化。当页面模板改版、字段含义调整或内容来源更换时，原有例外条件可能整体失效。此时应重新做一次只读回放，确认例外分布是否改变，再决定沿用旧规则还是重写。跳过这一步，等于用旧前提下的判断处理新前提下的数据。
脚本需求里例外描述的最小结构
为了让需求可交接，每条例外至少包含四部分：触发条件、判断依据、处置动作、报告方式。可以用下面的顺序组织，不必追求形式统一，但四部分缺一不可。
- 触发条件：什么字段、什么取值、什么组合会进入例外。
- 判断依据：阈值从哪来，是模板约束、历史人工记录还是业务规则。
- 处置动作：跳过、降级处理、停止执行三者选一，并写明选择理由。
- 报告方式：例外记录包含哪些字段，交给谁复核，复核后如何回流到规则。
假设某条规则的触发条件是描述字段为空，判断依据是“空值无法自动生成有效描述”，处置动作是“不修改，输出待补清单”，报告方式是“按页面地址汇总，交内容负责人”。这四部分写清后，执行者不需要再问“空值到底改不改”。
需要提醒的是，用改动前后的数据比较来验证规则效果时，要考虑季节、搜索需求变化和数据采集差异。某段时间某项统计归零或下降，不能单独证明规则处理正确，也可能来自采集口径变化、页面未被访问或需求本身波动。验证应尽量固定比较口径，并保留人工判断记录作为参照。
把例外当成需求主体，而不是附注
人工经验转脚本，难点从来不是正常路径，而是正常路径之外的那些页面。例外描述写得越具体，脚本的可执行边界越清楚，人工复核的负担越可控。实际动作上，先做只读回放、再根据例外是否成簇决定自动化范围，比直接写规则上线更稳妥。这个顺序本身就是单页面优化技巧从人工走向脚本时最值得保留的部分。
