网站运营技巧，把人工经验写成脚本需求时怎样描述例外情况

📍 WDQWDWQD987AAAAA:216.73.217.36
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f67fa6cb58ec.html
📄

网站运营技巧，把人工经验写成脚本需求时怎样描述例外情况

例外情况要写成“触发条件 + 判断依据 + 保留、改写或退出后的动作”，而不是只写一句“特殊情况人工处理”。如果例外在人工经验里只是模糊感觉，脚本执行时就会把该保留的页面误删、把该退出的页面继续处理。先决定这类例外是保留、改写还是退出，再把它翻译成可判断的条件，是需求描述里最影响后续动作的一步。

先判断例外属于哪一类，再决定保留还是退出

人工操作时，遇到不寻常的页面，操作者往往凭经验暂停或跳过。写成脚本需求时，这个“暂停”必须被拆成三种不同结果：保留（不动它，留给人工）、改写（按替代规则处理）、退出（本次不处理，并记录原因）。三者对应完全不同的后续动作，混用会让脚本在边界页面上反复执行同一段逻辑。

判断依据可以按“可观察信号”来分。比如页面结构缺失、字段为空、同一页面出现两种互相矛盾的状态，这些都属于可观察信号；而“看起来不太对”“和平时不一样”属于不可观察信号，不能直接写进需求。需求里能落地的例外，必须能被脚本用已有数据判断出来。

假设一个场景：人工整理页面时，遇到正文区域为空但导航完整的页面，会先跳过。写成需求时，如果只写“正文为空则跳过”，脚本可能把加载延迟导致的临时空值也当成例外，从而漏掉本该处理的页面。更稳妥的描述是加上“连续两次抓取均为空”这一条件，把临时状态和稳定状态区分开。这里的数字只是说明比较方法，实际阈值要按自己的采集节奏确定。

把例外写成可执行条件时，必须补上判断依据

人工经验里最容易被省略的，是“凭什么判断这是例外”。脚本不会凭感觉，只会按字段和状态判断。所以需求描述里每个例外都要回答三个问题：看哪个字段、满足什么状态、达到几次才算成立。

把这三项写全，例外才可复现。若只写“异常时跳过”，脚本执行者只能自行猜测，结果往往是同一批页面在不同时间得到不同处理。需要说明的是，某个字段暂时为空，也可能由采集延迟、页面改版或数据源波动造成，不能单独证明页面本身有问题；需求里应保留重新判断的机会，而不是一次为空就永久退出。

保留、改写、退出各自适用的前提

三种处理方式没有绝对优劣，取决于例外是否可逆、是否影响其他页面，以及人工介入的成本。

保留适用于例外状态可能自行恢复、或人工判断成本低于误处理成本的情况。动作是标记并搁置，等下一轮再判断。它的前提是你能接受这批页面暂时不进入后续流程。

改写适用于例外有明确替代规则的情况。比如主字段缺失但备用字段完整，可以按备用字段继续。前提是替代规则经过确认，不会把两类不同页面混为一谈。改写要写清替代字段和替换后的动作，否则等于把问题推给下一环节。

退出适用于例外会污染后续结果、且没有可靠替代规则的情况。动作是跳过并记录原因，供人工复查。前提是退出不会导致整批任务中断，且记录足够让人工定位到具体页面。

如果例外既可能恢复又会影响后续，优先保留而不是退出；如果例外稳定存在且替代规则明确，改写比保留更省人工。这个取舍应在需求里写明，而不是留给执行脚本的人临时决定。

一个假设例子：空值页面该保留还是退出

假设某批页面在人工整理时，遇到正文为空的情况会先搁置。现在要写成脚本需求，可以这样描述：读取正文字段，若为空则检查是否为连续第二次出现；是则标记为保留，写入待复查清单；否则本次退出，等待下一轮。这个描述里，判断依据是“连续第二次”，动作是保留加记录，退出只针对首次出现。

执行后，如果待复查清单持续增长，说明保留条件可能过宽，需要收紧判断依据；如果清单很快清空，说明保留策略有效，可以维持。若清单里大量页面其实是稳定缺失，则应改为退出并单独归类，避免占用复查资源。这个判断只看清单变化，不需要额外指标。

需要提醒的是，改动前后比较要考虑搜索需求本身的波动、采集时间差异和页面改版，不能把清单数量的变化直接当成处理方式对错。一次改动后清单归零，也可能只是采集时点不同，不能单独证明保留策略正确。

需求描述里必须写清的动作与记录

例外描述的最后一步，是写清触发后具体做什么，以及记录什么。动作要能被执行，记录要能被复查。至少包含：触发条件、处理方式、记录字段、复查入口。

  1. 触发条件：用可观察字段和次数描述，不用模糊词。
  2. 处理方式：明确是保留、改写还是退出，三者选一。
  3. 记录字段：写下触发时的字段值、时间和原因，方便人工核对。
  4. 复查入口：说明这批记录在哪里查看，由谁在什么时机复查。

把例外写成这样，人工经验才真正转成了可执行的脚本需求。下一步不是继续加例外，而是先跑一轮，看记录里出现最多的是哪类触发条件，再决定是否调整保留或退出的边界。

图1 图2
nginx