产品优化技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5021f4a0491a.html
📄
产品优化技巧：把人工经验写成脚本需求时怎样描述例外情况
直接回答：例外情况不能写成一句“特殊情况另行处理”，而要写成可判定的条件、触发后的动作和记录字段。人工经验里最容易被省略的，正是“我一看就知道不对”的那部分判断。脚本需要的是能落到数据上的判断依据，否则例外会变成静默跳过或错误覆盖。下面从一个矛盾现象入手，说明两种常见解释，以及用什么证据区分它们。
矛盾现象：脚本跑完，结果比人工更整齐，却更差
假设一个场景：你负责把人工整理的产品信息判断写成脚本需求，用于批量检查标题、属性或分类。人工处理时，某些记录会被跳过、改回或单独标记；脚本上线后，这些记录全部被统一处理，输出看起来更一致，但抽查时发现原本该保留的少数记录被改错了。这个结果与直觉相反——规则统一了，质量反而下降。
这不是脚本“更笨”，而是人工经验中的例外没有被翻译成脚本能识别的条件。人工判断时，操作者同时看到了字段值、上下文和过往处理记录，能在心里完成“这条虽然符合规则，但属于例外”的判断。脚本只看到你写进需求的条件，条件之外的部分默认不成立。
解释一：例外条件写得过于笼统，脚本只能全部执行或全部跳过
常见写法是“遇到异常数据时跳过”。问题在于“异常”没有判定标准。脚本实现时只能二选一：要么把所有不符合主规则的记录都跳过，要么全部套用主规则。前者会让例外记录留在原状，后者会把例外记录改错。
可区分的证据是：把脚本实际跳过的记录导出来，逐条标注“人工当时会怎么处理”。如果跳过记录里既有该保留的，也有该修改的，说明例外条件缺少区分维度，而不是脚本执行有误。下一步动作是把“异常”拆成可判定字段，例如某个属性为空、某个值超出预期范围、某两个字段互相矛盾。拆完后重新跑一遍，观察原本被误跳过的记录是否回到处理范围。
解释二：例外本身依赖人工上下文，脚本拿不到对应输入
另一种情况是例外条件其实存在，但它依赖脚本没有读取的数据。人工判断时可能参考了备注、历史修改记录或同批次其他记录的状态，而脚本需求里只写了当前字段。此时无论条件写得多细，脚本都无法复现判断。
区分的证据是：随机抽取一部分例外记录，记录人工判断时实际看了哪些信息。如果多数判断依赖当前字段之外的数据，说明问题不在条件描述，而在输入不完整。下一步动作是先确认这些数据能否稳定获取；能获取就补进需求，不能获取就把这类记录明确列为“不自动处理”，而不是让脚本猜。
把例外写成脚本需求时，至少包含三部分
无论属于哪种解释，例外描述都可以按同一结构落地。以下清单用于检查需求是否可执行：
- 判定条件：用字段、比较关系和取值范围描述，避免“异常”“不合适”“明显错误”这类词。条件之间写明是同时满足还是满足其一。
- 触发动作：明确是跳过、标记待人工复核、改回默认值，还是保留原值但记录原因。不同动作对应不同后续流程，不能只写“处理一下”。
- 记录字段：要求脚本输出命中例外的记录标识、命中条件和执行动作。没有这部分，后续无法核对例外是否合理。
一个注明假设的短例子：假设主规则是“属性为空时用同类产品的常见值填充”，例外是“该产品属于定制类，空值代表不适用”。需求里应写成：当分类字段等于定制类且目标属性为空时，不填充，保留空值并记录“定制类不适用”。这只是假设示例，用于说明条件、动作、记录三者的写法，不代表任何真实项目结论。
验证例外描述是否有效，要看可核对的证据
需求改完后，不要只看整体输出是否整齐。更有效的做法是保留一份人工处理过的对照样本，比较三组记录：主规则命中的、例外命中的、两边都不命中的。如果例外命中的记录里，脚本动作与人工判断仍不一致，回到判定条件继续拆；如果一致但两边都不命中的记录增多，说明条件边界可能收得太紧。
比较改动前后结果时，要考虑季节、搜索需求变化和数据采集差异。同一批数据在不同时间采集，字段缺失率和取值范围可能不同，不能把差异全部归因于脚本改动。一次改动前后的比较只能作为线索，不能单独证明处理正确；必要时用同一时间切片的对照样本复核。
最后一步动作是把验证中发现的漏判条件补回需求，并重新跑对照样本。如果补完后例外记录的动作与人工判断一致，且主规则命中记录没有被误伤，才可以把这套例外描述交给脚本实现。若仍不一致，优先检查输入数据是否完整，而不是继续增加条件数量。
