AI 代码审查
方案定位
面向汽车软件两端,以**双层审查(L1 + L2)**替代人工同行评审的重复劳动,让资深工程师只在关键点介入:
-
底软 / 安全关键域 — 底软、AUTOSAR BSW(CP / AP)、诊断栈、通信栈、HV 控制器;规则强约束(MISRA C:2012 / C++:2008、AUTOSAR C++14、ISO 26262、SecDev)
-
座舱 / Android 应用层 — HMI、车机系统、语音助手、地图、Carlink / CarPlay / HiCar、OTA、应用市场;Java / Kotlin / Jetpack Compose 主导,规则集是 AOSP CodeStyle、Android Lint、Detekt + Compose Rules、Checkstyle / PMD / SpotBugs
-
面向 OEM / Tier1 的软件部门、质量部门、合规团队
-
与 Gerrit / GitLab / GitHub / Gitee 深度闭环
行业痛点
| 痛点 | 现状 |
|---|---|
| 同行评审"走过场" | 人工看 PR 平均 15–30 分钟,只看得到风格和明显 bug;深层并发/内存/安全隐患漏过 |
| 规则多且变化快 | MISRA C:2012 / MISRA C++:2008 / AUTOSAR C++14 Coding Guidelines 叠加,工具维护成本高 |
| 经验不可复制 | 老工程师看到某一类代码就知道"容易出 bug",但这种直觉无法沉淀为制度 |
| 合规审计不可追溯 | 评审纪录靠评论区,无法批量统计规则覆盖率,ASPICE SWE.4 合规举证困难 |
双层审查架构
L1:客观静态扫描(本地工具链)
| 语言 | 工具 | 主要能力 |
|---|---|---|
| C/C++ | cppcheck、clang-tidy | MISRA C:2012、指针越界、未初始化、内存泄漏 |
| Python | ruff、bandit、mypy、semgrep | 风格、安全漏洞、类型、CWE |
| Java | Checkstyle、PMD、SpotBugs | 代码风格、坏味道、潜在 bug |
| Kotlin | detekt | 复杂度、异味、Compose 规则 |
这一层可以完全本地化运行(私有化部署不出数据),输出结构化 CodeEvidence JSON,作为 L2 的证据输入。
下图是 L1 + L2 双层闭环 的真实会话片段:L1 跑出 73 项 Checkstyle + 12 项 PMD,L2 在此基础上识别 6 个安全/资源问题,全程 2 分 18 秒:

L2:语义评审(LLM + 规则库 + 长期记忆)
与 L1 的区别:L1 回答**"合不合规则",L2 回答"有没有问题"**。L2 引入:
- 规则库(KB) — 把客户内部编码规范录入知识库,L2 审核时自动检索对照
- 长期记忆(LTM) —
bug-import把历史 Bug 四维聚合(模块热点 / 跨模块模式 / 文件热点 / 反复出现的根因),审查时如命中,报告中标记bug_pattern_match - 需求上下文(Requirements) — 针对安全关键代码,校验实现是否满足对应
SWE.3详细设计与SYS.2需求
详见 bug-import 技能 对 LTM 模式挖掘的工作方式。
下面是一次真实会话:用户要求 L2 在审核 HeartbeatChecker.java 时同时检索知识库,KB + LTM 一次命中 30 条文档,最终把"BMS 心跳模块反复 NPE"这种历史 Bug 模式标记为 Critical 级 bug_pattern_match:

客户价值
| 维度 | 传统同行评审 | combo agent 双层审查 |
|---|---|---|
| 平均审查耗时 | 15–30 分钟 / PR | 1–3 分钟 / PR |
| 交付周期节省 | — | 约 75% |
| 规则覆盖 | 依赖人的记忆 | MISRA C:2012 / C++:2008 / AUTOSAR C++14 + 客户自有规则 |
| 深度 | 风格 + 明显 Bug | 含跨函数、跨模块、安全、历史 Bug 命中 |
| 可复用资产 | 不可量化 | KB + LTM 持续沉淀,团队共享 |
操作步骤
前置:配置代码平台凭据
| 平台 | 鉴权方式 | 最小权限 |
|---|---|---|
| Gerrit | HTTP Password | Gerrit Code Review User(对目标仓库的读写) |
| GitLab | Personal Access Token | api + read_repository |
| GitHub | GitHub App 或 Fine-grained PAT | Pull requests: read & write + Contents: read |
| Gitee | Private Token | 同仓库读写权限 |
凭据通过 Agent 会话内的 manage_scm_bot 工具按提示词激活。详见 代码托管平台集成。
整体工作流
触发方式
方式 A:Webhook(推荐,自动化)
通过 Agent 提示词激活后,代码平台 Webhook 自动指向 combo agent,每次 PR 提交 / patchset 更新自动触发。下图是一次真实闭环:GitHub 推 webhook → Agent 自动调 GitHub API 拉 diff → 按模块审 30 个文件 → 22 个 finding 写回 PR 评论:

方式 B:会话手动触发
Agent 会:
- 调用
gerrit-integration技能拉取变更 - 启动 L1 静态分析
- 启动 L2 语义评审
- 合并报告回写为评论
方式 C:CI 流水线集成
L1 配置:关闭 / 启用特定规则
按文件类型自动分派;如要细调,在仓库根目录放 .combo-review.yaml:
L2 配置:让 L2 看见客户规范与历史 Bug
把客户内部编码规范 / 架构决策文档 / ASPICE 标准上传到指定知识库:
开启 bug-import 技能,定期把 Jira / Polarion / Redmine 的历史 Bug 导入:
bug-import 会按四个维度聚合(模块热点 / 跨模块模式 / 文件热点 / 反复根因),存为 LTM fact。L2 审查时如命中,报告中标记 bug_pattern_match。
审查报告解读
审查结束后,Agent 会把合并后的报告按行评论回写到代码平台。报告结构:
每条评论带证据引用(L1 工具原始输出、L2 引用的规范条款 / 历史 Bug)。
批量审查(历史代码补扫)
Agent 会列出区间内的 PR → 逐个审查 → 汇总统计(按规则 / 按模块 / 按严重性)→ 输出 html-report 看板。
典型工作流
- 触发 — PR 提交或 Gerrit patchset 刷新,Webhook 进入 Event Trigger
- 分派 — 平台根据变更文件类型分派到对应 L1 + L2 组合
- L1 扫描 — 并行启动静态分析工具链,输出 JSON 证据
- L2 评审 — Code Review Agent 构建上下文(变更 + 规则库 + LTM + 相关需求),输出语义审查报告
- 回写 — 合并 L1/L2 结果,按行评论写回代码平台,同时落地 KPI 记分卡
常见问题
Q:审查报告中有误报,能让 L1 某条规则不触发吗?
A:在仓库根目录 .combo-review.yaml 里 suppress 掉即可。
Q:L2 会把公司源码发到外部 LLM 吗? A:私有化部署下,L2 走内网 LLM(国产模型 DeepSeek / Qwen / GLM / MiniMax),代码不出内网。SaaS 模式下走合规 LLM 通道,合同内已约定数据边界。
Q:Gerrit 的 +Code-Review+1 打分能自动给吗?
A:可以。在 Gerrit 集成配置中开启自动打分,规则可配(所有 L1 错误 → -1;无任何错误 → +1)。
相关文档
- 🛠️ 平台技能:code-review 总览 · bug-import(LTM 模式挖掘)
- 🔌 代码平台对接:Gerrit / GitHub / GitLab / Gitee
- 📖 基础概念:Event Trigger 事件触发
- 🏠 场景总览:汽车场景