SEO实战经验：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9b7da1befacf.html
📄
SEO实战经验：把人工经验写成脚本需求时怎样描述例外情况
核心做法是：例外情况不要写成一句“特殊情况特殊处理”，而要写成“触发条件—判定证据—脚本动作—回退方式”四段式。触发条件说明什么数据形态会进入例外；判定证据说明脚本用什么字段或阈值识别它；脚本动作说明是跳过、标记还是转人工；回退方式说明动作失败后停在哪里。缺任何一段，开发只能猜，交付后你仍然要手工兜底。
先选对象：你手里那份页面清单能不能直接转成需求
假设你手上有一份人工整理的页面清单，字段包括URL、页面类型、目标词、当前标题、内链数量。人工处理时，你看到“内链数量为0”会顺手补链；看到“页面类型为聚合页”会先判断是否值得补。脚本没有这种临场判断，所以需求里必须把这两类分叉写清楚。
此时会碰到两种看似合理的写法。第一种是把例外写成白名单：只有清单里列出的页面类型才处理，其余全部跳过。第二种是把例外写成黑名单：默认全部处理，只排除明确不处理的类型。选择条件取决于页面类型的可枚举程度。
- 如果页面类型只有三五种、且未来新增类型仍需人工确认，用白名单更稳，代价是新增类型时脚本不处理，需要你更新需求。
- 如果页面类型开放、长尾形态多，用黑名单更省事，代价是误处理风险落在你身上，必须为每类排除项写出可验证的判定证据。
以聚合页为例，黑名单写法不能只写“排除聚合页”，而要写成：URL包含/tag/或/category/，且页面标题与目标词完全一致时，标记为待确认，不自动改写。这样开发能直接落成判断，你复查时也能逐条核对。
把例外拆成四段：触发、证据、动作、回退
人工经验里最常见的模糊表达是“这个页面不太合适”。脚本需求要把它翻译成可执行结构。以下四段可以直接套在你手里的清单上。
- 触发条件：什么输入会让脚本进入例外分支。例如“目标词为空”“内链数量为0”“页面类型不在已确认列表内”。
- 判定证据：脚本读哪个字段、和什么比较。例如“目标词字段为空字符串”“内链数量字段等于0”。
- 脚本动作：进入例外后做什么。可选跳过、写入待确认表、只记录日志、转人工队列。动作要单选，不要写“视情况处理”。
- 回退方式：动作执行失败或结果不符合预期时停在哪里。例如“写入待确认表失败则整批中止，不继续处理后续页面”。
一个假设例子：清单里某页面目标词为空，但内链数量为3。若触发条件只写“目标词为空”，脚本会跳过它，可你人工处理时可能仍想补内链。此时应把触发条件拆成两条：目标词为空且内链数量为0，跳过；目标词为空但内链数量大于0，标记待确认。这样脚本动作不同，你复查的优先级也不同。
例外描述里最容易漏掉的三类边界
第一类是空值和缺失值的区别。字段为空字符串、字段不存在、字段值为“未知”，在脚本里是三种状态。需求里要分别写明，否则开发可能统一按空处理，导致本该转人工的页面被静默跳过。
第二类是阈值型例外。人工经验常说“内链太少就补”，脚本需要明确少到多少。假设你写“内链数量小于2”，那么数量为0和1都进入例外。这个阈值是你定的，不是平台规则，改阈值就要同步改验收标准。
第三类是互斥条件。若同一页面同时命中“目标词为空”和“页面类型为聚合页”，脚本应按哪个分支走？需求里要给出优先级，例如先判断页面类型，再判断目标词。优先级不写，开发实现顺序不同，结果就不同。
这些边界不影响脚本能否跑通，但影响你拿到结果后要不要二次返工。返工成本通常高于写需求时多花十分钟。
用一个小验收动作检验例外描述是否够用
写完需求后，不要直接交给开发。先拿清单里最反常的三条记录，手工走一遍你写的四段式，看能否得出唯一动作。如果三条里有一条让你犹豫，说明对应例外还没写清。
具体动作：把这三条记录逐条填入触发条件、判定证据、脚本动作、回退方式。填完后问自己——换一个人按这份需求执行，会不会做出和我一样的选择。如果会，需求可交接；如果不会，回到上一步补证据字段。
这个动作的结果直接决定下一步：三条都能唯一判定，就可以进入脚本实现；有一条不能，就先补该条的证据字段，再重新验收。不要用“先跑起来再补”绕过它，例外分支的返工往往比主流程更贵。
改动前后比较时，别把一次波动当成结论
脚本按例外规则跑完后，你可能会比较处理前后的页面表现。这里要注意，一次改动前后的差异可能来自季节、搜索需求变化或数据采集口径不同，不能单独归因于脚本处理。比较时应固定同一批页面、同一统计口径，并记录例外分支实际命中了多少条。命中数量为0，可能是规则确实没触发，也可能是字段读取失败，需要先排查数据采集，再判断规则是否有效。
把例外写清楚，真正的收益不是脚本一次跑对，而是你下次改规则时知道该动哪一段、动了之后哪一批页面会受影响。这份可交接的需求，才是人工经验转成脚本后仍然可控的前提。
