APP优化技巧，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e94b795bb27f.html
📄
APP优化技巧，把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成“遇到特殊情况再处理”，而要写成“满足什么条件时，脚本改走哪条分支，并留下什么证据”。以你手里的一份人工操作记录为例，先圈出那些让人工停顿、回看或临时决定的位置，再把每个位置翻译成可判断的条件、可执行的动作和可检查的输出。缺少完整数据或权限时，最小动作是先写清条件与降级路径，而不是先追求脚本跑通全部场景。
从人工记录里找出真正的例外触发点
打开你手头那份记录，逐行标记三类内容：人工为什么停下来、停下来后看了什么、看完后做了什么不同的事。例如记录里写着“这条先跳过，等确认后再补”，这里的例外条件不是“确认”，而是“哪一项信息缺失导致无法确认”。把它写成条件，才有办法交给脚本。
一个可用的判断标准是：如果同一句话换个人来读，会做出不同动作，它就不算合格的例外描述。合格的写法要让两个执行者得出同一分支。你可以用这个短例子自检，以下为假设情境：人工记录写“页面结构异常时不处理”，改写为“当目标字段在约定位置取不到值，且备用位置也取不到值时，记录该标识并跳过该条，不做重试”。后者才能直接进入需求。
把例外写成条件、动作、证据三段式
每个例外都拆成三段，缺一段就会在执行时变成模糊判断。条件写可观测的事实，动作写脚本具体做什么，证据写留下什么以便复查。
- 条件：用取值结果、响应状态、字段是否存在这类可判断项，不用“看起来不对”“明显异常”这类描述。
- 动作：明确是跳过、重试、换备用路径，还是终止整批。重试要写清次数上限和间隔依据，不写“适当重试”。
- 证据：记录哪条数据、哪个条件命中、走了哪个分支。证据是下一步判断的依据，不是日志越多越好。
假设一份人工整理记录里有二十条被手动跳过，你按三段式改写后，脚本跑完输出一份命中清单。此时你能做的下一步，是拿这份清单回看人工记录，确认跳过的原因是否同类；如果原因分散，说明条件写得过粗，需要继续拆分，而不是直接调参。
缺少数据和权限时，先写降级路径
没有完整历史数据、也拿不到某些接口权限时，例外描述仍可先落地，但要把“无法判断”本身当成一个分支写进去。做法是给每个条件加一条降级路径：条件无法求值时，脚本按哪条默认动作走，并标记为待人工确认。
这里要区分两种成立条件。第一种，你能观测到条件成立与否，只是样本少，此时可以按条件分支执行，把结果标为观察对象。第二种，你根本观测不到该条件，此时不能把它写成判断条件，只能写成“数据缺失”分支。把第二种硬写成第一种，会让脚本在运行时做出没有依据的选择。
可执行的最小动作是：先只对能观测到的条件写分支，其余统一进入待确认队列，并统计队列规模。队列规模的变化会影响下一步——如果长期居高不下，说明需要补数据源或调整采集方式；如果逐步下降，才适合把其中稳定的部分转成自动分支。
用一次前后对照检验例外描述是否可执行
改完需求后，不必等脚本完整上线。选同一批输入，先按人工方式处理一遍，再按新写的分支逻辑走一遍，比较两者在例外条目上的动作是否一致。比较时要考虑需求波动和数据采集差异：同一批输入在不同时间跑，结果本身可能不同，所以差异要落到具体条目上核对，而不是只看总数。
如果两次结果不一致，先查是条件写得含糊，还是输入本身发生了变化。前者改需求，后者补输入说明。这个动作的结果直接决定下一步：一致的部分可以固化为脚本分支，不一致的部分继续保留人工判断，并在需求里注明原因。不要因为一次对照通过就认定分支已经完备，也不要因为一次不一致就否定整个拆分方式。
哪些结论不能从这次对照里推出来
一次对照只能说明这批输入下分支动作是否一致，不能说明脚本在全部场景下都正确，也不能说明人工经验已经被完整覆盖。抓取量、请求量或某类记录数下降，可能是分支生效，也可能是输入变少、采集时间不同或上游数据变化，这些解释在没有进一步核对前都成立。
因此，例外描述的完成标准不是“脚本不报错”，而是每个例外都能回答三个问题：什么条件下触发、触发后做什么、做完留下什么。能回答这三点的条目才适合交给脚本；回答不了的，继续留在人工环节，并在需求里标明待补信息。这样处理，脚本需求才既不过度承诺，也不遗漏真实存在的例外。
