权重提升方法：把经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /99c0d4bc3e11.html
📄
权重提升方法：把经验写成脚本需求时怎样描述例外情况
把人工经验写成脚本需求时，例外情况应写成“触发条件 + 判定证据 + 执行动作 + 记录方式”四段式，而不是只写“特殊情况另行处理”。你手上那份资料或页面，先找出人工操作时真正会停下来判断的位置，再把每个判断转成可执行的规则。下面以一份“页面内容质量巡检”的人工经验为例，逐步说明怎么落成脚本需求。
先分清两类例外：可判定的与需要人接手的
人工经验里常混着两种例外。第一种是条件明确、脚本能自行判定的，例如“正文少于 300 字且页面类型为文章”。第二种是条件模糊、必须交给人处理的，例如“内容看起来像拼接的”。两者的描述方式完全不同。
- 可判定例外：写成明确的字段与阈值，脚本直接执行动作，例如标记、跳过或转人工。
- 需人接手例外：写成触发信号加转交流程，脚本只负责筛选和记录，不替人下结论。
如果你把第二类硬写成阈值，脚本就会在边界样本上频繁误判；如果把第一类也交给人工，等于没有自动化。取舍条件是：判定依据能否用现有字段稳定表达。能，就写进脚本；不能，就写转人工，并注明转交后由谁看、看什么。
把每个例外写成四段式，而不是一句话
以“文章页正文过短”为例，人工经验常写成“太短的就别管了”。这句话无法执行。改成四段式：
- 触发条件：页面类型为文章，且正文字段去标签后字符数小于 300。
- 判定证据：记录正文字符数、页面类型字段、抓取时间。
- 执行动作：不进入本轮优化清单，写入待观察列表。
- 记录方式：输出页面地址、命中规则名、字符数，供下一轮复核。
这样写的好处是，任何人拿到需求都能判断脚本是否做对。假设同一批页面里，有 40 个因字数不足被排除，其中 15 个其实是图集页被误标为文章页，那么下一步不是调低阈值，而是先修页面类型字段，再重跑。这个动作的结果会直接决定你是改规则还是改数据源。
例外之间的优先级要显式写出
多个例外同时命中时，脚本必须有确定的处理顺序，否则同一页面在不同运行中会得到不同结果。常见冲突是“低质内容”与“高流量页面”同时命中。
一种做法是流量优先：高流量页面即使命中低质规则也保留，进入人工复核。另一种做法是质量优先：低质规则直接排除，不看流量。两种都成立，但代价不同。流量优先会漏掉一部分真正该处理的页面，但避免误伤；质量优先处理更彻底，但可能把有实际需求的页面排除在外。
选择条件是：你更怕漏处理，还是更怕误伤。若本轮目标是清理明显问题，选质量优先；若目标是稳中求进，选流量优先，并把冲突样本单独记录。这个决定会影响后续复核的工作量，因此要在需求里写明，而不是留给脚本作者猜。
用一份假设样本验证例外描述是否可执行
假设你手上有 100 个页面，按上述规则跑一遍，得到：正常进入清单 60 个，字数不足排除 25 个，类型字段缺失转人工 10 个，流量与质量冲突转人工 5 个。
如果转人工的 15 个里有 12 个其实是同一类字段缺失，说明例外描述里“转人工”用得太宽，应把字段缺失单独拆成一条可判定规则。如果 5 个冲突样本里多数最终被判定为应处理，说明流量优先的代价偏高，下一轮可改为质量优先。这个比较方法只用于说明如何用结果反推规则，不构成对任何实际数据的预测。
比较改动前后时要注意，搜索需求本身会随季节变化，采集时间不同也会带来差异。某次统计归零或某项数量下降，不能单独证明规则改对了，也可能是抓取范围、字段口径或需求波动造成的。要同时看命中规则分布和转人工比例，再决定下一步。
需求文档里必须留出的三个字段
无论你选哪种处理顺序，脚本需求都应包含：规则名、命中证据、下一步动作。规则名让复核时能定位；命中证据让判断可追溯；下一步动作决定页面是进入清单、排除还是转人工。
写完后再做一次检查：把每个例外读成一句“当……且……时，脚本做……，并记录……”。读不通的地方，就是还需要补条件或补动作的地方。按这个方式改完，人工经验才真正变成可执行、可复核、可迭代的脚本需求。
