搜索排名怎么优化，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /090c8f3ad31e.html
📄
搜索排名怎么优化，把人工经验写成脚本需求时怎样描述例外情况
结论是：把例外情况写成脚本需求时，先描述“什么条件下不执行默认动作”，再规定“遇到该条件时输出什么、交给谁判断”。如果只写正常路径，脚本会把原本需要人工判断的页面一并处理，后续排查会失去线索。一个反例是：当数据不完整、权限不足时，例外规则写得再细，脚本也可能无法拿到判断依据，此时应把该情况标为待人工确认，而不是强行套用规则。
先区分三类例外，别都写成“特殊情况”
人工经验里常出现“这个页面先不动”“那个词再观察一下”，转成脚本需求时，至少要拆成三类：数据缺失、规则冲突、业务例外。数据缺失指字段为空、抓取不完整或权限受限；规则冲突指同一页面同时命中两条互相矛盾的判断；业务例外指页面本身有活动、合作或临时安排，不适合按常规处理。
三类例外的下一步不同。数据缺失应进入待补采清单，规则冲突应输出冲突双方和命中位置，业务例外应记录生效时间与解除条件。若全部笼统写成“跳过”，脚本虽然能跑完，但人工接手时分不清是缺数据、规则打架，还是业务上本来就不该动。
描述例外时，至少写清四个字段
脚本需求中的例外描述，建议固定为四段：触发条件、默认动作、例外动作、输出证据。例如，假设某条经验是“标题与正文主题明显不符时先不改”，可以写成：
- 触发条件：标题与正文主题词重合度低于设定阈值，或标题字段为空；
- 默认动作：进入标题改写候选；
- 例外动作：不自动改写，标记为待人工确认；
- 输出证据：页面标识、命中字段、阈值、实际取值。
这里的阈值只是假设示例，不是行业标准。重点在于：例外不是一句“人工判断”，而是让脚本能说清“为什么这次没按默认动作走”。输出证据越具体，下一步越容易决定是补数据、改规则，还是维持人工处理。
数据不完整时，例外规则要降级而不是硬判
缺少完整数据或权限时，最容易犯的错是把“拿不到”当成“不符合”。例如，脚本想判断页面是否属于某类模板，但只能读到部分结构，这时不应直接归入“可批量修改”，而应输出无法判定。无法判定不是失败，而是一种有效结果，它告诉人工需要补哪一项数据或申请哪一项权限。
可执行的最小动作是：先列出判断默认动作所必需的最少字段，再为每个字段写“为空时怎么办”。如果某个字段为空会导致后续所有判断都不可靠，就把该页面整体转入待确认队列。结果会直接影响下一步：待确认队列变长，说明数据采集或权限范围需要先解决；待确认队列很短，才适合继续扩大脚本处理范围。
一个反例：例外写得越细，反而越容易误判
假设某条经验是“页面近期有较大改动时先观察”，脚本据此读取改动时间。但如果数据采集本身有延迟，或不同来源的时间口径不一致，那么“近期”这个条件就会把正常页面误判为例外，也可能把真正改过的页面漏掉。此时例外规则越细，越依赖数据质量；数据口径不统一时，细规则不会更安全，只会更难解释。
反过来说，如果数据来源单一、字段含义稳定、权限足够覆盖判断所需范围，那么把例外写细是值得的，因为它能减少人工重复判断。判断条件是否成立，不取决于规则写得多漂亮，而取决于脚本能否稳定拿到同一口径的证据。
改完之后怎样验证，才不会把波动当成效果
脚本上线后，不要只看处理数量是否下降。处理数量归零可能来自规则收紧、数据源变化、权限调整或采集延迟，不能单独证明例外处理正确。比较改动前后时，要考虑季节、搜索需求变化和数据采集差异；如果缺少对照，就不要把一次前后差异直接归因于脚本。
更稳妥的下一步是：保留一小批人工已判定页面作为核对样本，检查脚本对例外的标记是否与人工一致。若不一致集中在某一类字段，就回到该类字段的触发条件和输出证据上修改；若不一致分散，说明例外分类本身还需要重新拆分。这样每一步动作都能为下一步提供依据，而不是只留下一个“已优化”的结论。
