百度排名优化方法把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6337e91f5601.html
📄
百度排名优化方法把人工经验写成脚本需求时怎样描述例外情况
把人工经验写成脚本需求，例外情况不能只写一句“特殊页面另行处理”，而要写成可判定的条件：什么输入下脚本走默认规则，什么输入下必须停下等人判断。判断标准是这条经验在多少种页面上成立、失败时的代价是否可逆。默认规则覆盖大多数样本，例外清单只收那些“照搬会改错”的页面，两者分开写，脚本才不会把个别样本的结论硬套到全站。
先判断这条经验是普遍规律还是样本特征
人工操作时，你看到的是眼前这一批页面，容易把“这批页面的共同点”当成“所有页面的规律”。写脚本需求前，先做一次反向检验：把这条经验套到结构不同、内容类型不同、上线时间不同的页面上，看它是否仍然成立。
- 如果经验依赖的是页面结构，比如某个固定容器、某段固定文案，那么结构一变经验就失效，属于样本特征，必须写进例外。
- 如果经验依赖的是内容本身，比如标题与正文主题是否一致、正文是否覆盖了用户会追问的下一层问题，那么它更接近可迁移的判断，但仍要注明适用前提。
- 如果经验依赖的是数据表现，比如某个位置的点击率，那么要把采集口径、时间窗口和样本量一起写进需求，否则脚本无法复现判断。
这一步的产出不是结论，而是一份“成立条件”清单。条件越具体，后面写例外时越省力。
两种条件下选择不同的处理方式
条件一：例外页面数量少，且每一条都能用明确字段识别，比如页面类型标记、模板标识、内容来源字段。此时选择“脚本跳过加人工复核”。实施动作是让脚本在命中例外条件时不做修改，只输出一条待处理记录，附带页面标识和命中的条件名。结果是这批页面保持原状，人工按记录逐条处理，脚本不会误改。
条件二：例外页面数量多，或者例外条件本身模糊，无法用字段稳定识别。此时选择“脚本只做只读检查，不执行修改”。实施动作是让脚本输出检查结果，由人决定是否改、怎么改。结果是处理速度变慢，但避免了把错误规则批量放大。判断选哪种的依据是：能否用一条不依赖人工解读的条件把例外圈出来。能圈出来就走条件一，圈不出来就走条件二。
假设有一个页面模板，正文区在部分页面被替换成了列表结构。人工经验里“正文首段要包含核心词”在这批页面上不成立。如果脚本按默认规则给列表页补首段，可能破坏原有结构。此时应把“正文区为列表结构”写成例外条件，脚本命中后跳过，而不是让脚本猜哪种结构更合适。
例外清单要写成可执行的条件，而不是备注
常见的错误写法是“特殊情况请人工判断”，这种描述对脚本没有约束力。可执行的条件至少包含三部分：判定字段、判定值或范围、命中后的动作。
- 判定字段要来自脚本能读到的数据，比如页面类型、模板标识、内容来源、更新时间区间。不要写“看起来不合适的页面”这类无法程序化的描述。
- 判定值要给边界。比如“正文长度低于某个值时跳过”，这个值要有依据，可以来自人工复核过的样本分布，而不是随手定的整数。
- 命中后的动作要唯一。跳过、只记录、降级处理、进入人工队列，只能选一个，不能写“视情况而定”。
写完条件后，用一批已知的例外页面和正常页面各跑一遍，检查是否有正常页面被误判为例外，或者例外页面被漏掉。误判和漏判的代价不同，要分别记录，再决定条件是否需要收紧或放宽。
用一次改动前后对比验证例外是否写对
脚本上线后，拿改动前后的数据做比较时，要意识到季节、搜索需求变化和采集差异都会影响结果，不能把任何波动都归因于脚本。可行的做法是：先确认例外页面确实没被改动，再确认正常页面按预期执行，最后才看整体数据方向。如果例外页面出现了变化，说明条件没生效，应回到条件定义这一步重新检查，而不是先调默认规则。
如果某段时间请求量或抓取量出现归零或异常下降，也不能单独据此判断例外写错了。采集延迟、统计口径调整、页面本身下线都是合理解释。先排除这些原因，再回到脚本日志里核对命中记录，才能确定下一步是修条件还是修执行。
