数据检索与企业获客

我们通常碰到的局面

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

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

我们怎么检索

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

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

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

数据落到哪里

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

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

关于获客来源，说实话

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

你得到的东西

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