一到年底或者纪念日，打开购物 App 想给对象、爸妈、朋友挑个礼物，大部分人都会陷入同一个困境：搜索“送女朋友生日礼物”，出来的全是爆款榜单，翻了三屏还是不知道选什么。这也是我做这款鸿蒙原生礼物 App 时最想解决的问题——与其让用户自己在一堆商品里瞎逛，不如直接在 App 里内置一个能“连续追问、越聊越懂你”的 AI 选礼助手，用户只要说清楚预算、对象、场合和风格偏好，AI 就能层层收敛，最终给出几个真正靠谱的礼物方案。
这个想法听起来不复杂，真正做起来才发现，鸿蒙端接入大模型能力，关键不在“调 API”，而在整个“多轮对话大脑”的架构设计。我最终选择基于蓝耘 MaaS 平台来承载模型推理，配合鸿蒙 ArkTS 原生实现了一套会话管理链路。这篇文章就把我完整的技术选型、工程实现、踩坑排查和体验优化过程分享出来，希望能帮到正在做鸿蒙 AI 应用、或者正在纠结怎么给 App 加对话能力的开发者。
1. 先想清楚：礼物推荐为什么必须用“多轮对话”而不是一次问答
1.1 礼物场景的信息收集天然是渐进式的
如果你把“送礼物”这个决策过程拆开看，会发现它跟普通的信息查询完全是两码事。用户搜“机械键盘推荐”，单轮问答就能给出不错的答案，因为需求相对明确。但选礼物不是这样，用户一开始的诉求往往是模糊的，比如“想给女朋友买个礼物”，这句话里既没有预算，也没有场合，更没有风格偏好。
如果只做一个单轮问答，AI 就只能把这句话当成一个宽泛的检索条件，给出的结果大概率是“鲜花、口红、首饰”这类大路货。但用户真正需要的是一个“会追问的导购”——先问送给谁，再问预算多少，接着问对方平时喜欢什么风格、最近有没有提过想要什么，然后结合这些信息逐步缩小推荐范围。
这就是多轮对话的核心价值：它不是一次问答的堆叠，而是状态不断累积的上下文决策过程。每一轮用户的回答都在为 AI 提供新的约束条件，AI 的每一轮追问都在帮用户厘清自己都没想清楚的需求。
1.2 多轮对话和搜索式问答的本质差别
很多初级开发者会问：我用一个大轮次，把“你想给谁买、预算多少、什么风格”全部写死在 prompt 里，让用户一次性填完，不也一样吗？
功能上可能接近，但体验上差距极大。第一，强制用户一次性填写表单式信息，心理门槛很高，很多用户根本答不全；第二，用户自己也不确定“什么风格适合对方”，需要在对话中不断被启发、被确认；第三，礼物推荐里有大量隐性信息（比如对方最近加班多、上次送过什么、恋爱纪念日快到了），这些信息只有通过自然对话才能低摩擦地收集上来。
用技术语言说，多轮对话让 AI 拥有了“问诊能力”，而单轮问答只是“抓药能力”。对于礼物这种强个性化、强情感属性的场景，抓药式体验远远不够。这也是我在产品设计阶段就明确下来的原则：这功能必须做多轮对话，不能做成一个高级搜索框。
1.3 为什么选 MaaS 而不是自己部署模型
确定了要多轮对话，接下来就是选模型部署方式。我当时最纠结的问题是自己部署开源模型还是用 MaaS 平台。自己部署的吸引力在于数据完全可控、长期成本可能更低，但代价也很现实——我需要自己准备 GPU 服务器、处理推理优化、做高可用、盯模型更新。对于一个以客户端开发为主的团队来说，这完全是另一个领域的事。
MaaS 平台的思路是把模型推理、弹性扩缩容、API 网关这些都打包好，我只需要专注业务层。这就像自己做饭和点外卖的区别：自己做饭上限高，但你得起灶台、买菜、洗锅；点外卖虽然每单花钱，但胜在随叫随到。考虑到我当时的首要目标是快速验证这个功能的市场反馈，MaaS 几乎是唯一理性的选择。
2. 蓝耘MaaS选型复盘：给鸿蒙App配“对话大脑”的方案对比与成本账
2.1 蓝耘MaaS解决了什么核心问题
选蓝耘 MaaS，我最看重的是三点：模型可选、接口标准、接入成本。
第一，它不是一个绑定单一模型的封闭平台，而是提供了多种开源和商业模型的接入能力，我可以在不同阶段换模型而不用重写业务代码。做礼物推荐这种偏创意生成的场景，需要模型有比较强的中文理解能力和多轮指令跟随能力，模型选错了整个体验就垮掉，可替换性非常重要。
第二，接口兼容 OpenAI 格式。这意味着鸿蒙后端只需要写一套标准请求逻辑，如果以后要接别的模型服务商，改动成本很低。对于小团队来说，这等于给自己留了一条随时可退的逃生通道。
第三，接入成本确实低。注册、创建应用、拿 API Key、看文档，整体走下来不到一上午。对于想快速验证产品价值的个人开发者或者小团队来说，这个速度非常关键。
2.2 架构上最重要的决定：加一层后端代理
这里要给所有做鸿蒙 App + AI 的开发者一个非常明确的建议：不要让鸿蒙客户端直接持有 API Key 并直连 MaaS 的接口。
原因很简单：API Key 放在客户端里面，抓包就能看到，等于把钱包送给别人。无论平台方有没有做调用限制，这都是一笔不可控的成本敞口。另外，MaaS 的接口地址是固定的、跨域的，鸿蒙端直连虽然技术上没问题，但后续如果你想做用户维度限流、对话日志、敏感词过滤、统一 prompt 版本管理，没有一个中间层就会非常痛苦。
我当时的架构是：
鸿蒙App (ArkTS) ↓ HTTPS + JSON 后端代理服务 (Node.js 或 Spring Boot) ↓ HTTPS + OpenAI兼容格式 蓝耘MaaS模型接口这个代理层不复杂，就是一个标准的 API 转发服务，但它承担了几个关键职责：存储 API Key、做用户维度频率限制、统一异常响应格式、记录关键日志。鸿蒙端只需要跟自己的后端约定一套接口结构就行，完全不用关心底层对接哪个模型服务商。
2.3 成本估算：一次完整的选礼对话要花多少钱
做产品不能不算账。我按实际测试数据粗略估算过，一次完整的选礼对话（大约 8 到 10 轮），输入 token 在 3000 到 5000 之间，输出 token 在 800 到 1500 之间。以蓝耘 MaaS 上常见的中文对话模型推理价格来算，单次完整对话的模型成本大约在 0.01 元到 0.03 元之间。
| 项目 | 估算值 |
|---|---|
| 单次对话轮数 | 8~10 轮 |
| 输入 token 总量 | 3000~5000 |
| 输出 token 总量 | 800~1500 |
| 单次对话模型成本 | 约 0.01~0.03 元 |
| 日活 1000、人均 3 次对话 | 每日约 30~90 元 |
说实话这个成本远低于我最初的预期。真正的成本大头反而是后端代理服务器和开发人力，模型推理本身在礼物推荐这种中低频场景里完全可控。这也让我后续敢放开 prompt 字数、增加场景引导，不用担心用户一多就把预算烧穿。
3. 鸿蒙端工程准备：网络请求、会话存储与权限配置
3.1 DevEco Studio 工程基础配置
鸿蒙开发现在用的是 DevEco Studio，基于 ArkTS 语言和 ArkUI 框架。我开始做这个项目时用的 API 版本是 9 以上的稳定版，开启了compatibleSdkVersion适配合适的设备范围。
新建工程后，第一件事是在module.json5里声明网络权限。这一点光看官方文档容易漏，因为鸿蒙的网络权限体系和 Android、iOS 都不一样，它不是直接在 manifest 里写一行就能跑的，有些场景还得用户手动授权。我的做法是：
{ "module": { "requestPermissions": [ { "name": "ohos.permission.INTERNET" }, { "name": "ohos.permission.GET_NETWORK_INFO" } ] } }INTERNET权限是发起网络请求的基础，GET_NETWORK_INFO用于在网络状态变化时给用户友好的提示。如果少了这两个权限，请求会直接失败，而且错误信息不一定直观。
3.2 网络请求层：用 @ohos.net.http 还是 Axios
鸿蒙端发 HTTPS 请求有两种主流选择：官方提供的@ohos.net.http模块，以及社区适配的axios库（通过 OpenHarmony npm 源安装）。我两个都试过，简单总结一下：
@ohos.net.http：官方原生能力，依赖少，适合简单请求。但它的 API 风格比较偏底层，响应处理需要手动解析，做超时、重试、拦截器这些东西代码会变得比较啰嗦。axios：API 风格跟 Web 端一致，拦截器、超时、取消请求都很方便，团队上手成本低。缺点是引入了第三方依赖，需要注意鸿蒙兼容版本。
最终我选了axios，因为我的业务不仅有一个对话接口，还会请求商品信息、用户画像等多个接口，拦截器能统一处理 token 刷新和错误码映射，省很多事。
封装请求层时，核心代码如下：
import axios from '@ohos/axios'; const client = axios.create({ baseURL: 'https://api.example.com/v1', timeout: 30000, headers: { 'Content-Type': 'application/json', 'X-Client-Version': '1.0.0' } }); client.interceptors.request.use((config) => { const token = AppStorage.get<string>('sessionToken'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); client.interceptors.response.use( (response) => response.data, (error) => { if (error.code === 'ECONNABORTED') { return Promise.reject(new Error('请求超时，请稍后重试')); } return Promise.reject(new Error(error.message)); } );这里有一个容易被坑的细节：超时时间不能设太短。大模型对话接口的响应时间经常在 5 到 15 秒之间，如果按普通 REST API 的习惯设成 3 秒超时，AI 回复稍慢一点就会被掐断。我最终把超时设成了 30 秒，并且在 UI 层叠加了“正在思考”的状态动画，让用户能耐心等待。
3.3 会话上下文的数据结构设计
多轮对话的核心是会话状态管理。礼物场景里，每一轮对话都要知道：当前会话 ID、历史消息列表、用户已经透露的需求信息。我在本地用了一个GiftConversation类来管理：
export interface ChatMessage { role: 'user' | 'assistant' | 'system'; content: string; timestamp: number; } export class GiftConversation { sessionId: string; messages: ChatMessage[]; userProfile: UserProfile; constructor() { this.sessionId = this.generateSessionId(); this.messages = []; this.userProfile = { budget: -1, targetRelation: '', occasion: '', stylePreference: '', age: -1, hobbies: [] }; } appendMessage(role: ChatMessage['role'], content: string) { this.messages.push({ role, content, timestamp: Date.now() }); this.extractProfile(content); } private extractProfile(content: string) { // 从用户话语中解析出预算、对象、场合等结构化信息 // 实际实现可以用正则 + 语义兜底 } }之所以要在本地维护一个userProfile对象，是为了后续的功能扩展。比如用户第一轮说“预算五百以内”，第二轮又说“可以再加点”，AI 需要理解这是预算修正，而不是两个互相矛盾的条件。虽然模型本身也有记忆能力，但把关键信息结构化存下来，后续做商品筛选、做历史推荐记录回看，都会方便得多。
4. 核心链路实现：从“用户问一句”到“AI连续陪聊选礼”
4.1 请求体构造：system prompt + 历史消息 + 当前问题
MaaS 模型的多轮对话能力本质上是靠请求体里的messages数组驱动的。每一轮请求，客户端都要把完整的对话历史传给后端，由后端转发给模型。这个机制理解透了，多轮对话的实现思路就清晰了。
我的请求体结构大致是：
{ "model": "gift-assistant-v1", "messages": [ { "role": "system", "content": "你是「选礼助手」，一个专业的礼物推荐顾问。你的任务是通过多轮对话了解用户的送礼对象、预算、场合和风格偏好，然后给出具体且可购买的礼物建议。每轮对话最多追问一个问题，不要一次问太多。当信息充分时，输出推荐方案。" }, { "role": "user", "content": "我想给女朋友买个生日礼物" }, { "role": "assistant", "content": "好的！给女朋友的生日礼物是非常有心意的选择。为了帮你推荐得更准确，我想先了解一下：你的预算大概是多少呢？" }, { "role": "user", "content": "预算一千以内吧" } ], "temperature": 0.7, "max_tokens": 800 }这个请求体有几个关键点：
第一，system消息不是摆设，它定义了 AI 的角色、任务边界和行为准则。我在礼物场景里专门在 system prompt 里写了“每轮对话最多追问一个问题”，没有这句限制，模型经常一次抛出四五个问题，用户根本答不过来。
第二，messages数组是累积的，不能只传当前问题。这也是很多初做多轮对话的人容易踩的坑——如果只把最新一句话传给模型，模型就会“失忆”。每一次请求都要把从会话开始到当前的所有往返消息都带上。
第三，temperature参数在选礼场景里设置为 0.7 比较合适。太高（比如 1.2）会让推荐结果天马行空，太低（比如 0.2）会让推荐结果过于保守、缺乏惊喜感。礼物推荐需要在创意和合理之间找平衡。
4.2 系统提示词的系统设计与迭代
系统提示词是决定多轮对话体验质量的隐藏杠杆。我第一版 prompt 写得很简单，就一句话“你是礼物推荐助手”。结果模型的表现就像个复读机，用户说什么它都顺着说，完全不会主动引导。
后来我把 prompt 改成了带结构的形式：
你是「礼小伴」，一个经验丰富的礼物顾问。你擅长通过提问了解送礼需求，再给出有温度的礼物建议。 你的对话策略： 1. 第一轮：主动了解「送礼对象」和「场合」 2. 第二轮：确认「预算范围」 3. 第三轮左右：询问「对方兴趣爱好」或「最近偏好」 4. 信息收集充分后：给出 3 个具体礼物方案，每个方案包含礼品名称、参考价格、推荐理由 你的表达要求： - 语气亲切自然，不要像客服 - 每轮只提 1 个问题，避免给用户造成压力 - 如果用户说“不知道”，给出常见选项让用户选把策略写进 system prompt 后，对话质量提升非常明显。模型开始有了节奏感，该追问时追问，该收敛时收敛。这也验证了一个经验：多轮对话的体验上限，很大程度上取决于 system prompt 的设计水平，而不是模型本身的能力。
4.3 响应解析与消息追加的正确姿势
请求发出后，返回的响应结构一般长这样：
{ "choices": [ { "message": { "role": "assistant", "content": "一千元以内给女朋友选生日礼物，我推荐可以考虑这几个方向..." } } ] }拿到这个响应后，对应的操作是：
async function sendChat(conversation: GiftConversation, userInput: string) { conversation.appendMessage('user', userInput); const response = await client.post('/chat/completions', { sessionId: conversation.sessionId, messages: conversation.messages }); const assistantReply = response.data.choices[0].message.content; conversation.appendMessage('assistant', assistantReply); return assistantReply; }这里有一个我踩过的坑：响应消息追加进历史数组时，必须按实际返回的 role 来追加，不能想当然地默认是 assistant。有些模型在特定情况下可能返回 role 为tool或者空的响应，处理不当会导致下一轮请求格式错乱。
另外建议把完整的assistant返回对象（包括 token 使用量等信息）存一份到本地日志，这样后续如果对话出现问题，可以复盘排查是哪一轮出了岔子。
4.4 流式输出：要不要做，怎么做更好
多轮对话体验中，用户最焦虑的时刻是“消息发出去了，屏幕上一片空白”。等待 5 到 10 秒没有任何视觉反馈，用户会怀疑 App 是不是卡死了。
解决这个问题有两个方案：一个是服务端生成完一次性返回，客户端显示加载动画；另一个是使用流式输出，像 ChatGPT 那样一个字一个字地蹦出来。流式输出的代码复杂度会高一些，但体验确实更好，用户能感受到对话“活着”。
蓝耘 MaaS 的接口支持流式返回（SSE，Server-Sent Events）。鸿蒙端处理 SSE 的方式和 Web 端不太一样，不能用 EventSource，得用@ohos.net.http配合流式读取，或者在后端代理层把 SSE 转成 WebSocket 推给客户端。我在实际项目里选择了后端代理层做转换，鸿蒙端用 WebSocket 接收增量文本，这样处理起来更顺手，也方便控制连接生命周期。
当然，如果你的第一版不想花太多精力做流式，完全可以先用整包返回。礼物推荐场景里，用户对话通常是“想一想再回”，对秒级延迟的敏感度没有客服机器人那么高。先跑通再优化，是更务实的路径。
5. 实测踩坑记录：鸿蒙接入MaaS最容易翻车的四个环节
5.1 网络权限配置引发的“静默失败”
第一个坑是我在刚开始联调时碰到的，现象是：日志里请求已经发出去了，但始终拿不到响应，也没有报错信息弹出来。排查了半天，发现就是module.json5里漏了ohos.permission.INTERNET权限。
这个错误最坑的地方在于它不一定显式报错。有些设备上会提示网络异常，有些设备上就静默失败了，请求对象像石沉大海一样毫无回应。如果你在鸿蒙上调试 AI 接口遇到请求发出去没有响应，第一反应先检查权限配置，而不是怀疑 API Key 和请求格式。
另外，鸿蒙的权限还分system_grant和user_grant两种。网络权限属于system_grant，不需要弹窗让用户确认，只要在配置文件里声明即可。如果你用到了需要运行时弹窗的权限（比如定位），那还得多一步动态申请的逻辑。
5.2 中文乱码和 URL 编码问题
第二个坑和编码有关。鸿蒙的 Axios 默认行为在某些版本下对中文参数处理不够友好，直接拼接 URL 或者用 form 表单提交的话，中文问句很容易变成乱码，导致模型返回逻辑错乱。
我的规避方式是：所有请求体都统一用 JSON 格式，Content-Type显式指定为application/json; charset=utf-8。请求里的用户输入先做一次encodeURIComponent编码，后端收到后解码，虽然多了一步但彻底杜绝了乱码问题。这里提醒一下，如果你用了 Node.js 做后端代理，要注意对中文参数默认用decodeURIComponent解码，而不是unescape，后者对特殊字符的处理不够规范。
5.3 上下文无限膨胀导致的超时与成本失控
这是个非常隐蔽但后果严重的坑。随着对话轮数增加，messages数组越来越长，每次请求携带的 token 数量越来越大，直接导致两个问题：请求耗时指数级上升、费用水涨船高。
我实测过，当对话超过 15 轮时，如果所有历史消息全部携带，单次请求的输入 token 可能超过 8000，响应时间会从 3 秒飙到 10 秒以上。用户还在继续聊，模型却越来越“迟钝”。
解决方案是滑动窗口裁剪，只保留最近 N 轮消息：
function trimMessages(messages: ChatMessage[], maxTurns: number = 10): ChatMessage[] { const systemMessages = messages.filter(m => m.role === 'system'); const conversationMessages = messages.filter(m => m.role !== 'system'); const recent = conversationMessages.slice(-maxTurns * 2); return [...systemMessages, ...recent]; }注意，裁剪时system消息始终保留，因为它定义了模型的行为准则。普通对话消息只保留最近 10 轮左右，对礼物推荐场景来说完全足够了——用户聊到 10 轮还没收敛，大概率是 AI 引导出了问题，而不是历史消息太少。
5.4 JSON 解析异常与 “choices 为空” 的防御处理
最后一个坑来自模型输出的不确定性。虽然正常情况下模型会返回结构化 JSON，但偶尔会出现choices数组为空、或者content字段为 null 的情况。有些是模型自身的稳定性问题，有些是请求参数里的max_tokens设太短导致输出被截断。
我在代码里加了一道防御逻辑：
function extractAssistantReply(response: any): string { if (!response || !response.choices || response.choices.length === 0) { return '抱歉，我没有理解清楚，能再说一遍吗？'; } const content = response.choices[0].message?.content; if (!content || content.trim() === '') { return '我还在思考中，请稍后再试一次。'; } return content; }核心思想是：跟大模型交互的代码，必须有兜底话术，不能直接抛异常让客户端崩溃。用户面对一个偶尔“迟钝”的 AI 是可以理解的，但面对一个闪退的 App 是不能接受的。所有的边界情况都要用友好的提示承接住。
6. 进阶玩法：让对话大脑输出“可操作的礼物方案”
6.1 从自由文本到结构化推荐卡片
基础的多轮对话跑通之后，我发现一个体验问题：AI 推荐的礼物方案全都混在一大段文字里，用户看完还得自己提炼“是什么、多少钱、在哪买”。这对礼物场景很不友好。
于是我引入了一个进阶能力：让模型在对话结尾输出结构化 JSON，客户端解析后渲染成精美的推荐卡片。要点是在 system prompt 里约定输出格式：
当信息收集充分、准备输出推荐方案时，请严格按以下 JSON 格式输出，不要有任何额外文字： { "recommendations": [ { "name": "礼物名称", "price": "参考价格", "reason": "推荐理由", "tips": "购买小提示" } ] }然后在客户端做两层校验：先尝试JSON.parse，如果失败，就把整段文本当作文案展示，同时提供一个“一键提取方案”按钮，把文本发给后端一个专门解析的接口。这样即便模型偶尔输出不规范，用户也不至于拿到一堆没法用的文字。
6.2 用本地用户画像做跨会话记忆
礼物推荐有一个很特别的点：用户的需求在短时间内是有连续性的。比如这个月给女朋友买生日礼物，下个月可能又要送周年纪念日礼物。如果每次对话都从零开始问“你对象喜欢什么”，用户会觉得很蠢。
我在GiftConversation里维护的userProfile，配合AppStorage或轻量数据库做持久化，可以在用户新开一个会话时，自动带上历史画像：
function buildSystemPrompt(userProfile: UserProfile): string { let prompt = '你是「礼小伴」...（基础设定）'; if (userProfile.targetRelation) { prompt += `\n已知信息：用户的送礼对象是${userProfile.targetRelation}，上次提到对方喜欢${userProfile.hobbies.join('、')}。`; } return prompt; }这个功能做出来之后，用户能明显感觉到 AI “记得我”。虽然实现成本不高，但对产品好感度的提升非常明显——用户会觉得这个东西是真正为他量身定做的，而不是一个通用的聊天机器人。
6.3 关于“多轮对话”产品化的一些后续规划
目前这个“多轮对话选礼大脑”已经在我的鸿蒙礼物 App 里稳定跑了一段时间，从数据反馈来看，用户平均对话轮数在 5 轮左右，超过 60% 的用户会走完整个推荐流程，说明多轮对话的引导设计是有效的。后续我还打算做两件事：一是接入更细的商品库数据，让 AI 推荐的不是泛泛的品类，而是真实可下单的具体商品；二是做一个“对话记忆导览页”，让用户随时看到 AI 已经掌握了哪些信息、还可以补充哪些信息，降低对话中的不确定性。
回过头看整个项目，我最深的体会是：把大模型接进 App 并不是最难的，难的是想清楚多轮对话在每个业务场景里到底该怎么设计。礼物推荐这个场景天然适合多轮对话，因为它需要收集的信息维度多、需要用户参与确认、又需要有情感温度。而 MaaS 平台的存在，让中小团队也能以极低的成本给 App 装上这样的“大脑”。如果你也正在做一个需要 AI 对话能力的鸿蒙应用，希望这篇文章能帮你少踩几个坑。最后分享一个小技巧：调试多轮对话时，别只测“正常路径”，一定要多测“用户答非所问”和“用户中途改主意”这两种情况，多轮对话产品的真实体验差距，往往就藏在这些意外里。
