互联网创业方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dab4974226d4.html
📄
互联网创业方法：把人工经验写成脚本需求时怎样描述例外情况
例外情况不能只写在备注里，而要写成脚本可以判断的条件分支。判断依据是：这个例外是否稳定可观测。可观测的，写成带触发条件的规则；不可观测或依赖人临时判断的，写成人工确认节点，并规定超时后的默认动作。
先分清两类例外：可观测与需人工判断
人工经验里常混着两类信息。一类是“看到某个信号就改走另一条路”，比如订单金额为负、字段为空、同一编号在短时间内重复出现。这类例外有明确触发条件，适合直接写进脚本。
另一类是“感觉不对就先停一下”，比如内容语气异常、客户表述含糊、数据组合看起来不合理。这类判断依赖人的上下文，脚本很难稳定复现。硬写成规则，往往误伤正常情况；完全不写，又会把风险留给执行环节。
区分方法很简单：问自己这个例外能否用一条可核对的判断句描述。能，就进规则分支；不能，就进人工确认队列。
可观测例外：写成条件分支，并定义命中后的动作
可观测例外的需求描述至少包含三部分：触发条件、命中后的动作、动作失败时的去向。只写“如果异常就处理”没有执行价值，因为脚本不知道处理成什么结果。
假设一个场景：人工处理订单时，遇到同一客户当天第三次提交相同内容，会先搁置并核对。写成需求时可以这样描述：
- 触发条件：同一客户标识在自然日内出现相同内容提交，且计数达到三。
- 命中动作：不直接进入正常处理队列，转入待核对状态，并记录命中原因。
- 失败去向：若核对在设定时限内未完成，保持待核对状态，不自动放行。
这里的数字三只是假设示例，实际阈值应来自人工经验中真正会改变动作的那个点。写需求时要注明这个数字的来源，方便后续调整时有据可依。
动作定义清楚后，下一步才能验证。如果脚本命中例外后只是打了一条日志，而人工经验里其实会改变后续流向，那这条需求就没有还原真实动作，测试时也看不出差异。
需人工判断的例外：设确认节点，而不是硬编码规则
无法稳定观测的例外，写成人工确认节点更可靠。需求里要说明三件事：什么情况下进入确认、由谁确认、确认前脚本处于什么状态。
以内容发布为例。人工经验里，遇到涉及具体承诺的表述会先停下来确认。这个判断很难用规则覆盖，因为措辞变化多。需求可以写成：检测到特定类型的表述时，不自动发布，转入待确认状态，由指定角色确认后再继续。
关键在超时规则。如果确认节点没有超时定义，脚本可能无限等待。合理的写法是：超过约定时限未确认，保持待确认状态并提醒，而不是默认放行。默认放行会把人工把关变成形式。
这里有一个取舍：确认节点越多，脚本越安全，但人工负担越重。判断标准是例外出现的频率和误判代价。高频且误判代价低的例外，适合写成规则；低频且误判代价高的，适合人工确认。
用可核对证据区分“规则写错”和“需求本身在变”
例外处理上线后，如果出现与直觉相反的结果，不要立刻改规则。先区分两种解释：一是规则描述与人工经验不一致，二是人工经验本身已经变化。
可核对的证据包括：命中例外的记录、命中前后的状态变化、人工复核时的实际动作。如果记录显示脚本命中后执行的动作与人工经验一致，但结果仍不理想，可能是需求前提变了，而不是规则写错了。
假设一个例子：某条例外规则上线后，转入待确认的数量明显上升。可能的原因有几种：阈值设得过低、上游数据格式变化、人工经验中原本会放行的情形被误判为例外。要区分这些解释，需要看命中样本的具体分布，而不是只看总量变化。总量上升本身不能证明规则写错，也不能证明规则正确。
一次改动前后的比较还要考虑季节、需求波动和数据采集口径的差异。同一周的数据对比，可能受活动或外部事件影响。稳妥做法是保留改动前的样本区间，并在比较时说明口径是否一致。
实施动作：先写例外清单，再逐条标注可观测性
具体动作可以按这个顺序做：
- 把人工经验中所有“如果……就……”的句子单独列出来，形成例外清单。
- 逐条标注：触发条件是否可观测、命中后动作是否明确、失败去向是否定义。
- 可观测的写成规则分支，不可观测的写成人工确认节点。
- 为每个人工确认节点补上超时规则，明确超时后是保持等待还是提醒。
- 上线后按命中样本复核，区分规则偏差与需求变化。
这个顺序的价值在于：先暴露哪些例外其实写不清楚，再决定是补观测手段还是保留人工。如果跳过标注直接写脚本，容易把需要人判断的部分硬塞进规则，结果要么频繁误判，要么规则形同虚设。
最后提醒一点：例外描述的目标不是消灭所有例外，而是让脚本在遇到例外时知道该停、该转还是该继续。停和转的动作写清楚了，后续的复核和调整才有依据。
