国庆那几天我干了一件自己觉得挺有意思的事把一套跑在云上的大模型服务接到了鸿蒙设备里做成了一个“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 的分工逻辑整个应用架构其实不复杂我用一张“分工表”来梳理层级职责技术方案鸿蒙端 UI地图展示、对话界面、推荐卡片ArkUI 声明式开发鸿蒙端逻辑权限管理、语音采集、定位、请求封装ArkTS 语言网络传输HTTPS 调用JSON 格式交互标准 RESTful API服务端对话上下文管理、Prompt 模板、工具调用元生代 MaaS 网关模型层语言生成、意图识别、知识问答云端大模型这个架构的核心思路是将“重计算”留在云端“轻交互”放在端侧。端侧只负责三件事感知位置、语音、触摸、展示对话、地图、推荐内容、通讯把用户意图发给云端把模型结果渲染出来。所有需要“思考”的部分全部交给云端模型。我一直认为移动应用接入 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[]): Promisestring { 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 导游互动性高可实时提问无只能播放固定内容高支持多轮任意问答知识覆盖度依赖导游个人水平固定无法扩展极高大模型自身知识库兜底成本高中几乎为零稳定性依赖人力稳定但呆板受网络影响个性化低同一个团用一套话术低高可根据用户偏好调整讲解风格这个对比很直观AI 导游在互动性、知识覆盖度、个性化三个核心维度上优势明显。它最大的短板是受限于网络但这个问题会随着基础设施的完善逐渐弱化现在 5G 覆盖已经越来越广公共 Wi-Fi 在景区也越来越普及。6.2 值得优化的几个点第一个优化点是多模态能力。现在我的应用只用了文本和语音其实还可以接入图像识别。游客拍一张建筑照片应用识别建筑风格并生成讲解。大模型的多模态能力在元生代平台上也有后续可以扩展。第二个优化点是行程记忆。如果应用能记住游客的游览偏好、停留时间甚至能感知用户是否走累了推荐更轻松的路线体验会更完整。这需要更强的数据沉淀能力短时间做不出来但方向是对的。第三个优化点是离线兜底。虽然 MaaS 的体验足够好但在完全断网的区域会彻底不可用。我现在的方案是本地缓存景点基础文本如果网络不可用就播放缓存内容。这只能解决 30% 的场景如果要做到真正离线可用需要在设备端植入小模型和云端大模型做协同一个处理简单场景一个处理复杂场景组合出击。6.3 把方案拓展到其他场景这套“鸿蒙端 云端 MaaS”的架构本质上是一个通用的 AI 助手框架不限于景区导游。我盘了一下稍作修改就能复用到这些场景博物馆导览接入馆藏数据库支持展品详情问答、路径引导。校园导览新生入学报到时AI 助手带路、讲解教学楼分布。商场导购结合室内定位推荐店铺和优惠活动。智慧园区访客引导、会议室导航、政策问答。本质上是把“特定领域的知识库”和“大模型的自然语言理解能力”组合起来叠加位置感知提供一个有上下文、有记忆、有主动性的交互服务。这套思路可以平移到几乎所有“场地内服务”场景。7. 个人体验与心得这次实战做下来我最大的感受是鸿蒙生态接入大模型能力门槛比想象中低天花板比想象中高。门槛低体现在工程实现上。ArkTS 的语法和 TypeScript 高度相似有前端或移动端基础的开发者很快就能上手。元生代 MaaS 平台把模型服务封装得干净利落接入标准 API 就行不需要了解底层推理框架。整个应用的代码量不到两千行核心逻辑也就几个类的事情。天花板高体现在应用想象力上。当设备可以随时调动云端大模型的全部能力时应用的功能边界不再由“写死的逻辑”决定而由“交互的定义”决定。同一个框架你把它定义成导游它就是导游你把它定义成私人助理、学习教育工具、居家管家它就能变成那些东西。我遇到的最大瓶颈不是技术而是思维惯性。最初我总想着“把导游的讲解逻辑写进代码”结果越想越复杂。后来切换到“让模型理解导游场景自行组织讲解内容”的思维模式后所有问题迎刃而解。代码不负责“聪明”只负责“连接”。这个思路转变是这次实践最大的收获。如果你也想在鸿蒙设备上接入大模型能力我的建议是不要从训练模型开始也不要从自己搭建推理服务开始先把交互场景想清楚然后接一个成熟的 MaaS 平台跑通全链路。先跑通再优化最后才考虑更底层的定制。这条路是最务实、最能快速拿到结果的路径。