本文基于历史项目方案说明书做公开化整理。原始客户名称、品牌信息、报价、付款条款、人员姓名和未公开现场信息均已移除；部分参数按通用工程场景做了合理泛化。内容用于说明类似产品样机和设备开发的技术路径，如有侵权或不适宜公开的信息，请联系删除或调整。
一、需求复述与项目边界
车载AI助手的需求通常来自“做一个有陪伴感但不影响驾驶”的小型硬件。它需要表情、语音、声效、车辆状态感知和移动端设置，但不能把交互做得过重。
公开化后的开发目标是：开发V1基础版车载AI陪伴硬件，支持动态表情、欢迎语、基础语音问答、停车守护动画、车载风铃声效、参数设置和OTA升级。
| 边界项 | 本方案处理方式 |
|---|---|
| 版本定位 | V1基础版，优先稳定量产和成本可控 |
| AI能力 | 接入第三方大模型或自建代理服务 |
| 供电 | Type-C 5V和小电池缓冲 |
| 不包含 | 车辆OBD深度控制和驾驶辅助决策 |
二、系统总体架构
flowchart LR A["车载AI设备"] --> B["OLED表情屏"] A --> C["麦克风/扬声器"] A --> D["六轴IMU"] A -- "WiFi/BT" --> E["手机App/小程序"] A -- "HTTPS/MQTT" --> F["云端设备平台"] F --> G["大模型服务"] E --> F
设备端负责表情、语音采集、音频播放和IMU感知；移动端负责配网、设置、屏保和OTA；云端负责设备管理、AI接口配置、日志和版本管理。
三、结构与机械方案
结构建议做桌面小摆件形态，底部磁吸或胶垫固定，屏幕、麦克风孔、扬声器腔体和散热位置要在ID阶段一起考虑。车内高温暴晒是重要约束，外壳材料、屏幕盖板和胶粘剂都要做温度验证。
四、硬件、电气与关键器件
主控可选T113-S3、RK3566级Linux方案或成本更低的MCU+语音模组方案。V1如果要做本地动画和网络AI，Linux SoC更灵活；如果只做固定语音和动画，MCU方案成本低但扩展弱。
| 模块 | 关键设计 | 验证重点 |
|---|---|---|
| 显示 | 2.5寸左右圆形或异形OLED | 亮度、烧屏、动画帧率 |
| 语音 | 麦克风、音频功放、5W扬声器 | 车内噪声和回声消除 |
| 感知 | 六轴IMU | 急刹、转弯、震动误判过滤 |
| 通信 | WiFi/BT、App配网、OTA | 弱网重连和升级失败恢复 |
五、软件、控制与交互
软件分为设备端动画引擎、语音交互、IMU事件识别、配置管理、OTA和云端AI代理。驾驶中交互要克制，语音回复长度、屏幕动效亮度和声音提示都要避免干扰。
| 功能 | V1实现方式 | 后续扩展 |
|---|---|---|
| 开车欢迎语 | 本地随机语音包 | 根据时间和天气动态生成 |
| 基础问答 | 云端大模型API | 本地热词和离线指令 |
| 守护模式 | 停车动画和声效 | 震动触发记录和推送 |
| 自定义屏保 | App上传图片 | 二维码、挪车电话、主题商店 |
六、深化技术方案
6.1 结构与整机模块
AI车载助手不是简单把一个语音音箱放进车里。它需要处理车内固定、供电、麦克风阵列、扬声器、摄像头、热管理和行车振动。公开化方案建议拆为主机外壳、固定底座、显示/灯效面板、音频采集模块、车载供电模块和散热结构。主机外壳要考虑夏季车内高温、玻璃反射、仪表台曲面和遮挡驾驶视线的问题，固定方式可选磁吸底座、3M胶底座或夹持支架，但都要做振动和跌落验证。
若产品需要摄像头识别驾驶员或车内物体，摄像头角度应可调，且镜头附近避免强反光装饰件。麦克风阵列最好远离扬声器和空调出风口，结构上给麦克风开独立声孔，并在内部做声学隔离。车载供电建议从12V转5V/3.3V，增加反接、浪涌、过压、欠压和点火瞬态保护。
6.2 硬件与计算平台
硬件可按基础版和增强版两档规划。基础版采用ESP32-S3或RK3566级别平台，承担语音唤醒、蓝牙/Wi-Fi、灯效和简单本地控制；增强版采用RK3588S、Qualcomm或带NPU的边缘计算平台，支持本地视觉、离线语音、车内多模态交互和小模型推理。音频链路包括MEMS麦克风阵列、AEC回声消除、功放和扬声器；视觉链路包括MIPI/USB摄像头、ISP调参和隐私遮挡结构。
车规级量产与样机开发要分开看。样机阶段可以用工业级器件验证交互链路，DVT阶段再补EMC、温湿度、ESD和供电瞬态测试。涉及车辆CAN或OBD读取时，必须做只读隔离和权限边界，避免影响原车控制。
6.3 软件模块与技术栈
软件分为设备端、AI服务端和配置端。设备端可用Linux + C++/Python服务，或Android AOSP方案；低成本版本可用FreeRTOS承载唤醒、蓝牙和灯效。AI链路包括唤醒词、ASR、NLU/LLM、TTS、音频播放和本地缓存。配置端可以是小程序或App，用于联网、账号、设备名、语音包、固件升级和日志授权。
flowchart TD
A["麦克风阵列采集"] --> B["唤醒词检测"]
B --> C["降噪与回声消除"]
C --> D["ASR语音识别"]
D --> E["意图解析/大模型服务"]
E --> F{"需要车辆或设备动作?"}
F -- "是" --> G["权限检查与本地控制"]
F -- "否" --> H["生成回答文本"]
G --> I["TTS播报与灯效反馈"]
H --> I
I --> J["日志脱敏与状态上报"]
6.4 协议说明
设备端与云端建议使用HTTPS + MQTT组合。HTTPS用于登录、配置、固件版本和大模型请求；MQTT用于设备在线状态、远程配置、日志索引和OTA通知。设备本地数据结构包含device_id、firmware_version、wake_state、network_state、battery_or_vehicle_voltage、thermal_state、audio_level和privacy_mode。涉及图像和语音时默认不上传原始数据，只上传经授权的任务片段或脱敏特征。
七、测试验证与验收
验收要覆盖车内噪声、网络波动、高温暴晒和驾驶场景误唤醒。音频测试应包含怠速、行驶、开空调、播放音乐和多人说话；视觉测试应包含日光、夜间、逆光和玻璃反射。
| 验收项 | 测试方法 | 通过标准 |
|---|---|---|
| 唤醒与识别 | 多噪声环境采样 | 唤醒稳定，误唤醒可控 |
| 车载供电 | 点火、熄火、浪涌模拟 | 不死机，不损坏，状态可恢复 |
| 热管理 | 高温箱和日照模拟 | 降频策略明确，外壳温升可接受 |
| 隐私边界 | 断网、关闭摄像头、清除日志 | 用户状态清晰可见，数据可删除 |
八、周期计划
参考周期12到18周。第1-2周完成产品边界、交互脚本、硬件平台和外观安装方式冻结。第3-5周完成结构ID/MD、音腔、摄像头角度、供电保护和开发板联调。第6-9周完成语音链路、联网、基础AI服务、App/小程序配置和OTA框架。第10-12周做车内样机测试，修正麦克风位置、散热、固定方式和误唤醒。第13-15周进入DVT准备，补充EMC、温湿度、跌落振动和长时间运行。第16-18周整理小批试制资料、测试报告和固件冻结版本。
九、人员配置
建议项目经理1人，结构工程师1人，硬件工程师1人，嵌入式/Linux工程师1-2人，AI算法/服务端工程师1人，App或小程序工程师1人，测试工程师1人。若只做EVT演示样机，可压缩算法和App投入；若进入车载场景小批量，则测试和EMC资源不能省。
十、风险边界
风险主要在车内声学、供电瞬态、隐私合规和AI体验一致性。样机能演示不等于可装车长期使用，后续必须通过DVT/PVT阶段把热、振动、EMC和数据边界逐步验证清楚。
近期评论