降权恢复方法，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a2ca713e2383.html
📄
降权恢复方法，把人工经验写成脚本需求时怎样描述例外情况
有条件的结论是：例外情况要写成“触发条件 + 观察对象 + 允许的处置动作 + 需要人确认的边界”，而不是写成“遇到特殊情况再判断”。如果只写后者，脚本执行者只能按自己的理解补默认值，多个角色对同一事实的分歧就会变成执行事故。反例是：当恢复动作本身依赖人工目视、平台接口未开放或判断标准尚未稳定时，把例外写成脚本分支反而会制造假确定性，此时应把该步骤保留为人工节点，只让脚本负责收集证据。
先区分三种分歧，再决定写进脚本还是写进人工节点
多个角色对同一事实理解不同，通常不是谁不认真，而是分歧来源不同。写需求前先归类，处理方式完全不同。
- 定义分歧：同一句话指的对象不同。例如“页面已恢复”在编辑眼里是能正常打开，在技术眼里是返回状态与预期一致，在运营眼里是流量回到某个区间。这类分歧必须先在需求里固定字段名和取值来源。
- 阈值分歧：对象一致，但判断标准不同。例如“异常”是连续两天低于基线，还是单日跌幅超过某个幅度。这类分歧要写成参数，并注明基线怎么取、样本不足时怎么办。
- 处置分歧：事实一致，但该做什么不同。例如发现页面内容被替换，是回滚、重发还是先冻结。这类分歧要写成允许动作清单和升级路径，不能留给脚本自行选择。
实际动作：拿一张表，把每个分歧按这三类归档，再给每条标注“脚本可判”“脚本只记录、人判断”“必须人工执行”。这一步的结果会直接决定后面例外描述的粒度——被标为“脚本只记录”的条目，不需要写处置逻辑，只需要写清楚记录哪些字段、交给谁。
例外描述的四个字段，缺一个就会产生新歧义
把例外写成可核对的项目，最小结构是四个字段。
- 触发条件：写可观察的事实，不写主观判断。可写“同一路径在两次采集中的标题字段不一致”，不写“页面看起来不对”。
- 观察对象：指明取哪个字段、哪个时间窗、哪个来源。时间窗要写清楚是自然日还是滚动周期，避免不同角色各按各的口径统计。
- 允许的处置动作：列出脚本可以自动执行的动作，并写明动作的上限，例如只记录不修改、只标记待处理、可执行一次回退。
- 人工确认边界：写清楚什么情况下必须停下来等人。边界要具体到可判断，例如“同一对象在窗口内被标记两次以上”或“涉及删除、覆盖类操作”。
假设一个例子：某站点在降权恢复期间由脚本每天核对一批页面的标题、正文长度和内部链接数。需求里写“标题异常时处理”。执行者甲把“异常”理解为与基线不同，执行者乙理解为与上一次采集不同。结果同一批页面被反复标记，人工复核量翻倍。改成四字段后：触发条件为“标题字段与基线不一致且连续两次采集一致”，观察对象为“标题字段、基线快照、采集时间”，允许动作为“仅记录并生成待办”，人工边界为“同一路径七天内出现两次待办”。改动后，标记量下降，但下降本身不能证明判断正确——也可能是采集时间调整导致样本变化，需要对照同期搜索需求波动再确认。
哪些例外不该写成脚本分支
以下情况写进脚本会制造假确定性，保留人工节点更稳。
- 判断依赖目视或语义理解，例如正文是否被替换成近似内容、页面主题是否偏移。
- 判断所依赖的数据源本身不稳定，或采集口径在恢复期内还在调整。
- 处置动作不可逆，例如删除、覆盖、批量重发。
- 分歧尚未收敛，两个角色对同一事实仍有不同解释。
这些情况下，脚本的职责收窄为采集和留痕：记录原始字段、采集时间、采集方式，并生成可核对清单。人工节点负责判断和处置。这样做的代价是处理速度慢，收益是每个决定都有可追溯依据，后续把人工判断沉淀成规则时，有真实样本可用，而不是凭印象补规则。
从分歧到可核对项目：一次最小落地
下一步动作可以按这个顺序做，每一步的产出都影响下一步。
- 把当前恢复流程里所有“视情况而定”的句子抄出来，逐条标注属于定义、阈值还是处置分歧。
- 对每条分歧写一句可核对的事实描述，并指定数据来源和观察窗口。做不到的，直接标记为人工节点。
- 把能脚本化的条目按四字段写成需求，参数单独列出，注明基线取值方式和样本不足时的处理。
- 用历史数据做一次离线核对，只看标记结果是否与人工判断一致，不急于上线自动处置。
- 核对不一致的条目，回到第一步重新归类，而不是直接放宽阈值。
需要说明的适用条件：恢复期内的数据本身受季节、搜索需求变化和采集差异影响，改动前后的对比不能单独作为判断依据。某个指标归零或抓取量下降，也可能来自采集时间、抓取预算或站点结构调整，不能直接证明处理动作正确。把例外写成可核对项目的目的，是让分歧暴露在纸面上，而不是让脚本替人做没有共识的判断。做到这一点，后续每一次规则调整才有依据可查，恢复方法也才可能从一个人的经验变成可交接的流程。
