AI Code Governance for Mission Critical SW

Gen AI 生成的代码必须经过人工评审

在 Automotive 和功能安全相关软件中,AI 生成代码的生成履历、完整性、评审状态和变更控制证据必须被严格保留。

Synetics 定义该流程,并通过识别 AI 生成代码、支持评审人员的解决方案,使其进入实际开发流程。

ISO 26262 supporting controlA‑SPICE SWE.3 / SWE.4VS Code + JenkinsHash-based Integrity

区分咨询、人员、AI 与工具角色的 Flow

Flow
01
Consulting定义 AI 编码方式
02
Human向 AI 请求代码生成
03
AI按定义方式生成代码
04
Tool识别 AI 生成代码并确保完整性
05
Tool提示评审对象和评审项
06
Human执行评审
07
Tool保存 AI 生成代码的评审结果
08
Tool展示 AI 生成代码状态 Dashboard

咨询定义 AI 编码方式,人员负责生成请求和最终评审,工具管理 AI 代码识别、完整性和评审证据。

4 Integrity Levels

通过函数、静态上下文、模块/类、文件级哈希追踪变更影响。

3 Tool Components

用 AICodeGenSaver、AICodeGenReviewer、AICodeGenDashboard 连接 IDE 与 CI。

CI Review Gate

在 Jenkins 中验证 Annotation、Hash、评审状态和策略违规。

Why It Matters

AI 生成代码需要先控制,再追求速度

如果直接合并 AI 生成代码,可能出现需求遗漏、任意行为、评审证据不足和工具可信度问题。

追溯性变弱

如果没有模型、提示词、请求者和基准 commit,就难以说明代码生成依据。

评审证据不足

功能安全活动需要客观证据来说明谁在何时完成了评审和批准。

完整性回归未发现

已评审代码发生变化但状态不回退,会破坏变更控制和再评审机制。

Operating Flow

将 AI 候选代码转换为可批准的证据

从开发者请求到 Jenkins 输出成果物,形成一个闭环。

01

基于需求的生成请求

在 Gen AI 请求中包含需求 ID、变更 ID、安全分类和允许变更范围。

02

自动注入 Annotation 与 Hash

保存时 IDE Plugin 计算 provenance 和各层级 Hash。

03

人员评审与状态转换

AI 不能设置 Reviewed,只有人员 Reviewer 可以记录评审状态。

04

CI Gate 与审计证据

Jenkins 验证 Placeholder、Hash mismatch、未完成评审和独立性违规。

Integrity Model

按逻辑单元管理 AI 生成履历,而不是只看整个文件

即使人员代码和 AI 代码混在同一文件中,也能追踪变更影响和再评审范围。

L1

Function-Level

基于 AST 规范化函数签名和函数体,并用 @funcId 管理。

L2

Static Context Block

用 @staticContextId 管理 include、define、typedef、constexpr 等静态元素。

L3

Module / Class-Level

用 Merkle Tree 方式的 @moduleId 追踪类、结构体和 namespace 级变更。

L4

File-Level

用 @fileHash 支持 Jenkins 的 Quick Integrity Check。

Tool Architecture

流程必须在开发工具中运行,而不是停留在文档中

通过两个 VS Code Plugin 和一个 Jenkins Plugin,将流程落实到日常工程活动。

VS Code 保存 Hook

AICodeGenSaver

  • 更新 Annotation Placeholder
  • 计算各层级 Hash
  • 已评审代码变更时自动回退状态

人员评审支持

AICodeGenReviewer

  • 识别评审对象
  • 显示评审专用 Gen AI 指南
  • 记录人员 Reviewer 状态变更历史

Jenkins 验证 Gate

AICodeGenDashboard

  • 重新验证 Annotation 和 Hash
  • 应用 Advisory / Blocking 策略
  • 生成 Dashboard 和审计成果物

Consulting Scope

同时设计工具开发与流程导入

这不是单纯的插件开发,而是连接 Safety Plan、A‑SPICE 活动、编码规则和 CI/CT 运营。

流程策略设计

定义 AI 代码政策、状态模型、Annotation 规则、评审回归策略和 Gate 标准。

项目导入咨询

结合需求、变更、安全分类体系以及 Git/Jenkins 运营方式设计适用范围。

工具可信度支持

在 Safety 项目中,将 IDE/Jenkins Plugin 整理为软件工具可信度评估对象。

评审与验证体系构建

协调人员评审、AI 评审指南、静态分析、单元测试和 CI 质量 Gate。

Evidence Dashboard

留下可用于审计和流程评估的数据与成果物

Jenkins 结果不仅在画面显示,还应以 JSON、HTML、CSV 形式保存。

Gen AI 代码 LOC 与比例
评审对象函数/文件数与完成率
按模型/模块统计 AI 代码比例
Hash mismatch 与评审回归次数
平均评审耗时和人员进度

FAQ

该流程需要回答的问题

只应用该流程就能保证 ISO 26262 或 A‑SPICE 符合性吗?

不能。它是辅助控制手段,需要与 Safety Plan、编码规则、验证策略和质量保证活动一起运行。

AI 可以把评审状态设置为 Reviewed 吗?

不可以。AI 生成结果始终是候选代码,最终状态转换必须由人员 Reviewer 明确执行。

为什么不只按文件,而要按函数和上下文管理?

同一文件中可能同时存在人员代码和 AI 代码。逻辑单元 Hash 才能让再评审范围可控且可追踪。

Next Step

AI 代码生成不只是开发速度问题

Mission Critical SW 需要说明 AI 代码如何生成、变更、评审和批准。我们可以根据当前开发流程一起评估适用范围。