如何建立博客：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ad53f1f96cf4.html
📄
如何建立博客：把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要只写“遇到例外就跳过”，而要把例外拆成可判定的条件、可观察的信号和明确的处置动作。人工经验里“这条不合适”往往包含多个判断，脚本需求必须把这些判断写成条件—信号—动作三段式，并注明无法判断时是停止、降级还是转人工。判断标准是：只要同一例外在两次运行中可能得到不同结果，就说明描述还不够具体。
先区分两类例外：可判定的与需要人工介入的
把人工经验转成脚本需求时，最常见的错误是把所有“特殊情况”塞进同一个分支。更有效的做法是先分成两类。
- 可判定例外：能用字段、状态、时间、数量或格式直接判断。例如文章缺少发布日期、标题为空、正文长度低于设定下限、同一来源在短时间内重复出现。这类例外应写成脚本能自动执行的动作，比如跳过、标记待审或改用备用字段。
- 需要人工介入的例外：判断依赖语义、语境或业务意图，脚本只能识别“可疑”，不能确定“对错”。例如两篇文章主题相近但角度不同，或一段经验描述与当前栏目定位是否匹配。这类例外应写成“收集证据并转人工”，而不是让脚本自行决定。
区分的依据不是例外本身复杂不复杂，而是判断所需的信息是否已经结构化。如果判断依赖“读起来是否合适”，就应进入人工队列；如果依赖“字段是否为空、值是否超限”，就应写成自动分支。
用条件—信号—动作描述每一个例外
人工经验通常以口语存在，例如“太短的不要”“重复的不要”“看起来像广告的不要”。这些说法不能直接变成脚本需求，因为“太短”“重复”“像广告”都没有边界。转换时至少补齐三件事：
- 条件：在什么前提下才检查这个例外。例如仅对正文类内容检查长度，对短讯类内容不检查。
- 信号：脚本实际读取什么。例如字符数、字段是否为空、是否命中预设词表、同一标识是否在指定时间窗内出现过。
- 动作：命中后做什么。例如跳过、降级处理、写入待审清单、记录原因码并继续。
假设一个场景：你从人工整理的经验里总结出“来源不明的文章先不发”。写成需求时可以落成：当来源字段为空，且正文中没有可核对的出处说明时，将该条写入待审清单，记录原因码 missing_source，不进入发布队列。这个动作的结果会直接影响下一步——待审清单的数量和原因分布，决定你是继续补充来源字段，还是调整采集规则。
两种条件下的不同选择：自动跳过还是转人工
同一个例外，在不同条件下应做出不同选择。可以用下面这组对照来判断。
- 条件一：例外可以被稳定复现，且误判代价低。选择自动跳过或自动降级。例如标题为空、日期格式无法解析。动作是跳过并记录原因码。这样做的结果是运行日志里会积累一批同类记录，你可以据此判断是采集源问题还是解析规则问题。
- 条件二：例外无法稳定复现，或误判代价高。选择转人工并保留证据。例如内容是否与栏目定位一致、是否涉及需要谨慎处理的表述。动作是保留原始字段、标记可疑点、进入人工队列。结果是人工处理量上升，但避免了脚本按错误规则批量处理。
选择依据可以归纳为一句话：脚本能说清“为什么判它例外”，就自动处理；说不清，就转人工。如果一条例外规则写完后，你无法向别人解释它在什么输入下会触发，那它就不适合直接写进脚本。
出现与直觉相反的结果时，先分清三种解释
把经验写成脚本后，常会出现与预期相反的结果：本该被过滤的内容通过了，或者本该保留的内容被跳过了。这时不要立刻改规则，先区分可能的原因。
- 规则本身写错了：条件和信号不匹配，例如用字符数判断“内容太短”，但采集到的正文包含大量导航文本，导致字符数虚高。
- 输入数据变了：来源页面结构、字段格式或内容类型发生变化，原规则的前提不再成立。
- 观察口径不同：你比较的是两次运行的结果，但两次运行的输入范围、时间窗口或去重方式不同。
区分方法是保留一次运行的输入样本和命中记录，逐条核对触发原因。如果同一批输入在两次运行中结果不同，优先检查规则是否依赖了不稳定字段；如果输入本身不同，则先确认采集范围是否变化。一次改动前后的比较还要考虑季节、搜索需求变化和数据采集差异，不能只凭单次结果断定规则有效。
把例外写进需求文档的最小结构
为了让后续维护的人能判断规则是否仍然成立，每个例外至少写清以下内容：
- 触发前提：在哪个处理阶段检查，只对哪类内容生效。
- 判定信号：读取哪些字段或状态，阈值是多少，阈值依据是什么。
- 命中动作：跳过、降级、转人工还是记录后继续。
- 无法判断时的默认动作：默认继续、默认停止还是默认转人工。这一项最容易被漏掉，但它决定了脚本在边界情况下的行为。
- 可核对的输出：原因码、样本标识或计数，便于之后复查规则是否仍然适用。
完成这一步后，下一步不是继续增加规则，而是用一批已知样本回放，确认每个例外分支都能被解释。如果某个分支从未被触发，或者触发的样本都无法归因，就说明该例外描述还需要回到人工经验里补充条件，而不是直接上线。
