怎样优化网站：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /67b54cad48cf.html
📄
怎样优化网站：把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要只写“遇到异常就跳过”，而要把例外拆成三样东西——触发条件、判定依据、处理动作。触发条件说明什么情况下算例外，判定依据说明谁来核对、看哪个字段，处理动作说明脚本是继续、暂停还是交给人工。三者缺一，脚本执行者就只能靠猜，分歧会从需求评审一路带到上线之后。
一个常见矛盾：同一句需求，两个人读出两种结果
假设你负责把运营同事的手工检查经验写成脚本需求。原话是：“如果页面标题和栏目对不上，就记下来，不要改。”写需求的人理解成：标题与栏目名称不一致时，只记录，不修改页面。开发理解成：只要标题字段为空或栏目字段为空，就跳过这条记录。测试又理解成：两者只要有一个为空，就算对不上。
三个人都没有恶意，问题出在“对不上”这个词同时能指“不一致”和“缺失”。脚本上线后，一批标题正常但栏目为空的数据被记成异常，而真正标题写错的记录反而没被标出。复盘时大家才发现，争论的不是技术，而是对同一事实的不同理解。
两种解释，以及能区分它们的证据
解释一：例外是“值不相等”
这种解释把例外定义为两个字段都有值、但值不同。适用条件是字段本身有稳定的取值规范，比如栏目名称来自固定清单。能区分它的证据是：抽样查看被标记的记录，如果它们两边都有值且确实不同，说明判定逻辑成立；如果大量记录是一边为空，说明这个解释覆盖不了实际情况。
解释二：例外是“缺少可比较的值”
这种解释把例外定义为任一字段为空或格式不合法，导致无法比较。适用条件是数据来源不稳定，字段可能未采集或采集失败。能区分它的证据是：把被标记记录按“空值”“格式错误”“值不同”分组计数，如果空值占多数，说明当前更需要先解决采集完整性，而不是调整比较规则。
两种解释可以同时成立，但不能混在一个动作里。建议在需求里写成两个独立例外：missing_value 表示缺少可比较的值，value_mismatch 表示两边都有值但不相等。这样后续统计和回滚才有区分度。
把例外写进脚本需求的最小结构
每条例外至少包含四行：触发条件、判定依据、处理动作、核对人。触发条件要写成可观察的事实，而不是感受。例如“标题字段为空”是可观察的，“标题看起来不对”不是。判定依据要写清参照物，例如“以栏目清单文件为准”。处理动作要明确脚本行为，例如“写入待核对清单，不修改原页面”。核对人要写角色，不写具体姓名，方便交接。
一个注明假设的短例子：假设脚本每天处理一百条记录，其中十条标题为空、五条栏目为空、三条两边都有值但不同。如果只写“异常就跳过”，最终只会得到十八条无法区分的记录。如果按上面四行结构拆分，就能得到三组可核对的数据。这个数字只用于说明比较方法，不代表任何真实项目的结果。
实际动作：先跑一次只记录不修改的版本
把需求写成脚本后，第一个动作不是直接改页面，而是先跑一次只记录、不修改的版本。运行后导出例外清单，按触发条件分组。如果某一组数量远高于预期，先检查采集环节，而不是立刻调整比较规则。如果某一组数量很少但影响面大，再决定是否加入人工复核。
这个动作的结果会直接影响下一步：当例外清单能稳定复现同一分组时，才适合把处理动作从“记录”升级为“自动修正”；如果同一批数据每次分组结果都不同，说明判定依据还不稳定，此时应先固定字段来源和取值规范。一次改动前后的比较还要考虑季节、搜索需求变化和数据采集差异，不能把某次记录数量下降直接当成处理正确的证据，因为采集失败、字段改名或抽样范围变化都可能产生同样现象。
让多个角色对同一事实达成可核对的项目
需求评审时，让每个角色分别说出自己理解的触发条件，并写在同一张例外表里。出现分歧时，不争论谁的表述更好，而是回到证据：哪条记录能同时满足两种解释，哪条记录只能满足其中一种。能区分两种解释的记录，就是需要补充到需求里的边界样本。
最终交付的脚本需求应做到：读需求的人能说出例外在什么条件下触发、依据什么判断、脚本会做什么、由谁核对。做到这四点，例外就不再是藏在经验里的默契，而是可以逐条核对的项目。
