国庆那几天，我干了一件自己觉得挺有意思的事：把一套跑在云上的大模型服务，接到了鸿蒙设备里，做成了一个“AI 导游”应用，然后带着它逛了一圈著名古建景区。整个过程从立项到落地不到一周，踩了不少坑，也拿到了不少一手经验。今天就把这次“鸿蒙 AI + 云端 MaaS”的实战记录完整拆出来，给想在鸿蒙生态里接入大模型能力的朋友做个参考。

不夸张地说，这次实践让我对鸿蒙原生应用的 AI 化路径有了非常具体的体感：端侧负责交互和展示，云端大模型负责理解和生成，中间通过标准 API 协议衔接。这套组合打法和传统的“纯端侧 AI”“纯 Web AI”都不一样，坑位更刁钻，但天花板也更高。

先交代一下背景。我手上有一台支持鸿蒙 HarmonyOS 的开发设备，平时主要用于跑一些轻量级的原生应用测试。国庆前朋友推荐了一个叫元生代的 MaaS 平台，说可以按需调用多种大模型能力。所谓 MaaS，就是 Model as a Service，把大模型封装成服务，开发者不需要管模型训练、推理部署这些底层事，直接拿 API 用就行。对个人开发者和中小团队来说，这是接入 AI 能力最现实的路径，不用买卡、不用调集群，注册个账号拿 Key 就能开干。

于是我就想：能不能把这个云端的语言理解能力，和我手上的鸿蒙设备结合起来，做一个真正能在景区里用起来的 AI 导游？不是那种一问一答的聊天机器人，而是能结合游客位置、提供导览讲解、支持多轮问答、甚至能帮忙规划路线的实用工具。

这篇文章不做概念堆砌，只讲实操。你会看到我怎么拆解场景、怎么选型、怎么搭架构、怎么写代码、怎么调参数，以及在景区现场真机测试时遇到的各类问题。所有代码和方案都是可以直接参考复用的。

1. 场景拆解与整体设计思路

1.1 传统景区导览的痛点在哪

先说一个很现实的问题：现有的景区导览方案为什么体验不好？

常见的有三种：人工导游、电子导览器、手机扫码听讲解。人工导游的问题是贵、需要预约、旺季约不上，而且讲解节奏是固定的，你跟不上或者想多听两句都不行。电子导览器的问题更明显，设备老旧、租借麻烦、定位漂移、内容还是录制好的固定音频，你想问个“这个建筑为什么要朝这个方向”根本没人理你。扫码听讲解的问题在于内容碎片化，一码一讲，上下文不连续，而且基本没有互动能力。

真正缺的是一套能听懂人话、能连续对话、能根据游客所处位置主动调整讲解内容的导游系统。这恰恰是云端大模型的长项。传统导览是“播放”，AI 导览是“对话”，底层逻辑完全不同。

1.2 为什么必须用 MaaS 而不是本地模型

确定要做 AI 导游之后，摆在我面前的第一个选择是：模型跑在哪里？

当时我考虑过三种方案：

第一种方案，完全端侧部署。把一个小参数模型塞进鸿蒙设备里。好处是断网也能用、响应快、隐私好。但坏处很致命：我这台开发设备的算力跑 1B 模型都喘，做导游需要较强的语言理解、知识问答和多轮记忆能力，至少得 7B 以上的模型才靠谱。而且端侧还要处理语音识别、位置定位、渲染等任务，抢资源严重。测试下来，端侧模型回答一个简单问题都要四五秒，根本没法做交互。

第二种方案，自己搭建推理服务。这个直接被我否了。且不说本地有没有 GPU 服务器，光是模型部署、并发管理、弹性伸缩这些运维问题，就够喝一壶的，一周时间绝对搞不定。

第三种方案，接入 MaaS 平台，通过 API 调用云端大模型。这才是最务实的路线。元生代平台把模型封装成了标准化服务，我只需要处理应用层的逻辑：用户说什么、该传什么上下文、返回结果怎么展示。

选择 MaaS 还有一个隐形优势：灵活。大模型迭代速度非常快，今天用这个基座，明天那个基座效果更好，换一个参数就行，不需要改应用逻辑。程序员最烦的事就是“周一换模型、周二改代码”，用 MaaS 就完全不会有这个问题。

1.3 整体架构：鸿蒙端 + 云端 API 的分工逻辑

整个应用架构其实不复杂，我用一张“分工表”来梳理：

这个架构的核心思路是：将“重计算”留在云端，“轻交互”放在端侧。端侧只负责三件事：感知（位置、语音、触摸）、展示（对话、地图、推荐内容）、通讯（把用户意图发给云端，把模型结果渲染出来）。所有需要“思考”的部分全部交给云端模型。

我一直认为，移动应用接入 AI 的正确姿势不是把“AI 能力”硬塞进 App，而是把 App 变成 AI 能力的“交互前端”。这意味着你要想清楚：哪些逻辑应该在端上做，哪些应该丢给模型做。端上做交互控制，模型做语义生成，边界画清楚，体验才顺滑。

1.4 会用到哪些鸿蒙原生能力

这个项目里，鸿蒙端主要用到了以下原生能力：

位置服务：获取用户实时经纬度，然后通过逆地理编码换算成景区内的兴趣点编号。鸿蒙的位置服务接口继承自通用移动平台能力，用法类似但不完全相同，需要适配签名和权限声明方式。

语音识别与合成：实现“说话问导游”和“导游语音回答”的效果。我用的是系统级语音服务，采集音频流后转文字，模型返回文字后再通过合成接口播报出来。这套链路在鸿蒙上跑通需要特别注意权限申请时机，后面细说。

后台任务与通知：当用户在锁屏状态下继续聆听讲解时，需要靠后台任务保活。鸿蒙对后台任务的限制比较严格，简单说就是：前台时怎么玩都行，一退后台，资源立刻收紧。这里我踩了一个大坑，后面单开一节讲。

2. 从零搭建：环境准备与工程初始化

2.1 开发环境与设备要求

开始写代码之前，先要把环境搞定。官方推荐的组合是：DevEco Studio 配 HarmonyOS SDK，我用的是 API 12 的版本。需要注意，不同 API 版本对位置服务、语音服务的接口封装有差异，建议用较新的稳定版本，别追最新，否则第三方库适配跟不上。

设备方面，推荐用真机调试。因为模拟器在定位和语音这两个环节的表现和真机差异巨大，定位在室内模拟器根本拿不到真实信号，语音识别也需要真实麦克风采集。我是直接用开发设备连 USB 调试。

还要提前准备两样东西：华为账号和开发者认证。这是上真机调试和后续打包发布的前提。开发者认证需要实名信息，流程不复杂，但建议提前一两天搞定，别等调试当天才想起来。

2.2 元生代 MaaS 平台接入步骤

接下来是接入云端模型服务。元生代平台的接入流程比较标准：

控制台注册账号，完成实名认证，创建一个应用。创建后系统会分配一组 API Key 和 Secret Key，这组凭证相当于你的应用访问云端模型的通行证，务必妥善保管，不要硬编码在客户端代码里。

选择需要的模型能力。做导游项目，我主要用了两个能力：对话生成能力，负责讲解、问答、路线规划；语义理解能力，用于识别用户指令中的实体和意图。元生代平台上每个能力就是一个独立 API，调用方式大同小异。

开通服务后，控制台会给出接入文档和示例代码。各种语言的 SDK 都有，包括鸿蒙侧可以使用的 HTTP 接口。我建议先拿控制台自带的调试工具跑一遍，确认 Key 有效、模型能正常返回，再开始写应用代码。这一步能省下大量联调时间。

这里说一个重点：MaaS 平台给的 API 文档通常以传统 RESTful 接口为主，和鸿蒙应用的接入方式没有冲突。鸿蒙应用可以使用自带的 HTTP 工具包发起请求，不需要额外引入第三方网络库。我之前担心要自己封装一堆签名逻辑，实际看文档后发现，平台提供了通用鉴权头，照着格式拼就行，工作量不大。

2.3 鸿蒙项目工程初始化细节

在 DevEco Studio 里新建项目时，我选的是 Empty Ability 模板，包名等基础信息直接填。

这里有一个容易被忽视的细节：项目模块的 build-profile.json5 文件里需要配置签名信息。如果你的应用还没完成正式签名，会用自动签名模式，但设备必须登录同一账号才能识别。我在这个环节卡了快半小时，原因是设备和 IDE 登录的不是同一个账号，表现为“设备离线”。

创建完工程后，别急着写代码，先做两件事：一是确认 hvigor 版本和 SDK 版本匹配，否则编译会报各种莫名其妙的错；二是检查模块的 oh-package.json5 里有没有引入必要的依赖。我这次只用到了系统内置能力，所以依赖很简单。

2.4 权限声明：鸿蒙和安卓/iOS 的区别

鸿蒙的权限体系有自己的一套逻辑。在 config.json 或 module.json5 文件里声明权限时，要区分 system_grant 和 user_grant 两类。

我这次用到的定位权限和麦克风权限都属于 user_grant，也就是说运行时需要弹窗让用户授权。这里有个坑：鸿蒙要求开发者在发起能力调用前先检查权限是否已授予，未授予时主动发起授权请求，不能静默调用。如果直接调用定位接口而没申请权限，接口会静默失败，不报错、不返回数据，排查起来非常蛋疼。

正确做法是写一个权限检查工具类，集中处理“检查-申请-回调”的逻辑。在页面启动时依次申请定位和麦克风权限，用户同意后再初始化业务逻辑。语音合成权限也别忘了，合成播报属于后台音频播放的一种，需要单独配置。

3. 核心代码实现：鸿蒙端 + MaaS API 的完整串联

3.1 准备工作：定义数据模型与常量

动手写业务代码之前，先把数据模型定下来。我定义了三个核心模型类。

第一个是 ChatMessage，对应一次完整的对话消息。包含 role（用户还是助手）、content（文本内容）、timestamp（时间戳）。role 的取值传参方式要和 MaaS 平台 API 保持一致，我用的是 user 和 assistant 两种角色。

第二个是 TourPointInfo，对应景区兴趣点的信息。包括 pointId、名称、介绍文本、建议游览时长、坐标。这个模型的作用是给模型提供“知识背景”。当用户靠近某个景点时，我把对应景点的结构化描述拼进 Prompt，让模型基于当前场景回答问题。

第三个是 TourPlanResult，包含推荐的游览顺序、预计耗时、备注。这个模型用于路线规划功能的返回解析。

常量部分单独建了一个文件：API 端点地址、鉴权 Key、模型名称、超时时间。超时时间我设置为 30 秒，大模型生成一段较长文本可能需要接近这个时长，太短会把正常请求直接掐断。

3.2 MaaS API 调用封装

云端 API 的调用逻辑是整个应用的通信核心。我写了一个 AiTourService 类，封装所有对元生代平台的请求。

核心方法有两个：generateResponse，负责普通对话；generateTourPlan，负责带结构化输出要求的路线规划。

先看 generateResponse 的伪代码：

async generateResponse(userQuery: string, context: ChatMessage[]): Promise<string> { const requestBody = { model: 'qwen-plus-turbo', messages: [ ...context, { role: 'user', content: userQuery } ], temperature: 0.7, max_tokens: 1024 }; const response = await httpRequest(API_ENDPOINT, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${ACCESS_TOKEN}` }, body: JSON.stringify(requestBody) }); if (response.code !== 0) { throw new Error(`API 调用失败: ${response.message}`); } return response.data.choices[0].message.content; }

注意几个细节：

第一，上下文列表要包含历史消息，这样模型才能记住“上一轮说了什么”。我维护了一个长度为 10 的滑动窗口，超过 10 条就丢弃最早的。太长会导致 Token 消耗激增、响应变慢，太短会丢失上下文。10 条是我实测下来比较平衡的值。

第二，temperature 参数控制随机性。做导游讲解我设置了 0.7，如果追求更稳定的事实输出可以调到 0.3。但太低会让回答显得干瘪，少了一些人情味，导游嘛，还是希望话术活泼一点。

第三，max_tokens 是单次返回的最大长度。1024 个 Token 大约能生成 700 到 800 个汉字，足够覆盖一段景点讲解了。如果游客追问细节，再通过多轮对话补充。

3.3 鸿蒙 UI 页面开发

界面部分我用 ArkUI 声明式语法实现。整体结构分为三层：顶部的标题栏、中部的对话区域、底部的输入栏。

对话区域我用 Scroll + List 组件组合。每条消息渲染成一个气泡，左侧是助手的回答，右侧是用户的提问。因为导游场景需要较长的文本展示，我在气泡内部嵌套了可滚动区域，当文本超过一定长度时用户可以在气泡内滑动查看。

底部输入栏做了两个入口：文字输入框和语音按钮。按住语音按钮采集音频，松开后自动识别并发送。这个交互模式和主流语音助手一致，上手零成本。

地图模块我用了官方地图组件。显示用户当前位置的同时，在地图上打上附近兴趣点的标记点。点标记后弹出卡片，显示景点名称和介绍摘要，并提供“开始讲解”按钮。点击按钮后会触发一次完整的“定位-取景-生成内容-播报”流程。

先跑通文字交互，再叠加语音，最后接地图。分步走的好处是方便定位问题。我做的时候是一口气全写完再统一调试，结果出了 bug 根本分不清是 UI 的问题、语音的问题还是 API 调用的问题，白白多花了两三个小时。

3.4 语音交互链路实现

语音交互是 AI 导游的核心体验。我说一下完整链路：用户说话 → 录音 → 语音识别转文字 → 发送给云端模型 → 模型返回回答文本 → 文本转语音播报。

鸿蒙的语音识别接口属于系统级能力，调用形式是创建 recognizer 实例，设置监听回调。识别结果通过回调返回，分为中间结果和最终结果。我取最终结果发送。这里有个经验：不要每次回调都发送中间结果，否则用户还没说完你就把半截话发出去了，模型答非所问。

语音合成相对简单，创建 synthesizer 实例后调用 speak 方法即可。需要注意合成引擎的语速和音色选择。我选了标准女声，语速调慢了一点，因为导游讲解太快听起来很赶。

还有一个联动细节：当模型回答文本较长时，语音合成需要逐句播放。如果用户在播放过程中发起新对话，要立即停止当前播报，否则会和新回答重叠。这个逻辑处理不好，体验会很混乱。

3.5 位置定位与兴趣点匹配

定位逻辑用的是鸿蒙位置服务接口。获取经纬度后，通过计算距离找到距离最近的兴趣点。

兴趣点坐标需要提前录入数据库。我建了一个本地 JSON 文件，存储景区主要建筑和景点的经纬度、名称、简介。每次定位刷新后，遍历所有兴趣点，计算距离，取出最近的一个。

这里有一个精度问题：GPS 信号在建筑密集区域漂移明显，明明站在甲景点门口，定位却显示在乙景点。我加了一个容错机制：只有距离小于 50 米才触发自动讲解，否则只显示“附近景点”列表，由用户手动选择。

这个机制非常重要，避免了我走到一半被系统莫名切换讲解对象。景区导览最怕的就是“讲 A 讲到一半突然开始讲 B”，非常影响体验。

4. 现场实战：国庆景区里的真实表现

4.1 出发前的准备与测试

国庆当天上午，我在家里做了最后一轮测试：确认 API Key 有效、确认模型返回正常、确认语音链路通畅。把应用安装到设备上，带着充电宝就出门了。

这里提醒一句：出门前一定确认手机电量，AI 导游应用属于高耗电应用，屏幕常亮、GPS 持续定位、语音播报、网络请求，每一项都是电老虎。我实测连续使用两个小时，电量从 100% 掉到 38%，比我预想的还要夸张。后来我加了一个屏幕亮度自动降低的逻辑，才稍微缓解。

另外，网络环境决定了体验下限。景区里人山人海，4G/5G 信号并不稳定。我提前把主要景点的介绍文本缓存到了本地，至少保证弱网条件下也能看到基础文字内容，只是动态问答会受影响。

4.2 现场实际使用记录

进入景区后，我打开应用，授权了定位和麦克风权限，开始正式体验。

第一站是主殿。站在广场中间，应用触发了一次自动定位，匹配到了主殿的兴趣点，自动弹出了介绍卡片。我点击“开始讲解”，应用把主殿的结构化信息发给云端模型，模型生成了一段 200 字左右的讲解，语音播报出来。整体响应大约 2 秒，完全可以接受。

我试着追问了一句：“这座殿的屋脊上有几个神兽？”这个信息并不在结构化文本里，模型依靠自身知识库直接回答了。这个场景让我意识到，大模型导游和传统电子导览的本质差异就在这里：传统导览只能播报预置内容，而大模型可以基于自身知识回答任意问题，不受预置内容限制。

接下来测试路线规划。我问：“我想在一小时内看完中轴线的主要建筑，怎么走？”模型给出了包含顺序、时长、注意事项的回答。我按照它的规划走了一遍，实际时间和预测偏差在十分钟以内。

整个下午，应用一共有过 14 次主动讲解触发、9 次追问回答、3 次路线咨询。其中有两次定位偏移导致推荐了错误的景点，其余表现稳定。

4.3 真实场景中暴露的问题

现场测试暴露的问题比家里测试多得多，可以说是这趟实践最值钱的收获。

第一个问题是弱网环境下的响应超时。在人流密集区域，网络拥塞导致 API 请求超过 30 秒没有返回。我的超时设置直接掐断了请求，用户侧表现为“没有回答”。后来我把超时时间调整为 45 秒，并增加了一行“正在思考”的缓冲提示，体验好了不少。

第二个问题是语音识别的误识别。嘈杂环境下，系统把周围游客聊天的只言片语也识别进来了，导致模型收到莫名其妙的输入。我加了一个语音活动检测策略：只有当麦克风采集到超过一定分贝且持续超过一秒的语音才触发识别，短促的环境噪音直接忽略。

第三个问题是后台播放被系统回收。进入锁屏状态后，语音播报会持续一小段时间，然后被系统强制挂起。我试了申请后台任务权限，也试了前台服务类型，但鸿蒙的机制限制很明显，锁屏超过一段时间后应用会被挂起。这个问题的根治方案需要应用申请“长时任务”权限，这次因为时间关系没有深入处理，但大家在做长时间音频播报场景时，一定要提前研究这个限制。

4.4 性能与耗电数据复盘

回到家我导出了性能日志，整理了几个关键数据：

应用冷启动时间约 2.8 秒。其中 UI 初始化占大头，API 密钥读取、模型初始化等操作在启动阶段并行执行，没有阻塞界面。

单次对话全链路耗时：正常网络环境下，录音 3 秒 → 识别 1.5 秒 → 模型生成 2 秒 → 语音播报 5 秒，总耗时 11 秒左右。这个数据对导游场景完全可以接受，毕竟语音播报本身就是时间的大头。

应用峰值内存约 380MB。地图渲染和语音引擎是内存大户。运行两小时后，系统内存压力提示出现，我优化了地图标记点的数量，从每帧渲染全部标记改为只渲染可视区域内的，内存降了约 80MB。

连续两小时耗电 62%，属于较高水平。主要是因为麒麟芯片跑 AI 场景和语音处理时功耗较高。建议大家在实际产品中做省电策略：长时间无交互自动降低定位频率、屏幕常亮超过三分钟自动锁定。

5. 踩坑复盘：这五类问题最值得注意

5.1 权限初始化顺序导致的“静默失败”

最典型的问题就是权限没申请就调用能力，接口不报错但数据全空。我在调试定位功能时浪费了大量时间：代码逻辑检查了一遍又一遍，结果发现只是少了授权弹窗的确认。

在测试阶段，开发者模式可以一键授予所有权限，但正式运行时权限弹窗必须由用户手动点击。所以我专门写了一个启动引导页，在进入主界面前必须完成定位和麦克风的授权，防止进入主界面后功能异常。

5.2 上下文长度管理不当引发“遗忘症”

多轮对话中，如果上下文管理不当，模型会出现“遗忘”现象。表现为：前面聊过的景点信息，后面再问就答不上来了。

原因是滑动窗口把早期上下文丢弃了。我的 10 条滑动窗口在大多数情况下够用，但如果用户在 10 条之内穿插了多个景点的提问，模型可能混淆“当前正在讲哪个景点”。

我的解法是在 Prompt 开头加入一个“当前剧情摘要”，每次生成前把当前的景点名称、用户位置、最近一次交互摘要作为固定上下文传进去，模型就不会跑偏了。这个技巧对长对话场景非常有效，推荐大家直接采用。

5.3 网络超时与重试策略不合理导致“卡死”

我最初的设计是请求超时就直接失败，没有重试机制。现场实测发现弱网环境下请求超时概率不低，一旦超时整个交互就中断，用户骂娘是必然的。

后来我加了“两次重试 + 指数退避”策略：第一次超时后等 2 秒重试，第二次超时后等 4 秒重试，仍失败才提示用户。同时在等待过程中用“正在思考”的动画占位，用户感知到的只是稍微慢了一点，而不是“坏了”。

5.4 模型返回格式不稳定导致解析崩溃

MaaS 平台虽然是标准化接口，但模型输出内容存在一定随机性。我在路线规划功能里要求模型返回结构化字段，但有时模型会多输出一段解释文字，导致 JSON 解析失败。

解决方法是采用“双保险”解析策略：先尝试严格 JSON 解析，失败后用正则提取关键字段。如果仍然提取失败，就丢弃本次结构化结果，将全文当作普通文本展示。绝不因为一次解析失败就让整个功能崩溃。

5.5 鸿蒙系统对后台任务的限制导致播报中断

这个问题前面提过，我再展开讲讲。我在景区里发现锁屏后讲解播报大约 20 秒就会被系统挂起，即使用户正在听讲解。查遍官方文档，最终确认是鸿蒙的后台任务机制在起作用：普通应用退到后台后，系统会根据资源情况回收。

要解决这个问题，需要申请长时任务权限，适配方式是在 module.json5 中声明对应的后台模式，并在代码中启动长时任务回调。这需要应用满足特定的使用场景才会被系统接受。音频播放类应用是可以申请的，但需要在应用商店审核时说明用途。如果你做的场景不涉及长时间后台播报，就别折腾这项能力了，规则限制确实比较严格。

6. 效果评估与实用优化建议

6.1 和传统导览的对比评测

整个体验结束后，我做了一个对比表，不代表任何权威机构，纯粹是个人感受：

这个对比很直观：AI 导游在互动性、知识覆盖度、个性化三个核心维度上优势明显。它最大的短板是受限于网络，但这个问题会随着基础设施的完善逐渐弱化，现在 5G 覆盖已经越来越广，公共 Wi-Fi 在景区也越来越普及。

6.2 值得优化的几个点

第一个优化点是多模态能力。现在我的应用只用了文本和语音，其实还可以接入图像识别。游客拍一张建筑照片，应用识别建筑风格并生成讲解。大模型的多模态能力在元生代平台上也有，后续可以扩展。

第二个优化点是行程记忆。如果应用能记住游客的游览偏好、停留时间，甚至能感知用户是否走累了，推荐更轻松的路线，体验会更完整。这需要更强的数据沉淀能力，短时间做不出来，但方向是对的。

第三个优化点是离线兜底。虽然 MaaS 的体验足够好，但在完全断网的区域会彻底不可用。我现在的方案是本地缓存景点基础文本，如果网络不可用就播放缓存内容。这只能解决 30% 的场景，如果要做到真正离线可用，需要在设备端植入小模型，和云端大模型做协同，一个处理简单场景，一个处理复杂场景，组合出击。

6.3 把方案拓展到其他场景

这套“鸿蒙端 + 云端 MaaS”的架构，本质上是一个通用的 AI 助手框架，不限于景区导游。我盘了一下，稍作修改就能复用到这些场景：

博物馆导览：接入馆藏数据库，支持展品详情问答、路径引导。

校园导览：新生入学报到时，AI 助手带路、讲解教学楼分布。

商场导购：结合室内定位，推荐店铺和优惠活动。

智慧园区：访客引导、会议室导航、政策问答。

本质上是把“特定领域的知识库”和“大模型的自然语言理解能力”组合起来，叠加位置感知，提供一个有上下文、有记忆、有主动性的交互服务。这套思路可以平移到几乎所有“场地内服务”场景。

7. 个人体验与心得

这次实战做下来，我最大的感受是：鸿蒙生态接入大模型能力，门槛比想象中低，天花板比想象中高。

门槛低体现在工程实现上。ArkTS 的语法和 TypeScript 高度相似，有前端或移动端基础的开发者很快就能上手。元生代 MaaS 平台把模型服务封装得干净利落，接入标准 API 就行，不需要了解底层推理框架。整个应用的代码量不到两千行，核心逻辑也就几个类的事情。

天花板高体现在应用想象力上。当设备可以随时调动云端大模型的全部能力时，应用的功能边界不再由“写死的逻辑”决定，而由“交互的定义”决定。同一个框架，你把它定义成导游，它就是导游；你把它定义成私人助理、学习教育工具、居家管家，它就能变成那些东西。

我遇到的最大瓶颈不是技术，而是思维惯性。最初我总想着“把导游的讲解逻辑写进代码”，结果越想越复杂。后来切换到“让模型理解导游场景，自行组织讲解内容”的思维模式后，所有问题迎刃而解。代码不负责“聪明”，只负责“连接”。这个思路转变，是这次实践最大的收获。

如果你也想在鸿蒙设备上接入大模型能力，我的建议是：不要从训练模型开始，也不要从自己搭建推理服务开始，先把交互场景想清楚，然后接一个成熟的 MaaS 平台跑通全链路。先跑通，再优化，最后才考虑更底层的定制。这条路是最务实、最能快速拿到结果的路径。