如何维护网站，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2e497e2647c3.html
📄
如何维护网站，把人工经验写成脚本需求时怎样描述例外情况
可以写，但前提是把例外写成“可判定的条件分支”，而不是写成“遇到特殊情况再人工处理”。只要脚本需求里存在无法由数据判定的措辞，规模化后就会把原本正确的经验带偏。下面给出可落地的写法、一个会让结论失效的反例，以及下一步该做什么。
先区分两类经验：能判定的和不能判定的
人工维护网站时，很多判断依赖上下文。例如“这个页面内容太薄，合并掉”。对单个样本，人能看到页面主题、内链位置和栏目意图，所以判断成立。但写成脚本需求时，必须把它拆成脚本能读到的字段。
- 能判定：标题长度、正文非空白字符数、内链数量、状态码、最后修改时间、是否包含某类结构化数据。
- 不能判定：内容是否有价值、是否与栏目意图一致、用户是否真的需要这一页。
可操作的做法是：脚本只处理第一类，第二类写成“输出候选清单，由人复核”。这样脚本的产出从“执行删除”变成“生成待确认列表”，后续动作随之改变——你需要的不是回滚机制，而是一套复核排期。
例外要写成条件加动作，而不是写成备注
常见的错误写法是：“批量处理时，如果页面重要就跳过。”这句话对人有效，对脚本无效，因为“重要”没有判定口径。改写时用三段式：触发条件、判定字段、动作。
- 触发条件：脚本扫描到某类页面，例如正文非空白字符数低于阈值且内链数为零。
- 判定字段：该页面是否出现在人工维护的白名单中，白名单按路径前缀或页面 ID 记录。
- 动作：命中白名单则只记录不修改；未命中则进入候选清单，等待复核后再决定合并或保留。
假设阈值设为 300 个非空白字符，白名单覆盖首页、栏目入口和活动页。这个数字只是说明比较方法，实际阈值要按你站点自身的内容分布来定。关键在于：阈值和白名单都是可检查的，任何人拿到同一份数据都能得到同一结果。
会让结论失效的反例：样本成立不等于规则成立
假设你抽查了 20 个低字数页面，发现其中 18 个确实可以合并，于是把“低字数即合并”写成脚本规则。这个结论在规模化后会失效，因为剩下的长尾页面里，可能混着两类无法从字数看出的情况：一类是承担导航或转化入口作用的短页面，另一类是内容尚未补全的新页面。
这两类页面被合并后，表现往往不是立刻掉流量，而是内链结构被改变、后续补充内容的落点消失。此时即使某段时间的抓取量或请求量出现变化，也不能单独证明是这次合并造成的——季节性的搜索需求波动、采集口径调整、站点其他改动都会同时产生影响。所以判断规则是否成立，要看合并前后同类页面的对照，而不是只看总量。
反例的意义在于：它说明例外不能靠“事后发现再补”，必须在写需求时就列出哪些条件会让规则不适用。写不出这些条件的规则，就不该直接执行写操作。
下一步动作：先跑只读版本，再决定是否放开写权限
把经验转成脚本时，第一步不是上线执行，而是让脚本以只读方式跑一遍全量数据，输出三份东西：命中规则且不在白名单的页面清单、命中规则但在白名单的页面清单、以及规则无法判定的页面清单。
拿到结果后做两件事。第一，人工抽查第三份清单，看无法判定的部分是否集中在某几个栏目；如果集中，说明规则缺少一个可判定的字段，补上后再跑。第二，对第一份清单抽样确认，如果抽样中仍有应当保留的页面，说明阈值或白名单需要调整，此时不要放开写权限。
只有当你确认规则在抽样中稳定成立，并且例外都有对应的判定字段时，才把脚本从只读改为可写。这个顺序会让每次维护动作都能被解释，也方便在后续比较时区分“规则本身的问题”和“数据波动带来的差异”。
