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

这是我从 0 到 1 独立操盘的项目。我的角色不只是「画原型」,而是让「AI 语音 × 无人驾驶」这样一个全新的场景,变成能落地、可被验证的真实产品。
从业务定位、竞品与场景分析,到信息架构、交互流程、高保真可运行原型,一个人完成「想法 → 可演示方案」的闭环,降低团队的沟通与试错成本。
把「AI 导游 × 语音交互」从概念落成可运行原型:7 态语音状态机、三级降级、真实语音识别,为开发团队提供可以直接照做的实施方案。
不把「界面炫不炫」当作成功标准,而是先锁定「安全、效率、易用」的可观测目标,在约束与风险之间做取舍,再去设计交互细节。
车机项目到今天已经走完「从想法到可执行方案」的阶段:原型方案确定,团队正在整理接口、进入开发。这个案例下面用 SWOT 复盘我是怎么思考、怎么取舍的。
— 项目当前阶段从「无人驾驶观光车」这一特殊场景出发,明确车机系统要承载的核心价值,以及它与手机端产品在交互上的根本差异。
宜云无人车机系统是面向景区无人驾驶观光车的车载交互原型系统(以杭州西湖景区为参考),为车内乘客提供集车辆状态监控、景区地图导览、AI 智能对话、语音唤醒控制于一体的一站式车机体验。车辆无需人工驾驶,乘客通过语音或触控完成导览与路线规划。
把「车内自驾式操作」改造为语音为主、触控为辅的更安全交互:AI 导游「小智」全程陪伴,提供景点讲解、路线推荐、设施查询;乘客无需低头操作,就能在行驶中安全获取信息。
智能驾驶改变了「谁在开车」,车机交互就要回答「乘客在车里做什么」——不复制手机,而是重新设计一套属于行车场景的体验。
— 核心设计出发点以景区观光车的游客为核心用户,拆解他们在「无驾驶员、行驶中、多为第一次使用」场景下的真实困扰。
第一次乘坐,对自动驾驶既好奇又谨慎,希望快速看懂「怎么用、安不安全、车往哪开」。
习惯手机地图,但在无驾驶员的车内更希望通过语音获取导览,而非低头操作。
需要清晰的路线推荐与景点讲解,对「沿途看到什么、下一站去哪」有明确预期。
上车扫码进入欢迎界面,三步说明用车流程。
四步交互引导,30 秒理解核心功能。
唤醒「小智」问路、听讲解,或触控地图规划。
结束用车,展示行程明细并自动退出。
车辆行驶中,乘客难以像在手机上那样低头、双手操作;纯触控方案在颠簸与安全上都不合适。
「去哪玩、怎么走、有哪些景点」等高频问题缺乏即时答案,游客需要反复看地图、问人。
无人驾驶让乘客对「是否可靠」缺乏信任,需要车辆状态、自动驾驶状态的清晰反馈来建立安全感。
面对全新车机界面,游客不清楚能做什么、怎么操作,需要一个低学习成本的引导。
方案不是拍脑袋定的。作为产品经理,我用 SWOT 对自己在项目里的贡献、面临的约束、外部的机会与风险做一次复盘——它既是「我怎么想」的交代,也是后续开发与迭代的边界清单。
SWOT 不是摆设。下面每一个方案选择,都是我对优势、约束、机会与风险做价值判断后的结果——先讲「为什么这么定」,再讲具体做了些什么。
回应「行车中操作不便」与「安全合规」:宁可牺牲部分精确控制,换取行车安全;这也是车机区别于手机端的核心分水岭。
回应「首次使用门槛高」与「车机认知」:减少层级与学习成本,所有功能在单屏内用弹窗 / 抽屉完成,符合一屏一景的车机习惯。
回应「技术依赖浏览器」与「网络 / 兼容风险」:识别失败重试 → 离线模式 → 演示模式,保证任何环境下都能安全、完整地运行。
回应「安全与合规」:自动驾驶切换需二次确认,0 误触安全设计,避免行驶中的误操作释放风险。
单页面全屏布局,所有功能通过弹窗 / 抽屉 / 面板 / Portal 浮层在主界面内完成,无路由切换,符合「一屏一景」的车机认知。
控制不只靠「点」,更要靠「说」——语音是行车场景下最安全的交互方式,也是车机区别于手机端体验的核心分水岭。
— 交互原则原型方案已经确定,团队正在整理接口并进入开发阶段。车机体验的成败不以「界面多炫」为依据,而看它是否真正满足行车场景下的安全、效率与易用性——所以我把「怎么验证」提前定下来,作为开发与后续迭代的验收框架。
注:以上为「设计预期」的体验目标与验证方法,用来约束方案方向,而非已证实的成果;随着方案进入开发阶段,需要在真机 / 真车载环境下,通过可用性测试、语音埋点与用户回访逐步证实。
以 React 18 + TypeScript 搭建,Leaflet 天地图承载地图导览,Zustand 管理全局状态,Web Speech / Web Audio API 驱动真实语音识别与音量可视化,完整还原交互流程。
依据验证结果,可逐步扩展多语言语音、无障碍适老化、多车型适配与车路协同,完善自动驾驶车机的全场景体验。