如何优化网站：把人工经验写成脚本时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2c230864ee01.html
📄
如何优化网站：把人工经验写成脚本时怎样描述例外情况
把人工判断转成脚本需求，例外情况不能写成“特殊情况另行处理”，而要写成可判定的条件、可执行的动作和动作后的分支。做法是：先取一个你手里真实存在的页面或资料样本，标出人工判断依赖了哪些字段，再为每个字段写出“满足什么条件才照常处理、不满足时改走哪条路”。下面按这个顺序展开。
先锁定一个样本，把人工判断拆成字段
不要从“整站规则”开始写，先拿一个你已经人工处理过的页面或一份资料记录。假设这个页面是产品详情页，你人工判断它“可以照常优化”，理由通常藏在几个具体位置：标题是否与正文主题一致、正文是否覆盖了核心参数、页面是否已有唯一主入口、更新时间是否在合理范围内。
把这些理由逐条写成字段，而不是写成感受。例如把“内容还行”改写成“正文包含型号、尺寸、材质三项中的至少两项”；把“看起来是旧页面”改写成“页面标注的更新日期早于当前季度”。字段一旦能取到值，例外才有描述的对象。
这一步的实际动作是：为样本建一张两列的对照表，左列写人工原话，右列写可取值字段。结果是你会立刻发现，有些原话根本取不到值，比如“排版舒服”“读起来顺”，这类判断要么放弃进脚本，要么换成可测量的替代项，比如段落数、单段字数上限。
例外要写成条件加动作加去向
脚本需求里最常见的失败写法是只写条件不写去向，例如“若正文过短则跳过”。跳过之后呢？是进人工复核队列、还是只记录不处理、还是换用另一套模板？三种去向对应完全不同的实现，也对应完全不同的后续动作。
可执行的例外描述至少包含三部分：判定条件、命中后的动作、动作产生的结果如何影响下一步。举一个假设例子说明这种写法：
- 条件：正文非空白字符数少于 300，且页面没有任何结构化参数。
- 动作：不进入批量改写，改为写入待复核清单，并保留原页面不动。
- 去向：待复核清单每日由人工抽检，抽检确认属于空壳页面的，再单独决定合并或下线。
这样写的好处是，脚本执行完你拿到的不只是“处理了多少页”，还有“哪些页被挡在门外、为什么”。如果只写“过短则跳过”，这些页面会静默消失，下一次你无法判断是规则太严还是样本本身有问题。
区分“样本成立”和“规模化后成立”的边界
个别样本上成立的判断，规模化后经常失效，原因通常有三类，需要分别写进例外说明。
- 字段缺失型：样本页恰好字段齐全，批量页面里有一部分字段为空。写法是明确空值算命中例外还是算不满足条件，两者结果相反。
- 阈值漂移型：样本上“正文 300 字”是合理下限，但不同栏目类型的正常长度差异很大。写法是按页面类型分组设阈值，而不是全站一个数。
- 重复判定型：样本是唯一页面，批量里存在近似重复。写法是先做相似度判定，命中近似的页面不进主流程，避免同一套改写被套用多次。
判断边界是否写清，有一个简单检验：把脚本交给另一个人，他能否在不问你的情况下，对一批新页面给出和你一致的处理结果。如果他会反复来问“这种算不算例外”，说明边界还没落到条件上。
用一次小批量试跑校准，而不是直接全量
写完条件和去向之后，先在一小批页面上试跑，把结果分成三类：照常处理、命中例外、判定失败。判定失败指脚本既没判成满足也没判成例外，比如字段取值为空字符串、日期格式无法解析。这类必须单独统计，因为它们往往暴露的是采集或解析问题，不是业务规则问题。
试跑后的动作是回改需求，而不是回改数据。如果发现大量页面因更新日期格式不一而落入判定失败，正确做法是在需求里补一条日期解析规则和解析失败的默认去向，而不是手工把日期一个个改对。改完后再跑同一批，比较两轮结果差异。
比较时要注意，前后两轮之间如果跨越了较长时间，搜索需求和季节变化本身也会让页面表现不同，不能把差异全部归给这次改动。判断规则是否更合理，主要看命中例外的页面是否确实属于你预期的那一类，而不是看某一项统计数字的涨跌。
把例外说明写成可交接的文档片段
最后一步是把上面内容整理成脚本需求里可以直接引用的片段。建议按固定顺序写：适用范围、可取值字段清单、每个字段的判定条件、命中后的动作、判定失败的默认去向、试跑样本和回改记录。这样一份片段既能让开发照着实现，也能让后来接手的人知道哪些页面被有意排除在外。
需要保留的还有一条：任何一条例外规则都要注明它成立的前提。例如“正文少于 300 字视为例外”这条，前提是该栏目正常页面长度普遍高于这个值；如果栏目改版导致长度整体下降，这条前提就不成立，规则需要重新校准。把前提写进文档，下次调整时你才知道该动哪一条，而不是推翻整套规则重来。
