网站规划技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /37ca1f97f084.html
📄
网站规划技巧：把人工经验写成脚本需求时怎样描述例外情况
先给一个可执行的判断：把人工经验转成脚本需求时，例外情况不能只写“遇到异常就跳过”，而要写成“识别条件—默认处理—保留人工出口”三段。缺少完整数据或权限时，最小动作是把例外分成三类：可自动处理的、必须改写规则的、必须退出脚本交回人工的。这个动作的结果会直接决定下一步：前两类可以继续写脚本，第三类必须先补权限或补数据，否则脚本上线后会把人工经验里最关键的判断悄悄抹掉。
例外描述的第一层：先区分“数据缺失”和“规则冲突”
人工操作时，很多例外靠经验顺手处理，例如某栏目没有历史数据、某页面权限不够、某字段为空。写进脚本需求时，这两类例外的处理方式完全不同。
- 数据缺失：识别条件是字段为空、返回结果为空集、接口超时。默认处理可以记为“记录并继续”，但必须写明记录到哪个位置、后续由谁补看。
- 规则冲突：识别条件是同一对象同时命中两条互斥规则，例如既满足“保留旧链接”又满足“统一替换”。默认处理不能是“继续”，而应记为“停止该对象处理，输出冲突清单”。
如果缺少完整数据，无法判断某对象属于哪一类，最小动作是先在脚本需求里加一个“待定池”：只记录对象标识和命中的规则名，不做修改。这个动作的结果是，你可以拿待定池去补数据或补权限，而不是凭猜测把两类例外合并成一条“异常跳过”。
保留、改写还是退出：三种取舍的适用前提
例外情况落到脚本需求里，通常只有三种去向。选择哪一种，取决于你能否在脚本运行前拿到判断依据。
保留：例外对象原样不动
适用前提是，例外对象的影响范围可控，且你有办法在运行后单独复查。例如批量调整页面标题格式时，某些页面标题由人工长期维护，脚本识别到标记后直接保留。动作上，需求要写成“命中标记的对象不进入修改队列，并输出保留清单”。结果是你得到一份可复查的清单，下一步可以人工确认这些页面是否需要单独处理。
改写：给例外对象套一条更窄的规则
适用前提是，例外有稳定特征，且你能描述出比主规则更窄的命中条件。例如主规则是“所有栏目页统一替换导航文案”，例外是“带活动标识的栏目页保留原文案”。需求要写成“先匹配活动标识，命中则跳过主替换；未命中则执行主替换”。这里的关键是顺序：例外判断必须放在主规则之前，否则脚本会先改再判，等于没有例外。
退出：停止脚本并交回人工
适用前提是，例外涉及权限边界、法律或品牌口径，或者你无法在脚本里安全判断。例如需要删除某类页面，但你没有删除权限，只能标记。需求要写成“命中删除条件时，不执行删除，输出待删除清单并终止该批次”。结果不是脚本失败，而是把决策点交回人工，下一步是补权限或改由人工执行。
缺少数据或权限时，最小可执行动作是什么
缺少完整数据时，不要先写“如果数据缺失就报错”，而要先写“缺失时记录什么、由谁判断”。一个可用的最小动作是：在脚本需求里加一张例外登记表，字段至少包括对象标识、命中规则、缺失项、建议去向。建议去向只填“保留”“改写”“退出”之一，不填具体修改内容。
缺少权限时，最小动作是把“读取”和“写入”分开描述。例如你可以读取页面列表但不能修改，那么需求写成“只输出拟修改清单，不执行写入”。这样做的结果是，你拿到一份可验证的清单，用来判断例外分类是否正确；但不能由此推出脚本已经可以安全执行写入。
这里有一个假设例子：某站点有 100 个栏目页，脚本需求写“标题为空则跳过”。运行后 20 个页面被跳过。这个数字本身不能证明跳过是对的，因为标题为空可能是数据未同步、字段名变更或权限不足。合理做法是把这 20 个对象放进待定池，分别检查缺失原因，再决定保留、改写还是退出。
写进需求前，用一组证据区分原因
例外情况描述得对不对，取决于你能否区分“现象相同、原因不同”的对象。可以按下面这组证据来分：
- 同一对象在两次运行中是否都命中例外。两次都命中，更可能是规则冲突；只命中一次，更可能是数据同步或超时。
- 例外对象是否集中在同一栏目、同一模板或同一权限组。集中出现，优先检查该范围的规则或权限；分散出现，优先检查字段和接口。
- 例外清单能否被人工复核。不能复核的例外，不应写成自动处理。
动作上，先把例外清单按上述三条打标，再回到脚本需求里修改对应段落。结果是你的需求从“异常跳过”变成“按原因分流”，下一步才是决定哪些分流可以自动执行。
改动前后比较时，不要把一次变化当成结论
脚本处理例外后，你可能会比较改动前后的抓取量、请求量或页面数量。这些数字归零或下降，不能单独证明例外处理正确。季节变化、搜索需求波动、数据采集差异、统计口径调整，都可能产生同样现象。若要做比较，至少保留同一口径的前后两份清单，并注明假设：假设采集方式未变、假设例外分类未变。只有在这个前提下，清单差异才值得进一步排查。
把人工经验写成脚本需求，核心不是把所有例外都消灭，而是让每个例外都有明确的识别条件、默认处理和人工出口。缺少数据和权限时，先输出清单、不执行写入，往往比强行自动化更接近可用的下一步。
