邓承浩支持反“速成车”：新车发布可以赶，别让车主替厂家补测试

反对“速成车”，最该减少的是消费者提车后的意外，而不只是发布会里的豪言。深蓝董事长邓承浩公开支持这一轮讨论，态度明确；对买家来说，接下来有用的变化，是厂家把验证做在前面，交付时少留一些需要用户自己发现的问题。

10月11日，邓承浩发文，支持行业重视安全、反对速成车和伪创新的讨论与反思。同一天，中汽协发布倡议，提出将安全评估前置到产品创新全过程。四部门相关文件在10月10日公开征求意见，目前尚未完成正式发布。

来源：邓承浩公开发文，IT之家转载。支持表态不等同于对旗下所有车型的独立安全认定。

快，不该自动成为原罪

开发工具进步、团队配合更紧密，同样一项工作花的时间变少，当然是好事。消费者也希望产品及时改进，功能别永远留在“下个版本”。把发布节奏快直接判成产品差，并没有足够依据。

问题出在被节省掉的究竟是什么。少开几次没有结果的会议，和少做几轮验证，带来的后果完全不同。一个看起来更快的流程，可能来自效率，也可能来自省略，单看月份数字分不清。

本文自制时间线，依据工信部公示、新华社及IT之家报道。三项动作的日期和性质分别标注。

证券时报的走访报道记录了车企学习和自查的反应，也提到业内对研发效率与验证充分性的区分。这里值得继续往下看：公司宣布支持以后，会不会把验证资源、产品节点和问题处理一起调整。

消费者并不需要知道每家企业开了几场学习会。那些动作是否产生结果，最终要体现在交付状态和公开资料上。支持很容易表达，取舍会发生在新车准备上市的那个时间点。

能更新软件，不意味着整辆车可以晚点做完

软件改善菜单、优化交互、增加便利功能，是智能汽车的一部分。用户愿意获得升级，并不等于同意接收一辆需要自己长期验证的车。出厂时该完成的能力和后来新增的能力，需要分清楚。

比如一个功能尚在规划，就应该作为规划介绍，不能先在演示里把它讲得已经随时可用。已经开放的功能，则应说明适用条件和限制。让车主交钱以后再从提示框、群聊或客服回复里拼出答案，会增加使用成本。

本文原创观点图。用于说明开发效率和验证覆盖的区别，非深蓝内部流程资料。

部件也不是单独表现漂亮就万事大吉。接入整车以后，软件、硬件和各种操作状态相互影响。系统能否处理它应该处理的情况，需要对应验证。供应商的一句承诺、一次舞台演示，都很难替这些工作作答。

这同样不能被倒过来读成“OTA多就是速成车”。升级次数不直接等于问题数量，研发时间也不直接等于安全水平。判断一款产品，仍要看实际方案、验证依据以及异常处置，不能换一种标签继续站队。

“扎实做事”，需要让用户看得见

邓承浩说，这场讨论对扎实做事的品牌和中国智能电动车发展是好事。这是一个可以理解的立场。愿意投入验证的企业，希望市场能够区分实际工作和传播声量；这种区分要成立，就得让相关信息变得可理解。

本文整理图，依据中汽协倡议及公开讨论。表达信息需求，不认定深蓝存在特定质量问题。

对于车主，一份通俗的使用说明可能比一长串行业名词更有帮助。应急开门入口在哪，某项功能什么时候不能使用，出现提示后应怎样处理，最好在交车时就能说清。发生异常以后，反馈到哪里、有没有后续处理，同样属于用户对品牌的判断。

把安全公开成一套能查询、能操作、能跟进的信息，会比只让高管在热搜里出面更持久。车企不必公开全部研发细节，但不能让最基础的功能边界都变成消费者的猜谜题。

本文原创示意。用于解释用户关心的交付信息、升级说明和反馈入口。

目前讨论尚不能据此判定任何品牌已经满足全部拟提出要求，也不能指认某款车就是“速成车”。正式文件会怎样落地，还要继续看；品牌此刻可以先做的，是把现有产品的信息和验证说明讲清楚。

真正准备提车的家庭，不会因为学习会开得热闹就减少担心。交付人员如果能明确演示紧急操作、解释功能限制、给出查询和反馈入口，这种扎实，他们当天就能看见。

信源：IT之家：邓承浩表态 · 工信部征求意见公示 · 新华社：中汽协倡议 · 证券时报：企业学习、自查与行业反馈。头图及信息图为原创整理，发文截图为预览参考。资料截至2026年10月12日；公开截图发布前应确认转载授权。

作者提示含AI生成内容。