AI编写代码，谁来保证质量？

“ AI编程助手已经彻底改变了一名开发者一个上午能完成的工作量。过去需要几个小时才能理清思路、写出草稿的代码，现在几秒钟就能生成。对于探索性工作和快速原型开发来说，这种效率提升是实实在在的。
”

作者：Rafael Taubinger，IAR高级产品营销经理

AI编程助手已经彻底改变了一名开发者一个上午能完成的工作量。过去需要几个小时才能理清思路、写出草稿的代码，现在几秒钟就能生成。对于探索性工作和快速原型开发来说，这种效率提升是实实在在的。

但在受监管的嵌入式开发领域，比如汽车软件（ISO 26262）、工业控制系统（IEC 61508）、医疗器械（IEC 62304），速度从来都不是瓶颈，证据才是。这里说的证据不是代码能跑起来，而是能证明代码是在明确的开发规范下产出的、经过了相关标准的检验、并且从需求到测试全程可追溯。

这正是当前主流AI辅助方式最令人不安的地方：它加速的恰恰是原本并非瓶颈的环节（写代码），却给本来就已经很吃力的环节（验证、确认与合规认证），带来了更大的压力。

AI能生成代码，却生成不了合规性

现代AI工具确实很强。它们能建议实现方案、补全函数、生成测试框架。让它用C语言写一个转速（RPM）计算函数，得到的结果往往不仅语法没问题，逻辑上也说得过去。但这样的代码里，唯独没有合规性。

一段简单的AI生成函数，乍一看可能挑不出毛病。可一旦交给执行MISRA C 2012 Rule 10.3的静态代码分析工具，其中的隐式类型转换就会被判定为缺陷，而这个缺陷必须先解决掉，代码才能被追溯到已验证的需求上。

这样的情况，在嵌入式团队必须遵循的每一项标准里都会反复出现：

MISRA C/C++：安全关键型C/C++开发的基础标准。把语言限定在一个定义清晰的子集内，能最大程度降低未定义行为带来的风险。这在汽车、工业和医疗领域是不能让步的底线。随着AI工具生成的C/C++代码越来越多，MISRA合规也就成了所有代码进入代码库前必须跨过的一道关卡。

CERT C/C++：关注的是攻击者惯用的可利用编码模式。如果说MISRA关注的是功能安全（Safety），CERT C/C++关注的就是网络安全（Security），而在互联嵌入式系统中，这两者的边界正变得越来越模糊。

CWE：一份记录常见软件缺陷的目录。对于要审查AI生成代码的团队来说，CWE提供了一套识别漏洞的通用词汇。因为模型是从所有数据中学习的，合规与不合规的代码它都学到了，可能在不经意间就复现了训练数据中的漏洞模式。

模型不会自动遵守这些标准。这是开发者的责任，需要可靠的工具链来支撑。

验证环节，才是真正的瓶颈

在安全关键型项目里，验证与确认早已占去研发投入的40%以上。这不是效率低，而是构建监管机构和认证机构所要求的证据链所必须付出的成本。

如果AI只是加快了写代码的速度，却没有触及证据链本身，会怎样？结果是更多代码涌入验证流程，瓶颈进一步收窄。资深安全工程师要审查的追溯矩阵变得更庞大，而发布关口却还是纹丝不动。

AI工具冲击的，恰恰是开发曲线中本来就不是瓶颈的那一段。

真正的瓶颈，始终是后半程：静态代码分析、动态测试、覆盖率测试、可追溯性，以及最终签核。如果只加速前面写代码的环节，却不去解决后半程的问题，对于要交付认证级固件的团队来说，这算不上什么效率提升，反倒是给本已紧绷的流程又加了一道上游压力。

质量到底该在哪里落地

要填上这个缺口，就得把静态代码分析、动态代码分析和覆盖率测试真正纳入开发闭环，而不是等代码写完了再来一轮事后审计，而是让它成为持续、内嵌的日常环节。理想的工作流，不会把“生成代码”和“检查合规”分成两件事，而是让两者融为一体。

把静态代码分析嵌进构建过程

静态代码分析工具C-STAT是IAR工具链的一部分，能在代码刚写入的那一刻，就识别出违反MISRA C、MISRA C++、CERT C和CWE规则的地方，远远早于代码被送去评审会或认证审计。AI负责提建议，开发者负责把关，C-STAT负责验证。

图：C-STAT分析报告，展示某实际嵌入式项目中MISRA C 2012与CERT C检查项的违规情况

把动态代码分析放进调试环节

动态代码分析工具（C-RUN）会在调试过程中对代码做插桩，检测内存泄漏、越界访问、整数溢出，以及没处理的switch分支，这些问题往往跟运行时的具体状态有关，静态代码分析未必都能检查出来。在AI辅助生成代码、结构看似没问题但行为却可能出乎意料的情况下，运行时插桩检测就不是可有可无的东西了。

图：C-RUN在调试阶段检测堆错误与越界访问

模型负责建议，开发者负责判断

这些都不是在反对使用AI。效率提升是真实存在的。在嵌入式软件领域，熟练开发者本就稀缺、项目又越来越复杂，任何能加快写代码速度的工具，都具有真正的价值。

但在AI辅助的工作流里，开发者的角色正在从“代码的作者”变成“质量的把关人”，开发者不再是从零开始编写每一个函数，而是依据领域知识评估AI的建议，将其放入分析工具中检验，并做出模型无法替代的判断，例如代码逻辑是否符合安全意图、测试用例是否覆盖到正确场景等。

正是这层判断，才能把“生成的代码”变成“能站得住脚的代码”。而受监管行业真正需要的，就是这种经得起推敲的代码。

CI/CD：让证据自动化

内嵌工具能在工作站层面把问题拦下来。但放到团队协作的场景里，光靠工作站级别的检查还不够。真正的执行关口在流水线，不管代码是怎么写出来的，每一次提交都要自动拿企业所承诺遵循的标准进行测试。当一次开发者单次工作产出的代码量，可能比过去一整周还多的时候，人工触发质量检查就不再具有可扩展性。检查必须自动运行，伴随每一次代码推送。

IAR Build Tools提供与IAR Embedded Workbench相同的编译器、链接器和工具链，并将其打包为可在CI环境中无头（headless）运行的形式。无论流水线运行在Jenkins、GitHub Actions还是Azure DevOps上，CI中的构建结果都与开发者本机的构建结果完全一致。ISO 26262、IEC 61508和IEC 62304都要求，用来生成发布交付的工具配置必须留档、可复现，IAR Build Tools让这一点变得可验证。

C-STAT可在CI环境中以无头模式运行，违规项作为构建输出被报告，覆盖率趋势也会随时间被持续追踪，架构层面的偏移会立即显现。合规证据无需等到发布时再临时拼凑，而是在项目全程中不断累积。

支撑起这一切的平台

上面这些工具，只有放进一个真正受治理的开发平台里，价值才会成倍放大。在这样的平台上，构建是可复现的，工具认证有据可查，从源代码到认证交付之间的整条证据链，随时都能被完整还原出来。

IAR平台正是围绕这一需求设计的。它的工具认证（经TÜV SÜD认证）支持覆盖ISO 26262、IEC 61508和IEC 62304。C-STAT和C-RUN直接集成在这个环境中，这意味着，合规检查和构建过程运行在同一上下文中。

这才是“效率”和“合规”之间真正的分水岭。区别不在于AI本身，而在于它背后依托的平台和工具链。

AI负责编写代码，工具链保证质量与合规。IAR能实现两者兼得。