seo实战：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ad213b1129ec.html
📄
seo实战：把人工经验写成脚本需求时怎样描述例外情况
描述例外情况的关键，是把它写成一条可判定的规则，而不是一句“遇到特殊情况人工处理”。人工经验里最值钱的部分恰恰是例外，脚本需求如果只写正常路径，执行者遇到反常结果时只能猜，最后得到的数据无法支撑下一步决策。以下从一种常见矛盾现象切入，说明两种解释、区分证据，以及需求文档里该怎么落笔。
矛盾现象：脚本按经验跑，结果却和人工判断相反
假设你长期手工整理一批页面，凭经验认定“标题重复的页面优先处理”。写成脚本后，脚本把标题重复的页面全部排到队列前面，你抽查时却发现其中一批根本不该动。同一个经验，人工执行时没出问题，脚本执行时出了偏差，原因通常不在经验本身，而在经验被压缩成规则时丢掉了隐含前提。
这类矛盾在seo实战里很常见，因为人工判断依赖的是“看一眼就知道”的上下文，而脚本只认字段。把上下文补进需求，比争论经验对不对更有用。
两种解释：经验本身有边界，还是判定口径不一致
第一种解释是经验有隐含边界。人工说“标题重复优先处理”时，脑子里自动排除了模板页、分页和参数页，但这些排除条件从没被写下来。脚本没有这层默认，于是把不该动的页面也纳入了。
第二种解释是判定口径不一致。人工判断“重复”时可能只比较主体部分，脚本比较的是完整标题字符串，两者对同一个页面给出不同结论。此时经验没变，是“什么算重复”这件事在两套执行方式里定义不同。
两种解释的处置方式完全不同：前者要补例外清单，后者要统一判定字段。搞错方向，改完脚本仍会对不上人工结论。
区分两种解释的证据：换一个人按规则重跑
能区分二者的证据，是让另一位同事严格按你写下的规则手工判断同一批样本，再和你的原始判断比对。
- 如果同事按规则得出的结论和你不一致，说明规则本身缺少你脑中的隐含边界，属于第一种解释。
- 如果同事按规则得出的结论和你一致，但和脚本输出不一致，说明规则没问题，是脚本实现或字段口径的问题，属于第二种解释。
这个动作的价值在于：它把“我觉得脚本不对”变成了一条可核对的证据。样本不用大，覆盖你怀疑出问题的那几类页面即可。
需求文档里描述例外的写法
例外不要写成“其他情况人工判断”，而要写成“当某字段满足某条件时，执行某动作，并记录某标记”。可操作的结构是三段：触发条件、处理动作、留痕字段。
- 触发条件：写清判定依据的字段和比较方式，例如“标题字段去掉站点名后仍与其他页面完全相同”。
- 处理动作：写清是跳过、降级还是单独归入一个队列，避免“视情况而定”这类无法执行的表述。
- 留痕字段：要求脚本输出命中例外的原因码，方便你事后抽查，而不是只看最终列表。
举个假设例子：你要求脚本把“标题重复”的页面排前，同时规定“若页面属于分页或参数变体，则跳过并标记为变体”。执行后如果跳过数量远超预期，先别急着改阈值，去看标记原因码集中在哪一类，再决定是收紧条件还是补充新的例外。这个动作会直接影响你下一步是改规则还是改实现。
例外清单的维护边界
例外不是越多越好。每加一条，脚本的可解释性就下降一分。判断是否该加，可以问：这条例外能否用现有字段稳定判定？如果只能靠“看起来像”，就暂不写进脚本，改为输出到待人工复核队列。
另外，一次改动前后的比较要考虑季节和搜索需求变化，别把结果差异全归给脚本。请求量或抓取量归零也不能单独证明处理正确，它同样可能来自采集波动或需求本身下降。把例外描述清楚，是为了让每次判断都有据可查，而不是为了追求一次到位的自动化。
