超链接怎么做：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5661ab6503a3.html
📄
超链接怎么做：把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要只写“遇到特殊情况就跳过”，而要把例外写成可判定的条件、处理动作和记录字段三部分。人工处理链接时凭经验绕开的坑，脚本读不懂，只有把“什么算例外、例外时做什么、做完留下什么”写清楚，脚本才可能稳定执行。下面从一个常见矛盾讲起。
矛盾现象：人工做得又快又稳，脚本却频繁出错
同一批链接，人工检查时几乎不出问题，交给脚本后却反复在少数页面上失败。多数人第一反应是“脚本能力不够”，但更常见的原因是：人工经验里藏着大量没有写出来的例外判断。
例如人工看到某页链接指向站内搜索页，会本能跳过；看到链接文本是“点击这里”会去上下文找真实目标；看到同一地址带不同参数会判断哪个是正文入口。这些动作在人工那里是瞬间完成的，写需求时却常常被压缩成一句“正常处理即可”。脚本没有这种压缩能力，它只会按字面执行。
两种解释，先分清是哪一种
脚本在例外上出错，通常有两种解释，处理方式完全不同。
- 解释一：例外本身没被识别。写需求的人默认“例外很少”，没有列出判定条件。脚本把所有链接一视同仁，于是把该跳过的当成了正常项。
- 解释二：例外被识别了，但没有定义动作。需求里写了“异常链接需注意”，却没写注意之后是跳过、标记待人工、还是改写后继续。脚本只能停在原地或按默认值走。
这两种解释的修复方向相反：前者要补判定规则，后者要补处理动作。如果分不清，很容易在错误的一侧反复加代码。
能区分两种解释的证据
要判断属于哪一种，可以看脚本的输出记录，而不是只看失败数量。
- 如果失败项集中在某几类链接（例如带参数的、指向站内的、文本无意义的），说明判定条件缺失，偏向解释一。
- 如果失败项散落在各类链接上，且日志停在同一步，说明脚本认出了异常但不知道下一步做什么，偏向解释二。
- 如果同一批链接换一次运行结果就变，还要考虑数据采集差异或页面本身在变化，不能直接归因于需求写法。
注意：失败数量下降或某类链接处理量归零，不能单独证明改对了。也可能是判定条件过严，把正常链接一起挡掉了，需要回看被跳过的样本。
把例外写成脚本需求的三段结构
确认问题后，按下面三段改写需求，每一段都对应脚本能执行的内容。
第一段：判定条件
用脚本能比较的字段描述，而不是用“看起来不正常”这类描述。例如：链接目标与当前页面同域但路径为搜索页；链接文本为空或仅为“更多”；同一目标在一页内出现多次且参数不同。条件要写成“满足 A 且满足 B”，避免“或”堆太多导致边界模糊。
第二段：处理动作
每个条件对应一个明确动作：跳过、标记待人工、保留但降级处理、或按规则改写。动作必须是脚本可执行的一步，不能是“酌情处理”。
第三段：记录字段
要求脚本对每个例外输出：命中哪条条件、执行了哪个动作、原始链接是什么。这一步决定了后续能不能复盘。
一个注明假设的短例子：假设某页有 20 个链接，其中 3 个指向站内搜索页。需求写成“搜索页链接跳过并记录”，脚本运行后输出 3 条记录。如果这 3 条里混进了 1 个本该保留的正文入口，说明判定条件过宽，下一步应缩小条件而不是加更多动作。这个例子里的数字只用于说明比较方法，不代表任何真实项目结果。
前提变化时，决策要跟着换
同一套例外写法，在不同前提下结论不同，需要明确切换条件。
- 页面结构稳定时，可以把判定条件写细，动作直接跳过，依赖记录字段做抽查。
- 页面结构频繁变化时，判定条件越细越容易失效，此时应把动作改为“标记待人工”，先保住不漏，再逐步收紧条件。
- 例外占比很低时，优先保证正常链接的处理效率，例外走人工兜底。
- 例外占比升高时，说明原判定条件已不适配，应先重写条件，而不是继续扩大人工兜底。
切换的判断依据是记录字段里的命中分布，而不是感觉。一次改动前后的比较，还要考虑季节、搜索需求变化和数据采集差异，不能把同期波动直接算成改动效果。
落地时先做的一步
先挑一类例外，只写判定条件、动作和记录字段三行，跑一遍，看记录里命中的是不是你预期的那些链接。如果命中集合和人工判断一致，再把这套写法复制到下一类例外；如果不一致，先改条件，不要急着加动作。这样每一步的结果都能决定下一步改哪里，而不是把整份需求推倒重写。
