如何做网站SEO：把人工经验写成脚本需求时怎样描述例外情况，为什么人工经验一到脚本里就失真
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b6d6ca2527b5.html
📄
如何做网站SEO：把人工经验写成脚本需求时怎样描述例外情况，为什么人工经验一到脚本里就失真
结论是：例外情况不能只写在备注里，而要写成“触发条件 + 识别证据 + 脚本动作 + 停止条件”四段式，并给每种例外指定一个可观测信号。只有当例外能被稳定识别、且处理动作不会破坏其他页面时，才适合交给脚本；如果例外依赖人的主观判断，或同一信号对应多种原因，就应该保留人工复核，而不是硬编码进脚本。
为什么人工经验一到脚本里就失真
人工做站内优化时，很多判断是隐性的。比如看到某个页面标题过长，你会顺手改短；看到某页正文稀薄，你会先补内容再改标签。这些动作背后其实包含了“先判断页面类型，再决定动不动”的前提，但写脚本需求时往往只写了动作，没写前提。
脚本执行时没有这种上下文，它只会按规则批量套用。结果就是：本来只适用于产品页的规则被套到了栏目页，本来该跳过的聚合页被当成普通内容页处理。问题不在脚本能力，而在需求描述里缺了“什么情况下不执行”这一层。
所以描述例外情况，本质上是把人工判断里“我为什么这次不动它”讲清楚，让脚本也能识别同样的边界。
用四段式描述一个例外
一个可执行的例外描述，至少包含四个部分：
- 触发条件：什么情况下进入例外分支。例如“页面路径包含 /tag/”。
- 识别证据：脚本用什么字段或信号判断。例如“页面类型字段为聚合页，或正文段落数少于 2”。
- 脚本动作：命中例外后做什么，是跳过、降级处理，还是标记待审。例如“不修改标题，只记录到待审清单”。
- 停止条件：什么情况下例外不再成立。例如“当该页正文段落数达到 3 且被人工确认后，移出例外清单”。
这四段写全，脚本才有明确的边界。只写“特殊情况跳过”，执行者无法判断什么算特殊，最后要么全部执行，要么全部不执行。
哪些例外不该写成脚本规则
反例很关键：如果同一信号在不同页面代表不同含义，就不要把它写成自动例外。假设你用“正文少于 300 字”作为跳过条件，看起来合理，但实际可能对应三种完全不同的页面：
- 内容确实稀薄、需要补写的页面；
- 本来就是列表或导航性质的页面，不需要长正文；
- 正文被脚本或模板错误截断的页面。
这三种情况的正确动作完全不同。第一种要补内容，第二种应跳过，第三种要先修模板。如果脚本只按字数判断并统一跳过，第三种问题就会被永久掩盖。
因此，当例外信号无法区分原因时，正确做法是让脚本只做标记，把判断交回人工，而不是自动决定动不动。
一个假设例子：标题长度例外的处理
假设你有一条经验：标题超过 30 个字符就改短。直接批量执行后，发现品牌词页和活动页的标题也被改了，反而丢失了识别信息。
按四段式改写：触发条件是“标题字符数超过 30”；识别证据是“页面类型为普通内容页，且标题中不含品牌词和活动标识”；脚本动作是“生成建议标题，写入待审表，不直接发布”；停止条件是“人工确认该页不属于品牌页或活动页后，才允许自动替换”。
这个例子里，数字只是用来说明比较方法，不是通用阈值。不同站点、不同语言下，合理长度并不相同。重点是：把“什么时候不动”写进需求，而不是留给执行时临时判断。
验证例外规则是否真的生效
写完例外描述后，先在一小组页面上试跑，并记录三类结果：命中例外的页面、未命中但被改动的页面、以及被标记待审的页面。然后做一次前后对比。
对比时要注意，标题或内容改动前后的差异，可能同时受到季节、搜索需求变化和数据采集口径不同的影响，不能只看单一指标的升降就断定规则有效。更稳妥的做法是保留一批未改动的对照页面，观察两组变化方向是否一致。
如果发现例外页面仍被误改，优先检查识别证据是否足够具体，而不是先加更多规则。规则越多，冲突越难排查。
下一步动作
把当前脚本需求里所有“特殊情况”“视情况而定”“一般不处理”这类模糊表述找出来，逐条替换成四段式描述。对无法写出稳定识别证据的条目，先不写入脚本，改为输出待审清单。完成这一步后，再决定哪些例外可以自动跳过，哪些必须保留人工确认。
