鸿蒙AI：国庆我在故宫用了把"AI 导游"：蓝耘元生代 MaaS + 鸿蒙 HarmonyOS 实战全记录

当六百年紫禁城遇上国产大模型，当鸿蒙原生应用遇上统一 MaaS 网关——这个国庆，我用蓝耘元生代 MaaS 给故宫装上了一颗"会讲解的 AI 大脑"。

引言：一次国庆出行，一个技术想法

十一黄金周，故宫永远是顶流。红墙金瓦之间，人山人海的游客举着自拍杆，在太和殿前排起长队。但你有没有发现一个问题——绝大多数人逛故宫，只是"看"，而不是"懂"。

那些宫殿为什么这样建？太和殿里的金砖墁地有什么讲究？乾清宫"正大光明"匾背后藏着怎样的立储制度？没有讲解员，没有导览器，游客只能走马观花，拍几张照片，发个朋友圈，然后带着一知半解离开。

作为一个开发者，一个鸿蒙生态的参与者，我一直在思考一个问题：能不能用 AI，给每一位游客配一个"随身故宫专家"？

这个国庆，我把这个想法变成了现实。我用 HarmonyOS（鸿蒙）ArkTS 开发了一款名为「故宫 AI 导游」的原生应用，而它的 AI 大脑，来自 蓝耘元生代 MaaS。

这篇文章，我想完整地记录这次实战——从技术选型、蓝耘 MaaS 的接入体验，到鸿蒙应用的架构设计，再到最终效果。全程干货密集，希望能给同样想在鸿蒙上玩转大模型的你一些参考。

一、为什么是蓝耘元生代 MaaS？——大模型时代的"水和电"

在讲应用之前，必须先聊聊这次实战的核心底座——蓝耘元生代 MaaS（Model as a Service，模型即服务）。毫不夸张地说，正是它让这一切变得如此简单。

1.1 什么是 MaaS？为什么它是大模型应用的最佳形态

先简单科普一下 MaaS。传统上，如果开发者想在自己的应用里用上大模型，需要自己做什么？

• 买显卡、搭集群：动辄几十上百万的 GPU 投入，还得考虑机房、散热、运维
• 选模型、做微调：从开源社区挑模型，自己搭建推理框架，处理量化、加速
• 写接口、保稳定：封装 API、做负载均衡、应对高并发、保证可用性
• 管成本、防失控：按 Token 计费的黑盒，一旦流量上来账单可能失控

这一整套下来，没有专业 AI 团队和雄厚资金，根本玩不转。

而 MaaS 的出现，彻底改变了这个游戏规则。它把大模型能力变成一种"即开即用"的云端服务——你不需要懂 GPU，不需要懂推理框架，甚至不需要懂模型本身。你只需要调一个 HTTP 接口，就能让千亿参数的大模型为你所用。

这就像电力革命——你不需要自己建电厂，插上插座就有电。MaaS 就是大模型时代的"电网"。

1.2 认识蓝耘：不只是 MaaS，更是 AI 算力生态的筑基者

在深入平台功能之前，有必要先认识一下"蓝耘"这家公司——因为它不是凭空冒出来的新玩家，而是在 AI 算力领域深耕多年的实力派。

蓝耘科技是一家专注于 AI 算力服务与人工智能解决方案 的高新技术企业。和很多"蹭大模型热点"的公司不同，蓝耘的根基在算力——这是大模型时代最核心、最稀缺的资源。从 GPU 算力集群的建设运营，到 AI 开发平台的搭建，再到如今面向大模型时代的"元生代 MaaS"，蓝耘走的是一条从底层算力到上层模型服务的全栈之路。

这一点非常关键。为什么这么说？因为MaaS 的本质，是算力的高效交付。一个 MaaS 平台好不好用、稳不稳定、贵不贵，归根到底取决于它背后有没有强大、可控、高性价比的算力底座。蓝耘恰恰是从算力起家的——这意味着它对算力的理解、对推理性能的优化、对成本的控制，都是"刻在基因里"的，而不是简单地在别人的算力上套一层 API。

"元生代"这个名字也颇有深意——它寓意着大模型开启了 AI 的"新纪元"，而蓝耘要做的，就是这个新纪元的"基础设施提供者"。这种从算力底层一路做到模型服务的全栈能力，正是蓝耘元生代 MaaS 区别于市面上众多"二道贩子"式 MaaS 平台的核心底气。

1.3 蓝耘元生代 MaaS：凭什么脱颖而出

市面上的 MaaS 平台不少，为什么我最终选择了蓝耘元生代 MaaS？因为它在几个关键维度上，真正做到了开发者友好。

① OpenAI 兼容协议，零成本迁移

这是最打动我的一点。蓝耘 MaaS 完全采用 OpenAI 兼容的 API 协议（chat/completions）。这意味着什么？

意味着如果你之前用过 OpenAI 的 API，或者用过任何兼容 OpenAI 协议的框架（LangChain、LlamaIndex、各种 SDK），你几乎不需要改任何代码，只需要换一下 Base URL 和 API Key，就能无缝切换到蓝耘 MaaS。

// 这就是全部配置，仅此而已
endpoint: 'https://maas-api.lanyun.net/v1/chat/completions'
Authorization: 'Bearer <你的API_KEY>'

没有私有协议的学习成本，没有厂商锁定，没有奇奇怪怪的参数格式。这种对开放标准的尊重，是一个 MaaS 平台最大的诚意。

② 统一网关，一个接口接入所有模型

蓝耘 MaaS 是一个统一的大模型网关。看上面那张模型广场截图你就明白了——Kimi-K3、GLM-5.3、DeepSeek、Qwen、MiniMax……国内外主流大模型，全部汇聚在同一个平台，用同一套 API 协议对外提供。

这对开发者太友好了。想象一下：你的应用今天用 DeepSeek，明天想试试 GLM，后天想对比一下 Kimi——你只需要改一个 model 参数，不用换 SDK，不用改鉴权，不用重写代码。 这种"模型自由"，在以前是不可想象的。

③ 国产大模型全家桶，自主可控

蓝耘 MaaS 上架了大量优秀的国产大模型。在当前强调技术自主可控的大背景下，这一点尤为重要。你不用担心某天某个海外 API 突然断供，不用担心数据出境合规问题。蓝耘 MaaS 让你用上真正自主可控的国产大模型能力。

④ 可视化用量统计，成本一目了然

开发者最怕什么？最怕账单失控。蓝耘 MaaS 提供了非常清晰的可视化用量统计后台：

从截图可以看到，每个模型的调用次数、Token 消耗量、最高 TPM/RPM、消费金额、最近调用时间，全都一目了然。我这次实战用的 deepseek-v4-flash，调用了 3 次，消耗 5136 个 Token，成本 ¥0.00——是的，你没看错，平台给了充足的体验额度。这种透明、可控的计费体验，让开发者可以放心大胆地创新。

⑤ 企业级稳定性，为生产环境而生

作为面向企业的 MaaS 平台，蓝耘在背后提供了企业级的算力保障和稳定性。高并发、低延迟、SLA 保障——这些对于要面向真实用户的应用来说，是生死线。蓝耘 MaaS 让我可以专注于业务逻辑，把底层的算力和稳定性交给专业的人。

⑥ 模型广场：一站式的"模型超市"

我特别想单独说说蓝耘 MaaS 的模型广场。回到文章开头那张截图，你会发现它做得非常像一个精心运营的"模型超市"：

• 分类清晰：按"文本生成、图像理解、视频生成、多模态、语音合成"等能力维度分类，左侧还有厂商导航（DeepSeek、Kimi、智谱 AI、百度、阿里、MiniMax……）
• 信息完整：每个模型卡片都标注了能力标签、上下文长度、模型简介，一目了然
• 开箱即用：每个模型都配有"API 示例"和"查看详情"，点开就能看到调用方法和参数说明

这种产品化的呈现方式，大大降低了"选模型"的门槛。你不需要去各家官网翻文档对比，在蓝耘 MaaS 的模型广场里逛一圈，就能找到最适合你业务场景的那一个。对于我这种想快速验证想法的开发者来说，这种体验太友好了。

⑦ 从体验到生产：完善的开发者服务

蓝耘 MaaS 不只是给你一个 API 就完事了，它提供的是一套完整的开发者服务闭环：

• 充足的免费体验额度：注册即送，让你零成本把想法跑通（我这次实战全程没花一分钱）
• 详细的 API 文档与示例：每个接口都有清晰的文档和可直接运行的代码示例
• 灵活的计费模式：按 Token 用量计费，用多少付多少，不浪费；还有资源包等更优惠的选择
• 完善的管理后台：API Key 管理、用量统计、消费明细、子账号权限……企业级的管理能力一应俱全

这种"从体验到生产"的全流程覆盖，让一个个人开发者的小项目，和一个企业级的大规模应用，都能在同一个平台上找到合适的用法。

⑧ 不止于对话：面向未来的多模态能力

我这次实战只用了文本对话能力，但蓝耘 MaaS 的能力版图远不止于此。从模型广场就能看到，它还上架了图像理解、图像生成、视频生成、语音合成等多模态能力。

这意味着我的「故宫 AI 导游」未来有巨大的升级空间：游客拍一张文物照片，AI 就能识别并讲解（图像理解）；根据宫殿生成专属的国风插画明信片（图像生成）；把 AI 讲解转成真人般的语音导览（语音合成）……而这些，全部可以在蓝耘 MaaS 这一个平台内完成，不用再去对接其他厂商。这种"一个平台，全栈 AI 能力"的布局，才是真正的开发者福音。

1.4 蓝耘 MaaS 能力全景

为了让大家对蓝耘元生代 MaaS 有一个更立体的认识，我把它的核心能力整理成一张表：

1.5 一句话总结

如果说大模型是这个时代最强大的引擎，那么蓝耘元生代 MaaS 就是让你毫不费力就能踩下油门的那个踏板——而且这辆车的油箱（算力）、仪表盘（监控）、变速箱（模型调度），全都是蓝耘自己造的。

---

二、为什么是鸿蒙 HarmonyOS？——AI 原生应用的沃土

选好了 AI 大脑（蓝耘 MaaS），接下来要选一个"身体"——应用跑在哪个系统上？我的答案是 HarmonyOS（鸿蒙）。

2.1 鸿蒙 + AI，天作之合

可能有读者会问：为什么不直接用微信小程序，或者做个 H5？原因有三：

第一，鸿蒙是 AI 原生的操作系统。 HarmonyOS 从设计之初就深度考虑了 AI 能力的融合，系统级 AI、意图框架、分布式能力，都让 AI 应用有更广阔的想象空间。把 AI 应用做成鸿蒙原生，是最自然的选择。

第二，性能与体验。 原生 ArkTS + ArkUI 的声明式 UI，配合蓝耘 MaaS 的低延迟 API，可以做到接近零等待的流畅对话体验。这是 WebView 套壳方案无法比拟的。

第三，生态与未来。 鸿蒙生态正在高速扩张，手机、平板、2in1、车机、手表……一次开发，多端部署。我的「故宫 AI 导游」未来可以无缝跑到平板上做更沉浸的导览，跑到手表上做语音问答。

2.2 技术栈一览

---

三、应用设计：以 AI 为核心的故宫导览

在动手写代码之前，我先明确了这款应用的核心设计理念：AI 不是附加功能，AI 就是产品本身。

很多应用是把 AI 当作一个"聊胜于无"的入口藏在角落。而我要做的，是让 AI 贯穿整个用户体验的始终。

3.1 产品定位

「故宫 AI 导游」——一款以蓝耘 MaaS 大模型为大脑的故宫智慧导览应用。它要解决的痛点非常清晰：让每一位游客，都能拥有一个 7×24 小时在线、知识渊博、随叫随到的故宫专家。

3.2 功能架构

应用采用经典的底部三 Tab 结构，但每一个 Tab 都深度融入 AI：

• 首页：突出 AI 能力与蓝耘 MaaS 品牌，提供 AI 服务快捷入口
• AI 导游（核心页）：完整的多轮对话，支持宫殿历史、宫廷文化、文物故事问答
• 景点导览：每个景点一键唤起 AI 讲解，实时生成专属解说

---

四、实战效果：图文并茂看成果

话不多说，直接看最终效果。所有 AI 回答均由蓝耘 MaaS 实时生成。

4.1 首页：AI 能力的门面

首页是用户对产品的第一印象。顶部红金渐变的沉浸式头图（故宫红墙配色），明确传递"故宫 AI 导游"的定位。头图下方就是醒目的 “由蓝耘元生代 MaaS 提供大模型能力” 品牌条——我要让每一位用户都知道，这背后强大的 AI 来自哪里。

中间的「AI 智能服务」宫格提供四大能力入口：AI 语音讲解、智能路线、文物故事、参观问答。点击任何一个，都会直接跳转到 AI 导游页。底部还有一条「向 AI 导游提问」的体验引导条。

整个首页的设计语言非常明确：这是一个 AI 应用，AI 是它的灵魂。

4.2 AI 导游页：多轮对话的核心战场

这是应用的核心页面。打开就是一段由蓝耘 MaaS 驱动的欢迎语：

注意顶部那条深红色的品牌横幅——“蓝耘元生代 MaaS · deepseek-v4-flash · OpenAI 兼容 · 统一网关”，右侧还有"AI 导游已接入"的状态徽标。这是对蓝耘 MaaS 最直接的品牌露出。

页面下方是快捷提问区（“讲讲太和殿的历史”、"故宫为什么叫紫禁城？"等），降低用户的提问门槛。

实战对话一：讲讲太和殿的历史

我点击快捷提问"讲讲太和殿的历史"，蓝耘 MaaS 立刻返回了一段专业而生动的讲解：

看这段回答的质量——它不只是干巴巴地说"太和殿是皇帝办公的地方"，而是从"金銮殿"的俗称切入，讲它是"紫禁城的心脏"、“明清两朝皇权的最高象征”，甚至用了一句非常有画面感的话：

“它并不是一座简单的’大房子’，而是一部用木头、石头和琉璃写成的皇权史诗。”

这种表达的专业度和文学性，已经远超一般的导览器。更让我惊喜的是，它还自动补充了"历史沿革：三次改名，四次重建"的结构化知识，并提到了永乐十八年（1420 年）的始建时间。

实战对话二：游览贴士（上下文理解）

更有价值的是，AI 在讲解之后，主动给出了"游览贴士"——而且结合了国庆黄金周的实时场景：

“国庆黄金周期间，故宫实行实名预约、限流参观，建议提前 7 天在官方渠道预约……”

“太和殿广场游客众多，可先到中轴线两侧的廊下稍作停留，既能避开人流，也能远观太和殿全貌……”

“拍摄时请注意不要使用三脚架和自拍杆，也不要触摸汉白玉栏杆……”

这些是非常具体、可执行的实用建议。注意——它知道现在是国庆期间，知道要限流预约，知道要保护文物。这正是大模型相比传统固定文案导览的核心优势：它能理解上下文，能结合场景生成真正有用的内容。

最后它还非常贴心地收尾："站在太和殿前，你会明白什么叫’至高无上’……还有什么想了解的吗？我可以继续为你讲解中和殿、保和殿，或者聊聊太和殿广场上的铜鹤铜龟哦。"这种拟人化的引导，让对话体验非常自然。

实战对话三：故宫为什么叫紫禁城？

我继续追问"故宫为什么叫紫禁城？"，AI 给出了一段兼具历史深度和人文温度的回答：

它从明代永乐四年（1406 年）始建讲起，解释"紫禁城"取"紫微禁地"之意——紫微星是天帝居所，皇帝贵为天子，其宫殿自然称"紫禁"。然后讲了 1912 年清帝退位、1925 年溥仪被逐出宫后改称"故宫博物院"的历史变迁。

最打动我的是这段：

“如果你想感受’紫’与’禁’的氛围，建议站在护城河对面西侧的城墙上远眺一次角楼，那里最能体会’城’的森严之美。”

这已经不是简单的知识问答了，这是真正有洞察力、有体验感的导游建议。这种回答质量，让我对蓝耘 MaaS 背后的模型能力刮目相看。

4.3 景点导览页：AI 一键讲解

第三个 Tab 是景点导览。这里我做了一个很实用的设计：每个景点卡片右侧都有一个「AI讲解」按钮。

列表按"全部/宫殿/展馆/园林/城楼"分类筛选，涵盖太和殿、乾清宫、珍宝馆、钟表馆、御花园、慈宁宫花园、午门、角楼、坤宁宫等 9 处经典景点。每个卡片显示景点图标、名称、简介、建议游玩时长和热门标签。

AI 讲解的调用过程

当我点击太和殿的「AI讲解」按钮，应用会弹出一个底部弹层，先显示"AI 导游讲解中，请稍候…"的加载态：

注意弹层顶部同样挂着 “蓝耘 MaaS · AI 讲解” 的品牌标识。然后，蓝耘 MaaS 实时生成的讲解内容流式呈现：

来看这段针对太和殿的 AI 讲解：

“大家好，我是故宫 AI 导游。太和殿俗称’金銮殿’，是紫禁城等级最高的建筑，明清皇帝登基、大婚、命将出征等大典都在此举行。它坐落在三层汉白玉台基上，重檐庑殿顶，面阔十一间，殿内金砖墁地，蟠龙藻井下的宝座上方悬’建极绥猷’匾，气势恢宏。游览时建议一早从午门直入中轴线，避开人流高峰；国庆期间务必提前预约门票，殿外栏杆处拍照最出片。”

短短一百多字，信息密度极高：俗称、等级、功能（登基/大婚/命将出征）、建筑特征（三层汉白玉台基、重檐庑殿顶、面阔十一间、金砖墁地、蟠龙藻井、建极绥猷匾），最后还给了非常实用的游览建议（一早从午门进、避开人流、国庆预约、拍照机位）。

这种"知识 + 实用建议"的融合，正是大模型做导览的独特价值。 传统导览器只能播放预录的固定音频，而 AI 能根据场景、时间、用户需求实时生成个性化内容。

---

五、技术实现：鸿蒙 ArkTS 如何优雅地接入蓝耘 MaaS

聊完效果，我们来深入技术细节。这部分是给开发者看的硬核内容。

5.1 整体架构

应用的架构非常清晰，分为三层：

5.2 配置层：AIConfig

我把所有蓝耘 MaaS 相关的配置收敛到一个 AIConfig 类中，这是最优雅的做法——密钥、端点、模型、提示词集中管理，一处修改，全局生效。

// entry/src/main/ets/common/AIConfig.ets
export class AIConfig {
  // 蓝耘 MaaS 服务地址（OpenAI 兼容 chat/completions 接口）
  static readonly endpoint: string =
    'https://maas-api.lanyun.net/v1/chat/completions';

  // 访问密钥
  static readonly apiKey: string = 'sk-xxxxxxxxxxxxxxxx';

  // 模型标识
  static readonly model: string = 'deepseek-v4-flash';

  // 系统提示词：把模型约束为"故宫 AI 导游"身份
  static readonly systemPrompt: string =
    '你是"故宫 AI 导游"，一位精通明清历史与宫廷文化的专业讲解员……';

  static readonly temperature: number = 0.7;
  static readonly maxTokens: number = 1500;
  static readonly timeoutMs: number = 45000;
}

这里有几个值得说道的设计点：

① OpenAI 兼容协议的威力再次显现。 注意 endpoint 就是标准的 /v1/chat/completions，请求头就是标准的 Bearer 鉴权。蓝耘 MaaS 把接入成本压到了最低。

② 系统提示词（System Prompt）是灵魂。 我通过精心设计的 system prompt，把通用大模型"约束"成了一位专业的故宫导游。这是提示词工程（Prompt Engineering）的典型应用——不需要微调模型，只需一段好的提示词，就能让模型进入特定角色。

③ 模型可插拔。 想换模型？改 model 这一行就行。蓝耘 MaaS 统一网关的优势在这里体现得淋漓尽致。

5.3 服务层：GuideAI

服务层封装了对蓝耘 MaaS 的所有调用。我提供了两个核心方法：chat() 用于多轮对话（AI 导游页），ask() 用于单句提问（景点一键讲解）。

// entry/src/main/ets/common/GuideAI.ets
import { http } from '@kit.NetworkKit';
import { AIConfig } from './AIConfig';

export class GuideAI {
  // 多轮对话：自动追加 system 提示词
  static async chat(history: ChatMessage[]): Promise<string> {
    const messages: ChatMessage[] = [
      { role: 'system', content: AIConfig.systemPrompt }
    ];
    for (const m of history) {
      messages.push(m);
    }
    return GuideAI.request(messages);
  }

  // 单句提问（景点一键讲解）
  static async ask(prompt: string): Promise<string> {
    return GuideAI.request([
      { role: 'system', content: AIConfig.systemPrompt },
      { role: 'user', content: prompt }
    ]);
  }

  // 统一请求入口
  private static async request(messages: ChatMessage[]): Promise<string> {
    const body: ChatRequest = {
      model: AIConfig.model,
      messages: messages,
      temperature: AIConfig.temperature,
      max_tokens: AIConfig.maxTokens
    };

    const client = http.createHttp();
    try {
      const resp = await client.request(AIConfig.endpoint, {
        method: http.RequestMethod.POST,
        header: {
          'Content-Type': 'application/json',
          'Authorization': 'Bearer ' + AIConfig.apiKey
        },
        extraData: JSON.stringify(body),
        connectTimeout: AIConfig.timeoutMs,
        readTimeout: AIConfig.timeoutMs
      });

      if (resp.responseCode !== 200) {
        return `（请求失败：${resp.responseCode}）请检查网络后重试。`;
      }
      const text = GuideAI.extractContent(`${resp.result}`);
      return text !== '' ? text : '（AI 暂时没有返回内容）';
    } catch (e) {
      return '（网络异常）请检查设备网络连接后重试。';
    } finally {
      client.destroy();
    }
  }
}

这套代码有几个关键设计：

① 使用鸿蒙官方网络 Kit。 @kit.NetworkKit 的 http 模块是 HarmonyOS 的标准网络能力，无需引入第三方库，轻量且稳定。

② 完善的错误处理。 网络异常、HTTP 错误码、空响应，都有兜底。面向真实用户的应用，健壮性是底线。

③ 资源及时释放。 finally 块中 client.destroy() 确保 HTTP 客户端用完即销毁，避免资源泄漏。

④ 响应解析。 蓝耘 MaaS 返回的是标准 OpenAI 格式，从 choices[0].message.content 中取出文本即可：

private static extractContent(raw: string): string {
  try {
    const obj = JSON.parse(raw) as Record<string, Object>;
    const choices = obj['choices'] as Object[];
    if (choices !== undefined && choices.length > 0) {
      const first = choices[0] as Record<string, Object>;
      const msg = first['message'] as Record<string, Object>;
      if (msg !== undefined && msg['content'] !== undefined) {
        return `${msg['content']}`.trim();
      }
    }
  } catch (e) { /* 解析失败返回空 */ }
  return '';
}

5.4 UI 层：多轮对话的状态管理

AI 导游页的核心是聊天 UI 和多轮对话状态管理。ArkUI 的声明式范式 + @State 响应式状态，让这件事变得优雅。

@Component
export struct AiTab {
  @State messages: Msg[] = [];
  @State input: string = '';
  @State sending: boolean = false;

  private async send(text: string): Promise<void> {
    const content = text.trim();
    if (content === '' || this.sending) return;

    this.sending = true;
    this.input = '';

    // 用户消息 + AI 占位消息（"正在讲解…"）
    this.messages = this.messages.concat([
      { role: 'user', content: content, pending: false }
    ]);
    this.messages = this.messages.concat([
      { role: 'assistant', content: '', pending: true }
    ]);
    this.scrollToBottom();

    try {
      // 组装历史，调用蓝耘 MaaS
      const history: ChatMessage[] = [];
      for (const m of this.messages) {
        if (!m.pending) {
          history.push({ role: m.role, content: m.content });
        }
      }
      const reply = await GuideAI.chat(history);

      // 替换占位消息为真实回复
      const idx = this.messages.length - 1;
      if (idx >= 0 && this.messages[idx].pending) {
        const updated = this.messages.slice();
        updated[idx] = { role: 'assistant', content: reply, pending: false };
        this.messages = updated;
      }
    } finally {
      this.sending = false;
      this.scrollToBottom();
    }
  }
}

这里的精髓在于**“占位消息"模式**：发送后立即插入一条 pending: true 的 AI 消息显示"正在讲解…”，等蓝耘 MaaS 返回后再原地替换为真实内容。这让用户获得即时反馈，体验上完全感觉不到网络延迟的"卡顿感"。

而多轮对话的实现，就是把历史消息（不含 system）原样传给 GuideAI.chat()，蓝耘 MaaS 的大模型会自动理解上下文——这就是为什么前面 AI 能记住"我们正在聊太和殿"，并自然地延续话题。

5.5 景点一键讲解的实现

景点讲解用了 ask() 单句模式，但提示词做了精心设计：

private async loadExplain(s: Spot): Promise<void> {
  this.panelTitle = s.icon + ' ' + s.name;
  this.panelLoading = true;
  this.showPanel = true;

  const prompt =
    `请为游客讲解故宫的「${s.name}」。景点简介：${s.desc}。` +
    '请介绍它的历史背景、建筑看点和游览贴士，150 字左右，语言生动易懂。';

  const reply = await GuideAI.ask(prompt);
  this.panelText = reply;
  this.panelLoading = false;
}

注意这段提示词工程：我把景点的名称和简介作为上下文喂给模型，并明确要求"历史背景 + 建筑看点 + 游览贴士"三段式结构、“150 字左右”、“语言生动易懂”。好的提示词，是把大模型能力精准引导到业务场景的关键。 这正是蓝耘 MaaS 这种标准化 API 的优势——你只需专注于设计好提示词，模型能力交给平台。

---

六、鸿蒙特性深度应用

除了 AI，这款应用还深度运用了多项 HarmonyOS 特性，让体验更上一层楼。

6.1 沉浸式全屏

应用启用了沉浸式全屏，让红金渐变的头图一路延伸到状态栏，视觉冲击力极强：

// EntryAbility.ets
onWindowStageCreate(windowStage: window.WindowStage): void {
  windowStage.getMainWindow().then((win) => {
    win.setWindowLayoutFullScreen(true);
    // 获取安全区高度
    const top = win.getWindowAvoidArea(
      window.AvoidAreaType.TYPE_SYSTEM).topRect;
    AppStorage.setOrCreate('safeTop', px2vp(top.height));
  });
}

6.2 安全区自适应

通过 @StorageProp 响应式读取安全区高度，各页面自动适配刘海屏、挖孔屏、导航条：

@StorageProp('safeTop') safeTop: number = 0;
@StorageProp('safeBottom') safeBottom: number = 0;

这就是为什么截图中应用顶部能完美避开状态栏、底部能避开导航条。

6.3 多端适配

module.json5 中声明了 deviceTypes: ["phone", "tablet", "2in1"]，理论上同一套代码可以直接跑到平板和 2in1 设备上。鸿蒙的"一次开发，多端部署"在这里体现得淋漓尽致——未来把这款应用搬到平板做更沉浸的故宫导览，几乎零成本。

---

七、蓝耘 MaaS 深度体验：一个开发者的真实感受

写到这里，我想停下来，认真地、完整地夸一夸蓝耘元生代 MaaS。因为这次实战，它给我的体验实在太好了。

7.1 接入之顺畅，超出预期

我必须坦诚地说：在开始这个项目之前，我已经做好了"踩坑"的心理准备。接大模型 API，在我的经验里往往意味着——文档翻半天、鉴权搞不定、参数格式对不上、报错信息看不懂。

但蓝耘 MaaS 彻底颠覆了我的预期。从拿到 API Key，到第一段 AI 讲解成功返回，我只花了不到十分钟。

为什么这么快？因为它用的是 OpenAI 兼容协议。我甚至不需要看蓝耘的文档——只要你会调 OpenAI，你就会调蓝耘。POST 一个 JSON 到 /v1/chat/completions，带上 Authorization: Bearer <key>，请求体里放 model 和 messages，完事。返回的也是标准格式，从 choices[0].message.content 取文本。

这种"零学习成本"的接入体验，是一个 MaaS 平台能给开发者的最大礼物。 它把创新的门槛降到了最低，让开发者可以把宝贵的时间和精力，全部投入到真正的业务创新上，而不是浪费在和 API 搏斗上。

7.2 模型之丰富，予取予求

再看蓝耘 MaaS 的模型广场——那真叫一个琳琅满目。Kimi-K3、GLM-5.3、DeepSeek 系列、Qwen 系列、MiniMax……国内外主流大模型齐聚一堂，文本生成、图像理解、多模态，各种能力一应俱全。

这意味着什么？意味着我不再被单一模型绑架。 我可以根据业务场景自由选择：需要深度推理的用 DeepSeek，需要长文本的用 Kimi，需要多模态的用 GLM。而且切换起来就是改一个 model 参数的事。

这种"模型自由"在以前是不可想象的。以前你想同时用几家模型，就得同时对接几家的私有 API、维护几套鉴权、写几套解析逻辑。现在，蓝耘 MaaS 用一个统一网关，把这一切都抹平了。

7.3 回答质量之高，令人惊喜

回到应用本身，蓝耘 MaaS 驱动的 AI 导游，回答质量真的让我惊喜。前面截图里的那些回答——太和殿的历史沿革、紫禁城的命名由来、结合国庆场景的游览贴士——无论是专业性、结构化程度，还是语言的生动性、人文关怀，都远超我的预期。

特别是它能理解上下文、结合实时场景。它知道现在是国庆黄金周，会主动提醒实名预约、限流参观、避开人流。这种"有场景感"的智能，是传统固定文案导览完全无法企及的。

这背后，是蓝耘 MaaS 上架的高质量大模型，以及平台对推理服务的精心调优。

7.4 成本之透明，用得安心

开发者最怕账单失控。蓝耘 MaaS 的用量统计后台做得非常清晰——每个模型的调用次数、Token 消耗、TPM/RPM、消费金额、最近调用时间，全部可视化呈现。

我这次实战调用了若干次 deepseek-v4-flash，Token 消耗清清楚楚，而且平台给了充足的体验额度，我一分钱没花就把整个应用跑通了。这种透明、可控、友好的计费模式，让开发者可以毫无顾虑地去尝试、去创新。

7.5 自主可控，面向未来

最后一点，也是非常重要的一点——自主可控。蓝耘 MaaS 上架了大量优秀的国产大模型。在当前国际环境下，使用自主可控的国产 AI 能力，不仅是技术选择，更是战略安全。不用担心海外 API 断供，不用担心数据合规风险。

对于要面向真实用户、要走长期路线的应用来说，这一点至关重要。

7.6 性能实测：低延迟带来的流畅体验

作为开发者，我最关心的除了"能不能用"，还有"快不快"。这次实战我特意留意了蓝耘 MaaS 的响应速度。

在我的「故宫 AI 导游」中，从用户点击发送到 AI 开始返回完整讲解，整个过程的等待感非常短。要知道，我用的还只是一次性返回完整结果的非流式调用——即便这样，蓝耘 MaaS 的推理速度也足够快，配合我设计的"占位消息"模式，用户几乎感觉不到明显的卡顿。

这背后，正是蓝耘自建 GPU 算力集群带来的底气。算力是自己的，调度就能做到极致；推理是自己优化的，延迟就能压到最低。 这和那些"转手套壳"的 MaaS 平台有着本质区别——后者的延迟和稳定性，受制于上游，自己根本说了不算。

如果用蓝耘 MaaS 的流式输出（streaming），体验还能更上一层楼——AI 的回答会像真人打字一样逐字呈现，等待感会进一步消失。这也是我后续迭代的方向。

7.7 那些打动我的细节

除了大的方面，蓝耘 MaaS 还有很多打动我的小细节：

• 错误提示清晰：调用出错时，返回的错误信息能明确指出问题所在，而不是一个让人摸不着头脑的"内部错误"。
• 文档即查即用：模型广场上每个模型的"API 示例"，复制下来改个 Key 就能跑，对新手极其友好。
• 额度提醒贴心：用量统计页能清楚看到剩余额度，不用担心不知不觉中欠费。
• 密钥管理规范：API Key 的创建、禁用、删除都很方便，还支持多 Key 管理，方便区分不同应用、不同环境。

这些细节单拎出来都不起眼，但正是这些细节的堆砌，构成了一个平台"用起来舒不舒服"的整体感受。蓝耘 MaaS 显然是用心在做产品的。

7.8 横向对比：为什么我最终留在了蓝耘

说实话，在选型时我也对比过其他几家 MaaS 平台。最后留在蓝耘，是基于这么几个综合判断：

对比维度	某些平台	蓝耘元生代 MaaS
接入协议	私有协议，需学习	OpenAI 兼容，零成本
模型数量	只有自家模型	多厂商模型统一接入
算力掌控	依赖第三方	自建 GPU 集群
切换模型	改代码换 SDK	改一个参数
计费透明度	不够直观	可视化用量统计
上手门槛	较高	十分钟跑通

这个对比不是说其他平台不好，而是说蓝耘 MaaS 在"开发者体验"这个维度上，确实做到了让我这种一线开发者感到舒服。 它没有给我设置任何不必要的障碍，而是想方设法让我更快地把想法变成产品。

7.9 一句话总结蓝耘 MaaS

蓝耘元生代 MaaS，是我用过的接入最顺畅、模型最丰富、体验最友好的大模型服务平台。它让"给应用装上 AI 大脑"这件事，变得像调用一个普通 HTTP 接口一样简单。如果你也想在鸿蒙（或任何平台）上快速构建 AI 应用，蓝耘 MaaS 是我毫无保留的推荐。

---

八、技术要点总结与最佳实践

经过这次完整的实战，我总结了一些在鸿蒙上接入大模型的最佳实践，供大家参考。

8.1 架构层面

• 配置与服务分离：API Key、端点、提示词集中到 AIConfig，调用逻辑收敛到 GuideAI，UI 层只负责展示。
• 提示词即代码：精心设计的 System Prompt 是把通用大模型变成垂直领域专家的关键，值得反复打磨。
• 模型可插拔：把 model 做成配置项，充分利用 MaaS 统一网关的模型自由。

8.2 体验层面

• 占位消息模式：发送即显示"正在讲解…"，消除等待焦虑。
• 自动滚动到底部：新消息到达后 scroller.scrollEdge(Edge.Bottom)。
• 快捷提问降门槛：预设高频问题，降低用户输入成本。
• 品牌适度露出：AI 能力来源（蓝耘 MaaS）要在合适位置展示，既是信任背书，也是对平台的尊重。

8.3 健壮性层面

• 完善的错误处理：网络异常、HTTP 错误、空响应都要有兜底文案。
• 资源及时释放：HTTP 客户端用完 destroy()。
• 超时控制：设置合理的 connect/read timeout，避免长时间无响应。

---

九、展望：AI + 鸿蒙 + 文旅的无限可能

这款「故宫 AI 导游」只是一个开始。蓝耘 MaaS + 鸿蒙的组合，打开了太多想象空间。

短期可以做的：

• 语音交互：接入鸿蒙的语音能力，把 AI 导游变成真正的"语音讲解员"，边走边听
• 多轮路线规划：让 AI 根据游客的时间、兴趣、体力，动态生成个性化游览路线
• 图像识别：拍照识别宫殿、文物，AI 实时讲解（蓝耘 MaaS 的多模态模型就能做）

中期可以拓展的：

• 复制到更多景区：这套架构是通用的，换成颐和园、天坛、兵马俑，只需换提示词和景点数据
• 多语言导览：让 AI 用英语、日语、韩语服务外国游客
• 分布式协同：利用鸿蒙分布式能力，手机提问、手表听讲解、平板看大图

长期的想象：

• 数字人导游：结合数字人技术，让"故宫 AI 导游"有形象、有声音、有表情
• 千人千面：根据每个游客的兴趣偏好，提供完全不同的讲解内容和路线

而这一切的底座，都是像蓝耘 MaaS 这样的大模型服务平台——它把最强大的 AI 能力，变成了人人可用的基础设施。

---

十、结语：这个国庆，技术有了温度

回到最初的那个场景：国庆的故宫，人山人海。但现在，每一位游客的手机里，都可以装着一个知识渊博、随叫随到、永不疲倦的 AI 导游。它懂历史、懂建筑、懂文物，还懂怎么帮你避开人流、拍出好照片。

这就是技术的意义——让文化更可及，让旅行更有深度，让六百年的紫禁城，真正"活"在每一个人的掌心。

而这一切的背后，是鸿蒙 HarmonyOS 提供的强大原生能力，是蓝耘元生代 MaaS 提供的澎湃 AI 动力。

这个国庆，我用代码给故宫装上了一个 AI 大脑。而你，也可以用蓝耘 MaaS，给你的创意装上翅膀。

大模型的时代已经到来，MaaS 让每个人都能站上巨人的肩膀。别犹豫，去接入蓝耘 MaaS，去创造属于你的 AI 应用吧。 下一个让人眼前一亮的产品，可能就出自你手。

蓝耘 MaaS 快速上手指引

如果你读完这篇文章也想试试蓝耘 MaaS，这里有一份最精简的上手路径：

1. 注册并领取额度：访问蓝耘元生代 MaaS 平台，注册账号，领取免费体验额度。
2. 创建 API Key：在控制台创建你的 API Key（形如 sk-xxxx）。
3. 挑选模型：到模型广场逛一圈，根据能力标签和上下文长度挑选合适的模型（通用对话推荐 deepseek-v4-flash 这类兼顾速度与效果的模型）。
4. 发起第一次调用：用你熟悉的任何语言/工具，向 https://maas-api.lanyun.net/v1/chat/completions 发一个 POST 请求：

curl https://maas-api.lanyun.net/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-你的KEY" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role": "user", "content": "你好"}]
  }'

5. 集成进你的应用：无论是鸿蒙 ArkTS、Android、iOS、Web 还是后端服务，只要能发 HTTP 请求，就能用上蓝耘 MaaS。
6. 监控与优化：在用量统计后台关注 Token 消耗和成本，根据需要调整模型和提示词。

从注册到第一次成功调用，顺利的话真的只需要十分钟。 这就是蓝耘 MaaS 的开发者友好度。

结合这次实战，我给打算用蓝耘 MaaS 的开发者几点建议：

• 善用系统提示词：不必微调模型，一段好的 System Prompt 就能让通用大模型变成垂直领域专家，成本极低。
• 先做非流式，再上流式：先用简单的非流式调用跑通逻辑，产品成熟后再升级流式输出优化体验。
• 多模型对比测试：利用统一网关的便利，对同一场景试试不同模型，选效果最好的。
• 盯紧用量统计：养成定期看用量统计的习惯，既能控制成本，也能从调用数据中洞察用户行为。
• 密钥别硬编码到生产环境：演示项目可以图省事，正式产品一定要把 Key 放到服务端或安全存储。

travel-planner/
├── entry/src/main/ets/
│   ├── common/Theme.ets          # 全局主题（故宫红金）
│   ├── common/AIConfig.ets       # 蓝耘 MaaS 配置
│   ├── common/GuideAI.ets        # 蓝耘 MaaS 服务层
│   ├── entryability/EntryAbility.ets  # 沉浸式全屏 + 安全区
│   └── pages/
│       ├── Index.ets             # 底部 3 Tab
│       ├── HomeTab.ets           # 首页（AI 入口 + 品牌）
│       ├── AiTab.ets             # AI 故宫导游（核心）
│       └── SpotsTab.ets          # 景点导览（AI 讲解弹层）
└── ...

---

Built with HarmonyOS ArkTS · Powered by 蓝耘元生代 MaaS

这个国庆，让 AI 带你读懂故宫。