自建博客步骤：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /01189e9980dd.html
📄
自建博客步骤：把人工经验写成脚本需求时怎样描述例外情况
有条件的结论是：例外情况必须写成“触发条件+系统动作+人工兜底”三件套，否则脚本只能处理正常路径，遇到异常就静默跳过或报错退出。这个结论成立的前提是你已经知道异常长什么样；如果连一次完整的人工操作记录都没有，先补记录再写需求，否则脚本会把未知异常当成正常情况处理。
先区分“规则内偏差”和“规则外异常”
人工操作时，很多判断是顺手做的，写脚本时容易被误当成规则。判断标准很简单：这个偏差能否用已有字段和固定阈值描述。能，就是规则内偏差，写成条件分支；不能，就是规则外异常，写成中断并交回人工。
假设一个场景：你每次发布文章前会检查图片是否都有描述文字。如果只是“有或没有”两种状态，属于规则内偏差，脚本可以遍历图片标签，发现缺少描述就补一个占位值。但如果图片是从外部复制来的、描述文字需要结合上下文重写，这属于规则外异常，脚本应当停止并输出待处理清单，而不是自动填一个通用描述。这里的数字和场景均为假设，用于说明判断方法，不代表任何真实项目结果。
把这两类分开写，需求文档里就不会出现“遇到问题自行判断”这种无法测试的句子。
例外描述要落到可观察的信号上
“网络不稳定”“内容不合适”这类描述无法转成代码。可观察的信号包括：返回状态码、字段是否为空、文件大小是否为零、两个值是否相等、某一步耗时是否超过设定阈值。写需求时，把例外绑定到这些信号上。
- 状态码非预期：记录请求地址、时间和返回码，停止后续步骤。
- 必填字段为空：输出缺失字段名和所在记录标识，跳过该条继续处理其余条目。
- 同一记录重复出现：保留首次出现的版本，把重复项写入待确认列表。
- 数值超出合理区间：不自动修正，原样保留并标记，等人工确认区间是否要调整。
每条例外都要写明脚本接下来做什么：是跳过、停止、重试，还是写日志后继续。只写“处理异常”等于没写。
一个反例：把所有例外都设成重试会让判断失效
有人为了省事，把任何失败都写成“重试三次”。这会让真正的例外被掩盖：如果失败原因是权限不足或字段结构变化，重试三次仍然失败，只是把同一个错误重复记录了三遍，日志变长但信息没有增加。更麻烦的是，重试会拖延后续步骤，让你误以为脚本还在正常工作。
使这个反例成立的条件是：失败原因属于确定性错误，而不是临时波动。区分方法是看同一输入重复执行是否得到相同失败结果。相同，就不要重试；不同，才考虑有限重试。这个判断不需要完整数据权限，只需要把失败样本单独跑一遍。
缺少完整数据时仍可执行的最小动作
如果你拿不到全量日志或后台权限，仍可以做一件事：挑一条已经人工处理过的记录，把当时的判断点逐条写下来，标注哪些判断有明确依据、哪些只是凭经验。然后针对“凭经验”的部分，写出如果脚本遇到同样情况，你希望它停下来还是继续。
这个动作的结果会直接影响下一步：能写成条件的部分进入脚本需求，写不成条件的部分进入人工复核清单。两份清单分开后，你就知道脚本上线后哪些环节必须有人盯着，而不是等出错再回头补规则。
需要提醒的是，改动前后做比较时，搜索需求本身可能随季节变化，采集时间点不同也会带来差异。某次统计归零或某项数量下降，不能单独证明例外处理写对了，也可能是采集范围变化或需求本身波动。因此例外清单要配合人工抽查记录一起看。
交付前用三个问题检查例外描述
- 这条例外由什么信号触发，信号是否能在日志里看到？
- 触发后脚本执行什么动作，动作结束后流程停在哪一步？
- 如果脚本判断错了，人工从哪里接手，接手时需要哪些字段？
三个问题都能答上来，例外描述才算可交接。答不上来的条目，先留在人工清单里，不要硬塞进脚本。
