数字人已经显示在网页上，文字回复也正常，却始终听不到声音。遇到这种情况，先不要急着换模型、升级服务器。
AI数字人没声音，需要先分清：是用户听不到数字人的回答，还是数字人听不到用户说话。 前者涉及播放，后者涉及麦克风采集，两者受到不同的浏览器权限和接口限制。
下面以电脑Chrome和普通网页播放器为例，给出从检查到验证的操作流程。
先判断你遇到的是哪一种“没声音”
- 网页有画面，但完全没声音：先查网站声音权限和播放器静音状态。
- 点击按钮后才有声音：重点检查浏览器自动播放策略和
play()返回结果。 - 单独打开有声，嵌入官网后无声：检查
iframe的麦克风与自动播放权限。 - 能听见数字人，但数字人听不见你：检查麦克风授权、输入设备和 HTTPS。
一、先检查网站是否被静音
打开出现问题的数字人页面，点击Chrome地址栏左侧的“查看网站信息”图标，进入“网站设置”，找到“声音”，确认没有对这个网站设置禁止播放。修改后，重新加载页面测试。
接着点击数字人页面里的“开启声音”或“开始对话”按钮，再触发一次回答。
如果点击之后恢复声音，优先检查自动播放和按钮的播放逻辑。 Chrome对带声音的自动播放设有限制，不能假设访客第一次打开页面，就一定能听到欢迎语。
注意，给自己的浏览器放开声音权限，只能证明当前环境可以播放。网站仍然需要为首次访问者保留明确的“开启声音”入口。
二、排障示例：画面正常，为什么必须点击后才有声音？
假设出现这样的现象：网页能显示数字人，自动播放没有声音，但点击播放按钮后可以正常听见。
这时不要只检查页面有没有写 autoplay，还要让开发人员查看 play() 的执行结果。autoplay只是播放请求，不是浏览器一定放行的保证。
如果 play() 返回 NotAllowedError，说明当前播放受到浏览器、系统或权限策略限制，应记录报错并保留手动播放入口。
可以把取消静音和启动播放放到按钮点击事件中。以下是接入页面的简化示例，远端媒体流仍需由现有SDK或WebRTC代码绑定到该播放器：
<video id="character-video" playsinline></video>
<button type="button" id="enable-audio">开启声音</button>
<script>
const video = document.getElementById("character-video");
const button = document.getElementById("enable-audio");
button.addEventListener("click", async () => {
video.muted = false;
video.volume = 1;
try {
await video.play();
} catch (error) {
console.error("数字人播放失败", error.name, error.message);
button.textContent = "播放失败，请重试";
}
});
</script>这段代码处理的是“已有媒体流如何播放”，不是完整的数字人接入程序。其中，muted = false用于取消播放器静音，volume = 1用于设置播放器音量，play()负责尝试启动播放。
修改后怎么验证？ 重新打开页面，点击按钮，再让数字人回答。如果仍然无声，记录具体报错，继续检查媒体轨道，不要把“按钮已经点击”当成修复成功。
三、单独打开有声音，嵌入官网后却没有，检查iframe
先做一次对照：在同一浏览器中，分别打开数字人原始页面和嵌入后的官网页面，执行相同的点击与提问操作。
如果原始页面正常，只有嵌入页面异常，就应重点检查iframe权限及父页面策略。跨域嵌入时，麦克风和自动播放能力可能受到额外限制。
例如，接入代码可能需要包含：
<iframe
src="https://avatar.example.com/"
title="AI数字人"
allow="microphone; autoplay">
</iframe>其中的网址是示例，需要替换成实际数字人页面。microphone用于委派麦克风使用权限，autoplay用于委派自动播放能力。
但添加这两个属性，不等于自动获得全部权限。 父页面的 Permissions-Policy、浏览器播放策略和用户授权仍然有效；父页面已经禁止的能力，不能只靠修改iframe就重新开放。
修改后，要在最终发布的官网页面重新测试，不能只看WordPress编辑器中的窗口是否正常显示。
四、权限没问题，继续检查音频有没有到达播放器
以金福来数字人对应的实时接口文档为例，WebSocket承担实时通信和WebRTC信令，返回的音视频通过WebRTC接收。因此，WebSocket连接成功，不代表音视频已经正常播放。
开发人员可以沿着三个位置检查。
先看有没有收到音频轨道。 检查 ontrack 事件中的轨道类型。如果播放器绑定的是 MediaStream，可以通过 getAudioTracks() 查看其中是否包含音频。返回空数组，只能说明这个媒体流没有音频轨道，还需要检查是否绑定错了流，或音频是否由另一个播放器处理。
再看媒体流是否绑定到了正确的播放器。 检查实际显示数字人的 <video> 元素，其 srcObject 是否接收了对应的远端流，而不是误绑定到预览画面或其他元素。官方接入示例包含了接收轨道、设置 srcObject 和调用播放的过程。
最后确认轨道是否真的有数据。 音轨存在，并不代表持续收到可播放的声音。例如音轨的 muted 状态可能表示暂时无法提供媒体数据，不能与播放器自己的静音开关混为一谈。
这样才能分清问题发生在服务输出、网络接收、前端绑定，还是最终播放。
五、另一种情况：能听到数字人，但说话后没有回应
这种情况应转到麦克风排查，不要继续修改扬声器播放设置。
在Chrome中进入“设置—隐私和安全—网站设置—麦克风”，检查当前网站是否被允许使用麦克风，并确认选中了实际使用的输入设备。系统层面的麦克风权限也需要允许浏览器访问。
正式网站还应使用HTTPS。网页调用 getUserMedia() 获取麦克风，需要安全上下文和用户授权；本地开发地址 localhost 存在例外，不能因为本地测试正常，就认为普通HTTP网站也能正常录音。
重新授权后再提问，并检查是否收到用户音频或识别结果。只有播放与采集都正常，才算完成一次语音对话。
六、改完以后，用这张表验收
下面是建议验证项，不是已完成的测试结果。每次测试应记录浏览器版本、页面地址和实际现象。
| 验证项目 | 操作方法 | 需要确认的结果 |
|---|---|---|
| 首次进入页面 | 使用新的浏览器配置文件访问 | 无法自动发声时，有清晰的开启声音入口 |
| 手动开启声音 | 点击按钮，再触发回答 | 能实际听到声音，而不只是画面在动 |
| 官网嵌入 | 对比原始页面与嵌入页面 | 相同操作下均能正常播放和申请所需权限 |
| 麦克风恢复 | 拒绝授权后，再改为允许 | 页面能够提示重新开始对话，并恢复收音 |
| 连续交流 | 提问、等待回答，再追问 | 收音与播放持续正常，没有只成功第一轮 |
不要把“暂时听到一次声音”当成全部问题已经解决。建议把原始现象、修改位置和验证结果一起保存，方便后续复查。
七、AI数字人没声音常见问题
AI数字人有画面没声音，最先检查什么？
先确认当前网站没有被浏览器静音，再点击一次“开启声音”或“开始对话”。如果点击后恢复，问题通常与自动播放限制有关。
为什么必须点击后才有声音？
Chrome等浏览器通常会限制首次访问时的有声自动播放。网页应保留明确的播放按钮，并在用户点击后调用 play()。
iframe嵌入官网后没有声音，应该查哪里？
先检查 iframe 的 allow 属性，再核对父页面的权限策略。仅添加 autoplay 或 microphone，不能覆盖父页面已经禁止的能力。
能听见数字人，但它听不见用户怎么办？
这是麦克风采集问题。检查浏览器和系统麦克风权限、输入设备选择以及网站是否使用 HTTPS，然后重新开始对话。
八、官网接入遇到问题，把这些信息一起交给技术人员
沟通金福来数字人的官网接入方案时，可以准备：网站地址、浏览器版本、接入方式、复现步骤，以及脱敏后的报错截图。 这些信息能帮助区分是浏览器限制、网页嵌入问题，还是媒体接收异常。
金福来数字人官网提供网站接入相关服务，并设有“咨询试用”入口。正在接入或评估企业官网数字人的用户，可以通过该入口提交需求，进一步沟通接入方式与交互流程。
排查AI数字人没声音，最重要的是按顺序确认：浏览器允许播放了吗，音频实际收到了吗，播放器接对了吗，用户的声音又有没有传进去。 把这些环节分开检查，比反复刷新页面更容易找到原因。
