百度SEO技巧：把人工经验写成脚本需求时怎样描述例外情况，先区分三种例外来源，再决定写不写进脚本
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c0a10b7540c5.html
📄
百度SEO技巧：把人工经验写成脚本需求时怎样描述例外情况，先区分三种例外来源，再决定写不写进脚本
直接回答：不要试图在需求里穷举所有例外，而是把例外分成三类写清楚——触发条件、期望动作、无法判断时的默认行为。人工经验里最容易被省略的恰恰是第三类：执行人凭直觉处理了模糊情况，脚本没有直觉，只能靠你显式声明。写需求时先问执行人“上次遇到不符合规则的情况，你实际做了什么”，把回答转成可核对的条目，再决定这条经验是保留、改写还是退出脚本。
先区分三种例外来源，再决定写不写进脚本
人工经验中的例外通常来自三个地方，处理方式完全不同。
- 规则本身的边界：比如标题长度超过阈值时人工会截断，这属于可写成条件的例外，适合保留。
- 数据质量导致的意外：比如抓取到的字段为空、编码异常，人工会跳过或手动补，这类例外要写成“检测到即标记待复核”，而不是让脚本猜。
- 执行人的主观判断：比如“这条内容看起来像旧闻就不动”，这种判断依赖上下文，写成脚本条件后往往误伤，适合退出脚本、保留人工环节。
判断依据很简单：把同一个例外描述给两个不同角色听，如果他们对“该不该处理”给出不同答案，说明这条例外还没有被定义清楚，此时写进脚本只会把分歧固化进代码。
保留、改写、退出：三种取舍的适用前提
面对一条人工例外，先判断它属于哪种处理方式，再动笔写需求。
保留：例外条件明确且动作唯一
适用前提是触发条件和动作都能用一句话说清，且不同角色理解一致。例如“当页面正文少于 200 字时，不进入后续处理，只记录到待办列表”。这类例外直接写成判断分支，脚本执行结果可核对。
改写：例外背后其实是分类问题
适用前提是人工处理时其实在做归类，只是没说出来。例如执行人说“有些页面要特殊处理”，追问后发现是“栏目页和内容页处理方式不同”。这时不该写成一个模糊的例外，而应改写为按页面类型分流的两条规则。改写后需求条目变多，但每条都可验证。
退出：例外依赖上下文或频繁变化
适用前提是例外出现的频率高、判断依据随内容变化，且误判代价大。例如判断某段文字是否涉及敏感表述，人工会结合整篇语境，脚本只能做关键词匹配，误判后需要返工。这类例外应退出脚本，改为脚本输出候选、人工确认。
一个动作及其影响：把上述三类分别标注后，让执行人逐条确认“这条我上次是不是这么做的”。如果执行人对某条回答“不一定”，说明该条应归入退出类，而不是继续留在脚本需求里。这一步直接决定后续开发范围，避免脚本上线后频繁改条件。
把分歧转成可核对项目的写法
多个角色对同一事实有不同理解时，需求文档里不要写“按实际情况处理”这类表述。改成可核对的格式：
- 列出触发条件，用可观测的字段或状态描述，不用“异常”“不合适”这类词。
- 写明期望动作，包括动作完成后留下什么记录。
- 写明无法判断时的默认行为，默认行为应是保守的，比如标记待复核而非自动删除。
假设一个场景：三人对“内容过时”理解不同，一人指发布时间超过两年，一人指正文提到的活动已结束，一人指页面无访问。写成脚本需求时，应把三种理解拆成三个独立条件，分别对应不同动作，而不是合成一个“过时”判断。这样即使后续只保留其中一个条件，其余两个的讨论记录仍然可查。
技术示例中，条件分支可以写成类似 if 字段为空 then 标记待复核 的伪代码，但需求文档里更重要的是说明这个分支由谁复核、复核结果如何回流。缺少回流路径的例外处理，等于把问题从人工搬到了脚本日志里。
验证例外描述是否完整的检查动作
写完需求后，用一次小范围核对代替通读。具体做法：挑出需求中所有带“如果”“当”“除非”的句子，逐条问执行人“这条你上次实际遇到过吗，当时怎么做的”。回答与需求描述不一致的条目，按前述三类重新归类。
核对结果会直接影响下一步：一致率高的条目可以进入开发；存在分歧的条目先补充触发条件的可观测定义；依赖主观判断的条目从脚本范围移出，改为人工环节。需要注意，一次核对前后比较不能只看条目数量变化，还要考虑业务本身在这段时间是否有调整，否则容易把正常波动误判为描述改进的效果。
最后，例外描述不需要追求一次写全。可以先覆盖高频且判断明确的例外，低频或模糊的例外保留人工处理，等实际运行中积累出稳定的判断依据，再决定是否补进脚本。这样脚本需求始终对应真实可核对的场景，而不是一份谁都没法验证的规则清单。
