📍 WDQWDWQD987AAAAA:216.73.217.86
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fdb4c9490194.html
📄

排名优化方法，把人工经验写成脚本需求时怎样描述例外情况

例外情况不能只写“遇到异常就跳过”，而要写成可核对的三件事：触发条件、此时采用哪个动作、动作之后由谁或哪条规则接手。比如“若目标页面返回 404，则记录该 URL 并停止后续改写，交给人工确认是否保留原链接”，这样脚本执行后产生的记录本身就能成为下一步判断依据。

先把“例外”从形容词改成可观察的字段

人工经验里常出现“页面不正常”“内容太薄”“链接可疑”这类判断，写进脚本需求时，第一步是把它拆成脚本能观察到的字段。以一份待处理的页面清单为例，至少可以拆成四类：HTTP 状态、页面标题与正文长度、链接目标状态、页面是否被 robots 或规范标签限制。字段确定后，再为每个字段规定一个判断方式，例如标题为空、正文可见字符少于某个阈值、链接目标返回非 200。

这里的关键不是把阈值定得多准，而是让不同角色对同一份资料的理解落在同一列上。运营说“这页没内容”，开发看到的可能是正文抽取失败；SEO 说“这页不该改”，开发看到的可能只是状态码正常。把分歧转成字段和取值后，争论就从“感觉对不对”变成“这条记录为什么被判为例外”。

例外分支要写清触发、动作和交接

只写“如果异常则跳过”不够，因为跳过之后没有留下可核对的信息。一个可执行的例外描述至少包含三部分：

• 触发条件：用脚本能读取的字段描述，例如“目标 URL 返回 404 或 410”。
• 此时动作：明确是记录、跳过、保留原值，还是改用另一条规则，例如“保留原链接文本，不替换为目标 URL”。
• 后续交接：说明这条记录进入哪个队列、由谁复核，或满足什么条件后可以重新进入自动处理。

假设有一批内链需要从旧页面指向新页面，人工经验是“旧页面如果已经打不开，就别硬改”。写成需求时可以落成：若旧页面返回 404，则记录旧 URL、新 URL 和状态码，保留旧页面上的原有链接文本，不执行替换，并把记录放入待人工确认列表。这里的数字和阈值只是示例，实际取值要按站点情况确定。

用一份清单核对例外是否可执行

写完需求后，不要只读一遍文字，而应拿一份真实资料或页面逐条核对。核对时可以问四个问题：这个例外由哪个字段触发；触发后脚本会改变什么、不改变什么；执行结果会留下哪条记录；这条记录下一步由谁处理。如果其中任何一项只能靠口头补充，说明需求还没有写完。

例如同一批页面里，有的正文抽取为空但状态码为 200，有的标题重复但正文完整。前者可能需要先检查抽取规则，后者可能只需要标记为待复核。两种例外如果都写成“异常跳过”，执行后无法区分，后续处理就会重新依赖人工记忆。把触发字段和动作分开写，才能让结果可比较。

多个角色对同一事实有不同理解时，先对齐证据口径

当编辑、开发、运营对同一页面的判断不一致时，先不要争论结论，而是对齐证据口径：大家看的是同一个 URL、同一时间抓取的结果，还是不同时间、不同工具的输出。抓取量或某项统计归零，可能是页面确实变化，也可能是采集失败、规则改动、访问受限或时间窗口不同。把这些合理解释列出来，再决定例外是否需要扩大触发条件。

一个实际动作是：先用同一份页面清单跑一遍只记录、不改动的版本，把每条记录的触发字段和原始值导出，再让各方在同一份结果上标注“应处理”“应保留”“需人工确认”。如果标注分歧集中在某个字段，就回到需求里补充该字段的判断规则；如果分歧集中在动作，就补充交接方式。这样改动的结果会直接影响下一版脚本的范围，而不是反复修改形容词。

验证例外规则时，避免把一次变化当成结论

例外规则上线后，可以用改动前后对照来观察，但不要把一次前后差异直接归因于规则本身。季节、搜索需求变化、数据采集时间和采集方式差异，都可能让同一指标看起来不同。更稳妥的做法是保留未改动的对照页面，并记录同一时间窗口内的状态码、可抓取字段和处理记录，先看例外是否按预期触发，再看处理结果是否稳定。

如果某条例外触发后，记录里只有“已跳过”，没有原始值、时间和后续去向，那么它无法帮助任何人做下一次判断。把例外写成可核对的项目，最终是为了让脚本执行的结果能反过来修正规则：哪些触发条件过宽，哪些动作需要人工接手，哪些记录可以进入下一轮自动处理。这样，人工经验才真正变成了可执行、可复核的需求。