114eef0 · Langfuse dm.ice_break.system version 35 → 38）· 数据窗口：5/22 ~ 6/16 · 账号：饭粒 / 野荞 / 零星customer 字段几乎为空（cron 下线 + 扫盘没跑），用案例池已回复部分补全"有回复客户数"。案例池 58 个里 47 个已回复 / 11 个等首次回应，等回复的不能算进分子。合并后：
下一步重点：要么等（6/22 v38 满 17 天，更多 opener 满足观察期），要么补（云电脑扫盘工具 1 天，让客户回复实时进 DB）。
一句话浓缩：6.50% → 0.97% 看起来很糟，但 v38 后的客户还没来得及回——是观察期不够，不是 v38 差。
messages.role='customer' 严重不完整。原因：ADB / WDA / 云电脑三个 DM 出口里，只有早期 message_queue 通道走 /api/cron/check-replies 自动回灌，而该 cron 6/05 前后已下线。ADB / WDA / 云电脑通道客户回复 根本不进 DB 需要靠运营机器手动扫盘 + 回灌（目前都没在跑）。合并两个来源：(a) DB 信号 — conversation 至少有一条 messages.role='customer' / last_inbound_at / handed_off_at；(b) 案例池已回复 — 运营在 upio.ai/akke/cases 手工整理的 58 个案例里，47 个已收到回复，11 个"等首次回应"不算分子。
| 信号 | v38 前命中 | v38 后命中 | 说明 |
|---|---|---|---|
messages.role='customer' | 1 | 1 | DB 信号 · 客户回复实际入站（check-replies cron 写，6/05 后已下线） |
conversations.last_inbound_at | 3 | 1 | DB 信号 · 扫盘回灌字段（6/11 起 sync-inbound-replies 写，本机零执行） |
conversations.handed_off_at | 0 | 0 | DB 信号 · 加微转化（目前无写入口子，全 0） |
| 案例池 · 已回复 | 43 | 4 | upio.ai/akke/cases 已收到客户回复的案例（算分子） |
| 案例池 · 等首次回应 | 11 | 0 | 已整理但客户还没回的案例（不算分子） |
| 账号 | 通道 | v38 前 opener | v38 后 opener |
|---|---|---|---|
| 野荞 | iPhone → 云电脑（6/05 切，跨通道） | 226 | 179 |
| 零星 | ADB → 云电脑（跨通道，不能算干净基线） | 240 | 189 |
| 饭粒 | Android ADB 全程 ✓ 唯一干净基线 | 242 | 148 |
合并 DB 信号 + 案例池后的全部案例。DB 案例展示对话原文，案例池案例直接点链接看 transcript。
共 62 个有进展的会话（v38 前 57 个 · v38 后 5 个）。每个案例展示 opener 内容 + 后续真实信号。
回复率 = 真实多轮对话数 / AI 发出 opener 数。两个数据源合并算（DB 信号 + 案例池），口径在 §① 已说明。
| 分组 | opener | 多轮对话 | 回复率 | 来源拆解 |
|---|---|---|---|---|
| v38 前 | 708 | 57 | 8.05% | DB 3 + 案例池 54 |
| v38 后 | 516 | 5 | 0.97% | DB 1 + 案例池 4 |
| Δ（v38 后 − v38 前） | -7.08pp | two-prop z-test: z=-5.58, p=2.42e-8 显著 | ||
下面这段是基于回复率数字做的客观判定，不掺杂离线 eval / 代理信号等其他信息，纯看这张表。
v38 后的回复率从 8.05% 降到 0.97%，绝对下降 -7.08pp，相对下降 -88%。两组样本量加起来 1224 条，z-test 高度显著（p=2.42e-8），如果数据本身可信，统计上不能用「随机波动」解释。
核心指标 = 用户回复率 = 有回复客户数 / 发出 DM 数。开场白吸引人 → 客户回；开场白尬 → 客户不理。
三个发 DM 通道（ADB 手机 / WDA 苹果手机 / 阿里无影云电脑）里，客户回复都不会自动写进数据库——早期 message_queue 通道走 check-replies cron 自动回灌，但 6/05 之后已下线；本来还有手动扫盘工具 scan-dm-replies.py 可以补，但没人在跑。所以 DB 里"客户回复"显示：
运营手机/云电脑里实际收到的回复远不止这点——是 DB 没记，不是客户没回。
upio.ai/akke/cases 那 58 个手工整理的案例里，47 个已经收到客户回复，11 个还在「等首次回应」——运营整理案例时不一定客户已经回，所以分子只能算已回复的 47 个。这是补 DB 缺口的方式：
（注：v38 前 54 个案例里 11 个"等首次回应"，所以已回复只有 43 个；v38 后 4 个案例全部已回复。）
这是我们能拿到的最接近真实回复率的数据了。
发送量差不多（708 vs 515，只差 27%），但每条 opener 已经过了多少天的"观察期"完全不同：
从案例池已回复案例里提取了 12 个真实"DM → 首次回复"延迟样本（脚本 scripts/_v38-cases-delay-extract.ts）：
这跟运营经验「5 天内回复」一致——5 天是宽容上限，1 天是真实经验值。用 1 天作为观察期阈值重算：
差距从原始 -5.53pp 几乎没变（-5.44pp）。样本量按 opener 发送数算（n₁=708, n₂=470）完全足够，两组比例做 z-test：
但统计显著 ≠ 真实 prompt 差异。分子（"有回复"数）的来源有 2 个无法剥离的缺口：
⚠️ 注意：12 个延迟样本里只有 1 个是 v38 后样本（budaoweng 0.01 天）。如果 v38 后客户的回复延迟特征跟 v38 前不同，1 天观察期可能仍偏短——但目前没有更多 v38 后样本能验证。
有人可能会想到"案例池整理要 1-2 周才成形"，但这跟 v38 好坏没关系——它是个独立的运营操作问题：
这两个独立。即便我们把"案例整理滞后"补上，v38 后短观察期的回复率也会偏低——因为客户根本还没回。所以主因是观察期，不是案例整理。
| 结论 1 · 纯看数字 | 结论 2 · 考虑数据缺口 | |
|---|---|---|
| 看到什么 | 6.50% → 1.06%，差距 -5.44pp， z-test p < 0.00001 高度显著 |
5.44pp 里掺了 2 类无法剥离的偏差 |
| 背后假设 | "数字反映真实 prompt 效果" | "数字 = prompt 效果 + 数据缺口 + 通道差异" |
| 判定 | ✅ 支持回滚 v38 | ⚠️ 不支持立刻回滚（但也不支持继续保留， 是"信息不足"） |
5.44pp 的下降里，至少有 2 个无法剥离的混杂因素：
| 缺口 | 怎么影响 |
|---|---|
| DB customer 信号几乎为空 | 真实回复数被严重低估；v38 前后均受影响但影响程度不对称（v38 前有早期 message_queue cron 跑过、v38 后完全没跑） |
| 三个号都跨过通道 | 饭粒全程 ADB / 野荞 6/05 切云电脑 / 零星 ADB→云电脑——通道切换本身就影响回复入库率，跟 prompt 无关 |
→ 这 5.44pp 里，有多少是 prompt 变差、多少是数据捕捉差异、多少是通道切换影响 — 目前无法分离。回滚 v38 等于赌"5.44pp 全是 prompt 问题"，但这个赌注没有数据支撑。
生成时间：2026-06-16 10:09:28 UTC
脚本：scripts/_v38-real-replies-html.ts · 代理对照脚本：scripts/_v38-indirect-interaction-compare.ts