采集规则编写：新站首轮工作如何安排
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e02946fd7d3f.html
📄
采集规则编写：新站首轮工作如何安排
新站首轮不必急着铺量，先把采集规则编写当成一次小规模试验：准备一份字段清单，选一个内容类型写出最小规则，跑通后逐项验证，再决定是继续扩量还是先修规则。对多数新站，最关键的一步是先用少量样本验证规则，再批量执行，因为规则一旦写错，批量产出的内容很难逐条修正。
准备阶段：先确定要采什么，而不是先写规则
采集规则编写的第一步是列出字段，而不是打开工具。字段至少包括标题、正文、发布时间、来源链接、分类和标签。字段决定规则结构：标题和正文通常是必填，发布时间和来源链接用于后续核对，分类和标签影响内容归档。
同时要确定内容边界：只采某个栏目，还是按关键词跨栏目采；只采列表页，还是需要进入详情页。边界越清楚，规则越短，出错越少。
两种首轮方案：先小样验证，还是先全量执行
新站常见两种安排，适用条件不同：
- 小样验证方案：先采10到30条样本，逐条比对原文与采集结果。适合栏目结构复杂、正文含分页、图片较多或需要清洗格式的站点。判断结果是规则稳定后再扩量。
- 全量执行方案：规则结构简单、字段少、页面模板统一时，可以直接跑完整栏目，再抽查结果。适合列表结构固定、正文无分页的情况。
对新站更稳妥的是第一种。原因不是速度，而是纠错成本：规则错误在小样阶段只需改几行，在批量阶段可能涉及成百上千条内容。
实施阶段：把规则写成可检查的步骤
规则一般按“列表页提取链接 → 进入详情页提取字段 → 清洗与拼接”三段组织。列表页部分要处理相对链接和分页；详情页部分要处理正文容器、去除广告和无关模块；清洗部分要统一空格、换行和标点。
实施时建议把规则拆成可单独测试的片段。例如正文提取先只取第一段，确认选择器命中后，再扩展到全文。分页内容要明确是拼接为一条，还是拆成多条分别发布，这会影响后续的收录与阅读体验。
验证阶段：用检查项判断规则是否可用
验证不是看采到了多少条，而是看采到的内容能不能直接用。可以按以下检查项逐条核对：
- 标题是否完整，有无混入栏目名或导航文字。
- 正文是否缺段，尤其是分页后的第二页、第三页内容。
- 发布时间是否与原文一致，缺失时是否有统一处理方式。
- 来源链接是否可回溯，能否对应到原始页面。
- 正文中是否残留广告、推荐阅读、版权声明等无关模块。
抽查比例建议不低于样本的20%。发现同一类错误重复出现，说明规则需要修改，而不是靠人工逐条修补。
维护阶段：规则会失效，需要定期回查
目标站点的页面结构可能调整，规则不会一直有效。维护动作包括：定期回查采集结果、记录规则修改时间、保留一份字段对照说明。当出现正文突然变短、标题带出多余文字、分页内容丢失时，优先检查页面结构是否变化，再决定改规则还是停用该来源。
需要区分的是：采集规则编写解决的是“把内容取回来”，而抓取、索引、排名是后续不同环节。取回内容不等于会被搜索引擎收录，也不等于会有排名，这部分要单独评估。
下一步可以直接做一件事：选一个栏目，按上面的字段清单写一份最小规则，只采10条，逐条对照原文检查。确认无误后，再决定是否扩到全量。
