国庆黄金周还没到，朋友圈里已经有人在凌晨三点抢高铁票了。等下，高铁票固然难抢，但比抢票更让人头疼的是另一件事：去哪、怎么玩、每天怎么安排。即便你终于定好了目的地，打开手机刷到的攻略往往是"成都三天两晚攻略""重庆主城暴走路线"，刷了二十篇收藏了十个精华帖，最后打开地图还是不知道从哪里出发。信息过载带来的选择焦虑，比没得选更折磨人。

我这次国庆前做了一个小东西：基于蓝耘元生代 MaaS 平台接入大模型，前端用鸿蒙原生应用搭建，给出行人群做了一个 AI 行程规划师。用户只需要输入目的地、出行天数、人数、预算和偏好，十秒内就能拿到一份按天、按小时排好的完整行程方案，包含景点衔接、交通用时、餐厅推荐和备选预案。这篇文章不聊愿景，只讲落地，从选型、架构、提示词设计到鸿蒙端开发、成本控制、上架审核，一条链路上的经验和坑都写出来。

1. 一个出行规划工具，为什么非要接入大模型

1.1 国庆出行的信息过载，用传统工具解决到什么程度

先还原一下真实场景：假设你要在国庆期间带父母去成都玩四天。传统做法是打开各种攻略平台，搜"成都 4 天3晚 攻略"，你会得到几十篇内容高度同质化的笔记，有的推宽窄巷子，有的推大熊猫基地，有的推都江堰青城山一日游。问题是这些攻略默认你住在春熙路、默认你是年轻人、默认你能一天走两万步。

把这些攻略手工整合成一份自己的行程，通常要花掉两个晚上。而且整合完了还不一定合理：景点之间有多远？地铁要坐多久？中午吃饭的地方和下午的景点顺不顺路？这些信息分散在不同 App 里，没有谁能一次性回答你。

传统规划工具也不是没有。地图 App 能做路线规划，但它的强项是"从 A 到 B"，不是"四天三晚整体怎么安排"；OTA 平台能订酒店机票，但行程编排仍然靠人工；一些内容平台有"行程助手"功能，也只是把别人的攻略模板化套用，个性化程度很低。

所以核心矛盾是： 用户的需求是一个多约束下的组合优化问题——时间、预算、体力、偏好、交通、开放时间、人流密度，全部要在同一个方案里被满足。 而传统工具擅长解决单点约束，不擅长处理全局组合。

1.2 大模型补上的关键一环：把约束变成可执行方案

大模型在这里补上的关键能力，不是"知道宽窄巷子怎么走"，而是 理解自然语言表达的约束集，并把这些约束转换成一个结构化的执行方案 。

比如用户说"带爸妈，别太累，每天最多两个大景点"，大模型能理解"带爸妈"意味着节奏要慢、午饭时间要正常、休息时间要预留；"别太累"意味着不能像特种兵旅行那样暴走，景点之间要有缓冲；"每天最多两个大景点"是一个显式约束，必须被编码进输出。

这种能力，是之前的规则引擎和模板系统很难做到的。你当然可以用 if-else 写一个行程生成器，但你会被无穷无尽的特例淹没：下雨了怎么办？周一博物馆闭馆怎么办？这个景点排队两小时值不值得？大模型至少能把常识性推理引入到规划过程里。

我选择的实现路径是：用户输入需求，服务端通过大模型生成结构化的行程 JSON，鸿蒙客户端负责展示和交互。整个链路里，大模型是"规划大脑"，鸿蒙应用是"肢体和界面"。这两者配合好，体验上限非常高。

2. 技术选型：MaaS 平台 + 鸿蒙这套组合是怎么定下来的

2.1 自建模型、公有 API、MaaS 平台，我最后选了哪条路

接入大模型有三种主流路径，我逐一对比过：

方案	优点	缺点	适合场景
自建 GPU 集群 + 开源模型	数据不出内网、可控性最强	硬件成本高、运维复杂、模型调优耗时	有专业 AI 团队和稳定算力预算的大厂
直接调公有云大模型 API	接入快、效果有保障	需要自己管理密钥、限流策略、模型版本切换	原型验证、个人项目、中小应用
通过 MaaS 平台接入	提供完整模型服务和配套工具，无需关心底层 GPU 调度，通常支持模型热切换、监控、流式接口	依赖平台稳定性和定价策略	大多数希望快速产品化的项目

我最终选了蓝耘元生代 MaaS，原因很实际：

第一， 我不需要关心 GPU 集群的调度和运维 。自己租显卡部署模型，听起来自由，但实际上要处理驱动、显存、并发队列、模型热加载一堆问题，国庆前两周的时间根本不够折腾。

第二， MaaS 平台天然适合做产品验证 。它把大模型的调用封装成 API，我可以把精力聚焦在提示词和产品逻辑上，而不是模型部署。

第三， 模型可替换性 。MaaS 平台通常提供多个模型供选择，如果发现某个模型在行程规划场景效果不佳，或者其他模型更新了，通过改配置就能切换，不需要改业务代码。

很多人会担心用 MaaS 平台会不会被"卡脖子"或者成本不可控。我实测下来，MaaS 按量计费的特性反而更适合这种工具类应用：没有流量的时候成本趋于零，高峰期并发上来才线性增加，对个人开发者友好。

2.2 客户端选鸿蒙，不只是一次情怀投票

客户端技术栈的选择，我考虑过三种方案：

• 跨平台框架 ：比如 Flutter、React Native，一套代码多端复用，开发效率高，但打包体积偏大，需要依赖多端兼容桥接层。
• 纯 Web/H5 ：开发最快，但用户体验、系统能力调用（比如推送、卡片、分布式流转）受限。
• 鸿蒙原生应用 ：使用 ArkTS 语言和 ArkUI 框架，编译性能好，能使用鸿蒙的系统能力和生态接口。

我最终选鸿蒙原生，关键驱动因素有四个：

一是 鸿蒙设备的覆盖面 。随着鸿蒙操作系统在大屏、平板、折叠屏和车机上的铺开，同一个应用可以天然适配多设备形态，行程规划这种场景在手机上看是时间轴，在平板上看是双栏地图+列表，在车机上可以流转成天气和导航卡片。

二是 卡片服务 。鸿蒙的服务卡片能力很值得利用——把用户下一站的行程、导航入口直接放到桌面上，不需要打开 App 查看。

三是 应用市场分发 。鸿蒙有自己的应用市场生态，行程规划工具在这个生态里没有特别强势的竞品，对于新上架的应用有流量扶持机会。

四是 开发语言本身 。ArkTS 是基于 TypeScript 扩展的，如果你熟悉 TS，上手几乎没有心理负担。ArkUI 声明式 UI 的写法，和 SwiftUI、Flutter 的声明式语法逻辑上很接近，有 App 开发经验的人自适应得很快。

2.3 整体架构与数据流

整体架构分四层：

• 客户端层 ：鸿蒙原生 App，负责需求采集、行程展示、对话调整、缓存复用。
• 轻量服务层 ：我自建的一个极简网关，负责鉴权、限流、提示词组装、请求转发，以及缓存逻辑。为什么必须加这一层，后面会重点解释。
• MaaS 层 ：蓝耘元生代 MaaS 的模型服务，接收服务端转发的请求，返回结构化输出。
• 数据支撑层 ：静态的 POI 信息、节假日特殊运营时间等作为提示词的上下文注入。

数据流大概是：用户在鸿蒙 App 上输入需求→App 将需求发送到我的服务网关→网关组装提示词并调用蓝耘元生代 MaaS 的 API→模型返回结构化 JSON→网关校验后回传给 App→App 渲染成时间轴和地图。整个链路如果优化得当，从用户点击"生成"到看到第一个字，应该在 2-3 秒内。

3. 行程规划师的功能设计：从"国庆想去成都"到结构化行程 JSON

3.1 用户侧的功能栈

我没有做很复杂的界面，核心就三步：输入需求、生成行程、调整行程。

输入需求页包含了这几个字段：

• 目的地（自由输入城市或景点）
• 出行天数（1-7 天）
• 同行人（一个人/情侣/带父母/带娃，每一种对应不同的节奏系数）
• 预算档位（经济/舒适/轻奢）
• 兴趣偏好（美食、历史文化、自然风光、亲子、网红打卡）
• 特殊要求（比如"不排网红店""每天下午要留出休息时间""避开周一闭馆的博物馆"）

这些字段会直接映射到提示词里的约束向量。用户填得越细，生成方案越有针对性，但我也预留了"懒得填"的兜底逻辑——只填目的地和天数，其他用默认值。

输出侧是一个按天分组的行程卡片：

• 每天分为上午、下午、晚上三个时间段
• 每个时间段包含：景点/餐厅名称、地址、预计停留时间、交通方式与时长
• 每天末尾有"今日提示"：比如预约哪个场馆、是否需要早出发、备选景点是什么
• 整个方案的地图落点可以调用地图 SDK 展示

调整行程是最体现大模型价值的环节。用户可以直接说"第二天下午改到武侯祠""第三天别安排太满""把第一天晚上的火锅换成川剧表演"，系统会保留之前的约束，重新生成受影响的部分。

3.2 提示词模板与数据模型的设计

大模型输出的质量，一半靠基础模型能力，一半靠提示词和结构化约束。我用的提示词模板可以简化成几段：

你是一位熟悉国内热门旅行城市的行程规划专家。
请根据以下需求输出一个完整的行程方案：
- 目的地: {destination}
- 天数: {days}
- 同行人特征: {companion_type}
- 预算档位: {budget_level}
- 兴趣偏好: {interests}
- 特殊要求: {constraints}

要求：
1. 使用JSON格式输出，不要输出任何解释文字。
2. 每天按上午/下午/晚上三个时段规划，每个时段只能安排一个主地点。
3. 行程必须考虑地点之间的实际交通时间，晚间21点后不安排新活动。
4. 每个景点给出建议停留时间，单位分钟。
5. 如同行人是老人或小孩，每天步行总时长不超过3小时。

为了让模型输出稳定的结构化数据，我定义了严格的数据模型，可以用 TypeScript 接口来描述：

interface TripPlan {
  destination: string;
  days: DayPlan[];
  notes: string[];        // 全局提示，比如交通卡、天气提醒
}

interface DayPlan {
  dayIndex: number;
  date: string;
  daytime: string;          // 上午 / 下午 / 晚上
  summary: string;          // 当天节奏的一句话描述
  items: ActivityItem[];
}

interface ActivityItem {
  type: string;             // scenic / restaurant / theater / rest
  name: string;
  timeStart: string;        // "09:30"
  durationMin: number;
  address: string;
  transport?: {
    mode: string;           // subway / taxi / walk
    minutes: number;
  };
  notes?: string;
}

有了这个 JSON schema，客户端渲染就非常简单了——不需要理解自然语言，直接把 JSON 映射成 UI 组件即可。同时，这个 schema 也方便服务端做效果校验。

3.3 让模型先"想"再"写"：载荷与约束分离

这里有一个非常重要的实操经验： 不要把用户的需求一个劲儿塞进提示词里，也不要指望模型一上来就输出完美方案。

我采用的方法是"载荷与约束分离"。

"载荷"指用户的显式输入，比如目的地、天数、预算、偏好，这部分 1:1 放入提示词。"约束"指你希望模型遵循的规则和常识，比如交通时间衔接、开放时间、人群密度等，这部分写进系统提示词（system message），而不是用户请求里。

为什么要分离？因为用户输入是动态的，而约束规则相对稳定。如果约束和载荷混在一起，你每次都要在组装提示词时把所有规则重新拼接一遍，既容易出错，又浪费 token。更好的做法是： 系统提示词里固化规则，用户输入只放业务变量。

另一个技巧是给模型一个"思考空间"。如果直接要求模型输出最终 JSON，它偶尔会忽略某些约束。我让模型先生成一段极简的"规划说明"，再输出 JSON。这颗"思考按钮"非常有效，生成质量能肉眼可见地提升，后面我会细说。

4. 蓝耘元生代 MaaS 接入实战：提示词、结构化输出与流式响应

4.1 申请账号、创建应用、拿到密钥之后

在蓝耘元生代 MaaS 平台上的流程不复杂：注册账号、创建应用、开通模型服务、拿到一组 API Key。拿到 Key 之后，建议先把简单的对话接口跑通，确认网络连通性和返回格式，再进入提示词迭代阶段。

这里要插一句安全提醒： API Key 绝不能写死在鸿蒙客户端里。 客户端一旦上线，任何人都能反编译拿到你的 Key，等于别人拿着你的账单随便调模型。所以我在前面提到的那层轻量网关服务是必须的，Key 只存在于服务端。

第二个建议是： 在平台侧开通监控告警 ，至少要看调用量、错误率、平均响应时长三个指标。MaaS 平台基本都会提供调用日志和监控面板，不要等到线上用户投诉了才去查问题。

4.2 提示词构造的三种技巧

提示词工程是这个项目的核心环节。我用到的三种技巧，对行程规划这类强结构化生成任务都适用。

技巧一：给模型一个"规划草稿区"。 前面提到，不要直接让模型输出 JSON，而是让它先在内部"想"。实现方法是在提示词里增加一步引导：

步骤1：分析用户的约束条件，列出影响行程安排的关键因素，不超过5条。
步骤2：基于这些因素，先写一段文字版本的行程草案。
步骤3：将草案转换为你定义好的JSON schema，只输出JSON。

实测这个方法能让模型更稳定地遵守约束，因为分析过程会强化它对约束的注意。

技巧二：注入少量示例（Few-shot）。 我准备了两个示例：一个是一日游的紧凑安排，一个是带爸妈的慢节奏安排。每个示例都配上一段对应的 JSON 输出。模型需要模仿的不是内容，而是结构。你给它看了一个好的 JSON 长什么样，它还给你一个更规整的 JSON。

技巧三：温度参数设置。 行程规划需要稳定性和逻辑性，不是创意写作。我把 temperature 调到 0.2-0.4，这个区间既能保留一定多样性（比如同样是成都，两次生成的餐厅可以不一样），又不容易跑偏成天马行空的建议。

4.3 流式输出的落地细节

用户点击"生成行程"后，最怕的是等待。如果一次请求要等 10-15 秒才完整返回，体验会很差。解决手段是流式输出（SSE）。

MaaS 平台的流式接口一般支持增量返回 token，客户端可以逐字展示"正在规划"的过程，这一步很重要—— 用户看到不断涌出的文字，等待焦虑会显著降低。

在鸿蒙端接收 SSE 流的实现并不复杂，核心是对 HTTP 响应的流式读取。你要注意几个细节：

• 必须用异步 Read 循环读取数据块 ，而不是等整个 Response 结束再解析。
• 数据块是分片到达的 ，边界不一定对齐一次完整的 JSON，所以要在缓冲层处理"半截 JSON"。
• 需要做心跳和超时检测 ，长时间没有新 token 返回，要考虑重试还是提示用户"规划较慢"。

鸿蒙的网络请求基于 @ohos.net.http ，流式读取时需要持续读取 buffer。服务端返回格式通常是 data: {...}\n\n ，每次读到 \n\n 就可以解析一次增量数据，并更新 UI。

4.4 成本账本：一次完整规划花多少钱

接入 MaaS 之后，最现实的问题就是成本。我做了个简单的统计：

项目	预估 token 消耗	备注
系统提示词 + 示例	800-1200 tokens	每次请求都固定消耗
用户需求描述	50-300 tokens	取决于用户填写细致程度
模型输出（完整行程 JSON）	1200-2500 tokens	7 天行程通常更长
一次调整请求	400-900 tokens	只生成变更部分

一次完整规划的总成本在 2000-4000 tokens 量级。按平台的定价粗略折算，单次行程规划的模型成本大约在几分钱到一毛钱级别。这个成本对于个人工具类应用完全可接受，但如果不做缓存，流量一大还是会心疼，后面我会专门讲缓存怎么设计。

5. 鸿蒙端落地：ArkTS 页面、SSE 解析与多设备适配

5.1 页面架构与状态管理

鸿蒙端的页面结构我拆成了四层：

• 首页 ：表单输入 + 历史行程入口
• 生成页 ：展示流式生成过程，可中途停止
• 行程主页 ：按天 Tabs 切换，顶部是每日摘要，下面是时间轴卡片
• 对话调整页 ：输入调整指令，底部是对话气泡

状态管理方面， @Observed 和 @ObjectLink 的组合可以很好地处理行程数据。行程 JSON 解析成一个 TripPlanModel 实例，标注为 @Observed ；页面上的组件通过 @ObjectLink 订阅。当服务端返回新的行程版本，只需要更新这个模型，整个页面自动刷新。

ArkTS 的声明式写法类似 SwiftUI，页面结构是组件树。行程卡片我拆成了 DayCard 、 ActivityItemView 、 TransportBadge 等小组件，上层通过数据绑定自动联动，新增一个字段类型只需要改对应的子组件。

5.2 网络层如何对接 SSE 流

这里我把客户端网络层的核心思想写一下。使用 ArkTS 的 @ohos.net.http ，你需要创建一个 HttpRequest ，然后以流式读取方式持续获取增量数据：

import { http } from '@kit.NetworkKit';

let request = http.createHttp();
request.request('https://your-gateway.example.com/trip/plan', {
    method: http.RequestMethod.POST,
    header: {
        'Content-Type': 'application/json',
        'Authorization': 'Bearer ' + this.getClientToken()
    },
    expectDataType: http.HttpDataType.STRING,
    usingCache: false
}).then((response) => {
    // response.result 在流式下需要按块处理
    // 每次读到新的 data: 块，触发 onChunk 回调
    this.handleSSEBuffer(response.result);
}).catch((err) => {
    console.error('request error', JSON.stringify(err));
});

严格来说，鸿蒙的同步 API 是一次性拿到完整响应的，要实现真正的流式效果，通常的做法是拿到完整的 response.result 后，在 UI 层面按 token 模拟打字机效果，或者使用支持流式回调的底层 socket 封装。我的方案是折中：网关先把完整响应缓存好，客户端拿到后逐段展示"正在生成"的动画伴随真实数据的渐进渲染，最大程度模拟流式体验，同时降低实现复杂度。

在服务端，真正的流式转发是能做的。如果你的网关能接手 SSE 流并转发给鸿蒙端，鸿蒙端再逐字读取，那就是真正的流式。这个方案对网关代码有要求，但实现收益很明显，国庆高峰期的长时间等待场景建议做。

5.3 服务卡片与多设备适配

这次上架的版本里，我做了一个轻量服务卡片：把"今日行程"的前三个景点固定在桌面卡片上，用户锁屏或回到桌面就能看到下一步该去哪。卡片数据来自本地缓存的当日行程 JSON，不额外调用模型，所以没有延迟和额外成本。

多设备适配方面，我重点适配了三类形态：

• 手机（竖屏） ：时间轴单列向下滚动。
• 平板/折叠屏（横屏） ：左侧显示当天的景点列表，右侧是地图和天气信息，使用 GridRow 做栅格布局。
• 车机 ：目前只做了一个极简的"下一站导航"卡片，通过鸿蒙的分布式流转将手机上的行程卡片流转到大屏显示。

如果你时间有限，建议优先保证手机和平板的布局，车机场景后续迭代。

6. 在性能与成本之间做取舍：并发、缓存和 Token 账本

6.1 缓存层：相似请求合并，拿缓存挡流量

大模型调用不是免费的，也不是无限的。如果要面对国庆这种流量波峰，最理智的做法是： 让绝大多数请求在缓存层被拦下，真正到达大模型的请求只是一小部分。

我设计了三级缓存：

1. 内存缓存 ：同一用户短时间内的重复请求，直接返回上一次的行程结果。
2. Redis 缓存 ：以"需求关键特征的哈希值"作为 Key。比如"成都-4天-2人-舒适-美食"会被编码成一个 32 位哈希，第二次有人提交相同的需求，直接命中缓存。
3. 静态热门方案 ：对于成都、北京、西安等热门目的地的典型玩法，预先离线生成几十套标准行程，存成静态 JSON，作为兜底方案。

实测中，三级缓存可以拦截接近 60% 的重复请求。尤其国庆期间，大批用户输入"成都三天两晚""北京四天三晚"，需求高度相似，缓存命中率会非常高。

6.2 并发与限流：不等同于简单加机器

行程规划这个场景有个特点：上游大模型接口有并发上限。如果你的请求同时涌进来几百个，超过了 MaaS 平台的配额，就会触发限流或报错。

我在网关层做了两个处理：

• 令牌桶限流 ：控制每秒发往 MaaS 的最大请求数，比如 10 QPS。超出部分的请求进入等待队列，而不是直接打到模型服务。
• 优先级队列 ：实时交互的"调整行程"请求比"首次生成"请求优先级更高。因为用户已经在等结果了，久等体验差；首次生成可以接受稍微长一点的等待。

这样做的一个附加好处是：单日成本不会因为你做了免费推广就突然失控。模型调用被限流在预算范围内，用户端只是排队时间变长，不至于完全不可用。

6.3 用户体验优化：首 token 时间与骨架屏

性能优化不只靠缓存。网络层面，我用两个小程序来解决体验问题：

第一， 首 token 时间的优化 。大模型从请求发出到开始返回第一个 token，通常需要 1-3 秒。在这个阶段，客户端显示骨架屏和进度提示，配合"正在分析你的偏好""正在计算景点间的交通时间"等文案，转移用户注意力。

第二， 分段渲染 。流式输出时，先渲染当天的标题和时间段摘要，再渲染每个景点的卡片。这样用户看到内容是一段一段"长出来"的，比一次弹出整屏内容更有掌控感。

我还做了一个小程序：如果整体生成时间超过 15 秒，自动收起"继续等待"还是"重新生成"两个选项，避免用户干等。

7. 发布前最容易翻车的环节：提示词回归、兼容性和隐私合规

7.1 提示词也要做版本管理与回归

很多人改提示词是"改了跑，跑了看，不行再改"，没有版本管理的意识。在项目上线前两周，我吃了好几次亏：调整了一个约束条件的表述，结果所有生成结果都变得啰嗦；加了一个示例后，JSON 字段名开始不稳定。

后来我把提示词进行了规范化管理，用 Git 做版本管理，每个提示词版本对应一组测试用例：

• 必测用例 1 ：默认参数生成，验证 JSON 结构完整性。
• 必测用例 2 ：极端输入，比如"1 天 10 个景点"，验证是否会忽略约束。
• 必测用例 3 ：特殊输入，比如"周一去故宫"，验证是否会考虑闭馆日因素。
• 必测用例 4 ：非法输入，比如空目的地，验证是否能兜底返回错误提示。

每次改动提示词，先跑这组回归测试，全部通过再上到生产。这个方法大幅减少了线上由于"改了一个词"导致的批量失败。

7.2 真机适配与兼容性坑

鸿蒙应用调试阶段，模拟器可以帮你完成大部分逻辑验证，但真机适配才是花时间的地方。我遇到的主要问题有三个：

一是 不同屏幕尺寸下的卡面布局 。叠屏设备上，行程卡片文字过大导致换行混乱；小屏设备上，时间轴卡片太靠边被系统手势区遮挡。最终方案是采用弹性布局，卡片在固定最大宽度内自适应，且所有底部操作按钮预留系统安全边距。

二是 网络权限配置 。鸿蒙应用需要在 module.json5 中声明网络权限，否则真机上会静默失败。调试时模拟器没问题，一上真机就请求失败，这种问题很隐蔽。

三是 字体与深色模式适配 。深色模式下，景点卡片的背景色、行程时间轴的节点颜色都要跟着变。如果只适配了浅色，深色模式下文字对比度不足会很难读。

7.3 隐私合规与上架审核

行程规划类应用天然涉及用户位置和目的地数据，上架审核时隐私合规是重点。我在开发尾声做了三件事：

• 隐私政策页面 ：明确说明用户授权的地理位置仅用于本地行程展示和地图调用，不采集并上传到服务端。
• 最小权限申请 ：只申请网络权限和定位权限。很多人会顺手申请一堆权限，审核容易卡住，用户也会反感。
• 数据加密传输 ：客户端与我的网关之间用 HTTPS，网关与 MaaS 平台之间由平台保障传输层安全。

上架审核还遇到了一个容易忽略的细节：应用图标和截图。鸿蒙应用市场上架要求应用图标需要适配不同形状（圆形、圆角矩形、方形），截图需要包含完整页面信息，且不得出现模糊、遮挡。我因为截图中有测试环境的数据（假行程），被打回了一次，后来换成了真实的演示行程，才通过审核。

关于标题里"8 亿人"，坦白说，这是愿景式的说法。真实的产品在上架之后能做到多少用户，取决于分发渠道和运营投入。但从架构设计上，我是按照"国庆期间有大规模并发请求"来做的，缓存、限流、网关分层都为峰值预留了空间。

最后说一点个人体会。做这种 AI + 应用的落地，最大的认知转变是：大模型只是基础设施，产品和体验仍然是胜负手。没有蓝耘元生代 MaaS 这种把算力难题封装掉的服务，我大概率还停留在本地调试模型的阶段；没有鸿蒙生态，这个工具也只会停留在网页端，不会有服务卡片、分布式流转这些体验延展。技术选型没有绝对的"最好"，只有适合当前阶段和团队能力的"最合适"。如果你也要做类似的应用，建议先花一天时间把架构图画清楚——服务端网关、缓存策略、错误追踪、成本监控，这是比提示词更早需要确定的东西。

如果你想往下一步扩展，可以尝试接入口碑平台的数据做实时排队参考，或者把行程输出成日历邀请自动写入系统日历，再或者接入文旅目的地的活动 API。应用本身会越来越重，但核心价值——把用户从信息过载里解放出来——不会变。