国庆假期我背着设备在故宫里泡了整整一天一边跟着人流挤过太和殿一边对着手机上的元服务卡片说话。旁边游客以为我在用某款导游App其实我手里的是一套自己搭的组合鸿蒙HarmonyOS负责入口和交互蓝耘元生代MaaS负责调度云端多个大模型两者拼在一起就成了一个能听、能看、能规划路线的“AI导游”。这篇不是什么产品发布会通稿就是我自己的实战全记录。从为什么选鸿蒙元服务而不是单独做个App到MaaS平台怎么接、多模型怎么协作再到国庆现场真实踩到的坑都会写成可以直接复用的经验。想用鸿蒙做AI应用的人、对多AI协作感兴趣的开发者、或者单纯好奇AI旅游产品怎么落地的人都能从里面拿到点实在的东西。1. 为什么要组这个“鸿蒙AI导游”组合1.1 故宫场景下的五个硬需求先把需求列清楚再谈选型。故宫不是一个普通的室内场馆它有几个特性直接决定了技术方案走向。第一讲解内容必须准确。故宫建筑年代、历史事件、文物出处这些信息容不得大模型瞎编。第二交互必须快。站在太和殿广场上游客不会耐心等一个模型思考十秒响应超过三秒基本就属于不可用。第三双手经常被占用。拍照、撑伞、看地图、牵孩子这时候语音和卡片是比键盘输入友好得多的交互方式。第四网络条件很差。国庆期间的故宫基站拥塞是必然的实时的、长连接的方案很容易翻车。第五设备要能撑住半天。早上八点半进场下午五点出来中间连续使用续航和发热都是硬指标。这五个需求放在一起就把方案空间压缩得很小了需要一个免安装的轻量入口需要一套能兜底弱网情况的前端缓存机制需要一个能按需调用不同模型、还能快速降级的云端调度层。1.2 为什么是鸿蒙元服务而不是传统App很多人第一反应是做一个App不就行了。但故宫这个场景App有几个绕不开的毛病。下载安装这一关就直接劝退大部分游客。国庆当天我从午门走到神武门沿途观察了一下大家手机里装的导游类App屈指可数更多人用的就是小程序和系统自带的地图服务。传统App开发成本高、更新周期长、还要适配各种屏幕对一个体验型产品来说太重了。鸿蒙元服务解决的是“入口”和“形态”的问题。它免安装点开即用还能把自己做成一张服务卡片放在桌面、负一屏甚至锁屏上。这意味着用户不需要“先下载、再打开”而是“想用的时候卡片就在那里”。在AI导游这种高频短时交互场景里这个体验差距是非常明显的。另外还有一层考量元服务是鸿蒙系统的原生形态能直接调用系统的语音、定位、相机和设备协同能力不需要像在普通App里一样自己做一堆桥接适配。这对开发工期和稳定性都是实打实的利好。1.3 为什么接口要接在蓝耘元生代MaaS上模型选型这件事我自己纠结了很久。最开始想过本地部署一个开源大模型但一算账就放弃了一台能跑7B模型的设备成本先不说光是维护、调优、供电就够受的。故宫这种突发流量场景高峰期的并发完全不可控自建推理服务要么平时闲着要么峰值直接被打穿成本不可接受。后来把目光转到蓝耘元生代MaaS上。它本质上是一个大模型的托管和调度平台我不用关心GPU从哪来、推理环境怎么配只需要在平台上选模型、配API Key、按调用量计费。更重要的是它支持多模型路由同一个接口可以按策略分发到不同模型——这正好是我要的“多AI协作”的基础。我最终形成的技术判断是鸿蒙负责“端”的体验MaaS负责“云”的智能。端云之间通过标准HTTP接口通信两边解耦。这样我既不用碰底层模型部署也不用被困在某个单一模型的能力边界里。2. 系统架构与分工逻辑2.1 鸿蒙侧元服务卡片与系统能力鸿蒙这侧的架构我拆成了三层。最上面是入口层。用的是元服务的服务卡片用户添加到桌面后卡片上直接展示当前位置的推荐路线和下一个讲解点。不用打开App扫一眼卡片就知道往哪走这是传统App做不到的。中间是交互层。语音是主交互方式调用系统的语音识别能力完成输入再用系统TTS把模型返回的文本转成语音。拍照识别用的是相机能力加多模态模型拍一张太和殿的照片模型返回介绍内容。所有这些系统能力在鸿蒙里通过Ability和Service Kit就能调起来不需要额外引入重型SDK。最下面是本地缓存层。故宫的开放讲解数据、常用问答对、路线点位都提前打包进了本地资源。弱网或者断网的时候优先走缓存不走云端。实测下来这个设计救了很多次场后面详细说。2.2 蓝耘元生代MaaS侧模型路由与Agent调度蓝耘元生代MaaS这一侧我把它当成一个“模型调度中枢”。它提供了一组API我传给它的内容不光是“用户问什么”还包括“这次任务的类型”。它内部有路由策略把不同类型的请求分发到最合适的模型上简单的文物描述给响应快的轻量模型复杂的路线规划给推理能力强的对话模型视觉识别走多模态模型路径。这比我自己在代码里维护一串模型列表要省心得多。我实际用到的核心能力有三个。第一个是多模型调用统一接口不同模型的参数格式有差异但MaaS做了封装我传统一的JSON结构就行。第二个是Agent能力可以定义一些工具让模型在回答过程中调用这些工具比如查天气、查开放时间、调知识库检索。第三个是可观测性每次调用的模型、延迟、Token消耗都有日志方便我事后复盘调优。2.3 一次完整请求的调用链路把整个链路走一遍会更清楚。用户在卡片上点“开始导游”说了一句“我现在在太和殿给我讲讲这里”。语音先进鸿蒙侧的语音识别服务转成文本“我现在在太和殿给我讲讲这里”。文本通过HTTP请求打到蓝耘元生代MaaS的Agent接口。Agent判断这个请求需要两步先定位用户方位然后检索太和殿的讲解资料。定位信息从鸿蒙侧随请求带上Agent据此确定目标点位再从知识库里检索内容最后组织成一段口语化讲解文本返回。鸿蒙侧收到文本后TTS转语音播放同时卡片上更新文字和下一站建议。这整个链路看着简单但有一个非常关键的细节每一步都可能失败所以每层都设计了降级路径。语音识别失败了就直接让用户打字模型调用超时了就走本地缓存回答缓存也没有就给出一个兜底提示引导用户到下一个网络好的区域再试。这套降级策略在国庆当天真的是救命用的。2.4 端云协同为什么是靠谱的组合纯端侧实现AI导游的问题在于能力天花板低本地跑不动大模型视觉识别和多轮对话质量都受限。纯云侧实现的问题在于网络敏感故宫这种场景网络波动是常态一旦链路断了整个服务就瘫了。端云协同的平衡点在于端上做体验云上做智能。轻量的、确定性的逻辑放在端上比如路线点位计算、缓存命中、基础语音交互重度的、生成式的逻辑放在云上比如视觉理解、长文本生成、多轮对话。云不可用的时候端上的缓存逻辑能保证基础体验不归零等网络恢复再无缝切回。3. 功能实现从0到1搭出AI导游3.1 核心功能盘点这个AI导游最终落地了四个核心功能。语音问答是主力。用户直接问“这个建筑是什么时候建的”“屋脊上的小兽有什么讲究”系统用知识库加生成模型作答。实景识别针对的是“我不知道眼前是什么”的场景拍照后由多模态模型描述并给出名称和历史背景。路线规划基于点位数据和用户当前位置算出最优参观顺序并生成下一站提示。随身总结会在用户逛完一个区域后自动生成一段当日游览笔记方便发朋友圈。功能不多但每一个都是故宫场景里真实会被高频使用的。3.2 搭建过程演示一个最小可运行版本我在这里把最小版本的关键步骤列出来方便想复现的人快速上手。第一步注册蓝耘元生代MaaS账号创建一个应用拿到API Key和应用ID。第二步在平台里配置模型路由规则比如text-davinci类任务走对话模型vision类任务走多模态模型。第三步创建鸿蒙元服务项目在module.json5里声明服务卡片Ability并配置系统语音权限。第四步写核心调用逻辑骨架大致是这样的// 鸿蒙侧请求蓝耘元生代MaaS Agent接口 import http from ohos.net.http; import abilityAccessCtrl from ohos.abilityAccessCtrl; async function requestAIAgent(query: string, location: string) { let httpRequest http.createHttp(); let response await httpRequest.request( https://api.example-maas.com/v1/agent/chat, { method: http.RequestMethod.POST, header: { Content-Type: application/json, Authorization: Bearer YOUR_MAAS_API_KEY }, extraData: JSON.stringify({ agent_id: gugong_guide_v1, user_query: query, context: { location: location, timestamp: Date.now() } }) } ); let result JSON.parse(response.result as string); return result.answer; }第五步把模型返回的结构化JSON渲染到卡片上包括标题、正文、下一个推荐点位和一张缩略图。第六步配置端云缓存策略将故宫讲解资料预置于resources/rawfile目录查询时先查端侧索引命中就直接返回未命中才走云端。这套最小版本从开始写到能在模拟器跑通大约花了一个周末。如果只想验证交互逻辑连路线规划都可以先不做把讲解问答做到能用体验就已经能打了。3.3 提示词工程决定导游“像不像”同样的模型提示词写得像说明书还是像导游输出差别巨大。我最终用的系统提示词大致是这个结构你是一位资深故宫讲解员。你在回答时有几个原则 1. 所有关于建筑年代、历史人物、文物材质的信息必须依据提供的知识库内容不得凭空推测。 2. 回答控制在150字以内口语化像在现场和朋友聊天不要用书面语。 3. 如果用户问题超出故宫范围明确告知“这个问题超出我的讲解范围”不要硬答。 4. 每次回答结尾给出一个具体的、可执行的下一步参观建议。 5. 对不确定的信息明说“这部分没有可靠的史料记载”不用猜测填充。这套提示词的核心思路其实是“约束”而不是“引导”。给模型划出行为边界比告诉它“要专业”“要详细”有用得多。Temperature参数我调到了0.3太低会显得死板太高容易跑偏0.3在稳定性和自然度之间比较平衡。3.4 知识库与多模型协作方案纯靠大模型自己的知识做导游错误率是没法接受的。模型会非常自信地说出错误年代而且语气毫无破绽。应对方案是RAG把权威资料整理成结构化的知识库在模型回答前先检索把检索结果和用户问题一起交给模型。我把故宫开放数据、官方讲解词、公开史料整理成大约两千条记录每条记录包含地点名称、别名、建筑年代、历史沿革、关键事件、相关文物。检索用embedding匹配加关键词加权的方式保证在语义和精确两个方面都能命中。多模型协作的核心逻辑是“按任务分配按结果兜底”。语音问答走对话模型视觉识别走多模态模型简单查询直接命中知识库不走生成模型节省成本也降低延迟。当一个模型调用失败或返回格式异常时自动切换到备用模型重试一次如果还不行就走缓存降级。4. 国庆现场实测问题比预期多得多4.1 实测的基本情况国庆当天早上八点半入场晚上五点离场全程大约八个半小时。设备是一台支持鸿蒙的旗舰机开启了元服务卡片、蓝牙耳机、蜂窝网络和GPS。当天的网络状况比我预想的更差太和殿广场附近基站负载极高部分时段请求超时率超过四成。人流方面中轴线区域基本是摩肩接踵的状态手机信号被大量人体遮挡也是个现实问题。4.2 踩过的七个坑和对应解法第一个坑是定位漂移。GPS在宫墙之间的巷道里基本失效偏差经常在几十米以上路线规划自然就乱了。后来改为“点位锚定”逻辑以故宫官方推荐的几十个核心点位为锚用户靠近某个范围就触发该点位的讲解而不是依赖连续定位。第二个坑是语音识别被环境噪音干扰。故宫里有广播、有导游喇叭、有大量人声手机麦克风收音质量不稳定。解决方案是优先使用蓝牙耳机收音同时在端上做了一个简单的VAD检测检测到声音停顿才触发请求减少误唤醒。第三个坑是大模型幻觉。模型在回答某个建筑高度时给出了一个与知识库冲突的数字。查了下日志发现是模型在没有命中知识库的情况下自己“发挥”了。解决办法是把未命中的处理逻辑改成明确拒绝并返回“我暂时找不到可靠资料”的兜底话术而不是让模型编造。第四个坑是API超时。高峰期请求排队严重有些请求在十秒以上才返回。我在端上做了三重处理设置三秒超时上限超时后立即查询本地缓存缓存未命中就把请求列入重试队列等网络空闲再批量发送。第五个坑是发热与续航。连续使用大约四十分钟后手机背部明显发热电量消耗速度超出预期。排查下来主要是相机、语音和网络的连续高负载。后面把拍照分辨率降到720P、减少不必要的定位刷新频率、降低TTS采样率发热好了一些。第六个坑是卡片信息过载。最早设计卡片时把讲解全文、下一站、距离、预计耗时全部都放上去了结果在锁屏和口袋场景下根本没法看。后来砍成三层第一层只显示地点名和一句话简介第二层是完整讲解第三层是操作按钮。卡片在大部分情况下只需要展示第一层。第七个坑是多轮对话的上下文丢失。用户问完“这狮子是公的还是母的”之后接着问“那它呢”模型并没有理解这个“它”指的是什么。原因是上下文窗口管理得太粗暴。后来改成了显式携带最近两轮的用户问题并让模型在回答中复述一下理解的对象避免指代混乱。4.3 现场临时优化记录下午一点左右中轴线的网络基本处于不可用状态。我现场做了一次策略切换把“全程语音导游”改成“关键点位语音加普通点位文字卡片”的混合模式。到了网络好的区域再自动切回语音。这个调整看似简单但把用户体验从“频繁卡顿”拉回到了“基本可用”的水平。另一个现场调整是把路线规划从“按全局最优路径”改成“按当前点位就近推荐”。在人流巨大的时候全局最优路径往往会被拥堵路段打断规划器的收益趋近于零。就近推荐虽然每一步不是最优的但整体体验反而更顺。5. 我的真实体会跑完这一整趟几个感受特别深。第一MaaS平台比自己部署模型省心太多。我不需要考虑GPU规格、推理优化、弹性扩容平台把这些都封装好了我把精力全部放在业务逻辑和体验打磨上。第二鸿蒙元服务的入口形态确实适合这类轻应用。免安装加卡片把使用门槛降到了最低。游客在故宫里不会去装一个App但一定会用到卡片引导。第三提示词和知识库的设计比模型选型更能决定体验上限。一次回答的优劣80%取决于给模型喂的信息和边界20%才是模型本身的推理能力。第四真实场景才是最好的测试环境。在模拟器上跑得再顺到了现场也会遇到意想不到的问题。定位、网络、噪音、发热这些问题在文档里永远学不到。最后分享一个小技巧在卡片上除了“讲解”按钮一定要放一个“重新识别”按钮。故宫里很多点位长得有点像用户拍错地方的情况非常常见。这个按钮能在三十秒内完成纠错体验提升立竿见影。这套鸿蒙元服务加MaaS的组合后续还能扩展很多东西接入更多景区数据源、加入离线语音包、把游览笔记生成做成朋友圈分享模板。如果你也在做AI加旅游的方向希望这篇记录能帮你少踩几个坑。 
长河君 · 2026/10/26 16:37:09 · 阅读 1.2k 鸿蒙元服务+蓝耘MaaS：故宫AI导游实战全记录
国庆假期我背着设备在故宫里泡了整整一天一边跟着人流挤过太和殿一边对着手机上的元服务卡片说话。旁边游客以为我在用某款导游App其实我手里的是一套自己搭的组合鸿蒙HarmonyOS负责入口和交互蓝耘元生代MaaS负责调度云端多个大模型两者拼在一起就成了一个能听、能看、能规划路线的“AI导游”。这篇不是什么产品发布会通稿就是我自己的实战全记录。从为什么选鸿蒙元服务而不是单独做个App到MaaS平台怎么接、多模型怎么协作再到国庆现场真实踩到的坑都会写成可以直接复用的经验。想用鸿蒙做AI应用的人、对多AI协作感兴趣的开发者、或者单纯好奇AI旅游产品怎么落地的人都能从里面拿到点实在的东西。1. 为什么要组这个“鸿蒙AI导游”组合1.1 故宫场景下的五个硬需求先把需求列清楚再谈选型。故宫不是一个普通的室内场馆它有几个特性直接决定了技术方案走向。第一讲解内容必须准确。故宫建筑年代、历史事件、文物出处这些信息容不得大模型瞎编。第二交互必须快。站在太和殿广场上游客不会耐心等一个模型思考十秒响应超过三秒基本就属于不可用。第三双手经常被占用。拍照、撑伞、看地图、牵孩子这时候语音和卡片是比键盘输入友好得多的交互方式。第四网络条件很差。国庆期间的故宫基站拥塞是必然的实时的、长连接的方案很容易翻车。第五设备要能撑住半天。早上八点半进场下午五点出来中间连续使用续航和发热都是硬指标。这五个需求放在一起就把方案空间压缩得很小了需要一个免安装的轻量入口需要一套能兜底弱网情况的前端缓存机制需要一个能按需调用不同模型、还能快速降级的云端调度层。1.2 为什么是鸿蒙元服务而不是传统App很多人第一反应是做一个App不就行了。但故宫这个场景App有几个绕不开的毛病。下载安装这一关就直接劝退大部分游客。国庆当天我从午门走到神武门沿途观察了一下大家手机里装的导游类App屈指可数更多人用的就是小程序和系统自带的地图服务。传统App开发成本高、更新周期长、还要适配各种屏幕对一个体验型产品来说太重了。鸿蒙元服务解决的是“入口”和“形态”的问题。它免安装点开即用还能把自己做成一张服务卡片放在桌面、负一屏甚至锁屏上。这意味着用户不需要“先下载、再打开”而是“想用的时候卡片就在那里”。在AI导游这种高频短时交互场景里这个体验差距是非常明显的。另外还有一层考量元服务是鸿蒙系统的原生形态能直接调用系统的语音、定位、相机和设备协同能力不需要像在普通App里一样自己做一堆桥接适配。这对开发工期和稳定性都是实打实的利好。1.3 为什么接口要接在蓝耘元生代MaaS上模型选型这件事我自己纠结了很久。最开始想过本地部署一个开源大模型但一算账就放弃了一台能跑7B模型的设备成本先不说光是维护、调优、供电就够受的。故宫这种突发流量场景高峰期的并发完全不可控自建推理服务要么平时闲着要么峰值直接被打穿成本不可接受。后来把目光转到蓝耘元生代MaaS上。它本质上是一个大模型的托管和调度平台我不用关心GPU从哪来、推理环境怎么配只需要在平台上选模型、配API Key、按调用量计费。更重要的是它支持多模型路由同一个接口可以按策略分发到不同模型——这正好是我要的“多AI协作”的基础。我最终形成的技术判断是鸿蒙负责“端”的体验MaaS负责“云”的智能。端云之间通过标准HTTP接口通信两边解耦。这样我既不用碰底层模型部署也不用被困在某个单一模型的能力边界里。2. 系统架构与分工逻辑2.1 鸿蒙侧元服务卡片与系统能力鸿蒙这侧的架构我拆成了三层。最上面是入口层。用的是元服务的服务卡片用户添加到桌面后卡片上直接展示当前位置的推荐路线和下一个讲解点。不用打开App扫一眼卡片就知道往哪走这是传统App做不到的。中间是交互层。语音是主交互方式调用系统的语音识别能力完成输入再用系统TTS把模型返回的文本转成语音。拍照识别用的是相机能力加多模态模型拍一张太和殿的照片模型返回介绍内容。所有这些系统能力在鸿蒙里通过Ability和Service Kit就能调起来不需要额外引入重型SDK。最下面是本地缓存层。故宫的开放讲解数据、常用问答对、路线点位都提前打包进了本地资源。弱网或者断网的时候优先走缓存不走云端。实测下来这个设计救了很多次场后面详细说。2.2 蓝耘元生代MaaS侧模型路由与Agent调度蓝耘元生代MaaS这一侧我把它当成一个“模型调度中枢”。它提供了一组API我传给它的内容不光是“用户问什么”还包括“这次任务的类型”。它内部有路由策略把不同类型的请求分发到最合适的模型上简单的文物描述给响应快的轻量模型复杂的路线规划给推理能力强的对话模型视觉识别走多模态模型路径。这比我自己在代码里维护一串模型列表要省心得多。我实际用到的核心能力有三个。第一个是多模型调用统一接口不同模型的参数格式有差异但MaaS做了封装我传统一的JSON结构就行。第二个是Agent能力可以定义一些工具让模型在回答过程中调用这些工具比如查天气、查开放时间、调知识库检索。第三个是可观测性每次调用的模型、延迟、Token消耗都有日志方便我事后复盘调优。2.3 一次完整请求的调用链路把整个链路走一遍会更清楚。用户在卡片上点“开始导游”说了一句“我现在在太和殿给我讲讲这里”。语音先进鸿蒙侧的语音识别服务转成文本“我现在在太和殿给我讲讲这里”。文本通过HTTP请求打到蓝耘元生代MaaS的Agent接口。Agent判断这个请求需要两步先定位用户方位然后检索太和殿的讲解资料。定位信息从鸿蒙侧随请求带上Agent据此确定目标点位再从知识库里检索内容最后组织成一段口语化讲解文本返回。鸿蒙侧收到文本后TTS转语音播放同时卡片上更新文字和下一站建议。这整个链路看着简单但有一个非常关键的细节每一步都可能失败所以每层都设计了降级路径。语音识别失败了就直接让用户打字模型调用超时了就走本地缓存回答缓存也没有就给出一个兜底提示引导用户到下一个网络好的区域再试。这套降级策略在国庆当天真的是救命用的。2.4 端云协同为什么是靠谱的组合纯端侧实现AI导游的问题在于能力天花板低本地跑不动大模型视觉识别和多轮对话质量都受限。纯云侧实现的问题在于网络敏感故宫这种场景网络波动是常态一旦链路断了整个服务就瘫了。端云协同的平衡点在于端上做体验云上做智能。轻量的、确定性的逻辑放在端上比如路线点位计算、缓存命中、基础语音交互重度的、生成式的逻辑放在云上比如视觉理解、长文本生成、多轮对话。云不可用的时候端上的缓存逻辑能保证基础体验不归零等网络恢复再无缝切回。3. 功能实现从0到1搭出AI导游3.1 核心功能盘点这个AI导游最终落地了四个核心功能。语音问答是主力。用户直接问“这个建筑是什么时候建的”“屋脊上的小兽有什么讲究”系统用知识库加生成模型作答。实景识别针对的是“我不知道眼前是什么”的场景拍照后由多模态模型描述并给出名称和历史背景。路线规划基于点位数据和用户当前位置算出最优参观顺序并生成下一站提示。随身总结会在用户逛完一个区域后自动生成一段当日游览笔记方便发朋友圈。功能不多但每一个都是故宫场景里真实会被高频使用的。3.2 搭建过程演示一个最小可运行版本我在这里把最小版本的关键步骤列出来方便想复现的人快速上手。第一步注册蓝耘元生代MaaS账号创建一个应用拿到API Key和应用ID。第二步在平台里配置模型路由规则比如text-davinci类任务走对话模型vision类任务走多模态模型。第三步创建鸿蒙元服务项目在module.json5里声明服务卡片Ability并配置系统语音权限。第四步写核心调用逻辑骨架大致是这样的// 鸿蒙侧请求蓝耘元生代MaaS Agent接口 import http from ohos.net.http; import abilityAccessCtrl from ohos.abilityAccessCtrl; async function requestAIAgent(query: string, location: string) { let httpRequest http.createHttp(); let response await httpRequest.request( https://api.example-maas.com/v1/agent/chat, { method: http.RequestMethod.POST, header: { Content-Type: application/json, Authorization: Bearer YOUR_MAAS_API_KEY }, extraData: JSON.stringify({ agent_id: gugong_guide_v1, user_query: query, context: { location: location, timestamp: Date.now() } }) } ); let result JSON.parse(response.result as string); return result.answer; }第五步把模型返回的结构化JSON渲染到卡片上包括标题、正文、下一个推荐点位和一张缩略图。第六步配置端云缓存策略将故宫讲解资料预置于resources/rawfile目录查询时先查端侧索引命中就直接返回未命中才走云端。这套最小版本从开始写到能在模拟器跑通大约花了一个周末。如果只想验证交互逻辑连路线规划都可以先不做把讲解问答做到能用体验就已经能打了。3.3 提示词工程决定导游“像不像”同样的模型提示词写得像说明书还是像导游输出差别巨大。我最终用的系统提示词大致是这个结构你是一位资深故宫讲解员。你在回答时有几个原则 1. 所有关于建筑年代、历史人物、文物材质的信息必须依据提供的知识库内容不得凭空推测。 2. 回答控制在150字以内口语化像在现场和朋友聊天不要用书面语。 3. 如果用户问题超出故宫范围明确告知“这个问题超出我的讲解范围”不要硬答。 4. 每次回答结尾给出一个具体的、可执行的下一步参观建议。 5. 对不确定的信息明说“这部分没有可靠的史料记载”不用猜测填充。这套提示词的核心思路其实是“约束”而不是“引导”。给模型划出行为边界比告诉它“要专业”“要详细”有用得多。Temperature参数我调到了0.3太低会显得死板太高容易跑偏0.3在稳定性和自然度之间比较平衡。3.4 知识库与多模型协作方案纯靠大模型自己的知识做导游错误率是没法接受的。模型会非常自信地说出错误年代而且语气毫无破绽。应对方案是RAG把权威资料整理成结构化的知识库在模型回答前先检索把检索结果和用户问题一起交给模型。我把故宫开放数据、官方讲解词、公开史料整理成大约两千条记录每条记录包含地点名称、别名、建筑年代、历史沿革、关键事件、相关文物。检索用embedding匹配加关键词加权的方式保证在语义和精确两个方面都能命中。多模型协作的核心逻辑是“按任务分配按结果兜底”。语音问答走对话模型视觉识别走多模态模型简单查询直接命中知识库不走生成模型节省成本也降低延迟。当一个模型调用失败或返回格式异常时自动切换到备用模型重试一次如果还不行就走缓存降级。4. 国庆现场实测问题比预期多得多4.1 实测的基本情况国庆当天早上八点半入场晚上五点离场全程大约八个半小时。设备是一台支持鸿蒙的旗舰机开启了元服务卡片、蓝牙耳机、蜂窝网络和GPS。当天的网络状况比我预想的更差太和殿广场附近基站负载极高部分时段请求超时率超过四成。人流方面中轴线区域基本是摩肩接踵的状态手机信号被大量人体遮挡也是个现实问题。4.2 踩过的七个坑和对应解法第一个坑是定位漂移。GPS在宫墙之间的巷道里基本失效偏差经常在几十米以上路线规划自然就乱了。后来改为“点位锚定”逻辑以故宫官方推荐的几十个核心点位为锚用户靠近某个范围就触发该点位的讲解而不是依赖连续定位。第二个坑是语音识别被环境噪音干扰。故宫里有广播、有导游喇叭、有大量人声手机麦克风收音质量不稳定。解决方案是优先使用蓝牙耳机收音同时在端上做了一个简单的VAD检测检测到声音停顿才触发请求减少误唤醒。第三个坑是大模型幻觉。模型在回答某个建筑高度时给出了一个与知识库冲突的数字。查了下日志发现是模型在没有命中知识库的情况下自己“发挥”了。解决办法是把未命中的处理逻辑改成明确拒绝并返回“我暂时找不到可靠资料”的兜底话术而不是让模型编造。第四个坑是API超时。高峰期请求排队严重有些请求在十秒以上才返回。我在端上做了三重处理设置三秒超时上限超时后立即查询本地缓存缓存未命中就把请求列入重试队列等网络空闲再批量发送。第五个坑是发热与续航。连续使用大约四十分钟后手机背部明显发热电量消耗速度超出预期。排查下来主要是相机、语音和网络的连续高负载。后面把拍照分辨率降到720P、减少不必要的定位刷新频率、降低TTS采样率发热好了一些。第六个坑是卡片信息过载。最早设计卡片时把讲解全文、下一站、距离、预计耗时全部都放上去了结果在锁屏和口袋场景下根本没法看。后来砍成三层第一层只显示地点名和一句话简介第二层是完整讲解第三层是操作按钮。卡片在大部分情况下只需要展示第一层。第七个坑是多轮对话的上下文丢失。用户问完“这狮子是公的还是母的”之后接着问“那它呢”模型并没有理解这个“它”指的是什么。原因是上下文窗口管理得太粗暴。后来改成了显式携带最近两轮的用户问题并让模型在回答中复述一下理解的对象避免指代混乱。4.3 现场临时优化记录下午一点左右中轴线的网络基本处于不可用状态。我现场做了一次策略切换把“全程语音导游”改成“关键点位语音加普通点位文字卡片”的混合模式。到了网络好的区域再自动切回语音。这个调整看似简单但把用户体验从“频繁卡顿”拉回到了“基本可用”的水平。另一个现场调整是把路线规划从“按全局最优路径”改成“按当前点位就近推荐”。在人流巨大的时候全局最优路径往往会被拥堵路段打断规划器的收益趋近于零。就近推荐虽然每一步不是最优的但整体体验反而更顺。5. 我的真实体会跑完这一整趟几个感受特别深。第一MaaS平台比自己部署模型省心太多。我不需要考虑GPU规格、推理优化、弹性扩容平台把这些都封装好了我把精力全部放在业务逻辑和体验打磨上。第二鸿蒙元服务的入口形态确实适合这类轻应用。免安装加卡片把使用门槛降到了最低。游客在故宫里不会去装一个App但一定会用到卡片引导。第三提示词和知识库的设计比模型选型更能决定体验上限。一次回答的优劣80%取决于给模型喂的信息和边界20%才是模型本身的推理能力。第四真实场景才是最好的测试环境。在模拟器上跑得再顺到了现场也会遇到意想不到的问题。定位、网络、噪音、发热这些问题在文档里永远学不到。最后分享一个小技巧在卡片上除了“讲解”按钮一定要放一个“重新识别”按钮。故宫里很多点位长得有点像用户拍错地方的情况非常常见。这个按钮能在三十秒内完成纠错体验提升立竿见影。这套鸿蒙元服务加MaaS的组合后续还能扩展很多东西接入更多景区数据源、加入离线语音包、把游览笔记生成做成朋友圈分享模板。如果你也在做AI加旅游的方向希望这篇记录能帮你少踩几个坑。