为什么 Apollo 应该是你的第一次数据采集，而不是 Clay
没人谈论的瓶颈
每条 GTM 管道的起点都一样。你需要找到人。特定公司里、特定职位的特定人选。对大多数团队来说，这一步仍然是手动的。打开 LinkedIn Sales Navigator，滚动、点击、导出、导入，然后开始做数据补全。
下游的工作反而得到了所有关注。补全瀑布流、ICP 评分、邮件个性化、CRM 路由。这些步骤总是被优先自动化，因为它们感觉像是"难的部分"。
其实不是。真正难的部分是数据采集。从2.75亿人中找到对的500个人。而大多数团队仍然在手动做这件事。
为什么先用 Apollo
Apollo 拥有 B2B SaaS 领域最丰富的人员数据库。2.75亿+联系人。7300万+公司。已验证的邮箱。直拨电话。职级层级。公司技术栈。而且 API 每月前10,000个积分是免费的。
这改变了整条管道的经济模型。
老方法是这样的：打开 Apollo 的浏览器界面，跑一次搜索，导出 CSV，导入到 Clay，跑补全瀑布流，推送到 CRM。在外呼开始之前就有四个手动步骤。
新方法：一次 API 调用返回结构化的 JSON，包含人员和公司数据。脚本写入 Supabase。补全只对增量数据运行。CRM 同步自动发生。数据采集这一步从30分钟的点击操作变成了一次 API 调用。而且它跑在 cron 上，不在你的日历上。
Apollo 不是要替代 Clay。它们解决不同的问题。Apollo 处理人员搜索。Clay 处理补全和路由。Supabase 处理存储。每个工具各司其职。
两条路线
根据你的技术水平，有两种方式来构建这套系统。
黑客路线适合想要完全掌控的技术型操盘手。用 Supabase 做数据仓库。用 Apollo API 做采集。用 Claude Code 编写和迭代脚本。用一台 Mac Mini（或任何常开机器）跑 cron 定时任务。
每月总成本：Apollo 免费层（$0）+ Supabase 免费层（$0）+ 电费（约 $5）。代码在你的代码仓库里。数据在你的数据库里。管道在你睡觉时运行。
这里批处理模式很重要。永远不要一次性搜索 Apollo 的所有数据。按人物画像分批。先搜 VP/Marketing 总监。再搜销售。再搜 RevOps。每批都有自己的职位过滤器和对现有联系人的去重检查。这样可以避免积分浪费，从一开始就保持数据整洁。
SDR 赋能路线适合没有 GTM 工程师的团队。用 Claude Co-work 配合文件夹系统。三个文件夹：原始数据（Apollo CSV 导出）、调研（公司简报、技术栈分析）、产出（破冰话术、邮件序列、CRM 导入文件）。
把 Apollo 导出的文件放到原始数据文件夹。让 Claude 研究每家公司。让 Claude 根据职位和公司调研生成破冰话术。产出是一份可以直接导入 CRM 的 CSV。整个流程50个联系人只需10分钟。一个 SDR 手动做同样的事要花2-3个小时。
职位泄漏问题
如果不尽早解决，有一件事会毁掉你的管道质量：职位泄漏。你搜索"VP of Marketing"，结果拿回来的是 HR 负责人、营销科技公司的工程经理，以及 LinkedIn 标题里带"Marketing"的实习生。
Apollo 的职级过滤器有帮助，但不够。你需要一套允许列表/阻止列表模式。职位必须包含某些字符串（"marketing"、"growth"、"demand gen"）。职位必须不包含其他字符串（"intern"、"assistant"、"HR"、"recruiter"、"engineering"）。
先跑允许列表，再跑阻止列表。记录被过滤掉的数据，这样你可以随时间调优列表。把列表放在配置文件里，不要硬编码。这样非技术团队成员也可以调整目标定位，而不用碰采集脚本。
基础设施
整套系统跑在一台 Mac Mini 上。常开机。一次性 $599，每月电费 $5。如果你能给远程员工寄一台 MacBook，你就能跑一台常开的 GTM 服务器。
cron 每晚运行。从 Apollo 拉取新联系人。职位过滤。对 Supabase 去重。插入新联系人。对增量数据跑补全。同步到 CRM。等你早上坐下来的时候，管道里已经有新的合格联系人等着你了。
Mac Mini 不是重点。重点是基础设施足够简单，一台机器就能搞定一切。没有云编排。没有 Kubernetes。没有随用量增长的月度 SaaS 账单。就是一台机器按计划运行脚本。
会议获客
这就是这套架构真正发挥价值的地方。一个中型 SaaS 会议有500到2000名参会者。参会者名单在活动前2-4周公布。大多数销售团队手动筛选20-30个人就放弃了。
把整份名单跑一遍 Apollo。按姓名+公司匹配。职位过滤。ICP 评分。对结果分层：Tier 1（必须见面，安排会前会议）、Tier 2（在会场找到他们）、Tier 3（扫描胸牌后续跟进）。
从一场800人的会议中：Apollo 匹配了620人（77%匹配率）。职位过滤通过了340人。ICP 评分产出了85个 Tier 1、120个 Tier 2、135个 Tier 3。会前外呼在活动开始前预约了12场会议。总管道产出：是该团队上次用手动筛选在会议上产出的3倍。
深入了解
theGTMOS.ai 上的 Apollo Wiki 有完整的拆解。API 架构、职位过滤模式、Supabase 数据仓库 schema，以及两条路线的分步工作流。四个类别中的八个条目。全部来自生产环境的管道模式。
人员搜索是第一步。它应该最先被自动化，而不是最后。