人工翻号，慢且贵
销售逐个翻账号、看主页、抄联系方式，一天看不了几十个；找到的还多是消费者和探店博主。
企业定制交付 · 2026-09冰淇淋供应链 · B2B 获客
让 AI 替企业找到真能谈的客户，
每个判断有证据可回溯。
为一家冰淇淋供应链企业定制的 AI 获客工作台——从公开社媒发现经营主体、核验身份与采购角色，到企微名片交接的六步全流程系统。证据锚定每一个结论，AI 只筛不发：所有外发内容必须人工逐条批准。
- 客户冰淇淋供应链企业
- 目标客群冻品经销 · 高端餐饮
- 渠道公开社媒经营账号
- 交付六步获客工作台
0/448
离线回归测试全绿
工程 · 数据 · 通道 · 审批全链路
工程 · 数据 · 通道 · 审批全链路
0条
真实候选记录
三轮采集 · 迁移零丢失
三轮采集 · 迁移零丢失
0个
有经营依据的候选
证据逐条锚定公开原文
证据逐条锚定公开原文
0/30
对话协议固定题评测
24 次真实模型调用
24 次真实模型调用
01 / 业务背景
冰淇淋找客户，
难的不是搜索，是分清「谁真能采购」。
客户是冰淇淋供应链企业，产品主打高端餐饮甜点场景。真正的买家不是散客，而是食品经销、冷冻食材批发与高端餐饮的选品决策人——他们散落在公开社媒的经营账号里，人工找客面临四个具体困难：
订餐电话 ≠ 采购入口
抓到门店订餐电话不算获客——真正要找的是供应链、供应商相关的对接入口和采购决策人。
身份与采购权难核
「招代理」往往是在卖货不是求购；主厨不默认有采购权；同名主体不能想当然合并。
不敢让 AI 自动发消息
错身份、错话术的外发就是骚扰，砸的是企业自己的牌子——AI 获客的第一要求是不能翻车。
两条候选路径（与客户逐条对齐的业务规则）
| 路径 | 入围证据 | 优先联系角色 | 不能混同的对象 |
|---|---|---|---|
| 优先食品经销 · 冷冻食材批发 · 区域代理 | 实际经营食品品类；服务餐饮客户；冷冻仓储/配送分别核查 | 老板、合伙人、选品/采购负责人 | 只做冷链运输的物流公司；只卖设备的厂商 |
| 辅助高端餐饮 · 餐饮集团 | 可核查的门店/集团身份；人均 200+ 定位；菜单甜点场景 | 集团采购/供应链负责人；独立门店老板 | 顾客、探店博主、订餐客服 |
筛选假设需首轮名单复核，不代表已验证的采购需求——这是与客户约定的前提，也是本系统「三态如实」设计的由来。
02 / 六步获客工作流
六步，从「定规则」
到「名片交到业务手里」。
不是爬虫脚本，是一套完整业务系统：每步落盘留痕、预算可控、证据可回溯。右侧常驻 AI 助手，接受「把地区改为杭州」「重新筛选材料」「修改首条草稿」这类自然语言指令——每个动作幂等落盘，普通聊天不触发任何操作。
-
目标与产品
录入目标、产品、客群、地区与必要/优选/排除条件，绑定发送账号与企微名片——规则即配置，换行业不用改代码。
输出 获客任务 · 条件规则集 -
找客计划与搜索
AI 生成查询计划，浏览器只读采集公开页面；首五样本人工检查后再继续。每轮预算固定（默认 20 搜索 / 100 读页），耗尽不自动加。
输出 候选账号 · 公开证据 -
候选核验
逐项核验经营事实、身份、对接权限；每个字段三态标记：有证据 / 相反证据 / 未知——缺证据就标待核，绝不编造。
输出 核验档案 · 原句引用 -
首条与审批
AI 按证据起草首条消息，人工逐条批准后才进入发送队列；产品或规则一改版，旧批准自动失效——AI 永远没有直接发送权。
输出 已批准首条 · 版本绑定 -
对话接待
已批准会话的来信识别、停止状态与人工接管；拒联按对方稳定账号跨任务生效，不再打扰。
输出 会话状态 · 接待判断 -
企微交接
名片发送、对方添加、业务接手三步分别记录；图片送达单独验证——本机可解码不等于对方已收到。
输出 交接记录 · 商机状态
自动化引擎
浏览器采集、证据读取、材料分组、草稿生成全自动；单采集 Worker 串行 + 每账号独立登录环境，互斥不并发。
AI 助手（自然语言指挥）
「重新筛选」「改地区」「调整草稿」——指令→幂等动作，执行结果后端落盘；否定句和讨论绝不触发操作。
03 / 技术架构
模型输出不直接采信，
一切经过本地校验层。
React/Vite 六步工作台 + Fastify 本机服务 + SQLite 持久化（任务、上下文版本、证据、审批、发送状态）。LLM 只做三种协议判断，业务程序管理全部操作——模型没有工具调用权。
客群分析
这个账号是谁？有没有采购角色？
- 输入公开主页与笔记原文
- 判断经营品类 / 身份 / 角色 / 冷链条件
- 校验结论必须引用原文原句与位置
- 输出三态字段 + 待核问题清单
接待判断
这条来信该怎么回？
- 输入会话历史 + 产品确认快照
- 判断继续沟通 / 转人工 / 停止
- 红线禁止凭一句「好的」就发名片
- 输出受控回复或明确转人工
工作台助手
使用者的一句话怎么安全执行？
- 理解改条件 / 重筛 / 改草稿 / 开停搜索
- 执行SQLite 幂等事务，重复提交不重复执行
- 防误版本过期或对象不匹配时拒绝
- 回报真实执行结果，失败不显示已执行
版本化上下文改动形成新版本
旧批准自动失效
旧批准自动失效
幂等每个动作幂等键落盘
结果不明只核对不重发
结果不明只核对不重发
可恢复跨重启保留队列与状态
一致性备份先于迁移
一致性备份先于迁移
单实例独占实例锁
第二实例不触发迁移
第二实例不触发迁移
04 / 实证数据
三轮真实采集，
每个数字如实可查。
以下全部来自 2026-09-14 至 09-17 的真实运行与验收记录：消耗、候选、模型调用逐项落盘；复用名单与新增名单如实区分，没有包装。
三轮真实采集
| 轮次 | 去重账号 | 分析接受 / 待核 | 搜索 / 读页 / 模型调用 | 结果 |
|---|---|---|---|---|
| V1 首轮采集 | 19 | — | 原始消耗完整保留 | 首轮名单 |
| V2 旧材料重评 | 19（全部旧材料） | 17 / 2 | 0 / 0 / 21 | 协议升级重评 |
| V2 新一轮采集 | 27（18 新 + 9 复用） | 24 / 3 | 11 / 100 / 34 | 8 个有经营依据候选 |
新轮 8 个经营候选中 6 个来自历史账号、2 个为本轮新发现——复用如实标注。25/27 私信入口可打开，但「可打开」不等于「已送达」。候选数不代表采购效果，商业结果另记回复、试样、转企微、报价、订单。
质量验证
npm test
11 / 100搜索 / 读页
预算用尽即停，不自动加
预算用尽即停，不自动加
34 次真实模型调用
每次调用与消耗落盘
每次调用与消耗落盘
27 去重候选账号
18 新 + 9 历史复用
18 新 + 9 历史复用
0 条未经审批外发
安全设计使然（见边界）
安全设计使然（见边界）
05 / 工作台界面
真实工作台，
虚构验收数据。
以下截图来自隔离验收环境：全部使用虚构资料，0 外网请求、0 模型调用、0 消息发送——界面为真实产品代码，数据为验收夹具，公开无隐私风险。
06 / 安全与合规设计
AI 获客的差异化，
不在发得多快，而在不翻车。
面向真实企业经营者的外发系统，安全不是附件，是产品本体。六道机制全部在真实代码里落地并回归测试覆盖：
人工审批权
AI 永远没有发送权
- 逐条批准每条首条消息单独人工审批
- 通道未验不发图片接收链路未通过验收即整体关闭
- 专门入口确认产品、启用接待只有专门入口
证据锚定
每个判断可回溯到公开原文
- 原句引用结论必须引用原文原句与位置
- 本地校验JSON、结构、来源、否定与第三方身份逐层校验
- 推断≠事实模型推断不能升级成确认产品
三态如实
未知就写未知
- 字段三态有证据 / 相反证据 / 未知
- 不编造不造联系人、不推定采购意向
- 四列分显业务匹配、采购角色、触达入口、当前需求分开显示
公私隔离
私有数据不外流
- 物理隔离私聊、凭据、登录环境独立私有目录
- 不进模型私有证据不跨任务复用、不送客群模型
- 导出分版公开名单与私有商机摘要分开导出
版本失效
改版即作废旧批准
- 上下文版本产品/规则修改形成新版本
- 批准失效旧发送批准随版本自动失效
- 晚到保护旧版本晚到的结果不覆盖新评估
幂等与拒联
不打扰是硬约束
- 幂等键重复提交不重复执行，结果不明只核对不重发
- 拒联生效对方拒联按稳定账号跨任务跨账号生效
- 会话唯一同一物理会话只归属一个自动接待任务
07 / 诚实边界
可信的另一半，
是如实说出没做到什么。
本期 0 条自动外发
目标渠道的企微名片图片接收链路验证未通过，业务接待保持关闭——通道没验收就不启用，宁可交付慢一步，不让客户的名声冒险。
8 个经营候选 ≠ 8 个采购客户
经营事实成立只代表「这是真经营者」；采购意向、供货价格、起订量仍是未知项，如实标待核，不填造报价与适配率。
商业适配率未知
客户方对名单的复核反馈尚未返回；未复核前适配率记未知，不用模型自评冒充商业效果。
固定题 ≠ 真实准确率
448 回归与 30 题评测是工程边界验证，不能解释为模型对真实客户的判断准确率；真实链路验收单列、失败历史保留。
08 / 从一单定制，到一套方法
冰淇淋是第一个行业，
不是唯一一个。
交付后工作台完成通用化升级：冰淇淋保留为历史获客任务，设备经销、服务业务使用各自的行业规则——同一套六步流程、证据校验与审批机制，换行业只需换规则配置。定制一单，复用一套：这是这套交付对企业的长期价值。
行业规则可配置
目标、品类、角色与必要/优选/排除条件全部任务级配置；冷冻条件只在业务有要求时核验。
通用验收已通过
冰淇淋找客、设备经销找客、服务业务找客、区域问答、缺报价转人工、助手改目标六场景全部验证通过。