当国庆黄金周遇上大模型：我用蓝耘元生代 MaaS + 鸿蒙，给 8 亿人装了一个"AI 行程规划师"

一边是国庆 8 天长假、人山人海的出行大潮；一边是鸿蒙原生应用 + 国产大模型的技术浪潮。这个国庆，我没有出门"添堵"，而是宅在家里，用 蓝耘元生代 MaaS 给鸿蒙应用装上了一颗会规划行程的 AI 大脑。这篇文章，是这次实战的完整记录。

引言：每年国庆，我们都在重复同样的"规划焦虑"

先问大家一个问题：每年国庆前，你是不是都要经历一次"规划焦虑"？

打开小红书、马蜂窝、携程，攻略铺天盖地，却又千篇一律——"国庆必去十大景点""北京 3 天 2 夜保姆级攻略"……点进去一看，要么是去年的旧闻，要么是软广，要么根本不考虑"国庆"这个特殊的时间变量：人流爆了、酒店涨了、高铁票没了。

更要命的是，每个人的需求都不一样：

• 带娃的家庭要"节奏慢、有午休、厕所多"
• 年轻人要"出片、小众、不走回头路"
• 预算有限的学生党要"省钱、高铁夕发朝至"
• 长辈出行要"少爬坡、有电梯、节奏缓"

没有一份通用攻略，能同时满足所有人。

作为一个开发者，也是鸿蒙生态的参与者，我一直在琢磨一个问题：能不能用大模型，给每一个人配一个"专属的黄金周行程规划师"？ 它懂国庆的客流规律、懂你的预算和偏好、能跟你多轮对话、实时生成真正可执行的方案。

这个国庆，我把这个想法落地了。我用 HarmonyOS（鸿蒙）ArkTS 开发了一款名为「国庆假期计划」的原生应用，而它的 AI 大脑，来自 蓝耘元生代 MaaS。

这篇文章，我想把整个过程完整地讲给你听——从为什么是蓝耘 MaaS、为什么是鸿蒙，到架构设计、核心代码、实战效果，再到我对蓝耘 MaaS 这个平台的深度体验和真心实意的推荐。全程硬核，干货密集，希望能给同样想在鸿蒙（或任何平台）上玩转大模型的你一些参考。

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

在讲应用之前，我必须先把这次实战的"头号功臣"请出来——蓝耘元生代 MaaS（Model as a Service，模型即服务）。毫不夸张地说，没有它，就没有这篇文章的诞生。

1.1 先搞懂：MaaS 到底解决了什么问题

咱们先把概念说透。假如你今天想在自己的应用里接入大模型能力，不走 MaaS，你要自己做什么？

• 买显卡、搭集群：动辄几十上百万的 GPU 投入，还要搞定机房、供电、散热、运维、容灾；
• 选模型、做部署：从开源社区挑一个模型，自己搭推理框架，处理量化、加速、显存优化；
• 写接口、保稳定：封装 API、做负载均衡、扛高并发、保证 SLA；
• 管成本、防失控：按 Token 计费像个黑盒，流量一上来账单可能瞬间失控。

这一整套下来，没有专业的 AI 团队和雄厚的资金，根本玩不转。大模型能力，成了少数大厂的"专利"。

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

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

1.2 认识蓝耘：从算力底层一路做上来的"实力派"

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

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

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

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

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

口说无凭，先上一张蓝耘 MaaS 控制台的模型广场截图，你一眼就能明白它的实力：

看到没有——这简直就是一个精心运营的"大模型超市"：

• 厂商云集：Kimi-K3、GLM-5.3、DeepSeek 系列（deepseek-v4.1-flash、deepseek-v4-flash）、Qwen 系列（qwen3.8-max、Qwen3.7-Plus）、MiniMax（MiniMax-H3、MiniMax-M2.5）……国内外主流大模型齐聚一堂；
• 分类清晰：左侧导航按"文本生成、图像理解、视频生成、多模态、语音合成、图生视频"等能力维度分门别类，还有厂商导航（DeepSeek、Kimi、智谱 AI、百度、阿里、MiniMax、科大讯飞……）；
• 信息完整：每个模型卡片都标注了能力标签、上下文长度（100K、256K……）、模型简介，一目了然；
• 开箱即用：每个模型都配有"API 示例"和"查看详情"按钮，点开就能看到调用方法和参数说明。

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

1.4 五大杀手锏：为什么我最终选择了蓝耘

市面上的 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 是一个统一的大模型网关。回看上面那张模型广场截图你就明白了——几十个国内外主流大模型，全部汇聚在同一个平台，用同一套 API 协议对外提供。

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

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

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

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

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

从截图可以看到，模型总量、调用总次数、Token 消耗数三个核心指标高亮展示，下方的模型列表里，每个模型的调用总次数、调用失败数、Token 消耗总量、最高 TPM、最高 RPM、预计消费金额、最近调用时间，全都一目了然。

我这次实战用的 deepseek-v4-flash，调用了若干次，Token 消耗清清楚楚，平台还给了充足的体验额度——这种透明、可控的计费体验，让开发者可以放心大胆地创新，而不用担心月底收到一张天价账单。

⑤ MCP 广场：面向未来的 AI 服务生态

更让我惊喜的是，蓝耘 MaaS 不止于"模型调用"，它还在构建一个更大的 AI 服务生态——MCP 广场（Model Context Protocol，模型上下文协议）：

MCP 是当前 AI 领域最火热的开放协议，它让大模型能够调用外部工具和数据源。蓝耘的 MCP 广场上架了海量的 MCP 服务：网易云音乐自动播放、图片视频生成、中国股票数据、Wireshark 网络分析、Elasticsearch、百度搜索、韩国旅游 API、YouTube 摘要、灯塔性能优化……左侧还能看到分类（网页与搜索、文件处理、可视化图表、数据库、云平台、学术研究、位置服务……）。

这意味着什么？意味着蓝耘 MaaS 不只是给你一个大模型，它在帮你连接整个 AI 工具生态。 未来我的「国庆行程助手」想要查实时天气、查股票、生成图片明信片、调用地图服务，都可以通过蓝耘的 MCP 广场一站搞定。这种前瞻性布局，让我看到了蓝耘的野心——它要做的不是一个简单的 API 中转站，而是大模型时代的 AI 服务操作系统。

1.5 一句话总结蓝耘 MaaS

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

二、为什么是鸿蒙 HarmonyOS？——AI 原生应用的最佳载体

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

2.1 鸿蒙 + AI，天作之合

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

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

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

第三，生态与未来。 鸿蒙生态正在高速扩张，手机、平板、2in1、车机、手表、智慧屏……一次开发，多端部署。 我的「国庆假期计划」未来可以无缝跑到平板上做更沉浸的行程规划，跑到手表上做语音问答，跑到车机上做自驾导航联动。

2.2 技术栈一览

三、应用设计：以 AI 为核心的国庆出行助手

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

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

3.1 产品定位

「国庆假期计划」——一款以蓝耘 MaaS 大模型为大脑的黄金周出行助手。它要解决的痛点非常清晰：让每一个出行者，都能拥有一个 7×24 小时在线、懂国庆客流规律、能陪你聊、会给你出主意的专属行程规划师。

3.2 功能架构

应用采用经典的底部三 Tab 结构，但每一个 Tab 都围绕"国庆出行"这个主题深度设计：

• 首页：假期速览（倒计时/调休/高峰提示）+ 热门目的地 + AI 引流入口；
• 行程：时间线式的示例行程（D1~D4），并引导用户去 AI 页生成专属方案；
• AI 助手（核心页）：完整的多轮对话，支持目的地推荐、行程规划、美食攻略、省钱技巧等，由蓝耘 MaaS 实时驱动。

整个应用的设计语言非常统一：故宫红 + 琉璃金的国庆配色，沉浸式头图，卡片式布局，处处透出"黄金周"的节日氛围。

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

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

4.1 首页：假期速览 + AI 引流

首页是用户对产品的第一印象。顶部是红金渐变的沉浸式头图——"🇨🇳 欢度国庆 · 黄金周"、"国庆假期计划"、"规划你的黄金周 · 错峰出行更尽兴"，还有一个大大的 🎆 烟花 emoji，节日氛围直接拉满。

头图下方那条半透明标签非常关键——"✨ 由蓝耘元生代 MaaS 提供 AI 智能规划"。我要让每一位用户第一眼就知道：这背后强大的 AI 能力，来自蓝耘 MaaS。

再往下是「假期速览」四宫格：假期总天数（8 天）、放假日期（10.1-10.8）、调休上班（10.9）、出行高峰（10.1-10.3）。然后是「国庆热门目的地」列表——北京、成都、西安、杭州、重庆、桂林，每个城市带热度标签（爆/热/中）和特色（故宫/长城、熊猫/美食、兵马俑/古城……）。

最底部是一条金色的「AI 提示横幅」——"🤖 不知道去哪玩？去「AI 助手」页，让蓝耘 MaaS 帮你定制专属国庆行程"，把用户自然引导到 AI 页。

4.2 行程页：时间线式的示例计划

行程页采用时间线设计，D1~D4 四天，每天一个主题：出发·抵达、核心景点、自然休闲、美食购物。左侧是带图标的圆形节点 + 竖向连接线，右侧是内容卡片，列出"上午/下午/晚上"的具体安排。

注意页面顶部那条红色提示卡——"💡 以下为示例行程，可前往「AI 助手」页输入目的地，让蓝耘 MaaS 为你生成专属计划"。这里的设计哲学是：静态示例只是"引子"，真正的价值在 AI 动态生成。 我再次把用户引导向蓝耘 MaaS。

4.3 AI 助手页：多轮对话的核心战场

这才是整个应用的灵魂。打开 AI 助手页，首先是一段由蓝耘 MaaS 驱动的欢迎语：

注意顶部那条深红色的品牌横幅——"蓝耘元生代 MaaS · deepseek-v4-flash · OpenAI 兼容 · 统一网关"，右侧还有"已接入"的状态徽标。这是对蓝耘 MaaS 最直接、最高频的品牌露出。下方是快捷提问区："🗺️ 国庆去哪玩人少景美？""🏛️ 帮我规划北京3天行程""🍜 成都美食攻略""💰 国庆出行怎么省钱？"——预设高频问题，降低用户的提问门槛。

实战对话一：国庆去哪玩人少景美？

我点击快捷提问"国庆去哪玩人少景美？"，蓝耘 MaaS 立刻返回了一份让我拍案叫绝的方案：

来看这段回答的质量——它没有泛泛而谈，而是精准抓住了"国庆"和"人少景美"这两个核心矛盾，给出了一个"小众 + 错峰"的黄金组合。注意看它的排版（这正是我后面要讲的 Markdown 渲染的功劳）：

• "方案一：广西崇左/靖西（边境山水秘境）" 作为加粗标题醒目呈现；
• 推荐理由直接上数据："被誉为'广西的喀纳斯'，游客量仅为桂林的 1/5，国庆期间仍能悠哉游走"；
• 线路安排（5天） 用无序列表逐天拆解：
  • Day1：高铁至南宁，打车/拼车 1.5 小时抵崇左德天，入住明仕田园民宿（提前 7 天订，周边稻田比景区内更出片）；
  • Day2（核心）：早上 7:30 起床，8:00 进德天瀑布景区（避开 10 点后的旅行团，清晨光线柔和且人少），下午骑单车逛明仕田园；
  • Day3：包车去靖西鹅泉（看晨雾下田螺倒影），下午游通灵大峡谷（地下暗河清凉）；
• 避坑提示：别买套票，现场单买德天门票即可，摆渡车可步行替代。

这份回答的专业度，已经远超一般的攻略帖子。 它不只是告诉你"去哪"，而是告诉你"几点起床、几点进景区、为什么"——这种具体到小时的可执行性，正是大模型相比静态攻略的降维打击。

实战对话二：核心建议（上下文理解 + 结构化列表）

更让我惊喜的还在后面。当我继续往下翻，AI 在给出方案后，主动补了一段"我的核心建议（国庆避峰实操）"：

看这段——它用有序列表给出了三条极具实操价值的建议，而且完全结合了国庆黄金周的实时场景：

1. 出行日期：国庆期间游客高峰在 10 月 1 日–3 日；最建议你 9 月 30 日或 10 月 4 日 出发，最后两天预留返程缓冲。
2. 住宿：以上三个地方的民宿/酒店，今天就下单！锁定"可免费取消"房型，9 月 20 日后再比价。
3. 交通：放弃热门高铁直达，上述方案均优先选择"高铁大站 + 地面拼车"模式，别看 36 小时，绝对比在热门景区排 3 小时队值。

这三条建议，条条都是"老司机"级别的经验之谈——它知道国庆的高峰是 1-3 号、知道要订"可免费取消"的房型、知道"高铁大站+拼车"比直达更靠谱。这正是大模型相比传统固定文案攻略的核心优势：它能理解上下文，能结合场景生成真正有用的内容。

最后它还非常贴心地收尾："你想看更多具体哪个方向的细节？或者把出发城市告诉我，我帮你核对车票方案！"——这种拟人化的引导，让对话体验非常自然。

实战对话三：AI 的"思考"加载态

当我点击"帮我规划北京3天行程"后，应用会先显示一个加载态：

看左下角——"正在思考 🔄"，配了一个转圈的 LoadingProgress 组件。这是我特意设计的"即时反馈"机制：用户发送后立刻看到"AI 正在思考"，等蓝耘 MaaS 返回后再原地替换为真实内容。这让用户完全感觉不到网络延迟的"卡顿感"，体验非常流畅。

整个对话过程中，用户消息是右侧红色气泡，AI 消息是左侧白色卡片 + 机器人头像 + "规划师 · 蓝耘 MaaS"的小标签——品牌露出无处不在，却又恰到好处。

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

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

5.1 整体架构

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

┌─────────────────────────────────────┐
│   UI 层（AiTab / HomeTab / PlanTab）  │  ArkUI 声明式界面
├─────────────────────────────────────┤
│   服务层（HolidayAI / AIConfig）      │  蓝耘 MaaS 调用封装
├─────────────────────────────────────┤
│   蓝耘元生代 MaaS 统一网关            │  maas-api.lanyun.net
└─────────────────────────────────────┘

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-xxxxxxxx';

  /** 模型标识（deepseek-v4-flash 通用首选） */
  static readonly model: string = 'deepseek-v4-flash';

  /** 系统提示词：把模型约束为"国庆行程规划师"身份 */
  static readonly systemPrompt: string =
    '你是"国庆假期规划师"，一位专业的黄金周旅行与行程规划助手。' +
    '你熟悉国庆出行高峰规律、热门城市/景点推荐、交通住宿预订技巧、' +
    '美食攻略与避坑指南。请用简洁、友好、可执行的中文回答用户的问题。' +
    '给出建议时尽量具体到天/小时，并考虑节假日客流与提前预订。';

  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）的典型应用——不需要微调模型，只需一段好的提示词，就能让模型进入特定角色。 前面 AI 能给出那么专业的避峰建议，这段提示词功不可没。

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

5.3 服务层：HolidayAI —— 多轮对话的封装

服务层封装了对蓝耘 MaaS 的所有调用。核心是一个 chat() 方法，用于多轮对话。

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

export class HolidayAI {
  /** 多轮对话：自动追加 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 HolidayAI.request(messages);
  }

  /** 统一请求入口 */
  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 = HolidayAI.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 HolidayAI.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）原样传给 HolidayAI.chat()，蓝耘 MaaS 的大模型会自动理解上下文——这就是为什么 AI 能在你追问"那住宿呢"时，记得"我们正在聊北京 3 天行程"。

5.5 点睛之笔：自研 Markdown 渲染器

这是我最想单独拿出来说的一个亮点。

起初，AI 返回的内容是整段纯文本，直接塞进一个 Text 组件里。问题来了——大模型为了让回答结构清晰，会返回 ## 标题、**加粗**、- 列表、1. 有序 这样的 Markdown 标记。直接渲染的结果就是一堆原始符号，又丑又难读。

为了让 AI 的回答"好看"，我手写了一个轻量级 Markdown 渲染器（MdText 组件），把 AI 返回的 Markdown 文本解析成结构化的 ArkUI 组件：

核心思路是两步解析：先把整段文本按行解析成"标题/列表/引用/段落"等结构化行，再把每行按 ** 拆成"普通/加粗"片段：

// 把一行按 **加粗** 拆成片段
function parseSpans(text: string): Span[] {
  const out: Span[] = [];
  let rest: string = text;
  let bold: boolean = false;
  while (rest.length > 0) {
    const idx: number = rest.indexOf('**');
    if (idx < 0) { out.push({ text: rest, bold: bold }); break; }
    if (idx > 0) { out.push({ text: rest.substring(0, idx), bold: bold }); }
    bold = !bold;
    rest = rest.substring(idx + 2);
  }
  return out.filter((s: Span) => s.text.length > 0);
}

前面截图里那些赏心悦目的排版——"方案一：广西崇左/靖西"的加粗标题、"Day1/Day2/Day3"的金色圆点列表、"1/2/3"的红色序号建议——全都是这个渲染器的功劳。正是它，让蓝耘 MaaS 返回的高质量内容，以最优雅的方式呈现在用户眼前。

六、蓝耘 MaaS 深度体验：一个开发者的真心话

写到这里，我想停下来，认真地、完整地夸一夸蓝耘元生代 MaaS。因为这次实战，它给我的体验实在太好了，好到我觉得不单独用一章来夸，都对不起它。

6.1 接入之顺畅，超出预期

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

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

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

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

6.2 模型之丰富，予取予求

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

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

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

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

回到应用本身，蓝耘 MaaS 驱动的 AI 行程规划师，回答质量真的让我惊喜。前面截图里的那些回答——广西崇左的小众秘境、具体到天/小时的线路、结合国庆场景的避峰建议——无论是专业性、结构化程度，还是语言的生动性、可执行性，都远超我的预期。

特别是它能理解上下文、结合实时场景。它知道现在是国庆黄金周，会主动提醒避开 1-3 号高峰、订"可免费取消"的房型、用"高铁大站+拼车"模式。这种"有场景感"的智能，是传统固定文案攻略完全无法企及的。

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

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

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

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

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

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

6.5 成本之透明，用得安心

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

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

6.6 自主可控，面向未来

最后一点，也是非常重要的一点——自主可控。蓝耘 MaaS 上架了大量优秀的国产大模型。在当前国际环境下，使用自主可控的国产 AI 能力，不仅是技术选择，更是战略安全。不用担心海外 API 断供，不用担心数据合规风险。对于要面向真实用户、要走长期路线的应用来说，这一点至关重要。

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

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

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

6.8 一句话总结蓝耘 MaaS

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

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

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

7.1 架构层面

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

7.2 体验层面

• 占位消息模式：发送即显示"正在思考…"，消除等待焦虑。
• Markdown 渲染：AI 返回的结构化内容，一定要用渲染器呈现，而不是塞原始文本。
• 自动滚动到底部：新消息到达后 scroller.scrollEdge(Edge.Bottom)。
• 快捷提问降门槛：预设高频问题，降低用户输入成本。
• 品牌适度露出：AI 能力来源（蓝耘 MaaS）要在合适位置展示，既是信任背书，也是对平台的尊重。

7.3 健壮性层面

• 完善的错误处理：网络异常、HTTP 错误、空响应都要有兜底文案。
• 资源及时释放：HTTP 客户端用完 destroy()。
• 超时控制：设置合理的 connect/read timeout，避免长时间无响应。
• 密钥安全：演示项目可以硬编码 Key 图省事，正式产品一定要把 Key 放到服务端或安全存储。

八、展望：AI + 鸿蒙 + 出行的无限可能

这款「国庆假期计划」只是一个开始。蓝耘 MaaS + 鸿蒙的组合，打开了太多想象空间。

短期可以做的：

• 语音交互：接入鸿蒙的语音能力，把 AI 规划师变成真正的"语音助手"，开车、做饭时也能问；
• 流式输出：升级蓝耘 MaaS 的 streaming 调用，让 AI 回答像真人打字一样逐字呈现；
• 行程导出：把 AI 生成的方案一键导出为图片或日历提醒。

中期可以拓展的：

• 接入 MCP 服务：通过蓝耘 MCP 广场调用实时天气、股票、地图、图片生成等能力，让行程"活"起来；
• 复制到更多场景：这套架构是通用的，换成"春节回家""五一出游""周末遛娃"，只需换提示词；
• 多语言服务：让 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": "你好"}]
  }'

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

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

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

• 善用系统提示词：不必微调模型，一段好的 System Prompt 就能让通用大模型变成垂直领域专家，成本极低；
• 先做非流式，再上流式：先用简单的非流式调用跑通逻辑，产品成熟后再升级流式输出优化体验；
• 多模型对比测试：利用统一网关的便利，对同一场景试试不同模型，选效果最好的；
• 盯紧用量统计：养成定期看用量统计的习惯，既能控制成本，也能从调用数据中洞察用户行为；
• 探索 MCP 广场：别只盯着对话，去 MCP 广场逛逛，你会发现大模型能做的事情远比你想象的多。