端云协同AI导游实战：星鸿OS+蓝云元界MaaS

十一长假，我带着一台跑着星鸿OS的测试机，在朝云宫遗址公园把AI导游功能完整跑了一遍。所谓AI导游，不是播一段语音包，而是用大模型MaaS平台——蓝云元界MaaS——加上端侧实时感知，让手机变成一个真正认识古建筑、能做多轮对话、能根据兴趣切换讲解风格的本地向导。这篇文章就是这次实战的完整记录，包括为什么这么拆、端云两边各自做了什么、现场踩了哪些坑，以及一些光看文档根本发现不了的细节。如果你也在做智能导览、智慧文旅，或者想在国产操作系统上接MaaS能力做AI应用，这篇应该对你有用。

1. 为什么用“端侧+云端”拆：传统导览App的痛

1.1 传统导览机到底差在哪

景区里那种租来的导览机，我用了很多年，每次用都想扔。按键找点位、听固定录音、想追问一个问题完全没人理。讲解内容就是一块“数字录音带”，你走到哪它念到哪，位置稍微偏一点，讲的内容和眼前建筑对不上。更难受的是它没有“好奇心”的概念，游客不是来听填空题的，是想知道“这个屋顶上的小兽是干嘛的”“柱子为什么这么粗”“当年工匠怎么把石头运上来的”这类活问题。

所以我们的目标不是做“会讲话的讲解器”，而是做一个“陪你逛园子的人”。它能识别你眼前是什么建筑，能听懂你随口问的问题，能在你走错路时提醒你，还能根据你是第一次来还是文史爱好者调整讲解深度。这就不是录一段音能解决的，得让手机具备“看”“听”“说”“想”四个能力。

1.2 让AI导游“认得眼前建筑”需要什么

先说“看”。朝云宫里建筑长得都很像，飞檐、斗拱、彩画，外行看不出区别。传统图像分类模型在端侧很难直接区分“这是文华殿还是武英殿”，因为差异非常细微。我们的做法是先让端侧做一个粗粒度判断：检测到画面里有“古建筑”“石碑”“铜缸”“展板”等类别，再用OCR把牌匾上的字读出来，用文字去数据库里定位。这里OCR比纯图像检索可靠得多，因为牌匾本身就是自带标签。

再说“听”。现场环境嘈杂，有导游喇叭、小孩哭闹、景区广播。端侧麦克风阵列加VAD（语音活动检测）是必须的，不能一有声音就唤醒大模型。实测下来，单纯用云端唤醒词检测，延迟能到一秒以上，还容易被广播带偏。所以唤醒词必须放端侧。

最后是“想”。这是蓝云元界MaaS的活。把“看”和“听”得到的信息汇总成一个请求，发给云端大模型，让它结合知识库组织一段自然的话。这一步放在云上是必然的，端侧跑一个几十亿参数的模型，发热和功耗都扛不住，更别提推理速度了。

1.3 方案选型比想象中的更偏端侧

立项时有两条路：一条是全部走云端，手机只负责采集音视频，按帧传上去；另一条是端云协同，端侧先做大量预处理，只把“有价值的信息”传给云端。我一开始倾向全云端，因为省事。但实地测了两轮就放弃了。

景区网络环境比想象中差得多。朝云宫面积不小，有些院落里手机信号只有一格，公共Wi-Fi漫游切换时卡顿严重。如果每帧都传云端，延迟和流量都不可控。而且用户对着一个App说话，如果每次唤醒都要等1.5秒的网络往返，体验会非常难受。

最后做成的架构是这样的：端侧负责唤醒词、VAD、OCR定位、图像粗分类、状态机管理、离线兜底语料；云端MaaS负责多轮对话、复杂知识问答、个性化路线组织和多模态识别兜底。端侧把“眼前是什么建筑”“用户原话”“上下文摘要”拼成一个压缩后的上下文包，传到云端，云端返回文本流，端侧再TTS合成语音播放。这样既控制了延迟，又把成本压在一个合理范围。

2. 端侧感知与星鸿OS的活

2.1 语音链路：从唤醒到ASR的取舍

端侧语音链路是最先做的，也是返工最多的。“小朝，小朝”唤醒词跑在端侧，用了一块很小的DSP模型，功耗低，误唤醒率控制在可接受范围。但真正难的是唤醒之后怎么办。

第一个方案是唤醒后直接录 5 秒音频传云端ASR。问题在于用户说话节奏不一样，有人先说“这个房子”，停顿，再补一句“是什么时候建的”，如果按固定5秒切，后半句就被截掉了。后来改成端侧VAD检测，以“人声停顿超过600ms”作为断句边界，动态决定音频长度。这个600ms也是反复试出来的，太短容易把一个问句切成两段，太长又显得反应迟钝。

ASR模型本身放在云端，用大模型底座的语音识别能力。端侧只传压缩音频，不做本地识别，因为要识别的内容包括“鸱吻”“斗拱”“丹陛石”这类生僻词，小模型词表兜不住。但如果识别置信度低，端侧会主动提示用户“这边信号不太好，要不您走近一点再问一遍”，而不是傻乎乎把错词传给大模型。

2.2 视觉识别：先聚类再“问云端”

视觉链路我测试的时间最长。朝云宫核心区大概有三十多处主要建筑和几十件露天文物，刚开始我试图让端侧直接跑一个三十类分类模型，效果惨不忍睹。建筑之间实在太像，不同殿宇用的彩画图案、屋顶形制差异很小，一个模糊的小目标根本分不出来。

后来换成了“两段式”：端侧先用一个轻量模型判断画面里有没有“可讲解物”，有的话，把画面中心区域裁剪出来做OCR，识别牌匾上的文字。朝云宫几乎所有主要建筑门前都有牌匾，OCR读出来的字，比如“保和殿”，基本就是唯一标识。有了文字标识，再去本地数据库查坐标和讲解词，又快又准。

如果OCR失败，比如牌匾被树荫挡住，就退回第二步：把裁剪后的图像上传蓝云元界MaaS的多模态接口，让大模型直接看图识别。这招成功率不错，但延迟会多800ms到1秒。我建议把这一步放在“用户主动拍照”时触发，而不是让它在自动导览模式里频繁静默调用，否则流量和成本都控不住。

2.3 系统级权限与后台保活

AI导游这个场景对系统权限的要求非常敏感。相机、麦克风、定位、后台联网，几乎占全了。在星鸿OS上，权限不是一次授权永久有效的，应用在后台跑一会儿，系统可能会回收麦克风权限。我最初没处理这个问题，结果用户锁屏再打开，语音唤醒就完全失效了。

解决办法是监听系统权限变更回调，在权限被回收时立刻在通知栏提醒用户重新授权。但更优雅的方案是使用系统的“长时任务”能力，把AI导览声明为前台服务。在星鸿OS上，前台服务有明确的通知栏常驻提醒，用户能随时看到“AI导游正在运行”。这样的好处是减少权限回收概率，代价是通知栏会一直挂一条提醒。对于景区导览App，这条提醒反而让用户更安心，知道定位正在被使用，不会产生隐私恐慌。

还有一点，星鸿OS的分布式软总线能力在实测中给了我意外惊喜。有两台设备做对比测试时，我让其中一台没有蜂窝网络的平板借用了另一台手机的网络通道，共享摄像头数据和定位数据。这个“设备协同”能力让导览终端的选择范围大大扩展，后续如果做成景区自带的智能导览平板，可以直接借用游客手机的流量，省去景区部署Wi-Fi的成本。

2.4 本地状态机：多轮对话的“刹车片”

做多轮导游对话时，我踩了一个典型的坑：大模型什么都想回答，但导游App里不该什么都能聊。比如游客问“这附近有什么好吃的”“故宫门票多少钱”，模型很容易把话题带偏。而且模型在自由对话模式下，经常会忘记自己正在讲解哪座建筑，回答越来越泛化。

所以我加了一个本地状态机，用有限状态来约束大模型的自由度。状态包括：待唤醒、讲解中、追问中、导航中、闲聊中。端侧每轮都会根据当前状态调整发送给MaaS的上下文指令。比如在“讲解中”，系统提示里明确写“你正在讲解保和殿，回答应围绕该殿展开，不要主动推荐饮食或无关话题”。在“追问中”，则提醒“用户在追问上一个话题的细节，请优先从知识库中检索相关段落”。

这个状态机一定要放端侧，不能依赖云端判断。因为状态切换是低延迟操作，用户可能一句话没说完就改了话题，端侧能立刻感知意图变化并切换状态。如果走云端，一次状态切换就要多出一次网络往返，体验上就会“慢半拍”。

3. 云端MaaS：蓝云元界MaaS到底做了什么

3.1 模型选型不是越大越好

蓝云元界MaaS平台上可选的模型分好几个档位。我最初贪心，直接选了最强的对话模型，准确率确实高，但延迟和成本都让人肉疼。一次完整回答平均要2.8秒，连续导览半小时，光token费用就够买好几杯奶茶了。后来换成了中档模型做日常讲解，再配合规则修正，体验反而更好。

这里要明确一个点：导游对话的难点不在于“创意”，而在于“准确和稳定”。游客对历史建筑年代、尺寸、事件的提问都有标准答案，这些不是靠大模型想象力编的，而是靠资料检索。所以中档模型的语义理解能力完全够用，它只需要把检索到的资料重新组织成口语化回答即可。真正需要调用高档模型的，是那些“开放性问题”，比如“你觉得古代工匠是怎么想到用榫卯的”“这个建筑的设计理念对你有什么启发”，这类问题少，但值得用最强模型答出深度。

我的做法是把意图分拣放在端侧：根据用户提问里的关键词和当前状态，给MaaS请求打一个“难度标签”。简单问题走轻量模型，开放问题走高阶模型。这样既保住了质量，又把成本压到了原来的三分之一。

3.2 Prompt工程：把“导游”身份焊进系统

用MaaS最怕的不是模型不会答，而是模型太“AI”。我试过一段很普通的prompt，让模型扮演导游，结果它每句话都以“这座宏伟的建筑”开头，像一个被设定好的播音腔。后来重写了prompt，在系统提示里做了三个约束：

第一，明确“你是一位在朝云宫工作了二十年的讲解员，说话口语化，但每一句都要有依据”。第二，要求“优先使用<资料>标签中的内容，资料中没有的信息，明确说不知道，不能猜测”。第三，控制回复长度，“一般回答不超过150字，只有当用户主动要求详细讲时才展开”。

实际效果差别非常大。加入“说不知道”这一条之后，幻觉率肉眼可见地下降。很多模型为了显得专业会胡编历史故事，一旦它有权说“不清楚”，反而变得更谨慎、更可信。另外我还做了一个取巧的设计：在资料段落里故意留一些“冷门但有趣”的细节，比如某块匾额的字是谁题写的、某棵古树的树龄，这些细节喂给模型后，它会觉得自己“有东西可讲”，语气会自然很多。

3.3 检索增强：景区文档怎么喂给模型

光有Prompt不够，导游要能回答具体问题，必须接知识库。我把朝云宫景区官方讲解词、建筑测绘信息、历史修缮记录、开放时间、卫生间位置等结构化和非结构化的资料全部清洗后，切段做向量化，存进蓝云元界MaaS自带的检索服务里。

RAG的链路是：用户提问后，端侧把文本发给MaaS，MaaS先从向量库里检索最相关的4到6个片段，再把这些片段放在“<资料>”标签里连同问题一起发给大模型。这里有一个关键细节：检索片段不能太多。我一开始贪心，给模型塞了10个片段，结果模型在回答时把多个年代的修缮信息混在一起，出现“建于明代、清代重建”同时说的情况。缩减到4个片段后，回答的准确性反而提升了，因为模型有更多精力“读完”每个片段。

切段长度也有讲究。景区讲解词大多是条目式的，一段讲一个殿宇。按200字一段去切，刚好覆盖一个知识点。如果切太短，一个殿宇的信息被拆散，检索会漏；切太长，一个片段里揉了两三个建筑的信息，模型容易答非所问。

3.4 延迟与成本控制：RAG缓存、上下文裁剪、temperature

先看一个实测数据：接入MaaS早期，端到端平均延迟是3.2秒，优化后压到1.6秒。主要做了三件事。

第一是RAG结果缓存。同一座建筑、同一类问题，第一次检索后，就把检索片段和生成的回答摘要按“建筑ID+问题Hash”存进本地数据库。下次游客问同样的问题，直接调缓存，不再走模型。这个命中率在热门景点非常高，实测高峰期有五成以上的问题都能命中。

第二是上下文裁剪。多轮对话时，如果每轮都把完整历史发给模型，token会飞速增长，延迟和费用双双飙升。我的方案是端侧维护一个“最近3轮原始对话+全局摘要”。全局摘要是每五轮对话后由模型生成一次，把“用户已经问过什么、目前在哪座建筑、什么兴趣倾向”压缩成一段话。后续请求带上这段摘要即可，模型也知道前情，但token成本小很多。

第三是temperature调到0.3。导游讲解需要稳定和准确，不需要太强的随机性。0.3的采样温度让模型每次回答的差异不大，游客听起来更有“确定性”，配合上一条缓存机制，几乎不会出现同一问题两次回答不一样的情况。

4. 现场实测：从检票口到三大殿的一条路线

4.1 开场场景：扫码加载、权限弹窗处理

实测路线从朝云宫午门检票口开始。游客扫码进入小程序后，第一步是选择“当前到达的大概位置”，我做了四张手绘地图让用户点选，而不是直接请求GPS定位。原因是景区检票口人流密集，手机定位容易被建筑遮挡，误差能到几十米，用户手点选反而是最准确的位置初始化方式。

选完位置后，系统引导用户授权麦克风。这一步我踩过权限引导的坑：如果一上来就同时弹定位、相机、麦克风三个权限，用户大概率会拒绝或者懵掉。后来改成“按需申请”，检测到用户点击“开始语音导览”时才申请麦克风权限，点击“拍照识别文物”时才申请相机权限。实测授权通过率从52%提高到87%。

第一站是午门建筑群。端侧自动检测到牌匾文字，加载对应的讲解词，同时开始播放讲解音频。这时候用户还没有提问，系统处于“讲解中”状态。正常速度大概每讲完一座建筑约90秒，正好覆盖游客从看清外立面到走进殿内的时间。如果游客在某处停留时间特别长，系统会判断他可能对细节感兴趣，主动追问一句：“这里您想多看一会儿吗？我可以讲一讲屋顶檐角那排小兽的来历。”

4.2 “主殿为什么要建在高台上？”多轮追问

实测中最成功的场景是三大殿之一的主殿前。游客看到高台，会问“为什么要建这么高”。传统导览机只会念“这是古代等级制度的体现”，太单薄。我们的大模型在RAG检索后，给出了一个嵌套式回答：“一方面是为了防潮防洪，另一方面是等级象征，台基越高，建筑越尊贵。您看这个须弥座，每一层都代表不同的含义……”游客紧接着追问“那为什么只有皇帝能走中间这个台阶”，系统能接住这个话题，从礼制、功能、工艺三个维度继续展开。

这个连续追问过程实测了多轮，状态机在这里起到了关键作用。用户第二次提问时，“追问中”状态触发，MaaS的上下文指令切到“继续上一个话题，使用资料中<礼仪制度>相关段落”，而不是重新介绍这座殿的基本信息。如果没有这个约束，模型容易把刚讲过的内容换个说法再讲一遍。

4.3 弱网环境下端侧兜底问答

在景区西侧一处相对偏僻的院落，手机信号掉到一格，公共Wi-Fi也连不上。游客此时问“这个院子以前是干嘛的”，端侧检测到网络质量差，没有硬等MaaS返回，而是先走本地离线兜底库。

离线兜底库是我在出发前把景区所有主要建筑的基础信息按固定话术存进本地的，一共三千多条。虽然听起来生硬，但能保证用户在完全离线时也能听到准确的一分钟介绍。同时，端侧会在回答前加一句心理提示：“现在网络不太好，我先用离线资料给您简单讲一下，等信号好了我再补充细节。”实测这句话对游客满意度提升很大，因为人最怕的不是等待，而是不知道发生了什么。

等信号恢复后，端侧并不会自动补讲。它会把之前离线回答过的问题ID记录下来，在网络恢复后提示“刚才那个问题还没讲透，要我详细说说吗”。这个设计既避免了突兀的主动补话，又给用户一个追问的入口。

4.4 性能数据记录

跑完整个路线大约两个半小时，全程开启语音唤醒和自动视觉识别。记录一组关键数值：平均端到端回答延迟1.7秒，其中端侧处理占300ms，网络传输占400ms，MaaS推理占800ms，TTS合成占200ms；最差情况出现在午门广场人多拥挤时，延迟2.6秒。机身温度最高到41度，摸起来有点热但没降频。电量从100%掉到57%，其中屏幕和GPS是耗电大户，AI推理和通信加起来才占两成。

这个数据是在中档模型、开启RAG缓存的前提下测出来的。如果全程用最强模型，平均延迟会多0.9秒，耗电和流量也明显增加。所以我现在越发觉得，端云协同的“协同”二字不是口号，是真要把每个请求分类分流，该便宜的便宜，该贵的贵。

5. 实际遇到的5个问题与排查实录

5.1 语音唤醒被景区广播触发

第一次测试时，景区广播一响，手机就开始“小朝，小朝”地乱接话，特别尴尬。排查发现，唤醒词检测模型对同音字和相似音调太敏感，广播里某些词组的韵律和唤醒词接近。

我做了三层修正：第一，在唤醒后必须检测“用户距离”和“声纹方向”，如果声音来源距离超过一米五，不响应；第二，增加双词确认，用户需要连续说两句才能触发完整导游播报，单次唤醒只显示“我在听”的视觉反馈，不直接开口说话；第三，在端侧维护一个“环境音抑制”参数，当周围环境分贝持续偏高时，提高唤醒门限。这三层下来，误唤醒率从每十分钟三次降到了每三小时不到一次。

5.2 相机对焦古建筑琉璃件偏色

视觉识别在拍殿顶琉璃装饰时出现严重的偏黄现象。原因是琉璃瓦在阳光下反光强，相机自动白平衡被高光区域带走。识别结果里，有时候绿色的琉璃脊兽被识别成灰色。

排查后发现单纯调白平衡补偿不行，因为不同光照条件下同一件文物的颜色偏移方向不同。最后直接用多帧拍摄，端侧连续拍三帧，在本地做对齐和颜色归一化，再把处理后的图像上传MaaS。这个操作多花了200ms，但识别准确率从71%提到94%。后来我还加了“冬季模式”开关，在低色温的早晨和黄昏自动提升暖色调补偿，实测阴天识别效果也稳定。

5.3 MaaS返回超时导致对话中断

现场有一次游客问完问题，等了五秒没有任何声音反馈。原因是MaaS在高峰期排队，单次请求超过了我设的3秒超时阈值，端侧超时后直接丢弃了请求，也没有给用户任何反馈。

这个问题的本质是“超时后的行为没设计”。后来我把超时处理改成两种模式：网络层超时，立即播放“信号有点卡，我再说一遍刚才的话，您慢慢听”的缓冲语料；模型层超时，则把用户的问题转为“简化提问格式”重新排队，比如把“这个屋顶上的小兽到底有几种，它们都有什么讲究”压缩成“屋顶小兽种类与含义”，这样请求体更小，模型处理更快，二次成功率明显提升。如果二次还超时，就降级到离线兜底库匹配关键词回答。

5.4 双频Wi-Fi切换时链路断开

景区有公共Wi-Fi，覆盖范围大，漫游切换时发现连接经常断一两秒。表现在当前这个问题回答到一半，TTS播放突然卡住。

抓包发现，切换时旧的连接已经被回收，新连接还没完全建立，TCP层出现一段真空期。解决方式是在应用层做“音频流双缓冲”，把MaaS返回的文本先完整落地为本地临时音频文件，再开始播放。这样就算网络切换，已经生成的音频也能播完。同时断线重连后，自动补拉因切换丢失的音频数据。这个改动之后，用户完全感知不到Wi-Fi切换过程。

5.5 端侧意图识别误伤

有一次游客问“这个台阶为什么要这么多层”，端侧意图识别把“台阶”听成“台阶票”，直接跳到了“票务问题”状态，MaaS开始回答购票指引，非常离谱。

这种误伤的根源在于我把“票务、卫生间、餐饮”这类非讲解意图也接到了大模型上，意图识别一旦置信度不够，就会乱跳。修正方案是：针对高频误伤的意图，在端侧增加规则前置。也就是先做关键词强匹配，比如“门票、几点关门、厕所在哪、哪里吃饭”这类词的组合，直接走固定答案，不经过意图模型。而“台阶、屋顶、柱子”这些建筑词，则强制走讲解通道。规则和模型组合后，误伤率几乎降为零。

6. 工具包与复盘清单

6.1 主要组件选型清单

选型时我的原则是“每一层都用默认方案，先跑通再优化”。最开始不要上来就调模型参数，先把端到端链路跑通，看数据，找瓶颈。

6.2 上线前要检查的8个细节

第一，权限弹窗顺序必须和用户操作路径对应，按需申请，别一次性弹完。第二，所有云端请求都必须设超时，超时后的降级路径要明确，不能静默失败。第三，离线语料要覆盖所有核心点位，宁可少而准，不要多而乱。第四，TTS播放要能随时中断，用户打断时必须能立刻停。第五，多轮对话的上下文摘要要定期重置，防止长时间使用后token膨胀。第六，状态机要增加“超时复位”，用户三分钟没说话，自动回到待唤醒状态。第七，视觉识别不要自动连拍，除非确认用户正对画面中心。第八，所有讲解内容要标注信息获取时间，景区三年一小修、五年一大修，个别建筑可能不开放，要能动态调整。

6.3 我认为最有价值的三处经验

第一处，是不要迷信最强模型。真实景区场景下，中档模型加RAG加规则，效果和体验远超裸奔的强模型，成本却只有三分之一。第二处，是端侧状态机比大模型提示词更能管住行为。模型再听话也需要一个“刹车片”，这个刹车片必须放在触手可及的端侧。第三处，是超时和降级机制才是这类产品体验的分水岭。顺畅网络下各家产品都差不多，信号差、排队时还能让用户觉得“这App真懂事”，这才是核心竞争力。

这次实测让我感觉，AI导游的形态已经从“能对话的讲解器”悄悄进化成“会做决定的地方助手”。它能判断游客的节奏，是走马观花还是驻足细看；能感知网络环境的变化，主动调整回答策略；甚至能根据游客之前问过的话题，在下一座建筑主动提一句“这和刚才聊过的斗拱有些关系”。这些能力单靠云端大模型做不到，单靠端侧小模型也做不到，必须把两边拧成一股绳。手机只是载体，真正的方向，是把一个了解当地、知冷知热的“虚拟行家”揣进每个游客口袋里。