📍 WDQWDWQD987AAAAA:136.243.57.164
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /5a9c9c7c6b54.html
📄

SEO操作步骤：把人工经验写成脚本需求时怎样描述例外情况

例外情况要写成“触发条件 + 期望动作 + 判断依据”，而不是写“特殊情况特殊处理”。如果只写一句模糊的例外描述，开发、审核和内容执行三方会各自按自己的理解补全，最终脚本对同一页面给出不同结论。更稳妥的做法是：先列出人工操作时实际会停下来判断的信号，再把每个信号转成可核对的字段和动作。

矛盾现象：同一页面，三个人给出三种处理

假设一个页面人工检查时发现正文主体偏短，但页面还包含一段参数说明。内容编辑认为参数说明属于正文，应该计入有效内容；开发认为这段是结构化数据，不应计入；审核认为页面类型不同，判断标准本来就该不同。三人都说“按人工经验处理”，但脚本只能执行一种逻辑。

此时不要急着投票决定谁对，而要先把分歧转成可核对的描述。可以要求每人写出：看到什么信号时停下来、停下来之后做什么、什么情况下不做这个动作。这三项写不齐，说明例外还没有被定义清楚。

两种解释：是信号定义不清，还是动作边界不清

第一种解释是信号定义不清。三人对“正文主体”的字段范围理解不同，导致看到同一页面却提取出不同长度。第二种解释是动作边界不清。大家对“偏短”这个信号没有争议，但对偏短之后该补内容、该跳过，还是该转人工，没有统一约定。

这两种解释的修复方向不同。信号定义不清，要先统一字段和提取范围；动作边界不清，要先统一动作清单和升级路径。如果混在一起改，脚本会同时变动输入和输出，后面很难判断是哪一处导致结果变化。

用一组证据区分：让分歧落在可核对的字段上

可以做一个假设的比较：取同一批页面，让三人分别标注“是否计入正文”“是否触发例外”“例外后动作”。如果三人在“是否计入正文”上分歧最大，说明问题在信号定义；如果三人在“是否触发例外”上接近，但“例外后动作”差异明显，说明问题在动作边界。

这个比较只用于定位分歧来源，不代表改动一定带来某种效果。样本选择、页面类型分布和标注时间不同，都会影响结果。因此要记录标注时的假设条件，例如页面类型范围、字段提取规则和判断阈值，避免把一次标注差异当成长期结论。

把例外写进脚本需求的具体动作

可以直接采用下面的写法，把人工经验拆成脚本能读懂的条目：

1. 触发条件：写明字段、比较方式和阈值，例如“正文有效字符数低于该页面类型的中位区间下沿”。
2. 期望动作：写明脚本下一步做什么，例如“不直接补写，先输出待人工确认标记”。
3. 判断依据：写明依据来自哪个字段或哪份规则，例如“依据页面类型字段和正文提取范围说明”。
4. 例外再例外：写明当判断依据本身缺失时怎么办，例如“页面类型缺失时，转人工，不自动套用默认类型”。

写完这四项后，让开发复述一遍，再让内容执行复述一遍。如果两人复述出的动作不一致，说明需求里还有隐含假设没有写出来。这个复述动作的结果会直接影响下一步：能复述一致，才进入脚本实现；复述不一致，先回到字段和动作定义。

落地时要注意的比较条件

脚本上线后，如果要比较改动前后的差异，要考虑搜索需求变化、页面类型分布差异和数据采集口径差异。一次改动前后的数量变化，不能单独证明例外规则处理正确。更可靠的做法是保留人工复核样本，检查脚本输出与人工判断在哪些条目上仍然分叉，再决定是调整触发条件还是调整动作边界。

例外描述的目标不是消灭所有分歧，而是让分歧出现在可核对的字段和动作上。只要每个例外都能回答“什么信号触发、触发后做什么、依据是什么”，脚本需求就从个人经验变成了可以交接、可以复核的项目描述。