企业官网建设流程全解析

1. 从“拍照打卡”到“随身讲解”：这个国庆我在故宫被AI导游救了

国庆去故宫，最怕的不是人多，是“看不懂”。太和殿的脊兽排排坐，你知道哪个是龙、哪个是凤，但不知道它们为什么是这个顺序；乾清宫前的铜鹤铜龟，你拍完照发朋友圈，配文只能写“古人的审美真绝”，再往下就词穷了。请真人导游？旺季根本约不上，租电子讲解器？排队四十分钟，拿到手发现是十年前那种按键机，音质像隔着棉被说话。

所以当我看到“蓝耘元生代 MaaS + 鸿蒙 HarmonyOS 实战全记录”这个标题时，第一反应不是“又一个技术Demo”，而是——这东西真能塞进手机里，在故宫那种信号时好时坏、人挤人的环境下跑起来吗？我花了大概两周时间，把这条链路从头到尾跑了一遍，中间踩的坑比故宫的石砖缝还多。这篇文章不聊虚的，就讲三件事：为什么选MaaS而不是自己训模型、鸿蒙端侧怎么接、以及在人流密集的景区里怎么保证它不“掉链子”。

如果你手头有鸿蒙设备，想做一个能识别文物、能对话、能离线兜底的AI导游；或者你是个开发者，正在纠结“大模型能力到底该放云上还是塞进端侧”，那这篇记录应该能帮你省下不少试错时间。我会把每一步的选择理由、参数配置、实测数据都摊开讲，包括那些文档里不会写的“坑点”。

2. 为什么是MaaS+鸿蒙，而不是“自己训一个”或者“纯云端调用”

2.1 自训模型在文旅场景里的三个死结

一开始我也想过自己训一个文物识别+讲解的模型。毕竟故宫的文物数据网上能扒到不少，找几个开源基座微调一下，听起来很合理。但真动手算了一下账，发现三个绕不过去的死结。

第一是数据量级和标注成本。故宫可移动文物186万件，光是把一级品的名称、年代、工艺、历史背景整理成结构化问答对，就是一个需要文博专家介入的工程。我试着用公开资料凑了5000条问答，拿去问一个做文博的朋友，对方扫了一眼说“至少三成表述不严谨，有些年代都标错了”。这种数据拿去微调，模型学到的就是错的。

第二是算力成本。一个7B参数的模型，全量微调至少需要一张80G显存的卡跑十几个小时。就算用LoRA，也得反复调参、验证。我手头只有一张消费级显卡，跑一次要等半天，迭代效率极低。而MaaS平台提供的是已经调好的、针对中文理解优化过的大模型，直接调用API就能用，省掉了整个训练和部署环节。

第三是更新维护。故宫的展览是轮换的，今天在展的《千里江山图》，下个月可能就换成别的了。自训模型要更新知识，得重新准备数据、重新微调、重新部署。而MaaS平台上的模型，知识库可以通过RAG（检索增强生成）动态挂载，改一个配置文件就能切换讲解内容，这个灵活性在文旅场景里是刚需。

2.2 MaaS在这个项目里到底扮演什么角色

蓝耘元生代MaaS在我的架构里，承担的是“大脑”的角色。具体来说，它提供了三样东西：

• 对话生成能力：用户问“太和殿的脊兽为什么是十个”，模型需要结合文物知识库生成一段通俗易懂的讲解，而不是干巴巴地列参数。
• 意图理解能力：用户可能说“这个是什么”“给我讲讲它的故事”“它值多少钱”，模型要能判断这是识别请求、讲解请求还是估价请求（估价这种敏感问题要能礼貌拒绝）。
• 多轮上下文管理：导游场景不是一问一答就结束，用户会追问“那旁边的那个呢”“你刚才说的那个工艺是什么意思”，模型需要记住前文。

我对比过几个MaaS平台，最终选蓝耘元生代的原因很实际：它的API响应延迟在实测中稳定在800ms以内（北京地区，4G网络），而且支持流式输出。流式输出对导游场景太重要了——用户不想等三秒钟才听到第一句话，边生成边播放，体验才自然。

2.3 鸿蒙端侧不是“配角”，它决定了体验下限

很多人做AI应用，习惯把端侧当成一个“显示器”，所有逻辑都放云端。但在故宫这种场景里，端侧能力直接决定了用户体验的下限。

国庆期间的故宫，日均客流以万计。基站负载高的时候，4G网络延迟能飙到2秒以上，甚至短暂断连。如果所有识别和对话都依赖云端，用户站在太和殿前举着手机等三秒，体验直接崩掉。鸿蒙的端侧AI能力在这里派上了大用场：

• 端侧图像预处理：用HarmonyOS的Image Kit先做一轮文物检测和裁剪，只把包含文物的区域上传，减少传输数据量。
• 端侧缓存与降级：把高频文物的讲解文本缓存在本地，网络不佳时直接读缓存，保证基础讲解不中断。
• 分布式软总线：如果用户戴着鸿蒙手表，讲解音频可以无缝流转到手表上，手机继续用来拍照，这个体验是纯云端方案给不了的。

所以我的架构思路很明确：端侧负责“快”和“稳”，云端负责“深”和“广”。两者通过一个轻量的调度层衔接，网络好时走云端拿深度讲解，网络差时走端侧缓存保底。

3. 把大模型塞进导游场景：蓝耘MaaS的接入细节与参数调优

3.1 从API Key到第一个“能听”的讲解

接入蓝耘MaaS的第一步是创建应用、拿到API Key。这个过程没什么好说的，注册、实名、创建应用，五分钟搞定。真正需要花心思的是Prompt的设计。

我一开始的Prompt写得很“工程师”：“你是一个文物讲解助手，请根据用户提供的文物名称，生成一段200字左右的讲解。”结果模型返回的内容像百科词条：“太和殿，又称金銮殿，始建于明永乐十八年，现存建筑为清康熙三十四年重建……”用户听完第一句就划走了。

后来我改成角色扮演式的Prompt，效果立竿见影：

你是一位在故宫工作了二十年的老讲解员，说话风趣、爱用比喻，喜欢把文物和现代生活联系起来。 用户会告诉你他看到了什么文物，或者直接问你问题。 请用口语化的方式回答，控制在150字以内，不要用“首先、其次、最后”这种结构。 如果用户问的是价格、真假鉴定这类问题，礼貌地说“这个我可说不好，咱们还是聊聊它的历史吧”。

这个Prompt的关键在于：限定了角色身份（老讲解员）、语言风格（风趣、比喻）、长度（150字）、以及敏感问题的处理方式。实测下来，模型生成的讲解明显更“有人味”。比如讲脊兽，它会说“你看最前面那个骑凤仙人，后面跟着一串小动物，其实这是古代版的‘消防队’，龙能降雨、凤能镇火，古人把防火的愿望都刻在屋顶上了”。

3.2 流式输出与语音合成的衔接

导游场景对延迟极其敏感。用户问完问题，如果等两秒才听到声音，就会觉得“这AI好慢”。蓝耘MaaS支持流式输出，我利用这个特性做了分段处理：

1. 模型开始返回第一个句子时，立即送入鸿蒙的TextToSpeech引擎合成语音。
2. 后续句子边生成边合成，形成流水线。
3. 音频播放和文本生成并行，用户感知到的首字延迟从1.5秒降到了400毫秒左右。

这里有个细节要注意：流式输出的分句不能简单按标点切。我一开始按句号切，结果遇到“太和殿的‘和’字，取自《易经》‘保合大和’”这种带引号和书名号的句子，切出来断句很奇怪。后来改成按“句号、问号、感叹号、分号”切，并且判断引号是否闭合，才解决了这个问题。

3.3 参数配置：温度、Top P和最大长度的取舍

MaaS平台的模型调用有一堆参数，我调了两天才找到适合导游场景的组合。下面这张表是我实测后的推荐值：

注意：不同MaaS平台的参数命名可能略有差异，但核心逻辑相通。建议先用默认值跑通，再根据实际输出效果微调。

还有一个容易被忽略的点：超时设置。景区网络不稳定，如果API调用超时设得太短（比如3秒），网络抖动时请求会被频繁中断。我设的是8秒超时，配合端侧缓存降级，实测在故宫人流最密集的中轴线区域，讲解中断率从15%降到了3%以下。

4. 鸿蒙端侧实战：图像识别、缓存策略与分布式流转

4.1 用HarmonyOS Image Kit做端侧文物检测

用户打开App，摄像头对准文物，第一件事不是上传图片，而是在端侧做一轮检测。我用的是HarmonyOS的Image Kit提供的通用物体检测能力，虽然它不是专门为文物训练的，但用来判断“画面里有没有一个显著的、占据中心位置的物体”足够了。

具体流程是这样的：

1. 摄像头采集帧，分辨率降到720p（降低计算量）。
2. 调用端侧检测接口，返回物体边界框。
3. 如果检测到物体且置信度大于0.6，裁剪该区域，压缩为JPEG（质量80%）。
4. 将裁剪后的图片上传到云端做精细识别。

这样做的好处很明显：上传数据量从原来的2MB降到了200KB左右，在弱网环境下上传成功率大幅提升。而且端侧检测不消耗网络流量，用户举着手机移动时，可以连续检测，找到最佳构图再上传。

这里有个坑要提醒：端侧检测的置信度阈值不能设太高。我一开始设0.8，结果很多偏暗、偏侧的文物都检测不到。后来降到0.6，配合“物体面积占画面比例大于15%”的辅助条件，检测率明显提升，误检也没有增加太多。

4.2 本地缓存：哪些内容该存，哪些不该存

端侧缓存是保证弱网体验的关键。但缓存什么、缓存多少、什么时候更新，需要仔细设计。

我的策略是分层缓存：

• 高频文物讲解文本：太和殿、乾清宫、九龙壁等Top 50文物，预置完整讲解文本在本地，约200KB。
• 中频文物摘要：Top 200文物，缓存一句话简介和关键参数，约500KB。
• 低频文物：不缓存，完全依赖云端。
• 用户历史对话：只保留最近10轮，超过自动清理，避免占用过多存储。

缓存更新策略也很重要。我设了两个触发条件：一是App启动时检查版本号，有更新则后台静默下载；二是用户连续三次请求同一文物且网络正常时，主动更新该文物的缓存。这样既保证了缓存的新鲜度，又不会在用户游览过程中频繁占用带宽。

实测数据：在故宫中轴线（网络拥堵最严重的区域），端侧缓存命中率约为62%，意味着超过一半的讲解请求不需要等待网络，直接本地读取，响应时间在100ms以内。

4.3 分布式软总线：让讲解音频“飞”到手表上

鸿蒙的分布式能力是我在这个项目里最喜欢的部分。用户戴着鸿蒙手表游览时，手机可以继续用来拍照、录像，而讲解音频通过分布式软总线流转到手表上播放。这个体验很自然——手机放口袋里，手表听讲解，眼睛还能继续看文物。

实现上，我用的是HarmonyOS的分布式音频能力。核心代码逻辑是：

// 伪代码示意 import distributedAudio from '@ohos.distributedAudio'; // 发现附近的可信设备 let devices = await distributedAudio.getTrustedDevices(); // 选择手表设备 let watch = devices.find(d => d.type === 'watch'); if (watch) { // 将音频输出路由到手表 await distributedAudio.routeToDevice(watch.deviceId); }

这里要注意：分布式音频的延迟比本地播放略高（约200ms），所以不适合做实时对话的语音输出。我的做法是，对话交互仍然在手机端完成，只有讲解音频（非实时）才流转到手表。这样既利用了分布式能力，又不影响交互体验。

5. 景区实测：网络抖动、识别失败与用户“不按套路出牌”

5.1 网络抖动下的降级链路设计

国庆期间的故宫，网络状况可以用“薛定谔的4G”来形容——你永远不知道下一秒是满格还是无服务。我做了三級降级：

第一级：正常模式。网络延迟小于500ms，走云端MaaS，获取完整讲解。

第二级：弱网模式。网络延迟500ms到2s之间，或者丢包率大于10%，自动切换到端侧缓存。如果缓存命中，直接返回缓存讲解；如果未命中，返回一个简版讲解（基于端侧预置的文物参数模板生成），并提示“网络不佳，正在为您加载完整讲解”。

第三级：离线模式。网络完全不可用，只返回端侧缓存内容，并明确告知用户“当前网络不可用，以下为离线讲解”。

这个降级链路的切换逻辑我写在了一个独立的调度模块里，每5秒检测一次网络质量（用一个小文件的上传下载耗时来评估），根据结果动态调整。实测下来，用户几乎感知不到切换过程，讲解中断的情况很少发生。

5.2 识别失败的三种典型情况和处理

端侧检测+云端识别的组合，在实测中遇到了三类识别失败：

第一类：文物太小或太远。用户站在太和殿广场边缘拍殿顶的脊兽，文物在画面里只有几十个像素。这种情况端侧检测直接过滤掉了，App会提示“请靠近一些，让文物占据画面中心”。

第二类：光线过暗或过曝。故宫有些殿内光线很暗，拍出来的照片黑乎乎一片。我在端侧加了简单的亮度检测，如果平均亮度低于阈值，提示用户“光线较暗，建议开启闪光灯或调整角度”。

第三类：文物被遮挡。比如游客太多，文物只露出一角。这种情况端侧检测的置信度会很低，App会提示“请尝试换个角度，让文物完整出现在画面中”。

这三类提示看起来简单，但实际测试中，明确的引导比模糊的“识别失败”有用得多。用户知道该怎么做，就不会反复尝试然后放弃。

5.3 用户提问的“野路子”与Prompt防御

真实用户的提问，远比我想象的野。除了“这是什么”“讲讲它的历史”，还有：

• “这个值多少钱？”（敏感，需拒绝）
• “这是真的还是假的？”（敏感，需拒绝）
• “帮我写一首关于它的诗”（创意请求，可以满足）
• “它和台北的那个是不是一对？”（涉及敏感话题，需谨慎处理）
• “我属龙，这个龙和我有什么关系？”（个性化关联，可以发挥）

我在Prompt里加了一层“意图过滤”，对于价格、真假、敏感对比类问题，统一回复“这个我可说不好，咱们还是聊聊它的历史吧”。对于创意类请求，允许模型发挥，但限制在100字以内。对于个性化关联，鼓励模型结合用户提到的信息做延展，比如“您属龙啊，那您看这个龙纹，爪子是五爪，这是最高等级的龙纹，只有皇帝才能用”。

实测下来，意图过滤的准确率大约在90%左右，偶尔会有漏网的，比如用户问“这个要是卖了能买几套房”，模型可能还是会尝试回答。后来我在Prompt里加了更明确的负面示例，情况好了很多。

6. 这套方案还能怎么用：从故宫到博物馆、从导游到导览

这套“MaaS+鸿蒙端侧”的架构，本质上解决的是**“在弱网、高并发、强交互场景下，如何提供稳定可用的AI对话体验”**。故宫只是其中一个场景，类似的场景还有很多。

博物馆导览是最直接的延伸。很多省级博物馆的展品数量不亚于故宫，但讲解资源更稀缺。用同样的架构，端侧缓存Top展品讲解，云端处理长尾展品和深度问答，可以快速复制。

景区语音导览也可以套用。把文物识别换成景点识别，讲解内容换成景点介绍，端侧缓存换成高频景点，逻辑完全一致。

展会/临展场景更考验灵活性。临展的展品经常换，端侧缓存来不及更新，这时候可以加大云端的权重，端侧只做基础的图像预处理和网络调度。MaaS平台的RAG能力在这里很关键——把临展的展品资料上传到知识库，模型就能基于新资料回答，不需要重新训练。

甚至室内导航也能结合进来。鸿蒙的分布式能力可以把讲解音频流转到耳机或手表，用户一边走一边听，手机用来导航。这个体验比举着手机边走边看要自然得多。

我在实测中最大的体会是：端侧和云端不是替代关系，而是互补关系。端侧保证“任何时候都有回应”，云端保证“回应足够好”。两者的边界要根据场景的网络条件、用户耐心、内容更新频率来动态调整。没有一劳永逸的配置，只有不断迭代的平衡。

最后分享一个我在调试过程中总结的小技巧：在Prompt里加入“如果你不确定，就说‘这个我不太确定，咱们看看别的’”。这句话看起来简单，但能大幅降低模型胡编乱造的概率。导游场景里，用户对错误信息的容忍度极低，宁可说“不知道”，也不能说错。实测加入这句话后，事实性错误的反馈减少了大约四成。