oneshot-gtm：把「获客」做成一条可审计的流水线

一、一个具体的场景

假设你是一家小众 AI 工具的创始人，团队 5 个人，客户是「刚刚在 GitHub 上给某个 agent 框架点了 star 的独立开发者」。传统冷邮件工具的做法是：导入一份从某个数据商买来的 10 万条邮箱列表，然后每天自动群发 2000 封，用打开率优化模板。结果是邮箱域名被标记为垃圾邮件源，转化率为零，但你已经为每个「付费查询」付了费。

oneshot-gtm 走的是另一条路。它不预设你已经拿到市场匹配（PMF），而是从公开信号出发——有人在 Hacker News 上发了产品上线公告、有人拿到了新一轮融资、有人在公司注册信息里出现了新名字——把这些「事件」作为线索来源。然后由一个称为 ICP gate（理想客户画像闸门）的判定器，对每个候选人做「与你的画像是否匹配」的判断，不匹配的直接拒掉，且你可以人工推翻它的结论。名单不会直接发出去，而是进入一个审批队列，你逐条点「通过」之后才会生成草稿，而草稿永远不会自动发送。

这个设计背后是一个明确的观点：大多数外呼工具假设你已经赢得市场，于是优化「发送量」；而真正需要工具的创始人还没有赢，于是应该优化「每次有意义的回复成本」。工具的价值因此从「帮你发更多」变成了「帮你少发错」。

二、类比：它更像一家有审批制度的会计师事务所

把常见的群发工具想象成「自动印钞机」：你填一个模板，它替你大量印刷并寄出，没人核对内容。

oneshot-gtm 更像一家会计师事务所。线索进来先要过「执业资格核查」（ICP gate），不通过的业务被退回；通过的还要经过「底稿复核」（草稿 lint），凡是命中「机器味」写作特征的稿件一律扣下不送；最后寄出前还有「授权签字」（人工审批队列）。每个环节都留痕，形成了「签名收据」（signed receipt）——每一次付费调用（研究、数据补全、发信、LinkedIn、短信、语音）都留下可核对的回执，花费不再是一个估算值，而是一份记录。

三、核心功能与技术细节

两个前端表面：终端 CLI（apps/cli，基于 commander）与本地 Web 仪表盘（apps/web，React 19 + Vite + Tailwind + TanStack Router/Query + assistant-ui）。后端是 apps/server，用 Bun.serve 起单用户服务，绑定 127.0.0.1，通过 REST + SSE 与前端通信。另有 packages/ 下的 7 个共享包：core、doctor、find、intel、plays、prompts、shared-types。

线索发现器（Finders）：一个 finder 就是一个「信号源 + 调度计划 + 花费上限」的组合，内置 Show HN、融资新闻、加速器批次、职位变动、在招岗位、GitHub star 增长、活动嘉宾名单、企业注册库、公开招标等来源，并按行业提供「行业包」（如餐饮、家政、医疗、汽车维修、卡车货运、市政、垂直 AI 创业公司共 8 个真实垂直行业包 + 1 个占位包）。

Play（打法）：一个 play 描述「面向谁、发生了什么信号、第一句话说什么、怎么跟进」。邮件与 LinkedIn 在你发送时才会真正发出；X、Reddit、Hacker News 的草稿由你手动发布后标记为已发。

发送与限额：新邮箱每天发 10 封，之后每周递增 10 封，上限 50 封/天；当天配额用尽即停止直到午夜。重复发送有守卫，收到任意渠道回复即停止跟进序列。首触绝不索要会议，只给一条有用的信息并回问一行，或什么都不问。

数据与隐私：全部状态落在本地 ~/.oneshot-gtm/ledger.sqlite（SQLite 为唯一真相源），密钥在 ~/.oneshot-gtm/.env（权限 600），日志在 ~/.oneshot-gtm/events.jsonl（10MB 轮转三代），全部不离开本机。遥测默认开启但匿名，oneshot-gtm config telemetry off 一键关闭，只发送命令名、参数名、结果、耗时、版本、OS、LLM 提供方和随机安装 ID，不含潜客、提示词、回复、收据或钱包信息。

技术栈：Bun 1.3.13+ 运行时（用 bun:sqlite，纯 Node 下会直接失败）、TypeScript 6、Vitest 4、Turborepo、oxlint/oxfmt、OneShot SDK 0.53.1。LLM 提供方可自选 OpenRouter / OpenAI / Anthropic，工具本身不锁定单一厂商。

四、上手门槛

低门槛路径是 bunx oneshot-gtm-server，无需克隆仓库即可跑起仪表盘；完整路径需要 Bun 1.3+、Git、bun install、bun run cli -- init 填写画像与密钥、bun run cli -- doctor 自检、bun run --cwd apps/web build 构建一次，然后 bun run cli -- ui 打开 http://127.0.0.1:3030。首次使用的真实门槛不在技术，而在账户：需要自备 LLM 密钥，并开通 OneShot 钱包（推荐 Coinbase Developer Platform 服务端钱包，或直接提供私钥），实际调用按次计费。

五、争议与局限

这个项目把「不做什么」写进了代码：不会替你运营 SDR、不管理你的 DNS、不托管客户数据、不锁定单一 LLM、不做多用户。这种克制换来的代价是功能天花板——如果你的诉求是「全托管销售团队」，它明显不合适。

另一层局限是商业依赖：工具本身开源且 MIT，但核心的 OneShot 动作层（研究、补全、邮件、LinkedIn、短信、语音）是商业服务，付费收据与用量直接绑定其账单体系。脱离该服务后，「按结果付费」的卖点会被显著削弱。代码质量方面，STATUS.md 记录 7030 个测试 / 531 个文件全部通过且对真实 API 做过端到端验证，这是相当罕见的严谨度；但作者自己也承认覆盖率在两个包上偏薄（packages/doctor 仅 1 个测试文件对应 799 行代码，packages/intel 的重试测试覆盖有限）。项目的「假设一切绿灯」风格意味着作者对功能边界有强烈主张，使用前需要认真读 ROADMAP 里「尚未构建」与「永不构建」两节。

六、行业意义

oneshot-gtm 折射出 2026 年外呼工具的一个转折：从「规模化自动化」转向「约束与审计」。当监管与邮箱服务商不断收紧冷邮件规则时，靠发送量取胜的模式正在失效；替代路径是把判断力放回人手里、把成本变成可核对的凭据、把限制写进代码而不是写进营销页。仓库 742 次提交、672 star、MIT 协议、完整的 19 篇文档与逐项标注验证状态的 STATUS.md，说明这不是一个概念演示，而是一个被真实使用过的系统。

项目主页：https://oneshot-gtm.com ，文档：https://docs.oneshotagent.com/oneshot-gtm/introduction