AI-Generated Smells: An Analysis of Code and Architecture in LLM- and Agent-Driven Development
AI-Generated Smells: An Analysis of Code and Architecture in LLM- and Agent-Driven Development
原文链接：https://arxiv.org/abs/2509.06233 数据与脚本：https://doi.org/10.5281/zenodo.19245562 作者：Yue Cai Zhu, Nikolaos Tsantalis, Peter C. Rigby 机构：Concordia University 发布日期：2026-05-05
速查卡
| 项目 | 内容 |
|---|---|
| 一句话总结 | 这篇论文最重要的发现不是“AI 代码质量不好”，而是 AI 会形成一套和人类不同、并且会随任务复杂度升级而迁移的技术债指纹。 |
| 大白话版 | 简单任务里，AI 爱把逻辑全塞进超长函数；复杂项目里，AI 又会装作已经模块化，实际上只是把坏味道分散到更多文件里。 |
| 核心数字 | Qwen-Coder-480B 在 zero-shot 下 Long Method 11 次、few-shot 下 13 次；Gemini-2.5-pro 从 5 次升到 8 次；TLoC 与架构味道相关系数 ρ=0.94；ToF 与架构腐化相关 ρ=0.72；prompt specificity 对质量无显著影响 p>0.8。 |
| 评级 | A- — 它不是造新模型，而是在给 agent 编程时代建立“怎么量化坏味道”的第一批严肃框架。 |
| 代码 | 论文提供 replication package |
| 关键词 | code smells, architecture rot, Long Method, Temporal Field, MetaGPT, Modular Mirage, Volume-Quality Inverse Law |
核心 Insight
这篇论文的核心洞察可以压成一句话：
AI 不会消灭技术债，它只会把技术债换一种形态重新制造出来。
而且这种“坏”不是随机的。论文证明它带有明显的机器风格：
- 在简单算法题里，AI 倾向于把复杂逻辑塞进一个超长方法，形成 Long Method；
- 到复杂多文件项目里，这种坏味道又升级成 God Class、Too Many Branches、Potential Improper API Usage、Unstable Dependencies、Scattered Functionality；
- 更扎心的是，表面上文件变多了，模块拆开了，实际上只是形成作者所谓的 Modular Mirage（模块化幻觉）。
为什么这个想法 work？
因为传统评价 AI 写代码，太容易只看：
- 能不能跑
- 测试过不过
- lint 干不干净
但这些指标很容易错过真正的长期维护成本。论文把问题拉回软件工程本体：
- 代码是不是可演进
- 责任是不是分配合理
- 架构是不是会在规模上来后迅速腐烂
这是 agent 编程进入生产环境前必须补的一课。
方法详解
整体架构
论文设计了一个双实验框架：
输入模型/agent → Experiment I：单文件算法题 → Experiment II：多文件 agent 生成项目 → PyExamine 静态分析 → 统计 code / structural / architectural smells
这样做的好处是能把“简单任务时怎么坏”和“复杂项目时怎么坏”放在同一条轴上看。
关键技术组件
组件 1：Experiment I — 算法题上的单模型代码味道审计
做什么： 建立 AI 代码质量的基础画像。
怎么做：
- 使用 CodeContest 2022 数据集
- 抽取 90 个问题
- 对比模型包括：
deepseek-coder-v2:16b、Llama-3.3:70b、qwen3-coder:30b、qwen3-coder:480b、Gemini-2.5-pro - 同时抽样一组 human baseline 作为对照
- 分别测 zero-shot 与 few-shot
组件 2：Experiment II — MetaGPT 生成全项目后的架构味道审计
做什么： 看 agent 从单文件跨到多文件系统时，坏味道会不会发生性质变化。
怎么做：
- 采用 MetaGPT 作为多 agent 框架
- 底层模型为 Qwen-Coder 480B
- 设计 5 个应用场景
- 每个场景有 4 轮递增复杂度 prompt
- 统计：
ToF（Total Number of Files）TLoC（Total Lines of Code）AAC（Agent Action Count）
组件 3：PyExamine 静态味道检测
做什么： 统一、可重复地检测代码/结构/架构坏味道。
为什么选它： 论文强调 PyExamine：
- 覆盖 Long Method、Large Class 等多种 smells
- 静态分析，不依赖运行成功与否
- 可以批量、标准化输出位置与类型
与现有方法的关键区别
| 维度 | 常见 AI 代码评估 | 本文方法 | 为什么更好 |
|---|---|---|---|
| 关注点 | functional correctness / lint | maintainability / smells / architecture | 更接近真实工程代价 |
| 分析层级 | 单任务结果 | 单文件 + 多文件系统双层分析 | 能看坏味道迁移 |
| 对照对象 | 常无 human baseline | 有 human baseline | 能看 AI 与人类差异 |
| 干预变量 | 只看模型 | 还看 prompt specificity、体量、项目规模 | 能定位退化来源 |
实验结果
主实验：算法题中的味道指纹
| 模型 | Zero-shot Long Method | Few-shot Long Method | 其他关键观察 |
|---|---|---|---|
| deepseek-coder-v2(16b) | 2 | 2 | 相对温和 |
| Llama3(70b) | 0 | 0 | 更短，但往往是没把复杂逻辑做出来 |
| Qwen Coder(30b) | 7 | 7 | 程序性膨胀明显 |
| Qwen Coder(480b) | 11 | 13 | 最高，few-shot 反而更糟 |
| Gemini-2.5-pro | 5 | 8 | 同样出现 few-shot 恶化 |
| Human baseline | 1 | 1 | 但有 4 次 Temporal Field |
解读：
- 人类 baseline 的典型坏味道是 Temporal Field：状态封装差，但方法本身不长；
- AI 的典型坏味道是 Long Method：状态收进去了，但逻辑全堆在一个过程块里；
- 这就是论文提出的 Reasoning-Complexity Trade-off / Paradox：模型越强，越倾向于“硬啃复杂边界情况”，结果函数更臃肿。
Few-shot 为什么没救场
| 模型 | Zero-shot LM | Few-shot LM | 变化 |
|---|---|---|---|
| Qwen Coder(480b) | 11 | 13 | +2 |
| Gemini-2.5-pro | 5 | 8 | +3 |
论文的判断很重要：few-shot 示例并没有显著改善代码卫生，反而可能因为给了更多“完整展开”的信号，让模型写得更长、更满。
主实验：复杂系统中的坏味道迁移
论文在 Experiment II 里看到味道谱系发生明显切换：
- Long Method 不再是主角
- 变成 Too Many Branches (TMB)
- High Response for a Class (RFC)
- Potential Improper API Usage (PAU)
- Scattered Functionality (SF)
- Unstable Dependencies (UD)
作者把这类现象总结为：
- God Class Syndrome：逻辑被集中到 manager 类里；
- Redundant Implementation：外部调用逻辑被反复 inline 重写；
- Modular Mirage：文件分开了，但语义上没分工，相关行为碎了一地。
可扩展性分析
最关键的数据在相关性分析：
| 变量 | 与架构味道相关性 | 解释 |
|---|---|---|
| TLoC | ρ = 0.94 | 代码量越大，架构腐化几乎线性恶化 |
| ToF | ρ = 0.72 | 文件数越多，也明显更坏 |
| 结构味道相关 | ρ = 0.59 | 中高相关 |
| 代码味道相关 | ρ = 0.53 | 也相关，但不如架构层明显 |
论文因此提出 Volume-Quality Inverse Law：
代码量与文件数一旦上去，当前 agent 维持一致架构视野的能力会快速坍塌。
更狠的是：
- functional correctness 与结构质量解耦
- 更详细的 prompt 没显著帮助，p > 0.8
也就是：
- 跑通不代表结构好
- 多写点需求不代表 agent 就更懂架构
复现评估
| 维度 | 评分(1-5) | 详细说明 |
|---|---|---|
| 数据可得性 | ⭐⭐⭐⭐ | 90 题样本、human baseline、MetaGPT prompt 均给了 replication package。 |
| 代码可得性 | ⭐⭐⭐⭐ | Zenodo package 已公开。 |
| 算力需求 | ⭐⭐⭐ | Experiment II 用到 Qwen-Coder 480B，不算低。 |
| 工程复杂度 | ⭐⭐⭐ | 重在数据流水线、静态分析与统计，不是难在模型微调。 |
| 预期收益 | ⭐⭐⭐⭐⭐ | 对所有做 agent coding、自动编程评估、代码治理的人都非常有参考价值。 |
复现建议： 先复现实验 I 的 90 题 smell pipeline，再用一个轻量 agent 框架做实验 II 缩小版，验证 TLoC 与架构味道是否也近似同向增长。
批判性分析
局限性
- Experiment II 只用 MetaGPT：结论未必可无缝推广到所有 agent coding 框架。
- 只看首次产物：论文明确承认没有做“测试后反复 debug/self-correct”闭环，因此更像测模型天然写作偏好，而非最终极限能力。
- 静态分析也有误报边界：作者自己指出 FE、PSS 在算法题语境下会误报，所以最终重点放在更可靠的指标上。
- 场景仍是受控实验：真实企业仓库、多人协作、长期演化项目可能出现更复杂的 rot 模式。
改进方向
- Architecturally-aware agents：让 agent 内置 architect 角色或硬性设计约束。
- Refactoring agents / self-healing agents：不是只会写，还要会闻到哪里臭、主动重构。
- Longitudinal software evolution benchmarks：做更长时间尺度的开放式项目演化测试。
- Semantic cohesion metrics：未来不只看文件拆得开不开，还要测语义是不是黏在一起。
独立观察
- 这篇论文最值钱的地方，不是告诉我们“AI 还不够好”，而是告诉我们“AI 坏起来有稳定模式”。
- 很多团队今天在 agent coding 上的体感痛点——巨型函数、万能 manager、文件看似多但职责混乱——这篇论文几乎全都点名了。
- “模块化幻觉”这个概念很强，因为它准确描述了今天很多 agent 代码：目录很像样，架构其实是空心的。
对领域的影响
这篇工作会逼着自动编程赛道从“谁一次写对更多题”转向“谁能在规模上去之后还写得能维护”。
短期内最该调整的，不是 prompt 花样，而是评测体系：
- 要看 smell density
- 要看 architectural decay
- 要看 ToF/TLoC 上升时质量怎么崩
- 要看 agent 有没有自我重构能力
否则大家只会继续把能跑但会烂掉的代码，误当成工程胜利。