如何建自己的博客：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4b572d737baf.html
📄
如何建自己的博客：把人工经验写成脚本需求时怎样描述例外情况
核心做法是：先写正常路径，再把每个例外拆成“触发条件、期望动作、可核对的证据”三部分，并明确它在脚本里是保留、改写还是退出。触发条件必须写成能直接判断的真假句，而不是“遇到特殊情况”这类模糊说法。做不到这一点时，脚本会把例外当正常路径处理，结果只能靠人工事后发现。
先分清三种例外，再决定保留、改写还是退出
人工经验里的例外，往往混着三类东西：数据本身不完整、操作者做了额外判断、以及流程暂时走不通。它们的处理方式不同。
- 保留：例外有稳定触发条件，且期望动作唯一，例如某类输入缺失时跳过该条并记录原因。这类可以直接写进脚本。
- 改写：例外需要人做判断，但判断依据可以列举，例如同一事实有两种理解时，按字段来源优先级取值。这类要把判断规则写清，而不是把人的结论写死。
- 退出：例外无法用现有规则覆盖，继续执行会污染后续数据。这类应让脚本停下并输出待处理清单，而不是猜一个结果。
判断顺序建议是：先问触发条件是否可判定，再问期望动作是否唯一，最后问错误执行的代价是否可逆。代价不可逆的，优先退出。
把“多个角色理解不同”写成可核对的分歧项
同一事实有不同理解时，不要写“由运营确认”就结束，那等于把例外重新推回人工。可行的写法是把分歧转成一张核对项：分歧点、各方说法、判定依据、判定结果。
假设一个场景：导出文章列表时，编辑认为“已发布”指前台可见，技术认为指数据库状态为发布。脚本如果只按一个字段过滤，两边都会觉得结果不对。改写方式是把两种口径都保留为字段，由脚本输出对照，再由人决定以哪个为准。这里的假设只用于说明比较方法，不代表任何真实项目。
动作上，可以先跑一次只输出对照、不做筛选的版本，看差异条目有多少。如果差异集中在少数几类，就为这几类补判定规则；如果差异分散且无规律，说明该例外还不适合自动化，应退出并保留人工确认。这个动作的结果直接决定下一步是继续细化规则，还是先缩小脚本适用范围。
描述例外时必须写出的四项内容
一项例外写得好不好，可以用四个问题检验：
- 触发条件：用字段、比较符和值描述，例如某字段为空、某状态不在允许集合内。
- 期望动作：跳过、替换、标记、停止，四者只能选一个作为主动作。
- 证据：脚本要留下什么，才能让人事后核对，例如原始值、命中规则名、处理时间。
- 后续影响：该条被这样处理后，是否进入下一环节，是否计入统计。
如果第四项写不出来，说明这个例外还没想清楚，先不要写进脚本。
用一段短示例检查描述是否可执行
假设脚本需要抓取一批页面摘要，人工经验是“摘要缺失时手动补”。直接照搬无法执行，因为“缺失”和“补”都不明确。改写后可以是这样：
触发条件：摘要字段为空字符串。期望动作：标记为待补，不写入正式结果。证据：记录页面标识与命中规则名。后续影响：该条不计入完成数，进入待补清单。
如果实际数据里还有“摘要为占位文本”的情况，就再补一条规则，而不是把两种情况合并成“摘要异常”。合并会让证据失去区分度，后续无法判断问题出在哪一类。
改动前后比较时，别把波动当成脚本效果
把例外规则写进脚本后，常见做法是对比改动前后的输出数量。但数量变化可能来自搜索需求变化、采集时间差异或数据源本身波动，不能单独当作规则正确的证据。更稳的做法是固定一批已知样本，逐条核对脚本判定与人工判定是否一致，并记录不一致的条目属于哪条规则。样本一致率提高，才说明描述在变清楚；总量变化只作为参考。
当不一致集中在退出类例外上，说明脚本边界设得合理；当不一致集中在改写类例外上，说明判定规则还需要补充依据。这个区分决定了下一步是调规则，还是调适用范围。
