百度权重提升方法，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f8364fc9eb44.html
📄
百度权重提升方法，把人工经验写成脚本需求时怎样描述例外情况
结论是：先写清正常流程，再把例外写成“触发条件 + 判定证据 + 脚本动作 + 失败后去向”四段，而不是只写一句“遇到异常就跳过”。只有当例外能被独立复核时，脚本才不会把有效页面误判为无效；如果例外条件本身依赖人工感觉，结论就不成立，应先补证据字段再开发。
为什么例外描述决定脚本能不能用
人工做页面判断时，很多结论来自上下文：这个栏目是否长期更新、这个词是否和站点主营相关、这条收录波动是否伴随整站抓取变化。写成脚本需求时，这些上下文如果没被写成可读取的字段，执行者只能拿一个模糊阈值代替，结果就是该保留的被删、该处理的被漏。
一个常见反常现象是：脚本上线后处理量下降，看似“异常变少了”，但实际可能是判定条件过严，把原本该进入待处理队列的页面直接放过了。处理量归零不能单独证明规则正确，它也可能是抓取延迟、日志口径变化、页面模板改动或采集时间窗不同造成的。
例外描述的四段结构
每条例外都应能回答四个问题，缺一段就会把判断压力转移给写脚本的人。
- 触发条件：什么输入出现时进入例外分支，例如页面状态码、标题重复度、正文长度区间、链接层级或更新时间间隔。
- 判定证据：脚本能读取什么来确认，例如响应头、页面可见文本、站内链接关系、抓取时间戳。证据要能落成字段，不能只写“看起来像”。
- 脚本动作：进入例外后是跳过、标记待审、降级处理还是转人工，动作要唯一。
- 失败后去向：证据缺失、接口超时、字段为空时，任务进入哪个队列，由谁在什么条件下复核。
反例：什么写法会让结论失效
假设需求写成“如果页面质量低就跳过”。这里“质量低”没有可核对证据，脚本只能靠字数或关键词命中率代替。当站点新开一个短内容栏目时，脚本会把整批新页面跳过，人工再回来看时，已经错过了观察窗口。
这个反例说明：只要例外条件依赖人工主观判断，前面“先写四段结构”的结论就不成立。此时正确动作不是继续调阈值，而是回到业务侧，把“质量低”拆成可复核的具体情形，例如正文与标题主题偏离、页面主要链接指向站外、同一模板下内容重复度过高。拆不出来，就不应进入脚本开发。
用可核对证据区分不同解释
出现与直觉相反的结果时，先列证据再下结论。以下是一组假设比较，用来演示区分方法，不代表真实项目数据。
- 假设改动后抓取量下降：可能是规则拦截，也可能是采集时间窗错位、站点整体更新减少、日志字段变更。需要同时看改动前后同一时间窗、同一目录范围、同一日志口径。
- 假设处理量上升：可能是例外条件放宽，也可能是上游页面数量增加、模板批量生成、重复抓取。需要把页面去重后再比较。
- 假设待审队列变长：可能是判定证据缺失，也可能是人工复核速度下降。需要分开记录脚本标记量和人工处理量。
一次改动前后比较要考虑季节、搜索需求变化和数据采集差异，不能把统计相关直接当成因果。比较时至少固定目录范围、时间窗和日志口径，再判断变化来自规则还是环境。
下一步动作：先补证据字段再开发
如果四段结构写不全，先做一件事：把人工判断时实际看的信息列成字段清单，并标注每个字段的来源和缺失时的处理方式。字段清单完成后，再让脚本按字段组合进入例外分支。这个动作的结果会直接影响下一步——字段可读取，才进入开发；字段不可读取，就先补采集或改由人工复核，不把不确定判断塞进脚本。
只有例外能被独立复核，脚本才可能稳定替代人工经验；否则它只是把模糊判断换了一个执行位置。
