SEO优化技巧：把人工经验写成脚本需求时怎样描述例外情况，先分清三类例外：保留、改写、退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1d79229ed84f.html
📄
SEO优化技巧：把人工经验写成脚本需求时怎样描述例外情况，先分清三类例外：保留、改写、退出
直接回答：例外情况不要写成“特殊情况特殊处理”，而要写成可判定的条件、明确的动作和动作后的去向。脚本需求里最危险的不是漏写例外，而是把例外写成一句没有边界的备注，开发只能靠猜。判断标准很简单：把这条需求交给一个没做过你这项工作的人，他能否只根据文字决定“这条数据是保留、改写还是退出”。
先分清三类例外：保留、改写、退出
人工做SEO操作时，例外往往靠直觉处理。写成脚本需求时，先把每个例外归入三类之一，再写条件。
- 保留：原样通过，不进入自动处理。适用于人工判断价值高、但规则难以量化的条目。
- 改写：按指定规则生成新值，但保留原值以备回溯。适用于有明确替换逻辑的情况。
- 退出：不处理并记录原因，交给人工队列。适用于条件命中但缺少必要字段的情况。
三类的代价不同。保留会降低脚本覆盖率，退出会增加人工量，改写如果规则写错会静默污染数据。选择哪一种，取决于你更怕漏处理还是更怕错处理。
把“感觉不对”翻译成可判定条件
人工经验里最常见的描述是“这条看起来不对”。脚本无法执行这种判断，必须拆成字段级条件。一个可用的写法是：条件、证据字段、动作、去向，四段齐全。
假设一个场景：你有一批页面标题需要按规则改写，人工过去会跳过某类页面。不要写“重要的页面跳过”，而要写成类似下面的结构：
IF 页面类型 = 品牌词落地页 AND 标题长度 < 20 THEN 保留原值，记录原因=品牌页标题过短
这里的关键不是语法，而是每个条件都能从数据里取到值。如果“页面类型”这个字段本身不存在或不可靠，那么这条例外就无法执行，应改为退出并进入人工队列，而不是默认保留。
实际动作：先列出人工过去三个月内所有跳过处理的条目，逐条标注命中了哪个字段。如果某个例外找不到对应字段，说明它暂时不适合写成脚本，应归入退出类。
例外条件的顺序会影响结果
多个例外同时命中时，先判断哪一条决定了最终动作。顺序不同，结果可能完全相反。
例如一条记录同时满足“标题含品牌词”和“标题长度超限”。如果保留规则在前，它会原样通过；如果改写规则在前，它会被截断。两种做法都成立，但适用前提不同：品牌词优先级高时，保留在前；长度是硬约束时，改写在前。
建议在需求里显式写出优先级，而不是依赖开发默认的代码顺序。一个可检查的做法是：为每条例外编号，并在需求中写明“命中多条时取编号最小的一条”。这样后续出现争议时，可以追溯到具体规则，而不是争论哪条更重要。
用假设例子检验例外描述是否够用
假设你写了一条规则：标题含年份时改写为当前年份，但某些页面保留原年份。检验方法不是看规则本身，而是构造几条边界记录：
- 标题含两个年份，其中一个在品牌词内部。
- 标题含年份但页面类型字段为空。
- 标题不含年份，但正文含旧年份。
如果这三条在需求里都没有对应动作，脚本上线后大概率会出现人工没预期过的结果。补法不是增加更多备注，而是为每条边界指定保留、改写或退出，并说明依据哪个字段判断。
这个例子的数字仅用于说明比较方法，不代表任何真实项目的处理量。
上线后怎样判断例外写得对不对
例外规则的效果不能只看处理量变化。处理量下降可能来自规则生效，也可能来自数据源变化、采集时间不同或搜索需求本身波动。比较改动前后时，要固定数据窗口和采集口径，否则无法区分是规则起了作用还是外部因素。
一个可操作的检查是：抽取退出队列中的条目，人工判断其中有多少本应被自动处理。如果比例持续偏高，说明例外条件写得太宽，应收紧；如果保留队列里出现明显该改写的条目，说明优先级或条件写反了。
下一步动作取决于这个检查结果：退出队列准确率高，可以维持现状；误退出多，优先修条件而不是加规则；保留队列混入该处理项，先查优先级顺序，再考虑是否拆分例外。
