在这条路上，一致性是死线，不是优化项。四个端点必须全部二十四比特四万八千赫兹，不一致的结果不是变难听，是零。
数字音频有两个最基本的旋钮。采样率说的是每秒对声音拍多少张照片，四万八千就是一秒四万八千张。位深说的是每个点记录得多细，二十四比特就是每个点有二的二十四次方种可能。
bit-perfect 要求这条路上一个比特都别动，一端进来什么样，另一端原样吐出去，中间不许有任何转接。本项目有四个端点，规矩是全部设为二十四比特、四万八千赫兹。这条要求是驱动作者在文档里明示的硬前提，不是我们试出来的经验。
人的直觉是，规模上的差异通常换来程度上的差异。而这里恰好反过来。虚拟音频线的定位是搬运工，不是加工厂。它承诺原样搬运，就得先保证两端说同一种语言。说不通的时候不是凑合翻译一句，而是一个字节都不给。
而且它不报错。四个设备都挂着，浏览器里也能逐个枚举出来，只是读出来的数字永远是零点零零零。
对照着看更容易理解，日常听歌时规格不同也照样出声，因为系统会在中间补一个转接环节。同样一句格式不一样，在两种语境里的后果完全没有可比性。
全静音的候选原因太多了，线没装好、驱动装完没重启、格式不一致、端点被禁用、被别的程序独占，表象完全一样，都是零。
人在这种情况下最容易挑自己最近刚动过的东西当凶手。当时刚动过的是新装的第二个虚拟声卡驱动，于是第一反应是两根线打架了。
陷阱：删除之后再测确实好了，这是真的测量结果。但「我做了它，然后好了」跟「是它让它变好的」，中间隔着一整个可能同时发生的变量清单，重启、设备重新注册、默认设备被重置往往就混在同一次操作里。
真实过程是，白天装完驱动立刻去测，两根线全零，于是记下一条结论，双线冲突只能走单线。若不是后来把它当成待验证的说法重查一遍，它大概率会被写进部署文档，从此每个接手的人背一条并不存在的限制。
真正原因是装完驱动之后没有重启，这也是整张清单里唯一被打星号的一步。
一键验收脚本串起设备枚举、逐线回环、环境自检、项目级双向探针，跑完直接给出通过和失败的表格外加一条总判据。
| 检查项 | 判据 | 背后的想法 |
|---|---|---|
| 自检值 | > 0.005 | 先确认测量工具是好的，自检不过后面结论一个字都别信 |
| 答案线回环 | > 0.001 | 判据用来区分有无，不用来评级 |
| 面试官线回环 | > 0.001 | 双线目标态必须存在且成立 |
| 角色解析 | 四角色与默认播放全对 | 防设备都在但角色指错且不报错 |
| 空结果守卫 | 不得全部导通却一行线都没列 | 防过滤参数写错让匹配范围变成全集 |
| 项目级双向 | 结尾出现双向链路均成立 | 单向通了不算 |
默认设备一律图形界面手设。项目有明确禁令，不要用那个调用未公开接口的脚本，历史上它曾把端点直接置成禁用。
| 项 | 重装前（单线） | 重装后（双线） |
|---|---|---|
| 自检值 | 0.3550 | 0.355 |
| 答案线回环 | 0.1855 | 0.1892 |
| 面试官线回环 | 无此设备 | 0.1905 |
| 环境自检 | 18 通过 / 0 失败 | 18 通过 / 0 失败 |
| 双向探针 | 完全一致度为 1 | 完全一致度为 1 |
同一台机器、同一套方法，加了一根线以后原来那根没变差，新增那根也达到同量级。结论很硬，两根线互不干扰。整套原始输出落盘在带时间戳的证据目录里，任何人都可以回去复核。
清单还留了一条本轮不做的事，不删除残留的旧驱动文件，且不得据此断言冲突。删掉再测哪怕变好也证明不了什么，因为真正起作用的可能是同一次操作里的重启。
共同点是它们都不报错，而且都会让你得出比实际乐观的结论。这正是总判据里那个空结果守卫存在的理由。
设备能被枚举到，不等于线是通的。真正要的答案只有一个，拿一段真实信号走一遍，看另一端有没有真的动起来。数字动了才算，其它都不算。
CODEBUDDY.md 音频闭环（双线段）；README.md §6 部署与迁移五件套；tools/hificable/REINSTALL-CHECKLIST.md。
实测锚点：逐线回环与双向探针证据目录 autobot/data/probe/verify_20261006-203959/；双线自 2026-10-06 20:15 起恢复并通过验收。