关注+星标公众号，不错过精彩内容
翻译 | 安富莱电子
素材来源 | IAR官方博文
https://www.iar.com/blog/ai-writes-the-code.-who-guarantees-the-quality
AI 编程助手已经改变了一名开发者在一个上午能产出的代码量。曾经需要数小时草拟的代码，现在几秒钟就能生成。对于探索性工作和快速原型开发而言，生产力提升是实实在在的。
但在受监管的嵌入式开发领域——ISO 26262 下的汽车软件、IEC 62304 下的医疗器械、IEC 61508 下的工业控制系统——速度从来不是瓶颈，证据才是。不是证明代码能运行的证据，而是证明代码是在既定实践下产出、对照正确标准检查过、从需求到测试可追溯的证据。
这是 AI 辅助工具在典型部署方式下令人不安的真相：它加速了原本就不是问题的环节（编写代码），同时给原本就昂贵的环节（验证、确认和合规认证）施加了更大的压力。
AI 生成代码，但不生成合规性
现代 AI 工具确实能力强大。它们能建议实现方案、补全函数、生成测试骨架。当你要求用 C 语言计算 RPM 时，你会得到语法正确、通常逻辑也成立的结果。
但这份输出不会自带合规性。
一个简单的 AI 生成函数乍看没问题。执行 MISRA C 2012 Rule 10.3 的静态分析器会把隐式类型转换标记为缺陷——这种缺陷必须先解决，代码才能追溯到某个已验证的需求。
这个模式在嵌入式团队遵循的每一项标准中反复出现：
1、MISRA C/C++： 安全关键型 C 和 C++ 开发的基线。将语言限制在一个明确定义的子集内，可最小化未定义行为的风险——这在汽车、工业和医疗领域是不可妥协的。随着 AI 工具生成越来越多的 C/C++ 代码，MISRA 合规成为一切进入代码库前的关键关卡。
2、CERT C/C++： 侧重于预防攻击者可利用的编码模式。MISRA 针对安全，CERT C/C++ 针对安全防护——这两个关注点在互联嵌入式系统中日益重叠。
3、CWE： 一份在各代码库中反复出现的软件弱点目录。对于审查 AI 生成代码的团队来说，CWE 提供了一套结构化的词汇表，用于识别模型可能从训练数据中无意复制的漏洞——因为模型从所有数据中学习，合规的和不合规的都一样。
这些标准没有一项由模型来执行。那是开发者的责任，需要合适的工具链来支持。
验证瓶颈
在安全关键型项目中，验证和确认已经消耗了研发预算的 40% 或更多。这不是低效，而是构建监管机构和认证机构所需的证据链的成本。
当 AI 加速了编写但让证据链原封不动时会发生什么？更多代码涌入验证管道。瓶颈扩大。资深安全工程师要审查更大的追溯矩阵。发布关卡纹丝不动。
AI 工具攻击的是开发曲线上从来不是约束的那部分。约束始终在后半段：静态分析、动态测试、覆盖率度量、可追溯性和签字放行。在未解决后半段的情况下加速编写，对于交付认证固件的团队来说不是生产力提升——而是给本已吃紧的流程施加了上游压力。
质量真正所在之处
弥合差距意味着把静态分析、动态分析和覆盖率度量纳入开发循环——不是作为下游审计，而是作为持续的、内嵌的活动。正确的工作流不会把代码生成和合规检查割裂开来；它把两者整合在一起。
1、静态分析与构建内嵌
C-STAT 是 IAR 工具链的一部分，在代码录入点就标记出 MISRA C、MISRA C++、CERT C 和 CWE 违规——在代码到达评审委员会或认证审计之前。AI 建议，开发者审查，C-STAT 验证。
2、调试会话中的动态分析
C-RUN 在调试会话期间对代码进行插桩，检测内存泄漏、越界访问、整数溢出和未处理的 switch 分支——这些缺陷静态分析不一定能捕获，因为它们依赖于执行状态。在 AI 辅助的工作流中，生成的代码可能结构健全但行为出人意料，运行时插桩不是可选项。
模型建议、开发者判断
以上任何一条都不是反对 AI 的理由。生产力提升是真实的。在嵌入式软件领域，熟练开发者稀缺、项目复杂性日增，任何能加速编写的工具都有真正价值。
但在 AI 辅助的工作流中，开发者的角色从代码作者转变为质量策展人。手艺没有消失，它重新定位了。开发者不再从零编写每一个函数，而是用领域知识评估 AI 建议，把建议放进分析工具中跑，做出没有任何模型能做出的判断：逻辑是否符合安全意图，测试套件是否覆盖了正确的场景，架构是否仍然自洽。
正是这一判断层把生成的代码转化为经过认证的代码。经过认证的代码才是受监管行业所要求的。
CI/CD：让证据自动化
内嵌工具在工作站捕获问题。但在团队环境中，仅靠工作站级别的检查是不够的。流水线才是执行点——每一次提交都会自动对照组织承诺的标准进行测试，无论代码是如何产出的。
当一次开发者会话能产出比过去一周还多的代码时，手动触发质量检查就不再可扩展。检查必须自动运行，在每一次推送时。
IAR Build Tools 提供了与 IAR Embedded Workbench 中相同的编译器、链接器和工具链，封装为可在 CI 中无头执行的形式。无论流水线运行在 Jenkins、GitHub Actions 还是 Azure DevOps 上，CI 中的构建与开发者机器上的构建完全一致。ISO 26262 和 IEC 62304 都要求用于产出发布制品的工具配置是可文档化、可复现的。IAR Build Tools 让这一点可被证明。
C-STAT 在 CI 中无头运行。违规作为构建输出上报。覆盖率趋势随时间被追踪。架构漂移立即可见。合规证据无需在发布时才组装——它在整个项目过程中持续累积。
