单线与双线：一次取舍换来 85 个百分点

这 85 个百分点不是靠换模型、调提示词换来的，全部收益来自两件事：把物理接线改对，以及把一个不再需要的开关关掉。

一、开场

• 一个只有两个值的开关：开着时听对率最低掉到 15%，关掉时是 100%，相差 85 个百分点。
• 关键不在开关怎么调，而在它为什么存在、为什么必须被撤掉，以及为什么它存在的那段时间里没有一条日志报错。
• 单线拓扑 → 四个音频角色全挤在一根线上 → AI 应聘者听见自己 → 加开关在播报期关掉耳朵 → 逻辑对，代价是连面试官的后半句一起关掉了。

二、一根线上的四个角色

虚拟声卡白话：播放进一头，另一头就变成麦克风，全程数字、零比特经过空气。

单线态 = 四个角色全指 CABLE 一根线；双线态 = 面试官走 Hi-Fi，答案走 CABLE。

行首锚定陷阱：Hi-Fi Cable Output 与 CABLE Output 互为后缀子串，朴素包含匹配会先命中 Hi-Fi 线 → 两个角色一起指错且不报错；还要容忍系统给默认设备加的 默认值 - / 通信 - 前缀。已固化为 config.DEV_PREFIX。

宁可匹配不上，也不能匹配错。匹配不上会报错、会被看见；匹配错了只是安静地把声音送到错误的地方。

三、自己听见自己

单线下答案注入口与 iv 录音端在同一根线 → 助手在自己说话的同时把自己的话一字不落听了一遍，这就是自激。

后果是污染：转写流里既有面试官问句也有自己的答案，而「面试官说完了没」「该不该开口」「下一轮答什么」全建立在这锅粥上。

想靠软件在下游做分离很难做干净，两路声音叠加后没有天然标签告诉你哪个字属于谁。

四、那个看起来完全正确的开关

BRIDGE_PAUSE_IV：播报前发 pause 停止采集，播完发 resume 恢复。逻辑链条无懈可击，也确实生效——自激消失，转写流干净。

反直觉钩子 1：它在推理链上完全正确，在物理上完全错误。它以为关掉的是回声，实际关掉的是耳朵——耳朵没有选择性。

这类错误不以错误的形式出现：不崩、不报红、日志无异常，只是转写短一截，看起来特别像 ASR 偶尔抽风（会被归因给外部引擎）。

五、代价藏在后半句里

• 实测：单线期 13 条问句里 11 条本地转写只到第一句，追问、限定条件、问题核心全丢。
• 听对率：关开关 100% → 开开关 15%~62%（波动取决于句长与后半句落在哪个窗口）。100 − 15 = 开篇那个 85。
• 机理是结构性而非偶发：以为面试官说完就开播，播报期耳朵关着，面试官恰在此时补后半句，播完恢复时那半句已过去。
• 单线期时间窗 2026-10-06 18:50 ~ 20:15。系统能跑、能答题、能归档，看起来一切正常。

反直觉钩子 2：越谨慎、越安全的开关损失越大——它不制造错误，只把输入悄悄削掉一半。错误触发排查，削减不会。

教训不是「要更仔细」，而是这类检查必须固化成脚本，否则只在有人较真时才发生。

六、不是加功能，是撤掉一个开关

2026-10-06 20:15 双线恢复：两根虚拟声卡、四个端点统一 24bit / 48000Hz（bit-perfect 硬要求），面试官走 Hi-Fi，答案走 CABLE。

助手物理上听不到自己 → 自激不是被压制，是不存在 → 开关失去存在理由，BRIDGE_PAUSE_IV 改回 false。暂停/恢复接口保留为降级手段，当前为空操作。

再打开的硬规矩：不许凭感觉，必须先跑双线验收脚本看到每根线电平峰值达标。已升级为冻结项 R-FREEZE-002，冻结那个 false。

为症状打的补丁，在根因消失之后必须被显式摘掉。不摘，它就会从补丁变成新的根因。

七、拿信号说话

证据目录 autobot/data/probe/verify_20261006-203959/（2026-10-06 20:39:59 起）。

• 先验尺子（自检）：浏览器生成振荡器信号再去读，peak RMS 0.3550。若这步是 0，后面所有 0 都不能信。
• 逐线回环实测：只测 CABLE peak 0.1892（97 采样点 / 6023 ms）；只测 Hi-Fi peak 0.1905（98 / 6053 ms）；两根一起测 0.2091 / 0.1703。判据 > 0.001，高出两个数量级，不是擦线通过。
• 端到端双向探针（audio_probe.json，20:42 落盘）：注入方向 rms 峰值 0.23498、录回 130494 字节、送达率 dice = 1；接收方向听对率 dice = 1；阻塞项空 / 警告项空 / 总判定通过。
• 环境自检 18 项全 PASS：Node 24.15.0、可用内存 9.8G / 总 31.7G；默认播放 Hi-Fi Cable Input，默认录音 CABLE Output。

最容易被忽略的那句提示：设备名存在 ≠ 线导通，请以实测峰值为准。

八、带走的判断

• 先分清你在修症状还是修根因。 为症状打的补丁有寿命，根因一变必须显式摘掉；摘补丁要写进流程，不能靠谁记得。
• 任何「关掉一段时间」的开关，都要问清它关掉的是不是不止一样东西。 耳朵、暂停、静音都没有选择性。
• 不报错的损失要靠点数发现，不能靠指标平均值。 13 条里丢 11 条，在平均值里根本看不见。
• 判断一根线通不通，唯一有效证据是拿真实信号走一趟——这头播进去、那头录回来、看电平是否真动。而在此之前还有一步：先用已知信号验一遍你的尺子。

边界声明（不变）

本期全是声音路由的工程问题，未动平台任何东西，未做任何反检测与伪装，摄像头里始终是真人。这个立场从头到尾没变过。

README.md §5 定型架构 + 单线历史态说明（18:50~20:15，听对率 100% → 15%~62%）、§5 参数速查、§10 责任矩阵；CODEBUDDY.md 双线段与 config.DEV_PREFIX；autobot/config.js 设备正则与 BRIDGE_PAUSE_IV 注释（13 条问句 11 条只到第一句、R-FREEZE-002）；autobot/data/probe/verify_20261006-203959/（line_probe / enum_dev / check_env / audio_probe）。