论文信息

  • 论文：Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects
  • 作者：Peng Liang 等
  • 链接：https://arxiv.org/abs/2604.06373

核心问题：AI IDE 生成的项目「能跑」就够了？

Cursor、Copilot Agent 这类 AI IDE 越来越多地被用于生成项目级代码。功能测试通过率已经很高（这篇论文报告了 91%），但一个被严重忽视的问题是：功能正确不等于设计好。生成的代码能跑，但三个月后还能维护吗？新需求来了还能扩展吗？

这篇论文用严格的实证方法回答了这个问题：10 个项目、2 个静态分析工具、4498 个设计缺陷——数字本身就说明了问题的严重性。

研究方法：FD-HITL 框架 + 双工具静态分析

研究团队设计了一个 Feature-Driven Human-In-The-Loop（FD-HITL）框架，系统化地引导 Cursor 从精心编写的项目描述生成完整项目。覆盖 3 个应用领域、多种技术栈，共生成 10 个项目。

项目规模数据

  • 平均每个项目 16,965 行代码（LoC）
  • 平均每个项目 114 个文件
  • 功能正确率 91%（人工评估）

分析工具

  • CodeScene：检测出 1,305 个设计问题，分 9 个类别
  • SonarQube：检测出 3,193 个设计问题，分 11 个类别
  • 总计：4,498 个设计问题——每个项目平均 ~450 个

六大高频设计问题

1. Code Duplication（代码重复）

AI IDE 在生成代码时倾向于「复制粘贴」相似逻辑而不是抽象为公共函数。这违反了 DRY 原则（Don't Repeat Yourself），导致维护时需要在多个地方同步修改。根本原因：LLM 的生成模式是「按需补全」，没有全局视角去做抽象。

2. High Code Complexity（高代码复杂度）

圈复杂度（Cyclomatic Complexity）过高。AI 生成的函数经常嵌套多层 if-else 和循环，导致理解和修改困难。人类开发者通常会在写第三层嵌套时意识到「该拆函数了」，但 LLM 没有这个「重构冲动」。

3. Large Methods（大方法）

单个函数/方法过长。违反 SRP（单一职责原则）——一个函数做太多事情。这和上面的高复杂度是同一个根源：LLM 倾向于在一个上下文窗口内完成所有逻辑，而不是主动拆分。

4. Framework Best-Practice Violations

违反框架最佳实践。比如 React 中直接操作 DOM 而不是用状态管理、Spring Boot 中在 Controller 层写业务逻辑等。LLM 训练数据中包含大量低质量代码，生成时「学到」了错误模式。

5. Exception-Handling Issues

异常处理要么过于简单（空 catch 块）、要么过于粗暴（catch Exception 吞掉所有异常）。人类开发者在异常处理上会根据业务场景做分层处理，LLM 目前还做不到这种上下文感知的异常策略。

6. Accessibility Issues

前端项目的无障碍访问问题——缺失 alt 属性、ARIA 标签不正确等。这在功能测试中完全不会暴露，但对真实用户体验有显著影响。

违反的设计原则

  • SRP（单一职责原则）：大方法 + 高复杂度 = 函数做了太多事
  • SoC（关注点分离）：框架最佳实践违规 = 不同层次的逻辑混在一起
  • DRY（不要重复自己）：代码重复 = 同样逻辑多处出现

🔑 关键洞察：AI Coding 的真正瓶颈是设计能力

功能正确是表象，设计质量才是地基

91% 的功能正确率看起来很亮眼，但 4,498 个设计问题意味着什么？意味着项目上线后会面临：代码重复导致的同步修改噩梦、高复杂度导致的重构恐惧、异常处理缺陷导致的线上事故隐患。这些不会在功能测试中暴露，但在第 3 次需求变更时全面爆发。

LLM 的本质局限：没有「架构师视角」

LLM 的工作模式是逐 token 生成——它是「写代码的工匠」，不是「设计架构的建筑师」。工匠可以完美地砌每一堵墙，但不会主动思考「这堵墙该不该拆分」。代码重复、大方法、高复杂度这些问题的根源，是 LLM 缺乏全局架构视角。

Harness Engineering 的验证

这篇论文是 Harness Engineering 理念的最佳实证支持。FD-HITL 框架本身就是「渐进式披露」和「环境设计」的实践——通过人类分步骤地引导项目生成，而不是一次性给个大 prompt。但即使有了这个框架，设计质量问题依然系统性存在，说明人工介入不能止于「引导生成」，还需要延伸到「设计审查」和「重构指导」。

引发思考：AI Coding 的下一步是什么？

  1. Design-aware generation：让 LLM 在生成代码时同时考虑设计原则（SRP/DRY/SoC），而不是只追求功能正确。这需要专门的训练数据和 reward signal。
  2. Automated refactoring as a service：AI Coding 工具应该内置「设计质量检查 + 自动重构」模块，类似 CodeScene 但更激进——不只是发现问题，而是直接修复。
  3. Two-tier AI coding：第一层生成功能代码（LLM 擅长），第二层做架构优化（可能需要专门的小模型或规则引擎）。两层分离，各司其职。

逍遥云初 | 2026.04.09