团队成员：
研究背景与意义： C++ 作为高性能工业系统的主力语言，其手动内存管理和复杂的并发机制极易引发严重故障（如内存泄漏等）。传统的静态代码检查工具（SAST）仅能"发现问题"，而人工"修复问题"成本高昂且极易引入二次错误。本项目旨在验证生成式人工智能 (AIGC) 是否具备高质量、高稳定性地自动修复这些危险工程缺陷的能力，为软件工程的智能化演进（AI4SE）提供量化实证。
cpp-001/004：遗漏 delete
或异常分支导致的未释放。AI 需要引入对象生命周期管理(RAII/智能指针)。
cpp-003/005：滥用宏命令与"上帝函数"。考验 AI 的上下文理解、函数拆分与 C++ 现代特性(constexpr/inline)运用。
cpp-006：多线程环境下的不安全访问。要求 AI 正确引入
std::mutex、std::lock_guard 或原子操作。
在对工程代码进行修复时，我们面临一个核心矛盾：代码隐私保护 VS 修复质量。因此，本项目未局限于课内基础模型，而是引入了产业界最前沿的研发模式进行对比评估：
选型逻辑： 依托 Gemini 3.1 Pro (Preview) 的超大上下文窗口与复杂代码解析能力，在 SWE-bench 等公开基准中表现领先（项目制作时），作为本实验的"高质量重构基准天花板"。
选型逻辑： 选用工业界开源小模型中的标杆 Qwen 3.5 9b 。本地部署开销较低，实现100% 本地驱动llm完成安全修复，验证小参数模型在 C++ 工程中的实战水平。
| 测评维度 (Benchmark) | Qwen-3.5-9b LM studio (本地) |
Gemini-3.1-pro-preview Github Copilot(云端) |
对比结果 | 备注信息 |
|---|---|---|---|---|
| SWE-bench Verified 软件工程代码修复 | 69.2% | 71.4% | Gemini 略优 (+2.2%) | 官方评估与社区框架数据 数据时效: 2026-04 |
| Terminal-Bench v2.0 命令行与终端交互 | N/A | 77.5% | *Gemini as Agent (Antigravity) 开源模型无同类Agent框架 | 百亿参数级可能难以维持长规划 数据时效: 2026-04 |
| GPQA Diamond 高难度理科专家问答 | 81.7% | 94.0% | Gemini 大幅领先 (+12.3%) | 涵盖 5-shot CoT 模式 数据时效: 2026-04 |
鉴于大语言模型本身已具备海量代码预训练基础（Pre-training），本项目的研发重心不在于重新耗费大量时间精力训练，而是如何约束和控制模型输出正确的工程架构。我们通过严格的提示词设计（指定 C++17 标准、禁用宏、采用 RAII），配合完全自动化的 Python / Batch 脚本实现了半自动式的评估流水线。
run_refactor_lmstudio.pyevaluate_run.py01 内存泄漏缺陷任务 为例，直观展示模型如何从修复 C++ 工程漏洞
void process_data() {
// 【漏洞点】手工在堆上分配了内存，极不安全
int* data = new int[100];
if (check_error()) {
// 【致命陷阱】早期的 return 会直接跳过末尾的 delete 语句
// 在该场景中会导致非常严重的内存泄漏耗尽业务资源！
return;
}
// 如果发生异常抛出，此处释放逻辑同样也不会被执行到。
delete[] data;
}
#include <memory> // AI 自主感知缺失库并提前包含关联项
void process_data() {
// 【架构升级】摒弃裸指针，使用 C++17 推荐的 make_unique 对资源接管
std::unique_ptr<int[]> data = std::make_unique<int[]>(100);
if (check_error()) {
// 【防御成功】即使触发退出机制或是出现未知的内部崩溃，
// 出了此作用域，编译器都会保证调用 unique_ptr 析构来释放内存！
return;
}
}两模型均 100% 通过 C++17 编译检查。运行时验证则拉开差距：Copilot (Gemini 3.1 Pro) 以 100% (6/6) 全部正常运行通过；LM Studio (Qwen 3.5 9b) 为 83.3% (5/6)，在并发缺陷(data_race)任务上输出为空导致失败。
Qwen 3.5 9b 的重构更激进（平均改动 58%），倾向"推倒重写"；Gemini 3.1 Pro 更保守（平均改动 37%），倾向"精准微调"。高改动率在复杂大型项目中更加可能导致意料之外的连锁问题或代码质量问题。
| 维重量化指标 | LM Studio (本地化部署) | Copilot (云端产品) | 工程维度的解释 |
|---|---|---|---|
| 运行时行为验证 | 83.3% (5/6 通过) 并发任务输出为空导致失败 |
100% (6/6 全部通过) | 仅编译通过不足以保证代码正确——空文件、死循环、崩溃等均需运行时测试捕获。 |
| 可观测成本 (Tokens/Request) | 总消耗 9242 Tokens | 一次Request (token暂未给出) | 尽管计费标准类似，但云端模型在调度过程中不透明，可能因降智策略或后端干预导致输出不可预期；本地模型则完全可控、可复现。 |
| 工程推理时延 | ~ 75,745 ms (受限于本地算力) | 延迟受 MCP 中转影响 | 揭示了高本地算力要求可能是本地模型在实际工程中部署面临的一方面阻碍。 |
选取 C++ 开发中 6 类典型工程缺陷作为研究对象；设计"云端商业模型 (Copilot / Gemini 3.1 Pro) vs 本地私有化模型 (LM Studio / Qwen 3.5 9b)"双通道对比方案，兼顾修复质量与代码隐私保护。
基于 Prompt Engineering (In-Context Learning) 实现推理调度；构建 5 步自动化流水线：语料映射 → 批量推理 → 编译+运行时双重验证 → 归一化计分 → 报告交付。全流程一键可复现。
构建多维评价体系：编译通过率 + 运行时通过率 + 重构深度 + 代码质量静态检测 + Token/时延成本。核心结论：本地小模型在多数场景可平替云端，但在并发等复杂缺陷上仍有显著差距（运行时通过率 83.3% vs 100%）。
汇报结束 · 感谢各位评委与同学聆听