【附PPT】 陈诚：AI时代汽车软件研发与功能安全新范式

　　2026年7月21日-23日，2026中国汽车论坛在上海嘉定举办。本届论坛由中国汽车工业协会主办，以“新开局，新机遇，新征程——共绘汽车产业高质量发展新蓝图”为主题，由“1场闭门峰会、1个大会论坛、1场技术领袖峰会、13个主题专题论坛、N场行业发布”等16场会议和若干配套活动构成。各场会议围绕汽车行业热点、重点话题探索方向、引领未来。其中，在7月23日上午举办的“【主题论坛十】AI驱动智能网联新能源汽车产业数智新发展”上，奥特酷智能科技（南京）有限公司（AutoCore.ai）CTO陈诚发表演讲。以下内容为现场发言实录：

　　大家好，今天我想跟大家交流一个比较具体的问题。

　　过去至少18个月里，AI在大家工作中的应用已经非常广泛。大家用AI写代码、做文档、做设计。接下来的问题是：如何把AI真正用到汽车行业的安全工程中？

　　我们最基本的安全底线是什么？如何让系统达到ASIL D？如何满足ISO/SAE 21434的信息安全要求？今天我想结合我们在这方面的工作做一些分享。我们团队长期从事汽车基础软件和电子电气架构设计，在过去8年的实践中积累了不少经验。

　　AI进入汽车领域以后，一方面是AI进车，另一方面是AI进入大家的研发工作，这带来了很多变化。首先，安全对象在发生变化。以前的汽车更多是一个由软硬件共同定义的确定性系统。

　　但今天，通过OTA和模型持续迭代，车辆功能会动态变化，这已经成为常态。以前我们可以预先设计好固定的流程；现在，用户通过语音交互，再叠加用户习惯和记忆系统，最终可能通过SOA调用车身功能，功能组合和调用时序就不再完全可预测。

　　从功能安全角度看，安全对象在变化，研发过程也在变化。过去，SOP往往被视为项目的截止点；今天，SOP其实只是车型生命周期的开始。此后，我们可能每个季度或每半年都要进行一次OTA。

　　这么多新需求和变更进入以后，会对功能安全产生什么影响？这是一个很大的挑战。为了让汽车持续保持产品竞争力，软件更新不可避免；但在更新过程中，安全底线是否被放松，是今天必须关注的重要问题。

　　另一个挑战是证据关系的变化。因为车辆会不断进行OTA，安全证据及其相互关系也会持续发生变化。

　　一辆车销售出去、已经OTA了五个版本之后，是否仍然保有与SOP时点一致且完整的功能安全证据关系？这是一个非常重要的问题。

　　从确定性角度看，今天的AI本身存在不确定性，例如幻觉，以及temperature等采样参数所带来的发散性。怎样建立确定性？简单来说，就是要给AI设立清晰的安全围栏。

　　在车内运行侧，我们需要运行时的确定性，这是AutoCore.OS等核心产品所解决的问题；但研发侧的确定性如何建立，也是今天想跟大家重点交流的内容。

　　在我们公司，这套面向研发、尤其是功能安全的体系叫作AutoForge，它是一款面向汽车工程的智能体产品。

　　AutoForge当然可以和你对话。比如今天做PPT，大家也越来越依赖AI。但更重要的是它承担的工作：它作为V模型的智能执行层，把过去在功能安全和信息安全中大量依靠人工完成的工程任务，交由专业智能体辅助执行。

　　这和传统的通用Agent框架有很大区别。通用框架往往只提供程序框架，而我们面向的是功能安全的实际工程工作。AutoForge可以与企业已有的项目管理系统、ALM系统结合，也可以连接代码仓库和测试系统。

　　下面用一个比较典型的案例来说明。在实践中，如果是正向研发，或者按计划开展功能安全活动，按部就班执行即可；但进入后续阶段后，会出现大量变更。在变更过程中，每一个小变更是不是也应该完整走一遍安全流程？

　　理论上当然应该。但坦白说，过去不同公司、不同团队的执行情况并不一致。在今天的智能体时代，当变更发生时，智能体可以先对整个项目及其工程资产进行分析。

　　因为既有证据链已经存在，平台可以分析证据链中哪些内容与本次变更相关，并定位需要重新处理的上下游关系。

　　在此基础上，不同类型的专业Agent会执行相应任务，例如更新HARA分析、FMEA以及其他安全工程产物。

　　系统架构、测试用例也会相应更新；集成测试、黑盒测试等任务，同样可以由智能体辅助完成。但最终仍然需要人类专家承担安全门禁。坦白说，今天的AI还不能替安全责任人签字。

　　最终签字仍然是人类专家的责任，这是正常的安全流程。引入智能体以后，过去一次小变更如果完整走完流程，可能要以数周为单位；今天则有机会缩短到数小时。

　　讲到证据链，它不仅覆盖V模型左侧，也覆盖V模型右侧以及具体版本。也就是说，有了新的变更或需求，完成相应分析和实现之后，还必须继续验证后续环节。

　　实现以后，测试覆盖率是否达标？相关测试是否已经执行完成？我们认为，这些状态都应该在智能体平台上持续呈现和管理。

　　今天另一个非常重要的问题，是现实项目中存在大量版本。即使是同一车型，也会因为配置、年款不同而产生多个版本；具体到DBC、服务矩阵等工程资产也会不同，相应文件的MD5、checksum也会变化。

　　如何证明一个具体版本是可信的？必须有机制保证整条链路可追溯。对此，我们的客户和我们自己都是直接受益者。面对数百万行代码的软件工程，我们可以做到两点：第一，使其达到ASIL D级别的要求；

　　第二，在产品发布以后，所有变更仍能同步保持证据链完整。我认为这是非常重要的一点。接下来再谈智能体如何在汽车安全工程和研发体系中落地。我们认为主要有三个着力点。

　　第一个方面，需要一个可信的智能体运行平台。这一点非常重要。很多企业有严格的信息安全要求，需要私有化部署；同时，平台还必须能够连接企业已有的工具链和内部系统。

　　此外，记忆系统、长上下文和长时间任务运行也非常必要。在这些基础能力之上，还要有专业智能体。不论是功能安全、信息安全，还是代码、系统需求和软件设计，都需要相应的领域Agent。

　　从过去的经验看，每个项目、每家客户都会有相应的集成工作。具体到代码工程，不同代码仓库都有自己的harness和执行环境，需要针对性建立。我们认为，采用FDE模式，让工程师深入客户现场完成工具链接入、项目配置和持续迭代，是推动AI智能体在研发体系中快速落地的重要手段。

　　最后回过头来讲，AI，尤其是AI Agent，确实能够显著提升研发效率。以我们的实践为例，在一个存量项目的安全工程中，投入大约可以降到传统方式的1/50。

　　但我们还是要强调：AI不会替代安全责任人。真正的问题是，如何在AI赋能的情况下，继续满足功能安全和信息安全要求。以上是我们的一些看法。页面上的二维码是我们的AutoForge产品的链接，感兴趣的朋友可以扫描了解。

　　我们也欢迎进一步交流。这个行业确实在快速变化，甚至有人说软件会被AI“吃掉”。我们也认为，这个时间点可能会比想象中更早到来。但安全工程这件事不会消失，因为它最终关系到人身安全。

　　谢谢大家。

　　（注：本文根据现场速记及演示材料修订，仍需演讲嘉宾最终审阅。）