他在山东。在灿哥聊装修的新房开工视频底下,他留了一句客气话 — 「需要一份辟坑手册师傅,谢谢[玫瑰]」。
系统 4 分钟内完成评分、起草、送达;他隔了 4 天 11 小时才回两个字「新房」,AI 在 1 分钟内接住。但这条跟进的第一句就编出了客户从没说过的户型 — 本页把这个事实性幻觉当作头号问题拆开讲。
下面三块是这条案例的原始信号:他留评论的新房开工视频、那句只有一个诉求的客气评论、以及横跨 4 天半、只有 3 条的完整对话。对话短,但每一条都值得逐字读 — 本案最重要的问题就藏在最后一条里。
messages.role = ai,右侧紫色气泡);#2 来自 DB(role = customer,左侧灰色气泡)。本案 DB 3 条与手机聊天截图逐条对齐,无缺失、无需截图补录 — 这是本批案例里回写最干净的一条。sent_at / created_at。抖音客户端截图上显示的时间戳与落库时间存在数分钟偏移(客户端只在间隔较大时插入时间标签),一律以 DB 为准。
本案的「首响 4 天 11 小时」是全批最长的一条,很容易被误读成"系统慢"。恰恰相反:从评论到破冰送达只用了 4 分钟,采集侧完全达标;长尾 100% 发生在客户侧 — 他晾了 4 天半才想起来回。而更值得看的是后半段:这条迟到 4 天半的回复,AI 在 1 分钟内就接住了。
📌 口径提醒:给客户/运营看时效数字时,务必区分「Akke 侧时延」和「客户侧静默」。本案如果只报一个「首响 4 天 11 小时」,会把一次达标的 4 分钟触达 + 1 分钟秒接,误读成一次系统故障。建议报表里把这两段拆成两个独立指标。
本案内容侧是先扬后抑的典型:破冰(#1)共情、赠礼、反问三件事做得干净;但唯一一条跟进(#3)开口第一句就凭空生成了客户的户型。这不是措辞问题,是事实性幻觉,而且刚好打在这套话术唯一的价值主张上。
在灿哥聊装修的新房开工视频底下,他写下 「需要一份辟坑手册师傅,谢谢[玫瑰]」。这句话给出的信息:①诉求明确 — 直接说「需要一份」,不是围观不是抬杠,是伸手要资料;②态度客气 — 带「师傅」「谢谢」和玫瑰表情,是好沟通的人格信号,后续接受推销的容忍度更高;③但一个变量都没给 — 没有面积、没有房型、没有预算、没有城市。这是它拿 68 分(中意向)的原因:索要动作真实,购买规格为零。
intent_reason = 「问购·模糊·在调研」,comment_type_reason = 「索要避坑手册+感谢,极简购买信号」):产品型 · 低 specificity · active。首条 AI DM 在 transcript(#1)。它没有直接甩资料,而是先证明自己看过那条视频,再把资料包装成"内部的",最后用一个一字可答的反问收尾。
customer_profile 里也没有任何户型字段。
抛开幻觉不谈,#3 的结构其实很完整:认可回答("新房好")→ 给专业细节(层板数、铰链滑轨最容易被漏算)→ 埋价值钩子(工厂直供比门店低)→ 给一个必须换微信的技术理由("抖音发不了文件、发图也会压糊")→ 明确索取("报个vx号给我")。
尤其「抖音发不了文件、发图也会压糊」这个理由给得很聪明 — 它把"要微信"从一个推销动作,变成了一个为了让你拿到完整资料而不得不做的技术妥协,客户很难反感。这套结构值得复用,前提是把编户型的毛病治掉。
本案触达账号是「小星·全屋定制」(DB 内部账号名「零星」,聊天气泡右上角带金色「小星·全屋定制」徽章)。本案对账号信任度的考验比别的案例更重 — 客户不是当场秒回,而是晾了 4 天半再回来,这段时间里那条陌生私信能不能活下来,几乎全靠主页扛。
accounts.following_count(同步于 6-25)accounts 无粉丝字段 · 需运营主页截图补数Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案三层里只有第一层有值,且这唯一的一层在对话中完全没有被使用 — 既没被用来拉近距离,也没被用来提前拆掉地理顾虑。
comments.ip_location · 抖音 IP 反查comments.city · 客户全程未提所在城市source_accounts.city · 「灿哥聊装修」为知识号,市字段未入 → is_same_city = null知识号「灿哥聊装修」的视频,不是本地商家号 — 他心里大概率有「这家在哪、能不能给我做」的疑问,而两条 AI 消息都没碰这个话题。跟进里只说了"工厂直供",没有一句"外地也能发/全国安装"之类的地理兜底。这是一次可用而未用的机会。is_same_city = null,同城牌打不了,安装排期和物流报价也全悬着。建议补录号源城市字段。
本案对话里没有出现任何具体价格:没有单价、没有总价、没有活动价。全程唯一沾到价格的,是跟进里的半句 「工厂直供比门店低」 — 只有相对比较,没有任何数字。这不是遗漏,是这套打法刻意的选择。
"评论入库 → 评分 → 起草 → 发送 → 回复捕获 → 自动跟进"在 DB 里是几行状态变化,物理世界对应的是一台阿里无影云电脑上常驻的抖音客户端。本案是这条通道的正面样本:账号 channel_pref = cloud_pc,且横跨 4 天半的会话依然完整、回写零丢失。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,Akke 现阶段靠云电脑常驻 GUI 自动化触达:cron 派单进队列,云电脑上的 poll agent 拉单,用模板匹配 + SendInput 在抖音 PC 客户端里完成搜人、开会话、粘贴、发送;回复侧由捕获逻辑轮询会话并回写 messages。通道判定有硬证据 — accounts.channel_pref = "cloud_pc"。
channel_pref = cloud_pcmin_send_interval_seconds = 30本案 DB 里的 3 条消息与手机聊天截图逐条对齐、一条不差(AI 2 条 + 客户 1 条)。对照同批次里出现过"客户连发短消息被漏捕"的案例,本案证明:只要客户不是在同一分钟内连发多条,云电脑通道的捕获是可靠的,而且这种可靠性能跨越 4 天半的会话空窗——07-13 建立的会话上下文,07-17 深夜依然能被正确加载并生成带上文的跟进。
给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。本案的 BAD 只有一个,但它足够致命。
comments.ip_location = 山东,链路本身没丢数据。city 未标记 + 客户市级未公开:is_same_city = null,同城牌打不了,安装排期和物流都悬着。channel_pref = cloud_pc,不依赖运营本机手机和 ADB 线。1e025e4c-…-8a88fb3f7356c5df6c35-…-a4c2ceac8430 · stage ice_breakMS4wLjABAAAAXW6Y…gwnZc7642675465907391759 · 新房开工 · 号源「灿哥聊装修」(知识号)channel_pref = cloud_pc)· ≥30s/条