SEO技巧博客：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f9d2ef76d930.html
📄
SEO技巧博客：把人工经验写成脚本需求时怎样描述例外情况
例外情况不能写成“遇到特殊情况就跳过”，而要拆成可判断的条件、可观察的信号和明确动作。缺少完整数据或权限时，最小动作是先把例外写成“触发条件—判断依据—执行动作—记录字段”四段式，再让脚本按记录字段决定是否继续。
矛盾现象：脚本越像人工，例外越多
把人工经验写成脚本需求时，常出现一种矛盾：流程越贴近人工判断，例外分支越多；可脚本一旦分支过多，又很难验证是否真的按预期运行。表面看是“规则没写全”，实际往往是把两种不同的东西混在了一起：判断依据和执行动作。
人工操作时，判断依据常留在人脑里，比如“这条看起来像模板页”“这个链接像是导航”。写进脚本需求时，如果只写动作“跳过模板页”，脚本没有可执行的判断依据，只能靠额外猜测补规则，例外自然膨胀。
两种解释：判断依据缺失，还是动作边界不清
第一种解释是判断依据缺失。人工经验里隐含了观察维度，比如页面标题重复程度、正文段落数量、链接集中位置，但需求里没有把这些维度写成可读取字段，脚本无法区分正常页面与例外页面。
第二种解释是动作边界不清。判断依据写对了，但例外发生后该做什么没有定义：是整条记录丢弃、标记后继续，还是暂停并转人工。动作边界不清时，脚本只能选择最保守的做法，结果把本可继续处理的对象也拦下。
两种解释会导致不同现象。判断依据缺失时，例外数量通常随样本变化而波动，同一批对象换一个时间处理，结果可能不同。动作边界不清时，例外数量可能稳定，但处理结果集中落在“未处理”或“待确认”，后续步骤拿不到可用输入。
能区分解释的证据：看例外记录里有没有可复现字段
要区分这两种解释，不需要完整日志权限，可以先看例外记录里是否存在可复现字段。假设一个脚本需求要处理一批页面，人工经验是“正文太短的页面先不处理”。如果例外记录只写“页面不合格”，无法复现；如果记录里包含正文段落数、标题长度、是否含特定结构标记，就能复现判断过程。
可执行的最小动作是：让脚本在触发例外时，至少记录触发条件、读取到的值、采取的动作、下一步状态四个字段。这个动作不依赖完整数据仓库，也不要求额外权限，只需要在现有输出里增加几列。
记录之后，下一步取决于字段表现：
- 如果同一触发条件下，读取到的值分布很散，说明判断依据还没写清，应先补可读取的观察维度。
- 如果读取到的值集中，但动作栏大量出现“跳过”，说明动作边界过严，应检查例外是否真的需要中断。
- 如果读取到的值集中，动作栏却混用“跳过”和“继续”，说明需求里对例外的定义不一致，应先统一动作词。
这些现象只能说明需求描述与执行记录之间的差异，不能单独证明脚本逻辑正确或错误，也不能推出某个改动一定带来效果。缺少完整数据时，先让例外可复现，比先争论规则对错更有用。
短例子：假设的例外描述改写
假设人工经验是“列表页里夹杂的详情链接不要跟”。原始需求写成“遇到列表页就跳过”，脚本无法判断什么是列表页。
改成四段式后可以写成：触发条件是“同一路径下出现多个相似链接”；判断依据是“链接文本重复次数超过设定阈值，且目标路径层级相同”；执行动作是“标记为列表型链接，不进入下一步”；记录字段是“重复次数、路径层级、标记结果”。这里的阈值和层级只是假设示例，用来比较不同描述方式，不是真实项目结论。
这个改写的实际动作是：先不扩大脚本处理范围，只把例外记录补全。结果会影响下一步——如果记录显示大量对象都触发同一条件，说明人工经验里的“例外”可能其实是常见情况，应回到需求阶段重新划分正常与例外；如果触发很少且动作一致，才适合继续讨论是否自动处理。
缺少数据和权限时，不能推出什么
缺少完整数据或权限时，仍可执行的最小动作是补记录字段、统一动作词、保留可复现的判断依据。但不能由此推出：例外数量归零就代表规则正确，处理量上升就代表经验已完整迁移，或某次改动前后差异一定来自脚本本身。
一次改动前后比较还要考虑季节、搜索需求变化和数据采集差异。请求量、抓取量或某项统计归零，也可能是采集中断、权限变化、任务未运行或对象本身减少，不能单独作为处理正确的证据。把例外写成可判断、可记录、可回退的需求，才是人工经验进入脚本时更稳的起点。
