我认识的每位创始人，多少都买过一份“已验证”的一万条联系人名单，结果回复率基本都在零附近徘徊。我早年也干过同样的事，很快就明白了一件事：一堆邮箱地址，并不等于一条能推进成交的管道。真正能推动交易的，是知道哪些公司值得聊、为什么值得聊——这和单纯从网上抓一堆名字，完全不是一回事。
网页爬虫常被包装成“周五前搞到 1 万个线索”的捷径，但到了 2026 年，真正好用的工具，实际上是为了做一件更有价值的事：在客户释放购买信号的那一刻，找到真实的公司账户，并附上真实证据。我在 Thunderbit 花了很多时间思考销售场景下的数据采集方式，发现拿到最好结果的团队，从来不是抓取行数最多的那批，而是抓取最对的那批，而且还带着上下文信息。
用网页爬虫找 B2B 潜在客户，到底是什么意思？
大多数人一听“抓取线索”，脑海里浮现的都是某个工具把目录页扒下来，再吐出一个包含姓名、职位和邮箱的 CSV。那不叫潜在客户开发，那叫联系人收集；也正因为如此，很多销售团队最后拿到的名单，不是退信严重，就是转化惨淡。
真正有价值的线索记录，绝不只是一个名字。它至少要包含：账户身份信息（公司名称和标准域名）、能证明这家公司确实符合理想客户画像的证据、带时间戳的触发信号（说明为什么现在联系最合适）、可接受的联系渠道、数据来源记录，以及后续可复查的状态。听起来有点复杂，但拆开来看其实很简单：先从公开且允许使用的数据源开始，确认公司身份，收集匹配证据，记录触发事件，找到最小化的联系路径，完成验证和去重，最后再写入 CRM。少一步，最终得到的就还是大家最讨厌的那种——一张陌生人名单表。
为什么这件事比以前更重要了
AI 让爬虫变得极其容易上手，也让人更容易大规模用错。几年前，搭一个爬虫还得找开发者，或者折腾一整个周末的 XPath 选择器。现在，任何人都能让 AI 爬虫对着页面跑起来，几分钟就拿到结构化数据。这当然提升了效率，但也意味着更多销售团队比以往更快地把未经筛选、未经验证的数据灌进 CRM，而后面再清洗这些垃圾数据，耗费的时间往往比一开始做好还要多。
与此同时，监管并不会因为工具更聪明就自动放松。英国信息专员办公室已经明确表示，公开可获取的企业联系人数据仍可能受 UK GDPR 约束，而在 B2B 场景中，直接营销的拒收要求同样必须被尊重。在美国，FTC 的 CAN-SPAM 指南也不会因为是 B2B 邮件就网开一面——任何商业邮件仍然要有准确的邮件头、可用的退订入口，并且必须在 10 个工作日内处理退订请求。这些都不是什么冷门法律八卦，而是你实际工作中必须遵守的底线，无论你是否意识到。
开始之前：先看场合，也看服务条款
我就直说了：不是所有网站都能抓，不管你的爬虫有多强。Google Maps 的条款明确禁止导出或批量抓取 Maps 内容。LinkedIn 的用户协议也直接禁止抓取和未经授权的自动化操作。Clutch 现行条款同样禁止手动或自动抓取。这些都不是隐藏条款，而是你在对任何网站下手前，必须先检查的第一件事。我也专门写过关于 LinkedIn 抓取的内容，因为这类问题实在太常见了。
robots.txt 值得了解，但不能把它当成法律上的绿灯。按 IETF 自己的规范，robots.txt 只是爬取指令，不是授权系统，也不是访问控制机制。一个网站即使在 robots.txt 里允许爬取，也仍然可以在服务条款里禁止抓取；一旦发生争议，通常还是条款说了算。我的经验法则是：如果某个网站需要登录才能看到数据，前面有验证码，或者条款里任何地方写了“禁止抓取”，那就直接跳过这个来源，不要硬解题。
通常更安全、也更适合做 B2B 调研的公开来源包括：公司官网、政府备案文件、经许可的展会和合作伙伴目录、招聘页面，以及新闻中心。例如，SEC 的 EDGAR API 就提供免费的公开 JSON 申报文件和 XBRL 数据，甚至不需要 API key——只要把自动请求控制在 SEC 指南要求的每秒 10 次以内即可。
完整流程：从原始抓取到可导入 CRM 的线索
下面是我真正会推荐的流程。与其说是“爬虫流程”，不如说是一个以爬虫为核心的小型研究流程。
第一步，选择一个允许使用的公开来源，只抓组织层级字段：公司名称、域名、来源 URL、类别、所在地，以及让你关注它的那个信号（比如招聘信息、新闻稿、活动列表）。第二步，对于看起来有机会的账户，访问它们的官网，确认它们到底做什么、总部在哪里、以及对外公开的联系渠道是什么。第三步，只对已经通过筛选标准的账户做验证和补充，不要把增强数据的成本浪费在还没核实的公司上。第四步，在导入之前，先和你现有的 CRM 数据做去重。第五步，带着状态字段把数据推送进去，这样销售团队就知道哪些已经审查过，哪些还需要人工确认。
最后这一步，比很多人想得更重要。我建议给每条记录都打上类似 candidate_account、qualified_account、contact_ready、needs_review 或 rejected 这样的标签。听起来有点过度设计，但当 SDR 团队问你“等等，这家公司真的确认符合我们的 ICP 了吗？”的时候，你就会庆幸自己有明确答案，而不是只能耸耸肩。
去哪里找高信号的 B2B 账户
最有价值的信号其实并不隐蔽，只是大多数团队从来没有系统性地去看。公司招聘页能告诉你他们正在招什么人，这通常也能反映出他们正在投入哪个方向。新闻中心和新闻稿会透露融资、扩张和产品发布等信息。合作伙伴目录和展会参展名单（前提是允许抓取）能展示某家公司是否活跃于某个生态圈。公开备案文件，尤其是对规模较大的公司，往往比 LinkedIn 动态更能看出财务健康状况和战略重点。
当然，任何单一信号都不能直接证明购买意图——“招聘销售副总裁”并不代表这家公司明天就一定会买你的产品。但把这些信号放在一起，并与自己的 ICP 标准进行匹配，它们的筛选效果，远比一份六个月前从线索市场买来的静态名单靠谱得多，而那份名单往往早就有 20% 过时了。
为什么 AI 驱动的爬虫会改变玩法
这就是和我五六年前做爬虫时真正不同的地方。过去那种传统爬虫，要为每一种页面布局单独写选择器；网站只要一改 HTML，爬虫就坏了。AI 驱动的爬虫更像人在读页面——它会根据上下文理解“这是公司名、这是所在地、这是职位名称”，而不是依赖脆弱的 CSS 路径。
正因为有了这种变化，像 Thunderbit 这样的工具，才能在看到列表页后借助 AI Suggest Fields 自动推荐合适的列，而不是让你手工一个字段一个字段去映射。你也可以直接用自然语言告诉它你想要什么——比如“帮我提取公司名称、网站、行业和所在地”——AI 就会自己判断怎么抓。我接触过一些团队，以前为了一个网站配置爬虫得花半天，现在几次点击加一次检查就够了。这并不是因为合规规则变了——它们没有变——而是因为把这件事做好的技术门槛大幅降低了。关于这种变化在更广泛的 AI 抓取领域里意味着什么，你也可以看看我们对 AI 网页爬虫的分析，以及它和旧式规则驱动方法的区别。
子页面问题（为什么只抓列表页远远不够）
这里有个几乎所有新手都会踩的坑：列表页从来都不是全部信息。目录页可能只给你公司名称和一个链接，但你真正需要的证据——这家公司做什么、总部在哪、服务哪个行业——通常都藏在更深一层，也就是公司自己的详情页或官网里。
我见过不少团队从目录里抓了几百行，最后才发现一半“线索”都缺少那个真正决定资格判断的关键字段。这也是为什么子页面抓取会成为一个独立功能类别，而不是锦上添花的小功能。一个好的爬虫，应该先访问列表页，抓取每家公司详情页的链接，再自动跟进这些链接，把更深层的数据提取出来，最后合并成一条干净的记录。少了这一步，你判断线索时，其实只是在看公司名再猜。
分步教学：如何用 Thunderbit 找 B2B 潜在客户
下面我会按自己真正操作时的方式来讲：打开目标目录页，泡一杯咖啡，然后开始。
第 1 步：安装 Thunderbit 并打开你的目标目录
先安装 Thunderbit Chrome Extension，然后进入一个允许使用的公开来源——比如参展商名单、行业目录、招聘板块，或者任何适合你 ICP 的页面。在继续之前，先确认这个网站的条款允许这种用途；这个动作只要两分钟，却能在后面帮你省掉一堆麻烦。
第 2 步：点击“AI Suggest Fields”
不要手动一个个点页面来定义列，直接让 AI 根据页面结构推荐字段，比如公司名称、网站、所在地和类别。你也可以编辑这些字段，或者用自然语言自己新增，比如“提取这家公司服务的行业”就可以作为字段说明。
第 3 步：开始抓取
启动提取，让它跑完整个列表页（如果目录有多页，也包括分页）。这一步拿到的是“原始数据”——只有公司层面的识别信息，还不能算是私人联系信息。
第 4 步：用子页面抓取做补充
对那些看起来有潜力的行，使用子页面抓取，跟进每家公司自己的官网或详情页，提取更深层的信息，比如他们做什么、总部在哪，以及公开的联系渠道。这一步会把一条空白的目录记录，变成一条真正合格的账户记录。
第 5 步：验证和清洗
在任何数据进入 CRM 之前，先抽样检查。确认域名能正常解析，确认筛选理由真的成立，并把任何模糊不清的记录标记为 needs_review，而不是靠猜。如果你已经找到合法的公开联系渠道，也可以在这一步通过 Hunter 之类的服务做邮箱验证——但要记住，“邮箱有效”并不等于你有权向这个人发营销邮件。
第 6 步：导出并推送到 CRM
Thunderbit 可以免费导出为 CSV、Excel、Google Sheets、Airtable 和 Notion 等格式。在导入 HubSpot 或 Salesforce 之前，建议把公司域名统一作为主键。HubSpot 自己的导入指南建议，企业用域名作为主键，联系人则用邮箱；而如果你跳过这一步，Salesforce 的重复规则可能会悄悄拦下或标记你的导入。对我来说，先做 20 到 30 行的小批量测试，再做完整导入，已经不止一次帮我避免了更糟糕的清理工作。
小技巧与常见坑
下面这些是我会告诉任何刚开始做这件事的人注意的点。不要把抓到的职位名称或岗位当作购买意图的铁证——它只是一个线索，不是绿灯。也不要默认 AI 提取的字段一定正确；在任何流程放大之前，先抽样核对。把姓名联系人和直接邮箱，与公司层面的研究数据分开管理，并且用更严格的规则来控制，因为 B2B 场景并不自动排除个人数据的隐私要求。还有，不要让“工具技术上能做到”变成你的合规策略——每一次都要检查来源条款，而不是只在第一次看一次。
网页爬虫 vs. 购买线索数据库
这两种方式都有适用场景，假装其中一种在任何情况下都更好，这其实有点不诚实。
| 因素 | 网页爬虫（允许使用的来源） | 购买线索数据库 |
|---|---|---|
| 新鲜度 | 取决于你最近一次抓取，通常最新 | 往往几周内就开始过时 |
| 信号质量 | 高——你可以自己控制触发点和上下文 | 低——通常只是静态的公司基础信息 |
| 覆盖范围 | 较窄，取决于来源 | 更广，且标准化程度更高 |
| 成本模式 | 主要是时间成本 + 工具订阅 | 通常按记录或席位持续收费 |
| 合规风险 | 只要来源和字段选择得当，就比较可控 | 很大程度取决于供应商自己的数据来源方式 |
| 最适合的场景 | 定向、基于信号的外呼 | 广泛市场梳理、早期 TAM 评估 |
我的坦白看法是：当你需要上下文和时机——比如某个活动的参展名单、竞争对手刚发布的新产品页、或者一家刚发了三条销售招聘信息的公司——就去抓取。若你需要的是广覆盖、标准化的数据，而且愿意自己去验证新鲜度，那就购买或使用 Apollo 之类的补充数据服务。两者并不冲突；很多团队会先抓取信号，再对筛选后的账户做补充，而不是永远只走一种路线。
一个真实场景
假设你卖的是车队管理软件，想找正在增长的物流公司。你去抓取州交通部门的公开承运商登记册，或者行业协会会员目录，就能拿到公司名称、所在地和车队规模类别——这些都是公开且允许使用的数据。然后再进入每家公司的官网，确认它们确实还在运营，并抓取总部联系方式。最终你拿到的可能是 200 个合格账户，而不是 5000 个未经验证的名字，但这 200 个每一个都值得 SDR 去跟进，这才是目标。
当你不再把它当成“名单堆砌”，而是把它当成“用更好的工具做研究”时，B2B 线索抓取的效果才会真正起来。我见过销售团队，仅靠 150 个高质量账户，就做出了比 1 万条购买联系人更好的 pipeline，因为他们的外联内容更相关，而不是千篇一律。如果你也在思考 AI 抓取如何嵌入更大的销售流程，建议看看 AI 如何重塑潜在客户开发，以及销售团队日常是怎么用 AI 的——那两篇会比“抓取”这一步讲得更深。
搭建这种 pipeline，确实比直接下载一份联系人列表更费一点功夫。但最后拿到的这些账户，是真的愿意听你说话的。作为这些年把大量冷邮件发进虚空的人，我可以很负责任地说：这额外多花的三十分钟，绝对值得。
常见问题
从网上抓取 B2B 公司数据合法吗？ 完全取决于数据来源。公开的公司官网、政府申报文件，以及明确允许抓取的目录，一般都可以用于研究目的。但像 LinkedIn 和 Google Maps 这类网站，即使技术上能抓，也在条款里明确禁止。抓取前务必检查网站服务条款，并把 robots.txt 视为爬取指令，而不是法律授权。
在这个语境下，“lead”和“contact”有什么区别？ contact 只是一个姓名和联系方式。lead 则是更完整的公司记录：它有证据证明这家公司符合你的理想客户画像，还有一个带时间戳的信号，说明你为什么要现在联系。之所以那么多冷启动外联效果差，就是因为很多人只抓联系人，不看上下文。
AI 爬虫能保证数据一定准确吗？ 不能，任何声称能做到这一点的工具都值得你提高警惕。AI 提取在处理杂乱页面时非常强，但遇到歧义字段时仍然可能读错。无论你用什么工具，在规模化之前抽样检查，都是值得坚持的习惯。
我应该直接抓邮箱，还是之后再用补充数据工具？ 通常后者更可靠。补充数据工具在查找和验证联系人邮箱方面，往往比直接从页面硬抓更稳，而且验证状态也会标得更清楚。我的建议是先抓公司层面的资格信息，再只对已经符合筛选条件的账户做补充，这样更高效，也能降低合规风险。
怎么避免把重复线索导入 CRM？ 导入前先把公司域名统一成主标识，而不是公司名称——公司名的写法变化太多，去重不稳定。HubSpot 和 Salesforce 都有各自的匹配规则说明，先做一个小批量测试，再做完整导入，能提前发现大多数问题，避免后面把 pipeline 搞乱。
