真心话
凌晨四点半的一道施工工艺题
她在山西。凌晨 4:49，别人都在睡，她在「阿进」的视频底下敲下一句 26 字的提问 — 精装房已经做了吊顶，柜子到底做通顶柜，还是照侧面那样吊顶后再做柜子。
2 分 32 秒后，破冰躺进了她的私信。这一条是全批 12 个案例里唯一一场纯专业问答 — 没有清单、没有报价、不急着要微信，两次回复都是正面给答案，第二次甚至给了她没想到的第三个方案。可惜其中一句「成都这边」，说给了一个山西客户听。
→ 抖音个人主页
从「通顶柜还是吊顶后做柜子」到一个她没想过的第三方案
下面三块是这条案例的原始信号：她留评论的那条视频、凌晨敲下的 26 字工艺提问、以及一小时里 3 条来回的完整对话。这场对话短，但每一条都很重 — 全批 12 条案例里，只有这一条从头到尾在谈专业，没有谈资料、没有谈价格。
完整对话 · 3 条来回
2026-07-19 凌晨 · 单通道 DM（无影云电脑）· 全部 3 条均已入库，无截图补录messages.role = ai，右侧紫色气泡）；#2 来自 DB（role = customer，左侧灰色气泡）。本案不存在截图补录 — DB 里的 3 条就是聊天页里的全部 3 条，回写零丢失。时间口径：本页所有时间取 DB
sent_at / created_at（已换算 CST）。抖音客户端截图上显示的时间戳与落库时间存在数分钟偏移（客户端只在间隔较大时插入时间标签），页面统一以 DB 为准。
凌晨四点五十二分，系统照常在两分半内把答案递过去
这条案例的时效数字漂亮，但更值得看的是它发生的时刻：客户在凌晨 4:49 研究「柜子要不要通顶」这种施工细节。这个时间点本身就是一条强意向证据 — 一个人被某个装修决策困扰到凌晨还在刷、还在问，他的温度比 73 分这个评级要高。而系统不挑时间，2 分 32 秒后破冰就到了。
近实时触达 · 凌晨时段无衰减
「通顶柜还是吊顶后做柜子」
中意向进入触达队列
小星·全屋定制
首响 57 分：客户 05:48 回了一段 60 字长文（DB gap 3,406,637 ms）。她没有秒回，但回得极认真 — 这一小时她大概率是在自己接着琢磨这个问题。
AI 二轮 2 分：05:48 → 05:50，跟进 99 秒内送达，接住了她的长文。
📌 本案的时效读法要多看一层：光看「2 分 32 秒」只能证明管道快，看「凌晨 4:49 的人」才能读出客户的真实温度。深夜/凌晨提问的用户往往是被具体问题卡住、当下就想要答案的人 — 建议把「评论时段」纳入意向分的辅助信号，凌晨 0–6 点的高质量提问值得上浮一档优先级。
全批唯一一场纯专业问答 · 先给价值，再问问题
这是本批 12 条案例里内容质量最高的一条，也是唯一一条从头到尾没有「加个微信发你资料」的对话。同批其他案例的打法是用清单/报价换联系方式；本案客户问的是一道真实的施工工艺决策题，AI 两次都正面把答案给了出来。结果也很直接 — 换来了全批最长的一条客户回复。
2.1 触发评论 · 一道有明确前提的工艺选择题
在「阿进」的视频底下，她写下 「精装房，柜子是做通顶柜还是和侧面一样吊顶后做柜子，谢谢」。这句话的信息密度远高于同批其它评论：①房型交代清楚 — 精装房，意味着有既定的交付标准和现成吊顶；②问题是二选一的具体工艺 — 通顶柜 vs 吊顶后做柜，不是「多少钱」也不是「有尺寸吗」；③她已经在做决策，不是在看热闹；④句尾还带了一个「谢谢」 — 一个把对方当人、也期待被认真对待的信号。这不是一条留言，是一个已经进场的人在求解。
2.2 系统给她打了 73 分
intent_reason = 「问工艺·具体·在调研」，comment_type_reason = 「问柜子做法方案对比」）：知识型 · 高 specificity · active。这是本批唯一被判为
knowledge 且 specificity = high 的评论 — 系统认得出「这个人在问真问题」。73 分压在中意向档，是因为 knowledge 型天然被视作"来学东西的"而非"来买的"。但本案给了反例：她后续交出了完整的方案对比和造价判断，说明知识型 + 高具体度的组合，实际购买阶段可能比一句「多少钱一平」更靠后（更接近成交）。建议评分模型对 knowledge + high + 凌晨时段 这个组合做一次回测。2.3 破冰文案 · 一个值得当范本的结构
首条 AI DM 在 transcript（#1）。它没有推销、没有报价、没有要微信，而是干了三件事：先证明读懂了，再给一个带前提的真结论，最后用一个决定性变量收尾反问。
效果可以量化：同批那些「发你清单/报价，加个微信」的破冰，客户回复普遍只有 2–4 个字（「三房」「新房」「96」）；本案破冰换来的是一段 60 字、把两个方案的造价和后果都列全了的回复（#2）。这是本案最值得沉淀的一条结论 — 破冰有多专业，客户就愿意交出多少信息。
2.4 跟进 · 唯一一条给出「第三选项」的案例
客户在 #2 里把纠结说得很清楚：吊顶要重做 vs 拆了直接一门吊顶，「造价是一样的，但不知道怎么选择」 — 她卡住的点是两个方案价钱一样，无从取舍。跟进（#3）没有替她在 A 和 B 之间投票，而是：①点出两个方案各自的真实痛点（拆了重做费钱 vs 留原吊顶柜顶积灰难清理）；②给出方案 C — 柜体局部吊顶收口 + 加防尘条；③补一句成本判断「造价差不多但更耐用」。
问题不在于这句话本身（要柜子位置是合理的下一步），而在于节奏：这种高专业度的对话，信任是靠"你又教了我一件事"一层层堆起来的，堆得越厚，后面要什么都好说。建议：knowledge 型高质量对话可以多撑一轮纯答疑再引导 — 比如先接一句「防尘条这块要注意的是……」，等她再回一轮，信任积到位了再要位置和微信。抢一轮的收益，远小于把人问沉默的损失。
凌晨收到一条懂行的私信，她会先点头像看你是谁
本案触达账号是「小星·全屋定制」（DB 内部账号名「零星」，聊天气泡右侧带金色「小星·全屋定制」徽章，运营归属夏夏）。本案的信任建立主要不是靠主页，而是靠 #1 那段带前提的专业判断 — 但客户点进主页那一眼能不能扛住，仍然是这条链路的必答题。
account_id: 8af08f10
channel_pref = cloud_pc
accounts.following_count（同步于 6-25）accounts 无粉丝字段 · 需运营主页截图补数相当于对话内的持续身份背书
但粉丝数、作品数、播放量在 DB 里全是空的，这一层无法评估，是观测盲区而非账号差。对本案这种被专业度说服的客户影响有限；对那种"先查户口再说话"的客户就是硬伤。建议运营补一次主页截图入库。
客户在山西 · 话术里却说「成都这边我见过不少客户翻车」
Akke 的地区信号分三层：客户 IP 属地（省）、自报现居（市）、号源服务市。本案只拿到省级 — 山西。而跟进话术里出现了一个明确的地名错配，这是本案唯一一处实锤硬伤，也是全批最值得立刻修的一条规则。
📍 地区粒度 · 省级已知，但话术说了另一个省的事
IP = 山西 · 话术 = 成都comments.ip_location · 抖音 IP 反查comments.city · 客户全程未提所在城市source_accounts.city · 「阿进」标为本地号但市字段未入 → is_same_city = nullip_location = 山西。这句「成都这边」有两个可能来源：①话术模板里的固定表述没有按客户地区替换；②persona 设定的所在地被原样带出。无论哪种，对一个山西客户说成都的经验，轻则完全无感（成都的房子跟我什么关系），重则让她意识到"这是套模板话术" — 而本案前面辛苦建立的专业信任，恰恰最怕这个。她在这条之后就沉默了；虽不能断言是这句导致的，但它至少是一处没有必要的减分。
本周建议（二选一，都可立刻做）：
① 动态替换 — 地区性经验话术必须按
comments.ip_location 注入客户所在省/市，模板里写占位符而不是硬编码地名；② 直接去掉地名 — 改成「我见过不少客户翻车」，一个字不损失说服力，还免掉了错配风险。在地区字段普遍缺市级的现状下，②是更稳的默认选项。
city 未入库，is_same_city = null — 既打不了"同城本地仓 / 本地安装队"这张强信任牌，也无法做安装排期和物流报价的判断。本案的地名错配本质上就是市级数据缺位的下游症状：没有可靠地区字段可用，模板只能写死一个地名。补录号源城市字段能同时解掉这两件事。
一个字的价格都没报 · 而这恰恰是对的
本案对话未涉及价格话术 — 模块跳过。但"跳过"这件事本身值得写一段：同批多条案例是破冰第一句就报 568 / 588 / 284 一平的打法，本案一个数字都没给。这不是遗漏，是场景决定的正确选择。
卖的是"少踩坑"，不是"便宜"
而 #3 处理得恰到好处：既然客户把造价摆上桌了，就用相对造价接住 — 「造价差不多但更耐用」。这句话回答了她的成本顾虑，又没有引入任何需要后续兑现的具体数字，不给自己挖坑。对照同批「568/㎡ 没说按投影还是展开面积」那类悬空报价埋下的预期差，本案的克制反而更安全。
3 条消息，3 条都在库里 — 本批回写最干净的一条
"评论入库 → 评分 → 起草 → 发送"在 DB 里是几行行变化，物理世界对应的是一台阿里无影云电脑上常驻的抖音客户端。本案是通道演进后的样本：账号 channel_pref = cloud_pc，不依赖运营本机手机和 ADB 线；而且聊天页里的 3 条消息，DB 里一条不少。
7.1 当前 · 无影云电脑通道
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽，Akke 现阶段靠云电脑常驻 GUI 自动化触达：cron 派单进队列，云电脑上的 poll agent 拉单，用模板匹配 + SendInput 在抖音 PC 客户端里完成搜人、开会话、粘贴、发送。通道判定有硬证据 — accounts.channel_pref = "cloud_pc"（运营归属：夏夏）。
channel_pref = cloud_pcGUI 自动化 · 非本机 ADB / WDA
min_send_interval_seconds = 30连续失败 0 次 · 无冷却 · 队列无失败重试记录
7.2 回写完整度 · 3 / 3 全中
本案不需要任何截图补录：2 条 AI 消息 + 1 条客户回复全部进了 messages 表，且客户那条 60 字长文完整入库、没有被截断。对照同批出现过的"客户三分钟连发三条、DB 只捕到最后一条"，本案的回写是干净的 — 捕获逻辑在"单条长消息、间隔充裕"的场景下表现良好，问题只出在连发短消息。
last_queue_error = null · 无重试记录next_followup_at = null、last_outbound_at = null、last_inbound_at = null、handed_off_at = null，followup_policy 停在 standard。也就是说，这条已经聊出真专业度、且客户只是"没接上话"而非"拒绝"的对话，当前没有任何自动跟进被排上日程。本案客户的价值明显高于评分档位（凌晨提问、60 字长文、有明确工艺决策在手），让它就这么静置是最大的浪费。建议：对
knowledge + high specificity 且已产生长文回复的会话，自动排一次 T+1 的软跟进，而不是等人工发现。
答案已经给到位了 · 但最后半步走急了
业务实质：客户凌晨 4:49 主动提问、57 分钟后交出 60 字的完整方案对比 — 意向温度高于 73 分的评级；但尚未给微信，也未进入销售交接，且跟进节奏字段全空（
next_followup_at = null）。下一步：①补一轮纯答疑再引导 — 不要重复追问柜子位置，改发一条不索取的干货（如「防尘条选型 + 局部收口的施工顺序」），把上一轮抢掉的信任补回来；②修掉「成都这边」 — 立刻改话术模板，地区经验句要么按 IP 动态注入，要么去掉地名；③手动给这条会话排一次 T+1 软跟进，别让它静置；④拿到柜子位置/户型后再顺势推微信（出方案是天然理由）。
这个项目哪里做得好，哪里还能拧紧
给上面 6 个分析模块各打一个评价。good = 已达可复用标准；mid = 能用但有压缩空间；bad = 是这条链路的明显短板。本案是全批内容质量最高的一条，短板集中在一处 — 地区。
时效性 · 凌晨照跑，2 分 32 秒送达
GOOD- 本批最快一档：04:49:31 评论 → 04:52:03 送达，全程 152 秒。
- 凌晨时段零衰减：4-5 点跑得和白天一样快，评分与破冰落在同一分钟。
- 二轮跟进 99 秒：客户 05:48 发完长文，05:50 就被接住。
- 「凌晨提问」这个强信号没被系统利用：一个人 4:49 还在琢磨吊顶怎么做，温度明显高于 73 分档，但评分模型对时段无感。
- 本周建议：把评论时段纳入意向分辅助信号，0–6 点的高具体度提问上浮一档优先级。
内容 · 全批唯一一场纯专业问答，且给了第三方案
GOOD- 破冰结构可当范本：复述问题 → 给带前提的真结论 → 用决定性变量反问，先给价值再提问。
- 破冰深度换来回复深度：同批「清单换微信」的破冰只换回 2–4 个字（「三房」「新房」「96」），本案换回 60 字长文 — 这是本案最值得沉淀的结论。
- 唯一给出第三选项的案例：客户纠结 A/B 且造价相同，AI 给出「柜体局部吊顶收口 + 防尘条」的 C 方案，同时解掉两边痛点。
- 全程不推微信：两条 AI 消息都在正面答题，没有一句"加个微信详聊"。
- 结尾从顾问切回销售太快：客户刚拿到满意答案还没消化，就被追问柜子位置，此后沉默。
- 本周建议：knowledge + high specificity 的对话多撑一轮纯答疑再引导 — 抢一轮的收益远小于把人问沉默的损失。
账号信任度 · 靠专业度赢的，资产层仍是盲区
MID- 内容型信任建立得极快：她没问"你们是哪家公司"，直接把精装房现状和两套方案的造价全盘托出。
- 对话内持续背书：每条 AI 消息带「小星·全屋定制」金色徽章。
- 账号健康：active、连续失败 0、无冷却、无队列报错。
- 粉丝数 / 作品数 / 播放量在 DB 里全空：这一层无法评估，是没数据不是账号差。
- 本案侥幸绕开了：她被专业度说服所以没去查户口；换个"先看主页再说话"的客户，这个盲区就是硬伤。
- 本周建议：运营补一次主页截图入库。
地区 · 对山西客户说「成都这边」
BAD- 没有强行套近乎：破冰没有显式提「山西」，避免了"被画像"的反感。
- 实锤错配：#3 说「成都这边我见过不少客户翻车」，而客户
ip_location = 山西。要么是模板硬编码地名没替换，要么是 persona 所在地被原样带出。 - 代价不对称：对山西客户说成都的经验，轻则完全无感，重则暴露"这是套模板" — 而本案前面辛苦立起的专业信任最怕这个。
- 市级两端全缺：客户市未公开 + 号源「阿进」
city未入库 →is_same_city = null，打不了本地仓/本地安装队这张牌。地名错配本质就是市级数据缺位的下游症状。 - 本周建议：地区经验话术按
ip_location动态注入；在字段普遍缺市级的现状下，更稳的默认做法是直接去掉地名，改成「我见过不少客户翻车」— 一个字说服力都不损失。
价格 · 一个数字都没报，而这是对的
GOOD- 专业问答场景下不报价是正确选择：客户问的是工艺决策，插一句活动价会把咨询当场降级成推销。
- 用相对造价接住成本顾虑：客户说「造价是一样的」，AI 回「造价差不多但更耐用」— 回答了顾虑，又不引入需要后续兑现的数字。
- 对照同批更显克制的价值：破冰即报 568/588 那类，埋下了"按投影还是展开面积"的口径悬空风险；本案没有这个坑。
- 「差不多」还可以再落地一点：补一句量级参照（省下的整拆费用基本覆盖防尘条成本），能让判断显得是算过的而非说说的。
- 这是锦上添花，不构成短板。
信息流转 · 回写零丢失，但跟进节奏没排
MID- 回写 3/3 全中：聊天页里几条，DB 里就是几条，无需截图补录 — 本批最干净的一条。
- 60 字长文完整入库未截断：捕获逻辑在"单条长消息 + 间隔充裕"场景表现良好。
- 通道有硬证据：
channel_pref = cloud_pc，云电脑 GUI 自动化，≥30 秒/条节流，队列无报错。
- 会话节奏字段全空：
next_followup_at/last_outbound_at/last_inbound_at/handed_off_at均为 null，followup_policy停在 standard。 - 高价值会话被静置：客户只是"没接上话"不是拒绝，却没有任何自动跟进排期 — 本案是最不该被晾着的一条。
- 本周建议：对 knowledge + high specificity 且已产生长文回复的会话，自动排 T+1 软跟进。
- 评论
fbf02039-…-8ab15427cf09- conversation
d60ff7b2-…-8dfec68bd876· stage ice_break- comment_time
- 2026-07-19 04:49 CST
- 入库 / 评分
- 2026-07-19 04:52 CST
- 抖音昵称
- 真心话
- sec_uid
MS4wLjABAAAA5_Ds…lXubQX- IP 属地
- 山西（自报市未公开）
- 头像
- 已缓存
- intent_score
- 73 / 100
- intent_label
- 中意向
- comment_type
- knowledge · high · active
- video
7658612683017492402· 号源「阿进」· 本地号（市未标记）
- 发送账号
- 小星·全屋定制（内部名：零星）· 8af08f10
- 账号资产
- 402 关注 · 粉丝/作品未抓取 · active
- 通道
- 阿里无影云电脑（
channel_pref = cloud_pc）· ≥30s/条 - 客户回复
- 1 条（DB 1 + 截图 0）· 精装房 · 已做吊顶 · 两方案造价相同