网站SEO步骤：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4493f87a2766.html
📄
网站SEO步骤：把人工经验写成脚本需求时怎样描述例外情况
描述例外情况的核心不是穷举所有可能，而是为脚本划定“遇到什么就停下、交给谁判断”的边界。以你手上的一份页面清单为例：先写清正常路径，再把人工操作中依赖肉眼、上下文或外部确认的判断点单独标出，写成带触发条件的例外分支，而不是把例外塞进主流程里当注释。
先区分三类判断：可规则化、需阈值、必须人工
人工处理页面时，很多动作看起来连续，其实混着三种不同性质的判断。写脚本需求前，把每个动作归入一类，例外描述才有落点。
- 可规则化：如“页面标题为空则记录”。条件明确，脚本可直接执行。
- 需阈值：如“标题与正文主题明显不符”。需要你给出可比较的指标，例如标题词是否出现在正文前若干段。
- 必须人工：如“这个页面是否属于应保留的品牌词落地页”。涉及业务意图，脚本只能标记待审。
假设你有一份200个页面的清单，人工检查时发现其中3个标题与正文主题偏离。这3个样本成立，不代表可以写成“标题不含正文关键词就判为偏离”。规模化后，同义词、品牌名、栏目名都会让规则误伤。此时例外描述应写成：命中阈值后不直接改标题，而是输出候选页面并标注命中的具体条件，由人确认后再进入修改队列。
把例外写成“触发条件+默认动作+升级路径”
脚本需求里最有用的例外句式，是让每个分支都能被独立测试。可以用下面三段式描述：
- 触发条件：写明可观察的信号，例如“同一URL在两次抓取中返回的标题不同”。
- 默认动作：脚本遇到该信号时做什么，例如“保留旧值，记录两次结果，不自动覆盖”。
- 升级路径：什么情况下转人工，例如“同一URL连续三次结果不一致，进入人工复核列表”。
这样做的好处是：例外不会让脚本中断，也不会被静默忽略。你检查输出时，能看到哪些页面走了默认动作、哪些被升级。下一步该修规则还是该改数据源，取决于这两类记录的比例和具体样本。
用一份页面清单走一遍转换过程
假设你手上有一份包含URL、原标题、正文首段和上次更新时间的清单，想写成脚本需求，让它判断哪些页面需要更新标题。人工经验通常是“标题太泛就改”。直接写成脚本会失败，因为“太泛”没有边界。
转换步骤可以这样走：
- 先写正常路径：标题长度在合理区间、正文首段包含标题核心词，则标记为“暂不处理”。
- 再写例外一：标题长度正常但正文首段与标题无共同词，标记为“待确认”，不自动改写。
- 再写例外二：标题为空或与清单中另一页面标题完全相同，标记为“疑似重复”，输出两个URL供人工比较。
- 最后写例外三：页面属于栏目页、标签页或分页，不进入标题改写队列，只记录数量。
执行后，如果“待确认”数量远大于预期，先别改阈值，而应抽查这些页面，看是正文首段本身太短，还是共同词判断方式不适用。这个动作会直接影响下一步：是调整判断依据，还是把这类页面整体移出脚本处理范围。
边界要写清：哪些结论不能从个别样本直接放大
个别样本成立但规模化后出现例外，常见原因有三类，写需求时要分别说明。
- 样本代表性不足：3个页面标题偏离，可能只是这3个页面所在栏目结构特殊。脚本上线前应说明该规则只适用于哪些目录或页面类型。
- 判断依据依赖上下文：人工判断时看了页面在站内的位置、导航和内部链接，脚本只拿到标题和首段，信息量不同，结论自然不同。例外描述里应写明脚本可用的字段，不能默认它拥有全部人工视角。
- 数据采集差异：两次抓取结果不同，可能是页面确实变了，也可能是抓取时间、返回内容或渲染状态不同。看到差异归零或数量突增，不能单独证明某次改动正确，还要看采集方式和需求侧是否同时变化。
比较改动前后时，要考虑季节、搜索需求波动和数据采集口径差异。例如同一批页面在假期前后表现不同，不能只归因于标题修改。更稳妥的做法是保留同期未改动页面作为对照，观察两组变化方向是否一致。
交付前用一个小检查表验证例外是否可执行
写完脚本需求后，用下面几个问题快速检查例外描述是否足够具体：
- 每个例外是否有可观察的触发条件，而不是“看起来不合适”？
- 触发后脚本默认做什么，是否明确到不会自动覆盖原数据？
- 升级人工的条件是否可计数，例如连续次数、涉及页面数或字段缺失？
- 是否写明了不适用该脚本的页面类型或目录？
- 输出结果中能否区分“规则命中”“阈值命中”“人工待审”三类记录？
如果这五项都能回答，例外就不再是散落在人工经验里的感觉，而是一组可测试、可回退、可交接的处理分支。接下来无论你是调整规则还是扩大处理范围，都能先从输出记录里找到依据，而不是重新靠肉眼翻一遍清单。
