> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/14-chapter.md).

# 第14章 数据获取实战:工具选型、接入方法与实操边界

**本章导读**:AI 编程的"燃料"是数据——产品能拿到什么数据、拿到多新的数据,直接决定产品能走多远。本章系统讨论数据获取的三类来源(内置知识、联网搜索、自有数据)、主流爬虫工具的优缺点对比,以及一个被普遍忽略但构成全部技术讨论前提的实操边界——"公开可见"和"开放取用"是两件事。本章的方法论是"按交付形态选型"——把工具按"你愿不愿意维护基础设施"分类,而不是按品牌罗列,让读者建立清晰的选型框架。

**本章关键词**:数据获取、工具选型、行为边界、MCP、按交付形态分类

## 14.1 数据获取的实操前提

**现场还原**:某次行业研究工具上线后第 11 天,负责运维的工程师在工位上收到一封英文邮件——目标数据源(某行业资讯平台)法务部发来的,要求 7 日内删除已抓取的 4.7 万条数据,并保留进一步追诉的权利。工程师截图发到项目群里,客户(产品负责人)当晚拉了一个三人电话,客户的第一句话是:

> 客户:这个价格,我们知道吗?我说的是这个数据本身,他们卖不卖?我们能不能直接买?

负责人把爬虫脚本停掉,先回答客户的问题——"对方提供 API 授权,年费 1.2 万美元,比爬虫方案 18—22 天交付周期内免费抓数据的方案贵 8 倍,但合法可持续。"客户沉默了几秒,选了授权。事后复盘,客户把这次事件写成 12 页的内部复盘报告,标题就叫"看不见的边界"——他后来说:"'任何人都能打开看'和'我的程序能抓'之间,差一个我们 11 天前没看见的边界。"

**教训**:"公开可见"和"开放取用"是两条独立的判断,不能互相推导。一条经验法则——任何商业数据源,在抓取动作发生前,先查对方是否提供商业 API 授权;提供则优先走授权,授权费用通常远低于一次律师函 + 数据全删的代价。

### 14.1.1 "公开可见"和"开放取用"是两件事

数据获取讨论的起点,是一个被全行业反复验证过的判断:网站上的内容"任何人都能打开看",不等于"获得了批量抓取的授权"。

一个商品的价格页任何人都能打开看,但这不意味着你的程序能每小时抓一万次;一个社交平台的主页人人能浏览,但这不意味着你的程序能绕过验证、把内容装进自己的数据库。可见性描述的是信息的展示状态,授权描述的是行为的边界属性,二者不能互相推导。

这一原则看上去是常识,但 2026 年的爬虫环境里,违反它的产品每年都在以各种方式停摆——被平台封 IP、被服务商发函、被竞争对手举证。多数并非"技术不达标",而是规模与速度突破了对方欢迎的范围。

把这条放在最前面,是因为后续每一个工具、每一张模板、每一段成本估算,都建立在这条前提之上。一个错误的前提会让所有技术细节跑偏。

### 14.1.2 后续内容的逻辑顺序

本章剩余的篇幅,正是在这条前提下讨论:

* 14.2:三类数据源的决策框架——内置知识、联网搜索、自有数据如何分工
* 14.3:爬虫工具横评——按交付形态划分五类,各类的优缺点
* 14.4:通过 MCP 为 Agent 接入数据工具——如何让 AI 直接调用数据
* 14.5:实操边界——五条运营纪律

![三类数据源决策树](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-69069eb34eb63ce1b2362c19c993dffe89ff84f8%2Fsec14_decision_tree.svg?alt=media)

## 14.2 三类数据源的决策框架

**现场还原**:某次面向 B 端客户的行业研究产品,客户要求"每周一早 9 点,把过去一周的行业新闻摘要发到客户邮箱"。团队一开始选了最便宜的方案——AI 内置知识,零成本、零工程量。第一份摘要发给客户(20 多家公司的采购总监)后,客户群里立刻有 3 个人反馈"这个新闻是 6 个月前的"。客户(项目对接人)当场在群里回了一句:

> 客户:你给我的不是"上周",是"去年"。这个产品如果不修,我没法向上面交代。

负责人当晚把方案从内置知识换成爬虫 + 知识库,工程师用了 6 天把当日新闻的抓取 + 摘要 + 发送流程打通。第二周,客户群里的反馈从"数据滞后"变成了"这周的几条我们公司都引用了"。负责人后来在内部复盘时把这次事故总结成一句话:"客户要的是'新',不是'对'——'对'是底线,'新'才是产品价值。"

### 14.2.1 三条数据获取路径及其分工

为 AI 产品寻找数据,本质上只有三条路径,可以概括为一句话:**内置知识回答常识,联网搜索回答时事,爬虫与知识库回答"自有数据"**\[^52^]。

* **内置知识**:AI 模型本身的知识。优势:零边际成本。劣势:有截止日期、可能出错、不可追溯。
* **联网搜索**:通过 API 实时查询互联网。优势:时效性强。优势:有截止日期、可能出错、不可追溯。
* **爬虫与知识库**:主动抓取并自建数据库。优势:可复用、可审计、可定制。劣势:成本高、维护复杂。

三类数据源的分工:用内置知识处理常识(天气、地理、历史),用联网搜索处理时事(股价、新闻、最新版本),用爬虫与知识库处理自有数据(公司文档、行业资料、用户行为)。

**现场细节**:某次项目的数据源选型,作者本人参与了全过程。当时需为一款行业研究报告工具选择"行业新闻"数据源。三条路径摆在面前:用 AI 内置知识(便宜但滞后 6—12 个月)、用联网搜索(新鲜但 API 费用不可控)、用爬虫自建(可控但工程量大)。按"数据源决策四问"过了一遍:第一问"时效性",答案"是"(行业新闻需要当日);第二问"是否公开时事",答案"是";第三问"是否需要批量",答案"是"(每天 50—100 条);第四问"是否需要可复现、可审计",答案"是"(报告需要标注来源)。四个"是"指向"爬虫 + 知识库",但第二步实操后发现"每天 50—100 条"在爬虫建库后,边际成本接近零。最终选型:爬虫自建(以 Tavily + 自建脚本),每月成本约 8 美元,低于纯搜索方案的预估 60 美元/月。**三条路径的成本结构完全不同,选型不能凭"哪个最新"或"哪个最便宜",必须按"答案用完即弃 vs 数据反复使用"分**。

### 14.2.2 路线判断的四个问题

判断用哪条路径,只需回答四个问题:

* **时效性要求?** 没有——直接用内置知识。有——进入下一问。
* **数据是长尾还是公开时事?** 仅属公开时事——联网搜索。是——进入下一问。
* **需要批量获取或结构化字段?** 不需要——单次抓取工具。需要——爬虫 + 知识库。
* **需要可复现、可审计?** 需要——知识库 + RAG 检索,每条数据可回溯。

四个问题回答完,数据获取的路径就确定了。

### 14.2.3 三条路径的成本差异

三条路径的成本结构完全不同:

* **内置知识**:费用已摊入订阅,边际成本为零
* **联网搜索**:按调用次数计费,每次搜索有独立费用,且多数服务对"搜索返回的内容"还要按 Token 二次计费
* **爬虫与知识库**:一次性建设投入 + 可复用资产,长期使用边际成本接近于零

选型的关键判断:"答案用完即弃"选搜索(便宜但每次都要付费),"数据需要反复使用"选爬虫(贵但长期便宜)。

**现场细节**:某次项目,客户选了某联网搜索 API 接入产品,第一周花了 4,200 美元,远超 3,000 美元的月度预算。查账单发现,问题出在"内容也按 Token 二次计费"——单次搜索 0.01 美元,返回的 6,000 Token 内容又收了 0.018 美元,实际单次成本是 0.028 美元,接近 3 倍。客户对接人(运营)当晚在群里问:"为什么没人告诉我这个 0.018 美元?" 负责人把 API 提供方的价目表截图发过去——价目表里其实写明了,只是对方运营签合同时没看到这一行。**联网搜索的价目表要看"调用费 + 内容费"两行,只看一行会超预算 2—3 倍**。

## 14.3 爬虫工具横评:按交付形态划分五类

**现场还原**:某次项目选型会议,会议室里坐了 3 个工程师、1 个产品负责人。会议原计划 2 小时,开了 4 小时,核心议题是"五类爬虫工具里选哪一个"。3 个工程师各自推一个:工程师 A 推 Crawl4AI(因为"免费"),工程师 B 推 Bright Data(因为"功能强"),工程师 C 推 Firecrawl(因为"稳")。讨论 3 小时没有结论,负责人(产品方)问了一句:"这个产品 18—22 天要交付,我们团队有没有人能在交付前搭好 Crawl4AI 的反爬?" 工程师 A 沉默了几秒,答"能,但要先给我一周"。负责人又问:"那如果选 Firecrawl,工程师 C 一个人能搞定吗?" 工程师 C 答"能,3 天"。会议当场定 Firecrawl,后 18 天如期交付。负责人后来把这次选型总结成一句:"选型不是选最好的,是选'在交付期内能稳的'。"

### 14.3.1 形态分类的逻辑

工具对比类文章数量众多,但多数按品牌罗列,读完仍无法指导选型。本章采用的分类轴是**交付形态**,理由在于:形态决定了需要配置什么样的团队、承担什么样的风险、支付什么样的费用。同一形态内的工具可以互换,跨形态的替换才会牵动架构。

五类分别为:托管 API 型、开源自托管型、极简前缀型、企业反爬型、无代码市场型。

### 14.3.2 托管 API 型:以 Firecrawl 为代表

托管 API 型的代表是 Firecrawl。它是托管的网页抓取 API:输入一个 URL,返回一份清洗后的 Markdown 正文,浏览器集群、JavaScript 渲染、重试逻辑全部运行于服务端,用户无需维护任何基础设施。

**计费规则**:

* 基础规则:1 个页面 = 1 个积分(credit)
* 隐身模式(stealth,对付反爬站点的高级抓取方式):每页 5 个积分,即 5 倍价格
* 搜索功能:每 10 个结果 2 个积分

**档位**(2026 年年中刊例):

* 免费档:每月 1,000 积分
* 入门档(Hobby):16 美元/月,含 5,000 积分
* 标准档(Standard):83 美元/月,含 100,000 积分

**降低费用的两项关键操作**:

* 先列网址清单,再圈定抓取范围(用 Map 功能返回全站 URL 清单,先筛选再抓取)
* 利用免费额度实测 stealth 占比(只有被反爬拦截的页面才开隐身,普通页面用普通模式)

**适用场景**:中小规模、追求交付速度、不愿维护基础设施的团队。**不适用**:数据不得离开内网的场景,或受保护站点占比过高、stealth 费用失控的场景。

### 14.3.3 开源自托管型:以 Crawl4AI 为代表

开源自托管型的代表是 Crawl4AI。它是开源的 Python 爬虫库,专为向大模型供给数据而设计:直接输出保留标题、表格、代码结构的 Markdown,配备异步浏览器池。

**优势**:免费、零密钥、可深度定制、数据可保留在内网。 **劣势**:反爬问题完全由使用者自行承担。竞品厂商 Spider 的实测显示,未配置代理的 Crawl4AI 在混合 URL 语料上丢失了 28% 的页面\[^54^]——代理池、重试、验证码、指纹伪装,全部是使用者自己的工作。

**适用场景**:数据不得离开内网、预算为零、需对抓取逻辑做深度定制。 **不适用**:误将"免费"等同于"零成本"——同形态中免费意味着工程时间成本转嫁到使用者。

**现场细节**:某次项目,客户因"数据合规要求不得离开内网"而选了 Crawl4AI。工程师第一周用默认配置跑混合 URL 语料,200 个测试用例中丢了 28%,和 Spider 的实测一致。客户对接人(技术主管)在周会上问:"你说的'免费'方案,采集率不到 75%?" 工程师第二周加了代理池 + 浏览器指纹伪装 + 失败重试,采集率从 72% 提升到 96%,但这一周的工作量相当于 5 个工作日。客户(项目负责人)后来在合同复盘时把这条写进了"免费方案的隐性成本"一节——"免费不是零成本,只是成本从订阅费变成了工时"。**选 Crawl4AI 前,先问团队"能不能承担 1 周的反爬工程"——能,选;不能,选托管 API**。

### 14.3.4 极简前缀型:以 Jina Reader 为代表

极简前缀型的代表是 Jina Reader。其形态简单到几乎不构成一个产品:在任意网址前添加 `r.jina.ai/`,返回的即为清洗后的 Markdown,内置一个 1.5B 参数的小模型专门执行 HTML 转正文的任务。

**优势**:无需安装任何 SDK,一行命令即可完成;按 Token 计费,约 0.05 美元/百万 Token,新密钥赠送 1,000 万 Token 额度。 **劣势**:月抓 10 万页的规模下,费用为 Firecrawl 的 4—5 倍。

**适用场景**:少量大页面、无月度承诺的轻量需求。Agent 临时需要读取某篇文章时,一行命令即可完成。 **不适用**:量级上升后(超过月 10 万页)应更换形态。

### 14.3.5 企业反爬型:以 Bright Data 为代表

企业反爬型的代表是 Bright Data。当前述所有工具均被 Cloudflare 一类防线拦截时,才轮到它出场:解锁层覆盖 300 万+域名,持续对抗反爬措施,持有 1.5 亿+代理 IP。其 MCP 服务每月赠送 5,000 次免费请求,输出默认为 Markdown,可直接接入 Claude 与 Cursor。

**优势**:对付受保护站点能力强。 **劣势**:按成功请求或带宽计费,价格最高。

**适用场景**:确实存在难以攻克的站点,或企业级采集需求。 **不适用**:把"自行研发反爬绕过"作为长期策略——这是工程师最容易陷入的成本黑洞。

![抓取前实操自检流程](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-17419a9ae7468261304d04fed1ceebd2662d927d%2Fsec14_compliance_check.svg?alt=media)

![抓取环境围墙化十年](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-ecbcba13e4e4b246f3e33c04d35d15b1dede9530%2Fsec14_walled_garden.svg?alt=media)

### 14.3.6 无代码市场型:以 Apify 为代表

无代码市场型的代表是 Apify。它相当于"爬虫应用商店":7,000 多个预置的抓取小程序(Actor),社媒、电商、地图类站点的采集基本都有现成方案,配置参数后点击运行即可。

**优势**:无需工程团队,适合非工程场景。 **劣势**:社区 Actor 的维护质量参差不齐,默认走数据中心代理,住宅 IP 需额外付费。

**适用场景**:非工程团队,或"该站点大概率已有现成方案"的批量采集。 **不适用**:对抓取质量、稳定性、可控性有高要求的场景。

### 14.3.7 五类工具的选型表

| 形态       | 代表工具        | 核心优势      | 核心劣势    | 月度成本参考            | 适用场景          |
| -------- | ----------- | --------- | ------- | ----------------- | ------------- |
| 托管 API 型 | Firecrawl   | 稳定、易用、零运维 | 数据出内网   | $16 起             | 中小规模、不愿维护基础设施 |
| 开源自托管型   | Crawl4AI    | 免费、可定制    | 反爬自理    | 工程时间成本            | 数据不出内网、需深度定制  |
| 极简前缀型    | Jina Reader | 极简、零安装    | 大量级下费用高 | 按量,$0.05/1M Token | 少量大页面、零月度承诺   |
| 企业反爬型    | Bright Data | 对付受保护站点   | 价格最高    | 按成功请求计费           | 受保护站点、企业级采集   |
| 无代码市场型   | Apify       | 无需工程团队    | 质量参差    | $5 免费额度起          | 非工程团队、批量采集    |

**选型的核心问题**:团队"是否具备维护基础设施的人力"?有——选开源自托管型;无——选托管 API 型或极简前缀型;有受保护站点——选企业反爬型;无工程团队——选无代码市场型。

### 14.3.8 关于"横向基准"的提醒

市面上流传一组"横向基准":某项指标上 Spider 91.5% > Firecrawl 89% > Crawl4AI 84.5%\[^54^]——**这组数字由 Spider 这家竞品厂商自行测试、自行发布**,且每一项它都位列第一。来自利益相关方的基准,方向可以参考,具体数字不应采信。阅读任何工具对比文章,先确认作者身份——这个领域的基准测试,十之八九出自竞品之手。

## 14.4 通过 MCP 为 Agent 接入数据工具

**现场还原**:某次项目,客户对接人是技术主管,要求把已有的 Firecrawl 接入 Claude Code(交付期 18—22 天)。工程师(团队里最熟 MCP 的那位)在 30 秒内翻到一篇 AI 生成的教程,看到 `npm install -g @anthropic/firecrawl-mcp`,直接在生产环境的终端里跑下去。装到一半,工程师注意到包名不像"Firecrawl 官方"的风格——平时 Firecrawl 的包名是 `firecrawl-mcp`,这个多了 `@anthropic/` 前缀。工程师停下来,去 GitHub 上搜 Firecrawl 官方仓库,README 里的安装命令是 `npm install -g firecrawl-mcp`,没有 `@anthropic/` 前缀。回头去 npm 上查 `@anthropic/firecrawl-mcp`,周下载量 47,最后一次更新在 6 周前,README 里只有 8 行说明,代码里有一行调用了 `process.env` 读取所有环境变量。技术主管在群里看到截图后立刻说:"这个包要是有恶意代码,你刚才已经在生产环境跑了。**重装系统、改所有 token,别省事**。" 工程师当晚把生产服务器重做了一遍,所有 token 轮换。这次事故没有造成实际损失,但内部复盘时,客户(项目负责人)把"装包前必须用 2 分钟查包名"写进了团队 SOP。

**教训**:装包前用 2 分钟在 GitHub + npm 上核对包名,比踩中一次 slopsquatting(幻觉包名投毒)的修复成本(动辄 4—8 小时)低两个数量级。AI 教程里出现的"看似官方"的包名,十之八九是模型幻觉出的,不查就装是最高频的安全事故来源。

### 14.4.1 MCP 已成为数据工具的标准接入方式

MCP(Model Context Protocol,模型上下文协议)是**为 Agent 安装工具的通用接口标准**:工具提供方按协议将能力暴露为"工具",客户端(Claude Code、Cursor 这类编程 Agent)按同一协议接入,双方各自实现一遍即可互连——其地位类似于硬件领域的 USB-C,不同厂商的设备共用同一接口形态。

MCP 出现之前,每接入一个数据源都要在 Agent 代码中编写一层定制对接逻辑;有了 MCP,接入新工具仅是修改一行配置的工作。

数据获取工具的 MCP 化在 2026 年已成为事实标准:Firecrawl 提供官方 MCP 服务,Tavily 提供 `tavily-mcp`,浏览器自动化领域有 Playwright MCP,Bright Data 的 MCP 每月赠送 5,000 次免费请求,Apify 则将其整个商店挂载上来——一个 MCP 入口暴露 7,000 多个抓取小程序。

### 14.4.2 MCP 的两种部署形态

MCP 服务的部署形态有两种:

* **本地子进程(stdio)**:服务作为本地子进程运行,数据不经过第三方,适合个人使用
* **托管 HTTP 端点**:服务商将 MCP 挂载为公网 HTTP 端点,部署省事、可向团队共享,代价是请求须经过服务商的服务器——涉及私域数据时,"是否经过第三方"即为决策依据

### 14.4.3 使用 FastMCP 自行封装 MCP 服务

现成服务再好,也存在覆盖不到的需求:为搜索增加行业站点白名单、将公司内网 API 暴露给 Agent、对多家服务做统一封装。此时需要自行编写 MCP 服务器。

FastMCP 是 Python 社区事实标准的 MCP 服务端框架\[^340^],以装饰器方式将普通 Python 函数注册为 MCP 工具。自行编写 MCP 服务的常见模式:用 FastMCP 封装一个搜索客户端,暴露 web\_search 和 web\_extract 两个工具。

**验收环节需要检查三项**:

* 包名与 API 参数是否正确
* 返回值是否做了截断(工具返回的内容直接进入模型上下文,过长会立即超支)
* 实际运行一遍,检查输出是否为干净的 Markdown

**现场细节**:某次项目,工程师用 FastMCP 封装了公司内部搜索 API,暴露给 Agent 用。开发期间一切正常——工程师每次手动测试,搜索结果只有 200—500 字。某天下午 Agent 自主调用了一次,搜索的目标关键词命中了一份 3 万字的行业报告(全文返回),返回的 3 万字 Markdown 一次性塞进了模型上下文。当晚,客户的模型账户账单上多了一笔 240 美元的单次调用(对比正常单次调用约 0.05 美元,溢出了约 4,800 倍)。第二天,负责人在群里问工程师:"FastMCP 工具的返回值,你做截断了吗?" 工程师答"忘了"。负责人当时没多说,只把"返回值必须做截断,默认上限 2,000 字"加进了 FastMCP 工具封装的 SOP 第一条。**FastMCP 工具的返回值,默认上限 2,000 字,超出截断——这条不是优化,是硬约束**。

### 14.4.4 安装前的包名核对

本节最后是一项安全警示。网上不少教程在讲解 Firecrawl 的 MCP 安装时,所写的包名是 `@anthropic/firecrawl-mcp`——**该包名是错误的**,Anthropic 官方从未发布过这一名称的包,Firecrawl 官方仓库对应的 npm 包名为 `firecrawl-mcp`\[^353^]。

这一错误的危险性在于:`@anthropic/`这种带官方组织名的前缀在外观上极具迷惑性。AI 生成的教程尤其容易编造这类"看似官方"的包名——模型幻觉出一个不存在的包名,不法分子随即将同名恶意包上传至仓库等待受害者,这一攻击手法在安全领域称为 slopsquatting(幻觉包名投毒)。照教程执行 `npm install` 的瞬间,恶意代码即以当前用户的权限运行。

装包流程固定为三步:第一步,在 GitHub 上找到官方组织的仓库,以 README 中的安装命令为准;第二步,在 npm 上核对该包的发布者是否为官方组织;第三步,执行 `npm view 包名` 查看周下载量与最后更新时间——一个自称"官方包"的项目周下载量仅两位数,必然存在问题。这三步耗时两分钟,而踩中一次陷阱的代价远超两小时。

## 14.5 运营纪律:五条实操红线

**现场还原**:某次项目,客户的爬虫在目标平台跑了 11 天,被平台的风控系统识别——先是单 IP 段被临时封禁,然后域名被加入黑名单,最后法务部发来律师函,要求 48 小时内停止全部抓取动作并删除已抓数据。客户(项目负责人)当晚拉群,把客户对接人(技术主管)、负责运维的工程师、负责人(我方)拉在一起,第一句话是:

> 客户:这是合规事故,不是技术事故。律师函里写了三条:未遵守 robots.txt、未控制抓取频率、缓存了用户个人信息。前两条我们确实违规,第三条是对方误读——但单这两条就够赔偿了。

当晚,客户把抓取频率从"每秒 5 次"调到"每秒 0.5 次"(下调 10 倍),关闭了所有未声明禁抓路径的抓取脚本,清理了缓存中的用户信息字段。一周后,平台法务回函,要求补一份"未来 12 个月的合规承诺书",不再追责。负责人后来把这次事件写进了新员工入职培训的第一课——标题叫"**红线不是上线后学的,是上线前学的**"。

技术内容至此完毕,最后一节篇幅最短,分量最重。

落到实操层面,为团队设定的红线共五条\[^355^]:

一、**只抓对方欢迎你抓的内容**——登录墙、付费墙、验证码之后的内容全部不碰。判断方法:把你要抓的内容粘贴进浏览器,无须登录即可打开,且站点本身没有反爬墙——可以抓;否则就停。

二、**频率控制到对方感受不到**——一秒钟请求一百次、对方服务器响应变慢,即为越界。一条经验法则:单域名每秒不超过 1 次,每天总量不超过对方页面数的两倍。带缓存、错峰,是必备工程手段。

三、**不绕过任何技术防护**——站点明确声明禁止抓取的路径,不要尝试绕过;用户协议里写明禁止批量采集的,遵守。"我能绕过"不等于"我应该绕过"。

四、**避开敏感内容**——价格、库存、新闻稿这类公开业务数据,可以抓;姓名、手机号、邮箱、人脸、身份证、聊天记录这类涉及个人或隐私的内容,不要碰。判断不出"这条算不算敏感"时,默认按敏感处理。

五、**全程留痕**——抓了哪些 URL、什么时间、什么频率、HTTP 状态码是什么——全部写进日志,留至少 90 天。日志不是给工程师看的,是项目遇到纠纷时唯一能自证清白的材料。

五条全部通过,再讨论技术选型;任何一条存疑,就停下——工程师的回答永远是"技术上可行",但可行不等于应该。

**现场案例**:某次行业内部交流,一家中型公司(做行业资讯聚合)分享过一个事故:他们的爬虫在某行业垂直网站上跑了 3 个月,某天被对方起诉侵权,索赔 30 万人民币。庭审中,对方出示了"该公司在 90 天内累计抓取 X 万次、平均每秒 0.8 次"的证据,该公司辩护的核心论点是"我们抓的是公开数据"。法院最终判该公司败诉,理由是"虽抓的是公开数据,但抓取频率超出对方欢迎范围,且未保留任何抓取日志,无法自证清白"。该公司 CEO 后来在行业会上说:"我们当时连一行日志都没留——以为'没留痕就没事',结果是'没留痕,自己也没法证明自己没事'。这次教训让我们所有爬虫项目从第二天起,日志保留 90 天起步。" 负责人把这条写进了团队的运营 SOP 第六条(没有编号,但在内部文档里就叫"**日志不是负担,是保险**")。

## 14.6 方法论提炼与可复用资产

**现场还原**:某次项目收尾,负责人和工程师在会议室复盘——把 18—22 天的交付过程浓缩成 3 条方法论。工程师听完说:"这不就是我们之前两次重构都没解决的事吗?" 负责人答:"对——之前两次重构都在工具层动手脚,这次先把'该不该抓'和'该用哪类工具'在决策层分开,工具层就只是执行了。方法论不是新发明,是我们前两次失败换来的总结。"

### 14.6.1 三点方法论

本章信息量较大,收束为三点。

**第一点:三类数据源按"数据归属、是否有时效"分层,不按工具新旧分层**。2026 年的新工具功能再强,也无法回答私有数据的问题;Scrapy 历史再久,在稳定站点的高并发生产上仍是最优解。技术社区持续追逐新工具,但数据架构的分层逻辑十年未变——常识问内置知识,时事问搜索,自有数据自行抓取、自行建库。

**第二点:实操自检先于技术选型,顺序不可颠倒**。先回答"能不能抓",再回答"用什么抓"。流程颠倒的代价——工具选定、管道搭好、数据入库之后才发现越界——不是返工,而是数据全删、项目作废。

**第三点:本章是"检索"杠杆的工程底座**。第 7 章的 RAG 流水线、第 12 章的竞品监控,向上追溯,数据来源皆出于此。Agent 的能力再强,供给它的数据一旦中断、污染或越界,上层构建的一切均失去根基。

### 14.6.2 两张可复用模板

**模板一:抓取前实操自检表**——每个抓取项目启动前逐项核对,与 14.5 的五条红线一一对应。

```
抓取前实操自检表(任一项答不上来 → 停下来,先解决再谈技术选型)
□ 目标内容不需要登录、不需要付费、无验证码即可直接打开?
□ 页面不是反爬墙后面(弹验证、要 JS 渲染才能看到正文)?
□ 站点 robots.txt 没明文禁抓目标路径?
□ 目标内容不含个人敏感信息(姓名、手机、邮箱、人脸、身份证)?
□ 抓取频率有限流方案(每秒请求数有上限、有缓存、可错峰)?
□ 抓取量不超过对方页面数的两倍 / 天(不冲垮对方服务器)?
□ 抓取日志方案就绪:URL、时间、频率、HTTP 状态码全部留痕?
□ 不拿抓来的数据去跟原站打同质化竞争(不复制对方的核心内容)?
```

**模板二:爬虫成本估算模板**——核心公式为:月积分消耗 = 总页数 × (1 + 受保护页面占比 × (反爬倍数 − 1))。

```
月成本 = 普通页数 × 单价 + 受保护页数 × 单价 × 反爬倍数

例:5 竞品 × 15 页 × 30 天 = 2250 页/月,实测 2/15 ≈ 13% 页面要 stealth(5 倍价)
加权积分 = 2250 × (1 + 0.13 × 4) = 3420 → Hobby 档 5000 积分够覆盖
按 Standard 单价折算 ≈ $2.84/月
结论:选 Hobby($16/月),别为 $2.84 的用量买 $83 的档
```

使用模板时须注意两个参数的顺序:先用免费额度**实测**受保护页面占比,再代入公式估算,最后才选定档位。成本失控的案例,十之九是顺序颠倒——先购买大档位,随后才发现受保护比例是 60% 而非 6%。

### 14.7.1 本章思考题

1. 14.1.1 的"公开可见 vs 开放取用"边界:你的项目最近一次爬虫被法务警告是什么时候?这次事件有没有让你修改监控范围?
2. 14.2.2 的"数据源决策四问":你的下一个项目需要的数据,按四问走完后,落在哪条路径(内置知识/联网搜索/爬虫知识库)?为什么?
3. 14.3.7 的五类工具选型表:你团队当前用的是哪一类?是否具备"维护基础设施的人力"?如果没有,选型是否合理?
4. 14.4.4 的"装包前三步":你最近一次 `npm install` 前有没有在 GitHub + npm 上核对包名?如果没核对,踩中 slopsquatting 的风险有多大?
5. 14.5 的五条运营红线(robots 遵守、限频、脱敏、留存日志、应急联系):你的项目满足几条?如果少于 3 条,合规风险有多大?

### 14.7.2 本章延伸阅读

1. **\[工具文档] Firecrawl 官方文档 Build with AI(Skills + CLI)** — map/crawl/scrape 三个子命令;firecrawl-website-design-clone 工作流技能把网站设计系统提取为 DESIGN.md | 第 14 章
2. **\[工具文档] FastMCP 官方 GitHub 仓库(jlowin/fastmcp)** — 30 行教学代码基于官方 fastmcp 库,实测 3.4.5 可实例化并注册两个工具 | 第 14 章
3. **\[数据报告] AFFiNCO Firecrawl Pricing 2026(2026-07-23)** — Free 1,000 credits、Hobby $16/5,000、Standard $83/100k、stealth 5 credits/页、149k stars | 第 14 章
4. **\[文章] Apify 官方博客《Jina AI vs. Firecrawl for web-LLM extraction》(2026-06-11)** — Jina 约 $0.05/1M token、新 key 送 10M token、Apache-2.0;Firecrawl 核心 AGPL-3.0 | 第 14 章
5. **\[文章] xlap.top 技术博客 Crawl4AI 专文(2026-05-29)** — Crawl4AI 50,000+ stars、零密钥、CLI/Docker 部署 | 第 14 章

## 14.7 完整提示词:数据获取的选型与建库

**现场还原**:某次项目,客户原有 12 页的"数据获取方案文档"(团队自己写的,内部分享用),工程师看着累,客户对接人(运营)更看不懂——文档里一半是"代理池配置",另一半是"反爬绕过策略",看完不知道"我们项目到底用哪个工具"。负责人把本章的方法论提炼成了下面这份提示词,客户对接人(运营)在 18—22 天交付期里,直接用提示词和工程师对话——"我要做 XX 数据,提示词告诉我该用内置知识,工程师就只接这一类"。客户对接人(运营)后来在项目总结会上说:"这份提示词让我从'完全不懂技术'变成'知道该问工程师什么问题'——我不再追着工程师要'你怎么做的',而是问'你按提示词走到第几步了'。12 页文档没解决的事,这一段提示词解决了。"

以下提示词用于"为 AI 产品确定数据获取方案,包括数据源选择、爬虫工具选型、MCP 接入"。它把"三类数据源决策框架 + 五类爬虫工具选型 + 行为边界"全部落到 prompt 里,任何抓取动作都必须在 prompt 里显式声明边界。

```
你是数据获取顾问,擅长为 AI 产品选择合适的数据源、抓取工具和接入方案。接下来的所有工作,你必须严格按"数据源决策 → 工具选型 → MCP 接入 → 行为边界"四步推进,任何抓取动作都必须先回答"该不该抓"再回答"用什么抓"。

【你的工作方式】
- 阶段一(数据源决策):根据数据特性,确定用内置知识、联网搜索、还是爬虫+知识库
- 阶段二(工具选型):基于团队基础设施能力,选五类爬虫工具之一(托管 API 型 / 开源自托管型 / 极简前缀型 / 企业反爬型 / 无代码市场型)
- 阶段三(MCP 接入):把数据源工具接入 Agent,实现"AI 直接调用"
- 阶段四(行为边界检查):按 14.5 的五条红线,逐条核对

【数据源决策四问】
1. 时效性要求?没有 → 用内置知识,边际成本为零。有 → 进入下一问。
2. 数据是长尾 / 私有 / 指定站点?不是公开时事 → 联网搜索(便宜)。是 → 进入下一问。
3. 需要批量获取或结构化字段?不需要 → 单次抓取工具。需要 → 爬虫 + 知识库。
4. 需要可复现、可审计?需要 → 知识库 + RAG 检索,每条数据可回溯。不需要 → 一次性抓取即可。

【五类爬虫工具选型表】
- 托管 API 型(以 Firecrawl 为代表):中小规模、追求交付速度、不愿维护基础设施。计费 1 页 1 积分,stealth 5 倍价,Hobby 档 16 美元/月含 5,000 积分。
- 开源自托管型(以 Crawl4AI 为代表):数据不得离开内网、预算为零、需深度定制。免费但工程时间成本自负。
- 极简前缀型(以 Jina Reader 为代表):少量大页面、无月度承诺。约 $0.05/1M Token,新 key 送 1,000 万 Token。
- 企业反爬型(以 Bright Data 为代表):受保护站点、企业级采集。解锁层覆盖 300 万+域名,价格最高。
- 无代码市场型(以 Apify 为代表):非工程团队、社媒电商批量采集。7,000+ Actor,免费 $5 积分/月。

【选型决策树】
- 团队有维护基础设施的能力吗?有 → 开源自托管型。无 → 进入下一问
- 有受保护站点吗?有 → 企业反爬型。无 → 托管 API 型
- 团队无工程能力?无代码市场型
- 单次少量大页面?极简前缀型

【行为边界(五条红线)——这条最重要】
1. 只抓对方欢迎你抓的内容——登录墙、付费墙、验证码之后全部不碰
2. 频率控制到对方感受不到——单域名每秒不超过 1 次,每天总量不超过对方页面数的两倍
3. 不绕过任何技术防护——robots 协议明文禁抓的不绕过
4. 避开敏感内容——姓名、手机、邮箱、身份证等个人信息不抓
5. 全程留痕——抓了什么、什么时间、什么频率,留至少 90 天

【MCP 接入标准流程】
1. 工具选型完成后,安装官方 MCP 包(如 firecrawl-mcp、tavily-mcp、playwright-mcp)
2. 在客户端配置文件(如 ~/.claude/settings.json)添加 MCP 服务
3. 配置环境变量(API Key 等)
4. 重启客户端,验证工具出现在 Agent 工具箱
5. 用一个真实任务测试,确认 AI 能正确调用

【MCP 接入的安全检查】
- 包名必须以官方仓库为准(`firecrawl-mcp` 正确,`@anthropic/firecrawl-mcp` 错误)
- 必须在 GitHub 上找到官方组织仓库
- 必须在 npm 上核对发布者身份
- 必须执行 `npm view 包名` 查看下载量(两位数周下载的"官方包"必有诈)
- 警惕 slopsquatting(AI 教程中常见的"看似官方"包名实为恶意包)

【输入格式】
提供——
- 需要获取的数据(具体描述)
- 数据规模(每月多少页、每日多少次)
- 团队技术能力(有/无运维、有/无工程)
- 数据使用场景(产品内展示 / 报告生成 / 实时查询)
- 安全要求(数据能否离开内网)

【输出格式】
- 数据源选型建议(用内置知识 / 联网搜索 / 爬虫 + 知识库)
- 工具选型建议(五类之一,带理由)
- 成本估算(月度预算,带计算过程)
- MCP 接入步骤(具体命令)
- 行为边界确认(五条红线逐条核对)

【边界约束】
- 不绕过任何技术防护(robots 协议、反爬墙等)
- 不抓取需要登录、付费、验证码的内容
- 不抓取个人敏感信息
- 不在没看官方文档的情况下,凭"教程"装包
- 不推荐"免费但工程成本高"的方案给无运维团队
- 不推荐"反爬绕过"作为长期策略

【遇到这些情况,先暂停并通知我】
- 目标站点需要登录才能访问
- 目标站点的 robots.txt 明文禁抓目标路径
- 选型工具需要付费且超出预算
- 你的工具选型建议有几种都可接受
- 你发现目标内容可能涉及个人敏感信息
- 你意识到某条"教程"的包名可疑
```

## 本章方法论:让数据获取从技术问题变成决策问题

本章的方法论核心是"让数据获取从技术问题变成决策问题"——按数据归属和时效分层选择数据源,按交付形态选择爬虫工具,按运营纪律划定行为边界。技术细节是次要的,决策框架才是可持续运营的保障。

下一章(也是全书最后一章)将进入"skill 与子 Agent 的最佳实践"——把前 14 章识别的四根杠杆(检索、上下文管理、工具设计、子 Agent 架构)收束为可操作的工程体系。