seo实战攻略：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e9a7050d7e5e.html
📄
seo实战攻略：把人工经验写成脚本需求时怎样描述例外情况
结论是：例外情况不能写成“遇到特殊情况再处理”，而要写成可判断的条件、可观察的信号和明确的处置动作。只有当你已经能稳定复现人工判断，并且例外有清晰的触发边界时，这套写法才成立。如果例外本身依赖人的模糊感觉，比如“这条看起来不太对”，那再详细的脚本需求也无法执行。下一步动作是先挑一个最常出现的例外，把它拆成条件、信号、动作三部分，再决定是否交给脚本。
为什么例外描述决定脚本能不能用
人工操作时，经验丰富的人会在心里自动跳过很多判断：这条标题太泛、这个页面明显是旧活动、这段描述和正文重复。这些判断没有写出来，但一直在生效。写成脚本需求时，如果只描述正常路径，脚本会把所有输入都当正常情况处理，结果就是该跳过的没跳过，该保留的被误删。
例外描述的价值不在于覆盖所有可能，而在于让脚本知道“什么时候停下来，交给人”。一个可执行的例外条款，通常包含三件事：判断条件、观察信号、处置动作。缺任何一项，执行者都只能猜。
例外要写成条件、信号和动作
把人工经验转成脚本需求时，最容易漏掉的是判断条件。比如人工判断“这个页面不值得处理”，背后可能是页面没有任何正文、正文短于某个长度、或者正文全是导航文字。这三种情况在脚本里是三个不同的条件，不能合并成一句“内容质量差”。
可以按下面的顺序写每条例外：
- 条件：在什么输入状态下触发，例如正文段落数少于两个、标题与页面首个段落完全一致。
- 信号：脚本能读到什么来确认条件成立，例如段落数量、字符长度、重复文本的位置。
- 动作：确认后做什么，例如跳过该页面并写入待人工确认清单，而不是直接删除或改写。
这三项写清楚之后，脚本的行为才是可预期的。如果只写“遇到异常跳过”，执行时没人知道异常指什么，跳过之后也没有记录，后续无法复盘。
一个假设例子：标题重复的例外怎么落成需求
假设你人工处理页面时，习惯把标题和正文首段高度重复的页面挑出来单独改。现在要把这个习惯写成脚本需求。可以这样描述：
当页面标题与正文第一个段落的字符重合比例超过某个阈值时，不自动改写标题，只标记为待处理，并记录标题和首段原文。这里的阈值是假设值，用来演示比较方法，不代表任何实际标准。真正使用时，你需要用自己已经人工处理过的页面去反推这个阈值，看哪一档能把明显重复和正常重复分开。
这个例子的关键不是阈值本身，而是它把“我感觉重复”变成了可比较的数字。动作也很明确：不自动改，只标记。这样即使阈值定得不合适，也不会直接破坏页面，下一步还能根据标记结果调整。
会使结论失效的反例
如果例外条件依赖的是页面之外的信息，比如这条内容是否还在投放、这个页面是否即将下线，那么仅靠页面文本的脚本需求就不成立。这类例外需要额外的数据源或人工确认环节，不能硬塞进文本判断里。
另一种失效情况是例外太多。如果正常路径只覆盖少数页面，大部分输入都落入例外，那说明当前流程还不适合脚本化，应该先继续人工处理，把例外收敛到少数几类再考虑自动化。否则脚本会变成一堆互相冲突的条件，维护成本高于人工操作。
下一步：先固定一类例外再扩展
不要一次把所有例外都写进需求。先选一个出现频率最高、判断最稳定的例外，按条件、信号、动作写成一版，用一小批页面跑一遍，观察标记结果是否符合人工判断。如果符合，再把这版需求作为模板，套用到下一类例外；如果不符合，先修正条件和信号，不要急着增加动作。
同时要保留人工处理前后的对照记录。比较时注意，两次处理之间搜索需求本身可能变化，采集方式也可能不同，所以标记数量的增减不能单独证明需求写对了，还要看具体标记的内容是否和人工判断一致。下一步动作就是：用最近一批人工处理过的页面作为对照，只验证一类例外，确认条件、信号、动作三者能对应上，再决定是否扩大到其他例外。
