SEO排名提升方法把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f9f358f4849d.html
📄
SEO排名提升方法把人工经验写成脚本需求时怎样描述例外情况
把人工经验写成脚本需求时，例外情况不能写成“其他情况按经验处理”，而要写成可判定的条件分支：先明确哪些输入算正常样本，再为每个例外指定识别信号、处理动作和跳过条件。这样脚本跑出来的结果才能被复核，而不是把人的模糊判断藏进代码里。
先判断经验里有没有稳定前提
人工做排名相关调整时，往往默认了几个前提：页面类型一致、模板结构接近、数据采集窗口相同。写脚本需求前，先判断这些前提是否仍然成立。
- 前提稳定时：可以把人工判断压缩成规则，例如“标题长度超过阈值就标记待改”，例外只处理缺失值和乱码。
- 前提已变化时：不能直接照搬旧规则。比如站点从单一列表页扩展到多种详情模板后，同一个标题长度阈值对不同模板的含义不同，例外描述必须按模板类型分开。
判断依据不是感觉，而是看同一批页面里，人工处理动作是否随模板、栏目或数据来源发生变化。如果同一动作在不同分组下结论相反，说明前提已经分化，脚本需求里必须为每组写独立分支。
例外描述要落到可观测信号上
“页面质量差”“内容偏薄”这类说法无法直接写进脚本，因为它们没有可观测信号。例外描述至少应包含三层：识别条件、判断阈值、处理动作。
- 识别条件：用页面结构、字段是否存在、抓取状态或数据完整度来界定，而不是用主观评价。
- 判断阈值：给出具体比较方式，例如“正文可见字符数低于同模板中位数的一半”，并注明这个中位数按哪个分组计算。
- 处理动作：明确例外是跳过、标记待人工复核，还是降级处理。三种动作对后续流程的影响完全不同。
假设一个场景：人工经验是“正文太短的页面不参与标题优化”。写成脚本需求时，可以描述为：先按模板分组计算正文可见字符数的中位数；低于该中位数一半的页面标记为短内容例外，跳过标题改写，但保留在待复核列表。这个例子只用于说明描述方法，不代表任何真实站点的处理结果。
两种条件下应做不同选择
例外处理的分岔点通常在于：例外是数据问题还是业务问题。
- 当例外来自采集或字段缺失：优先修复采集，而不是在脚本里写补丁。因为补丁会把数据缺口当成业务特征，后续所有统计都会偏离。动作是记录缺失字段和缺失比例，先补数据再重跑。
- 当例外来自业务本身：例如某些页面本来就不适合做标题优化，应在脚本里显式排除，并写明排除原因和复核入口。动作是维护一份例外清单，脚本读取清单后跳过，同时输出跳过数量供人工抽查。
选择依据是：例外是否会在下一次采集时消失。会消失的按数据问题处理，不会消失的按业务规则处理。把这两类混在一起，脚本就会越改越难维护。
实施动作与结果如何影响下一步
写完例外描述后，先在小样本上运行，重点看三类输出：正常处理数量、例外跳过数量、人工复核数量。
如果例外跳过数量远高于正常处理数量，说明识别条件过宽，下一步应收紧阈值或拆分分组；如果人工复核数量居高不下，说明例外描述仍不够可判定，下一步应把复核中重复出现的判断补成新分支。反过来，如果三类数量都很少，可能是样本太小，不能据此判断规则稳定。
还要注意，改动前后的比较不能只看单次结果。季节变化、搜索需求波动和数据采集时间差异都会影响观测值。一次改动后指标变化，不能直接归因于这次改动，需要结合同期未改动分组做对照，才能判断变化是否来自脚本处理。
例外清单要能被人复查
脚本里的例外不能只存在于代码注释中。建议单独维护一份例外清单，每条包含：例外名称、识别条件、处理动作、最近一次复核时间、负责人。这样当业务前提再次变化时，能快速定位哪些分支需要重写。
清单里还要写清楚不适用条件。例如某条例外只适用于特定模板或特定栏目，一旦模板改版，这条例外就应失效并重新评估。没有失效条件的例外，会在业务变化后继续悄悄生效，把错误结论带进后续决策。
最终，例外描述的合格标准是：另一个人拿着这份需求，能在不看原始经验的情况下判断某个输入该走哪条分支，并知道走错时从哪里复查。做到这一点，人工经验才算真正变成了可执行的脚本需求。
