ARTICLE · 990294
汽车软件研发提效难?通用汽车拆解AI在汽车软件工程中的价值与边界
整理编辑｜TesterHome社区
在软件定义汽车的产业进程中，车载软件的复杂度增速早已超过研发效率的提升节奏。一边是功能迭代的压力持续攀升，一边是汽车行业对安全性、合规性、可维护性的严苛要求分毫不让，如何在不破坏工程严谨性的前提下提效，成了所有车企软件团队的核心命题。
当AI代码生成工具在通用领域快速普及，汽车工程领域却始终无法简单照搬——生成式输出的不可控性，与MISRA编码规范、全链路可追溯、强评审机制等汽车软件工程准则天然存在冲突。通用汽车VMEC嵌入式软件团队的最新研究，给出了一条经过实践验证的落地路径：将AI深度嵌入V型开发流程的各个环节，以“窄范围、强边界、可校验”为核心原则，用AI生成可供工程师快速验证的初稿，而非直接交付最终代码。
从智能虚拟顾问的实时合规指引，到嵌入式代码重构的结构化提示链，再到测试用例到脚本的自动化生成，AI始终作为工程能力的放大器存在，最终的判断、审批与责任仍牢牢掌握在工程师手中。以下是这份研究的完整内容，系统拆解了AI在汽车软件全生命周期中的价值、方法与边界。
以下是通用汽车团队的总结：
人工智能正快速重塑软件开发格局，但汽车项目对产出的要求远不止速度快。在软件定义汽车中，只有当最终生成的软件在严格管控的工程流程中仍具备可读性、可测试性、可维护性与可评审性时，开发速度才有意义。
通用汽车的团队在覆盖整个软件开发生命周期的广泛研究中秉持这一准则。研究的核心问题并非AI能否生成代码，而是AI能在哪些环节减少开发阻力，同时不削弱量产软件所需的严谨性。在各类差异显著的工程工作中，同一种规律反复显现：只有当AI在结构化的工程闭环中运行，生成可供工程师验证的、边界清晰的初稿时，才能发挥最大价值。
图1：V模型展示了AI辅助可在需求分析、设计、实现、验证与运维各环节减少开发阻力。
V模型是审视这项工作的有效视角，因为AI的应用机会覆盖了从早期开发决策到验证，再到长期维护的完整软件生命周期。在整个生命周期中，通用汽车的研究始终围绕同一个核心问题：如何在让工程判断牢牢掌控全局的前提下，借助AI消除开发阻力？
挑战与机遇
汽车软件是AI应用的潜力赛道，因为该领域工作复杂度高、包含大量重复性工程任务，且规模持续扩张。开发团队需要管理庞大的代码库、专用工具链，满足严苛的质量要求，同时软件还要随汽车功能的迭代不断演进。
研究表明，汽车软件复杂度的增长速度已经超过了开发效率的提升速度。这种失衡给行业带来了切实压力：既要加快开发速度，又不能牺牲严谨性。
但难点在于，汽车软件领域容不得随意使用AI。生成的测试工件可能偏离需求的真实意图；经过整理的嵌入式C函数仍可能存在逻辑错误、违反汽车工业软件可靠性协会（MISRA）编码标准，或是放回对应模块时无法编译。核心问题不只是模型能否生成输出，更在于生成的输出能否经受住工程层面的严格审查。
解决方案概述
通用汽车的研究沿着“阻力点”展开——也就是工程师在开发生命周期中频繁耗费时间的环节。
这类阻力常见于两个场景：
一是在主动开发阶段，通用工具缺乏领域知识，无法在问题出现时及时发现违规情况，导致问题不断累积，直到正式评审阶段才被暴露；
二是在维护阶段，遗留代码承载着多年积累的隐性假设，不仅现代化改造进度缓慢，手动重构大型嵌入式函数的成本也极高。针对这些场景，研究团队采用基于大语言模型（LLM）的方法，生成边界清晰的初稿供工程师评估和优化，而非从零开始编写代码。
图2：AI辅助测试自动化将需求与行为意图贯穿于测试用例生成、脚本编写、执行与反馈全流程，每个生成阶段都由工程师进行评审。
工作流本身也更清晰地体现出“边界清晰、可评审进度”的必要性。需求与行为意图会依次传递到测试用例、测试脚本，再到执行校验环节，每一次交接都由工程师审核，从而保证了可追溯性。
图3：重构提示方法围绕五大要素构建：框架、规范、模板、序列与迭代。
同样，这种对“边界清晰、可评审进度”的坚持也指导了代码优化工作。通过结构化的提示序列，每一轮重构的范围都足够窄，工程师可以完成检查后再推进下一阶段。
解决方案详情
这项研究最明确的结论之一是：最终效果的优劣，更多取决于围绕AI定义的任务边界是否清晰，而非AI模型本身的能力。
如果给模型分配的任务范围狭窄、定义明确，其输出就可以对照已知预期进行校验；
如果任务范围开放模糊，输出质量就难以保证。
由此研究团队总结出一条基本原则：每一次AI交互的边界都必须足够清晰，让负责评审的工程师能够直接判断结果是否正确。
对于实时合规指引场景，这意味着要把资深开发者的经验转化为明确的检查模式，这样每一条建议都可以依据自身优劣被评审，而非仅凭模型的判断就被采纳——这也是智能虚拟顾问（IVA）的核心理念。
这一原则同样适用于其他工作流
在代码重构中，通过提示链将结构清理与可读性优化拆分开来，不仅让每一轮修改都更易评审，也降低了后续修改悄悄推翻前期调整的风险。在脚本自动化中，采用结构化提示将遗留Perl工具迁移为Python的过程，比一次性重写的可评审性更强。在验证环节，在测试用例生成时明确给出格式、覆盖范围和抽象层级的指引，有助于保留从需求到已执行测试的可追溯性，避免不合理的结构传递到下游自动化流程中。不同场景采用的具体技术各不相同，但“让每一步骤的范围都小到足以验证”的核心原则始终不变。
上下文质量与任务范围同等重要
将标准与合规/不合规示例搭配使用，比单纯的文字描述能生成更优的检查模式。少量示例（Few-shot）比纯指令更能可靠地引导输出格式。对于嵌入式软件重构，当完整代码库无法全部放入模型上下文窗口时，预先计算好的函数间依赖关系摘要有助于保证代码一致性。更完善的提示框架始终能生成质量更高的候选结果。
研究也暴露了AI的明显局限性
总体而言，更大的模型通常表现更好，但即使是架构相同的模型，训练数据的差异也会影响最终效果。生成代码中的逻辑问题仍然需要人工审核。微调（Fine-tuning）也有帮助，但必须谨慎筛选符合规范的代码。上下文窗口的限制也是影响因素之一——输出质量会随输入规模扩大而下降，因此代码分段与人工评审必不可少。
对通用汽车的价值
在汽车软件开发中，AI最实际的价值在于帮助工程师更早发现问题、更快启动高难度工作，让可评审的进度在开发生命周期中顺畅推进。AI缩短了问题从引入到被发现的时间，让质量违规问题在编码阶段就被暴露，而非等到正式评审时才爆发。即便对于阻力极高的工作，有了AI生成的初稿，启动难度也会大幅降低。这些收益共同作用，减少了工程师在整个生命周期中不必要的时间损耗。
这一规律也体现在实测结果中。当任务范围控制在可评审的较小规模时，小范围重构可将圈复杂度（衡量函数复杂度的标准指标）降低约30%；验证工作推动了从需求到脚本的工作流实现更优的可扩展性；而IVA这类专家指引系统，能够在不将审批权移出工程师手中的前提下，提升支持服务的质量。这一切都没有免除工程师的责任——AI只是加快了生成候选方案的速度，最终是否达标，仍由工程师判定。
结论
要理解AI在汽车软件开发中的作用，最有价值的视角不是将其视为工程判断的替代品，而是将其看作放大和延伸工程能力的工具。在整个研究中，AI在处理边界清晰、上下文丰富的任务时价值最高，比如嵌入式代码重构、合规问题排查、遗留脚本迁移、生成测试工件等。这些工作既让开发进度清晰可见，又将验证、优化与审批权牢牢掌握在人类手中。
因此，AI的力量不只在于能用更短时间生成更多产出。更重要的是，当在严谨的工程工作流中使用时，AI能帮助团队更早发现问题，降低启动复杂任务的成本，在需求、实现、验证与评审之间维持更清晰的责任链路。
展望未来，这种应用模式指明了一条发展路径：汽车软件组织可以更高效地复用专业能力，在开发早期嵌入质量检查，让高阻力工作更具可重复性，同时不降低标准。若能实现这一点，AI的意义将不再只是代码生成器，而会成为一种工程基础设施。它可以作为实用的辅助层，帮助资深团队提升开发速度，同时将人类判断、技术依据与最终责任牢牢握在手中。在汽车开发领域，正是这样的结合，让AI不仅是一时的热点，更是可持续、值得落地的技术。
文章信源：https://engineering.gm.com/home.detail.html/Pages/news/us/en/engineering/2026/aug/0819-ai-build-better-vehicle-software-faster.html
OpenClaw 2.0发布：全系统级重构，Agent平台安全管控全面升级
Midscene 1.12版本更新，用Deepseek多模态跑E2E ，速度近乎人类操作
AI测试初创公司LambdaTest宣布更名，押注AI代理，创始人为印度裔