公开网页数据采集清单：先冻结 Schema，再开始提取

1. 用样例行冻结 Schema

字段名并不能完整定义一个字段。“价格”需要说明币种、税费、促销价与区间价如何处理；“公司名称”需要说明使用品牌名、法人名还是页面展示名；“发布日期”需要说明时区和无法识别时的表达。

最有效的做法是先用 3 至 5 个真实页面填写样例行。样例会暴露字段歧义、页面变体与转换成本。只有样例被确认后，才进入批量采集。

2. 明确公开来源与访问边界

“网上能看到”不等于“任何方式都可以采集”。任务应限定公开可访问页面、允许的域名、页面类型、访问频率与排除项，并遵守适用条款、技术限制与法律要求。需要登录、付费墙、个人账户或绕过访问控制的内容，不应默认进入公开网页任务。

站点的 robots.txt 是自动抓取的重要机器可读规则，但它不是访问授权，也不替代网站条款或适用法律判断。遇到边界不清楚的来源，应停在待确认状态。

• 列出允许域名和明确排除的域名或路径。
• 区分普通公开页面、公开 API、下载文件和搜索结果页。
• 设定请求速率、失败重试和停止条件。
• 排除个人隐私、高敏信息和需要绕过控制的内容。

3. 让每一行回到来源

数据集只有在错误可定位时才可维护。至少为每行保留 source_url 与 accessed_at；如果一行来自多个页面，还应说明各来源对应的字段。页面中的原始值与清洗后的标准值最好同时保留。

对于会频繁变化的数据，访问时间应精确到任务需要的粒度。对于下载文件，还应保留文件名、版本或校验信息。这样在页面更新后，团队仍能判断差异来自真实变化还是采集规则变化。

4. 把质量回执作为数据集的一部分

一份“成功导出”的 CSV 不能说明覆盖率。交付回执应统计请求记录数、成功记录数、重复记录、缺失字段、冲突值、无法访问页面和人工复核项。每个数字都应能对应到具体行或异常清单。

重复项不一定应被删除。先定义唯一键，再决定合并、保留还是标记。冲突值也不应由执行者随意挑选；应保留冲突来源，并根据冻结的优先级规则处理。

• 请求量、成功量与实际覆盖率。
• 按字段统计缺失率，而不只统计空白行。
• 重复判断所使用的唯一键与合并规则。
• 冲突来源、选值规则与未解决数量。
• 访问失败、页面变体和需要人工确认的记录。

5. 用可计算规则验收

“数据看起来不错”无法成为验收规则。更好的合同会写出必填字段、允许缺失率、唯一性规则、格式规则、来源覆盖率和抽查数量。对高价值字段，可以要求 100% 来源可追踪；对长尾字段，则可以接受明确上限内的缺失。

验收还应包含结构层检查：文件能否打开、编码是否正确、列名是否匹配、数据类型是否稳定，以及是否附带异常回执。只有结构、内容和证据一起通过，数据才算可交付。

6. 开始采集前的 10 项清单

把下面十项放进任务合同，可以显著减少返工与争议。

• 目标数据将用于什么决定或后续流程？
• 允许来源、排除来源与访问边界是什么？
• 字段定义、数据类型与允许格式是否完整？
• 真实页面样例行是否已确认？
• 缺失、冲突、重复和无法访问如何表达？
• 唯一键与去重规则是什么？
• 原始值与标准化值是否都要保留？
• 每行需要哪些来源与时间信息？
• 覆盖率、缺失率与抽查规则是多少？
• 什么情况需要暂停并请求重新确认？