采集规则编写搜索需求太分散时先做聚合页还是详情页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f3ad86d3e08e.html
📄
采集规则编写搜索需求太分散时先做聚合页还是详情页
先做详情页，除非你已经能稳定写出聚合页的筛选逻辑和更新机制。需求分散时，详情页承担的是“单条内容可被理解、可被引用”的任务，聚合页承担的是“多个相近需求能否被一个入口承接”的任务。两者不是先后顺序问题，而是判断你当前缺的是内容颗粒度，还是入口收敛能力。
先判断分散的是词，还是内容本身
搜索需求分散通常有两种来源。一种是同一件事被用户用不同说法表达，例如同一条采集规则被写成“列表页提取”“详情页字段抓取”“翻页规则配置”。这类分散适合用聚合页收口，因为底层内容相同，只是入口没有合并。另一种是每条需求对应不同的页面结构、字段组合或失败处理方式，例如有的站点要处理登录态，有的要处理异步加载，有的要处理编码转换。这类分散不适合硬聚，详情页更稳妥。
可以用一个低成本动作验证：从现有需求里挑十条，逐条写出它真正要解决的页面对象和字段目标。如果十条里有六条以上指向同一类页面对象，只差表述不同，聚合页成立的前提就比较充分。如果十条里超过一半的页面对象不同，先做详情页，把每类对象的规则写清楚，再考虑要不要聚合。
详情页优先时，采集规则编写要落到可复用的字段层
详情页不是只写一篇介绍。它需要把一条规则的输入、提取、清洗、输出讲清楚，让读者能照着改。具体可以按这个顺序落笔：
- 说明这条规则针对的页面类型，以及它不适用于哪些页面。
- 给出字段清单，区分必须提取和可选提取。
- 说明翻页或分页的处理条件，以及停止条件。
- 说明失败时的表现，例如字段为空、编码异常、重复内容。
- 给出一个最小示例，用假设数据演示字段如何对应。
这里的关键动作是把“必须字段”和“可选字段”分开写。如果读者按你的规则跑一遍，发现必须字段能稳定拿到，可选字段按页面差异取舍，这条详情页就完成了它的任务。下一步是否做聚合页，取决于这些详情页之间是否出现了稳定的共同字段和共同筛选条件。
聚合页成立的前提：有稳定的筛选维度和更新来源
聚合页不是把详情页链接堆在一起。它要回答的是：用户带着一个较宽的需求进来，能否通过一个入口找到最接近的几条规则。成立条件至少包括：
- 有一组可枚举的筛选维度，例如页面类型、字段类型、是否需要登录、是否处理异步加载。
- 每个维度下的条目有明确归属，不会同一条规则在两个分类里互相矛盾。
- 有更新来源，新增详情页后能判断它应该进入哪个分类。
- 聚合页本身有独立的说明文字，而不是只有链接列表。
假设你有二十条采集规则详情页，其中十二条都涉及列表页翻页，但翻页方式分为三类。此时可以先做一个按翻页方式分类的聚合页，把十二条规则归入三类，并在每类下说明适用条件。这个动作的结果是：用户不必逐条翻详情页，就能判断自己该看哪一类。如果分类后仍然有大量规则无法归类，说明聚合页的维度还没稳定，应该退回详情页继续补充字段说明。
保留、改写还是退出：三种取舍的适用条件
保留详情页并继续补充适用于需求分散但每类都有真实页面对象的情况。此时聚合页会掩盖差异，反而让读者误以为一套规则能通用。判断依据是：你能否为每条详情页写出不同的适用前提。如果能，保留详情页更合理。
改写为聚合页适用于多条详情页共享同一组字段和同一套处理逻辑，只是标题或入口不同。此时把重复内容合并，保留差异说明，可以减少维护成本。前提是你已经能列出稳定的筛选维度，而不是凭感觉合并。
退出某一类需求适用于你既写不出通用规则，也无法为每条需求提供独立可用的说明。退出不是放弃，而是把有限精力放到能写清楚的那几类上。退出后，原来指向这类需求的入口应改为说明适用范围，避免用户按错误预期使用。
用一次小规模验证决定下一步
不要一次性重做所有页面。先选五条详情页，按字段层补全说明，再观察它们之间是否出现两个以上共同筛选维度。如果出现，就为这两个维度写一个聚合页草稿，只放这五条，并写清分类理由。如果没有出现，就继续补详情页，不急着建聚合入口。
这个动作的结果会直接影响下一步：聚合页草稿能自然容纳五条规则，说明可以逐步扩展；如果草稿里出现大量“其他”或“待定”，说明详情页的字段边界还没写清，应先回到详情页把字段和适用条件补完。抓取、索引和排名是不同环节，页面结构清楚不等于一定被收录，但结构混乱会让后续判断失去依据。把这一步做扎实，比先争聚合还是先做详情更有用。
