国庆第三天我在故宫午门广场被人群挤得怀疑人生。旁边一位大哥举着手机屏幕怼着太和殿的脊兽嘴里反复念叨“这排小兽到底哪个是仙人、哪个是骑凤仙人”。那一刻我突然意识到与其租一台像砖头一样的官方讲解器、排队等人工导游不如利用手头能调动的技术给自己现场搭一个真正顺手的“AI导游”试试水。于是就有了这篇全记录在鸿蒙HarmonyOS上用元服务做客户端后端接蓝耘元生代MaaS平台的模型能力实现一个在故宫里边走边问、拍照即识的AI应用。整个过程有惊喜也有翻车我把从设计、开发、真机调试到现场排障的完整链路都写在这里希望对想在鸿蒙上做AI应用、或者对MaaS模式感兴趣的朋友有些参考价值。1. 故宫现场的真实痛点为什么传统讲解器和人工导游都不够用1.1 人多、环境吵传统讲解器体验打对折故宫国庆期间日均客流动辄数万人太和殿、中和殿这些核心殿宇前基本是人挨人、人挤人。我租过故宫官方的自动讲解器操作逻辑是“走到某个点机器自动感应开始讲”。想法很好但现场实际情况完全不是那么回事机器感应经常延迟人已经走到下一个殿了耳机里还在讲上一个殿的内容人多的时候信号互相干扰你根本分不清耳机里那点声音是自己的讲解器还是旁边大叔外放的小视频。租借要排队、押金要排队、归还还要再排队一天下来光是和讲解器打交道就花掉了将近四十分钟。人工导游当然更灵活但国庆高峰期价格不便宜而且非常难约。更关键的是跟着导游走其实是一种被动接收——导游讲什么你听什么你想问一个冷门问题往往没有时间得到解答一队人浩浩荡荡往前走你根本来不及在一个感兴趣的细节前多停留三秒钟。对于我这种喜欢在一个檐角下站五分钟反复琢磨的人来说传统导游模式确实不够用。1.2 故宫场景的特殊约束文物安全、内容严谨、信号复杂故宫不是普通公园它对技术方案有一堆隐性的硬约束。第一文物不能触摸很多建筑细节你只能在栏杆外面眯着眼睛看这时候需要借助技术去“放大”那些肉眼容易忽略的细节比如屋脊兽的排列顺序、斗拱的结构层次、彩画里隐藏的纹样。第二开放区域里信号环境并不理想人一多基站负载高4G/5G的实际体验会明显下降再加上故宫里高大的墙体、厚重的殿宇对信号也有遮挡效应你不能假设用户随时都有畅通的网络。第三内容讲究严谨性——故宫相关的历史知识游客问错了没关系AI如果答错了就是误导这种场景对生成内容有很现实的可信度要求模型给出的每一个年代、每一个事件背景都必须能经得起推敲。第四使用场景是碎片化的游客不会坐在一个点前听十分钟通常是在一个位置站三十秒、拍个照、又赶往下一个点所以AI导游的交互也必须轻快、短促、即问即答。1.3 我的诉求清单一个AI导游到底该干哪些活基于上面这些约束我给这个“AI导游”列了一份非常明确的需求清单免安装我不想在景点门口为了一个半天的用途下载一个上百兆的App占用存储、还要注册登录。拍照识别对准建筑、牌匾、文物拍一张能直接告诉我这是什么、它有什么故事。语音交互解放双手一边看文物一边听讲解最好能支持连续追问。内容可控生成的历史讲解必须经过审核或来源约束不能一本正经地瞎编。离线兜底信号差的时候至少要有缓存内容兜底而不是直接转圈圈卡死。轻量触达最好能从桌面卡片或扫码直接拉起入口用完即走不留下任何负担。这些诉求其实已经直接指向了一个技术组合鸿蒙元服务做客户端外壳蓝耘元生代MaaS做云端大脑。下面说说为什么这么选。2. 技术选型推演为什么是“蓝耘元生代MaaS 鸿蒙元服务”而不是纯App2.1 端侧AI和云侧大模型的分工逻辑在鸿蒙端跑AI有两种极端思路。一种是纯端侧小模型比如在设备上做简单的图像分类、OCR好处是不依赖网络、响应快、隐私好缺点也很明显——端侧模型的语义理解能力有限你让它回答“为什么故宫的屋顶要做成这种弧度而不是像西方建筑那样平直”它基本给不出让人满意的答案它只能识别“这是个屋顶”“这是红色”。另一种是云侧大模型理解能力强、知识丰富对开放性问题回答得漂亮但依赖网络而且把所有逻辑全塞给云端会有延迟成本和费用问题每次拍照都上传原图、每次问答都带完整历史很快就把请求体积和费用撑爆了。我的方案是取两者之长端上做轻量的预识别比如先判断“这大概是建筑、文物还是牌匾”把照片做裁剪、压缩和降噪预处理云端MaaS负责真正“烧脑”的部分——识别具体物件、生成讲解文本、根据上下文回答追问。这样既保证了核心问答质量又把不必要的云调用砍掉了一截也降低了网络传输压力。2.2 鸿蒙元服务免安装、即点即用刚好命中景点场景景点这种“用完即走”的场景天然适合鸿蒙元服务。元服务是HarmonyOS提供的一种轻量级应用形态用户点击服务卡片、扫描二维码或通过系统推荐即可拉起使用不需要走完整的下载安装流程。对我来说朋友在故宫门口发我一个元服务链接我点开就能用AI导游用完划走就行完全不占手机空间。鸿蒙元服务还支持服务卡片和意图框架可以把“入口”直接推到桌面负一屏或智能推荐卡片上。对游客来说门槛比下载App低太多——不需要搜索、不需要下载、不需要注册扫一个码或者点一张卡片AI导游就出现了。从开发角度讲元服务基于ArkTS语言和ArkUI框架和完整的HarmonyOS应用开发体系一脉相承熟悉鸿蒙开发的开发者上手成本并不高。2.3 蓝耘元生代MaaS模型按需调用省掉自建部署的坑蓝耘元生代MaaS是模型即服务平台通俗说就是你不自己部署大模型而是通过API按量调用别人已经跑起来的模型能力。对这个项目来说非常关键我不可能在国庆前专门租几台GPU服务器部署一个开源模型算力成本、运维成本、容器编排、弹性伸缩哪一样都够我喝一壶。直接用MaaS API注册、开通服务、拿到密钥几十分钟就能把模型能力接进应用。而且MaaS平台通常不只提供一个模型而是给你一个模型池——文本对话、多模态识图、语音合成这些能力可以在同一个平台下统一管理和计费。对个人开发者来说省去了对接多家服务商、维护多套鉴权体系的麻烦一个SDK或一套RESTful接口就能打通主要能力。蓝耘元生代这种形态本质上就是把“大模型能力”做成了像水电一样按需取用的公共服务我只需要关注应用层逻辑。2.4 多AI协作规划、识别、讲解、审核各司其职这个项目的实现里我刻意没有做“一个大模型干所有事”的架构而是拆成了几个AI Agent角色各自负责一个边界清晰的任务规划Agent根据当前位置、时间、游客兴趣爱好生成参观路线和推荐下一个景点。识别Agent多模态模型对拍照内容做识别输出建筑或文物的名称、标签和置信度。讲解Agent根据识别结果生成有趣、有深度的讲解文本负责“说人话”。审核Agent对讲解文本做一次事实性和合规性检查拦截明显不合适的表述。这种多AI协作的好处是每个Agent的任务边界清晰可以分别做优化、替换和灰度测试。比如识别Agent用多模态模型讲解Agent用对话模型互不干扰审核Agent甚至可以随时换成更严格的内容安全模型。坏处也明显——链路变长任何一个环节出问题都会影响整体体验。这个问题我在后面讲现场翻车时会细说因为国庆当天它实实在在地发生在了我面前。3. 实战落地从DevEco Studio到真机运行的完整链路3.1 工程创建与元服务配置开发环境我用的是DevEco Studio华为官方IDE。新建工程时选择“Empty Ability元服务”模板语言选ArkTS兼容版本按我当时手上的真机选HarmonyOS 5.x。这里有个需要注意的细节元服务的工程结构和普通应用不完全一样它的入口不一定是UIAbility而是可能以服务卡片、快捷方式等作为触发入口。我在工程里建了一个Entry模块用来承载主要交互页面然后额外创建了一个服务卡片模块做桌面级的“AI导游”入口。工程配置里还要单独声明元服务的图标、标签和路由信息否则上架测试时会被审核拦下来。几个关键配置项供参考bundleName建议用反域名方式命名便于区分不同元服务。abilityName入口Ability名称服务卡片跳转时要用到。metadata在module.json5里声明MaaS平台的密钥索引、网络权限用途等。我当时在这一步踩了个小坑元服务对merge配置有要求如果同时存在多个卡片模块路由表的配置必须显式声明所有可用页面否则真机点击卡片时会提示“找不到页面”。3.2 权限申请与隐私合规AI导游需要定位、相机、麦克风三样权限。HarmonyOS的权限模型是“按需申请、动态弹窗”元服务对权限审核更严格不能像普通App那样一股脑全要到。我在代码里做了三层处理只在实际使用时申请用户真正准备拍照或说话时才弹权限请求不做启动时一口气全要减少首屏阻力。说明文案写清楚每种权限都配上明确的用途说明同时在元服务内提供完整的隐私政策弹窗说明“图片仅用于识别、语音仅用于转写、定位仅用于推荐附近景点”。最小化授权定位权限使用“模糊定位”即可满足场景需求——我需要知道的是“你在哪个殿附近”而不是“你在哪个经纬度”。权限越小审核越容易过对用户也越友好。这点在开发鸿蒙元服务时特别重要因为元服务的目标是轻量触达如果一打开就要五个权限用户大概率会直接划走。3.3 接入MaaS接口拍照识别语音问答的代码骨架代码结构大致分六步拍照或从相册选择图片读取为PixelMap对象。端上预处理压缩图片到640x480以内裁剪主体计算主色调用于场景初判。调MaaS多模态识别接口上传图片并携带提示词“请识别故宫中的建筑或文物给出名称和简要背景”。拿回结构化结果名称、标签、置信度。调MaaS文本对话接口把识别结果和用户的追问一起发给讲解Agent。返回讲解文本嵌入小型审核调用确认通过后交给ArkUI渲染并播报。ArkTS示例代码示意import { image } from kit.ImageKit; import { http } from kit.NetworkKit; async function identifyAndExplain(imageUri: string, question: string): Promisestring { // 1. 解码图片并压缩 let source image.createImageSource(imageUri); let pixelMap await source.createPixelMap({ desiredSize: { width: 640, height: 480 } }); // 2. 调用MaaS识别接口示意请求头 let recognizeResp await http.createHttp().request( https://api.example-maas.com/v1/multimodal/recognize, { method: http.RequestMethod.POST, header: { Authorization: Bearer YOUR_MAAS_API_KEY, Content-Type: application/json }, extraData: { imageBase64: await pixelMapToBase64(pixelMap), prompt: 请识别故宫中的建筑或文物输出名称和简要背景 } } ); let recognizeResult JSON.parse(recognizeResp.result as string); let objectName recognizeResult.data.name; // 3. 调用MaaS文本对话接口组装讲解请求 let chatResp await http.createHttp().request( https://api.example-maas.com/v1/chat/completions, { method: http.RequestMethod.POST, header: { Authorization: Bearer YOUR_MAAS_API_KEY, Content-Type: application/json }, extraData: { model: maas-turbo-chat, messages: [ { role: system, content: 你是故宫AI导游回答要准确、通俗、有趣。 }, { role: user, content: 识别到${objectName}。游客追问${question}请给出讲解。 } ] } } ); let chatData JSON.parse(chatResp.result as string); return chatData.choices[0].message.content; }生产环境里还需要做超时控制、重试、鉴权信息加密存储等处理这段代码只是演示主流程。有一点提醒不要把MaaS的API密钥直接硬编码在元服务代码里我测试阶段为了方便明文写在了配置里后来真机调试被安全扫描工具提醒才改成了动态获取并加密存储。3.4 服务卡片与语音播报把AI导游“放”到桌面上鸿蒙的服务卡片能在桌面上直接展示信息这是元服务区别于普通App的典型体验。我给AI导游做了两种卡片路线卡片显示当前所在区域和推荐下一个景点点击直接跳转导航页。今日一问每天推一个故宫冷知识点开直接进入问答页。语音播报我用了双通道鸿蒙自带的文本转语音能力作为默认通道MaaS云端语音合成作为备选。实测下来端侧TTS延迟低、但音色偏机械云端合成效果好、但多一次网络往返。考虑到故宫现场信号不稳我默认用端侧TTS只有用户主动选择“沉浸讲解”模式时才走云端高音色合成。在钟表馆、珍宝馆这种安静室内展厅云端音色的“讲解感”确实好很多能明显感觉到语气停顿和重音分布更像真人。3.5 真机调试从模拟器到实物的跨越模拟器上跑得好好的一到真机就露馅这是AI应用最常见的坑。我遇到几个典型问题模拟器默认网络状态太好MaaS接口500毫秒返回真机上因为基站负载2秒甚至3秒才返回整个交互节奏立刻变得拖沓。相机权限在模拟器上可以随便给真机上有明显的授权弹窗流程用户在景点门口手忙脚乱的时候根本不想点“允许”。模拟器的图片处理管线更快真机上图片压缩、Base64编码这些操作会占用明显的时间拍照后立刻识别时甚至出现等待动画卡顿。我的建议是这种强依赖真实环境的AI应用从第一天起就要真机调试别在模拟器上自我感觉良好。我还专门把测试手机挂了一个低带宽限制模式来模拟拥堵环境比模拟器的网络模拟真实得多。开发过程中我基本保持“一小时真机一测”的节奏很多体验问题就这样被提前暴露了。4. 国庆故宫现场翻车实录问题定位与修复思路4.1 现象一太和殿门口模型响应超时国庆当天上午十点太和殿广场人流量达到峰值。我拍了一张太和殿的照片等了大概4秒转圈圈再等4秒直接超时。这个现象在御花园、养心殿附近也出现了而且越是热门景点越严重。定位原因分两层第一层是网络现场基站拥塞图片上传耗时比平时多了近一倍第二层是MaaS服务端推理队列排队多模态模型本身计算量大高峰期请求集中在同一时段排队时间明显拉长。修复办法从三个方向入手端上压缩彻底一点图片统一压到640x480体积控制在300KB以内大幅减少上传耗时。额外增强弱网模式在故宫里默认开启“弱网模式”把超时时间从5秒放宽到10秒同时增加“转圈圈文案”让游客知道系统还在尽力处理。引入语义缓存同一座太和殿不同游客拍的其实差不多第一次识别成功后后面30分钟内相同建筑的请求直接命中本地缓存不再重复调用云端识别接口。实测下来缓存命中率高得惊人——太和殿、乾清宫这种热门点的识别结果缓存可以覆盖六成以上的重复请求。这个方案在人多时几乎是救命的。4.2 现象二人声嘈杂语音识别率骤降在钟表馆里我想语音问“这件展品是哪国的”结果旁边一个小孩尖叫了一声我的语音被识别成完全不相干的一句话。纯端侧语音识别在这种环境里根本扛不住。我的解决思路是双通道校验先端侧语音转文字再把文字交给MaaS做一次“意图澄清”如果置信度低于阈值不直接执行而是回问一句“你问的是这件展品的来源对吗”。虽然多一步对话但避免了答非所问带来的更大挫败感。毕竟在景点现场游客问一遍没得到答案通常就不会再问第二遍了。4.3 现象三拍照识别张冠李戴在慈宁宫附近我对着一个琉璃影壁拍照识别Agent返回的是“故宫宫墙”。原因是那个位置宫墙和琉璃影壁颜色接近、构图相似多模态模型对小样本的琉璃构件识别精度确实不够。我做了两个处理第一增加提示词约束明确告诉模型“如果在故宫内识别到琉璃装饰优先判断是否为影壁、照壁类建筑构件的组成部分”把领域知识写进提示模型的表现立刻改善第二引入“用户纠偏”机制——识别结果页面提供一个可编辑框如果识别错了用户可以直接打字纠正。纠正后的数据会进入本地样本库同区域后续识别会优先参考。这个机制实测下来很有用多位朋友试用后都主动纠正过样本积累越多同区域识别越准。4.4 现象四讲解内容太“一本正经”游客根本听不进去第一次现场测试讲解模型给的回答是标准的百科式语言“太和殿是明清两代皇帝举行大典的地方面阔十一间进深五间建筑面积2377平方米……”不能说不对但人在景点现场真的听不进去。站在太和殿前面谁想听建筑面积数据后来我在提示词里加了一条“像朋友聊天一样介绍先讲一个有趣的故事或细节再补充理性背景。”同样一个太和殿改成“你抬头看屋脊上那排小兽第十个叫行什全故宫只有太和殿能放满十个。传说它是雷公的化身放在屋顶是为了镇殿避雷。你数一数别的殿最多九个只有太和殿敢放满。”这个改动效果立竿见影现场当时就好几个人抬头去数屋脊上的小兽。讲解内容生成不能只喂“事实参数”还得喂“叙事方式”这是AI导游体验的重要分水岭。4.5 排查方法论先分层再归因回头看所有翻车都遵循同一个排查链路先判断是端上问题还是云上问题用抓包工具看请求耗时分布等待响应的时间占总耗时大头问题多在云侧或网络端上处理占大头问题多在端侧代码。再判断是网络问题还是模型问题网络问题表现为整体变慢、连接超时模型问题表现为返回快但结果不对。最后判断是逻辑问题还是数据问题提示词写错、上下文传错是逻辑问题样本库不足、识别边界模糊是数据问题。另外提醒一点不要把“模型生成内容有误”归因于“参数没调好”就草草收场。把提示词设计、置信度阈值、缓存策略、用户纠偏当成一个整体来优化效果会好很多。我这次最深的感觉是AI应用现场翻车不是模型“笨”而是集成方式没匹配上真实场景的约束。5. 整体反思AI导游的价值边界与鸿蒙MaaS的组合拳5.1 实测数据与体验评分国庆当天实测从午门到神武门走完全程大约4小时我的AI导游完成了约80次问答交互其中拍照识别约35次语音问约45次。我记录的几组关键数据指标实测结果人流密集区响应时间平均3秒以上正常区域响应时间平均1.5秒左右建筑大类识别准确率约90%构件级识别准确率约70%需要用户纠偏次数约10次内容被二次追问的比例约40%总体体验打7分。扣分点主要在弱网场景下的卡顿以及部分构件识别不够精准。但“想用就拉起来用完就划走”的元服务体验和“问不倒”的AI讲解能力确实是传统讲解器完全给不到的。5.2 AI导游不是替代真人而是补充信息密度这次实测让我深刻体会到一个朴素的道理AI导游最大的价值不是替代导游而是把“信息密度”提上来。真人导游受限于体力、时间和路线只能挑重点讲AI导游可以做到每个物件都能问、每条问题都有回应哪怕是“这个屋顶为什么是斜的”“宫女的画像为什么都长一个样”这种跳脱问题它也能接住。但AI导游也有明显短板缺乏对游客状态的感知。真人导游能看出你累了、眼神飘了、对哪个方向好奇AI做不到。你站在太和殿前累得直喘AI还在那滔滔不绝讲斗拱结构这种体验就很出戏。所以我的结论是AI导游在景区更像一个“问不倒的百科全书加即时讲解器”更适合自由行和深度爱好者不适合需要被安排得明明白白的跟团游客。5.3 对鸿蒙元服务MaaS模式的后续想法这个组合几乎就是为“高频触点、轻量使用”的AI应用量身定做的元服务解决触达和分发问题MaaS解决模型能力和成本问题。对个人开发者来说不用自己买显卡、不用管运维、不用承担复杂的大模型部署工程就能把一个相对完整的AI应用跑在真实的系统生态里这个门槛确实被拉得很低。鸿蒙的分布式能力和元服务卡片体系让AI服务能以很低打扰度的方式出现在用户眼前这一点是传统“下载App”模式做不到的。后续如果继续做这个项目我考虑三个方向一是加入用户画像让讲解风格和内容深度能自适应不同人群——小朋友和历史爱好者需要的完全是两种语言。二是做离线增量模型把高频识别场景的样本在端上持续微调逐步减少对云端的依赖。三是把审核Agent做得更细建立针对景区语境的专业词表避免AI在文物命名、年代判定上出现低级的“一本正经胡说八道”这件事对文化场景尤其重要。最后说点实在话。这次“国庆故宫AI导游”与其说是一个能上架的产品不如说是一次技术可行性的充分验证鸿蒙元服务加蓝耘元生代MaaS确实能把AI应用做到“想用就拉起来用完就划走”的程度。但我也不回避现场那几次识别错误和超时卡顿让我意识到AI应用在真实公共场景里离“丝滑”还有距离。如果你也想做类似的东西我的建议是先想清楚场景约束——信号、噪音、用户耐心——再做技术选型先真机测试再追求体验优化。别被“大模型无所不能”的说法冲昏头落地的细节才决定你做出来的AI导游是被人夸好用还是被人当场划走。 
长河君 · 2026/10/25 21:49:48 · 阅读 1.2k 鸿蒙元服务+蓝耘MaaS：故宫AI导游开发实战全记录
国庆第三天我在故宫午门广场被人群挤得怀疑人生。旁边一位大哥举着手机屏幕怼着太和殿的脊兽嘴里反复念叨“这排小兽到底哪个是仙人、哪个是骑凤仙人”。那一刻我突然意识到与其租一台像砖头一样的官方讲解器、排队等人工导游不如利用手头能调动的技术给自己现场搭一个真正顺手的“AI导游”试试水。于是就有了这篇全记录在鸿蒙HarmonyOS上用元服务做客户端后端接蓝耘元生代MaaS平台的模型能力实现一个在故宫里边走边问、拍照即识的AI应用。整个过程有惊喜也有翻车我把从设计、开发、真机调试到现场排障的完整链路都写在这里希望对想在鸿蒙上做AI应用、或者对MaaS模式感兴趣的朋友有些参考价值。1. 故宫现场的真实痛点为什么传统讲解器和人工导游都不够用1.1 人多、环境吵传统讲解器体验打对折故宫国庆期间日均客流动辄数万人太和殿、中和殿这些核心殿宇前基本是人挨人、人挤人。我租过故宫官方的自动讲解器操作逻辑是“走到某个点机器自动感应开始讲”。想法很好但现场实际情况完全不是那么回事机器感应经常延迟人已经走到下一个殿了耳机里还在讲上一个殿的内容人多的时候信号互相干扰你根本分不清耳机里那点声音是自己的讲解器还是旁边大叔外放的小视频。租借要排队、押金要排队、归还还要再排队一天下来光是和讲解器打交道就花掉了将近四十分钟。人工导游当然更灵活但国庆高峰期价格不便宜而且非常难约。更关键的是跟着导游走其实是一种被动接收——导游讲什么你听什么你想问一个冷门问题往往没有时间得到解答一队人浩浩荡荡往前走你根本来不及在一个感兴趣的细节前多停留三秒钟。对于我这种喜欢在一个檐角下站五分钟反复琢磨的人来说传统导游模式确实不够用。1.2 故宫场景的特殊约束文物安全、内容严谨、信号复杂故宫不是普通公园它对技术方案有一堆隐性的硬约束。第一文物不能触摸很多建筑细节你只能在栏杆外面眯着眼睛看这时候需要借助技术去“放大”那些肉眼容易忽略的细节比如屋脊兽的排列顺序、斗拱的结构层次、彩画里隐藏的纹样。第二开放区域里信号环境并不理想人一多基站负载高4G/5G的实际体验会明显下降再加上故宫里高大的墙体、厚重的殿宇对信号也有遮挡效应你不能假设用户随时都有畅通的网络。第三内容讲究严谨性——故宫相关的历史知识游客问错了没关系AI如果答错了就是误导这种场景对生成内容有很现实的可信度要求模型给出的每一个年代、每一个事件背景都必须能经得起推敲。第四使用场景是碎片化的游客不会坐在一个点前听十分钟通常是在一个位置站三十秒、拍个照、又赶往下一个点所以AI导游的交互也必须轻快、短促、即问即答。1.3 我的诉求清单一个AI导游到底该干哪些活基于上面这些约束我给这个“AI导游”列了一份非常明确的需求清单免安装我不想在景点门口为了一个半天的用途下载一个上百兆的App占用存储、还要注册登录。拍照识别对准建筑、牌匾、文物拍一张能直接告诉我这是什么、它有什么故事。语音交互解放双手一边看文物一边听讲解最好能支持连续追问。内容可控生成的历史讲解必须经过审核或来源约束不能一本正经地瞎编。离线兜底信号差的时候至少要有缓存内容兜底而不是直接转圈圈卡死。轻量触达最好能从桌面卡片或扫码直接拉起入口用完即走不留下任何负担。这些诉求其实已经直接指向了一个技术组合鸿蒙元服务做客户端外壳蓝耘元生代MaaS做云端大脑。下面说说为什么这么选。2. 技术选型推演为什么是“蓝耘元生代MaaS 鸿蒙元服务”而不是纯App2.1 端侧AI和云侧大模型的分工逻辑在鸿蒙端跑AI有两种极端思路。一种是纯端侧小模型比如在设备上做简单的图像分类、OCR好处是不依赖网络、响应快、隐私好缺点也很明显——端侧模型的语义理解能力有限你让它回答“为什么故宫的屋顶要做成这种弧度而不是像西方建筑那样平直”它基本给不出让人满意的答案它只能识别“这是个屋顶”“这是红色”。另一种是云侧大模型理解能力强、知识丰富对开放性问题回答得漂亮但依赖网络而且把所有逻辑全塞给云端会有延迟成本和费用问题每次拍照都上传原图、每次问答都带完整历史很快就把请求体积和费用撑爆了。我的方案是取两者之长端上做轻量的预识别比如先判断“这大概是建筑、文物还是牌匾”把照片做裁剪、压缩和降噪预处理云端MaaS负责真正“烧脑”的部分——识别具体物件、生成讲解文本、根据上下文回答追问。这样既保证了核心问答质量又把不必要的云调用砍掉了一截也降低了网络传输压力。2.2 鸿蒙元服务免安装、即点即用刚好命中景点场景景点这种“用完即走”的场景天然适合鸿蒙元服务。元服务是HarmonyOS提供的一种轻量级应用形态用户点击服务卡片、扫描二维码或通过系统推荐即可拉起使用不需要走完整的下载安装流程。对我来说朋友在故宫门口发我一个元服务链接我点开就能用AI导游用完划走就行完全不占手机空间。鸿蒙元服务还支持服务卡片和意图框架可以把“入口”直接推到桌面负一屏或智能推荐卡片上。对游客来说门槛比下载App低太多——不需要搜索、不需要下载、不需要注册扫一个码或者点一张卡片AI导游就出现了。从开发角度讲元服务基于ArkTS语言和ArkUI框架和完整的HarmonyOS应用开发体系一脉相承熟悉鸿蒙开发的开发者上手成本并不高。2.3 蓝耘元生代MaaS模型按需调用省掉自建部署的坑蓝耘元生代MaaS是模型即服务平台通俗说就是你不自己部署大模型而是通过API按量调用别人已经跑起来的模型能力。对这个项目来说非常关键我不可能在国庆前专门租几台GPU服务器部署一个开源模型算力成本、运维成本、容器编排、弹性伸缩哪一样都够我喝一壶。直接用MaaS API注册、开通服务、拿到密钥几十分钟就能把模型能力接进应用。而且MaaS平台通常不只提供一个模型而是给你一个模型池——文本对话、多模态识图、语音合成这些能力可以在同一个平台下统一管理和计费。对个人开发者来说省去了对接多家服务商、维护多套鉴权体系的麻烦一个SDK或一套RESTful接口就能打通主要能力。蓝耘元生代这种形态本质上就是把“大模型能力”做成了像水电一样按需取用的公共服务我只需要关注应用层逻辑。2.4 多AI协作规划、识别、讲解、审核各司其职这个项目的实现里我刻意没有做“一个大模型干所有事”的架构而是拆成了几个AI Agent角色各自负责一个边界清晰的任务规划Agent根据当前位置、时间、游客兴趣爱好生成参观路线和推荐下一个景点。识别Agent多模态模型对拍照内容做识别输出建筑或文物的名称、标签和置信度。讲解Agent根据识别结果生成有趣、有深度的讲解文本负责“说人话”。审核Agent对讲解文本做一次事实性和合规性检查拦截明显不合适的表述。这种多AI协作的好处是每个Agent的任务边界清晰可以分别做优化、替换和灰度测试。比如识别Agent用多模态模型讲解Agent用对话模型互不干扰审核Agent甚至可以随时换成更严格的内容安全模型。坏处也明显——链路变长任何一个环节出问题都会影响整体体验。这个问题我在后面讲现场翻车时会细说因为国庆当天它实实在在地发生在了我面前。3. 实战落地从DevEco Studio到真机运行的完整链路3.1 工程创建与元服务配置开发环境我用的是DevEco Studio华为官方IDE。新建工程时选择“Empty Ability元服务”模板语言选ArkTS兼容版本按我当时手上的真机选HarmonyOS 5.x。这里有个需要注意的细节元服务的工程结构和普通应用不完全一样它的入口不一定是UIAbility而是可能以服务卡片、快捷方式等作为触发入口。我在工程里建了一个Entry模块用来承载主要交互页面然后额外创建了一个服务卡片模块做桌面级的“AI导游”入口。工程配置里还要单独声明元服务的图标、标签和路由信息否则上架测试时会被审核拦下来。几个关键配置项供参考bundleName建议用反域名方式命名便于区分不同元服务。abilityName入口Ability名称服务卡片跳转时要用到。metadata在module.json5里声明MaaS平台的密钥索引、网络权限用途等。我当时在这一步踩了个小坑元服务对merge配置有要求如果同时存在多个卡片模块路由表的配置必须显式声明所有可用页面否则真机点击卡片时会提示“找不到页面”。3.2 权限申请与隐私合规AI导游需要定位、相机、麦克风三样权限。HarmonyOS的权限模型是“按需申请、动态弹窗”元服务对权限审核更严格不能像普通App那样一股脑全要到。我在代码里做了三层处理只在实际使用时申请用户真正准备拍照或说话时才弹权限请求不做启动时一口气全要减少首屏阻力。说明文案写清楚每种权限都配上明确的用途说明同时在元服务内提供完整的隐私政策弹窗说明“图片仅用于识别、语音仅用于转写、定位仅用于推荐附近景点”。最小化授权定位权限使用“模糊定位”即可满足场景需求——我需要知道的是“你在哪个殿附近”而不是“你在哪个经纬度”。权限越小审核越容易过对用户也越友好。这点在开发鸿蒙元服务时特别重要因为元服务的目标是轻量触达如果一打开就要五个权限用户大概率会直接划走。3.3 接入MaaS接口拍照识别语音问答的代码骨架代码结构大致分六步拍照或从相册选择图片读取为PixelMap对象。端上预处理压缩图片到640x480以内裁剪主体计算主色调用于场景初判。调MaaS多模态识别接口上传图片并携带提示词“请识别故宫中的建筑或文物给出名称和简要背景”。拿回结构化结果名称、标签、置信度。调MaaS文本对话接口把识别结果和用户的追问一起发给讲解Agent。返回讲解文本嵌入小型审核调用确认通过后交给ArkUI渲染并播报。ArkTS示例代码示意import { image } from kit.ImageKit; import { http } from kit.NetworkKit; async function identifyAndExplain(imageUri: string, question: string): Promisestring { // 1. 解码图片并压缩 let source image.createImageSource(imageUri); let pixelMap await source.createPixelMap({ desiredSize: { width: 640, height: 480 } }); // 2. 调用MaaS识别接口示意请求头 let recognizeResp await http.createHttp().request( https://api.example-maas.com/v1/multimodal/recognize, { method: http.RequestMethod.POST, header: { Authorization: Bearer YOUR_MAAS_API_KEY, Content-Type: application/json }, extraData: { imageBase64: await pixelMapToBase64(pixelMap), prompt: 请识别故宫中的建筑或文物输出名称和简要背景 } } ); let recognizeResult JSON.parse(recognizeResp.result as string); let objectName recognizeResult.data.name; // 3. 调用MaaS文本对话接口组装讲解请求 let chatResp await http.createHttp().request( https://api.example-maas.com/v1/chat/completions, { method: http.RequestMethod.POST, header: { Authorization: Bearer YOUR_MAAS_API_KEY, Content-Type: application/json }, extraData: { model: maas-turbo-chat, messages: [ { role: system, content: 你是故宫AI导游回答要准确、通俗、有趣。 }, { role: user, content: 识别到${objectName}。游客追问${question}请给出讲解。 } ] } } ); let chatData JSON.parse(chatResp.result as string); return chatData.choices[0].message.content; }生产环境里还需要做超时控制、重试、鉴权信息加密存储等处理这段代码只是演示主流程。有一点提醒不要把MaaS的API密钥直接硬编码在元服务代码里我测试阶段为了方便明文写在了配置里后来真机调试被安全扫描工具提醒才改成了动态获取并加密存储。3.4 服务卡片与语音播报把AI导游“放”到桌面上鸿蒙的服务卡片能在桌面上直接展示信息这是元服务区别于普通App的典型体验。我给AI导游做了两种卡片路线卡片显示当前所在区域和推荐下一个景点点击直接跳转导航页。今日一问每天推一个故宫冷知识点开直接进入问答页。语音播报我用了双通道鸿蒙自带的文本转语音能力作为默认通道MaaS云端语音合成作为备选。实测下来端侧TTS延迟低、但音色偏机械云端合成效果好、但多一次网络往返。考虑到故宫现场信号不稳我默认用端侧TTS只有用户主动选择“沉浸讲解”模式时才走云端高音色合成。在钟表馆、珍宝馆这种安静室内展厅云端音色的“讲解感”确实好很多能明显感觉到语气停顿和重音分布更像真人。3.5 真机调试从模拟器到实物的跨越模拟器上跑得好好的一到真机就露馅这是AI应用最常见的坑。我遇到几个典型问题模拟器默认网络状态太好MaaS接口500毫秒返回真机上因为基站负载2秒甚至3秒才返回整个交互节奏立刻变得拖沓。相机权限在模拟器上可以随便给真机上有明显的授权弹窗流程用户在景点门口手忙脚乱的时候根本不想点“允许”。模拟器的图片处理管线更快真机上图片压缩、Base64编码这些操作会占用明显的时间拍照后立刻识别时甚至出现等待动画卡顿。我的建议是这种强依赖真实环境的AI应用从第一天起就要真机调试别在模拟器上自我感觉良好。我还专门把测试手机挂了一个低带宽限制模式来模拟拥堵环境比模拟器的网络模拟真实得多。开发过程中我基本保持“一小时真机一测”的节奏很多体验问题就这样被提前暴露了。4. 国庆故宫现场翻车实录问题定位与修复思路4.1 现象一太和殿门口模型响应超时国庆当天上午十点太和殿广场人流量达到峰值。我拍了一张太和殿的照片等了大概4秒转圈圈再等4秒直接超时。这个现象在御花园、养心殿附近也出现了而且越是热门景点越严重。定位原因分两层第一层是网络现场基站拥塞图片上传耗时比平时多了近一倍第二层是MaaS服务端推理队列排队多模态模型本身计算量大高峰期请求集中在同一时段排队时间明显拉长。修复办法从三个方向入手端上压缩彻底一点图片统一压到640x480体积控制在300KB以内大幅减少上传耗时。额外增强弱网模式在故宫里默认开启“弱网模式”把超时时间从5秒放宽到10秒同时增加“转圈圈文案”让游客知道系统还在尽力处理。引入语义缓存同一座太和殿不同游客拍的其实差不多第一次识别成功后后面30分钟内相同建筑的请求直接命中本地缓存不再重复调用云端识别接口。实测下来缓存命中率高得惊人——太和殿、乾清宫这种热门点的识别结果缓存可以覆盖六成以上的重复请求。这个方案在人多时几乎是救命的。4.2 现象二人声嘈杂语音识别率骤降在钟表馆里我想语音问“这件展品是哪国的”结果旁边一个小孩尖叫了一声我的语音被识别成完全不相干的一句话。纯端侧语音识别在这种环境里根本扛不住。我的解决思路是双通道校验先端侧语音转文字再把文字交给MaaS做一次“意图澄清”如果置信度低于阈值不直接执行而是回问一句“你问的是这件展品的来源对吗”。虽然多一步对话但避免了答非所问带来的更大挫败感。毕竟在景点现场游客问一遍没得到答案通常就不会再问第二遍了。4.3 现象三拍照识别张冠李戴在慈宁宫附近我对着一个琉璃影壁拍照识别Agent返回的是“故宫宫墙”。原因是那个位置宫墙和琉璃影壁颜色接近、构图相似多模态模型对小样本的琉璃构件识别精度确实不够。我做了两个处理第一增加提示词约束明确告诉模型“如果在故宫内识别到琉璃装饰优先判断是否为影壁、照壁类建筑构件的组成部分”把领域知识写进提示模型的表现立刻改善第二引入“用户纠偏”机制——识别结果页面提供一个可编辑框如果识别错了用户可以直接打字纠正。纠正后的数据会进入本地样本库同区域后续识别会优先参考。这个机制实测下来很有用多位朋友试用后都主动纠正过样本积累越多同区域识别越准。4.4 现象四讲解内容太“一本正经”游客根本听不进去第一次现场测试讲解模型给的回答是标准的百科式语言“太和殿是明清两代皇帝举行大典的地方面阔十一间进深五间建筑面积2377平方米……”不能说不对但人在景点现场真的听不进去。站在太和殿前面谁想听建筑面积数据后来我在提示词里加了一条“像朋友聊天一样介绍先讲一个有趣的故事或细节再补充理性背景。”同样一个太和殿改成“你抬头看屋脊上那排小兽第十个叫行什全故宫只有太和殿能放满十个。传说它是雷公的化身放在屋顶是为了镇殿避雷。你数一数别的殿最多九个只有太和殿敢放满。”这个改动效果立竿见影现场当时就好几个人抬头去数屋脊上的小兽。讲解内容生成不能只喂“事实参数”还得喂“叙事方式”这是AI导游体验的重要分水岭。4.5 排查方法论先分层再归因回头看所有翻车都遵循同一个排查链路先判断是端上问题还是云上问题用抓包工具看请求耗时分布等待响应的时间占总耗时大头问题多在云侧或网络端上处理占大头问题多在端侧代码。再判断是网络问题还是模型问题网络问题表现为整体变慢、连接超时模型问题表现为返回快但结果不对。最后判断是逻辑问题还是数据问题提示词写错、上下文传错是逻辑问题样本库不足、识别边界模糊是数据问题。另外提醒一点不要把“模型生成内容有误”归因于“参数没调好”就草草收场。把提示词设计、置信度阈值、缓存策略、用户纠偏当成一个整体来优化效果会好很多。我这次最深的感觉是AI应用现场翻车不是模型“笨”而是集成方式没匹配上真实场景的约束。5. 整体反思AI导游的价值边界与鸿蒙MaaS的组合拳5.1 实测数据与体验评分国庆当天实测从午门到神武门走完全程大约4小时我的AI导游完成了约80次问答交互其中拍照识别约35次语音问约45次。我记录的几组关键数据指标实测结果人流密集区响应时间平均3秒以上正常区域响应时间平均1.5秒左右建筑大类识别准确率约90%构件级识别准确率约70%需要用户纠偏次数约10次内容被二次追问的比例约40%总体体验打7分。扣分点主要在弱网场景下的卡顿以及部分构件识别不够精准。但“想用就拉起来用完就划走”的元服务体验和“问不倒”的AI讲解能力确实是传统讲解器完全给不到的。5.2 AI导游不是替代真人而是补充信息密度这次实测让我深刻体会到一个朴素的道理AI导游最大的价值不是替代导游而是把“信息密度”提上来。真人导游受限于体力、时间和路线只能挑重点讲AI导游可以做到每个物件都能问、每条问题都有回应哪怕是“这个屋顶为什么是斜的”“宫女的画像为什么都长一个样”这种跳脱问题它也能接住。但AI导游也有明显短板缺乏对游客状态的感知。真人导游能看出你累了、眼神飘了、对哪个方向好奇AI做不到。你站在太和殿前累得直喘AI还在那滔滔不绝讲斗拱结构这种体验就很出戏。所以我的结论是AI导游在景区更像一个“问不倒的百科全书加即时讲解器”更适合自由行和深度爱好者不适合需要被安排得明明白白的跟团游客。5.3 对鸿蒙元服务MaaS模式的后续想法这个组合几乎就是为“高频触点、轻量使用”的AI应用量身定做的元服务解决触达和分发问题MaaS解决模型能力和成本问题。对个人开发者来说不用自己买显卡、不用管运维、不用承担复杂的大模型部署工程就能把一个相对完整的AI应用跑在真实的系统生态里这个门槛确实被拉得很低。鸿蒙的分布式能力和元服务卡片体系让AI服务能以很低打扰度的方式出现在用户眼前这一点是传统“下载App”模式做不到的。后续如果继续做这个项目我考虑三个方向一是加入用户画像让讲解风格和内容深度能自适应不同人群——小朋友和历史爱好者需要的完全是两种语言。二是做离线增量模型把高频识别场景的样本在端上持续微调逐步减少对云端的依赖。三是把审核Agent做得更细建立针对景区语境的专业词表避免AI在文物命名、年代判定上出现低级的“一本正经胡说八道”这件事对文化场景尤其重要。最后说点实在话。这次“国庆故宫AI导游”与其说是一个能上架的产品不如说是一次技术可行性的充分验证鸿蒙元服务加蓝耘元生代MaaS确实能把AI应用做到“想用就拉起来用完就划走”的程度。但我也不回避现场那几次识别错误和超时卡顿让我意识到AI应用在真实公共场景里离“丝滑”还有距离。如果你也想做类似的东西我的建议是先想清楚场景约束——信号、噪音、用户耐心——再做技术选型先真机测试再追求体验优化。别被“大模型无所不能”的说法冲昏头落地的细节才决定你做出来的AI导游是被人夸好用还是被人当场划走。