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 合规举证困难

双层审查架构

Rendering diagram…

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 秒：

L1 静态分析 + L2 综合审核（CR-E2E-Round2 实际会话）

L2：语义评审（LLM + 规则库 + 长期记忆）

与 L1 的区别：L1 回答**"合不合规则"，L2 回答"有没有问题"**。L2 引入：

规则库（KB） — 把客户内部编码规范录入知识库，L2 审核时自动检索对照
长期记忆（LTM） — bug-import 把历史 Bug 四维聚合（模块热点 / 跨模块模式 / 文件热点 / 反复出现的根因），审查时如命中，报告中标记 bug_pattern_match
需求上下文（Requirements） — 针对安全关键代码，校验实现是否满足对应 SWE.3 详细设计与 SYS.2 需求

详见 bug-import 技能对 LTM 模式挖掘的工作方式。

L2 背后的检索能力（三档可选）

L2 不是"裸 LLM 看 diff"——它要找定义、看调用关系、跨文件追溯。这一切由平台代码索引三档能力支撑，按你愿意付出的初始化时间换深度：

档位	适合的代码审查场景	平均出结论时间
零索引	临时审一个外包提交、一次性接管的旧代码	立等可取
轻索引（默认）	日常 PR / MR / Gerrit change 审核	改一个文件秒级可搜
重索引	跨编译单元 / 全分支 / 全仓审、ASPICE 合规审、SOTIF 安全分析	初始化 10 分钟～小时级

ASIL-D 模块代码做"改这一行影响哪些下游"这种问题，必须开重索引档。轻索引给不出准确答案。详见代码索引三档。

下面是一次真实会话：用户要求 L2 在审核 HeartbeatChecker.java 时同时检索知识库，KB + LTM 一次命中 30 条文档，最终把"BMS 心跳模块反复 NPE"这种历史 Bug 模式标记为 Critical 级 bug_pattern_match：

L2 命中历史缺陷库（CR-E2E-T1-Java 实际会话）

客户价值

维度	传统同行评审	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 工具按提示词激活。详见代码托管平台集成。

整体工作流

Rendering diagram…

触发方式

方式 A：Webhook（推荐，自动化）

通过 Agent 提示词激活后，代码平台 Webhook 自动指向 combo agent，每次 PR 提交 / patchset 更新自动触发。下图是一次真实闭环：GitHub 推 webhook → Agent 自动调 GitHub API 拉 diff → 按模块审 30 个文件 → 22 个 finding 写回 PR 评论：

GitHub Webhook 触发自动 PR 审查（实际会话片段）

方式 B：会话手动触发

请审查 Gerrit 上这个 change: https://gerrit.example.com/c/123456

Agent 会：

调用 gerrit-integration 技能拉取变更
启动 L1 静态分析
启动 L2 语义评审
合并报告回写为评论

方式 C：CI 流水线集成

# .gitlab-ci.yml 示例
code-review:
  script:
    - curl -X POST -H "Authorization: Bearer $COMBO_TOKEN" \
        -d "{\"pr_url\":\"$CI_PROJECT_URL/-/merge_requests/$CI_MERGE_REQUEST_IID\"}" \
        $COMBO_URL/v1/webhook/code-review

L1 配置：关闭 / 启用特定规则

按文件类型自动分派；如要细调，在仓库根目录放 .combo-review.yaml：

l1:
  cpp:
    cppcheck:
      enable: [warning, style, performance]
      suppress: [unusedStructMember]
    clang-tidy:
      checks: "misra-*, -misra-c2012-17.8"  # 关掉 MISRA 17.8

L2 配置：让 L2 看见客户规范与历史 Bug

把客户内部编码规范 / 架构决策文档 / ASPICE 标准上传到指定知识库：

把这份《XXX 项目编码规范 V3.2.pdf》上传到代码审查规则库。

开启 bug-import 技能，定期把 Jira / Polarion / Redmine 的历史 Bug 导入：

把过去 2 年 Jira 里的 Bug 增量同步过来，每 6 小时跑一次。

bug-import 会按四个维度聚合（模块热点 / 跨模块模式 / 文件热点 / 反复根因），存为 LTM fact。L2 审查时如命中，报告中标记 bug_pattern_match。

审查报告解读

审查结束后，Agent 会把合并后的报告按行评论回写到代码平台。报告结构：

[L1] bms/heartbeat.c:42 [cppcheck/nullPointer]
  解引用前未检查空指针。建议加 null check。

[L2] bms/heartbeat.c:42 [bug_pattern_match]
  命中历史模式「BMS 模块心跳处理反复出现空指针」。
  相关历史 Bug：BUG-118, BUG-203, BUG-301, BUG-412。
  建议：参考 BUG-412 的修复方式，在进入 heartbeat handler 前统一做 null check。

每条评论带证据引用（L1 工具原始输出、L2 引用的规范条款 / 历史 Bug）。

全分支 / 全仓审（v1.1+ 新增）

除了单 PR 预检（场景 A）和定期批量扫描（场景 B），平台现在支持场景 C：全分支 / 全仓审——一次性深度审完整个仓库或一个长期分支：

对 vehicle-bsw 仓库的 release/2026Q2 分支跑一次全分支审，
要求重索引档，输出 ASPICE SWE.4 合规报告。

适合大版本发布前 / 新仓库接管时 / 月度合规审核。会自动开重索引档。

Gerrit 用户注意

Gerrit 适配当前不支持全分支审，仅支持单 change。需要全仓审请用 GitHub / GitLab，或 mirror 到通用 git 仓库后走平台通用代码审查。详见 gerrit-integration 行为升级。

批量审查（历史代码补扫）

把这个仓库从 commit abc123 到 main 的所有 PR 重新跑一次审查，汇总到一个报告里。

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）。

升级提醒：v1.1+ 起 auto_broadcast 默认改为 False——必须显式开启才会自动回帖。打 -2 前依然走 ask_user 二次确认。详见 gerrit-integration 行为升级。

Q：我们 PR 评审场景下，按"函数/类"切块不够细，能按 commit hunk 切吗？ A：能。平台开放 parser-sdk，自己写一个 hunk-aware 代码切片器，跟内置 code-aware 共存，PR 评审专用 KB 切到你这个就行。我们提供了一份完整可下载的参考实现：hunk_aware_code_parser.py。