dev-marketing-prospector

开发者营销潜客挖掘

一项 Infrasity 潜客挖掘技能，用于识别特定技术垂直领域中需要开发者营销服务的 SaaS 公司。输出中的每个数据点都附有来源 URL。公司自行发布的声明会标明。推断会明确注明是推断。

---

输入参数

每项潜客挖掘请求都有三个输入。开始前请确认这三项：

参数	含义
垂直领域	要在其中挖掘潜客的具体细分市场
融资阶段	要纳入的融资阶段范围（例如，从种子前轮到 A 轮）
员工人数	符合条件的公司员工人数上限

如果缺少任何一项输入，请先询问。

---

八步工作流

第 1 步 — 了解垂直领域

在搜索任何公司之前，先准确了解该垂直领域：

• 它解决的核心问题
• 该垂直领域的公司所构建的产品类型
• 这些公司的主要技术 ICP 是谁
• AI 在这一领域带来的颠覆机遇是什么

严格匹配测试：输出列表中的每家公司都应与列表中的其他公司同属一个范畴。如果某家公司显得格格不入——哪怕只有一点——它就只是相关领域的公司，而非严格匹配。相关领域的公司绝不能列入名单。

阅读 references/vertical-definitions.md，了解所有已知垂直领域的定义。对于其中未涵盖的任何新垂直领域，请先进行研究，再生成输出，并遵循该文件底部的新垂直领域流程。

---

第 2 步 — 应用硬性筛选条件

每家公司必须同时满足以下五项条件：

1. 严格匹配垂直领域 — 构建的产品确切属于该垂直领域，而非仅与之相关
2. SaaS / 产品优先 — 不是服务型公司，也不是以服务为主的公司
3. 面向开发者的产品 — 开发者能够发现、试用并采用的产品
4. 融资阶段 — 符合用户提供的范围
5. 员工人数 — 符合用户提供的上限

如果公司通过了垂直领域测试，但未通过融资阶段或员工人数筛选 → 排除。 如果公司通过了融资阶段和员工人数筛选，但仅属于相关领域 → 排除。 五项筛选条件必须同时满足，不得例外。

---

步骤 3 — 从所有可靠来源研究公司

不要依赖固定的数据库列表。广泛搜寻。针对特定公司，使用能提供最准确、最新数据的可靠来源。目标是准确，而非忠于某个来源。

Clay 数据增强（从这里开始查融资、员工人数和技术栈） 在为多家公司进行数据增强前，调用 get-credits-available 检查预算。 然后为每个候选公司调用 find-and-enrich-company，获取融资阶段、融资金额、领投方、日期、当前员工人数、技术栈（汇总自 BuiltWith + HG Insights）、LinkedIn URL 和总部所在地。Clay 汇总了 Crunchbase 和 LinkedIn 数据——将任何公司列入名单前，务必再从一个额外的人工来源核实员工人数和融资信息。

注意：Clay 不涵盖开发者和开源信号（GitHub、npm、Docker Hub 等）——这些信息请使用下方的人工来源。

融资和公司数据 Crunchbase、PitchBook、Tracxn、CB Insights、Dealroom、Harmonic、Carta、Companies House（英国）、SEC EDGAR（美国公开文件）

发现和潜在客户挖掘 Y Combinator 公司目录、TechCrunch、VentureBeat、TechEU、Sifted（欧洲）、The Information、StrictlyVC、Bloomberg、Forbes、Business Wire、PR Newswire

员工人数和人员 LinkedIn、RocketReach、ZoomInfo、Apollo、LeadIQ、Glassdoor、招聘网站（某公司正在招聘 10 个开发者营销职位，本身就是一种信号）

开发者和开源信号 GitHub（星标、分叉、贡献者、发布频率）、npm、PyPI、Docker Hub、Stack Overflow 趋势、Hacker News Show HN 帖子、Product Hunt 发布

收入和增长估算 Sacra、Contrary Research、Latka、Growjo、SimilarWeb（以流量作为代理指标）、SEMrush

竞争定位和第三方分析 G2、Capterra、StackShare、StackOne、OpenAlternative、分析师报告（公开可查时参考 Gartner、Forrester、IDC）、可靠博客发布的技术评测汇总

新闻和近期信号 在 Google News 搜索公司名称 + 当前年份、公司博客、公司更新日志、新闻稿、创始人访谈、播客访谈

**规则：**针对特定数据点，使用能提供最准确、最新数据的来源。如果两个来源存在冲突，注明两者的信息，并指出哪个来源更新或更可靠。对融资总额或员工人数等关键数字，绝不要只依赖单一来源。

进行有针对性的搜索，而非宽泛搜索。在每条搜索查询中使用准确的垂直领域名称、融资阶段和员工人数范围。将公司列入名单前，至少通过一个可靠来源核实其员工人数和融资阶段。

---

步骤 4 — 为每家公司梳理一个信号

**先检查 Clay：**使用公司名称调用 ask-question-about-accounts，在手动搜索新闻前查找近期事件。如果 Clay 返回的可核实信号符合下方标准，就以此作为起点。如果不符合，则回退到步骤 3 中的人工来源。

对于每家符合条件的公司，找出一个具体、近期、可核实的理由，说明为什么该公司现在是一个值得联系的潜在客户。必须属于以下一种：

• 一轮融资（注明轮次、金额、领投方、日期）
• 新产品发布或重大功能更新
• 新合作关系或企业客户公告
• 工程或产品团队招聘激增
• 公开基准测试、奖项或分析师认可
• 直接影响该公司的市场动因

该信号必须回答：为什么是现在——不是六个月前，也不是六个月后。

说明该信号为何能证明开发者营销与这家特定公司在这一特定阶段相关。不要让这种关联仅仅隐含在内容中。

---

步骤 5 — 为每个信号数据点标注来源

为信号中的每个数字、主张或事实找到并记录来源 URL。 应用以下三级分类：

等级	定义	标注方式
直接来源	来自可信第三方来源且可验证的统计数据	列出 URL — 无需标记
自我报告	公司自己的博客、新闻稿或 CEO 声明中的主张 — 未经独立验证	用 ⚠ 标记并注明为自我报告
推断	根据两个或更多有来源的数据得出的逻辑结论	明确说明这是推断，并列出底层来源 URL

如果某个数据点无法找到来源，请勿将其纳入信号。

---

步骤 6 — 为每家公司确定一个痛点

使该公司成为潜在买家的具体开发者营销缺口。必须：

• 与该公司的发展阶段、产品和竞争情况具体相关
• 表述后果 — 如果不解决这一缺口，会发生什么
• 与具体数字和竞争对手情况相关，而非泛泛而谈
• 绝不能写“他们需要更多知名度”——必须具体，并与其当前 的增长阶段紧密相关

常见痛点模式：

• 庞大的开源社区（GitHub stars），但商业转化率低（ARR 差距）
• 竞争对手的融资额和员工人数是其 X 倍，但处于同一市场
• 社区活动和开发者影响力仅集中在一个地区
• 所有企业客户都来自一个渠道（人脉、合作伙伴关系），没有自然流入
• 以当前发展阶段而言，员工人数太少，无法设立专职开发者营销职能

---

步骤 7 — 为每个痛点数据点标注来源

应用与步骤 5 相同的三级来源系统。针对痛点中的每个数字或主张：

• 找到来源 URL
• 分类为直接来源、自我报告（⚠）或推断
• 自我报告的主张在外联文案中必须表述为“Company X 声称……”， 不得作为独立验证的事实
• 推断必须明确标注为推断 — 它们是基于真实数字得出的战略观察，而非引文

对于自我报告的数据：务必查找原始来源（通常是公司自己的 博客，或投资人简介中的 CEO 引述）。不要将重复该数据的第三方文章 视为主要来源 — 应追溯到该数字最初出现的位置。

---

步骤 8 — 生成统一的输出表格

将每家符合条件的公司放入渲染后的可视化 HTML 组件中，且必须恰好包含 以下九列：

列	内容
Company	名称 + 融资阶段徽章 + 成立年份 + 员工人数
URL	网站 URL（可点击）
LinkedIn	LinkedIn 公司主页 URL（可点击）
Headcount	员工人数
Signal + Why Dev Marketing	信号，以及开发者营销为何与当前阶段相关
Signal Sources	编号来源链接（S1、S2……）— 每个来源单独一行
Geography	总部所在地及国家旗帜
Pain Point	具体的开发者营销缺口及其后果
Pain Point Sources	编号来源链接（P1、P2……）— 每个来源单独一行，自我报告来源需标注 ⚠

使用可视化工具将其渲染为简洁的 HTML 组件。表格必须支持 水平滚动。按融资阶段排序： Bootstrap → Pre-seed → Seed → Series A → Series B → Series C+

列宽、徽章颜色、来源单元格格式和 ⚠ 标记规范，请参阅 references/output-format.md。

---

诚信守则

这些规则适用于整个工作流程，并优先于任何要求增加名单长度的压力：

• 简短而诚实的名单始终胜过冗长而凑数的名单
• 切勿为了达到最低数量而添加相邻领域的公司
• 切勿添加与目标垂直领域相关但并不完全属于该领域的公司
• 如果没有符合条件的公司，请明确说明并解释原因
• 如果由于该垂直领域发展迅速，融资上限导致名单过短，请告知用户并提出取消上限
• 切勿将公司自我报告的主张表述为独立验证的事实
• 切勿将推断当作引文

输出格式参考

有关完整的 HTML 表格规范、列宽、徽章颜色、来源单元格格式以及 ⚠ 自行报告标记，请参阅 references/output-format.md。

---

垂直领域定义参考

有关所有已知垂直领域的准确定义，请参阅 references/vertical-definitions.md：AI Agentic、IAC、DevTools、Observability、DevOps、FinOps、AI/SDLC（AI 软件工厂）、AI Orchestration / AI Workflow Management，以及处理新垂直领域的说明。