ARTICLE · 1306768
AI时代,如何做好汽车软件的质量管理 ——从质量文化、过程控制到驱动的可信交付
AI时代,如何做好汽车软件的质量管理 ——从质量文化、过程控制到驱动的可信交付
过去，汽车质量更多体现在零部件的尺寸、材料和制造工艺上。今天，随着新能源汽车和智能汽车的发展，汽车越来越成为由软件、电子电气系统、数据和算法共同定义的复杂产品。一段代码的缺陷，可能影响BMS对电池状态的判断；一次软件升级的失误，可能造成大量车辆功能异常；一个未经充分验证的控制策略，甚至可能带来安全风险。 与此同时，AI Coding和Agent技术正在改变软件生产方式。代码生成速度越来越快，但软件生产效率的提高，并不意味着软件质量自然提高。相反，当AI大量参与需求分析、设计、编码和测试时，如何确保工作产品正确、过程受控、质量可信，正在成为汽车企业面临的新挑战。 在我看来，AI时代做好汽车软件质量管理，不能依赖某一种工具、某一个部门或某一个测试环节，而必须建立一套完整的质量管理体系，将质量要求真正融入软件研发和产品全生命周期。 我将这套体系概括为：TQM全面质量管理、零缺陷预防理念、一把手工程、SQA专业质量组织、朱兰质量三部曲、研发过程质量门禁和全生命周期质量改进。 
(汽车软件质量管理全局框架，简单有效) 新能源汽车的一个重要特点，是越来越多的核心功能由软件实现： 这些系统之间存在大量的软件接口、数据交互和控制逻辑。 单个软件模块功能正确，并不意味着整车运行一定正确。例如，BMS提供的电池温度信息、VCU的动力请求和热管理系统的执行策略，可能分别符合各自的需求，但如果接口定义、数据更新周期或异常处理机制不一致，整车仍然可能出现问题。 因此，汽车软件质量不能只关注代码和单个软件模块，而必须从系统和整车层面进行管理。我认为至少要关注五个方面： 汽车软件质量还涉及多个专业标准和规范，例如ISO 26262功能安全、ISO 21434网络安全、ISO 21448（SOTIF）、Automotive SPICE以及ISO 24089软件更新工程等。这些标准各有侧重，企业需要将其要求融入统一的研发质量管理体系，而不是各自形成孤立的流程和文档。 我的基本判断是：新能源汽车软件质量管理，必须从单纯的软件质量管理走向系统级、全生命周期的质量管理。 
质量管理首先是管理问题，其次才是技术问题。 第一，建立全面质量管理（TQM）文化。 TQM强调全员参与、全过程控制和持续改进。零缺陷（Zero Defect）理念强调预防优先、第一次就把事情做对，而不是等问题发生后再依靠测试和检查来发现缺陷。 零缺陷并不意味着软件开发过程中绝不允许出现缺陷，而是要求企业尽可能在需求、设计和开发早期预防问题，避免缺陷流入后续环节。 这首先是一把手工程。企业负责人必须对质量目标、资源投入和重大质量风险承担管理责任。当项目进度与质量要求发生冲突时，必须有明确的决策机制，不能让质量在进度压力下自动让步。 其次，必须明确全员质量责任。产品经理对需求质量负责，系统工程师对系统需求分解和接口负责，架构师对设计质量负责，开发人员对代码和单元测试负责，测试人员对验证充分性负责，项目经理负责组织协调，SQA负责独立的过程监督和质量评价。AI参与工作产品生成，也不能改变最终责任人的责任。 企业还应改变单纯考核进度、代码产出量和按时交付率的做法，将缺陷逃逸率、严重缺陷、重复问题、回归缺陷和质量问题关闭周期等纳入质量度量。 第二，建立专业的SQA质量组织。 这是很多企业容易忽视的问题。 有些企业认为质量是大家共同的责任，因此不需要专门的质量保证组织。但在实际项目中，一旦出现进度压力，质量活动往往最先被压缩；一旦发生质量问题，又容易变成部门之间的责任争议。 集体负责，不等于真正有人对质量体系负责。 我认为，汽车软件企业需要建立专业的SQA（Software Quality Assurance）职能。SQA应具备相对独立的质量评价能力，拥有过程审计、质量问题升级和质量门禁评价等必要权限，并具备软件工程、功能安全、网络安全、测试技术和质量管理等专业能力。 需要强调的是，SQA不是替开发人员检查代码，也不是替测试人员执行测试。开发负责构建质量，测试负责验证产品，SQA负责确保质量规则得到有效执行，评价过程和结果是否符合要求。 没有真正发挥作用的SQA组织，质量管理很容易退化为流程检查和文档管理。 
管理学家朱兰提出的质量三部曲，即质量策划、质量控制和质量改进，至今仍是指导软件质量管理非常实用的框架。 1. 质量策划：首先明确什么是合格的软件。 很多企业容易把项目计划当成质量计划。项目计划回答什么时候完成任务，质量计划则回答要达到什么质量目标、采取什么控制措施、通过什么证据证明质量合格。 汽车软件质量计划至少应明确： 例如，BMS中的电压采集、SOC估算和保护控制，风险特点不同，质量控制策略也应有所区别。对于安全相关功能，应按照适用的功能安全要求实施相应的分析、验证和证据管理。 2. 质量控制：把质量构建在研发过程中。 质量不是检查出来的，而是构建出来的。 需求阶段要控制需求的完整性、准确性和可验证性，提前识别安全、可靠性和异常工况要求；设计阶段要关注架构合理性、接口一致性、异常处理和性能约束；编码阶段要实施代码评审、静态分析和单元测试；集成阶段要验证接口、数据交互和软硬件配置；测试阶段要覆盖正常、边界和异常场景；发布阶段要控制版本、配置、遗留缺陷和升级风险。 AI可以辅助完成需求评审、代码检查、测试用例生成和缺陷分析，但AI的检查结果不能直接等同于质量结论。特别是涉及功能安全和重大质量风险的活动，必须经过有能力的工程人员审核和确认。 3. 质量改进：从解决一个缺陷到消除一类问题。 很多企业的质量管理停留在缺陷关闭层面：发现Bug、修改代码、回归通过，然后关闭问题。但这并不意味着质量得到了真正改进。 例如，某个BMS软件缺陷导致特定工况下SOC估算异常，不能只修复算法代码，还应分析需求边界条件是否遗漏、设计是否考虑温度和老化因素、测试是否覆盖相应场景、现有质量门禁是否存在漏洞。 通过FMEA、FTA、5Why、8D等方法分析根因，再将改进措施转化为需求检查清单、设计规则、测试用例和质量门禁。 真正的质量改进，不是让一个问题消失，而是让一类问题不再重复发生。 AI可以进一步从历史缺陷库中挖掘共性问题，辅助根因分析和改进措施复用，将专家个人经验逐步转化为组织级质量资产。 
质量管理不能只停留在制度和文档层面，必须落实到研发过程。我建议汽车软件企业重点建立六道质量门禁。 第1道：系统需求与软件需求门禁。 检查需求来源、需求分解、完整性、可验证性和双向追溯关系，特别关注功能安全、网络安全、可靠性和异常处理要求是否前置。例如，BMS的SOC估算需求必须明确适用工况、温度范围、误差指标和验收条件。准出条件是需求基线得到批准，重大问题关闭。 第2道：软件架构与详细设计门禁。 检查架构是否满足系统需求，模块职责和接口是否清晰，关键数据流、控制流、异常处理和资源约束是否合理。对于BMS与VCU、热管理系统之间的接口，还要考虑通信超时、无效数据和状态不一致等情况。准出条件是设计评审通过，关键设计风险得到处理。 第3道：代码与单元测试门禁。 检查编码规范、静态分析、代码评审、复杂度和单元测试覆盖情况。AI生成的代码必须遵循与人工代码相同的质量标准，不能因为代码由AI生成就降低审核要求。准出条件是严重静态分析问题关闭，代码评审完成，单元测试达到项目规定的质量要求。 第4道：集成与转测门禁。 开发完成不等于可以直接提交测试。转测前必须完成开发自测、接口验证、配置确认、变更影响分析和测试计划。对于控制软件，还要关注MIL、SIL、HIL等不同层次的验证。准出条件是集成基线明确，开发自测通过，软件具备正式测试条件。 第5道：测试完成与质量评审门禁。 不能只看测试通过率，还要检查需求覆盖、边界和异常场景覆盖、性能与可靠性验证、缺陷关闭情况以及回归测试充分性。对于BMS、VCU等系统，还应关注整车联合运行场景。准出条件是关键需求和风险场景得到验证，重大缺陷关闭或经过正式风险接受，测试证据完整。 第6道：软件发布与OTA门禁。 检查软件版本、配置基线、软硬件兼容性、遗留缺陷风险、发布证据，以及升级失败恢复和回滚策略。尤其要验证通信中断、电源中断、版本不匹配和升级失败等场景。准出条件是发布基线明确，质量证据完整，升级及恢复策略得到验证。 六道门禁不能变成六次额外会议，也不能成为重复填写表格的负担。每道门禁都必须有明确标准、责任人和客观证据，能自动检查的尽量自动检查。 质量门禁的本质不是增加流程，而是把质量要求变成研发过程中的硬约束。 
AI对汽车软件质量管理的影响，需要区分两个方面：一是AI用于软件研发和质量管理，二是AI作为汽车产品的一部分。 首先看AI辅助研发。AI Coding可以快速生成代码，Agent可以执行需求分析、修改代码和运行测试，但也带来了新的质量风险：生成代码可能存在逻辑错误，AI生成的测试可能不充分，Agent可能使用错误的上下文或修改不相关文件，第三方模型、工具、Skills和MCP服务还可能引入新的供应链风险。 因此，企业必须建立相应的质量护栏：对AI生成的工作产品实施审核；对Agent设置权限和工具调用边界；对代码变更实施静态分析、测试和独立审查；对模型、工具和依赖组件进行版本管理；保留必要的执行记录和验证证据。 AI Coding越普及，越需要工程化的质量保证体系。否则，AI提高的可能只是缺陷的生产速度。 其次，当AI进入汽车产品，例如智能驾驶感知与决策、智能座舱大模型、基于机器学习的故障诊断时，质量管理对象就扩展到了数据、模型和运行场景。 企业不仅要关注传统软件的功能正确性，还要关注训练和验证数据的代表性、模型在边界场景下的表现、异常输出、数据分布变化和模型性能漂移。对于智能驾驶等系统，还需要结合SOTIF等适用要求开展场景分析和验证。 AI也会改变SQA的工作方式。过去SQA需要花费大量时间检查文档、核对追溯关系和统计质量指标。未来，这些重复性工作可以由AI和自动化工具承担，SQA则应更多关注质量规则设计、风险识别、门禁机制、重大质量偏差和AI生成证据的可信性。 AI不会取代SQA，但会推动SQA从人工检查者转变为质量体系的设计者、监督者和改进推动者。 
这是我认为AI时代汽车软件质量管理需要进一步发展的一个重要方向。 传统汽车软件研发非常重视可追溯性，要求建立从系统需求、软件需求、架构设计、详细设计、源代码到测试用例和测试结果的双向追溯关系。 但是，可追溯性不等于一致性。 可追溯性回答的是两个工作产品之间是否建立了关联；一致性回答的是两个工作产品的内容是否真正匹配。 例如，BMS的SOC估算需求规定了特定温度和工况下的误差指标。如果需求、设计、代码和测试之间都建立了追溯关系，但测试用例没有覆盖相应温度条件，或者采用的误差指标与需求不一致，那么这条追溯链并不能证明软件符合需求。 有链接，不代表有覆盖；有覆盖，不代表实现正确；测试通过，也不代表需求真正得到验证。 ASPICE 4.0强调工作产品之间的一致性和双向追溯性，这意味着现代软件过程管理不能停留在建立文档关联上，还必须关注工作产品之间的内容一致性。 我认为，可以借助AI和Agent技术构建四层可信质量证据链： 第一，规格工程（Spec Engineering）。将模糊的自然语言需求转化为可验证的工程规格，明确适用工况、边界条件、指标、验收标准和约束。规格越清晰，后续验证越有依据。 第二，Agent编排与执行记录。由需求分析Agent、设计Agent、Coding Agent、Test Agent和Quality Agent承担不同任务，明确职责、工具权限和审核边界，同时记录输入、工作产品版本、工具调用、修改记录和人工审批。 第三，自动一致性验证。利用AI分析需求、设计、代码和测试之间的语义关系，检查需求是否落实到设计、设计约束是否体现在代码、测试是否真正验证验收标准，以及变更是否引入新的不一致。AI的判断仍需通过规则检查、人工抽查和独立验证进行校准。 第四，可信证据包（Evidence Package）。将需求基线、设计文件、源代码、测试用例、测试结果、软件版本、环境配置、追溯关系和审批记录形成可审计、可验证、可复现的质量证据包。 这里还必须区分Verification和Validation。Verification回答产品是否符合规定的规格和要求；Validation回答产品是否真正满足用户需要和实际使用场景。如果最初的需求就是错误的，那么即使各工作产品之间的一致性做得再好，也只是更准确地实现了错误的需求。 因此，汽车软件质量管理既要保证正确地实现需求，也要通过整车验证、用户场景和实际运行反馈，确认我们做的是正确的事情。 AI不会改变质量管理的基本规律，但会改变质量管理的手段、对象和能力边界。 无论软件由工程师编写还是由AI生成，无论产品是传统控制软件还是包含大模型和机器学习算法的智能系统，质量管理都必须坚持一个基本原则：质量必须在研发过程中构建，通过过程控制来保证，用客观证据来证明，并通过持续改进不断提升。 对于新能源汽车企业，质量管理还不能止步于软件发布，而必须延伸到整车运行、OTA升级和产品全生命周期。 质量文化是根，质量组织是保障，质量策划、控制与改进是主线，研发过程门禁是抓手，可信证据链是基础，AI是新的赋能手段。 真正决定汽车软件质量的，不是企业使用了多么先进的AI工具，而是企业有没有建立一套能够持续预防风险、发现问题、证明质量并不断改进的工程化质量管理体系。 为什么没有 ASPICE，日本车依然可靠？ 刚发布的《GB/T 48140-2026 汽车软件质量与缺陷管理规范》存在一系列问题 AI时代，质量要左移，而且更要有方法
（文章原来写了约12000字，但考虑读者缺乏耐心阅读，缩减了50%）
一、重新认识汽车软件质量：质量管理的对象已经发生变化
BMS负责电池状态估算和保护， VCU负责整车动力协调， MCU负责电机控制， OBC负责充电管理，热管理系统负责电池、电机和座舱的温度控制。 ......
需求质量：需求是否完整、准确、一致、可验证？安全、可靠性和异常工况要求是否充分考虑？ 设计与实现质量：架构是否合理？接口是否一致？代码是否可靠？异常处理是否充分？ 验证与确认质量：测试是否覆盖需求、边界条件和异常场景？测试环境和结果是否可信？ 系统与整车质量：软硬件协同、控制策略及整车运行是否满足预期？ 运行与演进质量：软件发布、OTA升级、配置兼容和现场问题处理是否受控？
质量目标：包括需求质量、设计质量、代码质量、测试覆盖、缺陷逃逸和发布质量等； 质量策略：根据功能重要性、失效后果和风险等级确定不同的质量控制强度； 质量活动：明确各阶段的评审、分析、验证和测试活动； 责任分工：明确执行者、审核者和批准者； 质量门禁：定义每个阶段的准入准出条件； 风险管理：识别关键质量风险，制定预防、控制和应急措施。
