超链接制作方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /338c3e624f6b.html
📄
超链接制作方法：把人工经验写成脚本需求时怎样描述例外情况
先给结论：描述例外情况时，不要只写“遇到异常就跳过”，而要写成“触发条件＋判定依据＋处理动作＋记录字段”四段式。这样脚本才能在不完整数据或权限受限时继续跑，并把无法判断的链接单独留下，而不是静默丢弃。但这条结论有一个反例：如果例外本身来自“规则尚未确定”，四段式会制造虚假确定性，此时应改为“标记待确认”，而不是强行给出处理动作。
例外描述为什么不能只写“跳过异常”
人工制作超链接时，经验往往藏在动作里：看到一个链接指向登录页，会先判断它是不是导航入口，再决定是否保留。写成脚本需求时，如果只写“异常链接跳过”，开发只能自行猜测什么是异常。结果通常是：脚本把所有无法访问的链接都删掉，而其中一部分只是临时超时或需要权限才能确认的有效目标。
更可执行的做法，是把例外拆成可观察的触发条件。例如：
- 触发条件：目标返回状态无法确认，或响应内容与预期页面类型不一致。
- 判定依据：是否有明确的状态码、是否在允许的等待时间内返回、是否命中已知的登录或验证页面特征。
- 处理动作：保留原链接、替换为备用目标、标记待人工确认，或暂时不写入结果。
- 记录字段：原链接、触发原因、判定依据、处理结果、需要谁复核。
这四段写清楚后，脚本的输出不再只是“成功”或“失败”，而是一份可以交接的清单。下一步动作取决于记录字段：如果多数例外集中在“无法确认”，说明缺的是权限或数据，而不是规则；如果集中在“命中登录页”，说明需要先明确登录页是否算有效目标。
缺少完整数据或权限时，最小可执行动作是什么
在没有完整抓取数据、也没有后台权限的情况下，仍然可以先做一件事：把例外分成“可自动判定”和“必须人工确认”两类，并只对第一类写脚本规则。
可自动判定的例子：目标地址格式明显不完整、协议缺失且无法补全、同一页面内重复出现完全相同的目标。这类例外不需要访问权限就能判断，脚本可以直接标记或去重。
必须人工确认的例子：目标需要登录才能看到内容、目标返回的页面类型与上下文不符、目标地址曾经有效但现在无法确认。这类例外不应由脚本直接删除，而应输出到待确认列表。
这样做的结果是：脚本可以先用最小规则跑起来，产出一份“已处理”和“待确认”分离的结果。下一步不是继续加规则，而是先看待确认列表里哪一类最多，再决定是否申请权限、补充数据，或调整链接制作标准。需要说明的是，待确认数量下降不能单独证明规则变好了，也可能只是采集时间、访问频率或目标站点状态变化导致的。
一个假设例子：把“链接打不开就删掉”改成四段式
假设有一批人工整理的内链，需要写成脚本批量检查。原始需求只有一句：“打不开的链接删掉。”按这个需求，脚本可能把超时、需要登录、临时维护的链接全部删除。
改成四段式后，需求可以写成：
- 触发条件：请求在设定等待时间内未返回明确成功状态。
- 判定依据：区分“明确失败状态”“超时”“返回登录或验证页面”“返回内容与预期类型不符”。
- 处理动作：明确失败状态标记为待替换；超时和登录页面标记为待确认；内容类型不符保留原链接并记录。
- 记录字段：链接、触发类型、等待时长、返回特征、建议动作。
这个例子的数字只是说明比较方法，不是真实项目结果。它的作用是让脚本输出可复核，而不是替人做最终判断。下一步动作是抽样查看“待确认”记录：如果同一目标反复出现超时，可能需要调整等待时间或换时间段再试；如果反复出现登录页面，则需要先确认这类页面是否属于允许的目标。
什么情况下四段式会失效
四段式成立的前提是：例外类型可以被事先列举，且每类都有相对稳定的判定依据。如果规则本身还在变化，例如团队尚未决定“登录页是否算有效目标”，那么强行写处理动作只会把未决问题藏进脚本里。
这时应把需求改成“标记待确认”，并明确记录：当前无法判定的原因、需要谁做决定、决定后会影响哪些链接。等规则确定后，再把待确认项转成具体的触发条件和处理动作。否则脚本越自动，后续返工越难发现。
下一步：先写例外清单，再写脚本规则
实际动作可以很小：拿一张表，列出最近人工处理过的例外，按“触发条件、判定依据、处理动作、记录字段”四列填写。填不出来的格子，就是脚本暂时不该自动处理的部分。
填完后检查两件事：第一，是否有例外被重复归入不同类别；第二，是否有处理动作会导致链接被永久删除却无法追溯。如果存在，先改成标记而不是删除。这样脚本第一版即使不完整，也能产出可交接、可复核的结果，而不是把人工经验变成一批无法解释的删除记录。
