性能提升方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5f36ee3648e2.html
📄
性能提升方法：把人工经验写成脚本需求时怎样描述例外情况
结论先说：例外情况不要写成“特殊情况特殊处理”，而要写成可判定的条件加上触发后的动作。前提是你已经能说清正常流程的输入、输出和判定依据；如果正常流程本身还依赖人的临场判断，那么先补判定依据，再谈例外。
先判断例外是“规则分支”还是“人的兜底”
把人工经验转成脚本需求时，最常见的失误是把两类东西混在一起：一类是有明确判定条件的规则分支，一类是暂时无法判定、只能交给人处理的兜底。两者的写法完全不同。
- 规则分支：条件可枚举、可验证，例如某个字段为空、某个数值超出区间、某个来源标记缺失。这类例外应写成脚本内的判断分支，并明确走哪条路径。
- 人的兜底：条件说不清，或者说不清时人自己也在凭感觉。这类例外不应硬塞进脚本，而应写成“记录并转人工”，同时把当时的关键输入一起留存。
判断方法很简单：问一句“两个人拿到同样的输入，会不会做出同样的判断”。会，就是规则分支；不会，就是人的兜底。这个区分决定了例外是写在脚本里，还是写在脚本外的处理队列里。
例外描述要包含四个字段
一条可执行的例外描述，至少包含触发条件、判定依据、触发后动作、记录内容。缺任何一项，脚本执行者都会在遇到边界时自行猜测，而猜测正是人工经验最难复现的部分。
- 触发条件：用可观测的事实描述，不用“异常”“不合理”这类评价词。例如写成“同一标识在两次采集中的取值不一致”，而不是“数据看起来不对”。
- 判定依据：说明依据来自哪个字段或哪一步结果，让执行者能自己复现判断。
- 触发后动作：跳过、重试、降级、转人工，四选一或给出优先级，不要写“酌情处理”。
- 记录内容：留下触发时的原始输入和判定结果，供后续核对。
一个注明假设的短例子：假设某流程正常路径是“读取记录—匹配标识—写入结果”。例外写成“若匹配到多条记录，则不写入，记录全部候选标识并转人工”。这里“匹配到多条”是可判定的，动作是明确的，记录内容也指定了。如果只写“匹配异常时人工确认”，执行者仍不知道什么算异常、确认什么、确认后写不写。
前提变化时，例外清单要重新划分
已有业务里，关键前提一旦变化，旧例外清单往往整体失效。常见的前提变化包括：数据来源更换、字段含义调整、处理频率改变、下游消费方式变化。
变化前后应采取不同决策的条件是：如果变化只影响取值分布、不影响判定逻辑，旧例外条件可以保留，只需重新核对阈值；如果变化影响到“什么算正常”，那么旧例外清单必须重写，因为原来被当作例外的情形可能已经变成常态，反之亦然。
实际操作上，可以先做一次小范围对照：用变化后的输入跑一遍旧规则，把被旧规则判为例外的记录单独看。如果这些记录里大部分其实是正常业务，说明判定逻辑需要改；如果只是数量变多、类型没变，说明只需调整阈值或容量。这个对照的结果直接决定下一步是改条件还是改动作。
一个反例：把兜底写成规则会让例外越写越多
反例是：有人为了省事，把“人工判断后决定”直接写成脚本里的一个分支，条件写得很宽，比如“其他情况转人工”。表面上看例外被覆盖了，实际上这个分支会吞掉大量本可自动处理的记录，转人工量上升，人工又无法从记录里看出为什么被转，于是继续加条件、继续放宽，例外清单越来越长。
出现这种情况时，不要继续往例外清单里加条目，而应回到正常流程，检查判定依据是否缺失。缺失的部分补上之后，很多“其他情况”会自然归入已有分支。这一步的动作是：抽取最近一批被转入兜底的记录，按触发原因归类，能归入已有规则分支的补条件，不能归入的保留为兜底并写清记录字段。结果是例外清单变短、每条都有明确触发原因，下一步才适合扩大脚本的适用范围。
下一步动作：先固化记录，再谈自动化
如果现在就要动手，优先做记录而不是判定。把每次人工处理例外时的输入、判断理由、最终动作记下来，连续积累一批之后，再看哪些理由反复出现且表述一致。表述一致的部分，就是可以写成规则分支的候选；表述仍不一致的部分，继续保留为兜底。
这样做的结果是：例外的描述从“人的感觉”变成“可核对的历史记录”，脚本需求里的例外部分才有稳定依据。在此之前，任何扩大自动处理范围的尝试都缺少可比对的基准，改动前后的差异也无法区分是规则变好还是输入本身变了。
