她在安徽。在桂林本地号「深度空间装饰王工」的工地实拍视频底下,留了 14 个字 — 「只设计软装可以不,怎么联系🌹」。
Akke 在 3 小时 49 分内拟了一段「软装能做 + 安徽梅雨季 + 几室几厅」的破冰,账号「饭粒(一筑·全屋定制)」走 ADB 真机推了出去。次日早晨她回了 — 「加 v 上聊吧 shiw223」,没寒暄、没问价。
videos.craft_terms = [] 但 4 个 hashtag 都进了数组(标准抓取,没有内联问题)。评论却问的是「软装」 — 跨业务线的轻度错位。这说明她看视频不是为了找施工方,而是顺着「装修」大词刷下来,看到有家公司在做就直接问她真正想问的(软装)。视频内容是引流入口,不是需求匹配。
在深度空间装饰王工(号源池里的一个桂林本地装饰公司号源,category_v2 = peer_decoration,属同行号源)发的那条工地实拍视频底下,她打了 14 个字加一朵 🌹(原评论)。其他「求联系」类案例(空间向量「我房子准备装修怎么联系你」、刚子道场「能联系下你吗」)开口都不限定服务范围;这条主动加了一个约束 ——「只设计软装」。3 件事同时暴露:①「只 X」= 她已经在筛供应商、分项目预算、不再处于"广撒网"阶段(用排除性副词的客户已经过了"什么都问问"那一段);②「怎么联系」+「🌹」= 礼貌的直接,软度很高(柔性买家信号);③ 跨省(安徽 IP / 桂林号源) = 不在意工厂在哪,关心能不能做。
视频信号与评论信号的明显错位:视频是工地实拍 + 靠谱工长方向(硬装 / 施工管理),看这种通常是装修中后期、要监工或验房的人。但她问的是软装(家具 / 灯具 / 窗帘 / 软饰)。这说明她不是顺着视频内容找匹配服务,而是顺着「桂林装修 / 装修公司」hashtag 大词刷下来,看到这家公司在做装修就直接问她真正想问的(软装)。视频内容是引流入口,不是需求匹配 — 软装是一个独立诉求,她需要的是有人能只接软装单。原评论的「只」字是关键 — 假设没有这个字,破冰话术会落入泛泛的「能做装修」回答;有了「只」,AI 立刻知道不要谈柜体 / 不要谈硬装,必须先在第一句话里把「软装我们能做」明确说清楚。
主页画像 inference · 重复商业型评论 ·
同一 sec_uid 在 2026-05-19 还问过另一条视频:「火锅店正在找装修公司,能设计吗🌹」(intent_score 33 / 低意向,触线-餐饮商铺装修)。两条评论的句式高度相似(「X 可以不 / 能 X 吗」+「怎么联系」+ 🌹),看起来是同一个人在不同场景下的标准问询模板。
3 种可能解读:① 她确实有多重身份(自家住宅软装 + 商铺装修都在筹备);② 她是装修中介 / 经纪人,帮不同需求方挂网询价;③ 她是设计师,找硬装承包方搭软装方案。本案不下定论 — 但 ACT 04 加微后第一句话应当探一下身份("是您自家还是有其他项目?"),customer_profile 可以留 multi_inquiry_signal = true 标记。
comments.ip_location · 抖音 IP 反查,可能偶尔漫游波动comments.city · f2 USER_DETAIL 抓不到自报市(客户未填或 profile 抓取被风控降级)source_accounts.city · 桂林本地装饰公司号源,属 peer_decoration(同行)类,客户在安徽 → 同城判定无效,is_same_city = nullcomments.city = NULLdeclared_city。
20260512173500)要求两边 city 都非空且号源市 ≠ "全国"。本案号源市是桂林、客户安徽 — 即使补抓到自报市是合肥,也仍是 false。跨省同行号源天然不打这个钩,但能拿省级气候 + 软装场景接业务,弥补了一部分。
Akke 的分析 cron 把评论喂给 LLM(DeepSeek V4 Flash)评分。模型读到「只设计软装可以不,怎么联系🌹」给出 knowledge 型 · medium · active = 60 分 / 中意向。但她进的是 5 人本地拉号通道(scripts/pull-fresh-leads.py)— 该脚本有自己的本地加分逻辑(强买家信号 +25),所以最终在 today-openers 里她排到了 85 分 / 高意向 区段,被纳入「24h 60+ DM 批次」。
comments.intent_reason)首条 AI DM 已在源料 pack 内(#1)。这条破冰跟空间向量的四段式有一个关键变体:第 ① 段不绕弯,开门见山「软装我们能做」。其他案例的 ① 段通常先复述视频内容("联动拉篮安装得看轨道承重"),再绕回业务;但本案视频是工地实拍(硬装方向),客户问的是软装 — AI 复述视频反而会显得"答非所问"。所以 AI 把 ① 段直接给业务确认("软装我们能做,全案搭配、灯具窗帘家具都包"),再用「上门量尺设计也免费」把"只设计"的预算焦虑卸下来。客户切了范围,AI 的第一句话必须先回答「能不能做」这个范围问题。
sanitizeReply 兜底替换层(生成后 string-replace 一次)。本案客户回复了 — 但若被抖音 IM 风控扫到敏感词,发送 / 投递率会受影响。
抖音对 web 端陌生人 DM 的封锁极严(Fly Tokyo 出口 IP 在 IM 入口直接挂掉)。Akke 的发送路径绕过 web 完全走真实物理设备 + 系统级自动化。本案走的是5 人本地运营流程(饭粒 / 野荞 / 夏夏 / 阳阳 / Gus)— 不走 message_queue / 不走 Dashboard / 不走 worker,由运营 Mac 通过 ADB 直接驱动 Android 真机注入文本。AKKE_ACCOUNT_ID = c5d236e1-…-506dfd09699b 锁定账号「饭粒(一筑·全屋定制)」,绑定抖音号 54362559027。
scripts/dm-phone-sender/send-one.pycomments.status = skipped、conversations 表对该 sec_uid 没有记录 — 这不代表 DM 没发,恰恰相反。5 人本地流程默认不写 message_queue(避免与 cron 抢号),需要运营在发完后手动调用 scripts/mark-contacted.ts 才会同步 conversation + messages + 反写 comments.status = contacted。本案 sent_at = 2026-05-24 14:34:19 已记录在 today-openers.json,但 mark-contacted 还没补 — 这会导致同 sec_uid 4h 后被其他同事重新 claim 重发(lead_claims dedup 失效)。下一步:运营在二次 commit 前先跑一次 mark-contacted,再回填截图。
Akke 在 2026-05-24 14:34 推送。次日早晨(2026-05-25 上午)运营开 inbox 时看到她回了 #2 — 「加 v 上聊吧 shiw223」。没问「你哪家公司」「能不能先发个目录」「软装报价多少」,跳过所有验证步骤,直接给了自己的微信号。这跟空间向量(5 天 + 给的是老公的 v)形成鲜明对比 — 同样是「客户给微」的收尾,但小角落给的是自己的 v,决策权完全在她手上、不需要分工对接。
决策权集中型买家的标准收尾 · shiw223
小角落、七七笑嘻嘻、草莓圣戴这三条案例的共同点:客户给的都是自己的微信号,回复都极简(小角落「加 v 上聊吧 shiw223」/ 七七「我 v xueMjiu」/ 草莓直接报 v)。没寒暄、没追问、不验证,跳过所有「先聊聊看」的中间步骤。
这跟空间向量(5 天后给的是「老公 v」)的分工型决策是对立的两种典型 — 决策权集中型买家的决定密度很高:①评论里已经主动框定 scope(小角落「只设计软装」/ 七七「我需要装修怎么联系」/ 草莓直接报需求);②回复完全省略了「聊聊看」「问问看」的探索动作 = 对方已经把这家排到了「准签约」位置;③不需要再走分工流程,自己就能拍板。
运营加 v shiw223 时的话术应当反映这点 — 不需要解释身份、不需要"嗨我是 Akke 工厂"的破冰开场(这条 DM 已经做过了),直接进 ACT 06 提到的「软装方案具体化」第一句话。她已经决定要聊,浪费她时间在二次介绍上反而显得不专业。
shiw223 第一句话
她已经在 DM 里给了 v、说了「上聊吧」 — 这已经是她的「破冰」了。运营加 v 通过后第一句话不要重复破冰("嗨我是 Akke 工厂" / "我们是做软装的")— 她在抖音端已经知道了,再说一遍只会让她觉得「这边没读上下文」。正确做法:直接跨过自我介绍、进具体方案动作,假定她已经准备好聊细节。
multi_inquiry_signal。不要做的事:①重复破冰、②寒暄超过半句、③推销活动促销价(她没问价,先别报)。shiw223 加上之后,所有动作直接进具体化阶段。
comments.status = skipped、conversations 表对该 sec_uid 仍无记录(5 人本地流程默认不写 message_queue,mark-contacted 还没补,customer reply 还在抖音 inbox 没回流)。npx tsx scripts/mark-contacted.ts --comment-id=e3a707b4-… --douyin-user=MS4wLjABAAAAXl91… --content="…opener…"(同 ACT 04 signal — 不跑的话 4h 后她可能被其他同事重新 claim 重发,她已经给 v 了,重发会很尴尬);②运营在饭粒账号的微信上加 shiw223,第一句话按 ACT 06 SOP(不重复破冰 + 直接接「只设计软装」+ 探身份 + 给 1-2 个具体动作);③加 v 通过后 customer_profile 写入 own_wechat = shiw223、decision_type = sole(决策权集中型,对照空间向量的 decision_split)。这条线索 ice_break 阶段已成功收尾,等 handoff。
sanitizeReply 加 string-replace 兜底层,作为最后一道保险。本案客户回复了 — 但若被抖音 IM 风控扫到敏感词,发送 / 投递率会受影响,不能依赖运气。scripts/mark-contacted.ts:标 lead_claim consumed + UPSERT conversation + INSERT message + 反写 comments.status=contacted。不调的话 4h 后该 sec_uid 会被其他同事重新 claim 重发(lead_claim 过期 + 无 conversation 阻挡)— 客户当天可能收到两条同样的破冰,体验差 + 触发风控双倍风险。本案客户已经给微了,重发会非常尴尬。这是5 人本地流程的最大单点漏洞,应该把 mark-contacted 嵌入 send-one.py 的成功回调里,让运营不需要记得手动调。decision_type = sole,与 decision_split 区分。skipped · 待 contactede3a707b4-…-719399752f607643284049658856229MS4wLjABAAAAXl91uPoQ…LVzfhome · hashtag 数组完整
软装怎么联系· 抖音 cid7643284049658856229