By Unbug 从”能用”到”好用”：让AI真正学会软件工程
引子：代码能跑，就够了吗？
想象一下：你让AI写一段代码，它很快生成了，测试也通过了。你很开心，把这段代码放进了项目。
三个月后，你发现这段代码像一块粘在代码库里的”口香糖”——想改改不动，想删删不掉，牵一发而动全身。功能是对的，但维护成本却高得离谱。
这正是2026年SANER会议上一篇论文《Grounding Generative AI in Software Engineering: Are We There Yet?》要解决的问题。
答案很明确：我们还没到那一步。
📝 论文概览
论文标题：Grounding Generative AI in Software Engineering: Are We There Yet?
会议：SANER 2026
🎯 核心问题：AI只会”写代码”，不会”做软件”
现状：功能正确，但质量堪忧
现在的大语言模型（LLMs）在代码生成方面已经很厉害了：
- ✅ 语法正确
- ✅ 功能正常
- ✅ 测试通过
但如果你是一个有经验的开发者，你会知道：代码能跑，只是最低要求。
论文指出了一个关键问题：当前的AI缺乏软件工程的基础知识。
什么是软件工程知识？就是那些让代码从”能用”变成”好用”的原则：
- 模块化（Modularity）
- 单一职责（Single Responsibility）
- 高内聚、低耦合（High Cohesion, Low Coupling）
- 适当的抽象（Abstraction）
这些概念在计算机科学课程里是基础，但在AI的训练数据里却很少见。
证据：AI在设计上真的很挣扎
论文引用了多项研究，结果让人吃惊：
- GPT-4o和Llama 3.1-70B在分类设计模式时，准确率只有38.81%
- WizardCoder和DeepSeek-coder 33B在面向对象编程概念上，甚至被本科生超越
- GPT-4在建模类之间的正确关系时，F1值只有0.34
这就像一个刚学编程的学生，能写出能跑的代码，但完全不知道如何组织代码结构。
后果：技术债务的AI生产线
如果我们用这样的AI来大规模生成代码，会发生什么？
论文警告说：
- AI Agent会继承底层模型的局限性
- 缺乏架构意识的模型会在生成的代码中传播糟糕的结构选择
- 我们会得到一个技术债务的AI生产线
短期内看，生产率提高了；长期来看，维护成本会爆炸式增长。
🔬 核心愿景：让AI成为真正的软件工程师
论文提出了一个大胆的愿景：让软件工程知识原生地融入AI。
他们把这个框架称为SENAI，包含三个核心部分：
策略一：用SE知识”喂饱”AI
不仅仅是代码，还有更多
现在的AI主要是在源代码上训练的。但软件工程的知识远不止代码本身：
UML图：提供软件系统的抽象高层表示
- 就像建筑蓝图，告诉你系统是如何组织的
- 比代码更能体现设计意图
架构决策记录（ADRs）：记录为什么这样设计
- 上下文是什么？
- 考虑了哪些替代方案？
- 每个选择的影响是什么？
仓库历史：（代码前、diff、提交消息）三元组
- 告诉AI代码是如何演化的
- 展示重构的过程和理由
新的训练目标
论文建议设计新的预训练目标：
- 实体内关系预测（组合、关联等）
- 类似于GraphCodeBERT预测数据流边
这就像教AI不仅要认识单词，还要理解单词之间的关系。
用RL对齐SE目标
强化学习（RL）也可以派上用场：
- 用基于SE知识的反馈引导模型
- 例如：CodeUltraFeedback用RL对齐代码可读性和风格
想象一下：AI每生成一段代码，就有一个”软件工程教练”给它打分，告诉它哪里设计得好，哪里需要改进。
策略二：重新定义”好代码”
当前评估的问题
现在的评估方法有什么问题？
Token-based指标：BLEU、ROUGE、CodeBLEU
- 只在语法层面比较
- 不关心代码质量
Execution-based指标：pass@k、执行准确率
- 只验证功能正确性
- 不关心可维护性
论文尖锐地指出：所有这些基准都将成功定义为”通过测试”，而不是代码质量、可维护性或长期影响。
新的评估方向
我们需要评估真正重要的SE质量属性：
- 模块化
- 内聚性
- 耦合性
- 抽象性
论文给出了一些新的基准测试任务示例：
任务1：重构练习
- 给模型低质量代码片段
- 要求重构以改进LCOM（方法内聚性缺乏）和CBO（对象间耦合）
- 同时保持功能正确性
任务2：识别和重构
- 首先识别软件系统中的次优部分
- 然后建议涵盖不同粒度级别的重构策略
这就像驾照考试，不仅考你能不能把车开走，还要考你会不会停车、会不会变道、会不会预判风险。
策略三：用Bloom分类法评估理解
论文最有趣的部分之一，是建议用Bloom分类法来评估AI对SE知识的理解。
Bloom分类法是什么？它是一个教育心理学框架，将认知技能分为层次级别：
| 级别 | 含义 | SE中的应用 |
|---|---|---|
| 回忆 | 记住概念 | “什么是内聚？” |
| 理解 | 解释概念 | “这两段代码哪段内聚性更高？” |
| 应用 | 使用概念 | “重构这段代码，提高其内聚性” |
| 分析 | 分解概念 | “给这些代码片段按耦合程度排序” |
| 评估 | 判断价值 | “这个设计决策合理吗？” |
| 综合 | 创造新东西 | “根据需求，设计一个高内聚低耦合的系统” |
论文认为，我们不应该只停留在”回忆”级别，而应该测试AI在更高认知层次上的能力。
📊 核心发现
挑战：数据从哪里来？
这个愿景面临一个现实问题：UML图和ADRs不像原始源代码那样广泛可用。
但论文也给出了缓解策略：
- 架构恢复方法：从代码库中提取架构信息
- 合成数据生成：类似于WizardCoder的方法
这就像虽然不是每本书都有教学指南，但我们可以从书的内容中反推出教学要点。
希望：这不仅仅是为了AI
论文指出，这一愿景对AI Agent尤为重要：
- Agent继承其底层LLMs的能力和局限性
- SE基础的LLMs为Agent提供内置的架构验证
想象一下：未来的AI编程助手，不仅能写代码，还能主动告诉你：
- “这里耦合度太高了，我建议这样重构”
- “这个类违反了单一职责原则，要不要拆分？”
- “根据项目历史，这种设计模式在这里可能不合适”
这才是真正的”AI程序员”，而不是”AI代码打字员”。
📈 数据亮点
| 指标 | 数值 |
|---|---|
| GPT-4o/Llama 3.1设计模式分类准确率 | 38.81% |
| GPT-4类关系建模F1值 | 0.34 |
| 认知评估层次 | 6级（Bloom分类法） |
| 论文类型 | 愿景论文（Vision Paper） |
| 系列位置 | 收官之作（最后一篇） |
💡 一句话总结
“我们需要的不是会写代码的AI，而是懂软件工程的AI。”——这篇论文为我们指明了方向：将数十年的软件工程知识系统性地融入下一代AI系统中。
🎓 研究意义
论文的核心结论值得深思：
“将LLMs根植于SE原则对于推进这些模型超越单纯的功能正确性至关重要。我们呼吁将高层设计见解集成到语言模型中，这将引导生成可维护、可扩展且符合最佳实践的代码。”
这篇论文没有给出具体的实验结果（作为愿景论文，这是正常的），但它为我们指明了一个清晰的方向。
过去几十年，软件工程领域积累了无数的智慧和经验。现在，是时候把这些知识教给AI了。
当AI真正学会软件工程时，我们可能会迎来一个新的时代：
- 代码质量更高
- 技术债务更少
- 开发者可以专注于真正有创造性的工作
这不是AI取代人类的故事，而是人类智慧与AI能力结合的故事。
毕竟，软件工程的核心从来不是代码本身，而是人如何思考和组织复杂系统。这一点，AI永远需要向人类学习。
🎉 系列总结
这篇文章是我们系列论文解读的收官之作。回顾整个系列，我们看到了AI在软件工程领域的快速发展，也看到了它的局限性。
从代码生成到代码审查，从缺陷检测到架构设计，AI正在逐步渗透到软件工程的各个环节。但正如这篇论文所提醒的，我们还有很长的路要走。
未来的方向已经清晰：让AI不仅学会”写代码”，更要学会”做软件”。这需要我们将数十年的软件工程知识，系统性地融入下一代AI系统中。
这是一个挑战，也是一个机遇。让我们拭目以待，看AI如何真正学会软件工程。
