一支创始人主导的 B2B 团队如何发现 14,000 家公司、对其评分,并在每个冲刺中精选出 150 个外联目标 — 全部基于单个 db/linkedin/search/companies 端点。
一家创始人主导的 B2B SaaS 运营团队(员工不足 10 人,成立于 2024 年)运行着一套精品化的外联项目 — 高质量、人工审核的触达,每周约 150 次 — 针对一套自定义的 ICP(理想客户画像)框架。团队没有购买横跨公司画像数据、列表构建、数据增强和投递的整套销售技术栈,而是在 db/linkedin/search/companies 以及四个辅助端点之上构建了一条单一的管道。
这种基于数据库的搜索用一个结构化的请求体和一套用于关键词匹配的迷你 DSL,取代了多供应商的技术栈。输出是原始行,由团队在自己这一侧进行评分 — 没有继承自供应商的 schema,数据发现也没有按记录收费。
在单个冲刺中通过一次查询发现(约 2 秒的实际耗时)
每周提供 钩子 + 已验证邮箱 + 无角色漂移
自付的 LLM 成本;发现类 API 调用在 MCP Unlimited 下免费
精品化的 B2B 外联需要一个精准的 ICP:不是"B2B 科技",而是公司类型、规模、地域、融资阶段和产品定位的一个特定交叉切面。现成的销售技术栈迫使你接受一个粗糙的 ICP — 行业代码、员工区间、硬性分类。要进一步收窄,团队需要拼接四到六家定价重叠、覆盖不全的供应商,然后无论如何还是要导出并在自己这一侧重新分类。
团队需要:
description、short_description、specialities、hashtags 和 locations 中同时匹配短语/db/linkedin/search/companies 端点通过结构化请求体直接暴露数据库。关键词使用一套迷你 DSL(空格 = AND,| = OR,"phrase" = 精确短语,-token = NOT)。过滤器是带类型的:employee_count_min/max、founded_on_min/max、country_hq、country_any、is_active、has_description、min_description_length 等等。
单个 keywords 字段会在 name、description、short_description、specialities、hashtags 和 locations 中同时搜索。对于从自主外联代理到合规研究工具等 27 个 ICP 类别,团队为每个冲刺构建一个 DSL 字符串:
{
"keywords": "\"AI SDR\"|\"AI BDR\"|\"autonomous outbound\"|\"AI sales agent\"|\"AI research agent\"|\"AI signal\"|\"AI inbound qualification\"|\"AI prospecting\"",
"country_hq": ["US","GB","DE","NL","FR","CA","AU","IE","SG"],
"employee_count_min": 11,
"employee_count_max": 200,
"is_active": true,
"has_description": true,
"min_description_length": 100,
"count": 1000
}
这一次调用就返回了 1,000 家 ICP 候选公司,包含完整的 LinkedIn 字段,实际耗时约 2 秒。
粗糙的国家过滤器有一个常见陷阱是子串匹配:US token 过去会错误地匹配到 Austria、Australia、Austin、Houston。country_hq 和 country_any 参数直接从 headquarter_location 和 locations[] 数组中解析出 ISO2 代码,消除了这一类误报。
{
"industry_name": "fintech|payments",
"country_hq": ["US","GB","DE"],
"employee_count_min": 51,
"founded_on_min": 2020,
"page_verification_status": true,
"count": 500
}
当跨字段的 keywords 撒网过宽时,团队会按特定字段收窄:
specialities: "data engineering|ML" — 仅在声明的 specialities 中匹配,忽略营销文案式的 descriptionname: "ai|agent" — 在公司名称中匹配(捕捉 AI 原生初创公司的品牌命名)description: '"sales intelligence" -consultancy' — 对咨询类命中进行布尔排除每日 ICP 刷新作为一条链式管道运行:
| 步骤 | 操作 | 由谁驱动 |
|---|---|---|
| 1 | 通过关键词 DSL 拉取 1,000–10,000 个 ICP 候选 | db/linkedin/search/companies |
| 2 | 用融资阶段 + 总额 + 增长评分进行数据增强 | crunchbase/company(缓存查找) |
| 3 | 对照 27 个类别的 ICP 框架为每家公司评分(HOT/WARM/MAYBE/EXCLUDE/COMPETITOR) | 使用 prompt 缓存系统提示词的 LLM |
| 4 | 过滤至 HOT 层级(池中前约 2-5%) | 在 cache_key 上使用 query_cache |
| 5 | 为每家公司找到 5–15 名高级决策者 | linkedin/sn_search/users |
| 6 | 抓取近 90 天的帖子用于购买意向评分 | linkedin/user/posts |
| 7 | 通过 vanity 解析的个人主页 URL 查找邮箱 | linkedin/user/find_email_by_url |
| 8 | 生成锚定到真实帖子或主页的 24–30 词个性化钩子 | LLM(使用更高层级模型以保证质量) |
| 9 | 将可直接发送的线索导出为 CSV 供外联平台使用 | export_data |
端到端运行时间:处理 14,000 家公司约 1.5 小时。自付成本:LLM 调用约 15–20 美元。发现类 API 调用:在 MCP Unlimited 下免费。
| 管道指标 | 数值 |
|---|---|
| 发现的公司数(单个冲刺) | 14,000 |
| 发现查询的实际耗时 | 约 2 秒 |
| 评分为 HOT 的公司(聚焦收窄) | 319(2.3% — 比朴素过滤窄 20 倍) |
| 主攻先锋细分中的 HOT 公司 | 211(占 HOT 的 66%) |
| 在 HOT 关联公司中找到的决策者 | 16,000 |
| 通过 Tier 2 查找器解析出的邮箱 | 8,100(vanity 解析后命中率 62%) |
| 生成的带可验证来源 URL 的个性化钩子 | 245(0 错误) |
| 可直接发送的线索(钩子 + 邮箱 + 无角色漂移) | 180 |
| 验证指标 | 数值 |
|---|---|
| 与外部获取的 279 家公司目标列表的交集 | 84%(279 家中有 234 家已在管道中) |
| 交集中被团队评分归类为 HOT 的比例 | 99%(234 家中有 231 家) — 独立确认 |
| Crunchbase 数据增强匹配率 | 25%(13,972 家公司中有 3,298 家含融资信息) |
团队运营整条外联漏斗 — 发现、数据增强、评分、意向检测、个性化、投递准备 — 无需订阅单独的公司画像数据、列表构建、数据增强或投递供应商。
| 端点 | 用途 | 用量占比 |
|---|---|---|
db/linkedin/search/companies |
通过 SQL 风格迷你 DSL 进行批量 ICP 发现 | 35% |
linkedin/sn_search/users |
批量进行高级决策者数据增强 | 25% |
linkedin/user/posts |
从近期帖子中收集购买意向信号 | 20% |
linkedin/user/find_email_by_url |
为外联投递解析邮箱 | 15% |
crunchbase/company |
用于层级评分提升的融资/阶段信号 | 5% |
LinkedIn 深度公司画像查询 + 灵活的迷你 DSL + 结构化过滤器的组合是该平台独有的。在别处复现它需要把四到六家供应商 — 公司画像数据、sales-nav 搜索、列表构建、数据增强、融资情报 — 拼接成一条在每一层都按记录计价的管道。
对于那些希望拥有自己 ICP 定义而不是从供应商那里继承一个的销售团队来说,SQL 风格的发现端点就是关键所在:编写你自己的评分规则,在数秒内对底层数据库运行它,并且只为通过你过滤器存活下来的那些行付费。