uv提升方法，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3859d38dd4d1.html
📄
uv提升方法，把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要只写“按经验处理”，而要把例外拆成可判定的条件、可执行的替代动作和可回退的兜底路径。人工操作时，人会自动识别“这个样本特殊”，但脚本不会；如果需求里只写正常流程，规模化后脚本会把所有样本都按同一规则处理，例外就会变成批量错误。写清例外，本质上是把人的判断依据翻译成脚本能识别的分支。
矛盾现象：单页跑得通，放大后却出现反例
常见情况是：用一页内容试了一套 uv 提升方法，标题改写、入口位置调整或推荐位替换后，这一页的数据看起来变好了。于是把同一套动作写成脚本，批量应用到几十页。结果一部分页面继续变好，另一部分却变差，甚至原本稳定的页面开始掉量。
这时容易得出两个相反结论：一是“这套方法根本无效”，二是“脚本执行错了”。两者都可能成立，但指向的处理完全不同。前者说明方法本身有适用边界，后者说明需求描述漏掉了判断条件。若不先区分，后续无论加量还是回退都会误判。
两个解释：方法有边界，还是需求漏了条件
解释一：方法只在特定条件下成立。人工试的那一页可能本身具备某些特征，比如已有稳定搜索需求、内容主题集中、页面结构简单。换到不具备这些特征的页面，同样的改动自然不成立。此时例外不是脚本的错，而是方法被用在了边界之外。
解释二：需求描述漏掉了人工判断。人工操作时，看到某页标题已经包含核心词，就会跳过改写；看到入口被其他模块占用，就会换位置。这些判断没写进需求，脚本却会机械执行，于是产生了人工不会做的动作。此时例外是需求缺陷，不是方法缺陷。
两种解释都会表现为“批量后出现反例”，但修复方向相反：前者要收窄适用范围，后者要补全判断条件。
能区分两种解释的证据
要区分它们，可以看反例页面的共同特征，而不是只看整体涨跌。
- 如果反例集中在某一类页面，比如主题分散、没有稳定搜索需求、结构差异大，更支持“方法有边界”。
- 如果反例分散在各种页面，且都能找到“人工本来会跳过”的动作，更支持“需求漏了条件”。
- 如果反例页面在改动前就处于波动状态，而正常页面相对稳定，说明部分差异可能来自数据采集或需求季节变化，不能直接归因于脚本。
- 如果把脚本动作逐条对照人工操作记录，发现脚本做了人工没做的动作，基本可以确认是需求描述问题。
这里要注意：一次改动前后的比较，必须考虑季节、搜索需求变化和数据采集差异。请求量或抓取量归零，也不能单独证明脚本处理正确，它可能是采集延迟、页面暂时不可达或统计口径变化造成的。
把例外写进脚本需求的具体结构
一个可执行的需求，至少要让脚本回答三个问题：什么情况下不执行默认动作、什么情况下执行替代动作、什么情况下停止并交回人工。
- 前置条件。写清哪些页面才进入这套 uv 提升方法。例如：仅处理已有稳定搜索需求的页面；主题分散或长期无稳定需求的页面不进入批量。
- 跳过条件。写清哪些情况直接跳过。例如：标题已包含目标核心词、入口已被更高优先级模块占用、页面结构不满足模板要求。
- 替代动作。写清跳过默认动作后做什么。例如：不替换标题，改为检查摘要；不调整入口，改为记录待人工确认。
- 兜底路径。写清脚本无法判断时怎么办。例如：遇到条件冲突、字段缺失或页面结构异常，停止处理并输出待确认清单，而不是自行选择一种规则继续。
假设一个短例子：某页标题已包含核心词，人工经验是“不再改写”。如果需求只写“替换标题为包含核心词的新标题”，脚本会重复改写，可能破坏原有匹配。补上“标题已包含核心词则跳过”后，脚本行为才与人工一致。这个例子的数字和条件都是假设，用于说明比较方法，不是真实项目结果。
先小范围验证例外规则，再决定是否扩大
写完例外条件后，不要直接全量执行。先选一小批同时包含正常样本和已知例外样本的页面，按脚本需求跑一遍，重点看脚本在例外样本上的动作是否与人工判断一致。
如果例外样本被正确跳过或转入替代动作，说明需求描述基本可用，下一步可以扩大范围。如果例外样本仍被默认动作处理，说明条件写得不够具体，应先补条件再扩大，而不是靠事后回退。回退只能减少损失，不能替代需求本身写清楚。
实际动作是：把“人工会怎么判断”逐条写成脚本能读的条件，再用小范围样本验证这些条件是否命中。这个动作的结果，直接决定下一步是扩大执行、收窄适用范围，还是回到需求补充例外。只有例外被写清，uv提升方法从单页经验走向规模化时才不会把个别成立当成普遍成立。
