智能化技术自研这件事，我入行这几年看得越来越清楚：它不只是技术路线选择，更是一家智能电动车企业能不能把护城河挖深的生死题。最近和同行聊起新势力的核心竞争力，大家绕不开一个判断——谁把智能化自研做透，谁才有资格谈长期主义。今天我不讲PPT，就结合我实际参与过的量产项目和踩过的坑，聊聊为什么自研是那条最深的护城河，以及它到底难在哪、怎么落地。1. 为什么智能化的命脉必须握在自己手里1.1 传统供应链玩法，在智能电动车时代不灵了早年做传统整车，主机厂和供应商之间的分工很清晰：发动机、变速箱、底盘这些核心系统，主机厂出需求、定参数，Tier 1负责实现和制造。机械结构的东西，只要测试充分、调校到位，供应商方案和你自己搞的差别没那么大，大家拼的是工程匹配和成本控制。到了智能电动车时代，游戏规则彻底变了。一辆车好不好用，不再只看加速和底盘，而是看座舱能不能听懂人话、辅助驾驶能不能让长途驾驶轻松一点。这些体验的核心是软件和算法，而软件和算法的成长高度依赖数据闭环——车跑起来之后采集的数据能不能回流、能不能反哺模型、能不能快速发布给所有用户。这件事供应商没法替你干，因为数据在谁手里，谁才有迭代的资格。主机厂如果把算法外包，就等于把进化速度交到别人手里。我经常和朋友打一个比方：传统造车像是买精装房，供应商把硬装做好，你拎包入住；智能化自研则是你把墙拆了重做水电，自己决定沙发放哪、灯光怎么调。过程费劲，但住进去的每一天都在按你的意愿变好。不自研，你只能等着物业统一翻新，物业什么时候动工、做成什么样，你说了不算。1.2 自研解决的三个核心问题：体验、速度、成本先说体验一致性。用供应商方案最头疼的是“拼接感”：语音系统是A家的、地图是B家的、辅助驾驶是C家的，每个单点都还行，但放在一起就有割裂感。自研之后，从感知到决策到执行，整个链路是一套语言写的，体验自然连贯。比如语音助手和导航深度融合，你说“帮我找充电站然后把路线发到车机”，系统能一步完成，而不是跳转好几个应用。再说迭代速度。自研团队每天都在改代码，改完当天就能跑仿真、上测试车，确认没问题后通过OTA推给用户。用供应商方案呢？提需求要排期，改缺陷要等版本，一个功能从提出到释放可能要等半年。智能化赛道半年意味着什么？可能竞品已经多卖了两轮车型。最后是成本。短期看自研烧钱，长期看是资本开支和费用化的平衡。每年付给供应商的软件授权费、按车收取的license费、每改一次需求就加一次的开发费，算下来比养一个几百人的自研团队贵得多。更关键的是，供应商的方案按整车收费，车卖得越多你付得越多，而自研投入是一次性的，摊到全生命周期里越卖越便宜。1.3 “护城河”不是一个技术点，是一整套系统能力很多人误以为自研护城河指的是某个单点技术，比如多目融合算法很强、语音识别很准。其实真正难被抄走的是一个组合：数据采集能力 + 标注体系 + 仿真环境 + 训练平台 + 车端部署工具链 + 组织协作方式。这套系统里任何一个环节拿出来都可能被复制，但把它们串成闭环，没有三年以上的持续投入根本搭不起来。这也是为什么我一直和团队说，自研的目标不是“做出来”，而是“跑起来”。算法模型在实验室里跑通只是第一步，能不能在量产车上稳定运行、能不能在资源有限的芯片上实时推理、能不能通过车规级验证，这才是真门槛。这些能力是供应商方案给不了你的。它们可以给你一个成熟的模块，但给不了你快速演进和深度定制的能力。2. 自研到底自研些什么2.1 自动驾驶算法与数据闭环：护城河最关键的一环高阶辅助驾驶是智能化自研的重头戏。算法栈可以拆成感知、预测、规划、控制四层，早期团队还能靠开源算法和公开数据集拼出一个Demo，但做到量产级、体验级，就完全不是一回事了。真正的分水岭是数据闭环。量产车队每天在路上跑，车端会积累大量视频片段和传感器数据，但不可能全部回传，带宽和存储都扛不住。自研团队要解决的第一件事，是知道该回传什么：哪些是罕见场景、哪些是模型当前处理不好的bad case、哪些是模拟器里生成不了的corner case。这需要做一套车端数据挖掘系统，在车上就完成初筛，只把高价值片段传回云端。回传之后是标注。一个感知模型想要升级，得先有高质量标注数据。早期靠人工一张一张画框，效率和成本都很吓人。后来我们做了自动标注和人工抽检结合，用一套已经相对成熟的模型打底，人只需要修正错误框，效率提升了好几倍。这个过程听起来不炫，但它是数据闭环的血液，做不扎实，算法再厉害也练不出来。验证阶段同样依赖自研。大规模路测之前，要先把新模型放到仿真环境里跑一遍，用海量场景库去压测。仿真环境最大的价值不是替代路测，而是把路测中发现的问题快速复现、快速回归。你可以想象一个场景，AEB误触发一次就可能导致投诉，仿真环境需要把这个场景拆解成多个子场景，反复验证模型的反应，确认修复了才能放行。2.2 智能座舱系统与底层OS自研：体验背后的技术主权很多人低估了座舱自研的价值，觉得不就是做个大屏、做个语音吗？实际做起来才知道，座舱是用户每天接触最多的智能化界面，它的体验好坏直接决定用户怎么评价这台车。座舱自研的第一个层面是操作系统和中间件。安卓可以拿来用，但如果你只是把安卓原封不动搬上车，更新迭代全跟着谷歌走，多屏交互、车控联动这些车特有的能力很难做好。我们需要做的是在上层搭建一套自己的跨端框架，让仪表、中控、副驾屏、后排屏之间共享一个数据状态。比如中控上调空调温度，仪表场景联动显示；副驾看视频时，声音自动切到副驾头枕，这些交互细节都依赖自研的底层调度。第二个层面是语音助手全链路自研。唤醒词、语音识别、语义理解、对话管理、语音合成，每一层都值得做深。供应商通常给的是整体方案，你只能在上面做简单配置，想加一个车控领域特有的意图，比如“打开洗车模式”“把座椅调到我最舒服的位置”，就得看供应商给不给你开放接口。自研之后，我们可以把用户数据直接作用于模型优化，同样的说法，在车上越用越灵。这个体验差距，是评测机构测不出来的，但用户每天都能感受到。还有一块经常被忽略：账号体系和应用生态。自研座舱意味着你有自己的用户体系，可以打通手机、手表、家充桩这些外部设备，实现上车前就准备好的无缝衔接。这是生态想象力的基础。2.3 整车电子电气架构与域控制器：自研的硬件底座自研软件跑在什么上面？答案是整车电子电气架构。传统车是分布式架构，全车几十个ECU各自为政，每个功能一个控制器，软件升级要么不管、要么只能整车进店刷写。智能化时代要把几十个ECU收敛成几个域控制器：智驾域、座舱域、车身域、动力底盘域，再往后是中央计算平台。做域控自研，主机厂要具备的是“软硬解耦”的能力。底层的计算平台可以是英伟达、高通这些芯片供应商，也可以是自己定制的芯片，但在其上跑的底层软件、中间件、应用框架必须掌握在自己手里。这就像智能手机：芯片可以买，但操作系统和核心应用是自己做的，体验和生态才能捏在自己手上。这里面有个很大的坑：域控制器集成度极高，发热、功耗、电磁兼容都有严格约束，算法模型要在一个功耗上限内跑满，不能动不动就过热降频。我们早期某款车型的智驾域控，长时间高负荷运行时会出现算力抖动，直接导致接管提示听起来很急。后来做了多轮功耗调优，把模型推理的算子拆开在不同计算单元上调度，这个问题才算解决。2.4 芯片自研的边界：不是什么都得自己造自研不等于什么都做，芯片就是一个典型。AI芯片自研是巨头级玩家的游戏，投入几十亿起步、流片周期以年计，而且一旦做出来，还得有足够大的量产规模摊薄成本。对绝大多数车企来说，更务实的路线是：深度参与芯片定义，但不用亲手造。深度参与的意思是在芯片立项阶段就绑定核心IP需求，比如NPU算力布局、内存带宽、安全性设计，都要围绕自家算法来定。算法需要多少算力、数据流如何走，直接反馈给芯片团队，这样流片回来后性能才能真正释放。我们有一次和某芯片厂商合作，提前半年把自研BEV网络的算子需求提过去，等到芯片量产，模型在它上面跑出来的效率比上一代平台提升近一倍，这就是深度协同的价值。边界也很清晰：通用型芯片，比如MCU、电源管理、接口芯片，直接采购成熟方案就好；战略级芯片，比如主控SoC、自动驾驶SoC，可以自研或深度定制；中间那些有技术含量但迭代快的AI加速单元，适合跟芯片厂商联合定义。把每一类想清楚，预算才花得值。3. 自研的账怎么算：成本、投入与时间线3.1 研发投入是一场持续多年的马拉松智能化自研烧钱的速度，远超很多人想象。一个千人规模的研发团队，每年光人力成本就是十几亿，再加上算力集群采购、数据标注外包、测试车队运营，每年几十亿投入很正常。做这件事要想清楚，它不是一次性的投入，而是持续多年的马拉松——第一年你可能只看到方案,第三年才有靠谱Demo，第五年才能量产上车。我见过一些企业在前两年还信心满满，第三年开始收缩预算，结果算法团队的人被竞品挖走一半，项目就这么烂尾了。自研最大的风险不是技术难，而是组织耐不住性子。它不像买供应商方案，给钱就有交付；自研的产出曲线是前期模糊、中期剧烈波动、后期才稳步上升，没有足够耐心，很难熬到收获期。那到底该投多少？没有一个固定比例，但可以参考两个数字：一是研发投入占营收的比例，新势力要做到15%以上才有资格谈智能化，传统车企普遍在3%-5%，差距就在这里；二是智能化研发中算法和数据团队的占比，如果软件算法团队不到研发总人数的一半，大概率还是以硬件为主，智能化深度就有限。3.2 人才密度决定了自研的天花板自研最难的不是钱，是人才密度。自动驾驶和座舱交互是典型的交叉学科领域，既要有懂深度学习的算法工程师，又要有懂操作系统的底层开发者，还要有懂整车功能安全、懂传感器标定的系统工程师。这批人市场上本来就少，而且流动极快。我在招人时最看重的是“工程嗅觉”。很多候选人简历漂亮，一问到量产细节就露怯：有没有做过模型裁剪？有没有处理过实车上的时延抖动？有没有和功能安全团队杠过需求？这些经验不是论文里能学到的，只能是真刀真枪的量产项目里磨出来的。一个成熟的智能驾驶算法工程师，从入职到独当一面，至少需要一年半，前半年都在熟悉工具链和真实数据。自研团队的组织架构也很重要。我们早期是纯职能制，算法、软件、测试各自为战，结果每次联调都像打仗。后来改成“版本火车”模式，每三周出一个可测版本，所有人围绕版本目标倒排计划，算法工程师和车辆测试工程师坐在一起办公，效率明显提升。研发管理上的精细化，很多时候比多招一百人更管用。3.3 什么阶段开始自研最合适很多人问我是该从第一款车就自研，还是先买方案过渡。我的看法是：起步期可以合作，但必须有自研的战略安排，最好是第一款车就开始建立自研团队，哪怕做的功能少一点、慢一点。起步期买方案有几大隐藏风险：一是供应商方案的黑盒特性，出了问题你只能“换件排查”，很难精准定位；二是方案的可扩展性差，供应商下一版本更新可能推翻你的二次开发；三是团队没有实战机会，永远在别人的代码上做配置，三年后还是执行者，不具备主导权。更现实的是，数据资产需要提前积累。如果你第一辆车用的是供应商方案，那产生的事故数据、接管数据、用户行为数据，大概率都不归你。等你想自研时，手里没有过去几年的数据积累，一切从零开始，这比晚做三年算法还致命。数据这件事永远不嫌早，越早开始采集和沉淀越好。4. 实操视角：一个自研功能的完整落地流程4.1 以高速导航辅助驾驶为例，看全链路怎么走我参与过的最典型的自研项目，是一款车型的高速导航辅助驾驶功能，从立项到全量推送整整走了十四个月。这个周期在行业内不算长，主要原因是团队已经有基本的数据闭环基础，但即便这样，过程中的波折也不少。第一步是需求定义和场景清单。产品团队和算法团队坐在一起，把高速场景拆成几千条用例：有清晰车道线的、无车道线的、有锥桶施工的、有大车压线的、有恶劣天气的、有隧道强光的。每一条用例都要明确预期行为和退出策略。这一阶段最容易犯的错是贪多，什么都想做，结果每个场景都做不透。我们最后的妥协是：首批只支持高速和城市快速路，暂不支持施工场景的自动避障，故障时清晰降级提醒用户接管。第二步是数据收集和模型训练。定义好场景后，车队开始按区域跑图，采集高速路段的视频和感知数据，同步做语义标注。模型训练不是一次性的，而是每天持续进行——白天有新车数据回流，晚上自动出训练任务，第二天早上评估指标。我们用的训练集群是几百张GPU卡的规模，配合自研的分布式训练框架才能支持这种节奏。第三步是仿真验证和实车测试。新模型先在仿真场景库跑一遍，通过率不达标直接打回；达标后进入测试车实车阶段。实车路测阶段最耗时，一个版本在高速上跑几千公里才能覆盖主要场景，很多问题只在特定光线、特定路口出现，跑不到就发现不了。团队每周例会的固定环节，是过一遍上一周采集到的bad case，讨论是算法问题还是策略问题，逐条给出处理意见。第四步是影子模式和灰度发布。模型达到标准后，不直接推给用户，而是先以影子模式运行：车辆继续用旧版本控制，但新版本在后台同步运行，持续对比输出的差异。影子模式跑上一个月，确认新版本没有带来异常风险，才开始内部员工灰度，然后是小规模用户、大范围推送。OTA是一个精细化操作，随时可以拉停。4.2 过程里的关键参数和判断依据功能落地中用到的几个关键参数值得记录。感知帧率要做到每秒15帧以上，否则高车速下目标运动轨迹会出现跳变；控制指令时延要控制在150毫秒以内，超过这个值，驾驶员会明显感到“车反应慢半拍”；变道决策置信度阈值要设到0.9以上，宁可偶尔不变道，也不要频繁无效变道引起用户吐槽。还有一套“安全兜底”的逻辑。系统一旦检测到驾驶员脱手时间超过规则限制，会先声音提醒、再点刹提醒、最后退出辅助驾驶并请求接管。很多人以为自动驾驶是机器完全在开，实际上现阶段更准确的说法是“人机共驾”——机器负责大部分稳定工况，人负责监督和边缘兜底。自研要把这套交互逻辑打磨得很细，否则很容易给用户造成误导，安全风险远比体验问题严重。4.3 量产路口必做的两件事：冻结与验收自研功能在量产前的最后阶段，最重要的事情是版本冻结和量产验收。版本冻结不是说代码不能不改，而是所有变更必须走严格的变更管理流程，任何改动都要重新跑全量仿真和关键路测。我们有过一次教训，邻近量产时为了让跟停体验更平顺改了一个参数，结果引入了一个低速下的偶发抖动，差点影响投产节奏。后来所有参数变更必须走测试专项，数据说话。验收阶段要看三个维度：功能性能指标、用户体感主观评价、安全冗余表现。性能指标好理解；主观评价需要一支固定评审团，每天开同一段路，靠脚感和体感打综合分；安全冗余重点看系统在异常状态下是否优雅降级。这三个维度都合格，功能才算具备交付条件。5. 常见问题与排查技巧实录5.1 问题一：自研进展太慢，怎么应对内部质疑自研团队最容易被问的一句话是：都做了一年了，怎么还在改Bug？这句话背后是管理层对投入产出比的焦虑，处理不好项目很容易被砍预算。我的经验是，从第一天就要建立可量化的进展汇报机制。不要只讲算法指标提升了多少，而是把进展拆成用户可感知的版本维度。比如每三周发布一个测试版，列出这个版本改了什么体验问题，下周计划解决什么。当管理层能看到节奏的时候，焦虑感会大幅下降。另一个办法是阶段性展示“技术肌肉”，哪怕是不直接上车的技术突破，比如某个感知模型在权威数据集上的排名、一次极端case的成功处理，都能给自研价值增加论据。5.2 问题二：累死累活把数据采回来，质量却不行这是数据闭环里最普遍的坑。车队跑了几万公里，回传的数据有一半不能用：要么是场景太普通没有训练价值，要么是传感器标定漂移导致数据整体偏差，要么是隐私脱敏没做好，根本进不了数据平台。解决方案要靠系统化治理。车端数据挖掘系统要设置动态触发条件，只有出现特定场景或者模型信心不足时才回传数据，而不是无脑录制；云端要做自动质量评估模型，基于多维度指标过滤低质量片段。标定更是要纳入日常运营流程，每次车辆保养时固定做传感器标定验证，确保回传数据的一致性。数据质量这件事，越早制定标准，后面的损失越小。5.3 问题三：算法团队和系统团队互相甩锅自研项目很容易出现这种局面：一个功能出了问题，算法工程师说是底软时延太大，系统工程师说是算法设计不合理，两边在会议上吵得不可开交，问题却迟迟没有结论。我后来建立了一套“端到端 owner”机制。每个功能指定一个负责人，不管内部是哪一层的Bug，owner要对最终用户体验负责，他有权调动算法、系统、测试任何一方资源。同时建立了一套全链路埋点系统，问题发生时能追踪到具体模块、具体环节，而不是靠猜。埋点系统刚开始建设时投入不小，但它能省下大量扯皮时间，非常值得。5.4 问题四：什么都想自研，结果什么都做不好自研的边界问题，是另一个极端。曾经有产品经理提了一堆自研需求，从流媒体后视镜到整车震动反馈，恨不得每颗螺丝都自己造。这会导致资源极度分散，核心战斗反而打不赢。我的原则是“战略定位决定自研清单”。与用户体验强相关、迭代速度要求高的领域，比如智驾算法、语音助手、整车OS中间件，必须自研；与体验弱相关、供应链成熟的领域，比如轮胎压力监测、网关模块，直接采购就行。适合别人做的，大方交给别人做，把自己的精力集中在能形成长期差异化的地方。6. 关于护城河的一个补充技术自研这个护城河，它不是一条笔直的河，更像是一整套水利系统。算法、数据、芯片定义、组织能力、供应链掌控力，每一条支流都在为这条系统输送能量，任何一条断了，整个体系都会受损。这也是我看一家企业智能化实力时，不太关心它PPT里写了多少自研比例，而是更关注几个可验证的信号：数据闭环是不是真的跑通、团队有没有量产交付经验、软件迭代有没有形成稳定节奏。有些人觉得自研是一场豪赌，烧钱多、见效慢，不如买现成的。但我的判断是，智能化自研不是选择题，而是生存题。短期买方案可能显得更高效，但长期看，没有自研能力的企业，在智能电动车这轮竞争里会被加速淘汰。最后说一点个人体会。我在实际项目中最大的感触是，自研最难的不是技术本身，而是“坚持”这两个字。资本市场波动、内部战略摇摆、竞品节奏施压，每一样都可能让团队中途放弃。但真正走过完整的自研周期之后，你会看到它带来的回报远超预期：不只是技术能力，更是团队信心、用户口碑和供应链话语权。护城河从来不是一天挖成的，但它一旦成形，别人想跨过来，难。
智能化技术自研这件事，我入行这几年看得越来越清楚：它不只是技术路线选择，更是一家智能电动车企业能不能把护城河挖深的生死题。最近和同行聊起新势力的核心竞争力，大家绕不开一个判断——谁把智能化自研做透，谁才有资格谈长期主义。今天我不讲PPT，就结合我实际参与过的量产项目和踩过的坑，聊聊为什么自研是那条最深的护城河，以及它到底难在哪、怎么落地。1. 为什么智能化的命脉必须握在自己手里1.1 传统供应链玩法，在智能电动车时代不灵了早年做传统整车，主机厂和供应商之间的分工很清晰：发动机、变速箱、底盘这些核心系统，主机厂出需求、定参数，Tier 1负责实现和制造。机械结构的东西，只要测试充分、调校到位，供应商方案和你自己搞的差别没那么大，大家拼的是工程匹配和成本控制。到了智能电动车时代，游戏规则彻底变了。一辆车好不好用，不再只看加速和底盘，而是看座舱能不能听懂人话、辅助驾驶能不能让长途驾驶轻松一点。这些体验的核心是软件和算法，而软件和算法的成长高度依赖数据闭环——车跑起来之后采集的数据能不能回流、能不能反哺模型、能不能快速发布给所有用户。这件事供应商没法替你干，因为数据在谁手里，谁才有迭代的资格。主机厂如果把算法外包，就等于把进化速度交到别人手里。我经常和朋友打一个比方：传统造车像是买精装房，供应商把硬装做好，你拎包入住；智能化自研则是你把墙拆了重做水电，自己决定沙发放哪、灯光怎么调。过程费劲，但住进去的每一天都在按你的意愿变好。不自研，你只能等着物业统一翻新，物业什么时候动工、做成什么样，你说了不算。1.2 自研解决的三个核心问题：体验、速度、成本先说体验一致性。用供应商方案最头疼的是“拼接感”：语音系统是A家的、地图是B家的、辅助驾驶是C家的，每个单点都还行，但放在一起就有割裂感。自研之后，从感知到决策到执行，整个链路是一套语言写的，体验自然连贯。比如语音助手和导航深度融合，你说“帮我找充电站然后把路线发到车机”，系统能一步完成，而不是跳转好几个应用。再说迭代速度。自研团队每天都在改代码，改完当天就能跑仿真、上测试车，确认没问题后通过OTA推给用户。用供应商方案呢？提需求要排期，改缺陷要等版本，一个功能从提出到释放可能要等半年。智能化赛道半年意味着什么？可能竞品已经多卖了两轮车型。最后是成本。短期看自研烧钱，长期看是资本开支和费用化的平衡。每年付给供应商的软件授权费、按车收取的license费、每改一次需求就加一次的开发费，算下来比养一个几百人的自研团队贵得多。更关键的是，供应商的方案按整车收费，车卖得越多你付得越多，而自研投入是一次性的，摊到全生命周期里越卖越便宜。1.3 “护城河”不是一个技术点，是一整套系统能力很多人误以为自研护城河指的是某个单点技术，比如多目融合算法很强、语音识别很准。其实真正难被抄走的是一个组合：数据采集能力 + 标注体系 + 仿真环境 + 训练平台 + 车端部署工具链 + 组织协作方式。这套系统里任何一个环节拿出来都可能被复制，但把它们串成闭环，没有三年以上的持续投入根本搭不起来。这也是为什么我一直和团队说，自研的目标不是“做出来”，而是“跑起来”。算法模型在实验室里跑通只是第一步，能不能在量产车上稳定运行、能不能在资源有限的芯片上实时推理、能不能通过车规级验证，这才是真门槛。这些能力是供应商方案给不了你的。它们可以给你一个成熟的模块，但给不了你快速演进和深度定制的能力。2. 自研到底自研些什么2.1 自动驾驶算法与数据闭环：护城河最关键的一环高阶辅助驾驶是智能化自研的重头戏。算法栈可以拆成感知、预测、规划、控制四层，早期团队还能靠开源算法和公开数据集拼出一个Demo，但做到量产级、体验级，就完全不是一回事了。真正的分水岭是数据闭环。量产车队每天在路上跑，车端会积累大量视频片段和传感器数据，但不可能全部回传，带宽和存储都扛不住。自研团队要解决的第一件事，是知道该回传什么：哪些是罕见场景、哪些是模型当前处理不好的bad case、哪些是模拟器里生成不了的corner case。这需要做一套车端数据挖掘系统，在车上就完成初筛，只把高价值片段传回云端。回传之后是标注。一个感知模型想要升级，得先有高质量标注数据。早期靠人工一张一张画框，效率和成本都很吓人。后来我们做了自动标注和人工抽检结合，用一套已经相对成熟的模型打底，人只需要修正错误框，效率提升了好几倍。这个过程听起来不炫，但它是数据闭环的血液，做不扎实，算法再厉害也练不出来。验证阶段同样依赖自研。大规模路测之前，要先把新模型放到仿真环境里跑一遍，用海量场景库去压测。仿真环境最大的价值不是替代路测，而是把路测中发现的问题快速复现、快速回归。你可以想象一个场景，AEB误触发一次就可能导致投诉，仿真环境需要把这个场景拆解成多个子场景，反复验证模型的反应，确认修复了才能放行。2.2 智能座舱系统与底层OS自研：体验背后的技术主权很多人低估了座舱自研的价值，觉得不就是做个大屏、做个语音吗？实际做起来才知道，座舱是用户每天接触最多的智能化界面，它的体验好坏直接决定用户怎么评价这台车。座舱自研的第一个层面是操作系统和中间件。安卓可以拿来用，但如果你只是把安卓原封不动搬上车，更新迭代全跟着谷歌走，多屏交互、车控联动这些车特有的能力很难做好。我们需要做的是在上层搭建一套自己的跨端框架，让仪表、中控、副驾屏、后排屏之间共享一个数据状态。比如中控上调空调温度，仪表场景联动显示；副驾看视频时，声音自动切到副驾头枕，这些交互细节都依赖自研的底层调度。第二个层面是语音助手全链路自研。唤醒词、语音识别、语义理解、对话管理、语音合成，每一层都值得做深。供应商通常给的是整体方案，你只能在上面做简单配置，想加一个车控领域特有的意图，比如“打开洗车模式”“把座椅调到我最舒服的位置”，就得看供应商给不给你开放接口。自研之后，我们可以把用户数据直接作用于模型优化，同样的说法，在车上越用越灵。这个体验差距，是评测机构测不出来的，但用户每天都能感受到。还有一块经常被忽略：账号体系和应用生态。自研座舱意味着你有自己的用户体系，可以打通手机、手表、家充桩这些外部设备，实现上车前就准备好的无缝衔接。这是生态想象力的基础。2.3 整车电子电气架构与域控制器：自研的硬件底座自研软件跑在什么上面？答案是整车电子电气架构。传统车是分布式架构，全车几十个ECU各自为政，每个功能一个控制器，软件升级要么不管、要么只能整车进店刷写。智能化时代要把几十个ECU收敛成几个域控制器：智驾域、座舱域、车身域、动力底盘域，再往后是中央计算平台。做域控自研，主机厂要具备的是“软硬解耦”的能力。底层的计算平台可以是英伟达、高通这些芯片供应商，也可以是自己定制的芯片，但在其上跑的底层软件、中间件、应用框架必须掌握在自己手里。这就像智能手机：芯片可以买，但操作系统和核心应用是自己做的，体验和生态才能捏在自己手上。这里面有个很大的坑：域控制器集成度极高，发热、功耗、电磁兼容都有严格约束，算法模型要在一个功耗上限内跑满，不能动不动就过热降频。我们早期某款车型的智驾域控，长时间高负荷运行时会出现算力抖动，直接导致接管提示听起来很急。后来做了多轮功耗调优，把模型推理的算子拆开在不同计算单元上调度，这个问题才算解决。2.4 芯片自研的边界：不是什么都得自己造自研不等于什么都做，芯片就是一个典型。AI芯片自研是巨头级玩家的游戏，投入几十亿起步、流片周期以年计，而且一旦做出来，还得有足够大的量产规模摊薄成本。对绝大多数车企来说，更务实的路线是：深度参与芯片定义，但不用亲手造。深度参与的意思是在芯片立项阶段就绑定核心IP需求，比如NPU算力布局、内存带宽、安全性设计，都要围绕自家算法来定。算法需要多少算力、数据流如何走，直接反馈给芯片团队，这样流片回来后性能才能真正释放。我们有一次和某芯片厂商合作，提前半年把自研BEV网络的算子需求提过去，等到芯片量产，模型在它上面跑出来的效率比上一代平台提升近一倍，这就是深度协同的价值。边界也很清晰：通用型芯片，比如MCU、电源管理、接口芯片，直接采购成熟方案就好；战略级芯片，比如主控SoC、自动驾驶SoC，可以自研或深度定制；中间那些有技术含量但迭代快的AI加速单元，适合跟芯片厂商联合定义。把每一类想清楚，预算才花得值。3. 自研的账怎么算：成本、投入与时间线3.1 研发投入是一场持续多年的马拉松智能化自研烧钱的速度，远超很多人想象。一个千人规模的研发团队，每年光人力成本就是十几亿，再加上算力集群采购、数据标注外包、测试车队运营，每年几十亿投入很正常。做这件事要想清楚，它不是一次性的投入，而是持续多年的马拉松——第一年你可能只看到方案,第三年才有靠谱Demo，第五年才能量产上车。我见过一些企业在前两年还信心满满，第三年开始收缩预算，结果算法团队的人被竞品挖走一半，项目就这么烂尾了。自研最大的风险不是技术难，而是组织耐不住性子。它不像买供应商方案，给钱就有交付；自研的产出曲线是前期模糊、中期剧烈波动、后期才稳步上升，没有足够耐心，很难熬到收获期。那到底该投多少？没有一个固定比例，但可以参考两个数字：一是研发投入占营收的比例，新势力要做到15%以上才有资格谈智能化，传统车企普遍在3%-5%，差距就在这里；二是智能化研发中算法和数据团队的占比，如果软件算法团队不到研发总人数的一半，大概率还是以硬件为主，智能化深度就有限。3.2 人才密度决定了自研的天花板自研最难的不是钱，是人才密度。自动驾驶和座舱交互是典型的交叉学科领域，既要有懂深度学习的算法工程师，又要有懂操作系统的底层开发者，还要有懂整车功能安全、懂传感器标定的系统工程师。这批人市场上本来就少，而且流动极快。我在招人时最看重的是“工程嗅觉”。很多候选人简历漂亮，一问到量产细节就露怯：有没有做过模型裁剪？有没有处理过实车上的时延抖动？有没有和功能安全团队杠过需求？这些经验不是论文里能学到的，只能是真刀真枪的量产项目里磨出来的。一个成熟的智能驾驶算法工程师，从入职到独当一面，至少需要一年半，前半年都在熟悉工具链和真实数据。自研团队的组织架构也很重要。我们早期是纯职能制，算法、软件、测试各自为战，结果每次联调都像打仗。后来改成“版本火车”模式，每三周出一个可测版本，所有人围绕版本目标倒排计划，算法工程师和车辆测试工程师坐在一起办公，效率明显提升。研发管理上的精细化，很多时候比多招一百人更管用。3.3 什么阶段开始自研最合适很多人问我是该从第一款车就自研，还是先买方案过渡。我的看法是：起步期可以合作，但必须有自研的战略安排，最好是第一款车就开始建立自研团队，哪怕做的功能少一点、慢一点。起步期买方案有几大隐藏风险：一是供应商方案的黑盒特性，出了问题你只能“换件排查”，很难精准定位；二是方案的可扩展性差，供应商下一版本更新可能推翻你的二次开发；三是团队没有实战机会，永远在别人的代码上做配置，三年后还是执行者，不具备主导权。更现实的是，数据资产需要提前积累。如果你第一辆车用的是供应商方案，那产生的事故数据、接管数据、用户行为数据，大概率都不归你。等你想自研时，手里没有过去几年的数据积累，一切从零开始，这比晚做三年算法还致命。数据这件事永远不嫌早，越早开始采集和沉淀越好。4. 实操视角：一个自研功能的完整落地流程4.1 以高速导航辅助驾驶为例，看全链路怎么走我参与过的最典型的自研项目，是一款车型的高速导航辅助驾驶功能，从立项到全量推送整整走了十四个月。这个周期在行业内不算长，主要原因是团队已经有基本的数据闭环基础，但即便这样，过程中的波折也不少。第一步是需求定义和场景清单。产品团队和算法团队坐在一起，把高速场景拆成几千条用例：有清晰车道线的、无车道线的、有锥桶施工的、有大车压线的、有恶劣天气的、有隧道强光的。每一条用例都要明确预期行为和退出策略。这一阶段最容易犯的错是贪多，什么都想做，结果每个场景都做不透。我们最后的妥协是：首批只支持高速和城市快速路，暂不支持施工场景的自动避障，故障时清晰降级提醒用户接管。第二步是数据收集和模型训练。定义好场景后，车队开始按区域跑图，采集高速路段的视频和感知数据，同步做语义标注。模型训练不是一次性的，而是每天持续进行——白天有新车数据回流，晚上自动出训练任务，第二天早上评估指标。我们用的训练集群是几百张GPU卡的规模，配合自研的分布式训练框架才能支持这种节奏。第三步是仿真验证和实车测试。新模型先在仿真场景库跑一遍，通过率不达标直接打回；达标后进入测试车实车阶段。实车路测阶段最耗时，一个版本在高速上跑几千公里才能覆盖主要场景，很多问题只在特定光线、特定路口出现，跑不到就发现不了。团队每周例会的固定环节，是过一遍上一周采集到的bad case，讨论是算法问题还是策略问题，逐条给出处理意见。第四步是影子模式和灰度发布。模型达到标准后，不直接推给用户，而是先以影子模式运行：车辆继续用旧版本控制，但新版本在后台同步运行，持续对比输出的差异。影子模式跑上一个月，确认新版本没有带来异常风险，才开始内部员工灰度，然后是小规模用户、大范围推送。OTA是一个精细化操作，随时可以拉停。4.2 过程里的关键参数和判断依据功能落地中用到的几个关键参数值得记录。感知帧率要做到每秒15帧以上，否则高车速下目标运动轨迹会出现跳变；控制指令时延要控制在150毫秒以内，超过这个值，驾驶员会明显感到“车反应慢半拍”；变道决策置信度阈值要设到0.9以上，宁可偶尔不变道，也不要频繁无效变道引起用户吐槽。还有一套“安全兜底”的逻辑。系统一旦检测到驾驶员脱手时间超过规则限制，会先声音提醒、再点刹提醒、最后退出辅助驾驶并请求接管。很多人以为自动驾驶是机器完全在开，实际上现阶段更准确的说法是“人机共驾”——机器负责大部分稳定工况，人负责监督和边缘兜底。自研要把这套交互逻辑打磨得很细，否则很容易给用户造成误导，安全风险远比体验问题严重。4.3 量产路口必做的两件事：冻结与验收自研功能在量产前的最后阶段，最重要的事情是版本冻结和量产验收。版本冻结不是说代码不能不改，而是所有变更必须走严格的变更管理流程，任何改动都要重新跑全量仿真和关键路测。我们有过一次教训，邻近量产时为了让跟停体验更平顺改了一个参数，结果引入了一个低速下的偶发抖动，差点影响投产节奏。后来所有参数变更必须走测试专项，数据说话。验收阶段要看三个维度：功能性能指标、用户体感主观评价、安全冗余表现。性能指标好理解；主观评价需要一支固定评审团，每天开同一段路，靠脚感和体感打综合分；安全冗余重点看系统在异常状态下是否优雅降级。这三个维度都合格，功能才算具备交付条件。5. 常见问题与排查技巧实录5.1 问题一：自研进展太慢，怎么应对内部质疑自研团队最容易被问的一句话是：都做了一年了，怎么还在改Bug？这句话背后是管理层对投入产出比的焦虑，处理不好项目很容易被砍预算。我的经验是，从第一天就要建立可量化的进展汇报机制。不要只讲算法指标提升了多少，而是把进展拆成用户可感知的版本维度。比如每三周发布一个测试版，列出这个版本改了什么体验问题，下周计划解决什么。当管理层能看到节奏的时候，焦虑感会大幅下降。另一个办法是阶段性展示“技术肌肉”，哪怕是不直接上车的技术突破，比如某个感知模型在权威数据集上的排名、一次极端case的成功处理，都能给自研价值增加论据。5.2 问题二：累死累活把数据采回来，质量却不行这是数据闭环里最普遍的坑。车队跑了几万公里，回传的数据有一半不能用：要么是场景太普通没有训练价值，要么是传感器标定漂移导致数据整体偏差，要么是隐私脱敏没做好，根本进不了数据平台。解决方案要靠系统化治理。车端数据挖掘系统要设置动态触发条件，只有出现特定场景或者模型信心不足时才回传数据，而不是无脑录制；云端要做自动质量评估模型，基于多维度指标过滤低质量片段。标定更是要纳入日常运营流程，每次车辆保养时固定做传感器标定验证，确保回传数据的一致性。数据质量这件事，越早制定标准，后面的损失越小。5.3 问题三：算法团队和系统团队互相甩锅自研项目很容易出现这种局面：一个功能出了问题，算法工程师说是底软时延太大，系统工程师说是算法设计不合理，两边在会议上吵得不可开交，问题却迟迟没有结论。我后来建立了一套“端到端 owner”机制。每个功能指定一个负责人，不管内部是哪一层的Bug，owner要对最终用户体验负责，他有权调动算法、系统、测试任何一方资源。同时建立了一套全链路埋点系统，问题发生时能追踪到具体模块、具体环节，而不是靠猜。埋点系统刚开始建设时投入不小，但它能省下大量扯皮时间，非常值得。5.4 问题四：什么都想自研，结果什么都做不好自研的边界问题，是另一个极端。曾经有产品经理提了一堆自研需求，从流媒体后视镜到整车震动反馈，恨不得每颗螺丝都自己造。这会导致资源极度分散，核心战斗反而打不赢。我的原则是“战略定位决定自研清单”。与用户体验强相关、迭代速度要求高的领域，比如智驾算法、语音助手、整车OS中间件，必须自研；与体验弱相关、供应链成熟的领域，比如轮胎压力监测、网关模块，直接采购就行。适合别人做的，大方交给别人做，把自己的精力集中在能形成长期差异化的地方。6. 关于护城河的一个补充技术自研这个护城河，它不是一条笔直的河，更像是一整套水利系统。算法、数据、芯片定义、组织能力、供应链掌控力，每一条支流都在为这条系统输送能量，任何一条断了，整个体系都会受损。这也是我看一家企业智能化实力时，不太关心它PPT里写了多少自研比例，而是更关注几个可验证的信号：数据闭环是不是真的跑通、团队有没有量产交付经验、软件迭代有没有形成稳定节奏。有些人觉得自研是一场豪赌，烧钱多、见效慢，不如买现成的。但我的判断是，智能化自研不是选择题，而是生存题。短期买方案可能显得更高效，但长期看，没有自研能力的企业，在智能电动车这轮竞争里会被加速淘汰。最后说一点个人体会。我在实际项目中最大的感触是，自研最难的不是技术本身，而是“坚持”这两个字。资本市场波动、内部战略摇摆、竞品节奏施压，每一样都可能让团队中途放弃。但真正走过完整的自研周期之后，你会看到它带来的回报远超预期：不只是技术能力，更是团队信心、用户口碑和供应链话语权。护城河从来不是一天挖成的，但它一旦成形，别人想跨过来，难。