SEO进阶技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /53b23eda64f5.html
📄
SEO进阶技巧：把人工经验写成脚本需求时怎样描述例外情况
例外情况不要写成“特殊场景另行处理”，而要写成一条可判定的条件加一个明确动作。做法是：先固定一份分歧样本，再把每种分歧命名，最后为每个名称写出触发条件、默认动作和升级路径。脚本读到条件成立就执行动作，读到条件不成立就走默认分支，人工只处理升级路径里的条目。
先固定一份多人理解不一致的样本
不要从规则写起，从分歧写起。挑出十到二十个页面或记录，让参与的人分别标注“这条应该怎么处理”。标注不一致的地方，就是例外情况的来源。
假设一份样本里，同一个栏目页被三个人分别标成“保留”“合并”“待确认”。这不是三个人水平不同，而是他们对“同一事实”的定义不同：有人看标题相似度，有人看正文主题，有人看内链指向。把这三条依据分别写下来，分歧就会从意见变成字段。
这一步的实际动作是给每条分歧记录一个编号和一句原话，例如“编号07：标题相似但正文主题不同，A认为合并，B认为保留”。编号的作用是后续脚本、复核和回退都引用同一个对象，避免口头描述在传递中变形。
把分歧翻译成可判定的条件，而不是形容词
脚本无法执行“内容质量差”“主题相近”“看起来重复”这类描述。需要把它们换成有取值范围的判断，并写清判断依据来自哪个字段。
- 能用布尔值表达的，写成成立与不成立两个分支，例如标题完全相同为真，否则为假。
- 需要阈值的，写明比较对象和边界，例如相似度高于某个值算一组，低于则各自保留；阈值本身要标注是谁定的、依据是什么。
- 依赖人工判断的，不要塞进脚本，而是输出一条待确认记录，并指定由谁在什么条件下确认。
这里有一个容易忽略的取舍：条件写得越细，脚本覆盖越准，但维护成本越高；条件写得越粗，跑得快，但例外会以“误判”的形式回流到人工。判断标准是看例外回流的频率——如果同一类误判反复出现，说明它不该留在例外里，应该升级成正式条件。
给每个例外写三段式：触发、动作、升级
描述例外情况时，用固定三段式，顺序不要变。
- 触发：什么条件下进入这个例外。写成可核对的字段比较，而不是主观描述。
- 动作：进入后脚本做什么。是跳过、标记、输出到待确认清单，还是执行替代处理。
- 升级：动作完成后交给谁、在什么时限内、依据什么信息决定下一步。
假设一条规则是：当两个页面的标题高度相似但正文主题不同时，不自动合并，而是输出到待确认清单，由负责该栏目的人在约定时限内核对正文后决定。这里的“高度相似”“主题不同”必须落到具体字段，否则执行者仍然要重新解释一遍。
三段式的好处是，脚本只负责触发和动作，人只负责升级。分歧不会消失，但会被收敛到一个有归属的环节，而不是散落在每次讨论里。
用一条假设流程检验描述是否够用
把写好的例外描述交给一个不参与讨论的人，让他按描述处理三个样本。如果他需要额外提问才能决定，说明描述里还缺条件或动作。
假设脚本对一批页面执行后，待确认清单里出现了二十条记录。先不要急着改脚本，先看这二十条集中在哪几类触发条件上。如果集中在同一类，说明这个条件需要拆细；如果分散在多类，说明升级环节的分工需要明确。这个观察动作本身不证明处理正确，它只是把“哪里还需要人”暴露出来。
比较改动前后时要注意，页面处理量、抓取表现或某项统计的变化，可能同时受搜索需求波动、采集时间差、其他改动叠加影响。单看一个数字归零或上升，不能直接说明这次例外描述写对了。更稳的做法是固定样本、固定观察窗口，并记录同期还有哪些改动同时生效。
把例外描述沉淀成可复用的核对项
每次人工处理完待确认清单后，把新出现的分歧补进样本，把反复出现的分歧升级成正式条件。这样例外描述会随处理过程逐步收敛，而不是每次重写。
交付给脚本的需求里，至少保留三样东西：分歧样本编号、每个例外的三段式描述、以及升级环节的责任人与时限。三者缺一，执行者就只能靠猜，而猜出来的结果又会变成下一轮分歧。
如果同一类例外连续多次都由人工按同一方式处理，就说明它已经具备转成默认动作的条件，此时再改脚本，依据是处理记录，而不是某次讨论里的印象。
