1. 这个项目到底在解决什么问题国庆黄金周出行几乎每个人都经历过那种攻略焦虑。打开手机小红书、马蜂窝、携程、飞猪来回切收藏了几十篇笔记最后还是不知道第一天该去哪、第二天怎么走顺路、带老人和带小孩的路线怎么区分。信息不是不够是太多了而且彼此矛盾。更麻烦的是每个人的出发地、预算、天数、同行人结构、体力状况都不一样但网上99%的攻略都是通用模板你只能自己去适配。我这次做的事情本质上是想验证一个假设大模型能不能把行程规划这件事从信息检索变成个性化生成。不是给你一堆链接让你自己挑而是直接根据你的约束条件生成一份可执行、可调整、带时间轴的行程表。技术选型上我用了蓝耘元生代 MaaS 平台来托管和调用大模型能力前端跑在鸿蒙系统上。为什么是这两个MaaS 的好处是我不用自己去折腾模型部署、显存管理、并发调度这些脏活直接拿 API 就能用而且平台侧对推理做了优化响应速度在可接受范围内。鸿蒙这边我主要是想验证一下在国产操作系统上做 AI 原生应用的体验——分布式能力、卡片服务、原子化服务这些特性其实很适合做轻量级、场景化的 AI 工具。这个项目适合谁看如果你是想快速验证一个 AI 应用想法的独立开发者或者你正在找一个 MaaS 平台做落地demo再或者你对鸿蒙生态的应用开发感兴趣那这篇内容应该能给你一些可直接抄的作业。我不讲虚的从架构设计到参数调优到踩坑记录全部摊开说。2. 整体架构设计与技术选型逻辑2.1 为什么选 MaaS 而不是自己部署模型先说最核心的决策模型怎么来。自己部署开源模型听起来很酷但实际算一笔账就知道不划算。一个 7B 参数的模型FP16 精度下光权重就要占 14GB 显存加上 KV Cache 和推理框架的开销一张 24GB 的卡勉强能跑但并发一上来就崩。如果是 13B 或者 70B那成本直接起飞。而且你还要处理模型版本管理、推理加速、负载均衡、故障转移这些运维问题一个人根本忙不过来。MaaSModel as a Service的思路就是把这一层全部抽象掉。蓝耘元生代这边提供的是标准化的 API 接口我只需要关心输入什么 prompt、输出什么格式、怎么控制成本。平台侧会处理模型的部署、扩缩容、推理优化。对于我这种想快速验证产品逻辑的场景来说这是最优解。具体来说我用了两类模型能力一个是通用对话模型负责理解用户需求、生成行程文本另一个是结构化抽取模型负责把自然语言行程转成 JSON 格式方便前端渲染。两个模型通过 MaaS 平台统一调度我这边只需要维护一套 API Key 和调用逻辑。2.2 鸿蒙端的技术栈选择鸿蒙这边我选的是 ArkTS ArkUI 的组合。ArkTS 是鸿蒙主推的应用开发语言基于 TypeScript 扩展类型系统更严格写起来比纯 JS 舒服。ArkUI 的声明式 UI 范式和 React 那套很像如果你有前端经验上手很快。为什么不用 Flutter 或者 React Native 跨平台方案两个原因。第一我想用鸿蒙的原子化服务能力——用户不需要安装完整 App通过卡片就能直接触发生成行程这个动作这对黄金周这种临时用一下的场景特别合适。第二鸿蒙的分布式软总线可以让手机、平板、车机之间无缝流转虽然这次 demo 没做车机端但架构上留了口子。网络层用的是鸿蒙的ohos.net.http模块配合 MaaS 平台的 RESTful API。数据缓存用了ohos.data.preferences把用户的历史行程和偏好设置存在本地下次打开不用重新输入。2.3 数据流与交互设计整个数据流是这样的用户在鸿蒙端填写出发地、目的地、天数、预算、同行人结构、兴趣标签前端把这些参数组装成一个结构化 prompt通过 HTTP 请求发给 MaaS 平台。平台侧模型生成行程文本返回给前端。前端拿到文本后再调用一次结构化抽取接口把文本转成 JSON。最后 ArkUI 根据 JSON 渲染成时间轴卡片。这里有个关键设计我把生成和结构化拆成了两次调用。为什么不一次搞定因为实测下来让模型同时做创意生成和格式约束两件事效果会打折扣。模型要么只顾着生成内容忘了格式要求要么为了满足格式内容变得很死板。拆开之后第一次调用专注内容质量第二次调用专注格式转换两边都能做到更好。交互上我做了三个入口一是完整的表单填写适合首次使用二是一键生成按钮用默认参数快速出结果三是鸿蒙卡片长按桌面卡片直接触发。三个入口对应不同的使用深度用户想快就快想细就细。3. 核心细节解析与实操要点3.1 Prompt 工程怎么让模型输出可用的行程Prompt 是这个项目的灵魂。我前后改了十几版才找到一个相对稳定的模板。核心思路是把约束条件显式化把输出格式模板化把示例给足。先看约束条件。用户输入的参数包括出发城市、目的地、旅行天数、预算范围、同行人老人/小孩/情侣/朋友、兴趣偏好美食/自然/人文/购物、节奏偏好紧凑/宽松。这些参数不能直接扔给模型要转成模型能理解的描述。比如带老人要转成同行有60岁以上老人需要避免长时间步行和爬山每天景点数量不超过3个中午需要安排休息时间。输出格式方面我定义了一个固定的 Markdown 模板## 第X天 **上午**景点名称游玩时长交通方式 **午餐**餐厅类型推荐人均预算 **下午**景点名称游玩时长交通方式 **晚餐**餐厅类型推荐人均预算 **晚上**活动建议 **住宿**区域推荐 **当日预算**XXX元这个模板的好处是结构清晰模型不容易跑偏后续转 JSON 也方便。我在 prompt 里会明确说严格按照上述格式输出不要添加额外说明。示例方面我放了一个完整的北京3日游样例在 prompt 里。实测下来给一个高质量示例比写一堆规则更有效。模型会模仿示例的风格和详细程度输出质量明显提升。注意prompt 长度要控制。我一开始把规则写得太细prompt 超过 2000 token结果模型反而抓不住重点。后来精简到 800 token 左右效果最好。3.2 结构化抽取从自然语言到 JSON模型生成的行程是 Markdown 文本前端要渲染成卡片需要 JSON。这一步我用了 MaaS 平台上的另一个模型专门做信息抽取。Prompt 很简单请将以下行程文本转换为 JSON 格式包含字段day天数、morning上午安排、lunch午餐、afternoon下午安排、dinner晚餐、evening晚上安排、hotel住宿、budget预算。直接输出 JSON不要其他内容。 行程文本 {这里插入模型生成的行程}这里有个坑模型有时候会在 JSON 外面包一层json的代码块标记导致解析失败。我的处理方式是在 prompt 里明确说直接输出 JSON不要用代码块包裹然后在代码里做一层容错——如果解析失败先用正则把代码块标记去掉再试一次。另一个坑是字段缺失。比如模型可能忘了输出budget字段。我的做法是在 prompt 里强调所有字段必须存在如果信息缺失填 null然后在代码里做默认值处理。3.3 鸿蒙端 UI 渲染与性能优化ArkUI 的声明式渲染很舒服但有个问题如果行程数据量大比如 7 天行程每天 8 个字段一次性渲染所有卡片会卡顿。我的优化方案是懒加载 分页。首屏只渲染第 1 天的行程用户下滑时再加载第 2 天。用LazyForEach组件实现实测下来滑动帧率稳定在 55-60fps。卡片样式上我用的是ColumnRow的嵌套布局每天一个主卡片内部用Flex布局排列时间段。颜色方案用了鸿蒙默认的主题色保证在不同设备上的一致性。还有一个细节加载状态的处理。模型生成行程需要 3-8 秒这段时间用户不能干等着。我加了一个骨架屏Skeleton用灰色方块模拟卡片布局同时显示AI 正在规划中...的提示文字。实测下来有骨架屏的等待体验比空白页好很多用户不会觉得卡死了。4. 实操过程与核心环节实现4.1 MaaS 平台接入从注册到第一个 API 调用第一步是在蓝耘元生代平台注册账号创建应用拿到 API Key 和 Endpoint。这个过程没什么好说的跟着文档走就行。需要注意的是API Key 不要硬编码在前端代码里我是在鸿蒙端做了一层代理前端请求先发到自己的后端服务后端再转发给 MaaS 平台。这样 Key 不会暴露在客户端。第一个 API 调用我建议先用 curl 或者 Postman 测通确认请求格式和返回结构。MaaS 平台的接口是标准的 OpenAI 兼容格式请求体大概长这样{ model: your-model-name, messages: [ {role: system, content: 你是一个专业的行程规划师...}, {role: user, content: 帮我规划一个北京3日游...} ], temperature: 0.7, max_tokens: 2000 }temperature这个参数很关键。行程规划需要一定的创意性比如推荐小众景点但也不能太发散比如推荐不存在的餐厅。我实测下来 0.7 是个比较平衡的值。如果你想要更稳定的输出可以降到 0.5如果想要更多惊喜可以升到 0.9。max_tokens要根据行程天数调整。3 天行程大概需要 1500-2000 token7 天行程需要 3000-4000 token。设太小会被截断设太大浪费成本。我的做法是根据天数动态计算max_tokens 天数 * 600 500。4.2 鸿蒙端网络请求封装鸿蒙的 HTTP 请求用ohos.net.http模块我封装了一个通用的请求函数import http from ohos.net.http; async function callMaaS(prompt: string): Promisestring { const httpRequest http.createHttp(); const response await httpRequest.request( https://your-backend.com/api/generate, { method: http.RequestMethod.POST, header: { Content-Type: application/json, Authorization: Bearer getToken() }, extraData: JSON.stringify({ prompt: prompt }) } ); httpRequest.destroy(); if (response.responseCode 200) { const result JSON.parse(response.result as string); return result.content; } else { throw new Error(请求失败: response.responseCode); } }这里有几个注意点。第一httpRequest.destroy()一定要调用否则会内存泄漏。第二超时时间要设置合理默认是 60 秒但模型生成可能需要更久我设成了 120 秒。第三错误处理要完善网络超时、服务端错误、解析失败都要有对应的提示。4.3 行程生成完整流程实录我拿一个真实场景跑一遍完整流程。用户输入从上海出发去成都5 天预算 5000 元带父母60 岁以上喜欢美食和人文节奏宽松。第一步参数组装。前端把用户输入转成 prompt你是一个专业的行程规划师。请为以下需求生成一份详细的行程 出发地上海 目的地成都 天数5天 预算5000元不含往返交通 同行人2位60岁以上老人 兴趣偏好美食、人文 节奏宽松每天景点不超过3个中午需要休息 请严格按照以下格式输出 ## 第X天 **上午**... **午餐**... ... 注意事项 1. 考虑老人的体力避免爬山和长时间步行 2. 推荐当地特色美食标注人均消费 3. 交通方式优先推荐地铁和打车 4. 每天预算控制在1000元以内第二步调用生成接口。请求发出后大概 5 秒返回结果。我截取第一天的输出## 第1天 **上午**宽窄巷子游玩2小时地铁4号线直达 **午餐**马旺子川小馆人均80元推荐宫保鸡丁、甜水面 **下午**人民公园鹤鸣茶社喝茶休息2小时体验成都慢生活 **晚餐**陈麻婆豆腐人均60元推荐麻婆豆腐、夫妻肺片 **晚上**锦里古街夜游1.5小时适合拍照 **住宿**春熙路附近酒店约400元/晚交通便利 **当日预算**约800元第三步结构化抽取。把上面的文本发给抽取模型返回 JSON{ day: 1, morning: 宽窄巷子游玩2小时地铁4号线直达, lunch: 马旺子川小馆人均80元, afternoon: 人民公园鹤鸣茶社喝茶休息2小时, dinner: 陈麻婆豆腐人均60元, evening: 锦里古街夜游1.5小时, hotel: 春熙路附近酒店约400元/晚, budget: 约800元 }第四步前端渲染。ArkUI 根据 JSON 渲染成卡片用户可以看到完整的时间轴。整个流程从用户点击生成到看到结果大概 8-10 秒。这个时间在可接受范围内但如果能优化到 5 秒以内会更好。我后续的优化方向是把生成和抽取合并成一次调用用 function calling 的方式让模型直接输出 JSON但这样会牺牲一些内容质量需要权衡。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定怎么办这是最常见的问题。即使 prompt 里写了严格按照格式输出模型有时候还是会自由发挥比如加一些额外的说明文字或者把 Markdown 标题写成别的形式。我的解决方案是三层防护。第一层在 prompt 里用更强的约束语言比如必须、禁止、严格按照第二层在代码里做正则校验如果格式不对自动重新请求一次第三层如果连续两次失败降级到备用 prompt 模板。实测下来第一层能解决 80% 的问题剩下 20% 靠第二层兜底。第三层基本用不上但留着心里踏实。5.2 生成速度太慢怎么优化模型生成 5 天行程需要 5-8 秒这个速度对于即时交互来说偏慢。我试过几个优化方向优化方案效果代价减少 max_tokens速度提升 20%行程详细度下降降低 temperature速度提升 10%内容创意性下降流式输出首字延迟降低 60%前端处理复杂度增加缓存常见目的地命中时速度提升 90%只适用于热门城市最后我选了流式输出 缓存的组合。流式输出让用户先看到部分内容感知上的等待时间大幅缩短。缓存则是把热门城市成都、重庆、西安、长沙等的行程预生成好用户请求时直接返回速度极快。流式输出的实现方式是MaaS 平台支持 SSEServer-Sent Events前端用EventSource接收。每收到一个 chunk就更新一次 UI。这样用户能看到文字一个个蹦出来体验比转圈等待好很多。5.3 鸿蒙端常见报错与解决报错一request failed with code 2300007。这是网络权限问题。鸿蒙应用需要在module.json5里声明ohos.permission.INTERNET权限。很多人第一次开发鸿蒙应用会忘掉这个。报错二Cannot read property xxx of undefined。这是 JSON 解析后字段缺失导致的。解决方案是在代码里做防御性编程所有字段访问都用可选链?.或者给默认值。报错三页面卡顿。如果行程数据量大一次性渲染所有卡片会卡。解决方案是用LazyForEach做懒加载只渲染可视区域内的卡片。报错四中文乱码。鸿蒙的 HTTP 请求默认编码是 UTF-8但如果服务端返回的 header 里没有正确声明 charset可能会乱码。解决方案是在请求头里显式加上Accept-Charset: utf-8。实操心得鸿蒙的 DevEco Studio 有实时预览功能改代码后立刻能看到效果调试效率很高。但预览环境和真机环境有差异网络请求、权限这些一定要在真机上测。5.4 成本控制怎么用最少的 token 做最多的事MaaS 平台按 token 计费如果用户量大成本会很快上去。我做了几个优化第一prompt 精简。把 system prompt 从 500 token 压缩到 200 token只保留最核心的指令。示例从完整行程缩短到只给格式模板。第二结果缓存。相同目的地 相同天数 相同偏好的请求直接返回缓存结果。缓存有效期设为 7 天因为景点和餐厅信息短期内不会大变。第三分级模型。简单请求比如 3 天以内的短途游用轻量模型复杂请求7 天以上、多目的地用高性能模型。轻量模型的成本只有高性能模型的 1/5。第四限制重试次数。格式校验失败时最多重试 1 次避免无限重试导致成本失控。实测下来这些优化能把平均成本降低 60% 左右。对于一个 demo 项目来说这个成本完全可以接受。6. 这个项目后续还能怎么扩展目前这个版本只做了生成行程这一个核心功能但架构上留了很多扩展点。比如可以加行程调整功能——用户对某一天的安排不满意可以直接说第二天下午我想换成博物馆模型重新生成那一天的安排。这需要维护一个会话上下文把之前的行程作为 history 传给模型。还可以加实时推荐——结合用户当前位置和当前时间推荐附近的餐厅或景点。这需要接入地图服务鸿蒙这边有ohos.geoLocationManager可以获取位置。另一个方向是多人协作——同行的人可以各自在手机上查看和编辑行程通过鸿蒙的分布式能力同步数据。这个场景在家庭出游中很实用但实现复杂度较高需要处理冲突合并。我个人最想做的其实是行程复盘——旅行结束后根据用户的实际轨迹和消费记录自动生成一份旅行报告对比计划与实际的差异。这个功能对用户来说有情感价值对平台来说能收集真实数据优化模型。不过这些都是后话了。当前这个 demo 已经验证了核心假设大模型 MaaS 鸿蒙确实能做出一个体验不错的 AI 行程规划工具。技术上的坑基本都踩过了剩下的就是产品层面的打磨。如果你也在做类似的东西希望这篇内容能帮你少走一些弯路。
