一句话看懂：OpenAI 用户 Peter Yang 在 X 上指出，ChatGPT Live 语音助手与 Codex 代码执行/工具调用能力之间严重割裂：用户通过语音要求打开 Google Doc 被拒，但手动切换插件后 Live 模式立刻获得上下文。这暴露了 OpenAI 当前产品组合中最明显的整合缺失——一个能说话的 AI 却无法同时使用它已有的工具。
事件核心：发生了什么
2026 年 7 月 16 日凌晨，用户 Peter Yang 发布了一条带有实际测试细节的推文。他在使用 ChatGPT Live 进行户外步行对话时，语音要求助手调取自己的 Google 文档，系统直接回答“做不到”。随后他手动在会话界面中触发了 Documents 插件，ChatGPT Live 立刻读到了正确的文档内容。Yang 进一步指出，ChatGPT Live 与 Codex 是完全独立运行的两套产品：Live 负责语音交互，Codex 负责调用插件、浏览器操作和代码执行，二者之间没有任何上下文或能力共享。他形容这是 OpenAI 当前“最大的错失机会”。该推文在数小时内获得超过 2.1 万次浏览和 390 次互动。
为什么重要
这一现象直接指向 OpenAI 在语音产品与工具产品之间的集成断层。ChatGPT Live 代表了实时语音交互的未来方向，但它的能力边界被人为限制在“聊天”层面；Codex 已经能够读写文件、操控浏览器、执行代码，却无法被语音模式调用。对一家声称要构建全能通用助手的公司来说，这种内部产品孤岛意味着用户体验严重分裂——用户必须手动切换模式、记住哪个能力在哪个产品里才能实现完整功能。这不仅削弱了语音助手原本“无手操作”的核心价值，也让 Codex 的自动化能力沦为桌面端的附属功能。从竞争角度看，如果其他对手（如集成 Gemini 的 Google Assistant 或 Anthropic 的 Claude 语音模式）率先打通工具调用链，OpenAI 在“AI 助理”这一赛道的先发优势可能迅速被侵蚀。
对用户/开发者/创作者的影响
对于日常用户，这意味着语音助手的实用性大幅受限：你无法在散步时让它帮你回复邮件、安排会议、编辑文档或部署代码——而这些恰恰是语音助手能真正解放生产力的场景。对开发者而言，目前不得不自行编写桥接逻辑：比如用 Codex 先执行文件读取，再把结果回传给 Live 进行语音朗读，增加开发成本和延迟。对于内容创作者和商业用户，目前唯一可行的路径是在桌面上提前准备好插件上下文，才能触发 Live 的协作能力。这种割裂让 ChatGPT Live 更像是一个语音版的“聊天玩具”，而不是一个能真正完成任务的数字助理。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
首先，OpenAI 是否会在下个版本中让 ChatGPT Live 自动感知用户已安装的插件列表，做到“知其所有”后再决策是否调用。其次，Codex 是否会接入 Live 的语音输入管道，使得用户可以通过语音直接触发文件搜索、邮件发送或代码执行等操作。第三，其他语音助手竞品（例如正在整合 Drive 和 Gmail 的 Google Gemini 或亚马逊 Alexa+）如果率先打通工具调用，将直接挤压 OpenAI 语音产品的应用场景。目前公开信息显示，OpenAI 尚未对这一反馈做出官方回应，但这类来自活跃开发者的实测批判，常常是产品路线调整的起点。
