Google搜索技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /32cecbb00e4b.html
📄
Google搜索技巧：把人工经验写成脚本需求时怎样描述例外情况
结论是有条件的：如果例外情况能用“可观察信号＋唯一处置动作”写清楚，就把它写进脚本需求；如果例外只能靠人的模糊判断，就先写成人工复核节点，不要硬塞进自动化流程。对Google搜索技巧类工作而言，最常见的失效反例是：脚本按规则跳过了某类页面，事后却分不清这是规则正确生效，还是页面本身根本没被处理到。
先分清两种例外，再决定写进脚本还是留给人
人工经验里的“例外”通常混着两类东西。一类是客观信号，例如返回状态、页面是否含某个结构化标记、链接是否指向站内、文本长度是否低于某个值。另一类是主观判断，例如“这个页面看起来像模板页”“这条结果质量不高”。前者适合写成脚本条件，后者适合写成待复核清单。
判断标准可以简化成一句：换一个人按同样输入操作，是否大概率得到同一个结论。如果会得到不同结论，就不该把它写成自动分支，而应写成“标记并暂停”的节点。这样做的代价是流程里多一次人工确认，但好处是例外不会被静默吞掉。
描述例外时要写清触发信号、处置动作和记录字段
一条可执行的例外描述至少包含三部分：什么信号触发它、触发后做什么、留下什么记录。缺任何一部分，脚本上线后都会变成无法复盘的黑盒。
- 触发信号：写可验证的条件，而不是“异常页面”“重要页面”这类无法判定的词。例如“同一路径下存在两个仅大小写不同的URL”。
- 处置动作：写明是跳过、降级、重试还是转人工。动作要唯一，不能写“视情况处理”。
- 记录字段：至少记录URL、命中规则、时间、当时抓到的关键值。没有记录，后续就无法判断是规则错了还是样本变了。
假设一个场景：你想让脚本跳过参数过多的URL。若写成“跳过看起来是重复的URL”，执行者无法判断；若写成“查询参数超过三个且不含分页参数时跳过，并记入待复核表”，就同时给出了边界和出口。这里的数字只是示例，实际阈值应由你自己的样本决定。
一个会让上述结论失效的反例
如果例外比例很高，把它写成人工复核节点反而会让流程瘫痪。比如某类页面在样本中占了大半，每次都转人工，脚本就失去了意义。这时正确的做法不是继续加规则，而是回到上游：先确认这类页面是否本就不该进入这个流程，或者是否需要单独拆成一条处理链路。
另一个反例是信号本身不稳定。若某个字段时有时无，用它做触发条件会导致同一页面时而命中、时而漏过。此时应先确认信号来源是否可靠，再决定是否采用，而不是用更多例外规则去补漏。
用一次小样本回放验证例外描述是否成立
写完需求后，取一批已知结果的URL做回放：脚本对每个URL的判定，与人工判定逐条对比。重点看两类差异——本该命中例外却没命中，以及不该命中却命中了。前者说明触发条件太窄，后者说明太宽。
回放结果会直接影响下一步：如果差异集中在某一种信号上，就修改该信号的判定方式；如果差异分散且无规律，说明这类例外还不适合自动化，应退回人工复核，等积累足够样本再重写。比较改动前后时要注意，搜索需求本身会随季节和事件变化，样本差异不一定来自你的规则改动，也可能来自外部环境。
把例外写成可交接的文本，而不是口头补充
最终交付给脚本的例外描述，应当能独立阅读：不依赖“和上次一样”“按老规矩”这类上下文。每条例外都对应一个可观察信号、一个唯一动作和一条记录。这样做的直接结果是，脚本运行后你能从记录里判断哪些是规则命中、哪些是人工介入，从而决定下一步是收紧条件、放宽条件，还是把某类例外移出自动流程。
