你的丫头
73 分中意向 · 同行装修号下问「门做三段还是两段」，聊成一场老房改造咨询

一句「门做三段还是两段」，怎么聊成一整场老房改造咨询

下面三块是这条案例的原始信号：一条问门体工艺的 knowledge 类评论、它所在的同行装修号视频、以及当晚一来一回 14 条的完整对话。先看全貌 — 破冰不塞资料、直接上工艺建议，客户被接住后一层层吐出老房底细（十多年、原来的门、厨房太潮、预算有限），每一条都被专业接应。注意 #5 那条不是客户发言，是抖音 IM 的火花系统提示被误存进对话——真实客户有效回复只有 6 条。

你的丫头 📍 浙江

门分三段好一点还是两段好点，总高2.8米，给点建议

2026-07-11 18:12:01 CST（入库 18:15:43，gap 3m42s）· 评论于「阿进」视频（号源类目：同行装修号）· 关键词 [门, 建议]

📹 评论所在视频（在抖音打开）· 号源「阿进」· 类目「同行装修号」

傍晚 6 点的评论 8 分钟破冰 · 客户当场秒回、全程分钟级

本案时效是全批最干净的一条：评论 18:12:01 留下，18:15:43 入库（gap 3m42s），18:20:29 破冰送达 — 全程 8 分 28 秒。而且客户在线：破冰后 27 秒就回「老房」，之后每一跳都在分钟级（#3 68s、#13 10s、#14 8s）。唯一的长间隔是客户 #7 抛出「厨房太潮」后，我方 #8 隔了约 3 小时才重启——这是本案时效上值得收紧的一处（详见复盘）。

破冰直接上工艺、句句接得住老房底细 · 内容是本案最硬的一环

这是本案最亮的一环。客户是 knowledge 类、评论问的是「门做三段还是两段」这种硬工艺问题，破冰没有绕圈，而是正面给建议（门洞 2.8 米配多层板做三段）+ 反问新房还是翻新。之后客户每吐一句底细，AI 都精准接住：老房层高不匀→三段适应误差、房龄十多年→20 年老房案例背书、门不换→柜体配合门洞收口、厨房太潮→糯米胶/PUR/多层板防潮、预算有限→只做上柜省料。唯一要留意的是 #5 系统消息混入，好在 AI 没被它带偏、跳过继续接客户的「原来的门」。

2.1 触发评论 · 硬工艺 knowledge 信号

在同行装修号「阿进」的视频底下，她问「门分三段好一点还是两段好点，总高2.8米，给点建议」。这是全屋定制里典型的 knowledge 类（问工艺）信号 — 带具体参数（2.8 米）、在调研做法、指向真实施工场景。系统据此判成 knowledge、active、specificity high，73 分中意向。相比纯「求资料」，问具体工艺往往说明客户已进入施工决策的前期。

2.2 系统给她打了 73 分

2.3 破冰文案 · 直接给工艺答案 + 反问场景

首条 AI DM（#1）四段很扎实：先正面回答三段 vs 两段的取舍、再落到她给的具体参数（2.8 米配多层板做三段）、给出品牌/材质锚点（兔宝宝 ENF）、最后用「新房还是翻新」反问收口把话头接住。knowledge 类客户最吃「你是真懂行」，这条直接答题就赢了信任。

2.4 跟进 · 顺着老房底细一层层接，正面处理预算敏感

专业话术撑住了 6 个来回 · 但发送号主页厚度仍是未知数

本案客户没有做任何身份检查（没问「你是做什么的 / 你们是哪家」），凭工艺专业感就聊了 6 个来回、吐出了老房全部底细 — 说明话术专业度足够撑住信任。但发送号「有大有小」的抖音展示资产依然未抓，若客户回头点主页确认「你到底是不是做这行的」，主页厚度心里没底；再叠加对话里几处外地地名（成都/福州/玉林），信任基座并不牢。

浙江客户 ×「同行装修号」号源 · 省级在手却报了外省案例

Akke 的地区信号分三层：客户 IP 属地（省）、自报现居（市）、号源服务市。本案只拿到省级（浙江）、客户没自报市；号源「阿进」是同行装修号、服务市字段未标，同城比对无从进行（is_same_city = null）。更值得警惕的是：opener 没提地区是对的，但跟进话术里连报「成都装房 / 福州老小区 / 玉林小区」三个外省地名，跟客户的浙江属地明显对不上。

对话未报一个具体价 · 但客户主动亮出「预算有限」，被正面接住

本案对话没有出现任何具体价格（没报单价、没报总价、没抛优惠）。真正的价格戏在客户侧：#10「预算有限，赞不考虑」是一条明确的价格敏感信号 — 客户主动划了预算红线。AI #12 的接法值得表扬：不回避、不硬推贵料，直接给出「只做上柜避湿区、省料省预算」的降本方案，把预算约束转成了具体可执行的省钱路径。

自动链路把人聊得很深 · 但入站捕获混入了平台系统消息

「评论入库 → 评分 → 派单 → 发送 → 入站捕获」五段在本案基本工作正常：opener + 后续共 14 条消息完整回写、无漏。但入站捕获暴露了一个问题：#5 这条抖音 IM 的火花 / 合养精灵游戏系统提示，被当成客户消息误存成 messages.role = customer — 这会污染「客户回复条数」「last_inbound」等统计口径，也可能误导 AI 上下文。好在本案 AI 没被带偏，但这是一个需要在入站侧加过滤规则的信号。

7.1 当前 · 无影云电脑·网页版 DM

7.2 云电脑常驻托管 · 5 步链路，本案 4 达标 1 有瑕

标准 5 步（常驻环境 / 调度 claim / 执行发送 / 自动回写 / 失败复核）本案发送侧全部达标，唯一瑕疵在「自动回写」的入站捕获环节：把抖音火花系统消息也当客户消息落了库。这类平台系统提示（火花 / 合养精灵 / 互动激励）应在入站侧按规则过滤掉，不进 messages、不计客户回复。

73 分中意向 · 聊得很深但停在专业问答 · 未推进到加微

这条案例哪里做得好，哪里还能拧紧

给上面 6 个分析模块各打一个评价。good = 已达可复用标准；mid = 能用但有压缩空间；bad = 是这条链路的明显短板。本案内容极强、却卡在没推加微，是「聊得深 ≠ 推得动」的典型样本。