# GTM 工程实战手册 与 _从定义目标客户画像（ICP），一直讲到如何安全地、成规模地推广自动化。_ _从 GTM 工程师在实际工作中遇到的痛点切入，提供**具体的解决方案、一条可以直接交给 agent 执行的提示词，以及必须遵守的关键原则**。所有涉及数据的实操章节，均附有我们亲自执行后得到的真实结果，并以同一目标客户画像为基准展开，确保不同章节的数据可以相互对照。侧重方法与流程的章节，则统一标注为 *Method*。_ _新增三项原创研究：联系人跳槽后的信息变化、招聘能否预测企业的下一轮融资，以及找到潜在客户与确认其联系方式可正常送达之间的差距。_ - **16** — 章 + 4 篇附录 - **6** — 同一个目标客户画像上的实测运行 - **3521 积分** — 全部运行的按量计费合计 - **502** — 累计调用记录 ## 什么是 GTM 工程？ GTM 工程（GTM engineering）指的是设计、搭建并维护一整套系统，使销售与市场团队能够把进入市场（go-to-market）的策略转化为可重复执行的工作流。典型场景包括目标客户圈选、线索补全、评分、信号监控、调研与入站线索分流。GTM 工程师负责打通数据与工具，验证这些工作流是否有效，并衡量它们对销售管道产生的实际影响。这项工作常与 RevOps、销售运营及工程团队交叠。本手册讲的是如何借助 鹦鹉AI 搭建这些工作流，并在任何对外消息发出之前保留人工审核。 与 RevOps 的区别见 FAQ；关于这项工作本身，按顺序阅读下面的 16 章 即可。 ## 以下为 2026 年 9 月 23 日那次线索名单实测的简化回放（第 5、8、11 章）。公司行仅为示意，数量取自那次运行的真实读数。1631.01 积分 的总价还包含两段未在画面中呈现的步骤：一次新闻查询（588 积分）与开场句评分。 ```text 列出 50 家美国软件公司：员工 51–200 人，已完成 A 轮融资。 ``` ```text 在查找联系人之前，先用名单已有的字段逐家对照我的目标客户画像，低于 50% 的直接淘汰。 ``` ```text 对通过的行，查找市场负责人并验证其工作邮箱。 ``` **companies.search** — 50 行 · 0 积分 美国 · 51–200 人 · 软件 · A 轮 - northwindlabs.com — 已列出 - greyharbor.io — 已列出 - fielderhq.com — 已列出 - loomwork.co — 已列出 - parallel.dev — 已列出 - arborline.io — 已列出 - halcyon.app — 已列出 - meridiansoft.com — 已列出 **icp.check** — 27 / 48 通过 匹配度 ≥ 50% · 仅使用名单字段 - northwindlabs.com — 通过 78% - greyharbor.io — 通过 64% - fielderhq.com — 淘汰 41% - loomwork.co — 通过 57% - parallel.dev — 淘汰 33% - arborline.io — 通过 69% - halcyon.app — 淘汰 22% - meridiansoft.com — 通过 61% **people.find** — 1631.01 积分 · 20 个已验证 市场负责人 · 经路由调用 · 成本最低优先 - northwindlabs.com — 已验证 - greyharbor.io — 已验证 - loomwork.co — 未知 - arborline.io — 已验证 - meridiansoft.com — 已验证 ## 下面哪一条像你这周的写照？ 我们阅读了 460 条讨论 GTM 工程的 Reddit 帖子与 1,456 条 LinkedIn 动态，其中的问题最终归纳为以下九类症状。勾选你遇到的症状，手册会给出对应的章节起点。 - [ ] **补全账单总是一次次超出你的预期。**「每一步补全都会照样烧掉 Actions。」—— r/gtmengineering → #ch5, #ch2 - [ ] **针对你的市场，拉回来的名单总是很单薄。**「平均每家公司只能拿到 0.5 个联系人。」—— r/RevOps → #ch7, #ch1 - [ ] **退信太多，或者所谓「有效」其实是全收域名（catch-all）。**「被我们标成『有效』的联系人，有一半其实是全收域名。」—— r/gtmengineering → #ch8 - [ ] **销售根本不看意向数据或信号流。**「意向数据对销售来说，基本等同于占星术。」—— r/sales → #ch9, #ch10 - [ ] **外发内容一看就是模板，回复寥寥。**「在庆祝发完一万封之前，能不能先挑十封念出来听听？」—— LinkedIn → #ch11 - [ ] **每个客户只联系一个人，而这个人并不是真正买单的人。** → #ch6 - [ ] **没有人能说清 agent 到底被允许自主做哪些事。**「就问一句：它做错了谁负责？」—— r/ClaudeCode → #ch3, #ch16 - [ ] **你说不清销售管道来自哪份名单、哪个信号、哪家供应商。**「CRO 现在要求按供应商核算 ROI。」—— r/RevOps → #ch14, #ch15 - [ ] **自动化停了，你几天后才发现。**「我们通常要过几天才能发现。」—— r/RevOps → #ch16 ## 第 0 章 · 起步 · 什么是 GTM 工程师？2026 年需要哪些工具与数据供应商？ **GTM 工程师负责把一家公司的销售与市场打法，转化为一套每周自动运转的系统：**将目标客户画像写成可筛选的条件，建立名单并补全数据，识别「现在应当联系谁」的信号，为每一条开场句做调研，分流入站线索，并确保消息在发出之前经人确认。GTM 工程是这门实践，GTM 工程师则是为它负责的人。这个岗位处在 RevOps、销售与工程之间。2026 年的变化在于它运行的位置：越来越多的工作在 鹦鹉AI 里运行——你用一段提示词描述任务，由它发起调用。 #### GTM 工程师的一周 1. **将目标客户画像写成文档**：依据团队真正赢下并留住的客户，写成供应商可筛选的字段（第 1 章）。 2. **以低成本方式建立名单、补全数据**：先用名单已有字段判断资格，只对通过判断的行投入费用，查找联系人、获取邮箱并加以验证（第 4 到 8 章）。 3. **关注时机**：招聘、融资、跳槽、发帖，每一类信号都需要附带链接与日期，再与匹配度一并评分（第 9、10 章）。 4. **把「写信的理由」交给销售**，连同出处一并交付，发送键始终留在人手里（第 11 章）。 5. **让数据保持可信**：发送前完成验证，刚跳槽的人重新核对，任何时机信号在获得权重之前先经过测试。我们的跳槽研究解释了其中的原因。 6. **衡量并推广**：为每一行打上标记，使销售管道能够追溯到某份名单、某个信号、某家供应商；自动化一次只放开一步（第 14 到 16 章）。 #### GTM 工程师、RevOps 还是销售运营？ 头衔在不同公司各不相同，职责也互相重叠，许多团队中 GTM 工程师就隶属于 RevOps。就本手册关注的销售管道工作而言，以下划分较为实用： | 角色 | 主要职责 | 衡量方式 | | --- | --- | --- | | **GTM 工程师** | 自动化工作流：名单构建、数据补全、评分、信号识别、线索分流与外发前调研 | 每小时、每花一美元数据成本，能产出多少合格销售管道 | | **RevOps** | 跨团队的营收流程、系统、规划、数据治理与报表 | 数据质量、预测准确性、营收效率 | | **销售运营 / 市场运营** | 工具管理、触达序列、营销活动与线索交接 | 工具正常运转、线索落到合适的销售手中 | | **SDR** | 对话：首次触达、跟进、约会议 | 约到的会议 | 在小团队中，一个人往往身兼数职。总体的分工是：RevOps 决定营收系统如何运转，GTM 工程师负责把其中可以自动化的部分构建出来。 #### GTM 工程在什么时候有用，需要哪些能力 只要目标客户画像能够写得下来，并且有人每周都在重复同样的调研，本手册中的工作流就会开始产生回报。小型工作流可以由团队现有成员兼任；当工作量与价值都足够时，才值得设立专职岗位。归根结底，这些技能与其说靠写代码，不如说靠精确： - **把规则写到机器能够执行的程度**：什么算合格、什么直接淘汰、agent 可以独立完成哪些动作。 - **数据判断力**：关注「每个正确结果多少钱」，而不是「每行多少钱」，并且清楚哪些字段会过期（找到不等于可送达）。 - **先测试再信任**：一个时机信号只有能够区分你自己的赢单与输单，才值得被赋予权重（我们的测试）。 - **足够的销售直觉**：当 agent 给出一个薄弱的写信理由时，你能一眼看出。 - **愿意与 agent、命令行和表格打交道**：agent 负责发起调用时，几乎不需要写代码。 整套技术栈由五层构成，其中只有一层是 鹦鹉AI。 - **Agent** — 鹦鹉AI，它规划步骤、发起调用。 - **数据层 · 鹦鹉AI** — 公司与人物搜索、数据补全、邮箱查找与验证、招聘、融资与新闻、社媒帖子、SEO 与广告数据。按调用计费；如果你已有供应商 key，则优先使用你自己的 key。 - **技能（Skills）** — 把方法写成文档：如何判断资格、如何写开场句、如何评分。开源技能见附录 A。 - **发送** — 你的邮箱与触达序列工具。不包含在本产品之内（第 12 章）。 - **CRM** — 结果存放于此，你才能从中学习（第 14 章）。 **在你的 agent 里设置一次** ```text set up 鹦鹉AI — https://parrot.amorist.cn/llms.txt ``` - [数据目录](/data#catalog) - [设置 鹦鹉AI](/access/mcp) - [文档](/docs) ## 第一部分 · 先定义，再动手 后续每一章都建立在这三个决定之上。跳过它们，agent 只会又快又错。 ### 第 1 章 · 目标客户画像 · 把目标客户画像写成供应商可筛选的字段 > 你的目标客户画像只是 PPT 里的一句话（「重视数据的中型 B2B 公司」），于是每一份名单都成了对这句话的另一种解读。 agent 无法搜索「重视数据」这类描述。它可以搜索的是国家、员工人数区间、品类、融资情况与技术栈。凡是无法转化为这些字段的内容，都只能成为 agent 取得行数据之后逐行执行的*检查*（第 5 章），而不能作为筛选条件。 1. 将目标客户画像拆分为**筛选条件**（供应商已建立索引的字段）与**检查**（对每一行的判断）。 2. 把采购方写成一个职能（「市场或增长」）而不是一个头衔，这样第 6 章才搜得到。 3. 把排除项写清楚：代理公司、消费级应用、已经被收购的公司。 **工作表 · icp.md** ```text ICP: the one we ran this playbook on filters country = US · employees = 51-200 · category = B2B and SaaS checks sells to sales, marketing, revenue or growth teams, or runs outbound itself would buy lead data, enrichment or prospecting APIs buyer function = marketing or growth (Head of Marketing, Head of Growth) exclude agencies, services firms, consumer apps, hardware, acquired companies ``` **prompt** ```text Using 鹦鹉AI, turn the ICP in icp.md into filters for two company-search providers. Use their free count endpoints only. For each provider show the exact filter object and the count it returns. Do not return any rows yet. ``` > ****规则** 目标客户画像中任何无法成为筛选条件的部分，都是一条检查，并且必须在任何产生费用的步骤之前执行。** - [面向 agent 的公司调研](/use-cases/company-research-for-ai-agents) - [公司数据供应商](/data#catalog) ### 第 2 章 · 市场规模 · 先免费数清市场，再为第一行付钱 > 你买下一份名单，之后才发现那个筛选条件在供应商那里的含义完全不同。 多家供应商都提供免费计数接口。先做这件事，并且至少用两家：同一个目标客户画像，按各家口径分别统计一次，得到的市场规模可能相差很远。 **一份目标客户画像，八个计数 · 美国，51–200 人** - CompanyEnrich：B2B + SaaS — 10,403 - CompanyEnrich：B2B + SaaS，2024 年后融资 — 1,357 - CompanyEnrich：B2B + SaaS，融资轮次 = series_a — 25 - Dropleads：「IT & Services」 — 15,873 - Dropleads：关键词「saas」 — 5,395 - Dropleads：「Computer Software」 — 21 - Apollo：A 轮筛选（付费页，9 月 23 日） — 958 _2026 年 9 月 30 日记录。八项计数均为免费（图中绘制了六项，另外两项相邻人数区间列于下方）；Apollo 的数字来自 9 月 23 日付费页面的第一页（18.2 积分）。CompanyEnrich 的每一行都是在第一行基础上追加一个条件，而非层层叠加。它的相邻人数区间：11–50 人 42,981 家，201–500 人 2,621 家。一个 `series_a` 这样的标签，或一个行业标签，就能在不经意间把市场缩小 400 倍。_ 1. 在两家供应商上各统计一遍。相差 2 倍属正常；相差 100 倍，说明某个筛选条件并没有在做你以为的事。 2. 从每家获取 10 行样本（费用很低），看过之后再决定采信哪个数字。 3. 把相邻人数区间也统计一遍。你真正的市场往往就在相邻的那一档。 **prompt** ```text Using 鹦鹉AI's free company-count endpoints, count my ICP on two providers and in the headcount bands either side of it. Show every filter you used. If two counts differ by more than 3x, tell me which filter is likely wrong before we pay for anything. ``` > ****规则** 在两个免费计数大致吻合、十行样本检查无误之前，不购买任何名单。** **鹦鹉AI 负责.** 多家供应商的免费计数接口，都在同一份目录里。 **你决定.** 读完样本之后，哪种口径最贴近你的市场。 - [公司数据供应商](/data#catalog) - [公司调研](/use-cases/company-research-for-ai-agents) ### 第 3 章 · 规则 · 把 agent 需要遵守的规则写下来，并写清谁有权叫停 > agent 会大批量地执行没有人会逐条批准的操作。「什么样的线索才算够好？什么证据能让它往前走？Claude 什么时候可以动手？」—— LinkedIn 指令里没写死的地方，agent 就会照着批量执行。写下来的规则仍然只是指令，并不构成保证，因此还需要一个数字、一份日志和一个负责人。 **门槛是一个业务决定** - 按 50% 门槛通过 — 27 - 按 60% 门槛则会通过 — 14 _9 月 23 日运行中的 48 家公司。门槛提高十个百分点，名单大致减半。_ **工作表 · rules.md** ```text icp_check pass if fit >= 0.5, judged on the fields the row already has (one cheap enrichment first if it has too few) people, email and news steps only on rows that passed icp_check drops log every dropped row with its reason email send only to verifier = deliverable; unknown and catch-all go to a separate list first_line a person approves every first line before a sequence starts spend_cap stop and ask if a run will cost more than 3500 积分 owner can pause every sequence with one command ``` > ****规则** 每个门槛都是提示词里的一个数字，每次淘汰都要附带理由，叫停权只归一个人。** - [这些门槛来自哪次运行](/workflows/find-and-verify-a-lead-list) ## 第二部分 · 把名单建起来 GTM 工程师如何借助 鹦鹉AI 建立名单、补全数据：先获取候选，用已有字段完成判断，只在能够产生回报的环节发起昂贵的查询。 ### 第 4 章 · 相似公司 · 最佳客户的相似公司是候选，不是线索 > 相似公司的种子取自你最好的客户，名单看起来正合目标，于是资格判断被整个跳过。 我们以 9 月 23 日运行中匹配度最高的三家客户公司作为种子，各获取 25 家同国家的相似公司，全部补全，再执行一遍与第 5 章相同的画像检查。 71 家相似公司，8 家通过画像检查 _2026 年 9 月 30 日记录。相似公司来自 Findymail；补全通过公司补全的路由调用完成（71 家 140 积分，由四家供应商按最便宜优先应答）。相似公司返回的字段太少，不足以判断，因此先执行一次低价补全，再运行检查。检查由 jev 在团队自己的 key 上执行，按 50% 判定匹配度；它不限制人数，8 个通过的行中有 3 个不在 51–200 人区间。_ - **71** — 个去重后的相似公司，来自 3 个种子，4.2 积分 - **13** — 家落在 51–200 人区间；53 家不超过 50 人 - **8** — 家通过模型检查（11%）；其中仅 5 家落在 51–200 人区间 1. 以 3 到 5 个真正成交过的客户作为种子，而不是你希望争取到的 logo 客户。 2. 如果供应商支持，用国家与规模约束相似公司；我们只约束了国家，结果大多是规模更小的公司。 3. 先执行一次低价补全，让行上有可供判断的字段；然后照常执行人数筛选，并运行与其他名单相同的检查。 **prompt** ```text Using 鹦鹉AI, find 25 lookalikes for each of these customer domains, same country and same size band. Enrich each lookalike, then run my ICP check from rules.md on it. Return only the ones that pass, with the reason each failed one was dropped. ``` > ****规则** 相似公司也要像其他行一样，通过同一道人数筛选与同一道画像检查。** - [公司调研](/use-cases/company-research-for-ai-agents) - [公司数据供应商](/data#catalog) ### 第 5 章 · 成本 · 在任何昂贵查询之前，先用已有字段做资格判断 > 积分消耗快于预期，因为找人、验证、新闻这些调用在每一行上都会执行。「我很少做全量补全。」—— r/gtmengineering - 列出的公司 — 50 - 可用域名 — 48 - 通过画像检查 — 27 - 付钱之前就淘汰 — 21 - 已验证可送达 — 20 _2026 年 9 月 23 日运行。检查由 jev 在免费名单字段上执行，阈值 50%，使用团队自己的 key。2884 积分 是在实际计费的基础上，再加上本次运行自己对 21 个被淘汰行的估算（1253 积分）；这些行从未做过补全。[提示词、步骤与 CSV](/workflows/find-and-verify-a-lead-list)。_ - ≈ 2884 积分 — 若将 48 家全部补全的估算 - 1631.01 积分 — 按量计费 · 每个可送达线索 84 积分 1. 用名单已带的字段判断每一行：描述、行业、规模、融资。 2. 淘汰未通过的行，并将理由记录在旁。 3. 只在通过判断的行上执行找人、验证与新闻查询；如果你已有付费供应商，优先使用你自己的 key。 **prompt** ```text Using 鹦鹉AI, list 50 US software companies with 51 to 200 staff that raised a Series A. Before you find anyone, judge each company against my ICP from the list fields alone, drop anything below 50%, and show me the price of every paid step before you run it. ``` > ****规则** 未通过检查的行，不执行任何昂贵查询（人物、邮箱、新闻）。如果一行缺少判断所需的字段，先执行一次低成本的补全。** **鹦鹉AI 负责.** 每一步执行之前先标价，按调用计费；你自己的 key 优先，且不经过平台计费。 **你决定.** 检查的标准是什么。agent 负责执行；它无法替你凭空定义目标客户画像。 - [线索名单的完整运行记录](/workflows/find-and-verify-a-lead-list) - [线索补全](/use-cases/lead-enrichment-for-ai-agents) - [数据目录](/data#catalog) ### 第 6 章 · 采购决策团队 · 哪些人物搜索 API 可以在 AI agent 中使用？按职能搜索，不要搜索「决策人」 > 每个客户只给一位高管发送邮件，而对方往往并不是真正购买你产品的人。 在通过第 5 章筛选的 8 家客户公司中，我们先向一个「决策人」接口索取采购决策团队名单，再直接按采购职能执行人物搜索的路由调用。 **「决策人」在 5 家客户公司中返回了 45 位高管** - 销售、营收、合作 — 10 - 运营、战略、幕僚长 — 7 - 产品、工程、设计 — 6 - 客户成功、支持 — 5 - 人力与 HR — 5 - 财务 — 4 - 创始人与助理 — 4 - 增长（无「市场」头衔） — 1 _2026 年 9 月 30 日记录，头衔由人工映射到职能；3 个头衔过于含糊无法归类，没有任何头衔包含「marketing」。一个采购决策团队接口（Lusha）当天在我们的 key 上服务容量已满，未产生费用。按职能搜索走人物搜索的路由调用，`title: marketing`，最多 3 行、每次调用 140 积分；QuickEnrich 应答了 7 家，Dropleads 应答了 1 家。联系方式是独立的付费步骤（第 8 章）。_ - **3 / 8** — 家客户公司在决策人接口被限流（429） - **8 / 8** — 家客户公司按职能搜索都返回了市场人员 - **20** — 位人物，含姓名与头衔，计量 0 积分 1. 自行绘制采购决策团队：谁付费、谁担任内部推动者、谁使用。每个人写成一个职能。 2. 按这些职能逐个搜索每家公司，先查看成本最低的行，再在每个职能中挑选资历最高的人。 3. 只对真正要写信的人揭示联系方式。 **prompt** ```text Using 鹦鹉AI, for each passed account search people by company domain with title "marketing" and then "growth", at most 3 rows each and $0.20 per call. Return name, title and a seniority guess. Do not reveal emails yet. ``` > ****规则** 按采购职能搜索。一份「决策人」名单是这家公司的组织架构图，而不是你的采购决策团队。** **鹦鹉AI 负责.** 人物搜索的路由调用：从成本最低的供应商开始尝试，并告知最终由谁应答。 **你决定.** 谁在你的采购决策团队里。没有任何接口知道你卖的是什么。 - [用 鹦鹉AI 进行人物搜索](/people-search) - [人物数据供应商](/data#catalog) ### 第 7 章 · 覆盖率与成本 · 在 AI agent 中做瀑布式邮箱补全，怎样花得最少 > 在别处表现良好的供应商，可能漏掉你半个市场，而单行报价把这件事掩盖了。「现在一半的邮件都退信。」—— r/gtmengineering 覆盖率取决于客群，唯一可靠的测试只能在自己的行上完成。真正应当关注的是**每个正确结果的成本**——一个单价便宜却遗漏较多的供应商，实际上很贵。 **每个正确工作邮箱的成本 · 同样 292 人** - 鹦鹉AI — 3.92 积分 - Clay — 27.65 积分 - Freckle — 29.89 积分 - Deepline — 64.68 积分 _2026 年 9 月 16 日，88 家公司，仅提供姓名与域名。完全匹配率非常接近：我们 90.4%，Freckle 90.1%，Clay 89.7%，Deepline 86.6%。每个人都有公开的团队页邮箱，因此找到率高于冷名单。[方法与表格](/blog/work-email-finding-bench)。_ 1. 从真实名单中取 20 到 50 行，运行邮箱查找的路由调用（从成本最低的供应商开始尝试；按成功计费的供应商，未找到不计费）。 2. 记录每个邮箱由哪家供应商找到，比较「每个正确结果」的成本，而不是单行价格。 3. 更换供应商之前，先把头衔范围放宽一档；结果太少，往往是一个头衔筛选造成的。 **prompt** ```text Using 鹦鹉AI, find work emails for these 30 people with the routed email finder, then verify each one. Report found, verified and cost per verified email, and which provider found each address. ``` > ****规则** 按客群、用你自己的行测出应当使用哪家供应商；客群发生变化就重新测试。** **鹦鹉AI 负责.** 把同一件事的全部供应商放进同一份目录，并提供路由接口：从成本最低的开始尝试，并告知最终由谁应答。 **你决定.** 哪个供应商在你的客群上胜出。目录负责对比，agent 负责选择。 - [292 人基准测试](/blog/work-email-finding-bench) - [邮箱供应商](/data#catalog) ### 第 8 章 · 送达率 · 先找，再验证，并把「未知」单独放 > 查找器返回的「有效」，实际上意味着这个域名什么都接收；退信最终记在你的发信域名上。「我们标成『有效』的联系人，有一半其实是全收域名。」—— r/gtmengineering 20 个可送达 · 1 个未知，单独放置 · 0 个无效 · 6 个未被任一查找器找到 _27 个有名有姓的人：找到 21 个邮箱（Hunter 找到 18 个，Kitt 在 Hunter 遗漏的里补充了 3 个），然后逐个验证。第三个查找器 Tomba 当天服务容量已满。验证器没有在任何一行返回全收域名标记。[回执](/workflows/find-and-verify-a-lead-list)。_ 上述公司先通过了匹配度检查。另一份仅按头衔搜索构建的样本中，「找到」与「可送达」之间的差距要大得多。我们让邮箱查找的路由调用为每个人查找邮箱，再把返回的每个地址逐一验证。 32 个可送达 · 16 个有风险 · 4 个未知 · 8 个无效 _研究 · 由头衔搜索得到的 60 人：每个邮箱都「找到」了，大约一半可送达。_ - **60 / 60** — 位人物都从查找器获得了一个地址 - **53%** — 的地址验证为可送达 - **455 积分** — 整个研究按量计费，含实时检查 _研究于 2026 年 10 月 7 日执行。方法：从六组美国头衔搜索中取 60 人，覆盖销售、市场、增长、营收运营与 GTM 工程，每组最多十人，不限行业。邮箱查找的路由调用在每一行上执行，再对每个地址执行验证的路由调用。「可送达」是验证器给出的结论，并非实测的收件箱投递结果。在 24 个能够读到可用实时档案的人中，22 人确实在名单上的公司任职；另外 36 人无从核对。结果因客群而异，请在你自己的行上运行。_ 1. 把验证作为独立步骤，将结论与地址一并存储。「找到」只代表查找器返回了一个地址；上述头衔搜索样本中，53% 的已找到地址验证为可送达。 2. 只向可送达的地址发信。未知与全收域名放入一份更小、节奏更慢的名单，或者完全不发。全收域名字段为空只意味着未知，并不等于安全。 3. 按发信域名监控退信与投诉。 > ****规则** 只有验证为可送达的地址，才能进入主触达序列。** **鹦鹉AI 负责.** 把查找与验证拆成两次独立调用，返回验证结论，以及验证器能够给出的全收域名标记。 **非本产品.** 收件箱、预热与发信额度。 - [线索补全](/use-cases/lead-enrichment-for-ai-agents) - [验证与查找供应商](/data#catalog) ## 第三部分 · 知道什么时候该联系 如何用 AI agent 搭建基于信号的主动触达：信号必须可核对，评分则把信号与匹配度合在一起。 ### 第 9 章 · 信号 · 怎样搭建基于信号的主动触达：只用能打开、能标日期的信号 > 团队有信号流，但是没有人行动。「又一条所有人都无视的告警流？」—— r/sales 意向分无法核实，销售自然会对它打折扣。一条招聘帖、一次入职、一份融资公告、一篇正好讨论这个问题的帖子——这些都能打开查看、标注日期，也能引用到开场句里。 - **16 / 27** — 家客户有过去 60 天发布或首次出现、目前仍在招的销售、市场或增长岗位 - **355 / 675** — 条返回的招聘帖已经关闭 - **0 / 27** — 家客户在最近 12 个月内有融资供应商查到的融资记录 _2026 年 9 月 30 日记录，对象是通过第 5 章检查的 27 家客户公司。岗位数据来自招聘搜索的路由调用（由 PredictLeads 应答，每次调用 28.01 积分，每个客户最多 25 条）；融资来自 Aviato（每次调用 7.01 积分；27 家中有 26 家有融资记录，最近一条仅到 2025 年 5 月）。两项检查合计 945.01 积分。仍在开放的招聘是有效信号；融资数据对这份名单已经过时。_ **线索信号技能里，一行长这样** ```text person Head of Growth, signal posted 3 SDR roles in the last 30 days why_now building outbound now; the list will need data source https://…/careers/sdr email found and verified, or blank ``` #### 跳槽：大多数联系人记录还没有显示新工作 一位内部推动者跳槽，是最好的写信理由之一。问题出在数据上：跳槽后的最初几周，我们核对的大多数存量记录都没有显示新公司。结果邮件可能发往一个他不再查看的邮箱，开场句还写错了公司。 **研究 · 148 位在 1 到 29 天前公布新工作的人** - 单一数据库 — 68% - 两家都收录的人 — 64% - 实时读取 — 4% _「找到的记录中没有显示新雇主」的比例。「两家都收录的人」只统计两家数据库都收录的人——在这些记录中，两家都没有对上。_ - **72%** — 的人跳槽三到四周后，记录仍未显示新工作（第一周是 61%） - **84 / 139** — 位被数据库收录的人中，没有一家数据库显示其新工作 - **1 / 3** — 的人能被实时档案读取找到 _研究于 2026 年 10 月 7 日执行。方法：取 1 到 29 天前（中位数约 13 天）发帖宣布新工作的人，将每条帖子作为标准答案。每个人按 LinkedIn 链接在五个联系人数据库中各查询一次，并执行一次实时档案读取，将各家返回的公司与帖子中公布的公司进行名称比对。68% 是五个数据库比例的平均值；64% 指的是两家数据库都收录的人里、两家同时漏掉的比率；只看单独一家时，漏报率是 69%。人工抽查 40 条不匹配记录，每一条都指向另一个组织，而不是新公司的拼写差异；少数可能是与新工作并行的兼职。按周分组比较的是不同的人，而不是同一批记录随时间的变化。实时读取来自本人维护的那份档案，因此它一致的部分在预期之内；它在 148 人中找到了 49 人。这里所有人都公开了变动，未公开者的结果可能不同。数据库不具名，结果会因数据库与客群而异。_ 1. 只保留带来源链接与日期的信号，去掉已经关闭的招聘：返回的招聘帖中，超过一半已经关闭。 2. 为每条信号写一行「为什么是现在」。写不出来，它就是噪音。 3. 遇到跳槽时，先用实时档案读取确认新公司，再执行其他操作。第二家数据库帮助有限：在两家都收录的人中，仍有 64% 被两家同时遗漏。 4. 为信号流指定一位负责人，在固定的一天集中分诊。 **prompt：实时核对跳槽** ```text Using 鹦鹉AI, for each person in job-changes.csv read their live LinkedIn profile and return current company, title and start date. Compare with the company in our CRM and flag every mismatch. For mismatches only, find and verify an email at the new company. Show the cost before you start. ``` > ****规则** 没有来源链接，就不构成信号。写不出「为什么是现在」，就不触达。** - [用 鹦鹉AI 识别线索信号](/leads-signals) - [实时档案读取](/people-search) - [信号供应商](/data#catalog) ### 第 10 章 · 优先级 · 把匹配度与时机放在一起评分，先处理 A 档 > 名单上的每家客户公司都在同一天收到同一套触达序列，无论对方那边是否有动静。 **27 家客户，各自归入一档** - A · 匹配度 ≥ 60% 且 2 个以上开放 GTM 岗位 — 8 - B · 至少 1 个开放 GTM 岗位 — 8 - C · 目前没有开放岗位 — 11 _2026 年 9 月 30 日记录。匹配度是第 5 章算出的画像匹配分（这些客户的匹配度在 50% 到 67%）；时机是过去 60 天发布或首次出现的开放 GTM 岗位。A 档本周就安排人员、撰写开场句；C 档等待信号。_ 时机信号在被赋予权重之前都值得怀疑。我们测试了一个流行的说法：能否从创业公司的招聘或新闻中，提前看出它的下一轮融资？结论是招聘无法区分两者，新闻反而指向相反方向。 | 信号 | 后续完成融资 | 未找到融资 | | --- | --- | --- | | 开放了一个 GTM 岗位 | 30% | 24% | | 开放了两个以上 GTM 岗位 | 19% | 15% | | 开放了任何岗位 | 47% | 48% | | 开放了高级岗位 | 18% | 19% | | 招聘加速 | 25% | 22% | | 出现在新闻里 | 26% | 54% | 研究 · 参考日期之前出现过什么：完成融资的创业公司 vs. 未找到融资的创业公司。 研究于 2026 年 10 月 6 日执行。方法：57 家美国创业公司在 2026 年 8 月中至 10 月初之间公布了种子轮到 B 轮融资（参考日期：公告日），与相似的创业公司对比——后者的最后一轮在 2025 年，我们的数据源没有显示其在 2026 年有融资（参考日期：公告日中位数）。这 61 家里有 54 家有任何招聘或新闻数据。招聘按首次出现日期（缺失时使用发布日）、新闻按发现日期，取参考日期前 90 到 7 天；最后一周剔除，以免融资本身被计入。GTM 岗位覆盖销售、市场、增长、营收运营、商务拓展、合作与客户成功。「招聘加速」指有两条以上岗位，且数量多于此前 90 天。只有一个数据源、覆盖不完整、对照组也未做匹配：几个百分点的差距属于噪音，公司年龄与覆盖差异也可能解释新闻那一项，我们并未确定原因。这只说明我们没有找到招聘信号的证据，不能证明它不存在。 1. 把匹配度与时机保留为两个独立的数字。相乘只用于排序，绝不用于决策。 2. 用数字定义档位，并写进 rules.md。 3. 每周重新评分；时机信号会衰减，匹配度几乎不变。 4. 时机信号在获得权重之前，先在你自己的历史成交上验证：出现过该信号的赢单比例 vs. 输单比例。如果无法区分，就把它当作写信理由，而不是一个分数。融资这件事，看到公告就直接跟进。 **prompt** ```text Using 鹦鹉AI, for each passed account pull open jobs and funding rounds. Count sales, marketing and growth roles that are still open and were posted or first seen in the last 60 days. Tier A if fit >= 0.6 and 2+ such roles, B if 1+, else C. Show the tier, the roles and their links. ``` **prompt：用你自己的历史成交验证信号** ```text Using 鹦鹉AI, take wins.csv and losses.csv (domain and close date). For each account pull job postings and news from the 90 days before its close date. For each signal, report the share of wins and the share of losses that showed it, and tell me which signals separate them by more than 15 points. Show the cost before you start. ``` > ****规则** 本周只处理 A 档。C 档在信号将其提升之前，什么都不发送。** - [线索信号](/leads-signals) - [融资与招聘数据](/data#catalog) ## 第四部分 · 对外触达 agent 负责寻找写信的理由，由人判断这个理由是否足够好、是否可以发送。 ### 第 11 章 · 开场句 · 调研交给 agent，写信由人来做——至少也要由人批准 > 几千封邮件发出去了，回复却寥寥无几。「冷邮件读起来，总像机器人写的。」—— r/sales 19 条开场句被评分，4 条尚可或更好 _9 月 23 日运行中，19 家公司有过去一年的新闻事件。jev 按 0 到 3 分给每条开场句评分：19 条中有 4 条尚可或更好，平均 1.79。大多数现成的「个性化」，并不值得发送。_ 1. agent 收集写信的理由，并附上出处。 2. 在任何人动笔之前先给理由评分。薄弱的理由直接丢弃，不要打磨。 3. 由人撰写或批准开场句。触达序列上线前，先念十句出来听听。 > ****规则** 未经人阅读的内容，不发送。** **鹦鹉AI 负责.** 调研：新闻、招聘、帖子、公司数据，每一项都附带出处。 **非本产品.** 写信与发送。方法见附录 A中的冷邮件技能。 - [开场句评分的方法](/jev) - [公司调研](/use-cases/company-research-for-ai-agents) ### 第 12 章 · 发送与回复 · 发信基础设施与回复：从业者给出的建议 > 花在收件箱与回复分诊上的时间，比花在销售上的还多。「我在基础设施上花的时间比销售还多。」—— r/b2bmarketing #### 发送 收件箱、域名与预热属于你自己的发信工具。论坛上真正站得住脚的建议是：发送量要保守，按域名监控退信与投诉。「永远不要放链接」这类绝对规则却站不住脚。 #### 回复 将每条回复归类为有意向、异议、转介绍、休假自动回复；连同 agent 收集的上下文交给对应的销售，由人批准回复，再把结果写回该行（第 14 章）。 > ****规则** 回复在一个工作日内完成分流，每个结果都写回行上。** ## 第五部分 · 入站 主动上门的线索值得最快回应，而大多数分流只需要一次查询。 ### 第 13 章 · 入站分流 · 从邮箱域名补全入站线索，并在几秒内完成分流 > 一个演示申请积压在队列里，等待人工去查询这家公司。 工作邮箱能提供一个域名，而域名已经能提供分流所需的大部分信息。我们参照表单处理器的做法，补全了 20 个公司域名。 - **2.2 秒** — 补全新域名的中位耗时（p90 4.5 秒） - **37.1 积分** — 20 个新域名，每个 1.82 积分 - **约 1/5** — 的价格；同一域名重复查询时，耗时约减半 _2026 年 9 月 30 日记录，用公司补全的路由调用查询 20 个此前未查询过的域名；TheCompaniesAPI 应答 13 个，Hunter 5 个，Dropleads 2 个；最慢一次 4.8 秒。另一组 20 个已经补全过的域名，中位 1.15 秒，总计 7.7 积分。这里测量的是查询本身，而不是完整的分流流程。_ - 员工人数 — 20/20 - 所在地 — 20/20 - 行业 — 16/20 - 描述 — 13/20 1. 提交时即从邮箱域名补全公司，并把结果保存下来，重复查询永远无需支付全价。 2. 只用两三个你信得过的字段完成分流：人数区间、国家、行业。缺少字段的交给人工，不要丢进线索培育池。 3. A 档入站线索在一小时内回复；对方已经把时机告诉你了。 **来自表单处理器或你的 agent** ```text Using 鹦鹉AI, enrich acme.com from this inbound email domain. Return employee count, location, industry and description, then route it by our rules: 51-200 staff in the US and a software category goes to tier A. Show the cost first. ``` > ****规则** 每条入站线索在人打开它之前，就已经完成补全与分流。** - [公司调研](/use-cases/company-research-for-ai-agents) - [人物补全](/use-cases/lead-enrichment-for-ai-agents) - [补全供应商](/data#catalog) ## 第六部分 · 运营与改进 没有衡量的打法会逐渐失效。这三章让整套系统保持诚实。 ### 第 14 章 · 归因 · 给每一行打标，才说得清哪份名单、哪个信号、哪家供应商带来了回报 > 没有人能说清上个季度销售管道来自哪里。「哪些正面回复变成了商机？哪些会议没有成效，原因是什么？」—— LinkedIn 公司 · 域名 · 人物 · 头衔 · 邮箱 · 哪家供应商找到的 · 验证结论 · 全收域名标记 · 作为写信理由的那个事件 · 开场句分数 _9 月 23 日运行 CSV 的列。标绿的几列让事后与结果做关联成为可能。[下载它](/workflows/find-and-verify-a-lead-list)。_ 1. 每行都保存：来源名单、信号、找到邮箱的供应商、验证结论。 2. 每月将行与 CRM 中的回复、会议、赢单做关联。 3. 淘汰那些从未出现在关联后赢单一侧的来源与供应商。 > ****规则** 没有来源与供应商的行，不得进入触达序列。** **鹦鹉AI 负责.** 每次调用都会告知由哪家供应商应答、花费多少，agent 可以把这两项写回行上。 **非本产品.** 持久记录与 CRM 关联。供应商与结果需要留在你自己的行上。 - [下载打好标的 CSV](/workflows/find-and-verify-a-lead-list) ### 第 15 章 · 指标 · 指标分层：系统健康、业绩表现、效率 > 所有人唯一在追踪的数字，是「发了多少封」。 | 层 | 指标 | 我们的读数（来自实测运行） | | --- | --- | --- | | **系统健康** | 两个市场计数对得上；分流字段的补全填充率；验证可送达比例 | 一个筛选条件使计数相差 400 倍以上（第 2 章）；20 个分流字段中填到 16 到 20 个（第 13 章）；21 个邮箱中有 20 个可送达（第 8 章） | | **业绩表现** | 按来源、信号与档位分别看回复率、会议、商机 | 由你来量：需要第 14 章的标签 | | **效率** | 每个可用结果的成本；付钱前淘汰的行比例；入站首次触达耗时 | 每个可送达线索 84 积分；48 行里 21 行在付钱前淘汰（第 5 章）；补全新域名中位 2.2 秒（第 13 章） | > ****规则** 每周复盘这三层，一次只修改一条规则。** - [所有带回执的工作流](/workflows) ### 第 16 章 · 推广 · 像上线软件一样推广自动化：影子运行、小范围客群、人工把关，最后才是自主运行 > 一个自动化悄悄停止了，或者悄悄出错了，几天都没有人发现。「我们通常要过几天才能发现。」—— r/RevOps 1. **影子运行。** 让自动化打法与手工流程并行运行一周，逐行对比产出。 2. **小范围客群。** 先对一个客群或一位销售开放。 3. **人工把关。** 在错误率已知之前，每次发送都由人批准。 4. **自主运行**只授予已验证的步骤；开场句上的人审永远保留。 #### 我们自己实测时出过哪些问题 Tomba 服务容量已满（9 月 23 日） · Lusha 服务容量已满（9 月 30 日） · 3 个客户被限流（429） · 我们的解析器读错字段：重跑耗资 756 积分 _这些问题没有一个抛出错误、让运行停下来。每一个都会悄悄产出一份更薄的名单。路由接口会回退到下一家供应商；那 756 积分 是我们自己的 bug，能够抓出来是因为我们保存了原始响应并核对了计数。_ 1. 按每次运行、每个阶段的预期行数设置告警，而不是等待报错。 2. 把供应商原始响应保存一周，解析出错时可以修复，不必再次付费。 3. 为每次运行设置消费上限，超出后暂停并询问人。 > ****规则** 未经影子运行验证的部分不得进入自主运行；每个阶段都要上报自己的行数。** - [所有带回执的工作流](/workflows) - [目录里的供应商成功率](/data#catalog) ## 附录 A · GTM 工程中最值得使用的 agent 技能，以及每个技能留给你的数据步骤 技能（skill）是方法。它们大多要么需要某家供应商的 API key，要么把实时数据留给 agent 自行解决。最后一列是目录里能够覆盖该步骤的那项任务。 | 技能 | Star 数 | GTM 任务 | 数据步骤 | 由谁覆盖 | | --- | --- | --- | --- | --- | | coreyhaines31/marketingskills | 51.8k | 冷邮件、竞品调研 | 你自己提供的信号；关键词与反向链接数据走 DataForSEO | 购买意向信号；关键词排名、反向链接 | | mvanhorn/last30days-skill | 63.1k | 调研人们如何讨论一个话题 | 社媒帖子；可选的 ScrapeCreators 或 Apify key | X、Reddit、TikTok、YouTube 的搜索与评论 | | AgriciDaniel/claude-seo | 17.9k | SEO 审计与研究 | DataForSEO；Google OAuth 接 Search Console | SERP、关键词量、反向链接；你自己的 Search Console | | zubair-trabzada/geo-seo-claude | 10.9k | AI 可见度与品牌提及 | 抓取页面与启发式评分 | ChatGPT、Perplexity 与 AI Mode 的带引用回答 | | phuryn/pm-skills | 26.6k | 竞品作战卡 | 网页搜索加上你的赢单/输单记录 | 公司补全、新闻、定价页、广告 | | swan-gtm/gtm-skills | 161 | 客户调研简报 | 不绑定工具的公司、人物与搜索证据 | 公司画像、决策人、招聘 | Star 数读取自 2026 年 9 月 29 日的 GitHub。六个第三方仓库均为 MIT 许可。这些技能尚未在我们的数据层上完成端到端运行。 ## 附录 B · 在 鹦鹉AI 中工作的 GTM 工程师，Clay 有哪些替代方案 如果你本来就习惯用提示词思考，真正的问题不是使用哪张表格，而是数据从哪里来、每个正确结果需要多少钱。同样是 292 人的实测： | 方案 | 工作方式 | 完全匹配 | 每个正确邮箱 | | --- | --- | --- | --- | | **鹦鹉AI** | 提示词；按次计费的数据层；你自己的 key 优先 | 90.4% | 3.92 积分 | | Clay | 可视化表格、共享工作区、积分 | 89.7% | 27.65 积分 | | Freckle | 表格式补全 | 90.1% | 29.89 积分 | | Deepline | 批量补全 | 86.6% | 64.68 积分 | 如果你的团队需要一张共享的可视化表格，并且已经在付费，那就继续使用 Clay。如果你希望整套流程都用提示词描述、只为调用付费，就把工作迁入 agent。[完整基准测试](/blog/work-email-finding-bench)。 ## 附录 C · 这本手册背后的每一次实测运行 | 运行 | 日期 | 返回了什么 | 计费 | | --- | --- | --- | --- | | 手册运行：计数、相似公司、采购决策团队、时机、入站（第 2、4、6、9、10、13 章） | 9 月 30 日 | 同一份目标客户画像上的 294 次调用；数字见各章 | 1890.01 积分 | | 研究：跳槽 vs. 五个数据库（第 9 章） | 10 月 7 日 | 148 人；68% 的记录未显示新工作 | 7770 积分 | | 研究：融资前的招聘与新闻（第 10 章） | 10 月 6 日 | 57 家完成融资 vs. 54 家未找到融资；招聘无法区分 | 9555 积分 | | 研究：找到 vs. 可送达（第 8 章） | 10 月 7 日 | 60 个找到，32 个可送达 | 455 积分 | | [建一份验证过的线索名单](/workflows/find-and-verify-a-lead-list)（第 3、5、8、11、14 章） | 9 月 23 日 | 50 家公司里得到 20 个可送达线索 | 1631.01 积分 | | [工作邮箱基准测试](/blog/work-email-finding-bench)（第 7 章） | 9 月 16 日 | 292 人，横跨五个聚合平台 | 我们这边 1043 积分 | | [在一个细分类目里找创作者](/workflows/discover-creators-in-a-niche) | 9 月 14 日 | 153 个匹配里得到 25 位创作者 | 140 积分 | | [触达创作者前先筛选](/workflows/screen-instagram-creators-before-outreach) | 9 月 14 日 | 20 份档案里 18 份，互动率中位 5.3% | 25.2 积分 | | [给关键词需求定价](/workflows/keyword-demand-to-ad-budget) | 9 月 14 日 | 50 个关键词，742,970 次月搜索 | 77 积分 | | [挖掘竞品广告](/workflows/mine-competitor-meta-ads-as-creative-pack) | 9 月 14 日 | 20 条 Meta 广告与 17 条 Google 创意 | 10.5 积分* | 三项研究各自独立、各有样本，不属于那批围绕同一份画像的运行；招聘研究那一行包含搭建两份样本的成本。页首的 3521 积分 是 9 月 30 日与 9 月 23 日两批运行，它们围绕同一份目标客户画像；其中包含我们因解析 bug 重跑一步花掉的 756 积分（第 16 章）。* 那次运行有两次调用使用了团队自己的 Apify key，我们从不计费。 ## 附录 D · 术语表与问题 | | | | | **ICP** | 目标客户画像，写成筛选条件与检查（第 1 章）。 | | **TAM** | 符合你筛选条件的公司数量（第 2 章）。 | | **检查（Check）** | 无法用筛选条件表达、只能逐行执行的判断，在付费步骤之前运行（第 5 章）。 | | **瀑布式补全（Waterfall）** | 按顺序尝试供应商，直到有一家应答。我们的路由接口从成本最低的开始尝试。 | | **全收域名（Catch-all）** | 对任何地址都照单全收的域名，验证器因此无法确认某个具体邮箱地址（第 8 章）。 | | **信号** | 一条带日期、可链接、让消息有理由现在发出的事件（第 9 章）。 | | **实时读取** | 在你需要的那一刻抓取某个人的公开档案，而不是读一条存量的数据库记录（第 9 章）。 | | **档位（Tier）** | 按匹配度与时机划分的优先级（第 10 章）。 | | **影子运行** | 让自动化打法与手工流程并行运行，在切换之前进行对比（第 16 章）。 | ## GTM 工程师常问的问题 ### GTM 工程师和 RevOps 有什么区别？ RevOps 负责跨团队协调营收流程、系统、规划与报表；GTM 工程师搭建并运行具体的工作流，例如数据补全、评分、信号与分流，而且常常隶属于 RevOps 团队。头衔各异、职责重叠。在实践中，RevOps 决定营收系统如何运转，GTM 工程师负责把其中可以自动化的部分构建出来。 ### 一个人跳槽之后，联系人数据有多准？ 跳槽后的第一个月内并不太准确。我们在 2026 年 10 月 7 日研究了 148 位在 1 到 29 天前公布新工作的人：联系人数据库的记录平均有 68% 未显示新雇主；当两家数据库都收录同一个人时，仍有 64% 被两家同时遗漏。实时档案读取在它找到的 49 人中有 47 人是最新的，但它只找到了这 148 人中的三分之一。开展与跳槽相关的打法时，写信之前先实时确认新公司。 ### 招聘或新闻信号，能预测一家创业公司即将融资吗？ 在我们的测试中，招聘不能。2026 年 8 月到 10 月公布种子轮到 B 轮融资的 57 家美国创业公司，与 54 家未找到融资的相似公司相比，事前几周开放 GTM 岗位、任何岗位或高级岗位的比例只相差几个百分点；而已记录的新闻在未找到融资的对照组中反而更常见（54% 对 26%）。看到融资公告就直接跟进；任何时机信号，在赋予权重之前，先在你自己的赢单与输单上测试一遍。 ### 我需要写代码吗？ 不需要。你用一段提示词描述任务，agent 负责选择调用，并在产生费用之前向你展示价格。真正需要你亲自完成的是第 3 章中的那些规则。 ### 这套方法能配合哪些 agent 使用？ 那条设置命令在 鹦鹉AI 中即可使用；任何能够执行 shell 命令的工具都可以通过 CLI 使用。每一章的提示词都是自然语言，不绑定任何一款 agent。 ## 今天就在你的 agent 里跑第 1 章。 一份目录，接入多家供应商的公司、人物、邮箱、招聘、融资与新闻数据。第 2 章中的那些计数是免费的。 **设置一次** ```text set up 鹦鹉AI — https://parrot.amorist.cn/llms.txt ```