用户体验优化方法，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /55bf675a1013.html
📄
用户体验优化方法，把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成一句“特殊情况另行处理”，而要写成可判定的条件分支：先说明正常路径的输入、判断和输出，再为每个例外指定触发信号、脚本动作、人工接管点和记录字段。如果例外会改变业务结果，就必须让脚本停下来交给人；如果例外只影响展示细节，才可以由脚本按预设规则继续。
先判断例外会不会改变业务结论
人工经验里最容易被漏掉的，是操作者凭直觉判断“这个不算数”的时刻。写成脚本需求时，先问一句：这个例外会不会让最终结论从成立变成不成立？会，就属于结果型例外；不会，只是过程波动，属于过程型例外。两类例外的描述方式不同。
结果型例外的典型信号包括：同一对象出现互相矛盾的两条记录、关键字段缺失导致无法归类、时间范围跨越了业务规则变更点。这类例外出现时，脚本不应自行选择一条继续，而应把对象放入待人工确认队列，并保留原始输入。过程型例外包括：页面加载慢于平时、同一用户短时间内重复提交、某个可选字段为空。脚本可以按默认值继续，只在日志里标记。
判断依据可以写成一句可执行的话：如果例外被自动处理后，人工复核时无法从日志还原当时的原始状态，就说明这个例外必须交给人。这条依据比“重要例外人工处理”更容易落地，因为它把“重要”换成了可检查的还原能力。
条件一：业务规则稳定时，用白名单加默认动作
当关键前提没有变化，比如分类标准、字段含义、结算口径都和人工经验形成时一致，例外描述可以采用白名单结构：脚本只处理明确列出的正常形态，其余全部进入待确认。这样写的代价是待确认量可能偏高，但好处是遗漏少。
实施动作可以分三步。第一步，把人工经验里“我一般会这样做”的句子改写成“当 A 且 B 时，执行 C；否则进入待确认”。第二步，为每个例外分支指定一个记录字段，至少包含原始值、触发条件、脚本动作、时间。第三步，先在一段历史数据上回放，统计待确认比例，再决定是否收紧白名单。
这里有一个假设例子。假设人工经验是“金额明显异常的单子先不处理”。脚本需求不能照抄这句话，而要写成：当金额低于历史同类的下限或高于上限时，标记为待确认，不自动通过；如果金额缺失，同样待确认。回放后发现待确认比例过高，下一步不是放宽阈值，而是检查是不是把“缺失”和“异常”混在了同一个分支里，拆开后再看比例。这个动作的结果会直接影响下一步：比例下降说明分支拆分有效，比例不降则说明人工经验里的“明显异常”其实依赖了未写出的上下文，需要继续向操作者追问。
条件二：关键前提发生变化时，先冻结旧例外再重写
如果业务规则、数据来源或统计口径已经改变，旧脚本里的例外描述会失效，因为原来的“正常”已经不存在了。此时不应在旧分支上继续打补丁，而要先冻结旧例外，再按新前提重写正常路径，最后才补新例外。
冻结的具体做法是：保留旧脚本及其日志字段，但停止用它产生业务结论；新脚本单独运行，两套结果并行观察一段时间。观察期内，只比较同一批对象在两套规则下的分类差异，不急着用差异比例下结论。差异可能来自规则变化，也可能来自数据采集时间不同、样本季节不同，单看一次前后对比无法区分。
重写例外时，优先描述三类：新规则下不再成立的旧例外、新规则带来的新例外、以及新旧规则交界处的对象。交界处最容易出问题，比如某段时间的数据同时符合新旧两套口径，脚本如果按时间戳硬切，可能把同一批对象拆到两个分支。更稳妥的写法是给交界对象单独一个标记，先不自动归类，等人工确认规则边界后再合并。
把例外写进脚本需求的字段清单
一份可执行的例外描述，至少要让开发和复核都能回答下面这些问题。可以用清单逐条检查，而不是在需求文档里写一段散文。
- 触发条件：用什么字段、什么比较方式判定为例外，是否允许组合条件。
- 正常路径：例外不成立时脚本做什么，输出写到哪个字段。
- 例外动作：跳过、标记、进入待确认队列，还是终止本次运行。
- 人工接管点：谁在什么时间看到待确认对象，确认后写回哪个字段。
- 记录字段：原始输入、触发条件、脚本动作、处理时间是否都保留。
- 退出条件：待确认对象积压到什么程度需要暂停脚本，而不是继续堆积。
其中“退出条件”最常被省略。没有退出条件时，脚本会把例外不断推入队列，人工处理速度跟不上，最后队列本身变成新的问题。写清退出条件后，脚本在积压达到预设值时停止产生新结论，下一步动作就变成先处理队列，而不是继续调规则。
用回放和并行观察验证例外描述
例外描述写完不等于正确。验证时优先做回放：拿一段已经人工处理过的历史数据跑新脚本，比较脚本动作和人工动作的差异。差异集中在哪一类例外上，就回到那一类分支继续追问操作者。回放的价值在于暴露“写漏了但没人发现”的条件，而不是证明脚本已经可用。
如果关键前提已经变化，回放的历史数据只能验证旧规则部分，新规则部分要靠并行观察。并行观察期间，不要因为某个指标暂时归零就认定处理正确。请求量、抓取量或待确认量的下降，也可能来自采集时间变化、上游数据延迟或样本本身减少，需要结合记录字段判断，而不是只看一个数字。
无论回放还是并行观察，都不要承诺固定见效时间。一次改动前后的比较要考虑季节、搜索需求变化和数据采集差异，能说明的只是“在当前假设下，哪一类例外被正确交给人处理”。把这个结论写回需求文档，下一步才是扩大运行范围或调整阈值。
