系统
个人微信单聊 · 客户备注「湘A逆风也绽放💋kfc00070007」。执行器跑在 Windows 云电脑
salespc-desktop-ehf2mjt 上——与同一天的闽D想家是同一台。逆
USER JOURNEY · 一句软性推迟 → 一句正确的应答 → 然后没有然后湘A逆风也绽放
湘A逆风也绽放
客户说"过些天联系你"，AI 那一句回得对
同一天、同一台机器上的另一条个微对话。全程只有 4 条消息，AI 只说了一句："好的，您先忙，有需要随时找我～"——没追问、没塞资料、没催，这一句是对的，而且能在库里查到它当时命中的规则就是这么写的。
值得写成一页的是它旁边那三件事：客户 19:11 发的消息，系统 19:35 才看到；同一个人在库里被建成了两条会话；客户说了"过些天"，而系统没给这句话留下任何一个待办。
1 条 AI 回复13 个字 输出，读入 16,202 token24m53s 客户等待⏸ 客户主动推迟，未跟进
1
加好友承接
9-21 14:45
2
通过验证
9-21 14:45 后
3
客户回应
9-21 19:11
5
AI 应答
9-21 19:36 ✓
6
等客户联系
进行中
7
建后续提醒
未建立
8
再次联系
未发生
00 · Full transcript
完整聊天记录与逐句积木标注
整条对话就这 4 条。AI 那条是数据库原文，下面的"真实调用"是 llm_call_provenance 里当时那一次的记录。这条对话里没有图片，但有两个时间戳值得盯着看。
销售（手打）
我们是有大有小全屋定制，兔宝宝ENF多层实木原价868现在征集样板房，每平方补贴300只要568，加微申领补贴
系统
你已添加了逆风也绽放💋，现在可以开始聊天了
湘A逆风也绽放
你好，我过些天联系你
AI 自动回复
好的，您先忙，有需要随时找我～
系统
对话停在这里。
next_followup_at = 空，followup_count = 0，阶段 nurture。01 · Customer context
用户背景与核心需求
诚实地说：我们对这位客户几乎一无所知。他只说了一句话，而且是让我们别打扰。这一节把"已知"和"不知道"分开列，因为后者才决定了下一步该怎么做。
✅
确定知道的
备注名带"湘A"（长沙车牌）与微信号；通过了好友验证；看过那条 568 样板房补贴的招呼语。
⏳
倾向性判断
他大概率不是拒绝——"过些天联系你"是推迟，不是"不需要"。加了好友没删，是留着的。
❓
不知道：有没有装修需求
他没说房型、没说面积、没说在哪个阶段。加好友的动机可能是补贴，也可能只是随手通过。
❓
不知道：为什么等了 4.5 小时
14:45 加上，19:11 才回第一句。中间发生了什么、他看没看过消息，系统这边没有任何记录。
❓
不知道："过些天"是几天
这是本案最关键的空白：没有日期，就没法安排跟进，只能被动等。
◐
决策阶段
接触期 → 需求未暴露。无尺寸、无报价、无到店、无成交。
02 · Conversion timeline
完整转化时间线
从加好友到 AI 应答，4 小时 51 分钟，一共 4 条消息。真正值得看的是最后半小时里的三个时间戳。
14:45
销售手打招呼语，客户通过验证
微信截图"原价868…补贴300只要568，加微申领补贴"——与同一天闽D想家那条是同一个模板。这条是人工发的：个微 AI 首触目前只判断不发送。
14:45 – 19:11
四个半小时的沉默
无记录客户通过好友后没说话。期间我方没有任何动作——这一点是对的：刚加上就追问，是这条链路最容易犯的错。
19:11
客户开口，内容是推迟
微信截图"你好，我过些天联系你"。这是整条对话里客户说的唯一一句话。它同时是三件事：一个软性推迟、一个未落地的时间承诺、一次仍愿意保留联系的表态。
19:35:53
系统这一刻才看到它
数据库落库消息落库、会话被创建，距客户发出 24 分 53 秒。这段时间系统这边没有任何记录——详见 04。
19:36:02 → 19:36:09
模型 5 秒给出回复，15.5 秒后发出
provenance 实录"好的，您先忙，有需要随时找我～"。从落库到发出只用了 15.5 秒——生成这一环是快的。
此后
没有然后
字段为空next_followup_at 空、followup_count 0。库里没有任何后续消息与待办记着"过些天"是哪天。（销售私下微信跟进不入库，销售侧是否跟过没核。）
03 · Conversation strategy
这一句为什么是对的
客户说"我过些天联系你"时，话术上能犯的错有一串。把它们和实际回复摆在一起看，才知道这 13 个字的分量。
| 可能的回法 | 问题出在哪 | 库里的规则怎么说 | 本轮实际 |
|---|---|---|---|
| "方便问下您那边是什么户型吗" | 客户明说了要往后推，还追问 = 没在听 | conf=10「禁机械追问」 | 没做 ✓ |
| "这个补贴到月底就结束了哦" | 制造紧迫感逼单，软推迟阶段最招反感 | conf=10「第一句先接住情绪给台阶」 | 没做 ✓ |
| 发一张效果图或价目表 | 客户没要，属于未经请求的素材投放 | conf=10「答完就停，别顺带介绍别的产品」 | 没做 ✓ |
| "好的，我一直都在，随时为您服务" | 态度保证，不是可兑现动作 | conf=9「打包票是红线，给具体动作不给形容词」 | 没做 ✓ |
| "好的，您先忙，有需要随时找我～" | — | 接住 + 把决定权留给客户 | 实发 ✓ |
和同一天的闽D想家正好照出对方：那边客户正在报尺寸、往前推，AI 却说"不着急定哈，我发几张风格图您先看看"——在客户踩油门的时候踩了刹车；这边客户自己踩了刹车，AI 顺着停住。同一个模型、同一版提示词（v27）、同一天、同一台机器，一条错一条对。两条输出的差别落在"客户当下在往前推还是在往后退"这个维度上——模型内部是不是真"读懂"了，日志证明不了。
这一条的账：读进去 16,202 个 token（知识库 + 决策规则 + 示例），吐出来 13 个 token，花掉 $0.0015。为了说好"好的，您先忙"这七个字，系统读了一万六——这不是浪费，是因为"该不该多说一句"恰恰要靠这一万六来判断。
03.1 · Reply pipeline
那 13 个字是怎么生出来的
下面这条链路是每一条 AI 回复都会走一遍的。格子里的数字全部取自 19:36:09 那条回复的真实调用记录。
01 发现
读微信窗口
客户 19:11 发出
19:35:53 才落库
慢了 24m53s
19:35:53 才落库
慢了 24m53s
02 落库
写 messages
同时新建了会话
历史为空
历史为空
03 检索
捞知识/示例/规则
知识 1 篇（0.39 弱）
示例 3 条 规则 13 条
示例 3 条 规则 13 条
04 组装
拼提示词
wecom.nurture.rules v27
16,202 token
16,202 token
05 生成
模型推理
qwen3-235b-a22b-2507
5.0s → 13 token
5.0s → 13 token
06 过闸
自检与清洗
无价格、无泄漏
全部 pass
全部 pass
07 发送
GUI 粘贴发出
19:36:09 发出
落库后 15.5 秒
落库后 15.5 秒
第 05 到 07 格都是绿的——生成和发送这一段没有任何问题，前后只用了 15.5 秒。红的是第 01 格：消息进系统就慢了 25 分钟。黄的是第 02、03 格：会话是新建的、检索几乎没捞到东西。
03.2 · What it cited
这一句引用了什么
把这一轮实际喂进去的示例和规则摊开，能看到输出跟哪一条对得上——也能看到哪一半没出现在输出里。（规则是全量注入的，见下方说明。）
引用一 · 示例 —— 一条几乎同构的范例
命中示例 fb4aeb9d · quality 10 · tags: 共情, 关心, 到店节奏
示例客户：我昨天感冒了，周末可能去不了
示例回复：那可得多休息，身体最要紧，这种天气感冒最难受了～您不着急，等好利索了咱再约。我先把配置和实拍发您手机上，躺着也能翻翻看。
本轮客户：你好，我过些天联系你 （同样是"现在不方便，往后推"）
AI 实发：好的，您先忙，有需要随时找我～
这条输出与示例前半段的处理方式一致——接住、不催。（能比对的是输出文本，示例有没有"被学到"日志证明不了。）这也对得上它在四种常见错法里一个都没踩。
但是 —— 示例的后半句没学
示例回复的收尾是"我先把配置和实拍发您手机上，躺着也能翻翻看"——在接住之后留了一个零成本的钩子：不要求客户做任何事，但把东西递到他手上，也给下次开口留了由头。
AI 实发只到"有需要随时找我～"就停了。范例里"给东西"的那半句，没有出现在输出里。
这不是这一条的偶然。同一天的闽D想家、次日的闽D******-张志标（09-22 那条回复），命中的示例都是"先给一句 + 再说一句"的结构，实发都只剩后半截。张志标那条最明显：示例原文"新房好，一张白纸最好规划。您家常住几口人，最想先解决哪块的收纳呀"，AI 实发只有后半句提问，一字不差。
另外两条命中示例
5de32005（q10）价格异议"这568真到地板价了"；9e6a1d3a（q10）"水电刚完工" → "刚完工那咱通电和水压后面盯仔细点哈，我家就是水压没处理好后面整改很麻烦"。
两条都跟"过些天联系你"不沾边，属于每轮都会被捞进来的常客。
引用二 · 决策规则 —— 注意：规则是全量注入的
先说清一件事，否则下面两条会被高估
查 src/lib/org-context.ts：decision_rules 按 confidence DESC 取前 40 条全量注入，不按客户当下这句话检索。所以"命中"只说明这一轮注入了它，不说明系统认为它跟这句话相关；"照做"是把输出和条文对照出来的结论，不是系统的判定。
换句话说：下面这两条不能当成"系统选对了规则所以回得对"的证据，只能说"输出与其中一条全量注入的规则一致"。
conf=10 · 输出与这条一致 ✓
「客户嫌贵／说太贵去不起买不起预算有限／礼貌道别／明显降温等情绪场景——第一句先接住情绪给台阶（"这我懂""确实"）；不方便到店就说"我先把配置和实拍发您手机上慢慢看"；禁机械追问"什么时候到店／来看样柜"」
→ 接住了、没追问。 → 但规则里同样写着"我先把配置和实拍发您手机上"，这半句也没做。
conf=9 · 输出与这条一致 ✓（这条只在本案那一轮的注入清单里）
「…给可兑现的具体动作 + 公司白纸黑字的时效，不给态度保证。反例：「不会让您等」「马上安排对接」「全程我跟到底」「保证不耽误您」——这类是打包票，兑现不了就是失信」
→ 实发"有需要随时找我～"是开放邀请，不是时效承诺，没踩这条红线。
引用三 · 知识 —— 基本没派上用场
命中知识《加微前沟通标准（电话/短信话术）》· 相关度 0.39
这篇讲的是"怎么高效拿到客户微信"。客户已经是好友了，这篇在这一轮基本用不上。相关度 0.39 —— 本页把 0.39 统一称为弱（三页此前对高/低的叫法不一致，已对齐：0.5 以上算捞对，0.1 以下基本是噪声，中间地带看内容是否对得上）。这一篇内容明显错配。
04 · Friction map
核心卡点：慢在落库之前，具体哪一环未定
客户 19:11 发的，19:35:53 才落库——中间这 25 分钟没查出来
微信截图上客户那条消息挂在 19:11；数据库落库是 19:35:53；回复 19:36:09 发出。
19:11 客户发出「你好，我过些天联系你」 ← 微信显示的时间
⋮ 这 24 分 53 秒，系统这边没有任何记录
19:35:53 消息落库，会话被创建
19:36:02 模型给出回复（推理 5.0s）
19:36:09 回复发出 —— 落库之后总共 15.5 秒
中间那 25 分钟花在哪，这一页没查出来。个微是靠盯着微信窗口发现新消息的，轮询和读屏都有节拍；但执行器的逐行日志不上云，要确认是"轮了很久才轮到"还是"轮到了没认出未读"，得回那台机器上看当时的日志。现在能确定的只有两件事：回复本身很快（15.5 秒），慢的是发现这一步。
换一条对话，代价完全不同
这次客户说的是"过些天联系"，晚 25 分钟回没有实质损失。但同一台机器上，闽D想家那条客户问的是"需要多少钱"——那种消息晚 25 分钟，人早去问别家了。响应快慢在这条链路上是由"多久发现"决定的，不是由"回得多快"决定的。
四个半小时没有主动打扰
客户 14:45 通过好友后沉默到 19:11，期间我方一条都没发。刚加上就追问是这条链路最常见的错，这次没犯。
05 · Technical blockers
技术卡点：同一个人，库里两条会话
这位客户在 conversations 表里有两行。它们的差别在身份键的取法上——一条用微信备注名，一条用会话 id。
| 创建时间 | 身份键 wecom_external_userid | 阶段 | 消息 |
|---|---|---|---|
| 16:41 | wx_pc_96bc68d765:湘a逆风也绽放💋kfc00070007按微信备注名当键（带 emoji） | ice_break | 0 条 |
| 19:35 | wx_pc_96bc68d765:consult:weixin:75ee9794…按会话 id 当键 | nurture | 2 条 |
不是孤例：两套身份键在同一台机器上并行
查近 7 天这台机器上的 200 条个微会话：181 条用备注名当键、19 条用 consult:weixin:<id>，两套并行。这个窗口里产生重复会话的客户有 4 位——除本案外还有闽B******、闽A******、杭A60757-橘子。
⚠️ 口径：查询窗口是 09-14 起的近 7 天，且要求两条会话都落在窗内。闽D******-张志标那一对是 09-08 + 09-18，跨出窗口所以没被这次查询抓到；算上他，已知受影响的是 5 位。
后果历史断开：19:35 那条会话是当场新建的，里面没有任何过去。
本案影响AI 回这句话时不知道 14:45 发过招呼语、不知道这人是当天刚加的。⚠️ 但注意：那条招呼语是销售手打、不经过系统，两条会话里都没有它——所以这一条不能全算在双键头上，真正的缺口是人工首触不入库。
潜在影响客户若问"你上午说的 568 包括什么"，AI 会因查无此事而答不上来。
修法身份键收敛成一套，并对已产生的重复会话做合并。
"过些天联系"没有转成任何待办
客户给的是一句带时间意味的承诺，是这条链路上最该记一笔的场景。查这条会话：next_followup_at 空、followup_count 0、followup_policy 默认 standard、阶段停在 nurture。
现状回完那一句就停住，没有提醒、没有队列、没有负责人。
识别"过些天／过段时间／回头／忙完再说"应识别为延期意向并落一个日期。
动作没给具体日期时，按默认间隔（如 5–7 天）设一次轻跟进。
待验证另有一套按天冷却的召回机制，它会不会捞起这位客户——本页没有验，要看召回侧的到期队列。
个微首触仍是人工，AI 只判断不发送
本案和闽D想家的招呼语都是销售手打的同一个模板。这意味着首触的时间点、措辞、补贴口径都不受系统控制，也无法按城市分档（568/598）。
现状干跑阶段：系统判断该不该发、发什么，但不真发。
影响首触质量取决于销售手上那份模板是否最新。
下一步先把干跑结果与人工实发做比对，再谈放开发送。
06 · Trigger model
这条接下来靠什么推进
手上有的
- 联系方式大概率还在：库里没有删除记录。好友关系与通道是否可用没有探测过（09-21 之后我方没发过任何消息）。
- 没有负面印象：唯一一次互动里我方没有追问、没有逼单。
- 他自己说了会联系：主动权在客户手上，但话是他说的。
- 补贴活动是现成的由头：下次接触不需要硬找理由。
缺的那一步
- "过些天"没有变成一个日期——这是唯一真正缺的东西
- 没有设任何提醒，全靠人记得
- 不知道他有没有装修需求，下次开口说什么没有依据
- 两条会话没合并，下次接上的是哪一条不确定
修复进展 · 截至 2026-09-23
本案暴露的问题，现在修到哪了
以下为 wecom-chat 仓已合并并部署上线的修复（截至 09-23 22:11，线上版本 158f185）。“已上线”指服务端代码在线上生效；本案对话发生在修复之前，页面上的原话不会因此改变。
| 问题 | 怎么修的 | PR | 状态 |
|---|---|---|---|
| 同一个人库里两条会话（两套身份键并行） | #1546 让同销售号 + 同名的新会话继承旧会话的城市 / 面积等事实。本案覆盖不到：用线上代码核对，两条会话同属一个销售号，但名字一个带 💋 一个不带，核心名对不上；且旧会话 0 条消息、没有可继承的事实。身份键本身仍是两套并行，未收敛 | #1546 | 未覆盖 · 待定 |
| “过些天联系你”没转成待办（卡点 02） | 尚未修 | — | 未覆盖 · 待定 |
| 人工首触不入库（卡点 03） | 尚未修 | — | 未覆盖 · 待定 |
| 消息 25 分钟后才被发现（落库之前） | 读屏延迟，与“连发第二句没进库”不是同一个问题，#1600 管不到。同一台销售电脑上龙文 19:52 那句也晚了 27 分钟才被读到，需要看销售电脑当时的日志 | — | 未修 · 待查 |
07 · Review
案例复盘：做对什么，还能改什么
做得好的地方
客户软性推迟时，AI 接住并停住——没追问户型、没塞素材、没用"活动快结束了"制造紧迫感、也没给"我一直都在"这类打包票。查 decision_rules 能看到它命中的正是"禁机械追问、先接住情绪"这条（conf=10），规则命中且照做了。加好友后四个半小时没主动打扰，也是对的。
可以优化的地方
回得对，但止于对：可以在同一句里留一个不施压的钩子（"到时候把您户型发我，我先让设计师看看"），把下次开口的由头留下来，而不是纯等待。另外这一轮读了 16,202 token 才输出 13 个字，上下文成本与产出严重不成比例，值得看看软推迟这类场景能不能走更轻的路径。
这条链路上的硬伤
客户等了 25 分钟才收到回音，慢在"发现"不在"生成"；同一个人两条会话（09-14 起的窗口内有 4 位客户如此，算上跨窗口的张志标是 5 位）；客户说了"过些天"而系统没留下任何待办——这三条都与这次回得对不对无关，是链路本身的问题。
更合理的推进方式
回复保持原样不变，但后面接三个动作：① 把"过些天"识别成延期意向，落一个默认 5–7 天的轻跟进；② 跟进内容不要用"在吗／考虑得怎么样"，用客户没成本的方式（"上次那个样板房补贴还在，您要是方便把户型发我，我先让设计师看看"）；③ 两条会话先合并，保证下次接上的是消息更全的那条。注意：合并恢复不了招呼语——它根本没入过库，要修得从「人工首触入库」下手，那件事应排在会话合并之前。
08 · Reusable SOP
软性推迟客户处理 SOP
适用于客户说"过些天／过段时间／回头联系你／最近忙"的场景。这类客户最容易被两种极端毁掉：追得太紧，或者彻底忘掉。
先判性质
区分"推迟"（过些天联系你）、"拒绝"（不需要了）、"敷衍"（嗯嗯好的）。只有推迟值得留跟进。
接住，不追问
第一句给台阶："好的，您先忙。"不问户型、不问预算、不问时间——他刚说了现在不想聊。
不制造紧迫感
"活动快结束了""名额不多了"在这个时点是负分，会把软推迟推成硬拒绝。
不给态度保证
"我一直都在""全程我跟到底"是打包票。要表达重视就说具体动作。
留一个无成本钩子
可选：把下次开口的由头留下（"方便的话把户型发我，我先让设计师看看"），客户不接也没损失。
立刻落跟进日期
客户给了日期就按他的；没给就按默认 5–7 天。这一步是本案缺的。
跟进内容先想好
不要"在吗／考虑得怎么样"。用对客户有用的东西开口：新样板房、同小区案例、他关心过的材料。
两次未回就降频
连续两次跟进无回应，转入低频（月度）或归档，不要持续消耗好友关系。
本案的判定
第 1–4 步都做到了，第 6 步"立刻落跟进日期"没有做——这正是整条对话停在这里的原因。回得对和跟得上是两件事，这条做到了前者。
第 1–4 步都做到了，第 6 步"立刻落跟进日期"没有做——这正是整条对话停在这里的原因。回得对和跟得上是两件事，这条做到了前者。
09 · Evidence & gaps
证据边界与待补充信息
数据库可核验的部分
会话 15096c5a… 的 2 条 messages 原文与毫秒级落库时间；chatReply 的模型、提示词版本（wecom.nurture.rules v27）、16,202/13 token、5.0s、$0.0015；命中的知识文档与相关度；命中的 13 条 decision_rules；两条会话的 wecom_external_userid、阶段与 next_followup_at；近 7 天 200 条会话的身份键分布（181 : 19）。
只有截图、没有库记录的部分
销售手打的招呼语；客户消息在微信端的发送时间 19:11（页面所有"落库时间"来自数据库，两者的差正是第 04 节的主题）。
仍需补充
那 25 分钟的执行器本地日志（逐行日志不上云，需回云电脑取）；召回机制是否会在几天后捞起这位客户；客户来源渠道；他是否有真实装修需求。
不做的断言
不断言那 25 分钟是"轮询周期造成的"——没有日志就只说"没查出来"。不断言召回会接住这条。不把"回得对"等同于"这条会转化"。