企业网站SEO方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /23e39cfb33f2.html
📄
企业网站SEO方法：把人工经验写成脚本需求时怎样描述例外情况
把人工经验写成脚本需求时，例外情况不能只写成“特殊情况特殊处理”，而要写成可判定的条件、可选择的动作和可回退的结果。否则脚本执行者只能猜，最后往往把本该保留的旧内容、旧链接或旧合作关系一并清掉。
矛盾现象：越强调“按经验判断”，脚本越容易误删
一个常见现象是：需求里写着“保留仍然有价值的部分”，脚本上线后却把大批旧页面标记为可删除。表面看是执行者没有理解经验，实际原因通常有两个。
第一种解释是例外没有被写成可判定条件。人工操作时，编辑看到页面标题、正文长度、内链数量和访问来源，能凭上下文判断“这篇还有用”。脚本只拿到字段，如果需求只写“低质量页面清理”，执行者只能按某个字段阈值处理，无法还原编辑脑中的判断。
第二种解释是例外虽然写了，但没有写清动作分支。比如需求写“有历史价值的保留”，但“保留”是指不删、不改、不跳转，还是只保留正文、其余部分进入新流程？不同理解会产生完全不同的结果。
能区分这两种解释的证据，是让执行者复述判定过程。如果他能说清“满足哪几个条件时进入哪条分支”，说明例外已可执行；如果只能回答“到时候再看”，说明例外还停留在经验层，需要继续拆解。
把例外写成三段式：触发条件、动作、回退
描述例外时，最实用的结构是三段式。第一段写触发条件，第二段写触发后做什么，第三段写做完后如果发现不对，如何回退。三者缺一，脚本执行者就会在边界处自行发挥。
触发条件要尽量用脚本能读取的字段表达。例如：
- 页面有外链指向，且外链来源页面仍在网站导航中；
- 页面正文包含与当前业务仍相关的主题词，但标题已过时；
- 页面被旧合作关系引用，但对方站点已不再更新。
动作要写清是保留、改写、合并、跳转还是仅标记待审。回退则要写明：如果执行后出现误判，是恢复原状，还是进入人工复核队列。回退动作决定了脚本能否安全试跑。
假设例子：旧合作关系页面退出
假设一个企业网站有一批旧合作方介绍页，合作已结束，但其中部分页面仍有外部链接。需求若只写“清理失效合作页面”，执行者可能全部删除。更可执行的写法是：
- 若页面无外部链接且无站内入口，标记为可删除；
- 若页面有外部链接但合作已结束，保留页面并改为说明性内容，不直接删除；
- 若页面有站内入口且仍带来咨询，进入人工复核，不自动处理。
这个例子的数字和条件都是假设，只用于说明比较方法。实际阈值需要根据网站自身数据确定，不能把假设值直接当成标准。
用“反例”检验例外描述是否够清楚
写完例外条件后，不要只拿正常页面测试，要专门找反例。反例是那些同时满足两条规则、或看起来像例外但实际不是的页面。能通过反例检验的需求，执行者才不容易误判。
例如，一个页面既有外部链接，又已经没有任何业务关联。它到底算“有历史价值”还是“可清理”？如果需求没有写优先级，执行者只能随机选一条。解决办法是写明判断顺序：先看是否有外部链接，再看是否有站内入口，最后看内容是否仍能回答用户问题。顺序本身就是例外描述的一部分。
另一个检验方法是让执行者用一句话说出“什么情况下我不会动这个页面”。如果他说不出来，说明例外条件还缺少否定边界。
试跑后看什么：区分误判与正常波动
脚本试跑后，不要只看处理数量。处理量下降或归零，可能是例外条件生效，也可能是数据采集差异、季节变化或搜索需求变化。一次改动前后的比较要考虑这些因素，不能把统计相关直接当成因果。
更可靠的做法是抽取三类页面人工复核：被保留的、被改写的、被标记待审的。如果被保留的页面里出现明显应清理的对象，说明例外条件过宽；如果被清理的页面里出现仍有外链或站内入口的对象，说明例外条件过窄或优先级写错。复核结果直接决定下一步是收紧条件、放宽条件，还是补充回退分支。
把人工经验写成脚本需求，关键不是把经验写得更详细，而是把例外写成执行者能判定、能执行、能回退的规则。这样旧内容、旧系统或旧合作关系退出时，仍然有价值的部分才不会被顺手删掉。
