怎么做网站优化，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (HTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)
🔗 /faecd68ce68c.html
📄
怎么做网站优化，把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要只写“遇到例外情况特殊处理”，而要在需求里为每个例外写清三件事——触发条件、期望动作、以及无法自动处理时交给谁。更关键的是，先决定这个例外是保留人工判断、改写成可执行规则，还是退出脚本流程。三种取舍对应不同的适用前提，混在一起写，脚本执行者只能靠猜。
先区分三种例外，再决定保留、改写还是退出
人工经验里的“例外”，往往混着三类东西。第一类是可判定的边界，比如某字段为空、某页面状态码不是预期值。第二类是需要语义判断的情况，比如两段描述看起来矛盾，但哪段更可信要靠业务理解。第三类是责任归属问题，比如数据缺失时该由谁补，而不是脚本能决定的。
可判定的边界适合改写成规则；需要语义判断的，要么保留人工复核，要么拆成更小的可判定信号；责任归属问题应当退出脚本范围，写成交接动作。判断标准很简单：如果两个人看同一份输入会得出同一结论，它就能进脚本；如果结论依赖谁来判断，就不该硬编码。
描述例外时，用固定字段替代自然语言
人工经验常写成“一般情况这样处理，特殊情况另说”。脚本需求不能这样写。每个例外至少包含四个字段，缺一个都会在实现时产生歧义：
when：触发条件，必须是可核对的判断，例如“目标页返回 404”或“同一字段在同一批次出现两个不同值”。then：期望动作，写清是跳过、记录、替换还是中止。else：条件不成立时的默认路径，避免实现者自行决定。owner：无法自动处理时交给谁，用角色而不是人名，例如“内容负责人”。
假设一个场景：人工经验说“标题太短就补一补，但别补成和别的页面一样”。这句话里“太短”和“一样”都是模糊的。改写成规则时，可以先定义“少于 N 个字符视为过短”，把 N 作为参数而不是写死在描述里；再定义“与同批次其他页面标题完全一致时，标记为待复核”。这样脚本能执行前半段，后半段交给复核。这里 N 只是举例说明比较方法，不是通用阈值。
把分歧转成可核对项目的具体动作
多个角色对同一事实理解不同时，不要靠开会统一措辞，而是产出一份例外清单，每一行对应一个可核对的判断。动作顺序如下：先让每个角色各自写出自己认为的例外，不要求措辞一致；再把所有例外按触发条件归类，合并描述相同但叫法不同的条目；最后逐条标注保留、改写或退出。
这个动作的结果会直接影响下一步：如果某条例外被标为“改写”，就需要补上可判定的触发条件，否则它无法进入脚本；如果被标为“保留人工”，就要在流程里留出复核节点，否则脚本会默认跳过；如果被标为“退出”，就要明确交接给谁，否则例外会静默消失。换句话说，标注结果决定了脚本的边界在哪里，而不是先写脚本再补例外。
保留人工判断的适用前提
保留人工不是偷懒，它有明确前提：例外出现频率低、判断依赖上下文、且判断错误的代价较高。满足这三条时，把例外留在人工环节更稳妥。但要写清人工介入的触发点和产出物，例如“标记为待复核的条目进入复核队列，复核后回写处理结果”。否则“保留人工”会变成没人处理的堆积。
反过来，如果某个例外高频出现，即使它需要判断，也值得先拆成几个可判定信号，把大部分情况自动化，只把真正模糊的部分留给人工。判断依据是频率和代价的组合，而不是“能不能写规则”这一句话。
改写成规则时，注意比较的公平性
把例外改写成规则后，验证方式也要写进需求。不要用改动前后的单次对比下结论，因为搜索需求、季节波动和数据采集口径都可能同时变化。更稳妥的做法是：先记录改动前的基线，再在相近条件下比较同一组指标，并说明哪些差异可能来自外部变化而非脚本本身。
例如，脚本上线后某类页面处理量下降，这既可能是规则生效，也可能是采集范围变了或上游数据缺失。需求里应当写明如何区分这两种解释，比如同时记录输入条数和处理条数。这样下一步调整规则时，才有依据判断是规则问题还是数据问题。
最后，例外描述写完不等于结束。每次发现新的例外，都应回到清单里补充触发条件和归属，而不是在脚本里临时打补丁。清单保持可核对，脚本的边界才稳定。
