1. 项目背景与实验设计
这个实验源于一个非常实际的需求——如何高效审计一个积累了十几年的C++音视频基础库。这个项目包含26个模块、数万个源文件,是典型的"老同事走了新同事不敢动"的遗产代码。面对这种情况,传统的人工审计方式需要耗费大量时间,而使用AI辅助审计则成为了一种可行的替代方案。
我选择了当前最强大的两个编程AI——Claude Opus 4.6和GPT-5.3-Codex进行对比测试。实验设计采用了双盲交叉验证的方法:
- Agent-1(Claude Opus 4.6)执行全量扫描,逐模块分析代码结构、依赖关系和质量问题
- Agent-2(GPT-5.3-Codex)执行独立验证,在不看Agent-1结论的前提下对同一批模块做审计
为了量化评估结果,我设计了一个四级判决体系:
- 🟢 核心基石:质量可靠,可直接作为新架构基础
- 🔵 提纯合并:有价值但冗余,需要提取核心逻辑
- 🟡 重塑提取:部分可用,需大幅改造
- 🔴 彻底淘汰:不值得修复,需用现代方案替代
2. 审计结果对比分析
2.1 一致率统计
26个模块中,两个AI给出完全相同判决的只有10个,一致率仅为38.5%。这个结果远低于我的预期,说明不同AI模型在代码审计上的判断存在显著差异。
更令人惊讶的是分歧的规律性:所有16个分歧案例中,Codex的判决都比Claude更严格,没有一次例外。具体表现为:
- Claude判定为"核心基石"的13个模块中,Codex只认可2个
- Claude认为"提纯合并"的11个模块,Codex有5个降级为"重塑提取"
- 两个AI对"彻底淘汰"的判定完全一致(都是0个)
2.2 审计视角差异
通过分析分歧模块,我发现两个AI的审计视角存在本质区别:
Claude更像一个项目经理:
- 关注功能覆盖度:接口是否声明?功能是否实现?能否正常运行?
- 优点:快速建立项目全景认知
- 缺点:容易忽略实现细节问题
Codex则像一个严格的Code Review专家:
- 关注实现质量:边界条件处理?资源管理?API过时风险?
- 优点:能发现深层次隐患
- 缺点:可能过度严格,增加重构成本
2.3 关键问题发现
最值得关注的是Codex独立发现的13个关键问题,这些问题Claude完全没有提及。几个典型案例:
-
mp4_parser模块:
- 问题:宽高字段写入错误,指针跳转多了4字节
- 后果:生成的MP4文件在严格解析器上会显示错误尺寸
- Claude评价:"MP4封装模块功能完整"
-
video_encrypt模块:
- 问题:仅使用4字节XOR的"伪加密",含空指针解引用风险
- 后果:安全性形同虚设,且存在崩溃风险
- Claude评价:"视频加密模块,功能可用,建议优化"
-
protocol_gb28181模块:
- 问题:Server和Client代码60%重复,典型的God Class
- 后果:修改一处可能引发多处回归Bug
- Claude评价:"协议支持完善,是核心基石"
3. 技术实现细节
3.1 审计流程设计
为了实现有效的交叉审计,我开发了一个repo-scan工具,主要功能包括:
- 代码解析:提取模块边界、依赖关系
- 问题检测:静态分析常见编码问题
- AI接口:标准化与Claude/Codex的交互
- 报告生成:可视化对比审计结果
关键的技术挑战在于:
- 处理大型代码库的内存占用问题
- 保持AI上下文的一致性(特别是对于Codex的256K窗口)
- 标准化两个AI的输出格式以便对比
3.2 提示词工程
有效的提示词设计对审计质量至关重要。我的提示词框架包含:
text复制【角色设定】
你是一个资深C++架构师,正在审计一个音视频基础库。
【任务说明】
1. 分析模块的架构质量
2. 评估代码实现风险
3. 给出四级判决建议
【输出要求】
- 按模块分别输出
- 每个判决必须附带具体依据
- 发现的问题需标明代码位置
针对两个AI的特性差异,我还做了针对性优化:
- 对Claude:强调"从架构师视角看整体设计"
- 对Codex:提示"像Code Review一样检查每处实现"
4. 实践建议与经验总结
4.1 审计策略优化
基于这次实验,我总结出以下实践建议:
-
双模型交叉验证:
- 先用Claude快速建立整体认知
- 再用Codex深度检查关键模块
- 对分歧点进行人工复核
-
问题分类处理:
- 架构问题(如God Class):优先交给Claude识别
- 实现缺陷(如空指针):依赖Codex发现
-
结果可信度评估:
- 两个AI一致认可:可信度高
- 结论分歧:需要人工复核
- 单个AI单独报告的问题:需谨慎验证
4.2 常见问题排查
在实际使用中可能会遇到的一些问题及解决方案:
-
AI漏报问题:
- 原因:提示词不够具体
- 解决:增加问题类型示例
-
误报过多:
- 原因:审计标准过于严格
- 解决:调整判决阈值
-
上下文丢失:
- 原因:代码量超出窗口限制
- 解决:分模块分批处理
4.3 性能优化技巧
对于大型代码库审计,这些技巧可以提高效率:
-
预处理:
- 使用ctags等工具建立符号索引
- 提取关键接口定义
-
分批处理:
- 按模块依赖关系确定审计顺序
- 优先审计基础模块
-
缓存机制:
- 保存中间分析结果
- 避免重复分析未修改代码
5. 工具链与生态系统
5.1 相关工具对比
除了Claude和Codex,其他值得关注的代码审计工具:
| 工具 | 优势 | 局限性 | 适用场景 |
|---|---|---|---|
| SonarQube | 规则完善,集成CI | 静态分析为主 | 日常质量门禁 |
| Semgrep | 自定义规则灵活 | 需要规则开发 | 特定问题筛查 |
| CodeQL | 深度数据流分析 | 学习曲线陡峭 | 安全漏洞挖掘 |
5.2 成本效益分析
从投入产出比考虑:
-
纯人工审计:
- 成本:约3人月/万行
- 优势:结果可靠
- 劣势:耗时长,成本高
-
AI辅助审计:
- 成本:约0.5人月/万行
- 优势:速度快,成本低
- 劣势:需要人工验证
-
混合模式:
- AI初步筛查 + 人工重点复核
- 平衡效率与质量的最佳选择
6. 未来改进方向
基于这次实验的经验,我认为AI代码审计还可以在以下方面改进:
-
领域知识增强:
- 针对音视频等特定领域优化
- 内置行业最佳实践
-
交互式审计:
- 支持追问和澄清
- 实现审计过程可追溯
-
结果可视化:
- 问题热力图
- 架构关系图
-
基准测试体系:
- 建立代码审计评估数据集
- 量化不同AI的审计能力
这次实验最深刻的体会是:AI代码审计不是要取代人工,而是帮我们更高效地发现问题。就像用Claude和Codex做交叉验证,本质上是在用不同视角弥补各自的盲区。对于重要的代码审计,这种多角度验证的方法值得推荐。
