怎么建设网站：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a71fe8e8996e.html
📄
怎么建设网站：把人工经验写成脚本需求时怎样描述例外情况
把人工经验写成脚本需求时，例外情况不能只写“其他情况另行处理”，而要写成可判定的条件分支：先列出正常路径，再为每个可能偏离正常路径的观察点写清触发条件、期望动作和无法自动处理时的交接方式。判断标准是执行脚本的人或程序能否仅凭输入数据决定走哪条分支，不需要再回来问你。
先拿一份人工操作记录，标出“正常”与“例外”的分界
假设你手里有一份人工整理页面信息的操作记录，里面写着“打开页面，找到标题，复制到表格；如果标题为空，就用一级栏目名代替”。这里“标题为空”就是例外，但描述还不够，因为执行者无法判断“为空”指字段不存在、字段存在但内容为空，还是内容只有空格。
把记录改成脚本需求时，可以按下面的顺序处理：
- 写出正常路径：字段存在且去除首尾空格后长度大于零，直接取该值。
- 写出例外触发条件：字段不存在，或去除首尾空格后长度为零。
- 写出例外动作：取一级栏目名；若一级栏目名同样为空，则标记为“待人工确认”，不写入最终结果。
- 写出证据留存：把原始字段值、栏目名和判定结果一起记录，便于事后核对。
这样改完，脚本遇到空标题时不会静默跳过，也不会用错误值填充。下一步是拿一批已知样本试跑，看标记为“待人工确认”的数量是否集中在某类页面。
例外描述要包含可核对的证据，而不是只写结论
人工经验里常有一句“这个页面看起来不对，先跳过”。这句话对脚本没有用，因为“看起来不对”不是可判定条件。需要把它拆成可观察的证据，例如：
- 页面返回的字段数量少于正常页面，且缺少的字段集中在同一区域；
- 同一字段在两次采集中的值不一致，差异超过预先设定的字符数；
- 字段值符合某种明显异常模式，例如全是标点、全是数字，或长度异常短。
把这些证据写成条件后，脚本才能在遇到异常时输出“哪一项证据触发、原始值是什么、建议动作是什么”。如果只输出“异常”，后续排查仍然要靠人工重新翻记录，等于没有减少工作量。
这里有一个取舍：条件写得越细，脚本越能自动分流，但维护成本也越高。若某类例外每月只出现一两次，写成“标记后人工处理”通常比继续加规则更划算；若某类例外在样本中反复出现，再把它升级为自动分支。
用一批样本验证例外分支是否真的可执行
假设你整理出三十条人工操作记录，其中正常路径二十条，例外路径十条。把规则写成脚本需求后，先不要直接全量运行，而是用这三十条记录做一次对照：
- 逐条检查脚本判定结果与人工记录是否一致；
- 对不一致的条目，判断是规则写错，还是人工记录本身有歧义；
- 把有歧义的记录补上判定依据，再更新需求。
如果十条例外里有六条无法仅凭输入数据判定，说明这些例外暂时不适合自动化，应保留人工确认环节。这个结果会影响下一步：不是继续加规则，而是先回到人工记录，把缺失的判定依据补出来。
需要提醒的是，样本对照通过并不等于线上运行一定顺利。页面结构、数据来源和采集时间都可能变化，所以上线后仍要保留异常标记和抽样复核。一次改动前后的比较也要考虑搜索需求变化和采集差异，不能只看某一天的数量升降就断定规则有效。
把例外写进脚本需求的具体格式
一条可执行的例外描述，至少包含四部分：触发条件、期望动作、证据输出、无法处理时的去向。可以写成类似下面的结构：
当字段A不存在，或去除首尾空格后为空：取字段B；若字段B也为空，则输出状态“待确认”，并记录字段A原始值、字段B原始值和页面标识，不进入后续写入步骤。
这个格式的好处是，执行者不需要理解业务背景也能照做；出现“待确认”时，人工只需要看记录里的原始值，不必重新打开页面。下一步可以按状态统计数量：如果“待确认”集中在少数页面类型，就针对该类页面补充规则；如果分散且量小，就维持人工处理。
最后检查一遍：正常路径是否只有一条，例外是否都有明确触发条件，每个例外是否都有动作和去向。缺任何一项，脚本执行时就会把判断权重新推回给人，人工经验仍然没有被真正写成需求。
