系统SEO排名技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5f7732d51506.html
📄
系统SEO排名技巧：把人工经验写成脚本需求时怎样描述例外情况
结论先说：例外情况要写成“可判定的条件 + 明确动作 + 兜底去向”，而不是写成“遇到特殊情况再人工看”。如果例外无法用现有字段判定，就应把脚本拆成两段：先输出待确认清单，再对确认结果执行动作。这样做会增加一次人工确认，但能避免脚本把正常页面误改，代价是流程变长、需要指定谁在什么时限内处理清单。
先决定例外写在脚本里还是清单里
两种做法都成立，取决于例外能否被稳定识别。若例外可以用已有数据字段判断，例如某个字段为空、状态值等于某个固定值、同一规则命中次数超过阈值，就适合写进脚本，让脚本直接跳过或走另一条分支。若例外只能靠语义判断，例如“这段文案是否真的在回答搜索意图”“这个页面是否属于品牌核心页”，就不适合硬写成条件，应让脚本输出清单，由人确认后再执行。
判断标准可以落到一句话：同一条例外，换一个人来看，是否会得到相同结论。会，就写成脚本条件；不会，就写成清单。把语义判断硬塞进脚本，常见结果是条件越加越多，最后没人敢改，也没人知道某条页面为什么被跳过。
例外描述必须包含的三个字段
无论走脚本还是走清单，一条例外至少要有三部分。第一是触发条件，用已有字段或可复算的规则表达，不要写“看起来不合适”。第二是命中后的动作，是跳过、降级、还是进入待确认。第三是兜底去向，即没有人处理时这条记录停在哪里、由谁负责、多久清理一次。
- 触发条件：写清字段名、比较方式和阈值，例如“标题字段为空”或“同一模板命中次数大于设定值”。
- 命中动作：写清是跳过、只记录、还是执行替代动作，不要留“视情况而定”。
- 兜底去向：写清进入哪份清单、由谁确认、确认后回到脚本的哪一步。
一个假设例子：某批页面要统一补充结构化数据，规则是“缺少某字段就补默认值”。如果直接把“页面类型不明确”写成例外，脚本无法判断。改成“页面类型字段为空则跳过并写入待确认清单”，脚本就能执行；人工确认页面类型后，再把结果回填，下一轮脚本即可处理。这里的动作是回填字段，结果是这批页面从待确认清单进入可执行范围，下一步才轮到批量执行。
会使结论失效的反例
上述做法有一个明确反例：如果例外比例很高，清单本身会变成新的瓶颈。假设待确认记录多到人工在约定时限内处理不完，脚本虽然没误改页面，但整批任务实际停滞。此时继续增加例外条件没有意义，应先检查触发条件是否过宽，或把任务拆成更小的批次，让每批的待确认量落在可处理范围内。
另一个反例是数据本身不稳定。若触发条件依赖的字段经常缺失或延迟更新，脚本会把数据问题误判为页面例外。这时要先确认字段的采集口径和更新节奏，再决定是否把它作为判定依据。请求量、抓取量或某类记录数下降，不能单独证明脚本处理正确，也可能是采集差异、需求变化或上游数据延迟造成的。
下一步：先跑只记录不执行的版本
把例外写清楚后，不要直接执行改动。先让脚本只记录命中结果，不修改任何页面，然后抽查清单：命中原因是否和预期一致，是否有明显误判，待确认量是否可处理。若清单质量稳定，再开启执行动作；若误判集中，就回到触发条件修改，而不是在执行阶段临时加人工判断。改动前后比较时，还要把季节、搜索需求变化和数据采集差异考虑进去，避免把并行发生的变化归因于这一次改动。
