数据类 Skill 系列走到第六篇。前几篇从清洗写到分析再写到挖掘但所有人都默认了一件事数据已经在了。现实中根本不是——数据采集才是这条流水线的源头也是失败率最高、最需要工程化的一环。网站改版、接口限流、反爬升级、字段变更任何一个波动都会让整条下游流水线断粮。这篇讲透数据采集 Skill 怎么设计它的边界、它的三大技术命门以及它和下游清洗 Skill 之间那条不能越过的线。一、先定位数据采集在流水线的位置把整个数据流水线画出来采集在最上游数据采集 → 数据清洗 → 数据分析 / 数据挖掘 → 报告 / 决策 ▲ └─ 采集的产出是原始数据不是干净数据采集 Skill 的第一设计原则它只负责把数据拿到手不负责把数据变干净。轻量处理去 HTML 标签、转编码可以做但深度清洗去重、口径统一、异常处理必须留给清洗 Skill。为什么因为采集和清洗的关注点完全不同——采集关注能不能拿到、全不全清洗关注干不干净、对不对。两者耦合改一处动全身。二、数据采集的四种形态先分清要采什么因为不同形态的 Skill 设计差异巨大形态数据来源特点典型工具网页抓取静态/动态网页结构易变、有反爬请求库 解析库API 调用官方/第三方接口稳定但有配额、需鉴权HTTP 客户端数据库同步业务库 / 数仓稳定但权限敏感连接器、ETL文件导入CSV、Excel、日志最简单读取库设计建议一个采集 Skill 聚焦一种来源。万能采集器在现实中不存在——网页采集和 API 采集的失败模式、重试策略、合规要求完全不同。先做最痛的那一种。三、定义输入输出契约采集 Skill 的边界定义重点在采什么、采到什么样算完成输入 - 目标定义URL 列表 / 接口参数 / 数据表范围 - 采集配置频率、字段清单、页数限制、时间范围 输出 - 原始数据文件统一格式含采集时间戳 - 采集日志成功/失败/重试记录缺失清单 - 数据完整性报告应采 X 条实采 Y 条缺 Z 条 边界 - 只做采集与轻量提取不深度清洗 - 遵守目标方的 robots、授权与频率要求 - 不采集个人敏感信息除非有明确合法依据注意输出里的缺失清单——这是采集 Skill 和手工爬虫最大的区别。手工爬虫抓到多少算多少采集 Skill 必须知道自己缺了多少、缺在哪。下游清洗和分析才能判断这批数据的可信度。四、核心流程采集不是发请求是一套工程步骤 1目标解析规则 → 解析 URL 列表 / 接口定义生成任务队列 步骤 2调度与限流规则关键 → 控制请求频率QPS 上限、并发数、时间窗口 步骤 3请求与重试规则关键 → 发送请求失败按指数退避重试如 3 次2s/4s/8s → 区分可重试错误超时、5xx与不可重试错误404、鉴权失败 步骤 4解析与轻量提取规则 → 从响应中提取目标字段HTML 用选择器JSON 用路径 → 只做格式转换不做语义清洗 步骤 5完整性核对规则 → 对照任务队列核对实采数量生成缺失清单 步骤 6存储与日志规则 → 写入统一格式CSV/JSON/数据库附带采集时间戳这个流程的精华在步骤 2 和 3采集 Skill 的工程质量不在能抓到而在被抓挂之后能自己恢复。重试策略、限流策略、断点续采才是它和一次性爬虫脚本的分水岭。五、三大技术命门1. 稳定性断点续采是底线采集是个长任务跑到第 3000 条断了不能从头再来。Skill 必须内置- 任务队列持久化已完成的记录标记进程重启后从断点继续 - 增量采集记录上次采集位置下次只采新增 - 失败重试可重试错误自动重试不可重试错误入待人工清单设计原则任何一次采集都要可中断、可恢复、可续采。这是采集 Skill 与手工脚本最本质的工程化差距。2. 健壮性目标会变Skill 不能一碰就碎网站改版是常态字段名说改就改。Skill 要- 解析规则与代码分离选择器/字段映射做成配置改版时只改配置 - 结构变化检测解析结果为空/异常时先怀疑结构变了而不是没数据 - 异常采样存档解析失败的响应体存下来供排查设计原则把解析规则当作需要维护的配置资产而不是写在代码里的死字符串。否则每次网站改版你的 Skill 都要重写。3. 合规性采集的底线不能碰这部分没有灰色地带必须写进 Skill 的硬约束合规清单硬性检查不满足即拒绝执行 □ 目标是否有公开 API有则优先用 API而非抓网页 □ robots.txt 是否允许不允许的目标不进任务队列 □ 请求频率是否合理模拟真实用户节奏禁止高频轰炸 □ 是否涉及个人信息涉及则需要合法依据否则不采 □ 是否受版权/授权保护未授权的内容不进采集范围为什么写进 Skill 而不是靠人自觉因为采集是自动化的——一条代码跑 10 万次每次都在替你做决定。把合规做成执行前的硬检查不通过直接拒绝运行而不是写进注释让人记住。六、和下游清洗 Skill 的衔接线这是数据流水线协作的关键设计——采集 Skill 的产出就是清洗 Skill 的输入两者之间的契约必须固定采集输出 → 清洗输入的约定 - 格式统一为表格文件 字段说明 - 每条记录带采集时间戳清洗时可用于去重 - 缺失清单随数据一起传递清洗可据此决定缺失策略 - 轻量处理只到可读取深度清洗全部留给清洗 Skill一条铁律采集 Skill 不做任何有损处理。不去重、不删字段、不合并——宁可把原始数据多给下游也不能在自己这层丢信息。因为采集层的任何自作聪明都会变成下游无法追查的数据损失。七、一个采集 Skill 骨架defrun_collection(targets,config):queuebuild_task_queue(targets,config)# 1. 目标解析results,missing[],[]fortaskinqueue:ifnotcheck_rate_limit(config):# 2. 限流wait(config[interval])resprequest_with_retry(task,config)# 3. 请求重试ifrespisNone:missing.append(task);continuerecordextract_fields(resp,config)# 4. 解析配置驱动ifis_empty(record)andsuspicious(resp):# 结构变化检测archive_raw_response(resp)# 存档待排查results.append(record)mark_done(task)# 断点持久化integritybuild_integrity_report(len(results),len(missing))save(results,config[output_path])save_log(integrity)returnconfig[output_path],integrity骨架里内置了三个采集 Skill 必备件限流、重试、断点记录——缺任何一个它都退化成一次性爬虫脚本。八、最容易踩的坑采集和清洗耦合采集时顺手做深度清洗下游改不动、源头丢数据。没有断点续采跑一半挂了全部重来长任务永远跑不完。重试策略一刀切把 404 和超时同等对待无效重试浪费配额。解析规则写死在代码里网站一改版整个 Skill 瘫痪。不核对完整性采了 80% 就当成功交付下游全然不知缺了 20%。无视合规高频抓取、绕过授权——不只是道德问题是法律风险。不存原始响应解析出错时没有存档排查只能靠猜。频率设置过激进短时间大量请求被限流封禁反而拿不到数据。九、一句话总结数据采集 Skill 的本质是把抓数据从一次性的手艺活变成可中断、可恢复、可续采、合规且自知缺漏的工程。它的成败不取决于能不能抓到第一条数据而取决于第 10000 条数据抓完时你是否知道自己抓全了没有、缺了什么、还守住了底线。至此这个系列已经完整覆盖了数据流水线的三环采集拿到→ 清洗变净→ 分析/挖掘用起来。每篇都在讲同一件事把隐性经验固化成可复现、可追溯、有验收标准的能力——这正是 Skill 的本质。