ChefShot ABM 获客引擎
一句话量级
一个 SDR 一天手动跑 32 条线索。同一条管线按自己的 Worker 节拍跑 1,920 条——相当于 60 个 SDR，而你的成本只是 API 用量。
32 条/天 = 15 分钟/条 × 8 小时。1,920 条/天 = 4 条/分钟 × 60 × 8 小时。1,920 ÷ 32 = 60。
你买的到底是什么
你买的不是一堆节点，是一条每天都在跑的获客系统：线索进来先查重、再让 AI 挑出正在让这家餐厅损失订单的那张照片、由 RAG 智能体写出诊断、补上决策人的直达邮箱——最后停在你面前等一个 [Approve]。
它替代的是什么
- 凌晨一点，SDR 还在复制粘贴第 60 个 LinkedIn 主页。一条线索的「查找 → 选图 → 写诊断 → 找高管邮箱 → 发信」人工要 15 分钟，8 小时只出 32 条。想把量做大只能招人，而一个人是 $3,000/月，60 个人就是 $180,000/月。账单先到，线索还没到。
- 量一上来，流程先掉链子。单线串联的营销流爬到上千条就 OOM；外部 API 一报 429 就全盘崩，而且没有断点续传——重跑只能全量重来，再烧一遍 API 账单，交付排期跟着滑坡。
- 图抓错了，邮件就白写。传统爬虫只拿到 Google Maps 首图，多半是店面外景；AI 诊断和图片驴唇不对马嘴，发出去也像群发。再投给 info@ 这种泛邮箱，投递状态还回不来，销售根本不知道谁值得跟。
架构
三段解耦管线。查重屏障在任何付费 API 调用之前，人工审批闸门卡在「邮件合成」与「投递」之间的主连线上。
防护栏
- HITL 审批阻断——AI 不许自己发邮件。高净值 / 低评分 ICP 不自动发送：n8n 向 Slack / 飞书 推送交互式卡片（原图 → 诊断 → 重绘图 → CEO 信息），销售点 [Approve] 后管线才放行投递，未审批的线索永远停在状态池。
- 滑动批次 Worker + 令牌桶 + 断点续传。定时工作流每 5 分钟提取 20 条线索，实测节拍 4 条/分钟；出站调用走 1.5 秒令牌桶限流 + 429 指数退避重试，所以频控不会把管线打断；中断后从状态池续跑，不用全量重来。
- 遥测与限损——先看住账单。节点耗时、Token 消耗、失败堆栈自动回写 CRM，单日调用成本超水位触发全局警报。抓取结果先按 Domain / PlaceID 查重，已存在直接丢弃，不进入 AI 富化环节。
- 解耦——Producer / Enricher / Consumer 三段不互相拖死。一段被限流或卡住，另外两段照常跑自己的状态池，不出现「一处 429、全线崩」的连锁。
你最终拿到手的东西
- 企业级自动化蓝图——可直接导入企业私有云的 n8n 工作流 JSON 矩阵，解耦为 Producer / Enricher / Consumer 三条管线。
- Agent 逻辑配置——Dify DSL 导出文件，含系统 Prompt、输出 Schema 与 RAG 知识库配置。
- CRM 治理与监控追踪——CRM 对象模型配置文件 + 自建邮件状态追踪网关的接口文档。
4 至 6 周，从核心链路梳理、Agent Prompt 调优到异步并发架构与 Tracking 部署。这是排期估算，不是合同承诺。
技术栈
- 编排层
- n8n · Dify
- 数据层
- Twenty CRM · PostgreSQL · Apify · Apollo.io · Firecrawl
- 呈现层
- FastAPI tracking gateway · Slack / Feishu cards · HTML email
数字，以及它的算式
- 单条线索 3 秒
- n8n 执行日志时间戳。一个人手动跑完同一条链路要 15 分钟。
- 人工基线 15 分钟/条
- 作者自测 n=1（查找 → 选图 → 写诊断 → 找高管邮箱 → 发信）。这是人工基线，不是客户实测。
- 300×
- 900 秒 ÷ 3 秒。同一条线索、同一份工作，快 300 倍。
- Worker 节拍 4 条/分钟
- 20 条 ÷ 5 分钟，滑动批次节拍。人的节拍是每 15 分钟 1 条。
- 日产能 1,920 条
- 4 条/分钟 × 60 × 8 小时。一个 SDR 一天只有 32 条。
- 一个 SDR 32 条/天
- 15 分钟/条 × 8 小时。这是人工一天的产能上限，管线是 1,920 条。
- 等效 60 个 SDR
- 1,920 ÷ 32 = 60。一整个外呼团队的人力。
- 省下的人力成本 ≈ $180,000/月
- 60 人 × $3,000/月，SDR 薪资取行业基线。换来的只是 API 用量账单。
- 按 10 万+ 级设计
- 设计容量，不是实测。实测节拍就是上面那 4 条/分钟。这两句话必须一起说。
同一个形状，另外三个问题
如果你的事不是上面那个场景，这一段才是重点：同一套架构指向三个互不相关的场景，都不是上一个案例的变体，也不需要从零重建。这些是**可平移的方向，不是已交付的项目**——上面那套系统是我们真跑过的，下面这三条是它的形状接下来能解决什么。这个区别我们标出来，不含糊过去。
B2B SaaS / 独立站出海
抓取使用老旧建站系统的商家，AI 分析官网 UX 缺陷，Apollo 抓取电商总监邮箱，自动发送 UX 改造分析报告与 Figma 概念重设图。
猎头与高端招聘
监控目标竞对公司的核心人员变动，抓取候选人 LinkedIn 并比对 JD 库匹配度，生成定制化挖角邮件，投递状态回写 CRM。
MCN 与达人营销
批量抓取 YouTube / TikTok 达人，AI 分析近期内容表现与受众画像，自动发送契合其人设的商单邀约。
有系统要做？
把情况写下来。你拿到的是针对你情况的书面回复——没有日历、没有 discovery call、没有十五分钟的寒暄。
状态
自研系统。这是我们给自己造的工具，用来证明我们自己的 ABM 编排能力，不是客户案例，也不代表任何外部组织在用它。它在我们自己的环境里运行中。
自研系统，在我们自己的环境里运行。
阅读完整架构，以及它在十万级为什么会崩