[问与答] 作为程序员,你愿意为“0 AI 代码介入”的汽车支付溢价吗?

大家好,我是做嵌入式开发的。先给纯软方向的同学铺垫个背景:基本上现在能通电的设备都会带 MCU ,也都有代码在上面运行。 结合目前的行业现状,我想和大家探讨一个细思极恐的问题: 现状:防不胜防,汽车底层代码正被 AI 全面渗透 我可以很肯定地说,只要是今年新出的车,100% 已经包含了 AI 生成的...
[问与答] 作为程序员,你愿意为“0 AI 代码介入”的汽车支付溢价吗?
[问与答] 作为程序员,你愿意为“0 AI 代码介入”的汽车支付溢价吗?

大家好,我是做嵌入式开发的。先给纯软方向的同学铺垫个背景:基本上现在能通电的设备都会带 MCU ,也都有代码在上面运行。

结合目前的行业现状,我想和大家探讨一个细思极恐的问题:

现状:防不胜防,汽车底层代码正被 AI 全面渗透

我可以很肯定地说,只要是今年新出的车,100% 已经包含了 AI 生成的代码。而且很多时候,这已经是避无可避的:

  • 上游污染(被动使用): 现在的 AI 渗透是全方位的,很多 MCU 原厂提供的 SDK 源码里,本身就已经混入了 AI 生成的代码。哪怕下游车企的程序员完全不用 AI ,只要基于官方库做开发,就已经“被动”使用了 AI 代码。
  • 下游外包(主动使用): 汽车行业有着极度细分的分包特性。很多底层设备的最终逻辑代码,可能就是由刚毕业没几年的应届生,为了赶工期用着各种 AI 工具(甚至是国产 AI )直接跑出来的。

隐患:缺乏 Review 的黑盒

难听点说,由于层层外包和赶进度,很多这种 AI 参与的代码根本没人严格 Review 。它纯粹是一个跑得通就行的“黑盒”。 它的控制范围有多广?

  • 轻则: 车上所有能被按下的按钮、空调开关、车窗升降。
  • 重则: 转向系统控制、ESP 车身稳定系统、甚至是碰撞后的应急解锁。

我的问题:

如果未来有车厂以此为卖点,宣传自己的系统是 “100% 纯人类手写、0 AI 介入、经过严格人工 Code Review”,大家愿意为这种安全性(或者说安全感)额外付费吗? 还是说,大家更愿意相信车厂的黑盒 Testcase 覆盖度足够高,只要价格越便宜越好?想听听各位 V 友的看法。

来源: v2ex查看原文