seo实战心得，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /22163f1a9d20.html
📄
seo实战心得，把人工经验写成脚本需求时怎样描述例外情况
直接回答：例外情况要写成“触发条件 + 判定依据 + 期望动作 + 不确定时归谁处理”四段，而不是写成“特殊情况特殊处理”。只有这样，脚本执行者、复核者和业务方才能对同一事实得出相同结论。适用前提是：这条经验已被至少一次人工操作验证过，且例外能被观察或记录；如果例外只存在于某个人脑中的直觉，先补记录，不要急着写进需求。
先分清三种“例外”，写法完全不同
把分歧转成可核对项目，第一步不是讨论谁对，而是判断分歧属于哪一类。三类例外的描述方式差别很大：
- 数据例外：字段缺失、格式不一致、同一事实有两种取值。描述重点是判定顺序，例如“标题为空时先取 H1，H1 也为空才标记待补”。
- 规则例外：常规流程不适用，但原因明确。描述重点是触发边界，例如“页面类型为聚合页时不套用单品模板”。
- 判断例外：需要人来看，脚本只负责收集证据。描述重点是输出什么、交给谁，例如“输出候选清单和截图路径，由内容负责人决定”。
很多争执源于把第三类硬写成第一类。脚本无法替人做价值判断，但可以把判断所需的材料准备齐。
用可核对的字段代替形容词
“内容质量差”“参数明显异常”“页面重要”这类词，不同角色理解不同，写进需求必然返工。替换方法是：把形容词换成可观察的字段和阈值，并注明阈值来源。
假设一个场景：人工处理时发现，某些列表页的筛选参数组合会生成大量近似页面，人工会挑一部分保留、一部分不处理。写成需求时可以这样描述：
- 触发条件：URL 含筛选参数，且参数组合数超过人工设定的上限。
- 判定依据：同一路径下参数组合的正文相似度高于设定值，或可索引参数组合数量超过上限。
- 期望动作：不自动删除，输出分组清单，标注每组代表 URL。
- 不确定时：清单交给谁、多久内回复、超时默认怎么处理。
这里的阈值是假设值，实际取值要由业务方确认，不能由脚本作者单方面决定。阈值一旦写死，后续修改要有记录，否则不同角色会各自记着不同版本。
把“谁说了算”写进需求，而不是留在会议里
例外描述最容易漏掉的是决策权。建议在每条例外后附一个责任字段，至少包含三项：谁提供判定依据、谁批准例外、例外结束后由谁确认状态。缺少这一层，脚本执行完，分歧仍然存在。
一个实际动作是：在需求文档里为每条例外建一行核对记录，包含触发样本、人工处理结果、脚本处理结果、差异原因。执行后拿这批样本回放，看脚本输出是否与人工一致。如果差异集中在某一类触发条件上，说明描述粒度不够，下一步应细化该类条件，而不是扩大例外范围。
需要提醒的是，回放一致不等于线上结果正确。样本可能不覆盖真实分布，季节和搜索需求变化也会让同一批页面的表现不同。比较改动前后时，要把采集差异和需求波动一起考虑，不能把一次回放通过当作长期验证。
一个反例：什么时候这套写法会失效
如果人工经验本身没有稳定结论，比如同一个人在不同时间对同类页面处理方式不同，那么无论例外描述多细，脚本都会放大这种不一致。此时正确动作是先做人工一致性核对：让两位执行者独立处理同一批样本，比较差异。差异大，就先统一判断标准；差异小，再把共识部分写成需求。
另一个失效情形是例外依赖外部信息，而脚本拿不到。例如判断某页面是否属于重点栏目，需要另一个团队的口头确认。这种情况下，需求里应写明“该字段由外部提供，缺失时进入待定队列”，而不是让脚本猜测。
下一步动作
选一批已经人工处理过的样本，按“触发条件、判定依据、期望动作、责任归属”四栏整理成表，再让脚本按这张表回放。回放结果与人工记录不一致的地方，就是需求描述还需要补充的地方；如果一致，再进入小范围试运行，并保留人工复核通道。这样做的结果会直接决定下一步是继续细化条件，还是可以扩大执行范围。
