她 IP 广东,老家在湖南娄底双丰。下午 3 点 04 分,她在一支工厂号视频底下打了一句:「湖南娄底双丰来不」。
9 分钟后系统就把破冰 DM 送到她抖音私信。1 小时 25 分她回头来一句 「我只做橱柜」——这之后,PM 在同一通对话里连续做了 L1 试水 → L2 配合 → L0 缓拒 → L1 表情 四档判定,每档按 6/23 新决策卡矩阵切换 AI 推进档。本案按 6 个模块复盘——做到位的、违规抢 v 的、与还能拧紧的。
下面三块是这条案例的原始信号:留评论的工厂号视频、那八个字直接问"来不来"的评论、以及由 AI 破冰 + PM 现场调用决策卡矩阵 接力 4 轮后落到 运营违规抢 v 的 10 条完整对话。先看全貌,再进入每个模块的拆解。
下方各模块在拆解时用 #1-#10 引用回这里。注意:DB 仅入库 #1 opener,#2-#10 是 PM 在本会话里逐句调取 6/23 决策卡推矩阵 + 运营手动 ADB 接力发送 + 客户截图回灌的全实战记录,writeback 未跑。
ice_break 与真实状态不符。
时效是 Akke 链路最先体现的工程指标。本案 9 分 9 秒 从评论到首条 DM 送达,是模块化样本里最快档(vs 珊珊 2h53m / 灯火阑珊 14 天)。这条速度让客户记忆里的视频还没翻篇就收到了破冰——是后续 1h25m 内收到首响的硬基础。
📌 9 分钟里 scrape cron 把评论从抖音抓回本地 + LLM 完成 78 分中意向评分 + opener 生成 + 本地真机推送一气呵成,没有任何一段拖后腿。这是 1h25m 首响的硬基础:客户刚发完评论没几分钟就收到回应,记忆里视频还热乎,回应概率明显高于隔天才收到 DM 的样本。
内容侧是评分模型 + 破冰话术生成 + 跟进话术生成三层共同决定的:客户留了什么、系统看到了什么、AI 写了什么、PM 调矩阵让运营怎么接力。本案的特殊性在于 PM 6/23 新决策卡当天首例实战——5 轮跟进每轮都按矩阵选 AI 推进档,逐档变化能看到话术结构怎么动。
在 石材橱柜板材批发(号源池里类目「工厂号」的石英石台面 + 橱柜板材账号)的视频底下,她只写了八个字:「湖南娄底双丰来不」。三件事一上来全暴露:①地理可达性 — 她在确认"你们能不能服务到湖南娄底双丰";②IP 广东 vs 自报湖南娄底 — 典型"在外打工 / 老家装修"客群,决策周期长但购买信号实;③"来不"用湖南方言 — 老家身份认同感强,破冰应当用同方言接回。
首条 AI DM 在 transcript(#1)。她问"娄底双丰来不",opener 直接用"来得来"湖南话接回——做对了。但 opener 也有两处可改:①把"双峰"打成"双丰"原文不报(开头复述错地名);②反问"几室几厅 + 准备先动哪一组"是两个问题,违反 self-check 第 3 道(一轮只 1 个问题)。
#3-#10 共 8 条是 PM 在本会话里现场调用 6/23 新决策卡 让运营接力的——每轮判档 + 矩阵选 AI 推进档 + 写话术 + self-check。4 轮档位变化(L1→L2→L0→L1 表情),前 3 轮按矩阵走、末轮翻车抢 v。
enterprise-data/youdayouxiao/data/product_knowledge.json 拉真实产品规格 → "18mm 多层板,兔宝宝/莫干山/千年舟三大牌任选,ENF 级"。这是 RAG 纠错的典型用例——LLM 的"通用装修常识"对每个客户都对不上,必须接产品资料库。DM 进入之后,客户的第一反应是点头像验证身份。本案的触达账号是「小星·全屋定制」——内部 DB 名为"零星",运营是夏夏。账号主页画像本次未自动抓取(需手动补主页截图),但客户在 #10 前的对话里说出 "您主页视频拍得很不错哈哈" ——这是客户自己提供的反向证言:账号视频内容质量达标,至少没被一眼判定为营销号。
accounts.id = 8af08f10-…-9efbda00000000-…-0001(有大有小)Akke 的地区信号分三层:客户 IP 属地(省)、评论里自报的城市(市)、号源服务市。本案三层中两层都明:IP 广东 + 评论自报 湖南娄底双丰。这个双信号组合是装修流量里非常常见的"在外打工,老家装修"画像——决策周期偏长但购买信号实。opener 接住了老家"双峰"(即便误打成"双丰"),但 IP 广东这层没用上。
comments.ip_location · 抖音 IP 反查comments.content · 客户原话source_accounts.city · 工厂号无市级标签 → is_same_city = null#1-#9 9 条全程没出现任何价格数字,原因合理:客户从来没主动问价、还没暴露户型/数量/阶段,主动报价没有锚点反而显得不专业。但末轮 #10 抢 v 时承诺 "最低报价"——这是把价格锚直接压到地板的潜在风险。
"评论入库 → 评分 → 起草 → 真机发送"在 DB 里是 #1 这条的几行变化——但 #2-#10 共 9 条对话完全没入库。本案是PM 现场调决策卡 + Claude 写话术 + 运营手动 ADB 发送 + 客户截图回灌的人肉接力流程,没有任何一步走 message_queue / messages 表的标准链路。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,Akke 现阶段靠本地物理设备 + 真机自动化触达。本案首条消息(#1)由内部账号「小星·全屋定制」承接,message_queue.error_message 为空、子通道字段未入库,按案例规范如实标注"需手动判定"。
conversations.stage 仍是 ice_break——实际客户已配合到 L2 又退回 L0;
②messages 表只有 #1 一行 outbound,没有 #2-#10 任何一条;
③last_outbound_at / last_inbound_at 都是 NULL —— 自动跟进 cron 不知道这条已经对话到第 10 条;
④本 user 4h 后理论上还会被自动 claim 重发——典型的writeback 漏导致重复触达风险(参考既墨 5-25 重发事故);
⑤Langfuse trace 里看不到 PM 决策卡 4 轮档位切换的真实数据,模型迭代失去黄金训练样本。
云电脑迁移的最大价值就是把人肉接力变成有审计的链路——所有发送统一通过云端调度器,子通道、节点、时间戳、PM 决策档位一并入库。
ice_break、followup_policy = standard,但真实状态是末轮 #10 运营抛 v 后等客户回应。 截至数据快照 2026-06-23 18:00 CST,客户尚未回复 #10。给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。
ice_break vs 真实 L2 又退回 L0 已抢 v。410b13da-9a84-460e-80a7-a122d66a0809ice_break ← 与真实状态脱节7f1508db-…-bdde0dMS4wLjABAAAAs-FT…1jO00000000-…-0001)