“在车企的决策链上级别越高的领导，越不理解软件的价值。”
在实践中，核心管理层越缺乏软件思维，做一件事情所需要的层层汇报就越多、决策流程就越漫长，因而，效率就越低。
只要“纯硬件思维”的领导还在台上，『软件定义汽车』就无从谈起。所以，软件就别急着去“定义汽车”了，先去“定义”一下车企大佬们的大脑再说吧？
为避免误伤，需要先强调一下：
本文diss的对象并不是“硬件思维”，而是“纯硬件思维”。“纯硬件思维”本身无错，但这种思维的人竟然在管理一项事关『软件定义汽车』的业务，并且还故步自封、不积极转变，那他就应该受到批判。
此外，这里说的是“纯硬件思维”，而非“硬件出身”——有的人是做机械出身，但通过长期的学习，具备了软件思维，那他就不属于本文所说的“纯硬件思维”这类人。
『软件定义汽车』的口号喊了好几年了，但只有极个别科技公司有了实质性进展，大部分玩家，尤其是传统车企和传统Tier 1都没什么起色；有一些曾经实力很雄厚的主机厂和国际Tier 1甚至面临着在这一波智能化的浪潮中“被出局”的危险。
造成这一局面的因素很多：技术不够先进，管理风格不合时宜，产业生态没建好......但归根结底，是数量非常非常多的“领导”无法胜任自己当前所在的岗位。
传统汽车时代也有软件，但那时的软件很小，且软件是依附于硬件而存在的，而当下我们谈的软件，是强大到足以“定义汽车”的软件，这就需要管理者有很强的“软件思维”才行；然而，许多领导岗位都被“干了一辈子机械”的人“占据着”。
“干了一辈子机械”也不是原罪。事实上，许多“干了一辈子机械”的人对产业的发展做出了很大的贡献，甚至是巨大的贡献，这些是不容否认的。但在这一个快速变化的产业里，一个人能对组织的当下和未来做出什么贡献，这是更应该受到关注的。
有一些人虽然在汽车产业“干了十几年机械”，但他们一直保持着一颗学习的心，也对大环境的变化格外敏感，因而，早在五六年前就开始积极学习，现在也具备很强的软件思维，成了合格的“软件定义汽车”业务的管理者。
可还有更多“干了一辈子机械”的人，在过去十几二十年里，除了那点专业知识之外，别的东西都不学习，他们不是“有20年工作经验”，而是“一份经验用了20年”，思维方式不再迭代。
在产业智能化转型的初期，他们没有足够高的敏感度，没有及时进入对新东西的学习状态；或者，在舆论的影响或老板的指令下，他们也尝试过学点新东西，这时才发现，自己已经丧失了学习能力，即便是真的想学，也已经“学不下去了”。
【说这些人“丧失了学习能力”，绝对不算夸张。比如，静下来读完九章智驾的一篇万字长文，已经“遥遥超出”了他们的“阅读理解能力”的上限。哈哈】
一些尚未丧失学习能力的，会学习一些智能化相关的专业知识，并自以为只要掌握些这方面的皮毛，就能向老板汇报、也能跟下属及合作伙伴有“共同语言”了；但对需要以怎样的思维方式来管理软件团队、如何打造出适合软件人才的组织文化、如何跟软件供应商相处这些更高维的知识，他们却关注不多。
身居管理层，但思维方式、认知水平却跟基层的螺丝钉们没有实质性区别。
上述种种现象，都印证了笔者近日在《“被干掉”的CEO和CTO：理工男歧视文科、轻视商科，终遭报应》一文中提到的观点：
人文素养差、商业思维弱的理工男，对环境的变化比较迟钝、对即将到来的危险毫无知觉；他们所谓的“学习”，往往是“只关注对具体知识的学习，却不关注思维方式的培养”“重视『术』，轻视『道』”，这其实就是“捡了芝麻丢了西瓜”。
许多“干了一辈子机械”的领导过不了“软件思维”这一关，这一问题，在传统车企和传统Tier 1都很严重。 这也是『软件定义汽车』理念落地的最大障碍之一。
所谓“软件思维”，并不是只要懂软件的原理就可以了，而是说跟软件相关的种种要成为你的潜意识、价值观及决策模型的一部分（甚至是最重要的部分）。下面，我们掰开了看看传统车企及传统Tier 1的大佬们“缺乏软件思维”的几大症状吧。
软件与硬件最直观的区别是：硬件是有形的，而软件是无形的。
一组可供对比的典型场景——
硬件公司接待客户或政府领导时，带他们看实验室、检测设备、生产线，那种气势恢宏，很容易让客人有“哇塞哇塞”的兴奋；
软件公司的人在接待客户或政府领导时，就只能跟别人“讲PPT”了，那对他讲的东西“到底是真的还是忽悠”，对方心里也没底儿。
另一个典型场景是，在公司内部——
如果钱投入到硬件设备上了，领导心里很“踏实”，因为钱花在哪了、进展到哪一步了，他能看得见，他有“掌控感”；
但如果钱投到软件上面了（其中有相当大一部分最终都是投入到人身上了），老板心里是很不踏实的，因为，软件这玩意儿是无形的，老板看不见，也无法确定最终会不会真的有收益。
可以把很多钱投到设备上、但不能投入到人身上，对人的价值承认度不足，这种“纯硬件思维”主导下的行为，在国央企尤为明显。这种思维的一个直接结果是，这些公司软件人才的薪资水平远低于市场价，因而，人才流失严重，之前的积累都化为泡影。
国内某头部主机厂之前有两款车型在规划自动驾驶方案时，为控制成本，就选用了小算力平台，结果发现，没法OTA。
那时，发现很多竞品车型都能OTA，他们很着急，但也没辙。这样，该主机厂看似自动驾驶“车队规模很大”，但由于无法OTA，在该车型上前期的投入对长期的能力提升并没有什么帮助。
后来，该公司的一个反思就是，“不能只考虑上车成本，还得考虑OTA”“有的钱，是不能省的”。
还有一个相似的案例：某德系Tier 1此前做域控制器时，在产品定义阶段“把硬件资源的上限卡得死死的，多一分都不行”，结果，等产品研发出来之后发现，无法支持最新版本的算法，落伍了。
不仅是做域控制器时，该Tier 1之前做发动机的ECU时，也是“把硬件抠得太死了”，往后，随着软件功能越来越多，硬件就跟不上了。“这时，对策只能是对软件做精简，让软件来适应硬件”。
人家都是硬件为软件服务，但这家德系Tier 1的思路却是“软件迁就硬件”，听上去像是“削足适履”？
几年前，该Tier 1德国总部的内网上有一篇博文《我为什么离开XX》，是一个从Facebook加入该公司的软件工程师在离职前写的。这篇帖子集中吐槽了该Tier 1大量高层管理者都是“纯硬件思维”，管理方式已经不能适应“软件定义汽车”的需求。
传统车企在表达自己向智能化转型的决心时，通常会宣称自己计划在几年内组建起2000人、甚至5000人规模的软件团队；在向外展示自己的智能化能力已经达到了怎样的水平时，通常会说自己的软件人才数量已经达到了XXX。
这就纯粹是“外行思维”了。
三年前，笔者跟某自动驾驶算法公司（如今算法能力位列TOP 3）CEO聊起此事，他说：“我只要一听哪个公司说自己要招几千名软件人才，就会断定他们‘肯定做不成’！”
后来，我又看见另一家自动驾驶方案公司（如今算法能力位列TOP 5）CEO在微信朋友圈点评某车企“数千名软件人才”的新闻：“真的需要这么人吗？给我300人，我肯定能搞出来。”
为什么这两家自动驾驶公司CEO均对主机厂在软件开发上迷信“人海战术”的做法表示不屑一顾呢？
因为，对软件开发来说，重要的并不是人才的数量，而是人才的质量。有时候，一个关键的大牛，价值超过1000个普通的算法人才；相反，不合适的人，你哪怕招10000个人，也不顶用啊。
而且，如果大量的人都不是很合适，那你的软件团队人数越多，组织的协同成本、甚至是“撕逼成本”就越高，因而，整体效率就越低。
由于软件具有“看不见”的特质，相比于硬件，它有更多的东西是无法通过图纸或文档等书面形式来呈现，而是装在工程师的脑子里的，这就导致，软件人员与软件人员、软件人员与硬件人员的协作频率，都要远高于硬件人员与硬件人员的协作频率。
可以说，过多的协作，是组织的低效之源。
要提高效率，就得力争“非必要不协作”。这就对个人的能力模型提出了更高的要求——需要每个人的能力结构更加健全，能够“端到端”地完成一些事情，而不是一些很简单的事情都需要别人来配合。
君不见，特斯拉Autopilot团队的软件人才和硬件人才之和总共也就200-300？核心算法团队应该就只有几十个，剩下有100-200做工程化的。
所以，核心应该是拼人才的质量，而不是数量。
然而，糟糕的是，有一些传统车企似乎完全没有这个概念。尤其夸张的是，他们所谓的“在很短的时间内将自动驾驶团队从几十人扩张到几百人、从一两百人扩张到上千人或数千人”，有可能都不是从外面招了很多优秀的软件人才，而是从公司内部的其他部门“划了”一些人到自动驾驶部门。
通过这种方式“做大”的自动驾驶团队，规模是上去了，但能力体系却仍然可能是传统的。这就存在一个巨大的风险：如果自动驾驶团队的规模很大但高端人才的密度却很低，那极个别几个出类拔萃的人才就会没有任何归属感，因而，干不了多久就会落荒而逃。
前段时间，笔者向三位既做过硬件又做过软件的朋友提了一个问题：
在离职交接时，如果要把所有的事情都交接清楚，软件岗位的交接，是不是需要比硬件岗位更长的时间？比如，硬件岗位，可能1个月时间就能交接清楚，但软件岗，2个月也未必能交接清楚？
因为，硬件相关的大部分事项，都可以通过实物或图纸来呈现，而软件相关的很多事项，它是装在工程师的脑子里的，没法通过图纸来体现的。
几位朋友的答案都印证了笔者这一猜测。
当然，实践中是很难留给软件岗位的交接更充足的时间的——
如果是员工主动辞职，在下一任东家都找好了的情况下，他们通常并不会想“我要比硬件同事多花点时间交接，争取交接到位”；
在员工被裁的情况下，领导更不会考虑“因为你是做软件的，所以，留给你更长的交接时间”，而是非常简单粗暴，无论员工是做硬件的还是做软件的，都要“分分钟钟走人”。
显然，在员工离职、尤其是被裁的情况下，软件研发成果在交接过程中的“漏损”要比硬件研发成果多得多。
在很难对软件员工的“离职交接”环节做很明显的优化的情况下，让员工在还在职的时候就把文档写好，就显得尤为必要了。
文档化，对研发成果的积累传承是极为重要的。而软件因为“看不见”，所以，要保证研发成果可传承，对文档化的要求应该是比硬件更高的。
实际上，做软件工程的都知道，代码并不是最有用的，相关的文档/注释才是开发过程的结晶。然而，车企的领导们普遍对文档化的重要性认识不到位，“以为只要把代码写好就可以了”。在实践中，由于交付压力比较大，领导们更关注的是“快”。
哪怕有一些工程师真的很看重文档化，他们也必须向交付效率妥协——写文档不在KPI里，你不花心思在这上面，并不会受到惩罚；但如果花过多心思在这上面，可能会“耽误正事”，反而会让领导不高兴。
一位算法工程师说：
很多领导意识不到文档的重要性，你吭哧吭哧写文档，半天没输出代码，领导还以为你在摸鱼呢。
于是，文档化的事情可能就被耽搁了。
与文档化被耽搁相类似的另一个问题是：在交付压力下，代码质量越来越差。
因为在“短期随便改，获得立竿见影的效果，但是代价是后面代码越来越难维护”和“仔细研究问题的根本原因，不惜对代码进行大量改动，以保证后续可以维护”这两个思路中，落地阶段，领导们永远是选择前一种。
可以说，在一些细节上，那些有追求的一线工程师是长期主义的，他们更希望做一些“可传承”的事情；但外行领导是短期主义的，对他们来说，眼前的苟且才是最重要的。
而正是领导的这种短期主义，导致文档化做不好、代码质量也越来越差，结果，等关键岗位上的人员离职之后，研发成果能保留下来的也不是很多。
两年前的夏天，笔者在无意间比较了多家智能汽车产业链上的公司的文化衫之后得出一个“规律”：通常，硬件公司的文化衫是带领子的，而软件公司的文化衫是不带领子的。
对笔者的这一发现，一位同事的解释是：硬件公司认为员工需要管控，而文化衫上的领子，就是管控的标志；软件公司认为员工是不需要管理的，所以，文化衫普遍不带领子。
那么，“需要管理”的硬件人才和“不需要管理”的软件人才的工作风格又有何不同呢？笔者最近在跟很多业内朋友深入交流后得到的答案是：
做硬件，对流程中的每一个步骤和时间节点都卡得特别死，工程师的个性很难在这个过程中有所体现；
做软件，也有流程，但工程师个人的特色可以在代码中得到很强的体现——实现同样一个任务，10个工程师写出来的算法，可能是10个不完全一样的版本。
这两种不同的工作风格，对人才的需求又有何不同呢？一位从硬件转软件的朋友是这么解释的：
硬件因为对过程管控做得比较严，所以，通常就不会对工程师的自驱力做硬性要求——一个工程师无论自驱力强还是弱，只要遵守了流程和时间节点，最终做出的东西，差别不会特别明显。
然而，软件就不一样了。软件的招聘门槛很低，一个外行在北大青鸟这种培训班训练一段时间后也可以写软件，但软件的过程管控很难，质量就难以得到保障，所以，要真正把软件做好的话，就需要高度自驱、对交付质量有完美主义或强迫症的人才能胜任。
自驱型的人也反感被严苛的流程、绩效考核等方式来管理。 因为，严苛的管理，主要是针对不自驱的人设计的，通常，自驱型的人是看不起没有自驱力的同事的，你用对待后者的方式来管理前者，前者就会觉得自己“被侮辱”了。
遗憾的是，很多“干了一辈子机械”、在“重流程” +严格考核的文化下长大的管理者，尽管已经身居高位，但他们自己其实没有足够的自驱力（至少是自驱力不能跟那些最优秀的软件人才匹敌）的，因而，他是没有能力跟自驱型的软件人才共情的。
或者，哪怕他们自己也有比较强的自驱力，但由于自己在过去这些年已经对“流程管控”习以为常了，因而，对自驱力强的软件人才对僵化流程的反感，他们无法与之共情。
一位自动驾驶公司CEO告诉笔者，他们去给某传统车企做工具链方面的培训，结果发现，对方的数据工程师的电脑是不能上外网的。“数据安全管理可以理解，但限制软件人才上网，这不是因噎废食吗？这样的文化，你怎么能自研呢？”
这一点，又恰好印证了笔者最近的《被“干掉”的CEO和CTO：理工男歧视文科、轻视商科，终遭报应》一文的观点：人文素养和商业思维弱的理工男，普遍同理心比较差，在做管理的时候，无法跟下属共情。
孟子有句话是“君之视臣如土芥，则臣视君如寇雠”，你都不考虑下属的感受，下属凭啥好好配合你完成工作？
当然，上面这些“大道理”可能领导都懂，然而并没有什么卵用。
我们看看这个例子：模型工程师花钱买数据去训练模型，500万花出去了，但模型还没训练出来，车企领导也不知道啥时会有结果，“那他的血压要上去了”。
还有一位主机厂的战投负责人告诉笔者：
我们公司的大部分高管都是制造背景，他们确实不懂软件，所以，做软件的人要想说服他们，会特别难。尤其是，对软件，他们也要用测硬件的方式来测一下，但全靠测的话，那软件的价值就不容易体现出来（软件的很多东西，是没法测出来的）。
毕竟，硬件的设计及制造过程是清晰的，领导看一眼就知道进展到哪一步了，心里比较踏实；而软件的中间状态是不可控的，这也让领导的心里“很没底儿”——这导致的结果是，领导对软件团队的信任度，其实是不如对硬件团队的信任度的。
一个无法回避的难题是，对不懂软件的管理者来说，如何评价软件工程师的工作成果，也是一件非常困难的事情——
看代码吧，他看不懂；
按代码量来评估吧，好的代码其实是很简单的，实现同一个任务，代码量越多，反而会导致运行效率越低，功耗也会更高；
按代码错误率降低了来评估吧，工程师可以先故意写错，然后再去debug。
既然不知道如何做结果评价，那就只能加强过程管控了。
1. 迷信“白盒交付”
无论动机是为了拿出自研的“政绩”向上头交差，还是为了更高效地向供应商“学习”，主机厂要求供应商“白盒交付”已经成为一种很普遍的现象了。起初，供应商们对主机厂提出的“白盒交付”要求还很抗拒，但现在，他们也不抗拒了。
因为，越来越多的供应商发现，若自己以“白盒”的形式做交付，主机厂需要支付比“黑盒”更多的钱，而自己却不会有什么实质性损失；另一方面，主机厂也没能力基于“白盒”搞出啥名堂。
在白嫖供应商的技术方面，白嫖软件知识的难度远大于白嫖硬件知识：
对硬件，主机厂如果能拿到供应商提供的详细的图纸，可能会很快搞懂里面的原理，再配之以自己强大的工程能力，便有机会把供应商的技术学到手；
对软件，即便主机厂能拿到供应商的全部代码，也未必能“接得住”，比如，代码里面可能会有一些隐性的bug，但别人不说，你不会知道的，而你如果自己去改了人家的代码，bug会更多。
通常，供应商做白盒交付的时候，也会设一些陷阱。比如，只给模型推理的代码，不给训练的代码。那主机厂即便是拿到了白盒，也用不起来。
更糟糕的是，主机厂花了很多时间去研究供应商的白盒，等他把这个白盒里面的技术搞明白，供应商已经在给其他客户卖迭代后的新版本了。这等于，主机厂的“白盒研究成果”还没使用，就已经落伍了。
关于白盒交付中的坑，九章在2023年7月中旬的《自动驾驶“全栈自研”大溃退——车企被迫“认清现实、放弃幻想”》一文中有过更详细的解读，在此不再赘述。
实际上，白盒交付，是供应商给主机厂的麻醉剂，也是缺乏“软件思维”的主机厂领导们交给供应商的智商税。
说白盒交付是“智商税”，这并非来自供应商的“一面之词”。实际上，很多主机厂的软件工程师也持类似的观点。还有一位传统主机厂的工程师很羡慕地说：“理想他们就想得很清楚，不管白的黑的，只要能实现功能、不出bug、价格足够低就行。”
这位工程师羡慕理想的管理层“想得很清楚”，就是在讽刺自家公司的领导们“没想清楚”。
2. “分开定点”
尽管产业已经发展了好几年了，但很多在主机厂身居高位的领导对自动驾驶的认知还是不足的。最典型的是：把自动驾驶系统视为“一堆零部件的集合”，而不是一个“有机的系统”。
“分开定点”，便是这种“零部件思维”的集中体现。“分开定点”经常是一个1+1<1.5的事情——既让被迫参与其中的供应商们苦不堪言，也让主机厂自己的相关人员感到心力交瘁。
一种典型场景是：算法公司说，我用这家的这款摄像头已经很久了，我的算法在这个摄像头上跑的话效果最优；但主机厂会说，不行，你得用我们推荐的。 于是，算法公司不得不基于一款陌生的摄像头对算法做优化，并对摄像头做标定，效率降低了不少。
在“分开定点”的情况下，算法公司的大量时间都被用来做无用功。
而主机厂的人也并没有从“分开定点”中尝到什么甜头——如果项目交付被迫延期了，最上面的人不会认为“分开定点”是最重要的原因之一，而是会把主因归结为项目组Leader的无能。从这个角度看，“分开定点”会加剧组织内部的内耗，甚至会迫使那些觉得“领导是傻X”的优秀人才快速逃离。
那么，对自动驾驶系统各模块分开定点，难度及后果的严重程度为何会远远超出主机厂最初的预期呢？
真正难的不在于“分开”，而在于将来自不同供应商的不同模块集成到一起。传统硬件跟传统硬件的集成，是“物理变化”；但现在，软件跟软件的集成、软件跟智能硬件的集成，都是“化学变化”。
具备初中以上学历的人应该都清楚，跟物理变化相比，化学变化最本质的不同是“有新的物质生成”，那么，在“分开定点”的情况下，将来自不同供应商的软件模块、软硬件模块集成在一起，可能一不小心就生成了谁都不想看到的“新物质”。
物理变化往往摸得着、看得见，哪里出了问题，理解起来比较容易，追踪难度也相对较低；但化学变化往往显得过于神秘，解释难度和追踪难度都比较大，甚至具有“不可解释性”，因此，跟上一个时代偶尔存在的“分开定点”相比，『软件定义汽车』时代的“分开定点”，带来的系统集成难度、检测难度、纠错难度都指数级上升，当然了，在此过程中的“撕X成本”也会大幅度上升。
在“分开”之后，为了保证上下游各模块之间的高频交互不受影响，各方都需要把所负责模块的接口定义得足够清晰。但在真正遇到问题之前，谁也不可能知道“把接口定得足够清晰”的标准究竟是什么，因此，后续执行中的各种撕X自然难免。
哪怕是在同一个公司内部，感知团队和规控团队日常的“撕X”都会很严重，更何况是在不同公司（感知算法供应商和规控算法供应商）之间呢？
还有一个极容易被忽略的问题：
在分开定点的情况下，供应商的项目经理往往也只能是“分开思考”（只思考我自己做的这一部分），长此以往，他们就很难养成系统性思维；如果所有的主机厂都在搞“分开定点”，那供应商的CTO、CEO也可能被迫去“分开思考”，久而久之，就无法养成足够强的系统性思维。
当一个供应商甚至多个供应商的项目经理乃至管理层都不具备很强系统性思维时，他们如何能做出好的产品呢？
本来，“分开定点”的动机只是为了更好地“控制供应商”，没想到，结果却变成了“削弱供应商”！供应商的能力被削弱了，不也意味着你得到的技术和服务的质量更差了、你的产品竞争力也更弱了吗？
再说了，跟缺乏系统性思维的“乙方”沟通，你们自己都不会觉得“心累”吗？心累得久了，可能就会有心理疾病哦。
现在看来，在软件在系统集成中占的权重越来越高、“化学变化”成为常态的时代，为了更好地控制供应商而去搞“分开定点”，最终却把自己累个半死，也导致交付效率、甚至交付质量极大地降低，这种看起来“损人不利己”的蠢事儿，实际上是只有“纯硬件思维”的人才能干出来的，真是“无知者无畏”啊。
相反，软件思维强的人不仅更能意识到“软硬一体”“软硬件协同优化”的必要性，他们甚至认为规控和感知应该交给同一个团队来做。“整个链条不打通的话，你感知做得再好，也不知道规控需要什么信息。”
到2023年，已经有一些主机厂发现“分开定点”行不通，重新回归到传统的“指定Tier 1”模式了。
甚至，有一些主机厂的反思更彻底。前段时间，某传统主机厂的自动驾驶负责人在跟笔者交流时说：“我们原来还想，感知找一个牛逼的供应商，规控我们自己做，把感知和规控解耦，但现在看来，感知和规控解耦，绝不会是未来的方向。”
当然，肯定还会有很多主机厂会继续在“分开定点”的问题上“一条道走到黑”。
这些主机厂的人当然会辩解说：分开定点的目标不是为了折腾供应商，更不是为了“自残”，而是为了让供应链更可控、为了降低成本。但是，笔者要提两个不可回避的问题：
有的环节，明明上游已经杀成一片红海了，你们为何仍然要强调“可控”？难道供应商都是傻X，宁可把订单让给竞品、自己少挣钱，也要卡你的脖子？
你们说的“降低成本”，是只算了显而易见的BOM成本，还是也包括了分开定点后新增的协作成本（其中最重要的是撕X成本）？以及，分开定点后效率降低导致车型上市延期的机会成本，在你对“成本”的考虑范围内吗？
莫非，这些主机厂之前曾被不可控的供应商伤出了“心理阴影”，因此，如今才对“可控”的诉求达到了如此“不惜一切代价”的程度？
3. 对找“二供、三供”有执念
在“分开定点”之前，主机厂还有一种已经很古老的供应商“管控”策略：同一个零部件，找2-3个供应商，让各供应商之间彼此制衡。
这一招，用于对传统硬件及传统ADAS供应商的管控，都能行得通；但如果用于对中高阶智驾方案供应商的管控，肯定是行不通的。
里面的差异在这里：
传统硬件的标准化程度已经比较高了，B供应商和A供应商做的东西不会有太大差异；并且，传统硬件和硬件的集成，又是“物理变化”，那么，把其中一个零部件换成另一家供应商的同类产品，并不会对更上一级的“系统”产生多少影响，因此，切换成本比较低。
ABCD等传统Tier 1们提供的传统ADAS，都是同质化程度较高的软硬一体的黑盒；并且，这些黑盒都是硬件主导的，软件占的比重很小，那么，把毫米波雷达这种切换成另一个供应商的，也不会对更上一级的“系统”产生多少影响，所以，切换成本也很低。
相比之下，高阶自动驾驶的硬件和软件都比ADAS要复杂得多，并且，硬件、软件都还没有收敛，不同供应商做的东西，会有较大差异（软件算法的差异会尤为明显）；并且，智能硬件和智能软件、软件和软件之间的集成，都是“化学变化”，那么，把其中任何一个模块换成另一家供应商的同类产品，都会对更上一级的系统产生非常大的影响，因此，切换成本非常高。
这里说的“切换成本”，最直接的是：新供应商提供的模块跟系统中其他模块之间的『软硬件系统调优』工作，包括数据采集、重新训练、测试等。
尤其重要的一点是，传统ADAS对车主的购车决策没产生过什么影响，车企在营销中也没有怎么介绍过ADAS，那车主对这类ADAS的体验也不抱啥希望，甚至很少开启。所以，哪怕切换供应商之后性能会下降、体验也会下降，也很少有消费者会真正注意到。
相比之下，高阶智驾产品在营销中往往滥用“接管率”这样的词，诱导用户将其当“L3”来用，这也导致用户的期望值被拔高。那么，一旦某个模块因切换供应商而使产品性能倒退，那用户对“体验降低”的敏感度会非常高。这个时候，甭说别的，单单舆情风暴，就够车企喝一壶的了。
前段时间，在一场演讲中，赵福全老师还从另一角度指出了主机厂对找“二供”“三供”这一执念背后的问题：
这对硬件主导的产品并无不妥，但对软件主导的产品，却很可能导致自己落后于人。这是因为“新汽车”基于数据、借助软件、不断迭代更新的能力是有延续性的，一旦切换了供应商，前面的积累就失去了意义，相当于重头再来了。
在最近的《那些相信了“软硬件解耦”的算法公司，都被坑得很惨》一文中，笔者提到了大多数算法公司是如何被多平台开发拖累到“生存能力没有保障”的。主机厂如果不放弃对找“二供”“三供”的执念，结果可能是，那些坚持多平台开发的算法公司遭遇过的困难，主机厂都要再遭遇一遍。
再强调一遍：不能只考虑BOM成本，还得考虑各种撕X成本、机会成本。
如果“控制别人”的结果是“不小心”削弱了自己，那你还是别控制了吧？
【这一章的内容，其实印证了笔者在《“被干掉”的CEO和CTO：理工男歧视文科、轻视商科，终遭报应》一文中提到一个观点：文素养和商业思维弱的技术型管理者，不擅长处理跟合作伙伴的关系。】
前几年，很多算法公司都幻想着在产业转型期能出现一个“软件Tier 1”，然后，自己就可以绕开传统的Tier 1，以“软件Tier 1”的身份直接服务主机厂了，但这几年下来，并没有出现几个真正的“软件Tier1”。
因为，在选择Tier 1的时候，主机厂还是更愿意信任硬件公司。通常，软件公司要跟主机厂合作，要么是委身于硬件背景的Tier 1，要么是自己把硬件也给做起来。
当然，对主机厂更信任硬件供应商、认为硬件供应商可以帮他们“兜底”这种现象，某自动驾驶公司CEO觉得“很扯淡”。“自动驾驶系统大部分是由软件定义的，而不是硬件。 一个做硬件的，可能对整体系统怎么运行的都不了解，那他怎么兜底啊？”
谈到这些荒诞的现象，某外资中间件厂商的中国区负责人说：“在主机厂的决策链上级别越高的领导，越不理解软件的价值。”真是一语中的。
笔者之前还跟朋友说：“我们教会父母接受新鲜事物和先进理念的难度，要远远大于教会自己的孩子。 ”同理，教会主机厂“级别很高的领导”理解并认可软件的价值，其难度要远远大于教会一些刚入职的应届毕业生。
主机厂级别高的领导不理解、也不认可软件的价值，其结果必然是“不肯为软件付费”。
通常，主机厂相关业务部门的人是认可软件的价值的，因而也愿意为软件付费，但如果把价格报上去，领导会问：
为什么要这么多钱? 这东西是只有我们一家用，还是也有别的主机厂用了，如果别人也在用，为什么这个钱要由我们来掏呢？
几乎所有原本打算“靠算法立身”的自动驾驶公司，都在自研域控制器，有的甚至还研发了毫米波雷达、摄像头、超声波雷达等硬件；当然，走得最远的，还有要自研芯片的。 这里面固然有一些软硬一体层面的考量，但根本、也最共性的原因也许是：
如果只卖软件，很难让主机厂掏钱。
是的，所有的自动驾驶公司都有个心酸处：软件是灵魂，但如果没有以硬件作为载体，软件将“一文不值”。
对定制化软件算法的开发费，大多数主机厂还是愿意支付的，但对License的费用，主机厂愿意出的价，少得可怜。 在实践中，很多算法公司在跟车企的合作中，软件算法都是只收取一次性的开发费，没有License。
车企不仅不愿意为License付费，也不愿意为OTA付费。
『软件定义汽车』的一个精髓是：车辆在卖出去之后，能靠软件OTA 持续为消费者提供新的价值，而车企也能在车辆的整个生命周期中，通过软件OTA向消费者收钱；但在实际操作中，有一个众所周知、却极具讽刺意味的事实是：
绝大部分车企，都不愿意为OTA向算法供应商支付费用。
2023年上半年，某自动驾驶公司CTO告诉九章智驾：“跟我们合作过的主机厂，只有理想一家肯为OTA付费。”
当然，主机厂不肯为OTA支付费用，吃亏的可不止是供应商。
某传统主机厂的员工告诉九章智驾，他们之前做成本控制方案时，只考虑到“上车的成本”，却没有考虑到“后续的OTA也需要钱”，结果就是，到了跟消费者承诺的OTA需要兑现的时候，该主机厂不愿意为OTA向供应商支付费用，那供应商当然就会选择“不作为”了。
没有OTA，承诺的新功能就无法交付给消费者，此时，老车主的吐槽对品牌的伤害非常大。
这让笔者想起一位做仿真软件的朋友的观点：
在欧美，主机厂客户更喜欢订阅制；但在国内，主机厂客户更喜欢买断。
订阅，尽管要持续付费，但你可以一直用到最新的版本；而买断，就是一次性花了很多钱，但会错过后面的版本升级，吃亏的还是你自己。
把上述一系列现象整合在一起看，我们会发现，很多车企大佬们的思维是分裂的——
在需要“附庸风雅”、提升逼格的时候，他们喜欢人云亦云地喊着『软件定义汽车』，尽管自己对『软件定义汽车』这个概念的认知度可能连“一知半解”都谈不上；但在需要谈钱的时候，他们果断地认为，软件要么只配被“白嫖”，要么只能寄于硬件的“篱下”。
这些大佬其实是不希望通过“卖软件”挣钱的，因为在他们的认知中，认为软件不值钱、不值得给别人付费。他自己都认为软件不值钱，他又希望让消费者为他们的软件付费。
也许他会辩解说“你当我傻啊，我肯定希望通过软件挣钱”，但在跟软件供应商合作时，你都不打算向软件供应商付钱，认为软件只配被白嫖啊，那你如何让你的客户(消费者)认为软件值得付钱？
可能主机厂的老板们想的是：等我先靠卖软件从消费者身上挣到钱之后，我再为供应商们的软件付费。但这种逻辑特别扯淡——你们作为产业的C位，都不敢主动确立为软件付费的游戏规则和价值观，消费者怎么敢啊，他们难道不怕被割韭菜吗？
另一方面，消费者愿意为软件付费，需要软件做得足够好才行；然而，主机厂不愿意为软件付费，那供应商哪来的钱、又凭什么要把软件做得“足够好”呢？
这一系列荒诞逻辑背后的根源是：主机厂的大佬们大多缺乏“软件思维”。更进一步说，很多掌权者的思维方式，还“配不上”『软件定义汽车』这个时代。
所以，车企要真的想通过卖软件挣钱，首先就得真正确立起“软件值得付费”的价值观。如何验证他们是否真的信仰这一价值观呢？关键得看他们是否尊重软件或算法供应商的利益，是否希望软件供应商挣钱。
三个月前，跟朋友聊起『软件定义汽车』什么时候真正实现的问题，我们的共识是：等“纯硬件思维”的领导们都退出智能化相关事项的决策岗位、有“软件思维”的年轻人被提拔到关键领导岗位之后。
几大新势力之所以在智能化上走在最前，最关键的原因是，他们没有太多的历史包袱，尤其是，没有一些“纯硬件思维”的元老。
相比之下，在传统车企及传统Tier 1，很多跟智能化相关的关键岗位，都被一些“纯硬件思维”且故步自封的老人占据着，这也是本文中提到的一系列拖累『软件定义汽车』这个目标的顽疾无法得到根治的最根本原因。
干了很长时间机械的人，能不能养成“软件思维”？肯定是可以的，我们在本文开头也提到了一些“硬件转软件”成功的情况。不过，总体来说，工程师改变起来相对比较容易，但领导要转变起来会难得多。
领导更难转变的可能性又可分两种：
身居高位久了，容易故步自封，认为自己什么都是对的，听不进去年轻人的观点，别人提醒他们转变，他们会摆出一副“老子走过的桥比你走过的路都多，轮得到你来教训老子”的架势；
心态还算开放，但长期只关注学习本专业的知识，已经被训练成“小模型”，思维固化了。
但无论哪种原因，待在一个自己不能胜任的岗位上，也确实是“德不配位”；哪怕这位领导在历史上对公司是有过贡献、甚至是有过重大贡献的。
这么说，好像对“中老年人”很残忍。笔者自己也觉得有点于心不忍，因为，“我们的父母也是老年人，并且，终究有一天，我自己也会老”。
当然，尽管“终有一天，我自己也会老”，笔者仍然写了这么一长篇“批评老人”的文章，是因为笔者有一个根深蒂固的理念：
不拖累他人，是一个成年人的最基本道德；所以，“年龄大了，思维转变不过来”，显然也无法赋予一个人一直“赖”在领导岗位上拖累公司、拖累员工、拖累供应商的行为以“合法性”。
“有一天，等我自己老了，我肯定不会成为一个拖累他人的存在，因而也肯定不会被年轻人嫌弃。”但只有真正的终身学习者才有底气说这种话。
1.
本文提到的种种问题，各类工程机械制造商在做无人驾驶时同样会遇到。所以，软件人才在决定加入这些公司之前务必要做好对新东家的“背调”。
2.
两年前，笔者曾听过一位主管资本市场的官方人士的讲座，在她的PPT上，“硬科技”是不包括软件算法的，特指“硬件”。 当时，笔者被“吓了一跳”，遂找一些业内朋友请教，然后得知：官方定义的“硬科技”，确实是特指“硬件”。
对这种科技公司的人看起来很荒诞的认定方法，有一个勉强说得过去的解释是：软件在财务数据上造假要比硬件容易得多，官方估计是为了避免这种问题，所以才把软件从资本市场支持的“硬科技”中排除出去了。
但即便如此，很多科技产业的从业者仍认为这种做法是因噎废食。 有朋友开玩笑说：按照他们这个认定标准，那ChatGPT肯定也不算“硬科技”了，因为它不是硬件。
在过去两年，笔者没有再关注过官方对“硬科技”的认定标准是否有过迭代，但听一些朋友说，是迭代过了。但愿如此吧。
3.
在本文的语境中，“软件思维”和“纯硬件思维”似乎有明显的高下之分。
笔者自己清楚，把这种想法赤裸裸地说出来显得“政治不正确”，但不服气的人可以想一个问题：在日常的生活和工作中，我们在说一个人思维僵化、“流程怎样他就怎样”的时候会说他“太机械了”，但很少会在批评一个人的某一个思维短板的时候说他“太软件了”吧？
“太机械了”的人在体制内比在体制外更常见。但这本质上跟体制内外没关系——体制外的市场化程度不高的岗位上的人也如此。总体上，岗位的市场化程度越低，人的思维方式“越机械”。
为何一直呆在这些岗位上会让人的思维变得“太机械”呢？因为，市场化程度低的岗位，尤其是行政类岗位，主要的工作内容就是简单的事情不断重复；场景简单、corner case特别特别少，那么， 算法就无法迭代。
“无法迭代”，这可不就跟机械产品很像吗？
既然场景复杂度决定数据质量、数据质量定义人的思维方式，那么，一个人要想避免被别人指责为“太机械了”，比读书更更效的路径其实就是：大胆地把自己置于一个更复杂的场景中，如饥似渴地消化各种corner case的数据，快速迭代自己的算法。
当然，如果没有数据闭环能力，数据再多也没用。这就如同李白和苏轼这样的人行了万里路可以写下许多永世流传的作品，而普通人行万里路，不过就相当于做了几个月邮差而已。
所以，要想避免成为“太机械”的人，除了在复杂场景中收集数据外，我们还得构建属于自己的“数据闭环能力”。