电商优化技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c941bffb317b.html
📄
电商优化技巧：把人工经验写成脚本需求时怎样描述例外情况
例外情况要在脚本需求里写成“可判定的条件加明确动作”，而不是写成“视情况处理”。先列出人工操作时实际会停下来的判断点，再给每个判断点指定一个可观测信号、一个默认动作和一个升级路径，脚本才能在关键前提变化时做出和人工一致的取舍。
为什么需求里写了“正常流程”，脚本上线后却频繁停住
常见矛盾是：人工操作时觉得流程很顺，写成脚本需求后却总在同一个环节卡住。原因通常有两个，且处理方式完全相反。
第一种解释是例外本身没被识别。人工执行时靠经验自动绕过了异常，比如某类商品缺主图、某类订单地址不完整，操作者顺手就处理了，但需求文档里只写了标准路径，脚本遇到这些输入只能报错或跳过。
第二种解释是例外被过度列举，把偶发情况也写成硬规则。人工偶尔处理过一次的罕见输入被当成通用分支，脚本为它增加判断，结果正常数据也被拦下，流程变慢甚至误判。
这两种解释的区分证据是：把过去一段时间的实际输入按类型归类，看卡住的位置是否集中在少数几类可复现的输入上。如果卡点集中且能稳定复现，属于第一种；如果卡点分散、每次输入都不同，更可能是第二种。仅凭“脚本失败次数多”不能判断是哪一种，因为采集口径变化、输入量突增也会让失败次数上升。
先记录人工在哪里停下来，而不是记录人工怎么做
把经验转成需求时，最有价值的记录不是标准步骤，而是操作者停下来的瞬间。建议在需求文档里为每个环节补一列“停下条件”，写清三件事：看到什么信号、当时做了什么、为什么不能继续走默认路径。
- 信号：必须是脚本能读到的字段或状态，例如字段为空、值超出预期范围、同一记录出现两次。
- 动作：只能是继续、跳过、标记待处理、转人工四类之一，避免“酌情处理”这类无法执行的说法。
- 原因：一句话说明为什么这个信号不能走默认路径，方便后续判断规则是否还成立。
这样做的一个实际结果是：需求评审时能直接发现哪些例外缺少可观测信号。缺少信号的例外无法写成脚本条件，只能先补数据采集，再进入开发，这一步会改变后续排期，而不是等到测试阶段才暴露。
例外描述要带默认动作和升级路径
只写“如果X则报错”还不够，因为报错之后由谁处理、多久处理、处理不了怎么办，都会影响脚本能否持续运行。每个例外至少要有两层：默认动作和升级路径。
- 默认动作：条件成立时脚本自己做什么，例如跳过该条并记录原因，或按保守值继续。
- 升级路径：默认动作执行后仍无法推进时，把记录交给谁、以什么形式交付、需要附带哪些字段。
- 恢复条件：什么情况下这条例外可以回到正常流程，例如字段补齐后下次运行自动重试。
假设一个场景：脚本需要按商品标题提取规格信息，人工操作时遇到标题里没有规格的就手动查详情页。写成需求时，“标题无规格”是信号，“转人工并附上商品编号”是默认动作，“人工补录后标记为已处理”是恢复条件。如果只写“标题无规格时特殊处理”，脚本无法判断特殊处理指什么，运行结果就不可预期。
关键前提变化后，例外规则要重新分类
已有业务里，例外规则不是一次写定就长期有效。当输入来源、字段定义或业务口径发生变化时，原来的例外可能变成常态，原来的正常路径反而成了少数情况。这时要继续区分两类变化。
如果变化只影响信号的出现频率，例如某字段缺失从偶发变成常见，规则本身可以保留，但默认动作要从“转人工”改为“先按保守值继续并抽样复核”，否则人工负担会迅速压垮流程。
如果变化改变了信号的含义，例如同一个字段过去表示单一规格、现在表示多个规格组合，那么旧条件已经失效，必须重新定义判定规则，而不是调整阈值。判断依据是：用新旧两批输入分别跑一遍规则，看同一条件是否仍然对应同一种处理动作。如果对应关系变了，就属于含义变化。
比较改动效果时要注意，前后数据差异可能来自季节波动、需求变化或采集口径调整，不能直接归因于规则改动。稳妥做法是保留改动前后的输入样本，用同一套判定逻辑回放，观察例外命中位置是否移动，而不是只看某个总量指标升降。
可直接套用的例外描述模板
把上面几点合并成一条需求句式，写起来会快很多：
当[可观测信号]成立时，执行[默认动作]，并记录[必要字段]；若[升级条件]成立，则转交[处理方]，待[恢复条件]满足后回到正常流程。
用这个句式检查每条例外，能发现三类常见缺陷：信号不可观测、默认动作不唯一、恢复条件缺失。补全这三项之后，脚本需求才真正对应人工经验里的判断，而不是只对应操作步骤。下一步可以拿这份需求去对照历史输入做一次回放，确认例外命中位置和人工当时的停留位置是否一致，再决定是否进入开发。
