Loxinity 这类 AI 音视频平台，第一次用先跑通一轮完整对话

第一次打开 Loxinity 这类 AI 音视频平台，判断有没有跑通，不看界面功能多少，只看一件事：你说完一句话，系统采集到、给出回应、你能听到或看到，这条链路是否完整走了一遍。很多人卡住是因为分不清“页面打不开”“权限没给”“声音没进去”“回应回来了但我没听见”这几种情况。把一轮对话拆成采集、播放、轮流发言三段分别观察，每一步留下可复述的记录，比反复刷新页面有用得多。

第一次用的目标应设为“走完一轮完整对话”，不要先调效果。先在浏览器地址栏和站点设置确认麦克风、摄像头授权落在“已允许”；再用三十秒自录音确认输入进得来、外放没被当成输入；然后用 performance.now() 在说话结束和回应开始两处打点，重复三次留下记录；最后检查音画同步与切换设备后的重新对齐。任何一段走不通，先记录现象再改配置，不要同时动多个开关。这套流程只用于建立可复现的第一次体验记录，不构成对平台能力的评价。

在浏览器地址栏和站点设置里确认麦克风、摄像头授权状态

这一步只为排除最外层的问题：采集端根本没拿到设备权限。检查动作按顺序做，不跳步。

授权弹窗出现的时机：通常在你第一次点击“开始对话”“加入房间”或页面加载后主动请求设备时弹出。如果点了按钮完全没有弹窗，说明请求动作没触发，或者该站点此前已被记住为“阻止”，浏览器不会再问第二遍。
权限图标显示的三种状态：地址栏左侧的图标一般表现为“已允许”（图标常亮或带确认标记）、“已阻止”（带斜线或红色提示）、“未询问”（灰色或带问号）。三种状态对应三种处理：已允许继续往下走，已阻止去站点设置里改，未询问说明还没触发请求。
被拒绝后的页面表现：常见是按钮点了没反应、提示“无法访问麦克风”、音量条始终不动，或干脆停在“正在连接”。页面不一定会主动说明是权限问题，所以要以地址栏图标为准。

修改权限后建议整页刷新一次，不要只关掉弹窗。部分浏览器在权限变更后需要重新建立采集上下文，旧页面上的设备句柄仍然是失效状态。摄像头同理，如果平台同时请求摄像头，两项要分开确认，只允许麦克风、摄像头仍为“已阻止”时，画面区域通常是黑屏或占位图。

用一次三十秒自录音判断输入音量与回声

权限给到之后，还要确认声音真的进得来，而且没有把自己的外放当成输入。做法是先找平台自带的录音回放或“测试麦克风”入口；没有的话，用浏览器录音页面录三十秒，对着麦克风正常音量说一段带数字和停顿的话。

录音回放的检查点：能否听到自己完整的一句话；有无断续、爆音、明显底噪；句子之间的停顿是否被保留。断续通常和网络或采样设置有关，爆音多与输入增益过高有关。
音量条随说话变化的观察方式：说话时观察电平条是否随音量大小起伏，停顿时是否回落到接近零。如果一直顶格，说明增益过高或存在持续噪声；如果几乎不动，说明输入选错了设备或系统层静音。
外放与耳机两种条件的差异：先用外放录一遍，再用耳机录一遍，对比回放里是否出现“自己刚才听到的声音”。外放条件下如果回放里混进了对方或系统的声音，说明设备回声消除没生效，输入把扬声器输出也收了进去。

两种条件都试过再下判断。只测外放很容易把回声问题误判成平台故障，只测耳机又会漏掉外放场景下真实存在的串音。输入设备选择也要在系统设置和浏览器权限里对齐，避免系统默认设备和页面实际使用的设备不是同一个。

用 performance.now() 给“说完话到出现回应”打点

主观感受说“它反应有点慢”，别人无法复现。把两处关键时刻换成同一时间基准下的毫秒数，记录才能比较。打开浏览器开发者工具的 Console，把下面的骨架按你页面上的实际事件替换后执行。

// 通用打点骨架：替换成页面真实事件即可
const marks = {};

// 1) 说话结束事件：按钮松开 / 键盘抬起 / 静音判定触发
function markSpeechEnd(tag = 'turn') {
  marks[tag] = { speechEnd: performance.now() };
  console.log('[mark] speech-end', tag, marks[tag].speechEnd.toFixed(1));
  window.__marks = marks; // 方便稍后在控制台取
  return tag;
}

// 2) 回应开始事件：可挂在新消息节点出现、接口返回、音频开始播放
function markResponseStart(tag, stage = 'response') {
  const t = performance.now();
  marks[tag] = marks[tag] || {};
  marks[tag][stage] = t;
  const gap = marks[tag].speechEnd != null ? (t - marks[tag].speechEnd) : null;
  console.log('[mark]', stage, tag, t.toFixed(1), gap != null ? '间隔(ms)=' + gap.toFixed(1) : '');
  return gap;
}

// 使用示例：手动调用，或绑定到页面事件
// const tag = markSpeechEnd('try-1');
// markResponseStart(tag, 'response-node');   // 回应内容出现
// markResponseStart(tag, 'first-audio');     // 真正听到声音

挂载位置按你能观察到的现象选：回应文本出现在页面上，就监听对应的 DOM 变化；回应是音频流，就监听的 play 事件。两处用同一个 performance.now() 基准，间隔才是可比的。连续做三次，每轮换个 tag，结束时在控制台执行 console.table(Object.entries(window.__marks).map(([k,v]) => ({tag:k, ...v}))) 把三轮记录并排看。三次之间差异小，说明这段耗时稳定；差异大，则要连同网络状态一起记录，不要只取最快的一次当结论。

检查画面与语音是否同步、切换设备后是否重新对齐

音视频两条链路各自独立，采集或播放任一环节有缓冲，就可能出现口型与声音对不上。观察方法很直接：对着摄像头说几个爆破音明显的短词，比如“八、怕、他”，看声音落在口型张开之前还是之后。

错位量级判断：轻微错位在实时通话中通常可接受，但如果一个短词说完画面才动，属于可感知的明显错位，值得记录。记录时不写“有点延迟”，写“说‘八’时声音先到、口型约一个词之后才动”。
静音后再开启的表现：手动静音几秒再取消静音，观察重新出声的第一句是否延迟或吞字。部分设备在重新启用时会重建音频上下文，这段时间内的表现要单独记一笔。
切换摄像头后的重新对齐现象：在设备列表里切换一次摄像头再切回来，观察画面是否重新同步、有没有短暂黑屏或音画短时脱节。切换后重新做一次“八、怕、他”的观察，对比切换前后是否一致。

这三项都建议在同一个页面会话里连续做，避免刷新掩盖问题。若切换设备后错位持续存在，先记录设备名称和切换顺序，再考虑更换设备复测。

把这一轮现象写成别人能照做的复现步骤

记录的目的是让别人照着做能重现同样的现象。四栏模板足够，不必写成长文。

环境：浏览器名称与版本、操作系统、麦克风和摄像头型号、是否使用耳机。
操作：从打开页面开始逐步写，例如“打开站点→允许麦克风和摄像头→点击开始对话→说一句话→等待回应”，按顺序、可照做。
现象：写看到和听到的，不写推断。例如“音量条不动”“回应文本出现但无声音”“取消静音后第一句丢字”。
时间点：写下打点得到的间隔毫秒数，以及操作发生的先后顺序，方便和别人的记录对齐。

需要一并记录的环境项清单：浏览器及版本、操作系统及版本、页面地址、网络类型（有线或无线）、是否开启系统的降噪或音频增强、系统默认输入输出设备、页面内选择的设备、权限图标状态、当前是否有其他标签页或会议软件占用麦克风。这份清单不必每次填满，但复现失败时，缺的那几项往往就是差异所在。

最后提醒一点边界：一轮跑通只说明这条链路在当前环境下走通了，不代表在别的浏览器、别的设备或更长时间使用中表现一致。记录时保留“当前环境”这个限定，后续换条件复测才有对照。