Gemini 3.8 Live发布：网站语音咨询可以先从哪一件事做起？

2026 年 9 月 15 日，Google 发布 Gemini 3.8 Live 和 Gemini 3.8 Live Extended Thinking。开发者可通过 Gemini API 与 Google AI Studio 构建实时对话应用，其中异步工具调用允许后台执行任务时继续对话。这给产品咨询提供了新可能，也要求网站清楚地区分“正在查询”和“已经办成”。Google 开发者公告

真正需要设计的，不只是一个麦克风按钮。客户说错了型号怎么办，查询期间改变需求怎么办，工作人员最后能收到什么，都会影响这项功能是否有用。

先判断客户需要实时对话，还是只需要少打字

语音留言、转写和实时咨询，适合不同的任务。访客想把一段复杂问题发给客服，录音后整理成文字可能就够了；如果回答需要不断追问使用条件，实时对话才更有发挥空间。

网站上的实际任务	可以先采用的方式	应交付的结果
客户描述故障，等待人员回复	语音留言或转写	可修改的文字、相关型号与附件
客户不知道该看哪个产品	实时问答加资料查询	确认过的需求与对应资料链接
客户已有明确型号，要问库存	对话加库存系统查询	对应地区、型号、查询时间的结果
客户希望直接下单或修改订单	对话加身份与业务操作	获得授权的操作和可核对的业务记录

如果每天只有少量咨询，客户主要需要上传图纸、填写尺寸，先优化原来的表单也可能更合适。语音的优势在于降低表达负担，不适合强迫每位访客开口。办公室、公共场所或嘈杂车间里的用户，仍然需要完整的文字入口。

Google 将普通 Live 版本侧重于规模与效率，将 Extended Thinking 用于更复杂的任务。可以按咨询复杂度试用两者，但网站的资料是否完整、工具能否返回正确结果，往往应比模型选择更早解决。产品定位与开发入口见官方模型介绍。

用一条设备咨询，定义第一版能做完什么

下面是一套自拟的设备网站方案，用来说明产品设计，没有上线测试数据。

访客说：“想买 B15，每天运行几个小时，车间比较潮湿，能不能用？”如果系统立即朗读产品介绍，很可能漏掉最重要的使用条件。更合适的处理是先确认型号，再补问资料查询真正需要的信息，例如现场湿度范围、安装位置，以及用户说的“每天几个小时”到底是多少。

这些条件应显示在页面上，让客户能修改。型号尤其适合同时保留识别文字与选项：“我听到的是 B15，您指的是这款设备吗？”一旦选定，再把内部产品编号传给资料查询。不要让后续工具只凭模糊的口述名称自由匹配。

查询回来后，回答可以围绕三点展开：已确认的使用条件、手册里对应的适用范围、仍需工作人员判断的缺口。页面同时展示资料标题和链接。客户既能听到解释，也能打开原文，工作人员也知道答案从哪里来。

第一版的完成条件可以写得很具体：客户能够确认型号、看见适用资料、修改需求摘要，并选择是否发送咨询。这样即使最后需要人工判断，前面的对话也已经减少了一轮重复询问。

产品资料需要怎样准备？

先选一个产品系列，把官网页面、手册和常见问题整理到一致的型号体系中。资料至少要能区分型号、适用条件、版本和来源。多款设备共用一份手册时，查询结果必须指出当前答案适用于哪款，不宜把整份手册的一段话直接当作所有型号的结论。

还有一类资料要单独处理：价格、库存、交期与地区服务。这些信息变化快，不能因为产品页写着“现货”就告诉客户今天一定能发货。如果没有业务接口，第一版可以收集数量、地区和期望时间，交给人员确认；如果已经有接口，页面应说明结果对应的查询时间与条件。

例如客户最初问一台设备，随后说可能要采购二十台。产品适用性资料也许不变，但库存和交期查询应重新执行。把两类信息分开，才能知道哪些答案可以沿用，哪些必须重查。

WordPress 负责发布产品资料，不等于它已经具备可供语音应用使用的全部数据。上线前应确认查询服务能读取哪些页面或字段，多久同步一次，资料撤下后会不会继续被检索。可先人工维护少量经过核对的资料，避免第一版直接抓取全站后无法解释来源。

对话继续进行时，怎样处理后台查询？

异步调用有助于减少等待时的沉默，但应用需要管理查询和当前需求的对应关系。Google 的 Live API 工具文档提供了非阻塞调用以及结果返回时的调度方式；这些能力需要应用配置，不能认为接入模型后就自动具备完整业务流程。

应用先为已确认条件建立查询记录，结果返回时只采用仍有效的一版需求。下面的时间表把改口与返回顺序放在一起验证。

查询失败：“暂时查不到库存”与“库存为零”不能使用同一个结果。超时意味着状态未知，网站可以提供重试或人工确认，不应把缺失数据解释成业务事实。

**客户打断：**区分两件事：停止播放当前回答，是否也要取消后台任务。用户只是想补充条件时，可能继续查询仍有意义；用户明确取消提交时，应用则应检查提交是否已经执行。声音停了，并不等于后台操作被撤销。

同一个客户改口，结果返回顺序怎样判定

延续前面的设备咨询，假设客户在查询中将型号从B15改为B50。下面是应用需要实现的状态示意，不是Live API实际运行日志。

时刻	本次发生什么	页面采用什么
09:00:01	客户确认B15，发出查询Q1，需求版本V1	显示“正在查B15资料”
09:00:03	客户改成B50，确认后建立V2并发出Q2	当前型号改为B50，V1不再有效
09:00:04	Q1返回B15手册	保存旧查询结果，不作为当前答案
09:00:05	Q2返回B50手册	检查型号和资料版本后展示
09:00:07	客户补充数量20台	保留B50适用资料，若要查库存则按20台重新查询

关键在于查询关联需求版本，而不只是“最后返回的结果优先”。Q1晚于Q2返回，也不应覆盖V2。这个顺序在网络有延迟时尤其容易暴露问题。

对应的验收输入可以直接交给开发者：“先确认B15，查询未结束时改为B50，让B15响应延迟返回；最终页面、语音与待提交摘要均必须是B50。”若页面已更新而语音仍念B15，说明两个输出没有采用相同的有效结果判断。

工具文档还明确，Live API工具响应需要客户端处理。这意味着业务记录与模型对话之间的关联要由应用维护；官方支持非阻塞调度，不等于已经替网站实现上述型号纠错。

询盘提交与人工交接，应在页面上看得见

语音可以帮助整理需求，最终提交前最好让客户看见联系人、型号、数量、地区和备注，并能够修改。复杂需求不必强行塞进固定字段，保留确认后的原话摘要也很有帮助。

提交动作需要独立的状态：待确认、正在发送、已保存或发送失败。只有后台确实保存后，才显示“已提交”并给出编号或明确的成功回执。通知邮件发送失败与询盘保存失败也应分开，避免客户因为没收到邮件而重复提交。

人工接手时，最有用的是一份短而准确的交接内容：确认过的需求、已经查看的资料、尚未解决的问题、回复渠道。工作人员不需要先读完整录音才能判断下一步，客户也不该再重复所有信息。

例如系统无法判断潮湿环境是否适用，可以把“客户确认 B50，安装环境待技术人员评估；已提供环境条件，尚未承诺适用性”交给人员。这样的交接比只留下“客户咨询 B50”更容易继续处理。

接入与验收，要同时检查页面和业务记录

Live API 概览列出了两种连接方式：由自己的后端转发，或由前端直接连接。官方建议生产环境的前端直连使用临时令牌，避免把标准 API 密钥放进浏览器。选择哪种方式，还要考虑现有网站后端、工具权限和媒体连接维护能力。

对于 WordPress 项目，可以把页面入口、资料查询和业务操作分开验收。页面负责让客户知道是否正在录音、如何停止以及如何改用文字；查询服务负责提供正确资料；提交服务负责保存确认后的内容。任意一层失败时，另外两层都不应把它掩盖成“已完成”。

试用时，可以从下列动作开始，而不是只听一段顺畅的演示：

试用动作	应核对的实际结果
拒绝麦克风权限	仍能进入文字咨询，不反复弹出权限请求
混说型号、数字和单位	页面能确认或修改，工具收到正确字段
查询期间换型号	旧结果不会覆盖新需求
网络断开后重新连接	说明状态，已保存的询盘不会重复生成
查询服务返回错误	明确失败原因范围，提供可继续的入口
要求人工处理	人员能收到已确认摘要与未解决问题

评估成本时，记录每次咨询的音频输入、输出、工具使用和实际完成情况，结合当时的官方计费规则计算。长时间闲聊、反复重试或错误的工具查询，都会让“单次成功咨询”的成本与一段短演示不同。

同样，效果也应围绕任务看：访客是否找到正确资料，需求是否完整，人员还要追问几次，提交是否成功。若这些指标没有改善，声音更自然也不足以说明功能值得扩大。先把一个产品系列做好，再扩大资料范围和操作权限，会更容易找到真正影响体验的环节。