不断线比对得准更重要：千机用单向广播把数百部手机变成古琴共鸣体

英文题目：Qianji: A Resilient Framework for Orchestrating “A Thousand Machines” in Distributed Performance.

会议身份：conference:nime:2026:conference-paper-id:nime2026_25

✅ 来源为官方会议 PDF；表格与 Figure 按原文证据绑定。PDF 公式以原页区域图片展示，未冒称作者原始 TeX。

会议来源：官方记录 · 官方 PDF

标签：#自适应滤波 #流式处理 #音乐 #空间音频渲染

评分：8.2/10 | 创新 1.5/2 | 技术严谨 1.2/1.5 | 实验充分 0.9/1.5 | 清晰度 0.8/1 | 影响力 1.0/1.5 | 开源 1.2/1.5 | 可复现 0.3/0.5 | 工程/实践 1.3/1.5

排名：前25% | 文档类型：系统技术报告

👥 作者与机构

• Ruilei Duan：机构信息未能从会议 PDF 纯文本可靠映射
• Zhengyang Ma：机构信息未能从会议 PDF 纯文本可靠映射

📌 核心摘要

该工作处理拥塞蜂窝网络下数百台同地手机作为扬声器阵列的分布式演奏，输入为古琴现场演奏与灰度空间手势视频及场馆座位图，输出为每台观众手机独立的包络化共振声光纹理与前方扩声叠加的厅堂声场，难点是高密度4G/5G抖动丢包与移动系统休眠挂起。离线作曲阶段将座位归一化坐标采样视频亮度并量化为每座二进制包络文件预分发，其输出直接构成运行时待触发的 per-seat 乐谱。运行时指挥台以发射后不管方式经Server-Sent Events广播带约2000 ms安全余量的时间戳 cues，无需维持连续控制流即可触发已预载的空间纹理。观众厚客户端扫码自选座位下载对应文件，以无状态HTTP周期校准时钟并经异常剔除与滑动平均多级滤波平滑后本地调度Web Audio回放，浏览器原生重连保障中断恢复。相对维持每客户端双向状态的Soundworks类框架，该设计以无状态扇出和文本纹理相干取代相位精确与逐设备可控，以牺牲双向交互换取拥塞下的稳定。在两次试点测试集下，首次试点的接入规模指标为100，高于第二次试点的接入规模指标50。结论适用边界受限于单向广播式共振，数千阵列声压掩蔽与双向交互外推尚未验证。部署硬件为2核4GB虚拟私有服务器与200Mbps峰值带宽，观众经自有蜂窝网络接入并承受相应延迟与吞吐约束。

🔗 开源与复现资源

• 代码相关资源：https://zmk5566.github.io/qianji/ — 链接可访问（HTTP 200）
• 数据相关资源：https://zmk5566.github.io/qianji/ — 链接可访问（HTTP 200）
• 复现相关资源：https://zmk5566.github.io/qianji/ — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

要解决的现场是什么：为什么几百部手机一起发声容易断？

这篇论文研究的不是耳机里的立体声，也不是录音室里的一台合成器，而是把观众席里几百部手机变成一个 distributed speaker array，也就是分布式扬声器阵列。白话说，就是全场手机同时发声，组成一张会动的“声音屏幕”。输入是古琴演奏意图与预先设计的空间手势，输出是每个座位上手机发出的、随位置变化的连续质感声音。

对刚入门的读者，关键是理解现场网络与实验室网络的区别。实验室里设备少、路由器可控，延迟小而稳定。公演现场是高密度蜂窝网络，也就是几百人在同一场馆同时用第四代与第五代移动通信上网，基站切换、丢包和抖动非常严重。抖动指包到达时间忽快忽慢，英文是 jitter。传统做法用双向长连接维持交互，例如 WebSocket，英文是全双工持久连接协议，服务器要为每个客户端保存帧缓存和状态，还要自己写心跳检测断线。一旦几百个连接同时抖动，维持这些状态的成本和重连逻辑就会拖垮系统。

论文因此把目标从“对得准”改成“不断线”。它明确提出 resilience-first，也就是韧性优先：宁可各手机之间有几十毫妙的模糊，也要保证集体质感不撕裂、不停顿。古琴在这里既是艺术选择，也是技术压力测试。古琴音量小、讲究余韵与环境共鸣，如果连这样安静细腻的质感都能被手机阵列托住而不盖住，说明系统在高抖动下仍能维持可用的音乐连续性。后文所有设计都围绕这个取舍展开。

已有路线走了多远：从听众乐器到网页音频框架缺哪一块？

第一条路线是把观众设备当乐器。早期例子如电话交响，利用通话本身的延迟和低保真做粗颗粒质感。智能手机出现后，手机乐团证明受过训练的乐手可以用手机做 expressive instrument，也就是富有表现力的乐器。更大规模的参与框架往往把手机当控制器，例如投票、合奏控制或把输入聚合成管弦乐线索，手机主要负责发指令，而不是被精确同步地发声。另一些作品把延迟当作作曲资源，用于打击乐即兴。论文认为，这些工作没有回答 co-located broadcast，也就是同场 1 对多广播的问题：几百台紧挨着的手机要在拥塞蜂窝网上保持质感连贯，其同步严格程度更接近相控扬声器阵列，而不是投票系统。

第二条路线是网页音频的网络性能与可扩展性。代表是 Soundworks，它用 WebSocket 做模块化同步与分布式状态管理，服务器为每个客户端保存同步镜像，可以远程监看和单设备调参，适合几十到上百台需要双向交互的乐团。但论文指出，这种设计要求每个客户端维持两条持久连接，服务器状态随客户端数线性增长。在纯指挥驱动、不需要关心单设备状态的广播场景里，这种双向开销是不必要的。另一支工作证明在受控网络下用线性回归可以做到 1–10 ms 精度，但评估环境不是公共蜂窝网。论文的定位因此是补位而非替代：当任务是数百台以上、严格单向、网络不可控时，用无状态单向扇出换可靠性。

任务如何形式化：输入、约束与不追求什么？

把任务说具体一点。设场馆有 N 个座位，每个座位有归一化 2 维坐标。作曲者给出随时间变化的空间手势，例如一朵云从左向右飘。系统要在演出时让第 i 台手机按自己的坐标播出对应的振幅变化，且所有手机在同一指挥线索下大致同时推进。约束有 3 条：第一，手机走观众自己的蜂窝网，服务器无法控制基站。

第二，手机操作系统会休眠后台音频线程，切后台还可能让时钟漂移；第三，运行时不能持续下发高频空间控制流，否则服务器与蜂窝网都会被打满。

论文明确不追求的也有 3 条：不追求逐样本相位对齐，不追求服务器实时知道每台手机的状态，不追求观众在演出中持续交互。举个教学例子帮助理解：这不像视频会议要求每个人嘴型完全同步，而像全场一起举起有明暗变化的灯带，只要波浪方向和明暗起伏看得出来、听得出来是连贯的，个别灯晚几十毫妙是可以接受的。后文的离线乐谱、广播触发与平滑对时，都是为了在这个形式化下保住波浪不碎。

全景如何走通：一个座位的声音从哪里来、到哪里去？

先沿一个座位走完全程。假设你是第三排第五座。演出前，作曲者在 Stage Editor，也就是舞台编辑器里画好座位图，你的座位被映射成归一化坐标。空间手势被渲染成标准灰度视频，亮度代表该时刻该位置应该多响。离线管线按你的坐标采样该视频的像素亮度，得到随时间变化的序列，再量化存成你的专属二进制文件。

演出当天你扫 2 维码进入网页，自报区、排、座，手机通过超文本协议下载只属于你的那个文件并预载音色。指挥按下触发后，服务器经单向通道广播一个带未来时间戳的线索，你的手机用本地估计的服务器时间换算出本地播放时刻，自主调度网页音频播放，全程不需要你再点按。

这就是论文反复强调的 thick-client philosophy，也就是厚客户端哲学：服务器是极简信令中转，复杂性放在端侧。3 个接口对应 3 种时间关系。作曲接口离线工作，把空间复杂度提前算完。指挥接口运行时工作，只发带时间戳的触发，不维持连续控制流。观众接口一旦加入就变成 passive resonator，也就是被动共鸣体，只接收和发声，不再交互。

厚客户端 × 无状态服务器： 厚客户端指合成、包络调度和播放时刻计算都放在手机端本地执行的分工，无状态服务器指服务器只做信号中转、不保存逐设备状态的分工。二者搭配的理由是数百设备并发时任何逐连接状态都会放大内存和维护成本，组合后新增的作用是即使个别手机短暂掉线，已预载乐谱的本地端仍能按本地时钟把当前乐句播完。

下面这张总览图把上述路径画成从左到右的流水线，重点看单向广播与时钟同步是两条分离通道，服务器不保存逐客户端状态。

看图路径： 1. 从左侧古琴手势出发，沿箭头数出视频包络与座位图两条支路如何汇入中间文件；2. 确认中间文件经预载进入无状态服务器，再分出实线广播与虚线对时两条不同线型；3. 观察右侧多部手机标注，确认其身份是扬声器阵列与共鸣体而非交互控制器

论文图 1。原论文 Figure 1：“Qianji’s resilience-first architecture for transforming Guqin gestures into per-seat scores and broadcasting them through a stateless server to audience smartphones.”。

这张图读完应该能复述：左侧是古琴手势进入视频包络与座位图，中间合并成按座位存放的二进制文件并预载到无状态服务器，指挥线索经服务器向右扇出，右侧手机同时经另一条虚线通道独立对时。两条通道分离是理解后文 3 层韧性的总钥匙。

指挥与观众端做什么：触发如何发、手机如何保持被动？

指挥台的设计关键词是可靠性压过交互性。它采用 fire-and-forget，也就是发射后不管机制：每次触发广播一个未来执行时刻，等于当前时间加一个安全余量。原文给出的余量约为 2000 ms。白话说，指挥不是像拉二胡那样连续送弓，而是提前广播一个未来时刻让网络抖动有时间被吸收。手机收到后按本地时钟换算，不需要回确认。因为音色与包络都已预载，指挥可以触发复杂的预置空间质感，而不必维持连续参数流。

观众端的设计隐喻来自古琴传统。古琴常放在琴桌或石头等共鸣体上，靠介质被动放大音色。论文把每部手机比作离散的被动共鸣体。实现上有 3 个动作：第一，扫码进入普通移动网页，不装应用；第二，通过 3 级选择器自报区排座，映射到预计算坐标并下载对应二进制文件。

第三，按加入键后进入 Zero-Interaction，也就是零交互界面，屏幕亮度随当前振幅包络明暗变化，既是视觉对应，也是“正在按本地调度发声”的可见证据。之后即使连接中途掉线，已下载的乐句仍可按本地时钟播完。

单向广播 × 服务器发送事件： 单向广播指只允许服务器向客户端推送指令、不要求客户端回传状态的分工，服务器发送事件是实现该分工的传输机制，它把推送做成普通超文本响应流，不做双向帧缓存和应用层心跳。二者搭配的理由是本任务只有指挥到观众的 1 对多触发，没有上行数据，组合后新增的作用是把服务器退化为无状态扇出器，并由浏览器原生重连接管断线恢复。

下面这张架构图把离线与运行时、广播与对时画在同一张图里，适合核对谁向谁发起连接、谁保存状态。

看图路径： 1. 先区分左侧离线区与中间运行时区，再看指挥台触发如何进入服务器；2. 对比蓝色单向广播分支与红色虚线对时回路的起点、终点和方向；3. 找到客户端侧标注的本地时钟与二进制乐谱，确认调度发生在端侧

论文图 2。原论文 Figure 2：“Qianji system architecture. Command broadcasting (SSE, blue) and clock synchronization (HTTP, red dashed) operate on separate channels.”。

读图后应能说清：离线侧只有舞台编辑器到灰度视频再到按座位二进制文件的单向预下载；运行时指挥触发进入服务器，服务器分出对时端点与广播端点；蓝色实线是服务器到客户端的单向推送，红色虚线是客户端主动发起的无状态对时请求；客户端盒子旁标注的网页音频、乐谱与本地时钟说明调度点在端侧。

无状态时钟同步 × 超文本传输协议轮询： 无状态时钟同步指服务器不保存每个客户端的时钟状态、每次对时独立计算偏移的分工，超文本传输协议轮询是实现该分工的动作，即客户端每隔固定周期向对时端点发起独立请求并携带类网络时间协议四时间戳。二者搭配的理由是把时间校准与指令广播放在不同通道，避免互相阻塞，组合后新增的作用是即使广播通道抖动或重连，对时仍能独立收敛到稳定估计。

离线乐谱如何构造：视频亮度怎样变成每个座位的音量？

直接给几百台手机实时算空间化是不现实的，因为那需要持续的逐客户端控制消息。论文把这部分搬到离线，用 Video-to-Volume，也就是视频到音量管线，以运行时带宽换预计算。具体分 3 步。第一步映射：把场馆座位表映射成归一化 2 维网格，支持非矩形布局，可直接编辑曲线排、环形剧场或多层看台的坐标；若是无固定座位的户外人群，则退化为纯时间包络，所有设备取同一像素的时间轨迹，保留质感编排但放弃空间化。

第二步采样：把空间手势渲染成标准灰度视频，按每座位坐标采样像素亮度。第 3 步编码：把亮度量化成 8 比特振幅包络，存成紧凑二进制文件。

视频到音量 × 二进制包络： 视频到音量指把空间手势画成灰度视频、再按座位坐标采样亮度的时间序列的分工，二进制包络是该分工的产物，即每个座位被量化为 8 比特振幅序列并存成紧凑二进制文件。二者搭配的理由是运行时无法承担逐设备的连续空间控制流量，组合后新增的作用是用离线预计算换运行时带宽，演出时客户端只需按座位下载对应文件并本地调度。

下面这张管线图把 3 步的输入输出与参数写得很具体，适合作为复现清单逐项核对使用。

看图路径： 1. 从顶部两个输入框出发，看它们如何汇入按座位坐标采样这一步；2. 沿垂直箭头读出帧率、量化位数与文件大小三处参数标注；3. 确认最后一步是观众自选座位后下载对应文件，而非服务器推送全部文件

论文图 3。原论文 Figure 3：“The Video-to-Volume pipeline. The Venue Editor defines seat coordinates; grayscale video encodes spatial ges- tures.”。

读图后应能复述：顶部是座位网格到坐标与灰度视频两个并行输入，中间是按座位采样与按帧率量化，底部是按座位存放的二进制文件经超文本协议被自选座位的观众下载。图中标注的帧率与单文件大小说明离线文件非常小，适合手机预载。需要强调的是，这里的视频不是给人看的演出画面，而是作曲者用来画空间运动的控制源，亮度就是音量。

有没有模型训练：本研究实际计算了什么、冻结了什么？

本研究没有训练神经网络，也没有梯度、损失函数、优化器或权重更新需要交代。这是一个系统与部署论文，它的“构造”就是离线编码与运行时估计。需要如实说明的 3 类计算如下。

第一类是离线采样与量化计算。输入是座位坐标与灰度视频帧，计算是按固定帧率读取亮度、量化为 8 比特、打包成二进制。没有学习参数，也就没有冻结与更新之分；可复现的关键是帧率、量化位数与坐标映射表是否与演出场馆一致。

第二类是运行时时钟估计。它不是学习出来的，而是一个多阶段滤波递推：每轮采集多个原始偏移样本，按往返时延做离群值剔除与排序筛选，再对轮均值做指数滑动平均。原文未给出反向传播路径，也未报告需要训练的阈值，阈值与系数是部署时直接设定的工程参数，不应从名称推定它们是可学习的。

第 3 类是音频素材准备。观众端播放的不是实时合成的正弦波，而是古琴录音经外部效果器做时间拉伸、反转与频谱塑形后的质感素材，集中在人耳敏感的中高频以保证手机小扬声器的清晰度。这一步是艺术制作，不属于模型训练，也没有报告可比的训练开销。把“无训练”等同于“输出完全确定”是误解：网络抖动、手机型号与操作系统调度仍会带来不确定性，系统的目标只是把这种不确定性限制在质感可接受的范围内。

在哪里验证：在什么机器、什么网络、多少台设备上测？

服务器是一台 2 核 4 GB 内存的虚拟专用服务器，峰值带宽 200 Mbps。观众设备走自己的蜂窝网，通过手机原生相机或聊天应用扫码进入网页客户端。古琴用两支界面话筒加一支小振膜话筒扩声，经前区左右中扬声器送出，以保住原声乐器在手机阵列前的声学存在；场馆中央另放一支立体声场话筒记录分布式声场。

验证分两轮导演与两场公演。第一轮导演约 100 台设备，在大学阶梯教室验证多机型与多系统版本的端到端连通。第二轮导演约 50 台真机，同时从五台异地机器发起模拟连接，在不同网络条件下压测，确认 2000 以上并发时单向事件流仍稳定。随后在 500 座场馆做两场公开演出，服务器日志记录的活跃连接分别约为 421 与约 320，约占入座观众的 84%。两场均无关键故障，短暂掉线的设备由浏览器原生重连透明恢复。

为便于核对条件与规模，把原文报告的部署要素整理成下表。表头含义为部署阶段、设备与网络条件、并发规模、服务器配置、接入方式。阅读时注意并发规模的聚合对象是服务器日志的活跃连接，不是入座人数，84% 是活跃连接占入座观众的比例。

上表说明主要信息条件：服务器配置在各阶段保持不变，变化的是真机数、模拟压力与网络异构程度。代价是公演没有保留客户端同步日志，因为按隐私设计不采集可识别信息与使用分析，这直接导致后文结果缺少现场定量同步数据，只能用仿真参数与主观听感补足，这是理解证据强度的前提。

同步与听感测出什么：在多大抖动下残差还剩多少？

论文没有给出公演现场的逐设备时钟日志，而是用部署代码中的参数做仿真来说明滤波器的收敛行为。仿真条件分中度抖动与重度抖动两档，往返时延标准差分别约为 60 毫妙与 180 毫妙。每轮采集 15 个原始样本，先剔除偏离轮均值超过 2 倍标准差的样本，再按往返时延排序只保留较好的 50%，最后对轮均值做系数为 0.3 的指数滑动平均。目标不是亚毫妙精度，而是稳定性：让突发尖峰不传进同步时钟。

离群值剔除 × 指数滑动平均： 离群值剔除指按往返时延偏离均值程度和按往返时延排序只保留较好一半样本的分工，指数滑动平均指对每轮均值按固定系数做平滑递推的分工。二者搭配的理由是蜂窝网络原始偏移样本噪声大且有突发尖峰，组合后新增的作用是先砍掉瞬时尖峰再抑制残余抖动，使估计以稳定性优先，而不是追求单次测量的相位准确。

下面这张仿真图是全文唯一的定量同步证据，需要按图例区分 3 层数据再判断好坏。

看图路径： 1. 对比左右两幅子图标题的中度抖动与重度抖动条件；2. 按图例区分灰色原始样本、橙色逐轮均值与蓝色平滑估计三层点线；3. 读出右下角两处收敛后残差标注，确认重抖动下仍保持在低毫妙量级

论文图 4。原论文 Figure 4：“Multi-stage sync pipeline under moderate (σRTT≈ 60 ms) and heavy (σRTT≈180 ms) jitter.”。

这张图应这样读：灰色是每轮 15 个原始样本，散布最大；橙色是剔除与选半后的逐轮均值，已明显收紧；蓝色是平滑后的估计，贴着真实偏移缓慢推进。左右两幅分别对应中度与重度抖动，右下角标注的收敛后残差在两档下都只有几个毫妙，说明抖动增大 3 倍后估计没有发散。纵轴是时钟偏移估计，不是音质评分，曲线向下不代表性能变差，关键是蓝色线是否稳定贴住真实值。

听感与运行结果是另一类证据。两场公演中，扫过全场的波浪与颗粒云在观众听感上是连贯的，相邻设备之间没有可闻的撕裂或时间断裂。古琴素材经处理后保留频谱特征但不再是离散音符，网络抖动反而把颗粒边缘抹模糊，使数字阵列更像有机的整体。但必须用“报告”而非“证明”来表述，因为这是现场主观描述，没有双盲评分，也没有与基线系统的同场对比。

为核对运行时关键参数，把原文明确给出的触发与同步配置整理成下表。表头为功能、动作、参数、通道、设计意图。注意触发时刻与对时周期的单位都是原文写法，比较时不要混淆 1 次性安全余量与周期性轮询。

上表的主要收益是把“韧性”落到可复现的数字：触发提前量、对时间隔、样本数、筛选比例与平滑系数都已给定。具体代价是这些参数未做消融对比，论文没有报告去掉某 1 级滤波后残差会恶化多少，因此只能说该组合在仿真中收敛，不能说每 1 级都是必要的。

拿掉哪一级会怎样：论文做了什么对照、没做什么对照？

严格意义上的消融，即逐个拿掉滤波器某 1 级再看残差变化，论文没有报告。它做的对照是条件对照：同一套滤波参数放在中度与重度两档抖动下，看收敛后残差是否仍可用。结果是两档都收敛，且重抖动下的残差仅略高于中度抖动，这支持“渐进滤波能抑制尖峰”的判断，但不支持“系数 0.3 最优”或“选半比例不可改”的结论。

协议对照同样缺失。论文用架构推理与已发表的内存基准说明选择单向事件流而非双向套接字的理由：在 1 对多广播中不需要双向帧缓存，原生重连可处理基站切换，万级连接下内存约低 60%。但它明确承认没有在相同高抖动下做自家的双向与单向头对头压测，也没有在相同蜂窝轨迹上把多阶段滤波与 Soundworks 或线性回归方案直接对比。这两项被列为未来工作，需要在可 opt-in 匿名遥测的部署上补做，才能在不损害观众隐私的前提下拿到真值偏移。

设备侧的韧性措施是规则而非对照。论文报告了 3 类动作：用屏幕唤醒锁加循环静音单像素视频把浏览器标记为活跃媒体，避免后台挂起；监听页面可见性变化，回前台时计算漂移，若超过 500 毫妙则硬跳到服务器时间，若小于则用变速平滑追齐而不产生可闻音高伪影；针对不同系统在音频上下文挂起、音量接口与缓冲大小上的差异做平台适配。这些是工程经验，不是受控实验，初学者复现时应逐项保留，不宜自行删减。

边界在哪里：多大阵列、多大噪声下结论不再成立？

第一个边界是规模外推。服务器压测确认 2000 以上并发稳定，最大公演是 421 台。但从数百到数千台同场齐鸣时，总声压、空间掩蔽与设备间相位干涉等涌现声学特性仍未探索，不能从较小部署直接预测。这是论文自己明确的限制。

第二个边界是测量缺失。出于降低参与门槛与隐私设计，公演没有记录客户端同步日志，也就没有现场定量数据。仿真用的参数取自部署代码，但真实蜂窝条件可能不同。未来需要 opt-in 匿名遥测来 bridging 这一缺口。

第 3 个边界是比较缺失。如前所述，协议选择与滤波管线都缺少同条件头对头对比，相关性不等于因果，趋势不等于每组都成立。复现者不应把“公演无关键故障”读成“延迟与误判率都已最优”。论文也没有测量误判率、端到端延迟分布或额外耗电，这些量不能宣称得到改善。

第四个边界是艺术条件的特异性。当前是严格离线管线，空间包络预先算好，单向架构只说不回话。若改成实时响应演奏者的在线模式或加入观众投票调参，网络拥塞与稳定性条件都会变化，需要重新验证。理解这些边界，才能决定何时值得尝试该框架，何时应选保留双向交互的框架。

要复现先做什么：按什么顺序搭出最小可运行系统？

复现的第一步是拿场地表。按论文的座位编辑器思路，把每个座位写成归一化坐标表，支持曲线排与看台，不强求矩形网格。若是无固定座位的开放人群，直接准备单像素时间轨迹作为退化方案。第二步是做灰度视频。把想要的空间运动画成灰度动画，亮度即音量，帧率与量化位数先按原文的 30 Hz 与 8 比特起步，确认每个座位的二进制文件大小在每 10 分钟约 18 KB 量级，便于手机预下载。

第 3 步是搭服务器。先实现两个独立端点：单向广播端点只做无状态扇出，对时端点只响应独立的超文本请求，两者不要共用阻塞队列。客户端每 6 秒请求 1 次，携带四时间戳计算偏移。

第四步是抄滤波参数。每轮 15 样本，先做 2 倍标准差剔除，再按往返时延留较好一半，最后用 0.3 系数做指数滑动平均。指挥触发统一加约 2000 毫妙安全余量。第五步是做设备保活：加屏幕唤醒锁与静音循环视频，处理页面可见性变化的两档追齐逻辑，并按系统分别处理音频上下文恢复。第六步是小规模先行：先在教室用约 50–100 台异构手机验证端到端，再加模拟连接压到 1000 级并发，最后才进剧场。

关于可用性，资源状态是唯一依据。本次收到的官方资源显示代码、数据集与复现资料均为可用，状态码 200，地址为项目主页。这意味着当前可写“项目页已公开”，但仍要区分三者：代码开源不等于权重下载，系统可运行不等于一键复现公演规模。论文脚注与正文均给出同一项目页，内含空间录音、文档与源码，复现前应先核对该页本次是否可达，再按上述顺序从小规模做起。

何时用它、何时不用：给研究生的行动清单

当你的任务是同场数百台以上、严格 1 对多、对交互没有要求、网络不可控时，这个框架值得尝试。它的核心动作是三句话：离线算完空间，运行时只广播未来时刻，对时独立平滑。当你的任务需要观众持续投票、演奏者实时调单台参数、或要求逐样本相位对齐时，应优先考虑保留双向状态的框架，而不是硬套单向广播。

常见的误解有 3 个。第一，把单向等同于简陋。单向在这里是主动取舍，用放弃上行换来无状态扇出与原生重连。第二，把仿真收敛当成现场精度。仿真只说明参数组合在两档抖动下不发散，不代表公演每台手机都达到该残差。

第三，把“无训练”等同于“确定性”。即使没有学习参数，蜂窝抖动与系统调度仍会让每次演出略有不同，韧性设计的目标是让这种不同停留在质感层面。

收束时回到古琴的隐喻。论文把手机阵列称为共鸣体，把单向架构比作乐器发声、山水共鸣但不回话的关系。这不是性质证明，只是帮助记忆：技术上是广播与对时分离，艺术上是把喧闹的手机“掏空”成只负责共鸣的器物。研究生若要沿此方向做下去，下一步最有价值的不是把画面做得更炫，而是补上缺失的两块证据：在自愿匿名遥测下拿到现场时钟真值，以及在相同蜂窝轨迹上与主流方案做 1 次可运行策略的头对头对比。

📐 原文公式与排版

以下展示论文原页中的数学表达区域，保留原始上下标、分式和符号排版。区域序号仅用于本文导航，不是论文公式编号。

区域 1 · 查看论文原页

另有 12 个候选区域因边界不明确或图片数量、尺寸限制未展开；请查看完整论文中的原始排版。

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

• 评分规则：type-aware-v1
• 评分模型：muse-spark-1.3-contributor
• 评分请求协议：openai_responses

← 返回 nime-2026 论文汇总