先确认现象
| 现象 | 可能原因 | 做什么 |
|---|---|---|
| 主持人听自己正常 | 观众端或区域问题 | 收集观众样本 |
| 所有人都慢半拍 | 语音链路或设备负载 | 降低同时任务 |
| 屏幕共享更卡 | 上传带宽不足 | 暂停共享测试 |
| 某主持人最明显 | 麦克风或本机网络 | 换设备测试 |
| 活动后才发现 | 没有监控位 | 安排旁听记录员 |
我会在每场 Stage 安排一个「耳朵位」：不用发言，只负责听延迟、爆音、断句和观众反馈。主持人通常发现不了自己卡，因为他听到的是本地声音。记录员要专门标注语音延迟、爆音和断句，而不是只看聊天区有没有人抱怨。
最短处理路径
先停掉主持人电脑上的高占用任务。录屏、云盘同步、浏览器几十个标签、剪辑软件后台导出，都会让语音体验变差。先减负，再改服务器设置。
然后让两位不同地区的观众反馈同一个时间点。若只有一个人卡，优先让他切设备或网络；若多地同时卡，再处理 Stage 或语音设置。
接着检查 Discord 语音与视频排查建议：输入输出设备、权限、客户端版本、网络状态、语音设置重置等。不要直接重开服务器，做可逆动作。
最后准备备用房间。大活动至少要有一个普通语音频道或外部直播链接，主持人知道怎么切，管理员知道怎么公告。
活动前 30 分钟查什么？
| 项目 | 合格标准 |
|---|---|
| 主持人设备 | 耳机、麦克风、充电器就位 |
| Discord 客户端 | 更新完成并重启过 |
| Stage 权限 | 主持人、版主、听众角色明确 |
| 备用频道 | 链接和公告文案准备好 |
| 记录员 | 负责听感和截图 |
| 观众提示 | 告知刷新、重进、切设备方式 |
彩排不要只问「能听到吗」。要模拟开场、上麦、切主持、播放素材、收问题、结束录制。真正出问题的往往是流程切换点。
我还会让主持人读一段固定文案，再让记录员标注延迟、断句和底噪。固定文案的好处是每次彩排都能对比，不会因为主持人临场发挥不同而误判。若外部嘉宾第一次来，至少提前一天做这一步。
为什么 Stage 会有延迟？
Stage 是面向社区活动的语音场景，重点是秩序和主持，不是专业低延迟制作台。主持人设备、Discord 客户端、服务器语音链路、观众网络和外部录制工具都会叠加延迟。
如果你还把 Stage 画面转到 OBS、再转到其他平台，链路会更长。每多一层，排查就多一个变量。我的做法是：Stage 只承担语音主会场，录制和分发单独验证，不在活动当天临时加工具。
活动中和后该怎么处理
活动中优先保内容，不追求完美。能听清就继续；听不清就切备用语音频道；全场异常就暂停 5 分钟并公告。活动后保留时间点、截图、观众样本和管理员操作记录，再查 Audit Log 是否有人改过频道或角色。
大型付费社群活动可以为主持人准备固定设备和固定操作环境。跨地区主持、远程嘉宾和外部推流一起上时，可配合 直播推流低延迟稳定线路 做会前测试。它不是 Discord 设置本身，但能减少主持端链路波动。