SEO技巧：把人工经验写成脚本需求时怎样描述例外情况，先分清三种例外处理：保留、改写、退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7b1707d20b38.html
📄
SEO技巧：把人工经验写成脚本需求时怎样描述例外情况，先分清三种例外处理：保留、改写、退出
直接回答：例外情况不能只写“跳过异常页面”，而要写成“触发条件 + 判断依据 + 保留、改写还是退出 + 退出后的下一步”。人工经验里最值钱的部分，往往是操作者看到某个信号后临时改变动作，脚本需求若只描述正常路径，自动化就会在边界样本上做出与人工相反的决定。下面用“保留、改写、退出”三种取舍，说明例外该怎样落到可执行描述。
先分清三种例外处理：保留、改写、退出
同一类异常，在不同前提下的正确动作并不相同。写需求时先让决策者明确当前目标是保覆盖率、保准确性，还是保执行稳定。
- 保留：样本本身有效，只是不符合主流程的整齐形态。适用前提是页面主体内容可读、与目标主题相关，且异常只影响次要字段。代价是后续仍需人工抽检，脚本不能宣称全自动。
- 改写：样本可用，但需要按规则转换后再进入下一步。适用前提是转换规则稳定、可被明确描述，且转换不会改变原意。代价是规则越复杂，维护成本越高，规则变更时要重新验证历史样本。
- 退出：样本无法可靠处理，继续执行会污染结果。适用前提是误判代价高于漏判代价，或该样本属于明确不服务的类型。代价是覆盖率下降，且退出原因必须可追溯，否则无法判断是规则问题还是数据问题。
取舍的关键不是哪种更“高级”，而是误判和漏判哪个更贵。若错误处理一条会带来连锁错误，就应选择退出并记录原因；若漏掉一条只是少一个样本，且人工可补，就应选择保留并标记待复核。
把“我一看就知道”翻译成可判断的触发条件
人工经验常以“感觉不对”存在，脚本需求必须把它拆成可观察信号。描述例外时，至少写清四件事：在哪里判断、看什么字段、满足什么组合、判断不了时怎么办。
假设一个场景：脚本要从一批页面中提取正文段落，人工操作时遇到“正文很短但评论很长”的页面会直接跳过。写成需求时，不能只写“正文过短则跳过”，因为“短”没有阈值，也没说明评论长度是否参与判断。更可执行的写法是：当正文段落数量低于设定下限，且评论区域段落数量高于正文时，标记为疑似低正文页面，退出提取并记录页面标识与两项计数，交由人工确认。这里的数字是假设示例，用于说明比较方法，不是固定标准。
这样写的好处是，例外不再是黑箱。执行后如果退出量异常升高，可以先检查是阈值设置问题，还是页面结构整体变化，而不是直接怀疑脚本失效。
例外描述要带动作结果，否则下一步无法决策
只写“记录异常”通常不够，因为记录之后没人知道该做什么。需求里应说明每个例外分支产生的输出，以及该输出如何影响下一步。
- 标记并继续：输出正常结果，同时附加例外标签。下一步可先分析带标签样本的占比，再决定是否调整规则。
- 标记并暂停该条：输出空结果和原因码。下一步按原因码分组抽检，确认是规则过严还是数据确实不可用。
- 整批暂停：当同类例外在短时间内集中出现时停止后续执行。适用前提是该异常可能影响整批数据，继续跑只会浪费资源并扩大错误面。
动作结果会直接改变下一步：如果例外集中在某一种原因码，优先修规则；如果原因码分散且人工复核后多数可用，说明退出条件过严，应回到触发条件重新取舍。
验证例外规则时，别把一次前后对比当成结论
例外规则上线后，常见做法是对比改动前后的处理量或产出量。但这类比较要考虑季节、搜索需求变化和数据采集差异，不能把统计相关直接当成因果。例如某类页面处理量下降，可能是规则生效，也可能是该类型页面本身减少，或采集范围发生了变化。
更稳妥的验证方式是：保留一批已人工判断过的样本作为对照，分别用旧规则和新规则处理，比较两者在保留、改写、退出上的分歧。分歧集中的地方，就是例外描述仍需补充的地方。这个动作的结果决定下一步是继续扩大适用范围，还是先收紧触发条件。
一份可复用的例外描述结构
把人工经验写成脚本需求时，每条例外都可以按同一结构落笔：触发位置 → 观察字段 → 组合条件 → 处理动作 → 输出内容 → 人工复核入口。其中处理动作必须从保留、改写、退出中明确选一个，不能写“视情况而定”。如果确实需要分情况，就拆成多条例外，分别写清各自前提。
这样做的直接结果是：脚本执行后能按原因归类，人工复核有明确入口，规则调整也有对照依据。例外描述的质量，最终体现在异常发生时系统做出的动作是否与人工判断一致，以及不一致时能否快速定位到是哪一条条件写错了。
