数据检索与企业获客

这是什么

获客名单搭建、B2B 数据富集、面向获客的网页抓取——交付的是一条你自己拥有的管道，而不是一份买来就开始过期的名单。数据在哪，我们就去哪取——公开目录、授权数据库、登录后的门户、一摞 PDF——取回来做结构化、去重、富集，再直接接进你的 CRM，从此没人再手工录一条记录。项目通常在 5.5 万到 17.5 万元之间，交付的是定时、带监控的任务，而不是一个 CSV。

我们通常碰到的局面

销售要的数据是真实存在的，只是散得到处都是。有的锁在某个供应商门户的登录后面；有的在一个完全靠客户端渲染出来的公开目录里；有的在三张互相对不上的表格里。CRM 里同一家公司用几个略有差别的名字录了四遍。没人信这些数据，于是大家继续手工录，管道也就一周烂一点。

这项服务就是把这套问题修好的管道：从数据所在之处检索回来，结构化、去重、富集，再把获客直接接进你的系统——让人不用再手动敲一条记录。

我们怎么检索

多数讲抓取的教程默认页面是静态 HTML。但真正值得抓的页面往往是 JavaScript 应用——列表要等客户端代码跑完、XHR 请求回来之后才存在。这类页面我们用 Playwright 驱动一个真实浏览器：像用户的浏览器一样把页面执行起来，等网络请求落定，再读渲染后的 DOM。单页应用、无限滚动的列表、以及你已获授权的数据所在的登录门户，都能这样拿下来。

对外暴露了真正 API 的数据源，我们就跳过浏览器直接打接口——更快、更省、也更不容易碎。具体某个源走哪条路，是逐源判断、并且写下来的，不靠碰运气。

值得抽取的不只是网页。同样的纪律也适用于文档——PDF、扫描件、账单——而且文档场景的赌注通常更高，因为那些数字直接喂给真实决策。我们给一家房贷经纪公司做过一条只在有把握时才自动填写的抽取管道：两个独立来源一致、归一化之后、高置信才写入，拿不准就直接去问借款人确认。如果你的数据问题是一柜子文件而不是一个网站，那也在这项服务的范围里。

如果你在意 SEO 和 AI 可见性，有一点值得知道：AI 回答背后的爬虫大多不执行 JavaScript。一份对 5.69 亿次 GPTBot 请求的分析发现，AI 检索爬虫拉的是原始 HTML，跳过客户端渲染。如果你自己的内容要等 JS 跑完才出现，这些爬虫看到的就是一个空壳。这跟我们检索时要解决的是同一个问题，只是方向反过来。

数据落到哪里

全都进 Postgres。我们跑在 Neon 上——一种能像 Git 一样分支的 serverless Postgres，所以我们可以拉一份隔离的库副本，拿来测一次迁移或一个新数据源，测完就扔。检索和富集作为定时任务运行，带监控；某个源改了页面结构、或某个 API 开始报错时，任务会显式失败、我们能第一时间知道，而不是闷头写一周脏数据。

去重发生在数据进 CRM 之前。公司按归一化后的名称、域名和标识符来匹配，而不是按字符串完全相等，这样 “Acme, Inc.” 和 “ACME Inc” 会合成一条记录而不是两条。联系人同理。清洗规则写在代码里，每次运行都重新跑一遍，数据库不会在第一遍清完之后又慢慢退回乱糟糟的状态。

关于获客来源，说实话

我们的线索来自公开和授权的数据源，并遵守平台条款。这不是一句免责声明——它是塑造整个实现方式的工程约束。禁止自动化采集的源，不会进入管道。我们宁可给你一份更小、但你能放心用的名单，也不给你一份更大、却可能害账号被封或违反合同的名单。如果你想要的某个源不能碰，我们会说清楚原因，再找一个合规的替代来源。

“合不合法”很少有一个字的答案，我们也不装作有。数据是公开的还是登录后的、条款怎么写、有没有涉及个人数据、你拿结果去做什么——这些问题我们逐源过一遍、落在纸面上，然后这个源才上线。

你得到的东西

• 数据源检索与结构化抽取，能用 API 就用 API，必须用浏览器才用浏览器
• 定时重跑、不会悄悄烂掉的线索挖掘与富集管道
• 每次运行都执行的去重与清洗，而不只是一次性
• 获客直接接进你的 CRM，无需手工补录
• 带监控的同步任务，源一变就显式报错