企业官网建设流程全解析

1. 项目概述：为什么我会在国庆假期验证一版 AI 导游

国庆当天中午，我挤在宫殿景区南门的人群里，手里攥着一台中端鸿蒙设备。手机里装的既不是普通地图，也不是官方导览 App，而是一个我打磨了快两周的 Demo：基于 HarmonyOS 的 AI 导游客户端，图片识别、语音识别、知识问答全部走云端 MaaS 平台的模型 API。旁边有位阿姨在问人工讲解多少钱，而我在同一秒内已经让应用识别出面前那座大殿，开始播放屋顶制式的讲解。

我为什么非挑国庆这个最拥挤的时间做测试？因为 AI 导游这类产品，恰恰是在高并发、弱网络、高遮挡场景下最容易暴露问题。如果你只在办公室联调，模型不会认错建筑，网络也不抖动，答错了还能重新试。可游客真实遇到的情况是：人挤人、手机信号时好时坏、光线刺眼，你举起手机时画面里塞满了陌生人。这套 Demo 能不能被真正带出门，比任何单元测试都更有说服力。

这篇文章写给三类人看。第一类是刚开始接触 MaaS 和鸿蒙开发的人，想看看端云协同到底怎么落地；第二类是做文旅信息化的人，想评估 AI 导览能不能替代人工讲解；第三类是打算自己做景区导游应用的独立开发者，可以直接抄我整理的方案和坑位。下面先讲清这个项目要解决什么问题，再逐步拆技术链路、上实操细节和现场数据。

1.1 人工讲解太贵，导览机又太傻

景区里人工讲解的价值很直观：有互动、能追问、会根据游客兴趣调整节奏。但在客流高峰期，一个好讲解员可能要等很久，价格也明显超出多数游客的心理线。电子导览机倒是便宜，可内容是固定的，你走到某个点位它机械地播一段词，想多问一句“旁边这个建筑以前是干嘛的”完全没有通道。手机搜索最灵活，但你需要在人群中反复切换 App、读长文字、听音频，体验非常碎片。

AI 导游要补的正是这个空缺：它像讲解员一样允许自由提问，又像导览机一样按位置和视觉触发，还比人工稳定，不会因为带团多了就语气疲劳。我这次做的 Demo，就是先把这些能力的最短闭环跑通：拍照识别建筑、语音提问、云端生成回答并播报，再加上离线兜底。这也是“AI 导游”这个说法在实测里最接地气的价值体现。

1.2 这个 Demo 到底做了什么

用一个词概括，它是“端侧感知 + 云端分析 + 知识库约束”的导览壳。端侧用鸿蒙的摄像头、麦克风、定位和传感器采集现场信号；云端统一通过 MaaS 平台调用多个模型能力，包括目标检测、图像特征、语音转文字、文本向量化和大模型对话；为了让回答不胡说，额外接了一个只包含该景区资料的检索增强知识库。用户看到的是“对着建筑拍照，得到一分钟语音讲解”这种极简交互，内部链路其实相当长。

我特意没有做太重的产品化设计。因为旅行场景下，游客没有耐心研究菜单，打开就是拍照或说话，两个动作能解决问题就够了。这也决定了技术选型要尽量简单：能用成熟 API 就不自己训练模型，能缓存就不重复请求，能降级就不让应用卡死。MaaS 在这里的价值很明显，它把“我可能需要一张 GPU 卡”替换成“我按请求付费”，对独立开发者和小团队特别友好。

2. 技术链路拆解：鸿蒙端 + MaaS 后端各司其职

这个项目最大的特点不是某个模型多复杂，而是链路很长：拍照触发识别、语音触发问答、定位辅助纠错、结果做缓存。如果架构不提前定清楚，后续调试会非常痛苦。我先把整体分工拆开讲，再讲为什么选鸿蒙、为什么不全放本地推理。

2.1 整体架构与核心模块

从数据流向看，应用内主要分四段：端侧应用、端侧策略、云端网关、MaaS 平台。端侧负责采集和展示，端侧策略负责请求控制和降级，云端网关负责鉴权限流和计费，MaaS 平台提供各类模型服务。

游客每拍一次照，端侧先把图片压缩到 800KB 以内，带上定位和朝向信息上传到网关；网关完成鉴权后把请求转发给视觉模型，模型返回“候选建筑 ID + 置信度”；端侧再用候选分数、距离和历史路径做一次后处理，决定最终播报哪一段内容。语音问答流程类似，录音先转文字，再进知识库检索，最后拼接成大模型对话。

MaaS 在这个链路里不是一个单一接口，而是一个能力市场。你可以把它理解成“用电不用自己建电厂”：模型训练、部署、扩容、运维都不是我操心的事，我只关心每次调用返回什么、花了多少钱。对一个独立开发者做的旅行应用来说，这几乎是唯一切合实际的方案。

2.2 为什么选鸿蒙而不是小程序或 H5

我最早做过方案对比，考虑了小程序、H5 页面和鸿蒙原生应用三个方向。如果只做“输入景点名看介绍”的工具，小程序完全够。但 AI 导游要连续调用相机预览、后台录音、前台卡片提醒，还要感知用户是否停留在某个位置，这些能力在小程序里要么权限受限，要么容易被系统回收。H5 在弱网下的表现和相机调用体验也一般。

鸿蒙这边有几个很实际的吸引力。第一，能以元服务的方式让游客免安装体验，扫码就能打开，降低使用门槛。第二，一次开发可以后续扩展到平板、折叠屏、车机和智慧屏，比如车内导航也能复用同一套导览逻辑。第三，它对相机、定位、传感器权限管理更直接，可以通过系统机制保证后台任务不被随意杀掉。这些点单独看不算惊艳，但组合起来非常适合景区场景。

当然，选鸿蒙也有代价：能拿来做真机调试的设备比普通安卓少，兼容性需要花时间验证。我的做法是先不做太多动画和自定义组件，把核心链路用最基础的 ArkTS 组件写通，确保中低端设备也能跑起来。

2.3 为什么不全塞进端侧模型

我也试过纯端侧方案，毕竟游客最怕“没网不能用”。但几个问题很快让我放弃：首先是安装包体积，一个像样的多模态模型动辄几个 GB，游客可能为逛一次景区不愿意下这么大的应用；其次是中低端手机推理慢，模型加载后的首帧响应往往要好几秒，国庆烈日下没人等得起；最后是迭代问题，景区资料一个月可能更新一次，端侧模型要重新发版，而云端 API 换个版本参数就行。

所以我选择了“端侧捕获、云端理解、本地兜底”的混合策略。网络好的时候做高清识别和大模型回答；断网或弱网时，端侧通过 GPS 触发本地缓存的讲解词，保证最基础的导览可用。这个方案算不上技术最前沿，但对真实用户体验最友好。

3. 核心细节与实操要点：图像识别、语音问答、知识库

方案定了，真正的工程量全在细节。这一章我挑三个最核心的环节：图像识别怎么减少误判、语音问答怎么防止胡说、知识库数据怎么整理。

3.1 图像识别：先检测建筑部件，再做二次判断

宫廷建筑最大的问题是“长得像”。我踩的第一个坑，就是模型把东侧院落识别成西侧院落，原因很简单：红墙黄瓦，远景拍摄时屋顶制式差异不清晰，光线一变特征就乱。单纯拿整张图做分类，压不住这种易混淆。

我改成两段式方案。第一步，先用目标检测模型找出画面里的建筑主体框，而不是做全图分类；第二步，对主体框做二次特征判断，把屋顶制式、门窗样式、匾额区域、相对周边建筑的位置都作为附加输入。最后拿模型输出里的 top3 候选，再和 GPS 坐标做距离过滤。

def match_building(photo_gps, model_output): candidates = [b for b in model_output if b.score > 0.6] candidates = [b for b in candidates if calc_distance(photo_gps, b.gps_anchor) < 50] if not candidates: return nearest_building_from_gps(photo_gps) return sorted(candidates, key=lambda b: b.score)[0]

用这段逻辑跑下来，识别准确率明显提升。核心参数我定为：置信度阈值 0.6、GPS 过滤半径 50 米、返回 top3。阈值没有定得很高，因为游客拍照时大概率存在遮挡或手抖，太高的阈值反而会把真实目标丢弃；低置信度的结果再靠定位和服务逻辑补救，比一味提高识别分数更可靠。

还要补充一个交互层：“易混淆集合”机制。我把容易互相认错的建筑放进同一分组，例如东西两侧几乎对称的殿宇。一旦模型输出的 top3 落在同一个集合里，App 不会直接播报，而是弹出一行简短确认：“您指的是东侧那座殿还是西侧那座殿？”用户点一下或说一句话，结果就进本地缓存。这样做既避免错误讲解，又顺手收集了难得的纠错样本。

3.2 语音问答：不要直接全量大模型，用 RAG 兜底

游客最常用的一句话是“这是什么地方，以前用来干什么的”。如果直接把语音转成的文字丢给通用大模型，它大概率能凑出一段流畅的介绍，但关键信息很可能有误，尤其是建造年份、用途变更这类细节。我不允许导游在核心事实上出错，所以接入了 RAG。

流程是：录音转文字后，先把问题做关键词拆解，用向量检索去知识库里找最相关的 5 个片段；再把“资料片段 + 用户问题 + 角色设定”一起交给 MaaS 的对话模型生成回答。回答生成后做长度限制和来源检查，最后转成语音播报。链路比直接调用多了一步，但换来的是“每个事实都有资料可溯”。

下面是我用的提示词模板：

你是一名严谨的景区导览助手。请只依据系统提供的资料片段回答。 如果资料中没有相关内容，请直接说“这个信息我不太确定”。 若用户问题涉及未经证实的传说，必须说明那只是传说。 回答控制在150字以内，语气像现场讲解，但不夸大。

注意，提示词里加了两个看起来反常识的约束：一是允许说“不知道”，二是让模型主动质疑“传说”。我这么做是为了防幻觉。游客能接受导游说“我不确定”，但接受不了导游一本正经地讲错知识。让模型自带批判性，比单纯求流畅更重要。

3.3 知识库数据怎么准备

知识库说白了就是结构化资料。我不能手工给每座建筑写长篇大论，也不建议这么做。更合理的做法是抓取公开基础资料，统一整理成 CSV，再按固定字段切块。

building_id,name,alias,location,era,style,function,story,keywords,protect_level h01,中轴大殿1,大殿1,中轴线第一进,明清,重檐庑殿顶,礼仪场所,主要用于大型典礼...,屋顶,国保单位 e03,东侧院落3,东宫3,东侧路第三进,明清,硬山顶,生活区,曾作为日常居住...,生活,国保单位

每一条记录切成长度不超过 500 字的片段，再通过向量化接口转成向量存进向量库。检索时带两个过滤条件：一是空间范围，只允许检索 GPS 附近 200 米内的建筑；二是关键词元信息，比如建筑 ID、别名、类型。这两个过滤条件能把误召回压得很低。我还会人工维护一份常见问题问答表，把游客最可能问的三十个问题提前写好，比如“为什么屋顶上有小兽”“为什么门钉是九的倍数”，让高频问题命中率更高、回答更稳定。

数据准备的关键心得是：宁可口径小一点，也不要让大段模糊资料进入上下文。片段越聚焦，检索准确率越高，模型引用时越不容易跑偏。

提示：如果测试时遇到模型置信度不高，请先让 GPS 兜底结果生效，再通过用户反馈修正知识库对应条目的检索权重。不要急着把阈值调到 0.9，那会带来大量漏识别。

4. 国庆现场实测：从排队到闭馆的真实记录

所有联调在节前都完成了，但真正让我手心冒汗的是国庆当天的人流量。这一章我把现场环境、关键数据和翻车场景都记录一遍，给以后做文旅项目的人留个参考。

4.1 现场环境与实测数据

当天的场景非常极端：室外温度高、游客密集、4G/5G 信号被大量人群摊薄，排队入场时手机基本处于半断网状态。我用的是一台中端鸿蒙手机，屏幕亮度调到最高，摄像头频繁调用，这本身就很考验发热和续航。为了避免网络波动影响体验，测试前我先预加载了三十个最热门景点的离线讲解词。

实测数据按场景记录如下，P50 表示一半请求耗时不超过该值，P90 表示 90% 请求不超过该值：

整体上，一个完整的“拍照 → 识别 → 讲解”闭环大约需要 2.5 秒，语音问答约 3 秒。对展厅体验可能觉得有点慢，但在游客普遍慢慢逛的景区里，这个延迟可以接受。真正要命的不是延迟，而是网络抖动导致的请求超时和排队。

4.2 典型案例记录：从拍照到讲解

我在中轴线最前端那座大殿前做了第一次完整验证。当时阳光很刺眼，屋顶细节被强光削掉一部分，我举起手机拍了一张，画面里还混进来前面游客的遮阳伞。第一次模型给的结果是 top1 置信度只有 0.55，属于非常不自信的状态。按我预设的规则，0.55 低于 0.6 阈值，App 没有直接播报，而是结合 GPS 判断我确实站在该殿正南约 30 米的位置，于是优先生成了“最近建筑”的讲解。

这个兜底逻辑在户外实测里非常重要。只守视觉阈值，游客体验会很差；把位置信息作为硬约束，即使视觉不自信也能给出一个基本正确的开始。随后我语音追问“屋顶上为什么有这么多小兽”，系统检索到知识库里的“脊兽”条目，模型在 150 字内解释：小兽数量与建筑等级有关，数量越多等级越高，并补充了一句这是礼制的一部分，属于比较可靠的史料。这个回答自然、有边界，没有胡编。

4.3 遇到的最大问题：信号抖动与并发排队

问题集中在午后入场高峰。上传图片后，云端有时候 3 秒没返回，有时候直接超时 120 秒。我翻了端侧日志，发现根因不是模型太慢，而是网关层连接池被打满，大量请求在排队。更糟的是，我的初次实现没有做并发限制，用户连续拍三张照片，三个请求同时发出去，不仅把队列拖得更长，还让 Token 消耗瞬间飙升。

后来我改了两处。第一，端侧请求队列只保留一个在途请求，后续拍照先存本地，等上一个完成后按时间戳依次发送。第二，统一超时时间从 120 秒缩短到 10 秒，超时后自动走“GPS 最近景点”降级。同时预加载讲解词起了救命作用，弱网时端侧直接读缓存，游客感知不到云端已经超时。最终优化后，大流量时段识别准确率比早上略降，但“卡死”和“长时间转圈”的问题基本消失。

5. 避坑指南：从“能跑”到“真正能带出门”

很多人做完 Demo 觉得“能识别、能回答”就万事大吉，但真带出门后会遇到一堆奇怪问题。我把最容易翻车的四个坑和处理方案整理成速查表，再补几条独家心得。

5.1 最容易翻车的四个坑

认错建筑这个坑，我第一次内测时完全没意识到。因为内测在傍晚人少、光线好的环境进行，模型表现稳定；一到国庆上午，人流遮挡和强光干扰让置信度普遍下降。如果产品上线，建议从一开始就做“易混淆组”人工标注，而不是依赖模型自己学习区分。对文旅应用来说，识别错的伤害远大于“识别不出来”——识别不出来时游客可能觉得是技术问题，识别错了则是对事实的误导。

Token 费用失控是另一种隐蔽问题。游客的耐心有限，但对话上下文会累积。如果不限制，一个人问二十个问题可能烧掉上千 Token，一百个人就是十万 Token，国庆一天下来账单非常夸张。在商业产品里，这不是“这点钱无所谓”的小事，而是决定商业模式能否成立的成本结构。

5.2 我自己的流程与规范

除了技术，有三条流程规范我强烈建议保留下来。

第一，默认禁止闪光灯。古建和文物对光线敏感，游客拍照时不应该被引导使用闪光灯。App 在弱光环境会自动提示关闭闪光灯，这不仅是识别需要，也是对文物的保护。

第二，不采集游客人脸。拍照识别时，画面里出现其他游客是必然的。我在端侧上传前会做人脸检测并打码，云端只收到建筑区域特征。这不只是为了隐私合规，也是让游客愿意继续使用的基础。

第三，讲解词要克制。我最初生成的介绍动不动三四百字，数据很全，但现场根本没人听。后来把每段语音控制在 150 字以内，先说“这是什么”，再说“一个最特别的地方”，最后给一句“你可以接着问”，体验立刻不一样。AI 导游不是搜索引擎，它更像一个随行朋友，话太多反而是负担。

6. 复盘与后续扩展：这套东西还能做什么

严格来说，这次国庆测试只是把 AI 导游的最短闭环验证了一遍。但整个架构的扩展性比我想象得好，因为核心链路已经和具体地点解耦。

6.1 换个园区只需换知识库

这套体系里，端侧逻辑、图像识别策略、语音问答链路都和具体地点没有强绑定。要换到另一个园区，我需要做的只是更新知识库 CSV、重新向量化、把易混淆分组和 GPS 锚点重新标注一遍。博物馆场景可以把建筑识别换成展品识别，植物园可以换成叶片识别，大学校园甚至可以做成新生导览。

也就是说，我已经搭了一个“按请求付费的导览壳”。谁有内容，谁就能快速套一层壳上线。对文旅部门来说，这种组装效率比从零开发经济得多；对独立开发者来说，也可以把它当成模板型产品来推。

6.2 成本估算与下一步想法

成本大体分三块：MaaS 推理费用、向量库存储费用、端侧开发人力。推理费用按调用次数算，图片识别、语音转文字、大模型回答各自独立计费。实测下来，如果只在高客流时段启用高精度识别，其余时间用低成本的离线缓存讲解，单次完整导览的成本能压到很低的水平。真正贵的是频繁对话，所以我才把热门问题做成缓存问答，而不是每次都让大模型重新生成。

这次从国庆现场带回工作室后，我最深的感受是：AI 导游这个产品的门槛不在于某个模型跑得多快，而在于数据准确度和交互克制。模型可以等网络变好、等硬件升级，但“敢把话说准”和“知道什么时候闭嘴”这两件事，需要从一开始就写进产品逻辑里。接下来我计划把鸿蒙元服务入口做深，用户扫码后不用下载完整应用，通过卡片直接唤起导览；再加位置触发，靠近某个建筑时手机轻震提醒，而不是让游客一直举着屏幕。AR 导航和多语言支持也排进了计划，但优先级都放在稳定性和成本之后。毕竟一次国庆实测已经让我看清，现场网络状态和游客耐心，才是这个产品最需要伺候的两位老师。