提高点击率方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1da3fcbbc58a.html
📄
提高点击率方法：把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成一句“特殊情况另处理”，而要写成可判定的条件、可执行的默认动作和触发人工复核的出口。否则脚本要么把例外当常规批量处理，要么在遇到边界时静默跳过，两种结果都会让点击率优化失去可控性。
先确定例外该写进脚本还是留在人工
判断依据不是例外出现得频繁不频繁，而是它能否用已有字段稳定表达。如果例外可以由标题长度、发布时间、页面类型、是否含品牌词这类固定字段判断，就适合写进脚本；如果判断依赖对内容语义的理解，比如“这条旧内容是否仍然代表当前业务方向”，就应保留人工确认。
假设有一批旧页面需要退出主推位，但其中一部分仍有访问价值。若脚本只按“发布时间超过两年”这条规则批量降权，就会误伤那些仍在持续带来有效访问的页面。更稳妥的做法是把规则拆成两层：脚本负责按字段筛出候选，人工负责确认哪些候选真正需要退出。这样脚本的职责是可验证的筛选，而不是替人做价值判断。
例外描述要包含三样东西
第一是判定条件，必须写成脚本能取到的字段和比较关系，例如“页面类型为产品页且最近一次内容更新距今超过 18 个月”。第二是默认动作，即命中例外时脚本做什么，是跳过、降权、还是放入待审队列。第三是复核出口，即什么情况下必须停下来交给人。
- 条件要可取值：不能写“内容质量差”，要写能取到的字段或明确的人工标记。
- 动作要单一明确：命中例外时只做一件事，避免一个条件触发多种互相冲突的处理。
- 出口要可追溯：进入待审队列的条目要记录命中原因，方便后续调整规则。
把这三样写清楚后，脚本需求就从“按经验处理”变成“按条件分流”。后续调整时，你改的是某一条条件或某一个动作，而不是重写整段逻辑。
两种条件下的不同选择
条件一：例外数量少且判断标准稳定。此时适合把例外写成脚本中的白名单或黑名单，直接跳过或单独处理。实施动作是给这批条目打上固定标记，脚本读取标记后执行对应动作。结果是脚本运行后可以直接看输出清单，不需要逐条人工过目。
条件二：例外数量多或判断标准会变化。此时不适合把规则写死，应让脚本输出候选清单，由人工在清单上做取舍。实施动作是把脚本的判定结果和原始字段一起导出，人工只处理被标记的部分。结果是处理速度取决于人工审核量，但误判风险更低，规则也能随判断标准变化而调整。
两种选择的分界不是技术能力，而是例外本身是否稳定。稳定就自动化，不稳定就留出人工环节，不要在需求里写“尽量自动处理”这种无法验收的描述。
实施动作与结果如何影响下一步
先在一个小范围上运行脚本，只处理一类旧内容，记录命中例外的条目数和人工复核后的实际处理数。如果两者差距很小，说明条件写得比较准，可以扩大范围；如果差距很大，说明条件还依赖未写明的经验，需要补充字段或改回人工判断。
比较改动前后效果时要注意，点击率变化可能来自季节、搜索需求变化或数据采集差异，不能只凭一次前后对比就断定是脚本处理带来的。更可靠的做法是保留未处理的一组作为对照，观察两组在同一时间段内的差异方向，而不是只看单组数值涨跌。
下一步动作取决于复核结果：条件准确就扩大自动化范围；误判集中在某一类页面，就为这类页面单独写例外；如果误判原因无法用字段表达，就承认这部分必须留在人工环节，不要为了追求全自动而把判断标准写得含糊。
