最贵的故障不报错，它不崩、不红屏、不写日志，只是安静地什么都不说；抓住它靠的不是运气，而是每一层都提前留了账。
切换到新的答题方案之后，整场出故障的形态非常整齐。面试官的话听得清，转写对，问句完整进到生成环节，但答案区是空的。
表面看跟麦克风没插好一模一样，平台那侧的表现就是那句「好像没有听到您的声音，您还在吗」。而这个第一反应是错的。
答案空了只是结果，从结果往回猜能猜出十几种可能。做对的第一件事是把这条路拆成四层，每层单独装仪表、单独报数。
| 层 | 要回答的问题 | 判据 |
|---|---|---|
| 虚拟线电平 | 声音有没有进来 | 播进线的一头，从另一头录回，看电平数字有没有真动 |
| WebSocket 数据帧 | 有没有东西在流动 | 逐帧全录，每帧带时间戳，看流水不看余额 |
| 浏览器轨道状态 | 到底有没有在录 | 轨道是否活跃、是否被静音、是否被系统收回 |
| 上行统计 | 音频包有没有真发出去 | 累计上行字节数在涨 |
结论：四层全绿，坏的只有一样，答案本身是空的。关键是这些仪表不是临时补装的，日常就开着。
大模型本身不记事。所谓能连续聊，是外面有人替它记账，给这段聊天一个编号，服务器按编号存上下文。它就像办事拿的那张号，报错号就是编号不存在。
大脑里放着多套答题方案，而网关的会话登记不区分应用。切到新方案后仍拿旧方案的编号去调用，对方查无此人，返回编号不存在的错。
最阴的地方：这类错误常被服务端吞掉，转成一个安静的空结果，对调用方来说既没报错也没内容。
验证办法朴素到可爱，同一个会话连问两次。首问就空，说明这套方案本身坏了，本场没有跑下去的意义。首问正常续问失败，就是典型的会话被拒，问题在编号那一层。
两种失败表面长得一模一样，修法完全不同。所以只问一次并通过，证明不了系统是好的，跨轮次的毛病只在第二、第三次才露面。
基于这个实验，每场正式开跑前加了一道强制自检。切完方案立刻连问两次，不符合预期就当场中止，不进面试房间。坏场次的发现时间压到二十秒以内。
为什么值钱。它不是事后告诉你哪里坏了，而是在开场之前就把这一场判死。一场十二分钟还要真人坐在摄像头前盯，跑完才发现答案是空的，最糟的是你分不清这是这一场运气差，还是系统早就不对了。
验收：三个基线场次的完整日志窗口内，编号错误与会话重置计数均为零，端到端通过。客户端那道连问两次的自检保留为防线，不撤。
同一份回执还是一轮零代码改动，开头写明冻结纪律全部维持。这一轮不是拿来顺手改参数的机会，否则后面看到的变化分不清来自维修，还是来自顺手的调整。
第一版结论说低指标来自平台容量上界，配的证据是，总共一百七十一个句子里得零分的只有一句，占百分之零点六，所以低分是普遍性的。
听起来有数字有百分比，但致命处在于。那个得分是从零到一的连续值，被丢掉的句子不是拿零分，而是普遍拿零点一到零点三。用一个天生看不见你要找的东西的统计量，去证明那个东西不存在，是最容易骗到自己的推理。
| 口径 | 送达率 |
|---|---|
| 实际播出句 | 0.566 |
| 从未播出句 | 0.134，得分超过零点六的占比零 |
差 4.3 倍。若瓶颈真在平台容量，两组应当同样低。差异只能来自一句话，到底有没有播出去过。裁决：平台容量上界真实存在，但不是主因。
空答案那一场能被一路追到编号那一层，靠的不是运气，是每一层都留了账。
README.md §4.4 坑三 · §8 排障手册 · §11 词汇表 · §10 遗留矩阵；回执-to-服务端-2026-10-06.md；autobot/docs/REQUIREMENTS-DEV.md C-001 与 §1.2.1 裁决表。
场次锚点：本集引用的分组分布数字来自 data/2026-10-05T18-21-09_night_2026-10-06_A（2026-10-06 02:20 场次）。