智能化技术自研这件事我入行这几年看得越来越清楚它不只是技术路线选择更是一家智能电动车企业能不能把护城河挖深的生死题。最近和同行聊起新势力的核心竞争力大家绕不开一个判断——谁把智能化自研做透谁才有资格谈长期主义。今天我不讲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”机制。每个功能指定一个负责人不管内部是哪一层的Bugowner要对最终用户体验负责他有权调动算法、系统、测试任何一方资源。同时建立了一套全链路埋点系统问题发生时能追踪到具体模块、具体环节而不是靠猜。埋点系统刚开始建设时投入不小但它能省下大量扯皮时间非常值得。5.4 问题四什么都想自研结果什么都做不好自研的边界问题是另一个极端。曾经有产品经理提了一堆自研需求从流媒体后视镜到整车震动反馈恨不得每颗螺丝都自己造。这会导致资源极度分散核心战斗反而打不赢。我的原则是“战略定位决定自研清单”。与用户体验强相关、迭代速度要求高的领域比如智驾算法、语音助手、整车OS中间件必须自研与体验弱相关、供应链成熟的领域比如轮胎压力监测、网关模块直接采购就行。适合别人做的大方交给别人做把自己的精力集中在能形成长期差异化的地方。6. 关于护城河的一个补充技术自研这个护城河它不是一条笔直的河更像是一整套水利系统。算法、数据、芯片定义、组织能力、供应链掌控力每一条支流都在为这条系统输送能量任何一条断了整个体系都会受损。这也是我看一家企业智能化实力时不太关心它PPT里写了多少自研比例而是更关注几个可验证的信号数据闭环是不是真的跑通、团队有没有量产交付经验、软件迭代有没有形成稳定节奏。有些人觉得自研是一场豪赌烧钱多、见效慢不如买现成的。但我的判断是智能化自研不是选择题而是生存题。短期买方案可能显得更高效但长期看没有自研能力的企业在智能电动车这轮竞争里会被加速淘汰。最后说一点个人体会。我在实际项目中最大的感触是自研最难的不是技术本身而是“坚持”这两个字。资本市场波动、内部战略摇摆、竞品节奏施压每一样都可能让团队中途放弃。但真正走过完整的自研周期之后你会看到它带来的回报远超预期不只是技术能力更是团队信心、用户口碑和供应链话语权。护城河从来不是一天挖成的但它一旦成形别人想跨过来难。