企业官网建设流程全解析

国庆假期，别人忙着打卡发朋友圈，我干了一件亲戚朋友看不太懂的事：带着一台装了鸿蒙系统的开发机，去某大型历史景区当了一天AI产品验证员。说得更直白点，就是把自己写的一段小程序，接上某云平台的MaaS服务，在景区里临时搭了个“AI导游”——游客只对着手机说一句“这个铜缸是干什么用的”，系统就能完成语音识别、调用大模型、生成带历史细节的回答，顺带还能规划接下来应该往哪走。

整套东西拆开看，就是三个环节：鸿蒙系统负责把语音拾取、界面展示和硬件能力调度这类端侧事情做扎实；某云MaaS平台负责把大模型推理和内容生成这类重活接走；我自己真正要写的，只是中间的提示词设计、请求编排和异常兜底逻辑。没有自训模型，没有自建GPU集群，核心工作量几乎全花在业务设计和现场调优上。

这篇文章适合谁看？如果你正在做文旅数字化、智能客服、博物馆导览这类方向的AI应用，或者手上刚好有鸿蒙设备、想试试AI能力落地，再或者只是好奇普通人怎么用MaaS平台快速搭出一款AI产品，这篇记录都有参考价值。我会从需求拆解讲到架构选型，再讲到开发实测和现场踩坑，尽量把每个决策背后的原因说清楚，而不是只给一份结果清单。

1. 任务拆解：AI导游到底要解决哪些问题

1.1 需求分析：从“电子讲解器”到“对话式导览”

先说实话，如果没有AI能力，景区讲解系统其实早就做成“区域触发自动播放”了，人到哪个点位，设备就播放哪一段解说词。但这种定点播放的模式有个天然短板：用户只能被动接收系统预设的内容，没法追问。

AI导游真正要解决的，是让人用自然语言和知识系统自由对话。

我在做需求分析那天，在景区门口观察了半小时游客行为，发现大家问问题的方式比预设内容要复杂得多：

• “这个大殿是什么时候建的？”
• “门口的石狮子有什么讲究？”
• “为什么这里的屋顶颜色和旁边那座不一样？”
• “我从东门进，想先去最有名的点，怎么走最顺？”

这些问题，传统讲解器一个都应付不来。但如果用大模型，就需要拆解成三层能力：能不能听懂用户说什么（语音识别）、能不能找到对应的领域知识（知识检索）、能不能用自然又准确的语言组织成回答（文本生成）。这三件事恰好分别对应端侧语音能力、云端知识库和模型生成能力。

另外还有两个容易被忽略的隐性需求。一是回答要有出处意识，游客问到的历史信息不能张口就编；二是导览体验要有“陪伴感”，不是机械念百科，而是像真人导游那样在讲一个故事。这两点直接决定了我后面在提示词和知识库设计上的取舍。

1.2 选型思考：为什么是鸿蒙系统 + 某云MaaS

这套系统选鸿蒙，倒不完全是为了追“国产化”的时髦，而是它的几个特性在这个场景里确实用得上。

首先是分布式能力。多设备流转做得很顺，手机上的对话可以流转到蓝牙耳机、手表甚至景区大屏上，用户不用一直举着手机看。其次是卡片服务，可以把“正在讲解的文物”“下一个景点距离”这类高频信息直接推到桌面卡片上，不用频繁解锁打开App。再就是端侧语音处理，鸿蒙对麦克风权限管理、音频焦点控制、语音活动检测的处理比较细致，做对话打断、音量自适应这类功能时更顺手。

云端选MaaS的理由更直接：省事。MaaS是“模型即服务”的缩写，简单理解就是把大模型的部署、推理、更新这一整套复杂流程封装成API，调用方不需要关心GPU够不够、模型怎么部署、推理框架怎么调优，只要专心写业务逻辑就行。

这个选择对个人开发者尤其友好。如果自己搭推理服务，光是一张推理卡的成本就足够劝退绝大多数业余项目。而MaaS按调用量计费，几十块钱就能支撑一次景区试点。平台之间的差别，更多在于价格、并发上限和模型能力上限，真正让体验立住的，还是端侧能力编排和提示词设计。

2. 架构设计与提示词工程

2.1 端云协同：鸿蒙端和某云MaaS怎么分工

整个项目的架构其实不复杂，一句话就能说清楚：鸿蒙端负责感知和呈现，云端MaaS负责理解和生成。

鸿蒙端承担四个具体任务。

第一是语音输入。用户按住按钮说话，系统调用鸿蒙的语音识别能力，把音频转成文字。考虑到景区可能人声鼎沸，我设了两种模式：网络好的时候用在线识别，效果更准；网络差的时候切到端侧离线识别，至少保证基础问题能被理解。

第二是界面展示。对话消息列表用类似聊天软件气泡的方式呈现，左侧是用户提问，右侧是AI回答。每次回答里，路线建议单独用一张带方向感的卡片展示，文物简介则放在气泡正文里，结构比较清晰。

第三是位置感知。鸿蒙端获取当前定位，结合服务端预置的景区坐标点，判断用户最近的兴趣点，把“附近景点”作为上下文一起发给模型。这样用户问“这附近有什么”，AI能给出针对性回答，而不是在一堆景点里猜。

第四是请求编排。把用户文本、当前坐标、历史对话记录、知识库检索结果封装成完整请求体，发给MaaS的API，再解析返回结果渲染到界面。

云端MaaS这边，负责大模型推理。开发时我在控制台选定了合适的基座模型，通过REST API调用。鸿蒙端把JSON请求体发送过去，MaaS平台在云端做大量推理计算，返回自然语言回答。整个链路的性能瓶颈几乎都集中在这个环节，尤其是游客密集时段，API响应延迟会有明显波动。

为什么要这样分工？因为端侧设备算力和内存有限，部署大模型不现实，而且模型知识需要频繁更新，放云上更合理。但完全依赖云端也有风险，后面实测部分我会细讲，国庆当天真正让系统处在崩溃边缘的，恰恰不是模型能力，而是网络延迟。

2.2 提示词设计：让AI导游“像人一样”说话的三个关键

整个项目里，投入产出比最高的就是提示词设计。模型选型决定了能力上限，但提示词决定了用户感受到的体验质量。第一版迭代时，我把系统提示词写成了结构化的导游角色设定，核心是三个点。

第一点是角色边界。提示词里要明确告诉模型“你不是一个通用聊天助手，你是景区导游”。我踩过一个很典型的坑：一开始只写了“请你作为景区导游回答用户问题”，结果模型时而像客服，时而像百科全书，甚至还会给用户推荐其他城市的景点。后来改成多段式描述，包含背景、语气、职责边界，效果立刻稳了。

第二点是知识边界。历史信息经不起模型发挥。我在提示词里明确加了一条规则：“当你对具体文物或历史细节不确定时，必须回答‘这个细节我暂时无法确认’，不得编造内容。”同时，后端在调用模型前，会先从景区结构化知识库里检索相关条目，把结果作为参考片段拼进提示词，相当于给模型一份“开卷考试材料”，让它在限定材料范围内作答，幻觉概率明显下降。

第三点是输出格式。为了前端能稳定解析，我要求模型回答包含正文文本和一个可选的路线建议字段。参考提示词大概长这样：

你是这个景区的资深导游，熟悉景区内所有文物和建筑背景。 你的语气亲切自然，像一位经验丰富的朋友在讲故事，避免官方背书式的严肃表达。 每次回答控制在150字以内，除非用户主动要求详细说明。 如果用户问的内容你不确定，必须明确回答“这个细节我暂时无法确认”，不要编造。 回答格式要求：正文使用一段文字，如有路线建议，在最后单独给出“路线建议：”字段。 以下是景区知识库中与用户问题相关的参考信息，请基于这些信息回答： [知识库检索结果]

这段提示词看着简单，实际迭代了五六个版本。前几次要么提示太啰嗦，模型输出经常超长；要么边界太松，模型自作主张加了很多景区外的信息。最终版本把“知识库检索结果”放在提示词末尾，让模型感知到“这份材料才是回答依据”，约束效果比在开头强调“你要遵守知识库”好得多。

3. 实战记录：从原型到现场的全过程

3.1 开发阶段：三件事快速搭出能跑的Demo

个人项目最怕拖。我给自己定的原则是“能跑优先，优化放后面”。从零到第一版可用的Demo，大概花了三天，核心就是完成三件事。

第一件，创建鸿蒙应用项目。我用开发者工具初始化空应用，页面用ArkUI写。第一个页面很简单：顶部景区名称，中间对话消息列表，底部一个“按住说话”按钮和输入框。ArkUI的声明式写法对做过前端的人来说上手很快，状态管理比较直观，不需要额外引复杂框架。

第二件，接入语音识别。鸿蒙系统提供语音识别服务，通过权限申请和API调用实现“按住说话→转文字”。有件小事值得注意：为了应对嘈杂环境，我把语音识别模式设成“普通话+领域词汇增强”，把景区特有名词提前加进识别词表。实测下来，识别准确率从大概七成提升到了接近九成。

第三件，对接MaaS API。我在控制台申请了API密钥，配置模型参数，temperature设为0.3控制回答稳定性，max_tokens设为300防止回复过长。鸿蒙端用HTTP库POST请求到接口，请求体长这样：

{ "model": "导览模型", "messages": [ {"role": "system", "content": "...（系统提示词）..."}, {"role": "user", "content": "这个铜缸是干什么用的？"} ], "temperature": 0.3, "max_tokens": 300 }

前端只需要拿到返回的content字段，渲染到气泡里，一条完整链路就通了。

整个开发阶段三天，第一天搭框架和语音识别，第二天接MaaS，第三天打磨提示词和异常处理。我的体会是：MaaS平台把基础设施复杂度全部藏起来了，真正耗时间的，是提示词调优和边界测试。

3.2 现场实测：国庆高峰期的真实表现

国庆当天，我带着开发机和一台测试手机到现场做实测。虽然已经有了心理准备，但真实景区环境还是给了几个下马威。

第一个问题是人多声音杂。我站在一处热门文物展柜前测试，语音识别的误识别率明显上升。游客问“这个展品是什么”，系统偶尔听成“这个展台是什么”，差之毫厘谬以千里。解决办法是在端侧把高频误识别词也加进识别词表，再配一个“二次确认”逻辑：当识别结果置信度低，且模型回答里包含地点信息时，前端会弹出小卡片问“您问的是不是某某文物”，让用户点一下确认，避免直接给错答案。

第二个问题是网络延迟不稳定。高峰期景区内无线网络压力很大，API请求偶尔要五六秒才回。对用户来说，超过三秒没反应，大部分人就会退出。我加了一套超时控制和重试机制：请求三秒没返回，前端先展示“正在思考中”的状态；五秒还没返回，切换成简洁版问题重发一次；重发仍然超时，退回离线知识库的快捷回答。这套兜底思路，有点像“大模型答不上来，就用小知识库顶一下”，虽然回答不够聪明，但至少让对话不中断。

第三个问题是游客提问发散。有些人会问“这附近有什么好吃的”“门票多少钱”，这些和导览相关性不高。我后来在提示词里加了边界规则：遇到这类问题优先引导回导览本身，不相关的内容可以简短回答但不展开。这样既没冷落用户，也不会让AI跑题。

现场三小时实测，我记录了几组关键数据：单次提问的平均对话时延在1.8秒左右，高峰期会涨到4秒以上；语音识别准确率在安静角落能到90%以上，在嘈杂展区掉到75%左右；用户连续追问超过三轮的比例约35%，说明对话式导览确实能激发探索欲。这些数据在正式技术文档里不算漂亮，但对于一个三天开发量的个人项目来说，已经足够支撑“体验可用”的判断。

4. 常见问题与调优经验

4.1 踩过的坑：三件看起来是小事但影响很大的细节

开发这个项目，有三件看着不起眼的坑，实际对体验影响很大。

第一个坑是没设意图边界。最初的提示词只说“你是导游”，没说“你不是什么”。结果模型面对无关问题时，会像聊天机器人一样不停回复，甚至有游客闲下来跟它聊了十分钟家常。后来我在提示词里明确“职责范围仅限于景区讲解、路线指引和参观建议，其他话题可以礼貌回避并引导回导览”，效果立竿见影。

第二个坑是上下文无限膨胀。多轮对话时，如果把历史记录全部塞进请求体，请求体会越来越长，不仅拖慢延迟，费用也水涨船高。我在鸿蒙端做了滑动窗口，只保留最近四轮对话；另外在每次请求前做一次“意图压缩”，把历史里提到的关键实体（文物名、方位词、时间词）提炼成简短摘要一起发给模型。这样既保留上下文，又控制住了请求大小。

第三个坑是没做结果缓存。国庆现场实测发现，很多游客问的是同一批问题，比如“这里最有名的文物是什么”“游览路线怎么规划”。如果不做任何缓存，每个游客来都打一次模型，费钱又费时。我在服务端加了一层简单缓存，按“问题+位置”作为key，命中后直接返回，完全绕开模型推理。实测下来，热门问题的缓存命中率超过40%，整体延迟也因此降了不少。

4.2 调优心得：几个可以直接照抄的参数

如果你也想快速上手类似项目，有四个参数和策略值得记下来。

一是temperature，我设置在0.2到0.4之间。导览场景追求准确，温度太高容易让模型自由发挥、编造历史信息；太低则回答会过于机械，缺少导游味。

二是max_tokens，设置为300到500。太短回答不够完整，太长又让用户在界面上翻页，体验反而不佳。300字正好覆盖“一段讲解+一句路线建议”的常态输出。

三是请求超时，建议累计重试两次，总超时上限控制在8秒内。超过这个时间，不如直接降级到离线回答，不要硬等。

四是离线兜底词库。准备一张“常见问题+关键词”的映射表，当云端请求失败时用本地规则回复基础问题。哪怕只是一句“当前网络繁忙，您可以试试问‘这个大殿是哪年建的’”，也能防止对话彻底断开。

这些数字看起来简单，但背后都是现场反馈换来的：温度过高导致说错文物年代，tokens太短导致回答戛然而止，超时过长导致用户等不及离开，没有兜底导致断网后完全不可用。参数调优，本质上是用代码把产品体验中能预见的意外都兜住。

4.3 后续可以怎么扩展

这次项目验证的不只是某个景区的导游，更是一个可以复用的模式。如果后续认真做产品化，有几个方向我愿意继续投入。

一是加入多模态能力。MaaS平台的模型普遍支持图片输入，游客拍一张文物照片，AI直接识别并讲解，导览体验会完全不一样。

二是做跨设备流转。利用鸿蒙的分布式特性，让用户在手机上提问，回答内容同步到智能手表或景区大屏，摆脱“一直举着手机”的束缚。

三是接入票务和实时人流数据。让AI导游不仅能讲文物，还能帮游客避开拥挤路线。这个方向需要更多后端系统配合，但产品价值会更大。

我个人体会是，AI导游这类应用的门槛，已经从“会不会训练模型”变成了“能不能把模型用好”。MaaS平台把基础设施门槛降到几乎为零，鸿蒙又提供了稳定的端侧能力和设备生态，剩下的比拼，其实是产品设计和对场景的理解。如果你也想做个类似的东西，不用纠结要不要先学模型训练，直接从一个具体小场景开始试，反而是上手最快的路径。

这次记录最大的价值，不在技术多前沿，而在于证明了一件事：一个普通开发者，凭一个小团队甚至一个人，用一个假期加几天时间，就能在真实场景里搭建并验证一款AI产品。剩下的事情，无非是在体验细节上慢慢磨。希望这篇记录能给你一点可复用的思路，如果后面真把它做成产品了，我再回来写第二篇实战记录。