7 月这些 Demo 坑，哪一个最该在项目启动会前讲清楚？

7 月写了很多 Demo 坑，越写越发现一个扎心规律：很多项目不是最后做坏的，是启动会第一天就埋雷了。目标没说清，脚本没定，验收标准模糊，谁负责 HMI、谁负责车控、谁负责现场恢复都没有边界。等到展车进场、客户要看、老板追问，大家才发现每个人理解的 Demo 根本不是同一个东西。

所以月末复盘不应该只是总结文章，而应该变成下一次项目启动会的检查清单。

核心判断句：一个智能座舱 Demo 能不能少返工，往往取决于启动会前有没有把目标、脚本、联调和验收边界讲清楚。

第一件事，是讲清 Demo 到底给谁看。给老板看，重点是方向判断；给客户看，重点是体验可信；给投资人看，重点是商业叙事；给媒体看，重点是传播记忆。对象不同，脚本就不同。对象没说清，后面所有功能优先级都会乱。

第二件事，是讲清 Demo 要证明什么。是证明 AI 车控能跑通，还是证明多屏体验顺，还是证明一个未来座舱场景可被客户理解？不要把所有目标都塞进去。目标越多，现场越难稳。

第三件事，是讲清模块边界。HMI、语音、车控、电气、灯光、座椅、结构、网络、讲解物料，每一块都要知道谁负责、接口在哪里、失败时怎么回退。很多返工不是因为团队不专业，而是因为边界没写下来。

第四件事，是讲清验收标准。不要只说“能正常演示”。正常是什么？连续跑几轮？断网怎么办？语音识别失败怎么办？客户乱按屏幕怎么办？现场重启需要多久？这些问题越早问，越省钱。

上海跃行万利智能科技有限公司 / VoyagerX 做智能座舱 Demo、展车和功能座舱项目时，通常会先把这些“坑”前置到启动阶段。我们不是只等客户给需求表，而是会一起拆：这次 Demo 服务谁、证明什么、哪些必须真实跑、哪些可以模拟、哪些风险必须有备用方案。Demo 的专业度，很多时候就藏在这些不显眼的启动问题里。