网站tag使用技巧：把人工经验写成脚本需求时怎样描述例外情况

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

网站tag使用技巧：把人工经验写成脚本需求时怎样描述例外情况

先给结论：人工经验里最容易漏掉的不是主流程，而是“看起来应该这样、实际却相反”的例外。写脚本需求时，不要只写“当A成立就执行B”，而要写成“当A成立且C不成立时执行B；若C成立则转人工复核”。判断标准是：这个例外会不会导致标签被误删、误并或误留。会，就必须单列条件；不会，可以合并为一条兜底规则。

先区分两类例外：可枚举的与不可枚举的

人工经验通常来自几十个页面的操作。你在脑子里判断“这个标签重复了，删掉”，但脚本不知道你凭什么判断。写需求前先把例外分成两类。

区分方法很简单：拿十条历史操作记录，逐条问“换成另一个人，他能不能只凭页面字段做出同样判断”。能，就是可枚举；不能，就是不可枚举。这个动作会直接影响下一步：可枚举例外进入脚本规则，不可枚举例外进入人工队列。

条件一：例外有稳定字段依据时，写成分支规则

假设你要写一个清理重复标签的脚本。人工经验是“同一标签第二次出现就删”。但实际操作中，有些第二次出现是页面底部的“相关标签”模块，删了会破坏内链结构。

这时需求可以这样描述：

若同一标签在正文区域出现次数大于1，且第二次出现位置不在<aside>或页脚模块内，则保留第一次出现，标记后续为待删；若第二次出现位于<aside>或页脚模块内，则不删，输出到复核清单。

这里的关键不是标签本身，而是“位置字段”能否稳定获取。如果页面模板统一，位置字段可靠，分支规则可以自动执行。如果模板混杂，同一模块在不同页面用不同容器，位置字段本身就不稳定，那就不要写自动删除，改成只输出候选清单。

实施后看结果时，不要只看“删了多少条”。要同时核对：被删的页面里，内链数量有没有异常下降；被保留的页面里，重复标签是否仍然造成主题分散。这两个信号指向不同解释，不能用一个总数概括。

条件二：例外依赖语义判断时，改成输出证据而不是直接执行

另一种常见情况：人工判断“这个标签和页面主题无关，应该去掉”，但脚本只能看到标签文本，看不到主题相关性。此时若强行写规则，比如“标签长度小于4就删”，很容易误伤品牌缩写或产品型号。

更稳妥的需求描述是让脚本输出判断依据，而不是直接改页面：

  1. 列出该标签出现的所有位置。
  2. 列出同页面其他标签的共现次数。
  3. 标出该标签是否出现在标题、H1或正文首段。
  4. 把以上信息写入复核清单，由人工决定是否移除。

这个动作的结果会影响下一步：如果复核清单里超过一半的条目都被人工判定为“应删”，说明规则可以进一步收紧；如果大部分被判定为“保留”，说明原来的直觉本身需要修正，而不是脚本写得不够激进。

用可核对证据区分“规则有效”和“需求写错”

脚本上线后出现与直觉相反的结果，比如“原本以为会减少重复标签，结果重复标签反而变多”。不要立刻改规则，先找可核对证据。

假设一个短例子：你原本统计到100个页面有重复标签，脚本执行后统计到120个。先别下结论。检查这120个页面里有多少是上次未覆盖的新页面，有多少是标签文本被拆分后重新计数。如果新增的20个全部来自新页面，那规则本身可能没有失效，只是统计范围变了。这个判断会决定下一步是回滚规则，还是只调整统计口径。

写需求时保留一个“转人工”出口

无论例外写得多细，都要在脚本需求里留一个转人工条件。常见写法是：当同一页面同时命中两条以上互斥规则时，不自动执行，输出到人工队列。这个出口不是保守，而是防止例外叠加后产生你没想到的组合结果。

转人工条件要写清楚触发依据，例如“命中删除规则且该标签同时出现在导航模块内”。这样人工复核时知道该看什么，而不是重新判断一遍。执行后如果转人工队列长期为空，可以考虑收紧条件；如果长期堆积，说明规则覆盖不足，需要补充可枚举字段。

最后记住：脚本需求描述例外时，重点不是把人工经验翻译得更完整，而是把“哪些情况必须停下来”写清楚。停下来的条件越明确，自动执行的部分才越可靠。

图1 图2
nginx