网络宣传方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e95162a5e280.html
📄
网络宣传方法：把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成“特殊场景另行处理”，而要写成可判定的条件、可执行的动作和可核对的结果。人工经验里的“看情况”，往往包含多个角色对同一事实的不同理解：运营看到的是内容质量，技术看到的是字段是否为空，审核看到的是风险等级。把分歧转成项目，核心动作是给每个例外配一个触发条件、一个默认动作、一个留痕字段，并明确谁有权判定触发。
先区分三种例外，再决定保留还是改写
人工经验中的例外大致分三类，处理方式完全不同。
- 数据形态例外：字段缺失、格式不统一、来源重复。这类例外适合保留并写成脚本条件，因为判定标准客观，例如“来源字段为空”或“同一标题出现两次”。
- 判断标准例外：某类内容是否算敏感、是否值得推荐。这类例外不宜直接写进脚本，应先转成评分表或关键词清单，再决定脚本只做标记还是做拦截。
- 流程权限例外：谁可以跳过审核、谁可以改标题。这类例外属于流程设计，脚本只能记录“谁在何时改了什么”，不能替代授权规则。
如果三类混在一起写，脚本需求会变成一份无法验收的说明。可行的做法是先把每条人工经验标注属于哪一类，再决定保留、改写还是退出自动化范围。
把“看情况”改写成条件句的具体动作
一条可执行的例外描述至少包含四个部分：触发条件、默认动作、人工介入点、留痕字段。假设有一条人工经验是“标题太夸张的就压一压”，可以改写成：
触发条件：标题命中预设的夸张词清单，且正文与标题的主题词重合度低于设定阈值。 默认动作：不直接修改标题，先标记为待复核，并保留原标题。 人工介入点：标记数量超过当日约定上限时，暂停自动标记，转为人工全量查看。 留痕字段：记录触发词、重合度数值、处理人和处理结果。
这里的关键取舍是：脚本先做“标记”还是直接做“修改”。标记的适用前提是判定标准尚未稳定，或误判代价较高；直接修改的适用前提是条件客观、可回滚、且修改后能对照原值。若两个前提都不满足，应选择退出自动化，把这条经验留在人工流程里，而不是硬塞进脚本。
用可核对的证据处理角色分歧
多个角色对同一事实理解不同时，争论“谁对”通常没有结果，因为双方看的不是同一份证据。可操作的做法是让分歧落到同一批样本上：
- 取一小批有代表性的内容，覆盖各方都认可的正常情况和各自认为的例外情况。
- 让每个角色独立标注：这条是否属于例外、依据是什么、希望脚本怎么处理。
- 对比标注结果，找出分歧集中在哪些条件上，而不是集中在哪些结论上。
- 只对分歧最小的条件先写进脚本，分歧大的条件保留人工判定。
这个动作的结果直接影响下一步：如果分歧集中在“是否敏感”这类判断上，说明需要先补一份判定标准，而不是继续改脚本；如果分歧集中在字段读取上，说明需要先统一数据来源。把分歧转成项目，就是把“我觉得”换成“在这批样本上，按这个条件，我们得到不同结果”。
验收时看什么，以及哪些现象不能单独当结论
例外处理上线后，常见的验收指标包括标记数量、人工复核量、误判样本数和回滚次数。需要说明的是，这些数字的变化不能单独证明处理正确。标记数量下降，可能是条件收紧了，也可能是数据来源变了，还可能是采集环节漏了内容。人工复核量上升，可能是误判变多，也可能是样本本身变复杂了。
因此比较改动前后时，要尽量控制可比性：同一时间段、同一数据来源、同一批判定人。如果跨越了季节或搜索需求本身发生变化的时期，前后差异里就混入了外部因素，不能直接归因于脚本改动。更稳妥的做法是保留一份固定样本集，每次改动都在这份样本上跑一遍，看结果是否与预期一致，而不是只看总量。
三种取舍的适用前提
保留人工处理：适用于判定标准不稳定、误判代价高、或例外出现频率很低的情况。此时脚本只做记录和提醒，不做自动决策。
改写为脚本条件：适用于条件客观、可枚举、可回滚的情况。改写后仍要保留人工抽查入口，避免条件随环境变化而失效。
退出自动化范围：适用于例外本身依赖上下文、无法用现有字段表达的情况。退出的动作要写清楚：这条经验由谁在什么环节处理，处理结果记在哪里，多久复查一次是否具备重新纳入自动化的条件。
把人工经验写成脚本需求，难点不在写代码，而在把“看情况”拆成可判定的条件、可执行的动作和可核对的记录。先处理分歧最小的例外，保留无法判定的部分，用固定样本集验证改动，才能让脚本需求既可用又可验收。
