安全关键软件中的‘氛围编码’：前景、风险与前进路径

氛围编码的吸引力

核心在于，它大幅降低了从意图到实现之间的摩擦。现代LLM可将自然语言需求直接转译为可编译代码，显著缩短开发周期。

主要优势：

• 加速开发周期：AI生成代码使概念→原型→量产的迭代极为迅速，尤其适用于需求尚处演进阶段的早期设计。
• 提升开发者产出效率：通过自动化模板生成、测试脚手架搭建及重构等重复性任务，工程师得以聚焦于更高层次的设计决策。
• 增强可及性：经验较少的开发者可借助AI辅助产出原本需深厚专业功底的代码，有效降低入门门槛。

上述能力共同使其在追求快速上市与应对日益复杂系统压力的环境中极具吸引力。

为何安全关键系统迥然不同

尽管优势显著，安全关键软件开发所施加的约束从根本上挑战了纯AI驱动代码生成（即‘氛围编码’）的可行性。

• LLM的非确定性：LLM本质上是基于异构数据集训练的随机系统。相同输入可能产生不同输出，且无法保证严格遵循安全编码标准。这种非确定性与认证要求（强调可重复性、可追溯性与形式化依据）相悖。
• 高缺陷与漏洞发生率：实证研究表明，大量AI生成代码存在安全缺陷或违反最佳实践，可能导致不可预测行为。不可预测的软件既不安全也不可靠。即便模型持续改进并产出更优、更安全的代码，现有研究仍表明：模型无法被无条件信任——它们可能生成导致行为异常的代码结构，或无法精准实现指定需求；甚至当明确指令其遵守设计约束与编码规范时，仍可能违规。
• 缺乏资格认证框架：现行安全关键系统标准虽允许使用代码生成工具，但要求工具必须具备确定性，并须经专门的“工具资格认证”（Tool Qualification/Validation）流程——即提供证据证明工具行为确定、符合操作规范。例如，将仿真模型转换为源代码的工具可满足此要求；一旦认证通过，其输出可在关键系统中有限或无需额外验证地使用。而LLM则完全不同：目前尚无被广泛接受的方法论，可依功能安全标准（如ISO 26262、DO-178C、IEC 62304）对LLM基代码生成器进行资格认证。未经认证，其输出默认不可信。

核心原则：验证不可妥协

行业实践与当前研究一致得出明确结论：AI生成代码本身对安全关键系统不具备内在可信度。

仅当其经历与人工编写代码同等严格的验证与确认（V&V）流程后，方可被接受。

该流程包括：

• 静态代码分析
• 动态测试（单元、集成、系统级、SIL/PIL/HIL测试）
• 适用时的形式化验证
• 安全评估
• 标准合规性核查
• 需求→实现→测试的全程可追溯性

换言之，“氛围编码”或AI代码生成并未消除传统安全工程实践的必要性，反而凸显其重要性。

AI与确定性验证的混合模式

鉴于独立AI代码生成的局限性，当前研究与实验性工作普遍趋向于一种混合模型。

在此范式中：AI负责从需求生成代码；确定性工具则实时标记潜在缺陷与不合规项。二者构成反馈闭环——若分析工具检测到问题，即生成诊断信息并提交给AI代理请求修复；代理尝试修正后，修改版代码重新进入流水线；循环迭代直至代码通过全部质量关卡，最终提交人工专家复审。

此类工作流的核心价值在于显著降低最终人工复审所需投入。确定性代码分析工具可自动识别并消除整类问题，从而节省验证与批准环节的时间与精力。该模式建立在成熟的软件测试自动化基础之上。

宏观上看，此构想颇具吸引力，但仍面临若干挑战。首要在于：整体效能受限于流水线中集成的确定性工具能力。自动化检测仅对特定类问题可行，典型如静态分析——可作为质量关卡嵌入流水线，系统性依据预设规则评估代码。此类工具擅长识别潜在运行时错误、未定义行为等，并强制执行MISRA等编码标准，从而提升对AI生成代码的信心。

当发现违规时，静态分析工具输出的诊断信息通常结构清晰、可操作性强；在多数情况下，这些信息可被AI代理直接接收并用于代码修复。除静态分析外，单元测试、属性测试及形式化验证等技术亦可进一步强化该自动化流程的稳健性。

易IC库存管理软件

该工作流假设需求文档已包含测试用例规范：需求连同生成请求一并提交给AI代理；测试用例规范则用于自动生成单元、集成及系统级测试用例。生成代码随后通过多级关卡——执行前述测试用例，并将失败结果与代码覆盖率反馈至AI代理，触发修复请求（可能涉及修改代码、调整测试用例或补充新测试）。

当所有关卡均通过后，代码提交人工专家复审。理论上，此时代码应已清除所有可被质量关卡识别的问题。与此同时，另一代理被指派整合各关卡执行报告，并起草初始版安全文档。

需强调：此流程为简化模型，未涵盖真实安全关键软件开发的全部复杂性，仅旨在阐明当前活跃研究方向及AI代理在其中的潜在角色。其核心价值在于：通过前置消除特定类缺陷，切实减轻最终人工复审与批准负担。

另一替代路径是赋予代理一套技能集合——包括代码构建、静态分析执行及各类测试运行能力。在此模式下，代理拥有充分自主权，可自行决策达成目标所需步骤。

“技能导向”路径更契合AI代理长期融入软件开发的战略愿景。但目前多数团队倾向采用管控更严格的方案，原因在于：处理大型代码库（如为既有系统新增功能）时，代理采取“不合理”行动（如无谓重建整个代码库）所耗费的时间与计算资源成本过高。

实验性工作流的启示

内部曾实施图3所示实验流程：目标为验证能否对简单C++程序进行‘氛围编码’，并自动通过三重关卡——MISRA指南静态分析、MC/DC覆盖单元测试、带覆盖率的集成测试。团队选用多个主流编程挑战基准集，但结论是：现有基准集复杂度不足，难以全面评估该流程在自动化精炼‘氛围编码’实现中的可行性。因此转向更基础问题：能否生成功能正确且自动符合MISRA C++:2023标准的简单C++程序？

实验设置如下图所示：

实验结果积极：代理成功为所有案例生成功能正确代码，并自动确保其符合MISRA C++:2023标准。下图展示了达成合规与功能正确所需的迭代次数分布：

在总计72个测试案例中，46个仅需2轮迭代即达成目标；仅6个案例需6轮迭代完成。这表明：将静态分析纳入自动化反馈闭环，完全可行——足以保障AI生成代码符合安全关键软件常用行业标准。

结论

‘氛围编码’正在变革软件开发方式，带来显著的生产力与灵活性提升。然而，其在安全关键系统中的应用受限于确定性、可追溯性与可验证性的根本要求。

基于当前能力，‘氛围编码’不应被视为传统安全关键代码开发的替代方案，而应定位为增强层。

AI编程代理应被视为紧密受控、以验证为核心流程中的协作伙伴。恰当使用时，它们能在不牺牲安全的前提下提升效率——这一平衡，正是未来关键系统开发的关键所在。