宜云无人车机系统 — 景区自动驾驶车机交互

面向景区无人驾驶观光车的车载交互系统,以语音为核心、触控为辅,让游客在行车中安全地获取导览、规划路线、与 AI 导游「小智」互动。

车机 HMI · 语音交互 · AI 交互
宜云无人车机系统主界面

作为产品经理,我对这个项目负责什么

这是我从 0 到 1 独立操盘的项目。我的角色不只是「画原型」,而是让「AI 语音 × 无人驾驶」这样一个全新的场景,变成能落地、可被验证的真实产品。

全链路 · 从 0 到 1

端到端独立操盘

从业务定位、竞品与场景分析,到信息架构、交互流程、高保真可运行原型,一个人完成「想法 → 可演示方案」的闭环,降低团队的沟通与试错成本。

AI × 业务落地

把 AI 变成可用产品

把「AI 导游 × 语音交互」从概念落成可运行原型:7 态语音状态机、三级降级、真实语音识别,为开发团队提供可以直接照做的实施方案。

决策 · 价值判断

先定义目标,再定方案

不把「界面炫不炫」当作成功标准,而是先锁定「安全、效率、易用」的可观测目标,在约束与风险之间做取舍,再去设计交互细节。

车机项目到今天已经走完「从想法到可执行方案」的阶段:原型方案确定,团队正在整理接口、进入开发。这个案例下面用 SWOT 复盘我是怎么思考、怎么取舍的。

— 项目当前阶段

项目背景与产品定位

从「无人驾驶观光车」这一特殊场景出发,明确车机系统要承载的核心价值,以及它与手机端产品在交互上的根本差异。

项目背景

宜云无人车机系统是面向景区无人驾驶观光车的车载交互原型系统(以杭州西湖景区为参考),为车内乘客提供集车辆状态监控、景区地图导览、AI 智能对话、语音唤醒控制于一体的一站式车机体验。车辆无需人工驾驶,乘客通过语音或触控完成导览与路线规划。

核心价值

把「车内自驾式操作」改造为语音为主、触控为辅的更安全交互:AI 导游「小智」全程陪伴,提供景点讲解、路线推荐、设施查询;乘客无需低头操作,就能在行驶中安全获取信息。

智能驾驶改变了「谁在开车」,车机交互就要回答「乘客在车里做什么」——不复制手机,而是重新设计一套属于行车场景的体验。

— 核心设计出发点

目标用户与场景痛点

以景区观光车的游客为核心用户,拆解他们在「无驾驶员、行驶中、多为第一次使用」场景下的真实困扰。

面向哪些用户

A

家庭 / 老年游客

第一次乘坐,对自动驾驶既好奇又谨慎,希望快速看懂「怎么用、安不安全、车往哪开」。

B

散客 / 自由行游客

习惯手机地图,但在无驾驶员的车内更希望通过语音获取导览,而非低头操作。

C

团队 / 游览团

需要清晰的路线推荐与景点讲解,对「沿途看到什么、下一站去哪」有明确预期。

完整使用流程

1

扫码用车

上车扫码进入欢迎界面,三步说明用车流程。

2

新手引导

四步交互引导,30 秒理解核心功能。

3

语音 / 触控导览

唤醒「小智」问路、听讲解,或触控地图规划。

4

结束结算

结束用车,展示行程明细并自动退出。

核心痛点

01

行车中操作不便

车辆行驶中,乘客难以像在手机上那样低头、双手操作;纯触控方案在颠簸与安全上都不合适。

02

信息获取效率低

「去哪玩、怎么走、有哪些景点」等高频问题缺乏即时答案,游客需要反复看地图、问人。

03

缺乏驾驶安全感

无人驾驶让乘客对「是否可靠」缺乏信任,需要车辆状态、自动驾驶状态的清晰反馈来建立安全感。

04

首次使用门槛高

面对全新车机界面,游客不清楚能做什么、怎么操作,需要一个低学习成本的引导。

决策复盘:用 SWOT 看清这次产品

方案不是拍脑袋定的。作为产品经理,我用 SWOT 对自己在项目里的贡献、面临的约束、外部的机会与风险做一次复盘——它既是「我怎么想」的交代,也是后续开发与迭代的边界清单。

S
优势 · 我为项目带来的
核心竞争力
  • 全链路独立操盘:从业务定位、场景分析,到信息架构、交互、高保真原型,一个人闭环,降低沟通与试错成本。
  • AI × 业务落地:把「AI 导游 × 语音」落成可运行原型(7 态状态机、真实语音识别),给开发一份可直接照做的蓝图。
  • 判断力优先于表现:先定「安全 / 效率 / 易用」目标再设计细节,不为炫酷堆动效。
  • 差异化场景洞察:抓住「无驾驶员、行驶中、首次使用」三个特殊性,确立语音为主的差异化定位。
W
劣势 · 我正视的约束
短板与限制
  • 原型离量产有距离:未经过真实车载硬件、网络与语音噪场环境的验证。
  • 缺少真实运营数据:使用行为、语音成功率尚未采集,指标多为设计预期。
  • 场景样本有限:以西湖景区为参考,待扩展其它景区与车型的适配性。
  • 技术依赖浏览器:语音识别依赖 Web Speech API,量产需转车载原生方案,存在兼容与依赖风险。
O
机会 · 我捕捉的窗口
外部机遇
  • 政策与市场:文旅数字化、智慧景区、自动驾驶观光车落地趋势明确,景区有体验升级与降本增效的双重诉求。
  • AI 技术成熟:语音与大模型能力成熟,把「AI 导游」做成差异化体验的成本显著下降。
  • 框架可复制:语音状态机、单页分区、三级降级,可复用到观光车、摆渡车、园区接驳等多场景。
  • 行业先发:无人车机交互标准仍在早期,较早建立「行车安全交互」的方法论与原型,有机会成为范式参考。
T
威胁 · 我管理的风险
不确定性
  • 硬件与供应链:量产涉及整车厂、车规屏等,接口与周期不可控。
  • 多方协作错位:景区、开发、算法、硬件等多方信息不同步,会影响落地节奏。
  • 安全与合规:无人驾驶 + 语音播报在公共出行中的责任边界与数据合规要求高。
  • 竞品与替代:同行可能快速跟进同类方案,或乘客更习惯使用手机端,影响采纳度。

关键决策与方案落地

SWOT 不是摆设。下面每一个方案选择,都是我对优势、约束、机会与风险做价值判断后的结果——先讲「为什么这么定」,再讲具体做了些什么。

从 SWOT 到关键取舍

取舍 01

语音为主、触控为辅

回应「行车中操作不便」与「安全合规」:宁可牺牲部分精确控制,换取行车安全;这也是车机区别于手机端的核心分水岭。

取舍 02

单页全屏、一屏一景

回应「首次使用门槛高」与「车机认知」:减少层级与学习成本,所有功能在单屏内用弹窗 / 抽屉完成,符合一屏一景的车机习惯。

取舍 03

三级降级兜底

回应「技术依赖浏览器」与「网络 / 兼容风险」:识别失败重试 → 离线模式 → 演示模式,保证任何环境下都能安全、完整地运行。

取舍 04

自动驾驶二次确认

回应「安全与合规」:自动驾驶切换需二次确认,0 误触安全设计,避免行驶中的误操作释放风险。

界面信息架构:单页全屏,四区协同

车机主界面

一张屏承载全部行车功能

TopBar 顶部 天气 / 时间 / 讲解 / 电量
LeftBar 左侧 搜索 / 金刚位 / 线路
地图主区 POI / 车辆 / 导航路线
BottomBar 底部 车速 / AI 语音 / 驾驶

单页面全屏布局,所有功能通过弹窗 / 抽屉 / 面板 / Portal 浮层在主界面内完成,无路由切换,符合「一屏一景」的车机认知。

核心功能模块

车机主界面 顶部状态栏 + 左侧面板 + 全屏地图 一张屏承载车辆状态、导览入口与地图主区
地图导航 POI 标记 + 车辆位置 + 导航路线 缩略图标记、蓝色虚线导航、可拖拽详情浮窗
AI 智能导游 景区天气 / 必逛景点 / 游玩线路 侧边抽屉 + 快捷宫格 + 常见问题引导
语音唤醒交互 你好小智 · 7 态语音状态机 唤醒涟漪 / 音柱波形 / 打字机播报 / 异常降级
自动驾驶体验 二次确认 + 粒子波纹激活动效 自动驾驶切换需确认,0 误触安全设计
扫码用车 · 锁屏 · 结算 欢迎扫码 → 锁屏锁定 → 行程结算 完整用车生命周期,Portal 浮层避免遮挡地图

语音为核心:7 态状态机

控制不只靠「点」,更要靠「说」——语音是行车场景下最安全的交互方式,也是车机区别于手机端体验的核心分水岭。

— 交互原则

从方案到落地:验证计划

原型方案已经确定,团队正在整理接口并进入开发阶段。车机体验的成败不以「界面多炫」为依据,而看它是否真正满足行车场景下的安全、效率与易用性——所以我把「怎么验证」提前定下来,作为开发与后续迭代的验收框架。

验证目标(可观测的体验指标)

语音优先
核心操作可语音完成 导航 / 讲解 / 查询全覆盖
7 态
语音状态机完整闭环 唤醒 → 播报 → 异常降级
30s
新手引导上手时长 四步交互代替说明书

如何验证这个方案

注:以上为「设计预期」的体验目标与验证方法,用来约束方案方向,而非已证实的成果;随着方案进入开发阶段,需要在真机 / 真车载环境下,通过可用性测试、语音埋点与用户回访逐步证实。

技术实现

从交互到高保真可运行原型

以 React 18 + TypeScript 搭建,Leaflet 天地图承载地图导览,Zustand 管理全局状态,Web Speech / Web Audio API 驱动真实语音识别与音量可视化,完整还原交互流程。

持续迭代

下一步扩展方向

依据验证结果,可逐步扩展多语言语音、无障碍适老化、多车型适配与车路协同,完善自动驾驶车机的全场景体验。

更多案例

继续探索我在不同终端上的产品实践。