网站排名提升方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ed2d1c1c8308.html
📄
网站排名提升方法：把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成“特殊情况另行处理”，而要写成可判定的条件、可观测的信号和明确的兜底动作。否则脚本执行者只能靠猜，旧内容退出时最容易把仍有价值的部分一起删掉。
先看一个矛盾：规则越整齐，退出越容易误伤
把人工经验转成脚本需求时，常见的做法是先把正常流程写清楚：满足什么条件就保留，满足什么条件就下架。问题出在旧内容、旧系统或旧合作关系需要退出时，正常流程往往覆盖不到那些“看起来该退、其实还有用”的部分。比如某个旧页面已经不再更新，但仍有少量稳定访问，且这些访问集中在少数几个入口。按整齐规则处理，它会被归入退出名单；按人工判断，它可能值得保留。
这个矛盾不是规则写错了，而是规则只描述了主体情况，没有描述例外。例外不是少数派意见，而是会影响下一步动作的分支条件。
两种解释：是内容真的没价值，还是判断依据不足
面对“旧内容该不该退出”的分歧，通常有两种解释。
- 解释一：内容确实已经失去作用。它不再被任何有效入口引用，访问来源单一且持续下降，保留它只是增加维护负担。
- 解释二：判断依据不足，退出条件写得太粗。它仍有访问，只是访问量小；仍有引用，只是引用方本身也在退出。此时直接下架，损失的不是流量，而是可回溯的上下文。
这两种解释对应不同的脚本需求写法。前者可以直接写“满足退出条件即删除”；后者必须写“满足退出条件时先标记，等另一个信号出现再决定”。
能区分两种解释的证据
要区分是内容没价值还是依据不足，可以看三组证据。
- 入口是否仍然存在。如果外部引用、站内导航或旧系统调用仍然指向该内容，退出前要先确认这些入口是否也会同步退出。入口还在，内容就不该单独消失。
- 访问是否集中在特定路径。如果访问只来自一个旧入口，且该入口本身正在被替换，那么内容可以跟随入口一起退出；如果访问来自多个分散入口，说明它仍被不同场景使用。
- 退出后是否影响其他环节。旧系统或旧合作关系退出时，常有关联的说明页、回调地址或对接文档。删除内容前，要确认这些环节是否还需要读取它。
假设一个旧活动页已经不再推广，但站内帮助中心仍有两处链接指向它。脚本需求如果只写“活动结束后下架”，执行者会直接删除；如果写成“活动结束后标记为待退出，检查站内引用后再决定”，执行者会先输出引用清单。这个动作的结果直接影响下一步：引用清单为空，才进入删除；引用清单不为空，先处理引用方。
把例外写进脚本需求的具体格式
例外情况要写成“当……且……时，执行……，否则……”。不要用“视情况而定”这类无法执行的描述。一个可用的结构是：
- 触发条件：什么信号出现时，进入例外分支。例如“内容超过约定期限未更新，且仍有站内引用”。
- 判定依据：用什么数据判断。例如引用清单、访问来源分布、关联系统调用记录。
- 动作：进入例外分支后做什么。例如标记为待退出、输出引用清单、暂停删除。
- 下一步条件：什么情况下继续退出，什么情况下保留。例如引用清零后删除；引用仍在则保留并转人工确认。
这里的关键是让脚本执行者能独立判断，而不是每次遇到例外都回来问。例外描述得越具体，后续动作越少反复。
退出时保留仍然有价值的部分
旧内容退出不等于全部删除。仍然有价值的部分通常包括：可复用的说明段落、仍然被引用的数据、旧合作关系结束后仍需留存的对接记录。脚本需求里可以单独写一条“保留清单”，明确哪些字段或段落不随主体退出。
例如，旧系统下线时，操作手册可以退出，但其中关于数据导出格式的说明可能仍被新系统引用。此时脚本需求应写成“主体内容标记退出，数据格式说明段落保留并迁移到新位置”，而不是整页删除。这个动作的结果是：退出范围缩小，但后续迁移有明确来源。
需要提醒的是，一次改动前后的比较要考虑季节、搜索需求变化和数据采集差异。某段时间访问下降，可能只是需求本身在变化，不能单独作为内容失效的证据。把这一点写进例外描述，可以避免脚本把正常波动误判为退出信号。
写完例外后要检查什么
检查例外描述是否可执行，可以问三个问题：执行者能否根据写下的条件独立判断？判断需要的信号是否已经存在或可获取？判断结果是否对应明确的下一步动作？三个问题有一个答不上来，例外就还停留在人工经验层面，没有真正变成脚本需求。
把例外情况写清楚，不是为了增加规则数量，而是为了让退出动作停在正确的位置：该退的退，该留的留，该转人工的转人工。
