💻 computer science

Can LLMs Produce Better Object-Oriented Designs than Human-Involved Development?

本研究比较了大语言模型前、大语言模型后及纯大语言模型生成的 Java 项目的面向对象设计质量，发现尽管大语言模型生成的代码复杂度较低且代码异味更少，但其往往存在过度简化和职责划分薄弱的问题，这凸显了在分解设计时持续需要人工指导的必要性。

原作者： Zushuai Zhang, Elliott Wen, Ewan Tempero

发布于 2026-05-20

📖 1 分钟阅读☕ 轻松阅读

原作者： Zushuai Zhang, Elliott Wen, Ewan Tempero

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你是一位受命建造一座复杂房屋的大师建筑师。你有三支不同的团队可供选择来负责实际施工：

传统卫队（PreAI）：经验丰富的建造者，从未使用过计算机助手。他们自己绘制蓝图，并手工完成所有工作。
混合团队（PostAI）：经验丰富的建造者，如今拥有了强大的计算机助手。他们仍然负责绘制蓝图和做出重大决策，但让计算机协助他们砌砖和切割木材。
机器人团队（PureAI）：一支由先进机器人组成的团队，它们只需接收关于房屋的简单口头描述，即可从零开始、端到端地建造整栋房屋，无需人类触碰任何工具。

本文提出了一个简单的问题：哪支团队建造的房屋最好？ 具体来说，“机器人团队”所创造的设计是否与人类团队一样好，甚至更好？

实验

研究人员利用一款经典的棋盘游戏Kalah（卡勒）设置了一场“建造挑战”。他们要求三组人员编写一个用于玩该游戏的 Java 软件程序：

第一组（PreAI）：2021 年的学生（在 AI 编程工具普及之前）。
第二组（PostAI）：2024 年的学生（在 AI 工具普及之后）。
第三组（PureAI）：将同样的任务交给三个不同的一流 AI 模型，由它们完全自主生成代码。

他们不仅检查游戏是否能运行，还评估了设计的质量。这就像检查房屋是否具有合理的布局、房间尺寸是否恰当，以及管道是否杂乱无章。

研究发现

1. 机器人团队建造了“更小”的房屋，但它们过于简单

PureAI（机器人） 团队编写的代码在表面上看起来非常整洁。

好消息：它们的代码“异味”（如混乱代码等不良习惯）更少，整体复杂性似乎更低。这就像一栋墙壁很少、空间非常开放的房子。
坏消息：这种简单性实际上是个问题。机器人过度简化了设计。它们没有分别为“玩家”、“棋盘”和“坑洞”（游戏中的洞）建造独立的房间，而是经常将所有内容合并成一两个巨大的房间。
比喻：想象一栋房子，厨房、卧室和浴室都只是一个没有门的大房间。它非常简单且易于清洁（低复杂性），但极不适合居住，因为你无法将不同活动区分开来（“职责分离”不佳）。机器人忽略了使系统易于理解的至关重要的“抽象”（即 distinct 的概念）。

2. 混合团队（PostAI）开始表现得像机器人

2024 年的学生（使用 AI 助手）所构建的系统并不像 PureAI 团队那样“机器人化”，但他们比 2021 年的学生更接近机器人。

他们的设计也变得过于简单，缺少了 2021 年学生所包含的一些 distinct“房间”（概念）。
然而，与机器人不同，混合团队的代码实际上比老派学生产生了更多的混乱习惯（代码异味）。似乎当人类尝试修复或编辑机器人生成的代码时，他们有时会在局部引入新的混乱，即使整体结构看起来很简单。

3. “提示词”很重要，但它不是魔杖

研究人员尝试给机器人更具体的指令，例如“确保你为‘玩家’和‘棋盘’分别创建独立的类”。

结果：当指令更具体时，机器人在创建独立的“房间”（概念）方面做得更好。
局限性：即使拥有最好的指令，机器人所构建的房屋质量仍未能完全达到人类设计的水平。它们仍然倾向于过度简化。

核心结论

机器人擅长砌砖，但人类仍需负责绘制蓝图。

该论文得出结论：虽然 AI 能够编写出可运行且外观整洁的代码，但它在面向对象设计的宏观层面上存在困难。它倾向于将所有内容混为一谈以追求“简单”，这实际上使得软件在后期更难维护，因为系统的 distinct 部分被丢失了。

PureAI（机器人）：擅长避免小错误，但不擅长理解宏观结构。
PostAI（使用 AI 的人类）：开始失去部分结构深度，并且在此过程中有时会使代码变得更加混乱。
教训：如果你使用 AI 编写软件，你必须充当建筑师。你需要明确告诉 AI 如何将问题分解为 distinct 的部分（分解），以及每个部分负责什么。如果你只是说“建造一个游戏”，AI 将构建一个混乱且过度简化的版本，它看起来整洁，但后期难以修复。

技术摘要：大语言模型能否产生优于人类参与开发的面向对象设计？

问题陈述

尽管大语言模型（LLM）生成代码的能力日益增强，但其在多类项目中生成高质量**面向对象设计（OOD）**的能力仍不明确。先前的研究主要集中在：

问题层面（单个方法或类）的功能正确性，而非项目层面的架构。
前 LLM 基线，未能考虑 LLM 辅助的人类开发（PostAI）所产生的影响。
高层工件（例如 UML 图），而非已实现代码的可维护性和结构质量。

本研究旨在填补以下空白：理解由 LLM 端到端生成的项目（PureAI）中的 OOD 质量，与 LLM 广泛采用之前（PreAI）和之后（PostAI）由人类参与生成的项目相比有何差异。

方法论

作者开展了一项对比案例研究，使用研究生 Java 作业：实现卡拉赫（Kalah）棋盘游戏。该研究分析了三个作者身份条件下的 11 个数据集：

PreAI（人类参与，前 LLM）： 2021 年 3 月的 93 份提交，早于主要 LLM 编程助手的公开发布。
PostAI（人类参与，后 LLM）： 2024 年 8 月的 57 份提交，在 LLM 工具成为主流之后。
PureAI（LLM 生成）： 使用三个当代模型（gpt-5.4、gemini-2.5-pro、gemini-3.1-pro-preview）进行的 810 多次生成运行，跨越三种提示变体，其 OOD 指导的具体性各不相同（无、宽泛、具体）。仅保留通过所有 19 个功能测试用例（最多经过五次修复迭代）的运行结果。

评估指标

本研究采用多维评估框架：

OOD 指标： 13 个捕捉结构特征的指标，包括加权方法数（WMC）、类间耦合（CBO）、方法缺乏内聚性（LCOM）、继承树深度（DIT）、类数量（#Cl）和代码行数（LOC）。
代码异味密度： 检测到的 30 种异味类型（11 种方法级，19 种类级）的项目级密度，按规模（KLOC）归一化。
领域建模：
- 概念表示： 六个关键领域概念（Board、Game、Player、Pit、House、Store）是否被显式建模为类。
- 运行时一致性： 实例化对象的数量是否与领域概念隐含的要求相匹配。

统计分析

比较使用了 Mann–Whitney U 检验，针对非二元指标使用 Cliff's delta（ $\delta$ ）计算效应量；针对二元指标使用卡方检验/Fisher 精确检验及优势比（OR）。结果使用 Benjamini–Hochberg 程序进行多重比较校正。

主要贡献

首次对比分析： 这是第一项在项目层面设置中比较 PreAI、PostAI 和 PureAI 条件下 OOD 质量的研究。
多维评估： 本研究结合了定量 OOD 指标、代码异味分析和基于需求的领域建模，提供了设计质量的全景视图。
关于过度简化的实证证据： 论文提供了证据表明，虽然 LLM 生成的代码通常看起来更“干净”（异味密度更低），但这通常与过度简化（缺失抽象、职责分离较弱）相关。
PostAI 趋势洞察： 研究表明，LLM 时代人类参与的项目（PostAI）在设计趋势上比 PreAI 更接近 PureAI（简化），但在代码异味方面并未出现同样的减少。

结果

RQ1：PreAI、PostAI 和 PureAI 之间的差异

结构简化与过度简化： 与人类项目相比，PureAI 项目通常表现出更少的类、更低的总复杂度、规模和耦合度。然而，这种“简化”与过度简化相关：
- 每个类的平均复杂度和最大百分比复杂度/耦合度更高（负担集中在更少的类中）。
- 内聚性较低（LCOM 较高），因为单个类通常代表多个领域概念。
- 显式表示的领域概念较少（缺失抽象）。
代码异味： 与人类参与的项目相比，PureAI 项目的代码异味密度（方法级和类级）显著更低。
PostAI 趋同： 在许多 OOD 指标上，PostAI 项目在统计上比 PreAI 更接近 PureAI，表现出类似的简化和缺失领域概念的倾向。然而，与 PureAI 不同，PostAI 项目的代码异味密度高于PreAI，特别是在方法级。
运行时一致性： 一旦领域概念被表示，PureAI 项目在运行时通常比人类项目更有可能保持一致性。

RQ2：PureAI 中提示具体性的影响

指导的影响： 增加提示的具体性（从无 $\to$ $\to$ 宽泛 $\to$ $\to$ 具体）通常会导致：
- 更多的类以及更高的总复杂度/规模/耦合度（远离过度简化）。
- 每个类的平均复杂度和最大百分比复杂度/耦合度降低。
- 整体和方法级代码异味密度降低。
- 领域概念的表示得到改善（尽管效果因模型而异）。
局限性： 更具体的提示并不能完全缩小与人类参与项目之间的差距。对于某些模型（例如 O54），将具体性从宽泛增加到具体所带来的额外改善有限。

意义与启示

论文得出结论，虽然 LLM 能够有效处理实现细节（生成异味更少且运行时一致性高的代码），但在缺乏明确人类指导的情况下，它们在面向对象分解和职责分配方面存在困难。

过度简化风险： PureAI 项目通常看起来更简单且异味更少，但这掩盖了缺乏适当抽象和职责分离的问题，这可能损害长期的可维护性。
PostAI 警示： LLM 工具的出现可能导致人类开发者产生模仿 LLM 过度简化（缺失概念）的设计，同时引入新的局部问题（方法级异味），从而可能抵消生产力提升。
人机回环的必要性： 关于高层分解和领域建模的适当人类指导仍然至关重要。仅依赖通用甚至具体的 OOD 提示不足以实现可与人类相媲美的设计质量。
审查策略： 在 LLM 辅助环境中的代码审查应显式检查缺失的领域概念和过度简化的结构，而不仅仅是功能正确性或局部代码异味。

该研究表明，在 OOD 中利用 LLM 最有效的方式是：由理解领域和预期架构的人类专家定义结构，然后利用 LLM 在该结构内进行实现。

实验