把人工判断写成脚本需求,例外情况不能只写一句“特殊情况特殊处理”。可执行的做法是:先选定你手里一个正在处理的旧页面或旧资料,把人工每次做决定时看的那几个信号写出来,再为每个信号规定“满足什么条件才走例外分支、例外分支做什么、做完之后回到哪一步”。脚本需求描述的是判断路径,而不是操作员的直觉。
人工经验里最常见的含糊表述是“看起来不对就改”。脚本读不懂“看起来”。你需要把这句话翻译成一个能被程序判断的条件,通常来自页面本身、抓取结果或配置数据。
假设你正在清理一批旧页面,其中一部分要退出、一部分保留。人工判断时可能看的是:这个页面还有没有从其他页面指向它的链接、它是否仍在站点导航里、它的内容是否已经过时。这三件事都可以变成条件。
这一步的产出是一张信号表:信号名称、数据来源、判断条件、谁来提供。没有这张表,后面的例外分支就没有落脚点。
“例外”这个词太粗。写成脚本需求时,至少要区分三种情况,因为它们的处理动作完全不同。
区分的价值在于:第一类可以批量跑,第二类需要人看一眼再放行,第三类需要先补数据。如果三类混在一起,脚本要么误删有价值的内容,要么把所有页面都推给人工,等于没省事。
下面是一个假设例子,数字仅用于说明比较方法,不代表任何真实项目的阈值。
假设你给旧页面退出定了一条规则:入站内链数小于 2,且页面最近一次内容更新距今超过 18 个月,则标记为候选退出。但你还想保留那些虽然内链少、却仍在导航里的页面。
写成脚本需求时,可以这样描述:
关键在最后一条:动作的结果要能被下一步读到。如果脚本处理完不写回状态,下一轮你无法区分“已经处理过”和“从未命中规则”,例外判断就会重复发生。
执行这条规则后,你可能会发现候选退出清单比预想的长。这时不要急着放宽阈值,先看命中的页面里有多少是“保留并复查”。如果这一类占比很高,说明导航这个信号在你的站点里权重被低估了,应该把它提前到第一层判断,而不是留在例外分支里。
第一,数据缺失怎么办。入站内链数取不到、更新时间字段为空,这些不是“等于 0”,而是“未知”。未知应该走暂停或跳过,不能当成满足条件。
第二,例外分支的出口在哪里。每个例外处理完,要么回到主流程,要么进入人工队列,要么终止。没有出口的分支会让脚本卡住或静默丢弃页面。
第三,谁负责补数据。如果例外是因为某个字段没人维护,脚本需求里要写明这个字段由谁提供、多久更新一次。否则例外会长期堆积,规则形同虚设。
把这三件事写进需求,脚本才可能在你不盯着的时候也做出接近人工的判断。
拿你手上那个旧页面对象,先按新写的条件手动跑一遍,看它落入哪个分支、分支动作是否符合预期。再换两三个边界页面试:一个内链刚好等于阈值,一个更新时间刚好在边界,一个字段为空。如果这三个都能得到你认可的结果,说明例外描述基本可用。
比较改动前后时要注意,搜索需求本身会随季节和热点变化,页面流量或抓取量的升降不能单独归因于这次脚本调整。更稳妥的做法是固定观察同一批页面在相同周期内的处理结果,看的是“命中分支是否符合预期”,而不是流量数字本身。
如果边界页面仍然需要你临时拍板,说明还有一条判断规则没被写出来。把它补进信号表,再重跑边界用例,直到脚本的输出和你的判断一致为止。