网站SEO技巧，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /17818e473c76.html
📄
网站SEO技巧，把人工经验写成脚本需求时怎样描述例外情况
把人工经验写成脚本需求时，例外情况不能写成“遇到异常就跳过”。更可执行的做法是：为每个例外规定判定信号、处理动作和留痕字段，并允许脚本在无法判定时把任务退回人工。否则脚本会把本该保留的页面改坏，或者把该处理的页面静默漏掉。
先拿一个页面当样本，把经验拆成“常规路径”和“例外出口”
假设你手里有一批页面，人工判断时习惯先看标题是否与正文主体一致，再看正文是否覆盖了用户可能追问的下一层信息。这个经验听起来简单，但写成脚本需求时，真正需要描述的是“什么情况不按常规处理”。
可以先选一个页面作为样本，按下面顺序记录：
- 常规路径：标题与正文主体一致，正文对核心问题有直接回答，脚本按既定字段抽取并生成修改建议。
- 例外出口一：标题与正文主体明显不一致，但页面仍有独立价值。脚本不应直接改标题，而应标记为“需人工确认主题归属”。
- 例外出口二：正文只是列表或参数堆叠，缺少可读的解释句。脚本不应强行扩写，而应标记为“内容形态不支持自动改写”。
- 例外出口三：页面包含时效性强的活动信息或价格信息。脚本不应套用通用模板，而应标记为“需人工核对时效字段”。
这样拆完后，脚本需求里就有了两类东西：一类是正常执行的动作，另一类是遇到特定信号时改变动作或停止动作的规则。例外情况不是错误处理附录，而是脚本能否安全运行的核心部分。
两种写法需要取舍：硬编码判定，还是保留人工复核入口
写脚本需求时，常见两种做法。第一种是把所有例外都写成硬编码规则，例如“标题长度超过某个范围就跳过”。第二种是只写判定信号，把最终决定留给人工复核。两种做法都成立，但适用条件不同。
选择硬编码规则的条件与代价
当例外信号稳定、误判代价低、页面量大到人工无法逐条查看时，硬编码更合适。例如，页面正文为空、标题缺失、正文与标题重复度过高，这些信号容易用程序判断，跳过或标记后不会造成不可逆损失。代价是规则会随时间变得不准确，需要定期抽样检查。
选择人工复核入口的条件与代价
当例外涉及主题归属、品牌表述、法律或时效信息时，人工复核更合适。脚本只负责把可疑页面筛出来，并附上判定依据。代价是处理速度受人工排期影响，脚本不能承诺当天处理完所有页面。
一个可用的折中做法是：脚本先按硬编码规则处理低风险例外，再把高风险例外写入待复核队列。待复核队列中的页面不自动发布修改，只生成建议。这样既不会让脚本完全停摆，也不会让高风险页面被静默改掉。
每个例外至少写清三件事：信号、动作、留痕
只写“遇到异常就人工处理”没有可执行性。更具体的需求应该像下面这样描述：
- 信号：脚本从页面中读取到什么字段、什么值或什么组合时，判定为例外。例如，正文中可抽取的解释性句子少于两句，且页面主体为参数列表。
- 动作：判定为例外后，脚本是跳过、生成建议、写入待复核队列，还是只记录不修改。动作必须互斥，不能同时写“跳过并修改”。
- 留痕：脚本输出中保留页面标识、判定信号、建议动作和处理状态。留痕不是给脚本看的，而是给后续人工复核和回退用的。
假设一个页面被判定为“标题与正文主体不一致”，脚本的动作是写入待复核队列，而不是直接改标题。人工复核后确认页面主题确实偏移，下一步才决定是改标题、合并内容还是保留原样。这个动作的结果会影响后续脚本规则：如果多数待复核页面最终都被保留，说明判定信号过严，应调整阈值；如果多数都被改写，说明脚本可以承担更多低风险动作。
用一个小样本验证例外规则，不要先全量跑
例外规则写完后，先在一小组页面上验证。样本应包含常规页面、已知例外页面和边界页面，而不是只挑最容易处理的页面。验证时重点看三件事：
- 本该进入例外出口的页面，是否被常规路径错误处理。
- 本该常规处理的页面，是否被例外规则大量拦截。
- 留痕字段是否足够让人工复核者在不打开原页面的情况下理解判定依据。
如果样本中大量页面被拦截，先检查信号是否过于宽泛，而不是直接放宽动作。例如，“正文少于三句”可能把短但完整的问答页也拦下来，此时应改为“正文少于三句且没有直接回答核心问题”。如果样本中例外页面被漏掉，则要补充信号组合，而不是只依赖单一字段。
验证通过后，再逐步扩大处理范围。每次扩大范围后，比较改动前后的页面表现时，要考虑季节、搜索需求变化和数据采集差异。一次改动前后数据下降，不能单独证明例外规则有错，也可能是需求本身在变化。反之，数据上升也不能单独证明规则有效。
脚本需求里最该避免的写法
以下几种写法会让例外情况在实现阶段被忽略：
- 只写“其他情况按常规处理”，没有定义什么算其他情况。
- 把例外处理写成一句“人工介入”，但没有说明介入后输出什么、由谁接收。
- 用“尽量”“适当”“必要时”描述动作，脚本无法判断何时触发。
- 把多个例外合并成一个出口，导致复核者无法区分是主题问题、时效问题还是内容形态问题。
更稳妥的做法是：每个例外出口只对应一类可区分的判定信号，并明确该出口的输出物。脚本可以自动处理低风险例外，但高风险例外必须留下可复核的记录。这样，人工经验才真正变成脚本能执行、人能接手的处理方案，而不是一段看起来完整、运行时却不断越过边界的描述。
