怎样建设网站：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a9e4493cf7e1.html
📄
怎样建设网站：把人工经验写成脚本需求时怎样描述例外情况
例外情况不能只写“有异常就跳过”，而要写清触发条件、判断依据、执行动作和留给人工的出口。更稳妥的做法是把每条例外写成可核对的四元组：什么现象、依据哪份数据判断、脚本做什么、什么情况下必须停下来交给人。这样多个角色对同一事实的理解分歧，才能转成可以逐条勾选的项目。
先看一个矛盾现象：同一句需求，三个人读出三种结果
假设团队要把“批量检查页面标题是否为空”的人工经验写成脚本需求。人工操作时，检查者看到标题标签缺失、标题只有空格、标题重复，会凭经验分别处理。写成一句“标题异常就记录”，开发、编辑和验收方很容易出现三种理解：开发认为只有标签不存在才算异常，编辑认为空白标题也算，验收方则认为重复标题也应该进报告。
矛盾不在于谁不认真，而在于“异常”这个词没有落到可观察的现象上。人工经验里大量判断是隐性的，写需求时如果不把例外拆开，脚本只能按某一种理解执行，另外两种理解就会在验收时变成争议。
两种解释：是判断标准没写全，还是处理动作没分开
第一种解释是判断标准没写全。人工经验里“标题有问题”其实包含多个条件，需求只写了其中一个，导致脚本漏判。第二种解释是处理动作没分开。判断标准写全了，但所有例外都被要求执行同一个动作，比如统一记录到同一列，结果不同严重程度的问题混在一起，验收方无法判断脚本是否按预期工作。
这两种解释对应不同的修改方向。如果是标准没写全，需要补充触发条件和判断依据；如果是动作没分开，需要把例外按处理方式分组，而不是继续往判断条件里堆描述。
能区分两种解释的证据：让每条例外都有独立编号和预期结果
把例外逐条编号，并为每条写出预期结果，再拿同一批输入分别让人工和脚本执行，对比差异出现在哪一条。如果差异集中在某条判断条件上，说明是标准没写全；如果每条判断都一致，只是记录位置或后续动作混乱，说明是处理动作没分开。
这个对比需要控制输入范围。使用同一批页面、同一时间点的数据，避免把季节变化、搜索需求波动或数据采集差异误当成脚本问题。一次改动前后的比较也要考虑这些因素，不能因为某天记录条数变化就断定判断逻辑正确或错误。
可核对的例外描述模板
每条例外至少写清四项：现象、依据、动作、人工出口。下面是一个假设例子，用来说明写法，不代表任何真实项目结果。
- 现象：标题标签不存在。
- 依据：页面源码中不存在 <title> 标签。
- 动作：记录页面地址和缺失类型，标记为待处理。
- 人工出口：同一地址连续两次出现缺失时，暂停自动处理，交给人工确认页面是否已下线。
再写第二条：
- 现象：标题标签存在，但去掉首尾空格后为空。
- 依据：标签内文本经过去空格处理后长度为 0。
- 动作：记录页面地址，与“标签不存在”分开归类。
- 人工出口：不自动填充标题，只进入人工待办。
两条例外分开后，开发和验收方可以逐条核对，不再争论“空标题算不算异常”。
把分歧转成项目：先冻结判断依据，再决定自动动作
多角色协作时，先冻结判断依据，再讨论自动动作。判断依据要指向具体数据来源，例如页面源码、抓取结果文件或人工填写的清单。依据一旦确定，就不要在执行中途更换，否则前后结果无法比较。
自动动作按风险分级：只记录、记录并标记、记录并暂停。风险越高的例外，越应该保留人工出口。比如标题缺失可以自动记录，但涉及删除页面、合并地址或替换正文的动作，不应仅凭一条例外规则自动执行。
实际动作可以这样安排：先选出十条已知的人工处理记录，按上面的模板写成例外条目，再让脚本对同一批输入输出结果。对比差异后，只修改有分歧的条目，不整体重写需求。这个动作的结果会直接决定下一步：如果差异集中在判断条件，就继续补充依据；如果差异集中在动作归类，就调整分组和人工出口，而不是继续增加判断条件。
验收时看什么：不看总条数，看每条例外的去向
总条数变化不能单独证明处理正确。记录条数归零，可能是判断条件写错导致没有触发，也可能是输入数据本身变化，还可能是采集环节漏掉了数据。合理解释不止一种，所以验收要逐条看例外的去向：每条例外是否按预期进入对应分类，是否在需要时停下来交给人工。
如果某条例外没有出现在结果里，先检查输入是否包含该现象，再检查判断依据是否与输入格式一致，最后才检查脚本逻辑。顺序反过来，容易把输入问题误判成脚本问题。
把例外写成可核对的条目，并让每条都有明确的去向，人工经验才能真正转成脚本需求。下一步不是继续补充描述，而是拿一批已知输入做对照，确认分歧发生在判断条件还是处理动作上，再决定改哪一层。
