先说好的一面：技术链路是绿的。10 条会话破冰最快 2 分 43 秒、最慢 8 分 34 秒；客户回复后 AI 自动代回全部在 1–2 分钟内送达； 3–5 条消息全部回写入库，零 presence 噪声。输的不是速度，是话术和数据。两个问题都在人能改的地方。
10 位客户里有 5 位，开口第一句要的就是清单或手册。破冰全都答应了「可以发」，然后拿这个承诺去换户型信息—— 户型拿到了，清单一份都没真发出去。5 个人答完就沉默。
| 客户 | 他开口要什么 | 破冰承诺了吗 | 真发了吗 | 客户后续 |
|---|---|---|---|---|
| 杨梅2.0版不吃笨饭 高意向 93 · 全批最高 | 想要清单 主播 13w是硬装还是全落地呀 | 承诺 | 没发 | 隔夜回「新房」后沉默 |
| 晴空云下的心安 | 小姐姐可以发一份清单吗 | 承诺 | 没发 | 报出户型后沉默 |
| Sicily | 求手册 谢谢哥 | 承诺 | 没发 | 回「新房」后沉默 |
| 乌龙牛乃茶乌龙💙 | 灿哥，我需要一份装修手册，谢谢 | 承诺 | 没发 | 给了户型+精确面积，AI 转头要微信，无回应 |
| 今天下雨了吗 | 给我也发一份清单 | 承诺 | 没发 | 答了两轮，AI 抛加微问句，无回应 |
10 条会话的 is_same_city 全部是 null，一次同城判定都没成功。查库之后发现这不是单纯「字段忘了填」，是两层问题叠在一起。
| 号源 | 类目 | source_accounts.city | 影响的会话 |
|---|---|---|---|
| 苏等等的家 | 本地号 | null | 4 条（杨梅 / 晴空 / 起风了 / 今天下雨了吗） |
| 阿进 | 本地号 | null | 1 条（花开^谁哭泣） |
| 灿哥聊装修 | 本地号 / 知识号 表里有两行同名记录 | null | 2 条（Sicily / 乌龙） |
| 我得装修日记📔 | 业主日记 | null | 1 条（bkpp9999991） |
| 小刘厂长美式家具 | 本地号 | 成都 | 1 条（老八烧烤） |
source_accounts 里有两行，一行标「本地号」、一行标「知识号」，两行 city 都空。
同一个号被拆成两条记录，后面任何按号源做的统计都会偏。
唯一填了 city 的「小刘厂长美式家具」是成都号，但它当天捞到的客户 老八烧烤 IP 属地是湖北——
跨省。而这条会话的 is_same_city 依然是 null，不是 false。
所以补 city 是必要的，但不够。判定链路本身没落地：客户侧 10 个人的 self_reported_city 也全是 null（没人在评论里自报城市），
号源侧 city 大面积为空，两边都缺的情况下，同城判定根本没有可比的输入，永远返回 null。
同城信号缺失最直接的代价，是 AI 话术会随口报一个和客户完全无关的地区案例。 花开^谁哭泣 是江苏客户，两条 AI 消息连报了两次成都：
is_same_city 真的能写出 true/false，而不是继续全 null——今天的证据表明，填了 city 的那条也没判出来，光补字段可能救不了。两个问题里，清单兑现是更贵的那个——它直接作用在意向分最高的 5 位客户身上，而且改起来只是话术顺序调整（先给再问），不需要动数据。
同城牌是更容易的那个——补 5 行 city 字段是十分钟的活，但要留意光补字段可能不够，判定链路本身需要再验一次。
速度这块今天没有欠账，不用动。