7 个 AI 同时审查一份代码，最终修了 38 个问题——多模型代码审查实战复盘

背景

最近完成了一个 QA 平台的 Phase 1 开发，代码量约 2 万行（Python 后端 + React 前端）。在准备合并发版前，想做一个实验：如果让多个 AI 模型同时审查同一份代码，它们会发现什么？结论一致吗？

这个想法源于一个观察——单个 AI 的 review 往往有盲区，但不同模型的训练数据和推理风格不同，可能互补。于是我把代码分别发给了 7 个 AI：

Claude（Anthropic）
Kimi（月之暗面）
GLM（智谱）
DeepSeek
小米 MiMo
Antigravity（蚂蚁）
Minimax

目标

收集 7 份独立 review，合并去重，得到一份”共识路线图”
按优先级修复所有真实问题（目标：CRITICAL + P1 全部闭环）
记录各模型的独特发现和误判，为后续选择审查模型提供参考

遇到的问题

问题一：各模型的报告格式和严重级别定义不统一

有的模型用 CRITICAL/HIGH/MEDIUM/LOW，有的用 P0/P1/P2/P3，有的直接用”必须修/建议修/可选”。合并时需要人工对齐语义。

问题二：存在明显的误判

部分模型把”有意识的设计决策”误判为”漏洞”。例如：

Minimax 把 JWT 黑名单的 fail-open 策略标为 CRITICAL，但代码注释明确说明这是”Redis 抖动不能导致 500”的 trade-off
DeepSeek 声称 Dockerfile CMD 路径不存在，但实际上 PEP 562 lazy-export shim 让路径有效
小米把 docker.sock 挂载标为 CRITICAL，但这属于部署侧风险，不是代码可利用漏洞

问题三：同一问题被不同模型以不同角度发现

例如 SQL LIKE 注入，DeepSeek、小米、Kimi 三个模型都发现了，但描述和严重级别各不相同。需要合并为一条并取最高共识级别。

排查过程与踩坑

第一步：逐份 Review 分析

每份 review 平均 15-25 个条目，7 份合计约 120 条。初步去重后剩下约 50 个独立问题。

关键发现：不同模型的强项差异明显：

模型	强项	独家发现
GLM	架构级问题（双重写入、租户隔离）	executor/tasks 双重写入终端状态
Antigravity	框架警告（SQLAlchemy、Mock）	SQLAlchemy 2.0 overlaps 警告
Kimi	细节校验（边界值、类型）	expires_days 无上界
DeepSeek	安全漏洞（注入、协议）	SQL LIKE 注入
Claude	端到端流程（审计、部署）	docs_url factory 模式永久关闭

第二步：一手代码验证

这是最关键的一步。每个问题都必须通过 grep / sed 在代码中确认存在，不能只看 AI 的描述。

例如 Minimax 声称的”RBAC 跨租户绕过”，实际检查发现 get_for_tenant 在路由层已经做了租户校验，platform_admin 仍然 scoped to tenant_id。这是误判。

第三步：合并路线图

最终得到 7 阶段 40 条目的修复路线图：

第一阶段（CRITICAL）：4 条 — SQL 注入、iframe 逃逸、状态归一化、XSS
第二阶段（P1）：9 条 — 审计异常传播、密钥校验、token 安全等
第三阶段（独家发现）：4 条 — GLM 和 Antigravity 的独有问题
第四阶段（容器加固）：3 条 — Dockerfile、CI E2E
第五阶段（数据库/测试）：3 条 — fixture 类型、迁移清理
第六阶段（P2）：12 条 — 一致性与可读性
第七阶段（P3）：5 条 — 文档与代码清理

第四步：逐条修复

每个问题单独一个 commit，遵循”中文 commit message + semantic prefix + 单一意图”原则。共产生 17 个 commit。

解决方案

核心改动

以几个典型问题为例：

§1.1 SQL LIKE 注入（3 个模型共同发现）

# 修复前
pattern = f"%{q}%"

# 修复后
def _escape_like(s: str) -> str:
    return s.replace("\\", "\\\\").replace("%", "\\%").replace("_", "\\_")

pattern = f"%{_escape_like(q)}%"
filters.append(or_(
    ProjectORM.name.ilike(pattern, escape="\\"),
    ProjectORM.description.ilike(pattern, escape="\\"),
))

§3.1 executor/tasks 双重写入（GLM 独家发现）

executor 和 tasks 两个模块都调用了 finish_if_current()，虽然第二次调用 rowcount=0 不影响正确性，但语义重复且在日志/metrics 上产生迷惑。修复：明确职责边界，只保留一处写入。

§6.4 rate_limit 时钟回拨（Antigravity 独家发现）

用 time.time() 作 Redis score，时钟回拨会重置限流。改用 Redis TIME 命令获取服务端时间。

误判处理

对 5 个误判项明确标注”不要按这些结论修改”，避免后续有人按错误结论改回归。

修复结果

40 个问题中修复了 38 个（95%）
剩余 2 个：1 个是版本号验证（已确认无需修复），1 个是文件拆分重构（不阻塞发版）
所有 CRITICAL + P1 问题全部闭环
608 个单元测试全部通过
ruff check 干净

经验总结与工具推荐

核心教训

多模型 review 有明显的互补价值。GLM 发现的架构级问题（双重写入）和 Antigravity 发现的框架警告（SQLAlchemy overlaps），其他 6 个模型都没提到。
一手代码验证不可省略。7 份 review 中有 5 个误判，如果直接按 AI 结论修改，反而会引入新问题。
合并比单独 review 更有价值。单个模型平均发现 15-20 个问题，但合并去重后有 40 个独立问题，覆盖率显著提升。
AI 对”有意识的 trade-off”识别能力弱。多个模型把 fail-open 策略、部署侧风险等设计决策误判为漏洞。这需要人工判断。

工具推荐

ruff：Python linter，修复过程中持续运行确保代码质量
pytest -W error::RuntimeWarning：把警告升为错误，发现”虚假通过”的测试
SQLAlchemy 2.0 的 overlaps 参数：显式声明 relationship 重叠，消除警告

最后的反思

这次实验让我重新认识了 AI review 的定位：它是辅助工具，不是权威裁判。AI 擅长发现模式匹配类问题（注入、XSS、边界值），但对架构级 trade-off 的判断仍然需要人类把关。

最高效的方式不是让一个 AI 做全面 review，而是让多个 AI 各展所长，人工合并验证。这比任何单个模型的 review 都更可靠。

背景

目标