她是内蒙古姑娘,在河南郑州打工。凌晨 00:35,她在设计师视频底下问了一句 「100平的可以装成这样吗」 — 这条评论拿到全批最高的 93 分,6 分钟后破冰就送到了她私信。
然后系统开口叫了她一声「小龙女哥」。昵称是女性角色名、主页简介自述「内蒙古姑娘」、抖音横幅写着「方便以后找到她」— 三重信号全指向女性。最好的线索没有配上最好的话术,这就是本页要讲透的事。
下面三块是这条案例的原始信号:她留评论的那条「100平怎么做出大宅感」视频、那句带面积带参照物的提问、以及一小时里 3 条来回的完整对话。对话很短,但每一条都值得逐字看 — 本案的问题和亮点都藏在字面上。
messages.role = ai,右侧紫色气泡);#2 来自 DB(role = customer,左侧灰色气泡)。本案 DB 3 条与手机聊天截图逐条对得上,没有丢失、没有需要从截图补录的消息 — 这在本批案例里是少数。sent_at / created_at。抖音客户端截图上显示的时间戳与落库时间存在数分钟偏移(客户端只在间隔较大时插入时间标签),页面统一以 DB 为准。
本案时效侧几乎没有可挑剔的地方:00:35 评论,00:41 送达,全程 6 分钟,而且是深夜时段 — 没有人工值守,链路自己跑完了采集、评分、起草、云电脑发送四段。客户此时大概率还在刷同一批装修视频,注意力窗口完全没关。
📌 值得记住的一点:凌晨不是低质量时段。本案客户 00:35 刷装修视频、01:39 回私信,全程清醒且有耐心。深夜线索被当成"明天再说"处理,才是真正的浪费 — 本案链路没犯这个错,6 分钟就把消息递到了她还在看手机的时候。
本案内容侧是一高一低的强烈反差:评分模型判得极准(93 分,本批最高),跟进话术也是本批写得最扎实的之一;但破冰第一句就出了一个三重信号都能避免的硬错误 — 把一位女性客户叫成「哥」。
在米凌设计师_胡设计发的「100 平怎么做出大宅感」视频底下,她写下 「100平的可以装成这样吗」。这 10 个字信息密度很高:①给了面积 — 100 平,一个可以直接进方案的硬变量;②给了明确参照物 — 「装成这样」指向视频里的具体效果,等于她已经选好了想要的样子;③句式是可行性询问 — 「可以…吗」不是感叹不是抬杠,是在确认自己家能不能落地。三样凑齐,这就是一条典型的高意向购买前问询。
intent_reason = 「问购·具体·在调研」,comment_type_reason = 「报面积+可装否=产品问询」):产品型 · high specificity · active。首条 AI DM 在 transcript(#1)。结构是标准的四段式:招呼 + 溯源 + 反问,但第一段就翻车了。
客户只回了一个「新」字,跟进(#3)却把这一个字用足了。这条值得逐句拆:
本案触达账号是「小星·全屋定制」(DB 内部账号名「零星」,聊天气泡右上角带金色「小星·全屋定制」徽章,运营归属夏夏)。深夜一条陌生 DM,客户的默认反应是点头像验证这是不是个真做定制的号 — 她最终回了消息,说明这一关过了。
accounts.following_count(同步于 6-25)accounts 无粉丝字段 · 需运营主页截图补数
Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案的问题不是没数据,而是数据摆在眼前没人捡 — 她的主页简介白纸黑字写着「在河南郑州打工」,IP 属地也是河南,省市两级本来都能确定,但 DB 的 comments.city 仍是空的,破冰和跟进也全程没提过一次郑州。
comments.ip_location · 抖音 IP 反查 · 已入库但话术未使用comments.city · 但主页简介明写「河南郑州」 — 是采集没抽取,不是客户没说source_accounts.city · 「米凌设计师_胡设计」标为本地号但市字段未入 → is_same_city = nullcomments.city 就能填上「郑州」。目前是空的。comments.city;②话术层加规则:city 非空时,破冰或第一轮跟进必须带一次城市锚。
本案对话未涉及价格话术 — 模块跳过。破冰和跟进都没有出现任何单价、总价、活动价或优惠信息,客户也没有问价。
"评论入库 → 评分 → 起草 → 发送"在 DB 里是几行行变化,物理世界对应的是一台阿里无影云电脑上常驻的抖音客户端。通道判定有硬证据 —— 账号 channel_pref = cloud_pc,不依赖运营本机的手机和 ADB 线。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,Akke 现阶段靠云电脑常驻 GUI 自动化触达:cron 派单进队列,云电脑上的 poll agent 拉单,用模板匹配 + SendInput 在抖音 PC 客户端里完成搜人、开会话、粘贴、发送。本案的凌晨 00:41 发送,也印证了这条通道不依赖人工值守。
channel_pref = cloud_pcmin_send_interval_seconds = 30
本案 messages 表里 3 条记录(AI 2 条 + 客户 1 条)与手机聊天截图逐条完全一致,没有出现同批其他案例里"客户连发短消息被漏捕"的情况。原因也很朴素:本案客户只回了一条,且间隔充裕(57 分钟) — 回写没有被并发压力考验到,这是"没出问题"而非"证明了不会出问题"。
给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。本案一句话总结:93 分的最优线索,配了一句叫错性别、丢掉地区的开场。
comments.ip_location = 河南,抖音 IP 反查跑通。comments.city 却仍是 null。city 也未标记:「米凌设计师_胡设计」是本地号但市字段为空 → is_same_city = null,同城牌打不出来。comments.city;city 非空时话术必须带一次城市锚。channel_pref = cloud_pc,凌晨 00:41 无人值守自动发出。84036832-…-d3ececb7dc1f7a9891f2-…-bff6a93c952c · stage ice_breakMS4wLjABAAAA06so…NQYhkcomments.city 为空 · 主页自述郑州)7652647692639718671 · 100 平大宅感 · 号源「米凌设计师_胡设计」channel_pref = cloud_pc)· ≥30s/条