SEO优化步骤：把人工经验写成脚本需求时怎样描述例外情况，先判断分歧属于哪一类：事实不同还是判断不同
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /09413ced2a38.html
📄
SEO优化步骤：把人工经验写成脚本需求时怎样描述例外情况，先判断分歧属于哪一类：事实不同还是判断不同
直接回答：不要用“正常情况”“特殊情况”这类词，而要把例外写成“触发条件 + 可观察信号 + 脚本动作 + 人工接管点”。当多个角色对同一事实理解不同时，先让他们各自举出一个能核对的具体页面或字段，再把分歧固化成脚本里的条件分支，而不是塞进一句模糊备注。
先判断分歧属于哪一类：事实不同还是判断不同
例外描述写不清，通常不是表达能力问题，而是分歧类型没分清。可以用一个简单判断：如果两个人看同一份原始数据会得出同一结论，分歧属于事实不同；如果看同一份数据仍会得出不同结论，分歧属于判断不同。
- 事实不同：一个人说“这个页面没被处理”，另一个人说“已经处理过”。这类分歧靠核对日志、字段值、时间戳就能收敛，脚本里应写成断言和校验，而不是例外分支。
- 判断不同：一个人认为标题过短该改，另一个人认为标题虽然短但符合该页意图。这类分歧没有唯一答案，脚本里应写成阈值加人工复核标记，把决定权留给指定角色。
把这两类混在一起，脚本需求就会出现“遇到不合适的情况请酌情处理”这种无法执行的句子。可执行的动作是先要求每个角色写出自己的判断依据，例如“字符数少于某值”还是“与页面主题不匹配”，依据不同就说明分歧属于判断类。
条件一：规则可以量化时，例外写成边界值和默认动作
当分歧能落到可测量的量上，例外就该写成明确的边界。假设某团队约定页面标题长度以字符数衡量，那么需求里应写清：默认动作是什么，边界值是多少，超出边界时脚本做什么。
一个假设例子：默认动作是“标题字符数在某个区间内则保留”，例外是“低于下限或高于上限”。脚本遇到例外时不直接改写，而是输出一条待复核记录，附带页面地址、当前标题、字符数和判定原因。这样做的结果是，复核者拿到的是可核对的项目，而不是一句“标题有问题”。
这里的关键取舍是：能量化就量化，但量化不等于自动执行。把例外标出来和直接改掉是两件事。如果脚本一遇到边界值就自动改写，后续复核就失去了判断空间；如果只标不改，复核成本会上升，但误改风险下降。选择哪一种，取决于该改动是否可逆、影响面是否集中在少数页面。
条件二：规则依赖语境时，例外写成触发信号加人工接管点
有些判断无法量化，比如“这段内容是否仍然符合页面意图”。这时例外不能写成数值区间，而要写成触发信号和接管点。
触发信号是脚本能观察到的现象，例如：同一页面在两次抓取之间正文主体发生变化、页面类型字段与模板不匹配、多个角色对同一字段给出不同标注。接管点是明确的人，例如“由内容负责人复核”，而不是“由相关同事确认”。
实施动作可以这样设计：脚本先按默认规则处理，把所有触发信号命中的页面单独输出成一份清单，清单里每一行包含页面地址、命中信号、脚本已做动作、未做动作。复核者只需对未做动作的部分作决定，已做动作的部分如果被推翻，再回填成新的例外条件。这样一轮之后，例外清单会收缩，因为其中一部分会被证明是事实分歧，可以直接转成断言。
把分歧转成可核对项目的最小结构
无论属于哪一类，例外描述都可以落成四个字段，缺一个都会让脚本需求变得含糊：
- 触发条件：脚本在什么情况下进入例外分支，写成可判断的表达式或信号名。
- 可观察信号：进入分支后记录什么，例如字段值、时间戳、页面地址、标注来源。
- 脚本动作：跳过、标记、输出清单，还是执行某个可逆的默认动作。
- 接管点：谁在什么时限内复核，复核结果如何回填成新的条件。
核对方式是让不参与编写的人只看这份结构，判断自己能否复现同一个决定。如果复现不了，说明某个字段仍然依赖未写出的默契。
比较改动效果时要留意的干扰
例外条件上线后，团队常想比较改动前后。此时要注意：季节变化、搜索需求本身波动、数据采集口径调整，都可能让同一指标前后不同。一次改动前后的差异不能单独证明例外处理正确，还需要看被标记页面的复核通过率、被推翻的比例，以及例外清单是否在后续轮次中收缩。这些观察只用于判断规则是否更可核对，不构成对收录或排名的承诺。
如果例外清单长期不收缩，通常说明触发条件写得太宽，或者接管点没有真正作决定。下一步不是继续加规则，而是回到最初的分歧记录，确认哪些属于事实不同，把它们从例外分支移出，改成脚本里的断言。
