博客技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2b06976b2b31.html
📄
博客技巧：把人工经验写成脚本需求时怎样描述例外情况
结论先说：例外情况不要写成一句“特殊情况另行处理”，而要写成“触发条件 + 判断依据 + 处理动作 + 未命中时的默认行为”四段式。只有当例外能被稳定识别、且处理动作不会破坏主流程时，才适合写进脚本需求；如果例外依赖人的临场判断，更稳妥的做法是把它标成人工确认节点，而不是硬编码进自动化流程。
先区分两类例外：可判定的和需判断的
写需求前，先把收集到的例外逐条过一遍，问自己一个问题：换一个执行的人，只看给定字段，能不能得出同一个结论。能，就是可判定例外；不能，就是需判断例外。
- 可判定例外：字段缺失、数值越界、状态码异常、时间戳早于某个基准、同一标识出现多次。这类适合写成脚本里的条件分支。
- 需判断例外：标题语义模糊、配图是否合规、内容是否值得保留、两个来源冲突时信谁。这类应写成“挂起并输出待确认清单”，由人处理后再回流。
把需判断的例外硬写成 if-else，脚本会给出一个看似确定的错误答案，比直接报错更难排查。反过来，把可判定例外交给人工，会让确认队列迅速堆积，自动化等于没做。
四段式写法：让例外可执行、可回退
每条例外单独成段，按下面四段描述，缺一段就说明需求还没想清楚。
- 触发条件：用什么字段、什么比较方式命中。例如“发布时间字段为空，或解析结果不是合法日期”。
- 判断依据：为什么这算例外，而不是正常波动。写清参照物，比如“与同批次其他记录的字段完整率对比后明显偏低”。
- 处理动作：命中后具体做什么——跳过、标记、降级、进入人工队列、还是终止整批。
- 默认行为：没命中任何例外时走哪条主路径。这一条最容易被省略，却决定了脚本在边界外的表现。
一个假设的例子：某批历史文章需要补全摘要字段。需求可以写成“若正文少于 80 字，则不生成摘要，标记为待人工确认；其余记录按主流程生成”。这里的 80 字只是示例阈值，真实值应来自你自己的数据分布，而不是照搬。
反例：什么情况下四段式也会失效
如果例外之间会互相覆盖，四段式逐条罗列反而会制造矛盾。比如“字段为空则跳过”和“字段为空则用默认值补齐”同时存在，脚本执行顺序不同，结果就不同。
这时要补一层优先级规则：明确哪条例外先判、命中后是否还继续判后续条件。否则测试时可能碰巧通过，换一批数据就出现前后不一致。判断需求是否已经足够稳，可以看一个信号：把例外清单交给没参与整理的人，他能否在不提问的情况下说出每条的执行顺序。做不到，就说明优先级还没写死。
下一步动作：拿一批旧数据做干跑
需求写完不要直接上线。先挑一批已经人工处理过的历史数据做干跑，把脚本输出和人工结论逐条对比。
- 不一致的记录，归因到具体哪条例外描述不清，回改需求而不是改脚本绕过。
- 一致但被标为“待确认”的比例过高，说明阈值定得太紧，需要放宽触发条件。
- 一致且自动处理的比例合理，才进入正式流程。
比较前后结果时要注意，不同时间段的搜索需求、内容来源和采集方式本身会变化，处理量下降或异常数归零，既可能是规则生效，也可能是数据源变了、采集范围缩小或字段口径调整。要确认是哪一种，得回到原始数据看分布，而不是只看汇总数字。干跑通过后，再把这批例外规则沉淀成可复用的检查项，供下一篇同类需求直接引用。
