1. 项目背景与核心发现
最近我在处理一个遗留的C++音视频基础库时,尝试了一个有趣的实验:同时使用Claude Opus 4.6和GPT-5.3-Codex对26个模块进行代码审计。结果令人震惊——两个AI只在10个模块上达成共识,一致率仅为38.5%。
这个项目是个典型的"祖传代码":十几年的历史积累,26个模块,数万个源文件。新来的开发人员都不敢轻易改动,生怕引发连锁反应。我原本希望通过AI审计快速评估代码质量,没想到却发现了AI审计工具之间巨大的判断差异。
1.1 审计结果对比
Claude的审计结果相对乐观:
- 13个模块被评为"核心基石"(质量可靠,可直接作为新架构基础)
- 11个模块需要"提纯合并"(有价值但存在冗余)
- 2个模块需要"重塑提取"(仅部分可用)
而Codex的评估则严格得多:
- 仅2个模块获得"核心基石"评价
- 16个模块需要"提纯合并"
- 8个模块被标记为"重塑提取"
更关键的是,Codex独立发现了13个Claude完全漏报的关键问题,这些问题不是简单的代码风格问题,而是实实在在的功能缺陷和安全隐患。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 审计方法设计
2.1 双Agent交叉审计方案
为了确保审计的客观性,我设计了一个双Agent交叉审计流程:
-
环境准备:
- 使用repo-scan工具的交叉扫描功能
- 为两个AI创建完全隔离的审计环境
- 确保它们无法看到对方的分析结果
-
审计执行:
-
Agent-1(Claude Opus 4.6):执行全量扫描
- 逐模块分析代码结构
- 检查依赖关系
- 评估质量问题
- 给出四级判决
-
Agent-2(GPT-5.3-Codex):执行独立验证
- 不看Agent-1的结论
- 对同一批模块做独立审计
- 使用相同的四级判决体系
-
-
结果对比:
- 生成交叉扫描报告
- 可视化展示判决差异
- 重点分析分歧模块
2.2 四级判决体系
我们采用了一个四级的质量评估体系:
| 判决等级 | 含义 | 建议行动 |
|---|---|---|
| 🟢 核心基石 | 质量可靠 | 直接保留,作为新架构基础 |
| 🔵 提纯合并 | 有价值但冗余 | 提取核心逻辑,合并同类模块 |
| 🟡 重塑提取 | 部分可用 | 大幅改造,仅保留算法/协议层 |
| 🔴 彻底淘汰 | 不值得修 | 删除重来,用现代方案替代 |
这个体系既考虑了代码质量,也给出了明确的改进方向,特别适合遗留系统的现代化改造。
3. 典型分歧案例分析
3.1 MP4解析模块的字节错位
在mp4_parser模块中,Codex发现了一个严重的字节写入错误:
- 代码应该写入32位的16.16定点数(高16位整数+低16位小数)
- 但实际上写入16位值后,指针错误地后移了4字节
- 导致低16位被后续数据覆盖
这个错误在大多数播放器中表现正常(因为播放器容错能力强),但如果遇到严格按规范解析的工具,就会得到错误的宽高值。而Claude在审计同一段代码时,给出的评价却是"MP4封装模块功能完整"。
3.2 形同虚设的视频加密
video_encrypt模块被Claude评价为"视频加密模块,功能可用,建议优化"。但Codex发现了严重问题:
- 加密逻辑只是简单的4字节XOR
- 用Python脚本十行就能逆向
- 内含时间炸弹代码
- ReadFrame存在空指针解引用风险
这根本不是加密模块,而是一个随时可能崩溃的安全隐患。
3.3 协议实现中的God Class
protocol_gb28181模块被Claude称赞为"协议支持完善,是核心基石"。Codex却揭露:
- Server和Client代码60%是复制粘贴的
- 三组配对对象各自重新实现了"SIP会话+RTP媒体+业务控制"
- 典型的God Class设计
- 修改一处可能引发多处回归问题
4. AI审计差异的本质原因
4.1 Claude的审计特点
Claude的审计风格像是一个注重整体功能的项目经理:
- 关注接口声明和实现
- 检查基本功能是否完整
- 重视代码能否编译运行
- 偏向"功能覆盖度"评估
- 容易忽略实现细节的质量问题
这种风格适合快速建立对代码库的整体认知,但可能遗漏深层次问题。
4.2 Codex的审计特点
Codex的审计风格则像是一个严格的Code Review专家:
- 检查每个分支条件
- 验证资源管理
- 识别过时API
- 关注边界条件
- 偏向"实现质量"评估
- 对代码健壮性要求极高
这种风格能发现许多潜在问题,但可能需要更多时间来分析。
5. 实践建议与经验总结
5.1 多AI交叉审计策略
基于这次实验,我总结出以下实践建议:
-
关键代码必须双审计:
- 至少使用两个不同家族的AI模型
- 确保审计过程完全独立
- 对比分析结果差异
-
分歧点就是重点:
- 两个AI结论一致的模块可信度高
- 存在分歧的模块需要人工重点检查
- 分歧点往往揭示代码的潜在问题
-
根据场景选择工具:
- 快速了解项目整体:优先使用Claude
- 深入检查代码质量:优先使用Codex
- 生产环境代码:必须双审计
5.2 审计工具配置技巧
在实际操作中,我发现这些配置能显著提升审计效果:
-
上下文窗口设置:
- Claude Max版支持1M tokens上下文
- Codex Pro版支持400K tokens
- 大上下文有助于分析复杂模块
-
提示词优化:
python复制# 示例审计提示词模板
"""
你是一个资深C++工程师,正在审计[模块名]代码。
请从以下维度评估:
1. 功能完整性(接口实现、边界条件)
2. 代码质量(资源管理、错误处理)
3. 设计合理性(耦合度、扩展性)
4. 安全隐患(缓冲区、注入风险)
按照四级体系给出判决,并详细说明理由。
"""
- 结果对比工具:
- 使用diff工具可视化差异
- 为每个分歧点创建issue
- 记录审计决策过程
5.3 人工复核要点
AI审计后的人工复核应该关注:
-
验证AI发现的问题:
- 重现问题场景
- 评估实际影响
- 确定修复优先级
-
检查AI的盲区:
- 业务逻辑正确性
- 领域特定知识
- 性能关键路径
-
制定改进计划:
- 核心模块优先重构
- 高风险问题立即修复
- 技术债务登记管理
6. 常见问题与解决方案
6.1 审计结果差异过大怎么办?
当两个AI的审计结果差异很大时:
-
分层处理:
- 先解决两个AI都认可的问题
- 然后处理一个AI发现的问题
- 最后人工复核分歧点
-
权重分配:
- 安全相关问题上倾向Codex
- 架构设计问题上参考Claude
- 业务逻辑问题必须人工确认
6.2 如何提高审计效率?
-
模块化审计:
- 按功能划分审计单元
- 控制单个审计任务的规模
- 建立模块依赖关系图
-
增量审计:
- 先审计核心模块
- 再审计依赖模块
- 最后审计工具类模块
-
自动化集成:
- 将AI审计集成到CI流程
- 设置质量门禁
- 定期生成技术债务报告
6.3 审计成本控制
-
模型选择:
- 日常审计使用基础版
- 关键审计使用高级版
- 混合使用降低成本
-
结果复用:
- 建立审计结果知识库
- 相似模块参考历史结果
- 定期更新审计结论
-
人机协作:
- AI负责初步筛查
- 人类专家重点复核
- 逐步建立信任机制
7. 工具链与工作流建议
7.1 推荐工具组合
基于实际使用体验,我推荐以下工具组合:
-
核心审计工具:
- Claude Code(功能覆盖分析)
- Codex CLI(实现质量分析)
- 月成本约40美元(两个基础版)
-
辅助工具:
- repo-scan(交叉扫描)
- Semgrep(模式匹配)
- SonarQube(静态分析)
-
可视化工具:
- D3.js(审计结果可视化)
- PlantUML(架构图生成)
- Grafana(质量趋势监控)
7.2 审计工作流优化
一个高效的AI审计工作流应该包含:
-
预处理阶段:
- 代码规范化
- 依赖分析
- 模块划分
-
并行审计阶段:
- 启动多个AI审计任务
- 设置超时机制
- 监控资源使用
-
结果整合阶段:
- 自动生成对比报告
- 标记关键分歧点
- 提供修复建议
-
持续改进阶段:
- 跟踪问题修复
- 评估审计准确率
- 优化提示词模板
8. 未来展望与个人体会
这次实验彻底改变了我对AI代码审计的看法。以前我可能会依赖单一AI的审计结果,现在则坚持必须交叉验证。两个20美元的基础版AI协作,效果远胜一个200美元的高级版。
在实际操作中,我发现Claude更适合快速理解代码库全貌,而Codex则擅长发现隐藏问题。将它们组合使用,既能获得全局视角,又能捕捉细节缺陷。这种"广角+微距"的双重检查,显著提升了我的代码审查效率和质量。
对于大型遗留系统,我现在的标准流程是:
- 用Claude快速扫描,建立架构认知
- 用Codex深度检查,发现潜在问题
- 人工复核关键分歧点
- 制定分阶段的现代化改造计划
这种工作方式不仅适用于C++项目,我在Java和Go的遗留系统改造中也取得了不错的效果。关键在于理解不同AI工具的特性,合理利用它们的优势,而不是盲目相信单一工具的结论。
