Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects

该研究提出特征驱动的人机协同（FD-HITL）框架，利用 Cursor 生成了 10 个大型软件项目，发现虽然其功能正确率高达 91%，但生成的代码仍普遍存在违反单一职责、关注点分离和 DRY 等设计原则的严重设计缺陷，可能给系统的长期可维护性和可扩展性带来风险。

要点

这篇论文就像是一份**“AI 厨师”的体检报告**。

想象一下，你雇佣了一位名叫 Cursor 的超级 AI 厨师。它不仅能切菜（写代码片段），现在还能根据你给的菜单，独立做出一桌完整的宴席（生成整个大型软件项目）。

研究人员想知道：这位 AI 厨师真的能做大餐吗？它做出来的菜，除了能吃饱（功能正确），味道和摆盘（设计质量）怎么样？

为了回答这个问题，研究人员给 Cursor 下了 10 道复杂的“大菜”订单（比如做一个社交 APP、一个电商网站、一个学习工具等），并发明了一套**“人类主厨指导法”**（FD-HITL 框架）来指挥它。这套方法不是让 AI 瞎忙，而是像人类主厨一样，先定菜单、再分步骤、最后检查每一道菜。

以下是这篇论文的通俗解读：

1. 实验结果：AI 能做大餐，但“卖相”有待改进

• 功能很强大（能吃饱）：
  在人类的指导下，Cursor 成功做出了 10 个大型项目。这些项目平均有 1.7 万行代码，包含 114 个文件。

  • 比喻： 就像 AI 厨师真的端上了 10 桌满汉全席，而且客人（用户）尝了之后发现，91% 的菜都能吃，味道也对（功能正确）。
  • 结论： AI 确实有能力生成大型软件，不再是只能写几行代码的小工具了。

• 设计有隐患（摆盘乱、食材浪费）：
  虽然菜能吃，但研究人员用两台“专业质检机器”（CodeScene 和 SonarQube）去检查，发现了一堆设计问题。

  • 比喻： 虽然菜熟了，但有的菜里重复放了三次盐（代码重复），有的盘子太大装不下（方法太长），有的切菜手法太乱（逻辑太复杂），还有的没给过敏的人留提示（无障碍问题）。

2. 发现了哪些“厨房事故”？（主要设计问题）

研究人员把这些问题分成了几类，就像厨房里的常见事故：

1. 重复劳动（代码重复）：

   • 现象： AI 为了省事，把同样的代码复制粘贴了好多遍。
   • 比喻： 就像厨师为了做 10 份炒饭，把“加盐、加葱、加蛋”的步骤写了 10 遍，而不是写一个通用的“炒饭公式”。以后想改盐量，得改 10 个地方，累死人。
   • 违反原则： “不要重复自己”（DRY）。

2. 贪大求全（方法太长/太复杂）：

   • 现象： 一个函数（方法）里塞了太多功能，代码长达几百行。
   • 比喻： 就像让一个厨师同时负责切菜、炒菜、摆盘、洗碗和收银。结果就是，这道菜做得慢，而且一旦收银出错，整个厨房都乱套了。
   • 违反原则： “单一职责原则”（SRP）——一个厨师只该专注做一件事。

3. 逻辑迷宫（代码复杂）：

   • 现象： 代码里充满了层层嵌套的“如果...那么..."，像迷宫一样。
   • 比喻： 就像菜谱上写着：“如果客人是左撇子且今天下雨且心情不好，就加糖；否则如果...否则..."。这种菜谱，换个人根本看不懂，稍微改一下就容易出错。
   • 违反原则： “保持简单”（KISS）。

4. 框架违规（不守规矩）：

   • 现象： AI 用的技术（比如 React 或 Spring Boot）有特定的最佳实践，但 AI 经常忽略。
   • 比喻： 就像在法式餐厅里用中式炒锅的规矩来炒菜，虽然能熟，但行家里手一看就觉得“不地道”，以后维护起来很麻烦。

5. 忽视特殊人群（无障碍问题）：

   • 现象： 界面设计没考虑到视障人士或键盘操作者。
   • 比喻： 餐厅装修得很漂亮，但没有给坐轮椅的人留通道，或者盲文菜单没写清楚。

3. 为什么会出现这些问题？

研究发现，如果让 AI 像“发疯”一样（Vibe Coding，即不加思考地快速生成），它很容易写出垃圾代码。

成功的秘诀是“人类主厨指导法”（FD-HITL）：

• 不要一口吃成胖子： 不要直接说“给我做一个淘宝”，而是要把任务拆解成“先做登录”、“再做商品列表”、“最后做支付”。
• 步步为营： 每做完一个小功能，人类就要检查一遍，确认没问题了，再让 AI 做下一个。
• 比喻： 就像教小孩搭积木，你不能说“搭个城堡”，而是要说“先搭地基，再搭第一层墙”。人类负责规划和检查，AI 负责执行具体的砌砖工作。

4. 给普通开发者的建议（避坑指南）

这篇论文给那些想用 AI 写代码的人提了几个醒：

1. 别只盯着“能不能跑”： 代码能跑通只是第一步，代码好不好维护更重要。AI 生成的代码往往“能跑但很难改”。
2. 人类必须当“总指挥”： 不要完全甩手给 AI。人类要花更多时间在前期设计和需求拆解上，把具体的代码生成交给 AI。
3. 先后端，后前端： 先让 AI 把数据库和后台逻辑跑通，再让它做界面。这样如果逻辑错了，不会把界面搞得一团糟。
4. 每步都要检查： 每生成一个功能，就人工测试一下，发现问题马上让 AI 改，不要等最后再一起修。

总结

AI 厨师（Cursor）现在是个非常厉害的“执行者”，能帮你快速做出大菜。
但是，它还不是一个完美的“主厨”。 它做出来的菜，如果没人盯着，可能会盐放多了、摆盘乱了、或者没考虑过敏源。

结论： AI 可以极大地提高开发速度，但它不能替代人类工程师的设计思维和质量把控。未来的软件开发模式应该是：人类负责“想”和“管”，AI 负责“做”和“写”。

技术摘要

这是一份关于论文《Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects》（超越功能正确性：AI IDE 生成的大型项目中的设计问题）的详细技术总结。

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）的发展，新一代 AI 编程工具（如 Cursor、Claude Code 等）已具备代理能力（Agentic Capabilities），能够在项目上下文中生成代码，而不仅仅是生成代码片段。然而，现有的研究存在以下缺口：

• 缺乏大规模项目生成的实证研究：大多数现有研究仅关注简单的、小规模的项目生成，缺乏对工业级规模（如数千行代码、多架构组件）项目的评估。
• 忽视设计质量问题：现有研究多关注代码的功能正确性、安全性或片段级质量，缺乏对项目级代码设计质量（如可维护性、可扩展性、架构原则遵循情况）的深入评估。
• 开发模式风险：开发者常采用“Vibe Coding"（即不深入理解输出、仅追求速度的提示词模式），这可能导致生成的代码存在严重的设计缺陷。

核心研究问题 (RQs)：

1. Cursor 能在多大程度上生成大型软件项目？
2. Cursor 生成的大型项目中存在哪些设计问题？

2. 方法论 (Methodology)

为了回答上述问题，作者进行了一项实证研究，主要包含以下阶段：

2.1 提出 FD-HITL 框架

作者发现随机提示（Ad hoc prompting）无法有效生成大型项目，因此提出了**“特征驱动的人机回环”（Feature-Driven Human-In-The-Loop, FD-HITL）**框架。该框架包含四个阶段：

1. 项目初始化：定义项目上下文，通过协作确定技术栈。
2. 需求与设计：生成 requirements.md（系统组件与详细需求）和 tasklist.md（按特征划分的增量开发路线图）。
3. 项目实现：
   • 先搭建项目骨架（后端/前端/数据库连接）。
   • 特征驱动循环：逐个处理 tasklist.md 中的特征。先完成后端和数据库任务并测试 API，再集成前端。
   • 持续的人工反馈与调试（利用终端错误、截图等辅助 Cursor 修复问题）。
4. 系统级审查与测试：全系统手动测试，修复逻辑错误和 UI 不一致问题。

2.2 数据生成

• 工具：Cursor Pro。
• 样本：生成了 10 个 大型项目，涵盖 Web 应用、移动应用和实用工具三个领域。
• 技术栈：包括 React, Spring Boot, Django, React Native, Vue.js, PHP (WordPress) 等。
• 筛选标准：每个项目至少包含 8,000 行代码 (LoC)，使用至少 3 种技术，具备复杂架构（如前后端分离）。
• 规模：平均每个项目约 16,965 LoC 和 114 个文件。

2.3 评估过程

1. 功能正确性评估：通过人工执行项目并对照需求文档进行验证。
2. 静态分析：使用两个业界标准的静态分析工具检测设计问题：
   • CodeScene：侧重于高层设计问题（如复杂度、重复代码）。
   • SonarQube：侧重于代码规范、安全漏洞及低层设计问题。
3. 人工过滤：手动检查并剔除了 SonarQube 识别出的 1,612 个误报（False Positives），最终保留有效问题进行分析。

3. 关键贡献 (Key Contributions)

1. FD-HITL 框架：提出了一套系统化的方法，指导开发者利用 AI IDE 生成大型、功能正确的项目，强调了需求分解和增量开发的重要性。
2. 大规模实证数据集 (DIinAGP)：发布了包含 10 个项目描述、对应生成的代码（总计约 17 万行代码）以及设计问题标注的开源数据集。
3. 设计问题分类与映射：通过定性和定量分析，将检测到的数千个设计问题归纳为多个类别，并映射到经典的设计原则（如 SRP, DRY, KISS, SoC）。
4. 实践建议：为从业者提供了关于如何有效使用 AI IDE 以避免设计缺陷的具体建议。

4. 研究结果 (Results)

4.1 功能正确性与规模 (RQ1)

• 生成能力：在 FD-HITL 框架辅助下，Cursor 能够成功生成功能完备的大型项目。
• 正确率：10 个项目的平均功能正确性得分为 91%（最高 96%，最低 85%）。
• 局限性：尽管功能基本可用，但仍有部分需求未完全实现或存在逻辑错误（如缺少“更新帖子”功能、富文本编辑器渲染问题）。

4.2 设计问题发现 (RQ2)

研究发现了大量的设计问题，表明生成的代码虽然“能跑”，但质量堪忧：

• 问题数量：
  • CodeScene 识别出 1,305 个问题（9 个类别）。
  • SonarQube 识别出 3,193 个有效问题（11 个类别）。
  • 两者重叠的关键问题为 133 个（均为严重级别，主要涉及代码复杂度）。
• 主要问题类别：
  1. 代码重复 (Code Duplication)：CodeScene 中最常见的问题（28.4%），违反 DRY 原则。
  2. 高代码复杂度 (Code Complexity)：包括复杂方法（Complex Method）、大方法（Large Method）、深层嵌套（Deep Nested Complexity）。违反 SRP 和 KISS 原则。
  3. 框架最佳实践违规 (Framework Best-Practice Violations)：SonarQube 中最常见（35.3%），如 React 的 Props 验证缺失、Spring Boot 的字段注入等。
  4. 异常处理问题 (Exception-Handling Issues)：捕获通用异常、空 catch 块等，违反 Fail Fast 原则。
  5. 可访问性问题 (Accessibility Issues)：前端 UI 缺乏标签关联、键盘导航支持不足。
  6. 设计原则违反：大量方法违反单一职责原则（SRP）和关注点分离（SoC）。
• 技术特异性：SonarQube 发现的问题中，59% 是特定于技术栈的（如 JavaScript/React, Java/Spring Boot, PHP 等）。

4.3 重叠分析

CodeScene 和 SonarQube 的重叠率较低（约 4%），但重叠部分均为**严重（Critical）**级别，主要集中在代码复杂度（如认知复杂度、循环复杂度）上，表明这些是 AI 生成代码中最核心的设计缺陷。

5. 意义与启示 (Significance & Implications)

5.1 对从业者的启示

• 不能仅依赖功能正确性：AI 生成的代码虽然能运行，但设计质量（可维护性、可扩展性）较差，可能成为技术债务。
• 人机协作模式：人类应专注于高层任务（需求细化、架构设计、特征分解），将低层实现交给 AI。
• 系统性流程：必须采用结构化流程（如 FD-HITL），避免“Vibe Coding"式的随意提示。
• 分阶段验证：先完成后端和 API 测试，再进行前端集成；每个特征生成后需进行黑盒测试。
• 明确非功能需求：在提示词中显式指定可访问性、设计原则等要求。

5.2 对研究者的启示

• 工具局限性：现有的静态分析工具在检测高层架构耦合方面仍有不足，未来需结合 LLM 辅助分析。
• 行为研究：需进一步研究开发者使用 AI IDE 的行为模式，以优化工具设计，防止过度依赖。
• 框架扩展：未来的框架应引入显式的设计约束（如最大方法长度限制）或多模态输入（如 UI 原型图）。

6. 结论

AI IDE（如 Cursor）在系统化框架（FD-HITL）的辅助下，具备生成大型、功能正确软件系统的潜力。然而，生成的代码存在显著的设计缺陷，严重违反软件工程核心原则（SRP, DRY, KISS 等），对长期维护构成风险。因此，AI IDE 目前无法替代资深开发者的工程判断，特别是在需求工程和架构设计层面，必须保持严格的人工审查和代码重构。