WorkBuddy音视频失败主因是浏览器权限链路中断：需依次检查系统级授权（Windows/macOS隐私设置）、浏览器媒体权限（地址栏锁图标→网站设置）、安全上下文（仅HTTPS或localhost）、设备可用性及广告拦截器干扰。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
检查浏览器权限设置是否被手动禁用
WorkBuddy 依赖浏览器的 MediaDevices.getUserMedia() API 获取摄像头和麦克风，而该 API 会严格遵循浏览器的权限策略。如果用户曾点击过“拒绝”或在地址栏点击过摄像头图标并选择“阻止”，即使页面重载，权限仍保持拒绝状态。
实操建议：
workbuddy-pet
下载
WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo
- 在 Chrome / Edge 地址栏左侧点击锁形图标 → “网站设置” → 找到“相机”和“麦克风”，确认其值为“允许”（而非“询问”或“阻止”）
- 若看到“已阻止”，需手动改为“允许”，然后刷新页面；部分旧版 Chrome 还需点击“清除权限”再重试
- Safari 用户需额外检查系统偏好设置 → “隐私与安全性” → “相机”/“麦克风”，确认 WorkBuddy 对应的域名（如
workbuddy.example.com）已勾选
确认页面是否运行在安全上下文（HTTPS 或 localhost）
getUserMedia() 在非安全上下文中会被浏览器直接拒绝调用，且不抛出明确错误，只静默失败。常见表现是点击开启音视频按钮后无反应、控制台无报错、但 stream 为 null。
实操建议：
- 确保访问地址以
https://开头，或使用http://localhost（Chrome/Firefox 允许 localhost 作为安全上下文） - 禁止使用
http://127.0.0.1、http://192.168.x.x或自签名证书未被信任的 HTTPS 站点——这些均被视为不安全上下文 - 本地开发时可用
npx serve -s或 VS Code Live Server 插件启动localhost:port，避免直接双击 HTML 文件打开（file:// 协议必然失败）
排查 WorkBuddy 自身的媒体设备请求逻辑
WorkBuddy 可能封装了媒体请求流程，若其内部未正确处理 Promise 拒绝、未监听 NotAllowedError 或 NotFoundError，就会掩盖真实原因。
实操建议：
- 打开开发者工具（F12）→ Console 标签页，手动执行：
navigator.mediaDevices.getUserMedia({ video: true, audio: true })观察是否报错及具体错误类型 - 若报
NotAllowedError：说明权限被拒，回到第一个副标题检查 - 若报
NotFoundError：说明系统找不到可用设备，需检查物理设备是否插好、驱动是否正常、其他应用（如 Zoom、Teams）是否独占占用 - 若返回 Promise pending 但无结果：可能是 WorkBuddy 的 JS 脚本加载异常或被广告拦截器屏蔽，尝试禁用 uBlock Origin 等扩展后重试
Windows/macOS 系统级权限未授予浏览器进程
现代操作系统会在首次请求时弹出系统级授权窗口，但该弹窗可能被最小化、遮挡，或用户误点了“不允许”。一旦拒绝，系统不会再次提示，除非手动重置。
实操建议：
- Windows：设置 → 隐私和安全性 → 摄像头 / 麦克风 → 确保“允许应用访问摄像头/麦克风”已开启，并在下方列表中找到对应浏览器（如
Google Chrome），确认开关为开启状态 - macOS：系统设置 → 隐私与安全性 → 摄像头 / 麦克风 → 勾选对应浏览器（注意：Safari 和 Chrome 是独立条目，需分别确认）
- 重启浏览器后重试；若仍无效，可尝试在终端执行：
tccutil reset Camera com.google.Chrome
（macOS，重置 Chrome 的摄像头授权）
http://127.0.0.1 替代 localhost。 
