系统排名提升方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b16aa2574ab1.html
📄
系统排名提升方法：把人工经验写成脚本需求时怎样描述例外情况
写脚本需求时，例外情况不能只写“特殊情况特殊处理”，而要写成可判定的条件加明确动作：满足什么条件时保留人工判断、满足什么条件时改写为规则、满足什么条件时直接退出不处理。三者对应的是样本外推风险的不同等级，写清楚边界比写全流程更重要。
先定义什么叫“例外”，否则脚本无法判断
人工经验里常有一句“这种页面先别动”，但脚本读到这句话无法执行。要把例外写成可判定的形式，至少包含三个要素：判定字段、阈值或取值、命中后的动作。例如“当页面正文可提取字符数低于某个下限，且该页面仍有外部链接指向时，标记为待人工复核，不进入自动改写队列”。
这里的关键不是阈值取多少，而是阈值必须来自你实际观察到的分布，而不是凭感觉设一个整数。假设你抽查了若干页面，发现多数页面正文长度集中在一个区间，少数极短页面恰好是聚合页或跳转页——那么极短本身就是一类需要单独处理的样本，而不是需要调参的噪声。
保留、改写、退出：三种取舍各自成立的前提
保留人工判断
当例外样本数量少、但单个样本影响大时，保留人工环节更划算。典型前提是：这类页面数量占比低，但一旦处理错会牵连导航结构或核心入口。此时脚本的职责不是执行改写，而是把候选样本筛出来并输出判定依据，让人工在有限集合里做决定。动作是给每个命中样本附上触发原因，结果直接影响下一步是人工复核还是退回规则。
改写为规则
当例外能被拆成两三个稳定条件、且这些条件在历史样本中反复出现时，才值得改写成规则分支。前提是你能说清“什么样的情况属于这一类”，而不是“看起来像这一类”。如果连你自己都要逐个打开页面才能判断，说明条件还没抽象出来，此时改写只会把人工的模糊判断固化成脚本的硬错误。
直接退出
当例外无法用现有字段判定、且处理成本高于收益时，退出是合理选择。退出的含义是脚本明确不处理并记录原因，而不是静默跳过。动作上要求输出一条可追溯的记录，结果是你能在后续复查中统计这类退出的规模，判断它是否已经大到需要单独建规则。
用一组可区分原因的证据替代“经验之谈”
写需求时最容易犯的错是把结论当条件，比如“内容质量差的页面不要动”。质量差不是字段。可操作的写法是列出能区分原因的证据，例如：
- 页面是否承担站内跳转职能，可从出站链接占比判断；
- 页面是否由模板批量生成，可从正文重复片段比例判断；
- 页面是否长期无更新，可从最后修改时间与当前时间的差值判断。
这三条各自指向不同的处理方式：跳转页适合退出，模板页适合改写规则，长期未更新页适合保留人工判断。把它们混成一条“低质量”规则，等于放弃了区分能力。
一个注明假设的短例子
假设你有一批页面需要统一调整标题结构，人工经验是“标题里带品牌词的不要动”。写成脚本需求时，可以这样描述例外：如果标题中已包含品牌词，且该标题对应的页面在近一个观察周期内没有其他结构性改动，则标记为保留，不参与本次批量改写；如果标题含品牌词但同时命中另一条结构问题，则改为输出待复核记录，由人工决定是否覆盖。
这个例子的重点是：例外不是一刀切地排除，而是按命中条件的组合分流到保留或复核。动作不同，结果不同，下一步的入口也不同。
验证例外描述是否成立，靠的是前后比较的谨慎解读
写完例外条件后，不要急着用“改动后数据变了”来证明描述正确。一次改动前后的差异可能来自季节波动、搜索需求本身的变化，或数据采集口径的调整。更稳妥的做法是：先只对命中例外条件的样本做小范围处理，观察这批样本与未命中样本在同一时间段内的表现差异，再决定是否扩大适用范围。
如果某类样本的处理量、抓取量或某项统计在改动后归零，这不能单独证明例外条件写对了——也可能是采集方式变化、上游数据源调整，或该类样本本来就在减少。把这些合理解释一并列出，才能判断例外描述是否真的站得住。
最终判断标准很简单：把这份脚本需求交给另一个人，他能否在不问你任何问题的情况下，对同一个页面得出和你一样的保留、改写或退出结论。能，说明例外写清了；不能，说明还有条件藏在你的经验里，需要继续拆成可判定的字段和动作。
