SEO聚类方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9b0197dea16b.html
📄
SEO聚类方法：把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要只写“遇到例外时人工判断”，而要写成“先识别例外类型，再决定脚本是跳过、标记还是按另一套规则处理”，并给每种例外配一个可核对的判断依据。这样脚本需求才能被开发者和审核者用同一套事实验收，而不是靠谁记得更清楚。
假设情境：三个人对“同主题页面”理解不同
假设一个团队要做页面聚类脚本，输入是已有页面清单，输出是每个页面归属的主题簇。写需求的人说“同主题就归一组”，开发者理解成标题相似度，审核者理解成搜索意图一致，内容编辑理解成正文讲的是同一件事。三个人都没错，但脚本只能执行一种判断。分歧点不在“聚类方法”本身，而在例外情况没有被写成可核对的条件。
把人工经验转成脚本需求时，例外的描述至少要落到三个字段：触发条件、处理动作、核对证据。触发条件说明什么情况下算例外；处理动作说明脚本接下来做什么；核对证据说明人怎么确认脚本做对了。缺任何一个字段，例外都会退回成“看情况”。
例外要按“可判断的顺序”写，而不是按重要性写
人工做聚类时，往往先看整体感觉，再回头处理个别页面。脚本不能这样，它需要一条从明确到模糊的判断链。建议把例外排成这样的顺序：
- 硬冲突：同一页面同时命中两个主题簇的核心条件，且两个条件互斥。此时脚本应标记为待定，不自动归类。
- 弱信号：页面只命中一个簇的边缘条件，没有命中核心条件。此时脚本可归入该簇，但输出置信标记。
- 缺数据：页面缺少标题、正文或内链等判断所需字段。此时脚本跳过，并记录缺失字段名。
- 人工已处理：页面此前被人工移出某簇。此时脚本尊重人工结果，除非硬冲突再次出现。
这个顺序的意义在于：不同角色对“例外”的理解不同，但一旦排成顺序，分歧就变成“这条规则该排第几”，而不是“要不要处理”。排序本身可以讨论，排序后的执行结果可以核对。
把分歧转成可核对项目的动作
一个实际动作是：为每个例外类型写一条可复现的最小例子。例如硬冲突可以写成“页面 A 的标题同时包含主题 X 和主题 Y 的核心词，且正文对两个主题的篇幅接近”。这个例子不需要真实数据，只需要让三个人分别判断它该归哪一簇。如果三个人给出不同答案，说明触发条件还太模糊，需要继续拆分；如果三个人答案一致，这条例外就可以进入脚本需求。
这个动作的结果会直接影响下一步：例子能对齐，就继续写处理动作；例子对不齐，就先回到触发条件，而不是先写代码。很多脚本需求失败，不是因为逻辑错，而是因为例外例子本身没有对齐，开发者和审核者在验收时用的是两套事实。
处理动作要区分“跳过、标记、另走规则”
例外情况最常见的错误描述是“人工确认”。人工确认不是处理动作，它只是把问题推迟。脚本需求里应明确三选一：
- 跳过：不归类，输出空值，并记录跳过原因。适合缺数据或硬冲突。
- 标记：先按默认规则归类，但附加待复核标记。适合弱信号。
- 另走规则：不按主规则处理，改走一条独立分支。适合人工已处理或业务上有特殊约定的页面。
选择哪一种，取决于例外被发现的时机和后续由谁处理。如果例外会在脚本运行后立即进入人工队列，标记比跳过更省事；如果例外会导致错误归类扩散到下游，跳过更安全。这个取舍不需要统一答案，但需要在需求里写明，否则开发者会默认选最省事的那种。
核对证据要能回答“为什么这个页面在这里”
脚本输出聚类结果后，审核者需要能回答：某个页面为什么被归入这一簇，或者为什么被跳过。核对证据不需要复杂，但必须包含触发例外的字段名和值。例如“标题命中主题 X 核心词，正文命中主题 Y 核心词，两主题篇幅比例接近，判定为硬冲突”。
如果核对证据只写“脚本判断”，审核者无法区分是规则生效还是数据异常。一次改动前后比较时，还要注意季节、搜索需求变化和数据采集差异：同一批页面在不同时间抓取，缺失字段的比例可能不同，跳过数量随之变化。跳过数量归零不能单独证明规则正确，也可能是采集更完整或阈值被放宽。把核对证据和采集条件一起记录，下一步调整阈值时才有依据。
回到假设情境：三个人最终不需要对“同主题”达成哲学共识，只需要对“硬冲突的最小例子”达成一致。例外描述清楚后，脚本需求就从一份经验说明变成一份可验收的规则清单，分歧也从理解差异转成了规则排序和阈值选择。
