最近很多开发者开始关注 Grok 的语音交互能力尤其是新增的双语音选项 Aurora 与 Liora。相比单纯在网页里“打字问答”语音交互更适合移动端、车载场景、智能助手类应用也能给内容创作者提供更自然的配音素材。本文就从功能定位、环境准备、切换方式、API 调用、文本导出到 Word 这几个角度做一次完整的双语音对比与实操梳理。文章主要面向三类读者一是想给个人项目接入 Grok 语音能力的开发者二是做自媒体或课程内容、需要快速生成配音稿的创作者三是单纯想弄清楚 Aurora 和 Liora 到底有什么区别、什么时候用哪个的普通用户。读完你至少能明白这两条语音各自的风格差异、在网页端如何切换、通过 API 调用时怎么传参数以及如何把 Grok 生成的文本规范地导入 Word。1. 背景Grok 双语音是什么1.1 语音交互为什么越来越重要Grok 本身是 xAI 推出的对话式 AI 助手早期大家更关注它的文本推理、代码生成和实时信息检索能力。但随着移动端和智能硬件普及语音正在成为 AI 产品的重要交互入口。用户开车时、做饭时、运动时很难盯着屏幕打字这时候语音输入和语音回复就成了刚需。所谓“Grok 新增双语音”简单理解就是 Grok 在语音回复能力中提供了两种可选音色Aurora 与 Liora。它们不是两个独立的大模型而是基于同一套语言模型能力之上的语音合成角色。你问同一个问题选择 Aurora 和选择 Liora得到的文字内容可能一致但“听感”完全不同。专业角度来看语音回复背后依赖的是 TTSText-to-Speech文本转语音技术。TTS 系统把模型生成的文字转成音频流再通过流式传输推给客户端播放。音色差异通常来自不同的声学模型训练数据以及对韵律、停顿、重音等参数的不同控制方式。1.2 Aurora 与 Liora 的定位差异从命名和产品定位上看Aurora 与 Liora 走的是截然不同的风格路线不过在具体听感上不同版本可能还有一些差异建议以实际体验为准。Aurora更像“清晰播报型”语音。它适合朗读长文本、技术文档、新闻摘要特点是咬字清楚、语速平稳、信息密度高。Liora更像“自然陪伴型”语音。它适合闲聊、情感支持、创意讨论特点是语气更温和、停顿更自然甚至会有一些语气助词。这种区分并不是简单把音量调大调小而是从训练数据到韵律控制都做了差异化处理。Aurora 在长句朗读时更稳Liora 在短句对话时更生动。1.3 两条语音的适用场景Aurora适合语音版新闻摘要、技术课程配音、播客开场白、产品功能介绍。Liora适合情感陪伴类应用、客服机器人、儿童故事、创意头脑风暴、日常闲聊。如果你的应用是工具型、信息型优先选 Aurora如果你的应用是关系型、陪伴型优先选 Liora。2. 环境准备与版本说明2.1 使用方式概览Grok 双语音并不是只能在唯一的客户端里使用。从我目前看到的信息看常见使用入口包括入口适用场景语音能力Grok 网页版快速体验、文本对话、语音回复试听支持双语音切换Grok 官方 App移动端对话、语音输入、语音播报支持双语音切换API 接口自建应用、自动化脚本、第三方集成支持语音参数控制Grok Build快速构建轻量应用原型的平台可接语音能力版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。不同版本、不同地区的功能开放程度可能不一样如果你的账号里暂时没有语音选项优先检查客户端是否是最新版。2.2 基础环境要求一般来说使用网页版和 App 只需要一个可用的 Grok 账号。网页版还提供免费使用入口但免费范围的额度和功能开放情况要以官方页面为准。如果是开发者要调用 API则需要准备一个可用的账号对应的 API Key支持 HTTPS 请求的开发环境如 Python、Node.js、curl。这里要特别提醒任何 API Key 都属于敏感凭据不要提交到公开仓库不要写死在前端代码里更不要截图发到群里。建议通过环境变量或本地配置文件管理。2.3 推荐工具清单网页版Chrome、Edge 等现代浏览器。移动端iOS / Android 官方 App。开发者Python 3.8、curl、Postman 或 VS Code。文本导出Typora、VS Code、Pandoc、Microsoft Word。3. Aurora 与 Liora 核心对比3.1 音色表现与情感表达从语音合成角度音色主要由声学模型决定。Aurora 的声线通常听起来更清亮、清晰适合信息型朗读Liora 的声线更柔和、有温度适合对话型场景。情感表达方面Aurora 更克制重音和停顿都服务于信息传递Liora 则更松弛语句之间有明显的情感起伏。需要说明的是TTS 的情感表达是“可控的”不是固定的。两者都可能支持通过提示词或参数来调整语气具体能力范围要以官方文档为准。3.2 信息播报与对话陪伴的取舍用一张表来总结它们在内容类型上的倾向维度AuroraLiora内容类型新闻、文档、技术说明闲聊、情感陪伴、创意对话语速偏平稳适合信息密集场景偏自然适合边想边说情绪表达克制、准确丰富、温和长文本更适合长时间朗读建议分短句使用短对话稍显“正式”更自然、更接近真人聊天典型场景新闻播报、语音助手播报心理陪伴、睡前故事、陪练选择原则并不复杂如果你的内容是“给用户看的”Aurora 更稳如果你的内容是“和用户聊的”Liora 更合适。3.3 语音指令与交互差异在实际交互中用户在网页版切换语音后提问风格也可能影响听感。比如对 Aurora 说“请用简洁的方式介绍 Scrum”它会更注重条理。对 Liora 说“我今天有点累随便聊聊”它会更容易进入陪伴状态。这其实不是语音模型在理解文字而是 Grok 在生成回复时会把“当前语音角色”作为上下文的一部分从而影响文本的措辞和节奏。语音模型最终朗读的文本是由语言模型生成的所以两条语音在“说什么”的层面就已经有差异不只是“怎么读”的差别。4. 核心原理语音合成与文本生成的关系4.1 TTS 的基本流程要理解双语音的异同有必要了解 TTS 的基本流程语言模型生成回复文本。文本归一化把数字、缩写、特殊符号转成适合朗读的形式。音素转换把文本转成音素序列。声学模型预测预测梅尔频谱。声码器合成把频谱转成音频波形。客户端播放。Aurora 和 Liora 的差异主要发生在第 4 步和第 5 步。文本层面的差异则来自第 1 步的提示词控制。4.2 为什么“听感”不只是音色很多人以为换语音只是换了一个“发声的人”其实语音模型还影响停顿位置、重音、语速、语调曲线。同样是“好的我明白了”这句话Aurora 可能读成“好的短停我明白了”听起来像完成任务。Liora 可能读成“好的~我明白了”语调微微上扬听起来像认真回应。这就是韵律层Prosody的差别。在语音合成中韵律控制是比音色更难的部分也是最影响听感的部分。4.3 双语音对应用开发的意义对开发者来说两条语音意味着产品有了“人格选择”。你可以做两个模式“专业模式”默认使用 Aurora让助手听起来更高效。“陪伴模式”默认使用 Liora让助手听起来更亲切。这种方式比让用户自己脑补“AI 助手性格”更直观因为声音本身就是人格的重要载体。5. 实战一网页版切换双语音5.1 打开语音设置网页版入口比较简单打开 Grok 官网并登录。进入对话界面。找到语音或声音设置入口。在语音列表中选择 Aurora 或 Liora。保存后开始语音对话系统会用对应语音朗读回复。不同版本的界面差异较大如果你的页面没有语音入口请优先升级到最新版本或者查看官方帮助中心。5.2 试听与验证切换完成后可以输入同一句测试文本观察两条语音的差异。推荐测试内容请用三句话介绍什么是大语言模型。分两次提问分别切换 Aurora 和 Liora重点听这几个维度第一句语速是否有差异。中间停顿是否自然。结尾语气是下降还是上扬。长句子有没有吞字或机械感。5.3 网页版使用注意事项语音回复依赖网络音频流网络不稳定时可能出现卡顿。浏览器需要允许自动播放音频。免费使用入口可能有频率限制频繁切换可能触发风控。不要用自动化脚本绕过网页端限制合法合规使用即可。6. 实战二通过 API 调用双语音6.1 准备 API Key如果你的应用需要调用 Grok 的语音能力基本流程是在官方控制台创建 API Key。将 API Key 写入环境变量。发送 HTTPS 请求请求中带上语音参数。本文把具体接口名省略因为不同版本接口差异较大。重点演示思路你需要根据自己的接口文档调整参数名。6.2 用 curl 体验语音切换在 Windows 的 CMD 中也可以直接体验。先设置环境变量再发送请求。Windows CMD 设置环境变量示例set GROK_API_KEY你的key然后使用 curl 发送请求核心思路如下curl -X POST https://api.example.com/v1/chat/completions ^ -H Authorization: Bearer %GROK_API_KEY% ^ -H Content-Type: application/json ^ -d {\model\:\grok-latest\,\voice\:\Aurora\,\messages\:[{\role\:\user\,\content\:\你好请介绍一下你自己\}]}把 voice 参数换成 Lioracurl -X POST https://api.example.com/v1/chat/completions ^ -H Authorization: Bearer %GROK_API_KEY% ^ -H Content-Type: application/json ^ -d {\model\:\grok-latest\,\voice\:\Liora\,\messages\:[{\role\:\user\,\content\:\你好请介绍一下你自己\}]}这里说明一下grok-latest是示例模型名真实模型名请以官方文档为准。voice参数可能不叫这个名字也可能是voice_id需要你根据实际接口调整。响应的音频文件通常会返回一个 URL 或 base64 编码内容。6.3 用 Python 写一个语音调用脚本下面是一个 Python 脚本示例演示如何封装双语音调用逻辑。# 文件路径grok_voice_demo.py import os import requests API_KEY os.environ.get(GROK_API_KEY) API_URL https://api.example.com/v1/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } def ask_grok_with_voice(user_input: str, voice: str): payload { model: grok-latest, voice: voice, messages: [ {role: user, content: user_input} ], } resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json() if __name__ __main__: question 请用一句话介绍你自己 for voice in [Aurora, Liora]: print(f当前语音{voice}) try: data ask_grok_with_voice(question, voice) print(data) except Exception as exc: print(f请求失败{exc})脚本运行方式python grok_voice_demo.py实际项目中建议把API_URL和模型名统一放到配置文件里避免代码写死。6.4 API 调用的常见返回结构语音接口的返回结构通常包括字段说明id请求唯一标识object返回类型content文本内容audio.url音频文件地址audio.expires_at音频有效期usageToken 消耗信息你需要先判断音频是直接返回 base64 还是返回下载链接。如果是下载链接要注意有效期及时保存到本地或对象存储。7. 实战三把 Grok 生成的文本加入 Word7.1 为什么要单独处理文本导出很多内容创作者遇到的问题是Grok 生成了一段很好的语音稿但复制到 Word 后排版全乱标题层级丢失代码块变成纯文本。这其实不是 Grok 的问题而是 Markdown 与 Word 之间的格式鸿沟。7.2 方法一复制后直接粘贴如果你只需要纯文本内容在 Grok 对话界面点击复制按钮。打开 Word。使用“只保留文本”粘贴。Word 中粘贴选项位置Windows右键 - 粘贴选项 - 只保留文本。Mac右键 - 粘贴并匹配格式。这种方法最快但会丢失标题层级和列表缩进。7.3 方法二先转 Markdown 再导入适合需要保留标题结构的场景。步骤一把 Grok 生成的文本保存为.md文件。步骤二使用 VS Code 打开安装 Markdown All in One 插件可以快速预览。步骤三用 Pandoc 把 Markdown 转成 Wordpandoc grok_notes.md -o grok_notes.docx如果你没有安装 Pandoc也可以直接复制 Markdown 内容用 Typora 打开后导出为 Word。Typora 内置了 Pandoc 集成操作路径是文件 - 导出 - Word。7.4 方法三用 Python 脚本生成 Word如果你需要批量处理文本可以用 python-docx 库。安装依赖pip install python-docx示例代码# 文件路径md_to_word.py from docx import Document doc Document() doc.add_heading(Grok 语音稿整理, level0) lines [ ## 1. 项目背景, 这里写项目背景内容。, ## 2. 核心结论, 这里写核心结论。, ] for line in lines: if line.startswith(## ): doc.add_heading(line.strip(# ), level2) else: doc.add_paragraph(line) doc.save(grok_output.docx) print(Word 文件已生成)这种方式适合需要把 Grok 生成的多段内容批量合并到 Word 文档的场景。脚本里可以再加表格、代码块样式按项目需求扩展。8. 常见问题与排查思路8.1 问题速查表问题现象常见原因解决思路网页端没有语音选项浏览器版本过旧或功能未全量开放更换最新版 Chrome/Edge检查账号权限切换语音后没有声音浏览器禁止自动播放点击页面后再次播放开启自动播放权限语音卡顿或断续网络波动或音频流缓冲不足切换网络降低音频质量参数API 返回 401API Key 错误或已过期检查环境变量重新生成 API KeyAPI 返回 429请求频率超限降低并发增加退避等待返回的音频 URL 无法访问音频链接过期尽快下载或改用 base64 返回CMD 中 curl 中文乱码Windows 控制台编码问题执行chcp 65001后重试生成的 Word 格式混乱Markdown 与 Word 格式不兼容使用 Pandoc 或 Typora 转换8.2 详细排查CMD 中文乱码Windows CMD 下调用 curl 时中文乱码是常见问题。原因通常是默认编码为 GBK而接口返回的是 UTF-8。解决方法chcp 65001然后再执行 curl 请求。如果还是乱码可以考虑把请求参数写入 JSON 文件用-d body.json方式提交。8.3 详细排查语音切换不生效如果你在网页端选择了 Liora但播放声音仍是 Aurora可能原因页面缓存没有刷新重新加载页面。语音设置没有保存成功。当前对话历史仍然使用旧语音参数新建对话再测试。客户端版本未更新升级到最新版。顺序排查即可一般前两步能解决大部分问题。8.4 详细排查调用频率限制如果在 API 调用时遇到频率限制不要通过延迟重试暴力解决。更合理的方式降低请求 QPS。对语音回复结果做本地缓存。把相同问题的音频结果保存为文件避免重复生成。在团队协作场景中还要为不同业务分配不同 API Key避免一个应用出问题影响全部业务。9. 最佳实践与工程建议9.1 按场景固化语音策略在开发语音应用时不要给所有用户提供同一个默认语音而是根据场景固化策略新闻类、资讯类默认 Aurora。陪伴类、聊天类默认 Liora。儿童内容优先 Liora语速可进一步调慢。技术教程Aurora 为主配合文本高亮更佳。如果产品允许用户自定义也要把“当前语音”作为用户设置项保存起来而不是每次进入对话都重新选择。9.2 音色能力要有兜底方案语音合成能力具有很强的时效性和地域性正式上线前一定要做兜底音频文件下载到本地避免临时链接过期。对 TTS 异常设计重试机制最多重试 2 次避免死循环。如果语音服务不可用回退到纯文本回复不让用户卡在“播放失败”界面。在日志中记录语音合成耗时和失败率便于监控。9.3 文本内容与语音内容的优化Grok 生成的文本如果是用来朗读的建议做如下优化避免使用“图 1 展示了……”这类视觉指向表达。把长句拆成短句降低朗读难度。为语音稿添加“停顿提示”例如用逗号、分号控制节奏。英文缩写按需要拼读例如 API 可以说成“A-P-I”。9.4 安全与合规红线无论使用哪条语音都必须注意语音内容不得涉及违法、暴力、侵权信息。涉及个人信息的语音对话要做好脱敏处理。语音合成音频如果对外发布需要确认版权和平台规则。不要在提示词中加入绕过限制、破解系统等不安全内容。9.5 生产环境的配置管理在项目中使用双语音建议用配置文件区分环境# 生产环境配置 grok.voice.defaultLiora grok.voice.newsAurora grok.audio.qualityhigh grok.timeout30测试环境可以用较低音频质量降低成本和延迟。生产环境再切换到高音质。10. 总结与下一步学习路线本文围绕 Grok 新增的双语音 Aurora 与 Liora梳理了功能定位、对比维度、网页端切换、API 调用、文本导入 Word 和常见问题排查。核心结论是Aurora 更偏信息播报Liora 更偏自然陪伴没有绝对的好坏只有是否匹配场景。如果你现在准备开发一个语音问答应用下一步可以从这几件事开始先体验两条语音的实际听感选定一个默认音色。用 API 调通一个最小语音回复 demo。把音频文件保存逻辑、超时重试、错误日志补上。尝试用 Grok Build 快速搭建一个应用原型把语音能力嵌入实际产品流程。如果你只是普通用户建议先把网页版双语音切换用熟练尝试不同提示词找到最适合自己内容风格的音色。语音交互还在快速迭代中参数和接口后续可能调整实践中要多留意官方文档更新。如果本文对你有帮助可以收藏备用也欢迎在评论区分享你的实际听感区别。