权重提高方法，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d94b8e30a1e5.html
📄
权重提高方法，把人工经验写成脚本需求时怎样描述例外情况
结论先说：例外情况不能写成“遇到特殊情况再处理”，而要在需求里写清触发条件、默认动作、人工接管点和留痕字段。只有满足三个前提，脚本才能替人做判断：触发条件能从数据里读到，默认动作不会造成不可逆后果，人工接管有时间窗口。缺少任何一条，例外就必须停住等人工确认，而不是让脚本自己猜。这样写出来的需求，才会让权重提高方法从个人手感变成可复用的流程。
先分清哪些例外该写进脚本，哪些只能留给人
把人工经验转成脚本需求，第一步不是写代码，而是给例外分类。可以用一条判断线：这个例外出现时，下一步动作是否依赖只有人才能拿到的信息。如果依赖，就不该写成自动分支。
- 可枚举的例外：字段缺失、数值越界、同一对象出现两条冲突记录。这类例外有明确边界，适合写成脚本里的条件分支，并规定默认动作。
- 需要语义判断的例外：两段内容哪段更贴近用户意图、某个改动是否伤害品牌调性。这类例外应写成“标记并转人工”，脚本只负责把证据收集齐。
- 低频但后果重的例外：会影响已发布页面的批量操作。即使能枚举，也应默认暂停，等人工确认后再继续。
这里有个常被忽略的动作：在需求里为每条例外写一个exception_id，并规定它出现在日志的哪个字段。这个动作的结果是，脚本跑完后你能按例外类型统计发生了多少次，而不是只看到“成功”或“失败”。下一步该收紧哪条规则，就有了依据。
描述例外时必须写全的四个要素
很多脚本需求失败，不是因为逻辑错，而是因为例外描述缺项。缺一项，执行者就会用自己的理解补上，结果和原始经验偏离。建议每条例外都写全下面四项。
- 触发条件：用数据字段和比较关系描述，例如“同一目标对象在两次采集中的主字段值不同”。避免写“看起来不对”这类无法执行的描述。
- 默认动作：例外发生时脚本先做什么。常见选择是跳过、标记待处理、或按保守值继续。要写明选哪个以及为什么。
- 人工接管点：人在哪一步介入，看到什么信息后做决定。如果没有人可以及时介入，默认动作就必须足够保守。
- 留痕要求：例外发生时记录哪些字段，方便事后区分是规则问题还是数据问题。
举个假设的例子说明比较方法。假设你写了一条规则：某页面连续两次观察的主指标都低于同类页面的中位水平，就进入优化队列。例外是“该页面刚改过主字段”。如果需求只写“刚改过的不处理”，执行者无法判断“刚”是几天。写成“最近一次主字段变更距本次观察不足一个采集周期”才可执行。这个例子里数字只是说明比较方法，不代表任何真实阈值。
出现与直觉相反的结果时，先别改规则
脚本上线后，常出现一种反常现象：例外数量没有下降，反而集中到某一类。直觉反应是规则写错了，但更常见的原因是数据采集口径变了，或者搜索需求本身在波动。这两类原因的处理方式完全不同。
可以用一组可核对的证据来区分：
- 如果例外集中出现在某个时间段，且该时间段内采集频率或字段范围有调整，优先怀疑采集差异，而不是规则失效。
- 如果例外分散在不同时间段，但都指向同一类对象，优先怀疑规则边界没覆盖到这种对象。
- 如果例外数量整体变化，同时外部需求也在变化，不能只凭一次前后对比就断定改动有效。季节、需求波动和采集差异都可能造成同样的现象。
这里要强调一个反例，它会让前面的结论失效：如果例外本身就被定义错了，那么无论采集多稳定、规则多清晰，统计出来的例外数量都不能说明流程在变好。比如把“人工判断为可优化”直接写成触发条件，脚本永远无法稳定执行，因为判断标准没有落到字段上。此时正确的下一步不是调阈值，而是回到人工经验，把判断依据拆成可读字段。
一个可执行的下一步：先跑影子模式再接管
不要一上来就让脚本执行动作。先让它以影子模式运行，只记录“如果按规则执行会做什么”，不真正改动任何对象。运行一个完整采集周期后，按exception_id汇总，检查三件事：例外是否都能归到预设类别，默认动作是否产生过不可逆后果，人工接管点是否真的有人及时处理。
如果这三项都通过，再把默认动作从“仅记录”切换为“执行并留痕”。切换后继续观察一个周期，重点看例外结构有没有变化。如果例外从“未知类型”转为“已知类型”，说明规则覆盖在变好；如果未知类型比例没降，说明需求里还缺少可读字段，下一步应补字段而不是加规则。这个动作的结果直接决定你是继续自动化，还是先回到人工经验里补描述。
权重提高方法最终依赖的是可复现的判断，而不是某个人记得住多少例外。把例外写清楚，脚本才不会在关键时刻替你做错决定。
