技术总结：更快的代码，更深的债务？关于 LLM 辅助软件开发中技术债务及其早期迹象的多视角文献综述

问题陈述

将大语言模型（LLM）快速集成到软件工程工作流中，虽然承诺了生产力的提升，但也引入了显著且常被忽视的长期风险，即技术债务。先前的研究主要关注 LLM 生成代码的功能正确性和即时质量，但在理解这些人工制品如何累积成长期技术债务方面存在关键空白。早期证据表明，存在一种权衡：短期速度的提升（例如，增加代码变更率、降低复用率）可能会加速债务的积累，表现为幻觉引用、不安全配置和非确定性行为。此外，现有文献缺乏对传统债务类型（代码、设计、文档）如何被 LLM 放大以及新兴的、针对 LLM 特有的债务类别的全面视角。同时，在标准化基准、LLM 特定指标以及专门用于检测和衡量这些债务的工具方面也存在明显的缺失。

研究方法

本研究采用多视角文献综述（Multivocal Literature Review, MLR），综合了学术研究与从业者“灰色文献”的证据。综述过程遵循 Garousi 等人提出的指南和 SEGRESS 框架。

• 数据来源： 作者共分析了 104 个来源：
  • 31 个正式来源： 来自顶级会议和期刊（如 ICSE, FSE, TSE, ASE）的同行评审论文，检索自 IEEE Xplore、ACM Digital Library、Springer Link 和 Elsevier ScienceDirect。
  • 73 个灰色文献来源： 行业报告、公司博客（如 IBM、Salesforce）、开发者论坛和媒体报道，通过 Google Search（使用 SerpAPI）检索，并经过质量和相关性过滤。
• 检索策略： 一个综合搜索字符串，结合了 13 种已建立的技术债务类别（如代码、设计、架构债务）与 LLM 特定术语（如“LLM”、“Copilot”、“AI-generated code”）。
• 筛选标准： 入选要求必须明确讨论 LLM 背景下的技术债务。排除标准则剔除了仅关注功能质量而不涉及债务，或仅关注利用 LLM 来检测债务而非引入债务的论文。
• 分析： 作者使用了混合编码方法：
  • 演绎编码（Deductive Coding）： 应用 Alves 等人的现有技术债务分类法（13 种类型）。
  • 归纳编码（Inductive Coding）： 识别未被传统分类法覆盖的新兴 LLM 特定债务类别。
  • 可靠性： 两名作者独立提取数据并对来源进行编码，实现了极高的评分者间一致性（大多数类别的 Cohen's Kappa > 0.90）。

核心贡献

1. 首个多视角研究： 这是首个整合学术界和从业者视角，以绘制 LLM 辅助开发中技术债务图景的综述。
2. 分类法扩展： 本研究证实了传统债务类型（代码、设计、文档）依然普遍存在，但识别了 六种新兴的、LLM 特有的债务类别：
   • 治理债务（Governance Debt）： 由于幻觉和非确定性导致的长期监督负担。
   • 快速集成债务（Fast-Integration Debt）： 因优先考虑速度而非验证（即“氛围编程/vibe coding”）而产生的风险，导致基础结构不稳定。
   • 提示词债务（Prompt Debt）： 由不清晰、无文档或脆弱的提示词引起的责任，这些提示词会阻碍可复现性。
   • 数据债务（Data Debt）： 来自噪声或不透明的训练/检索数据所隐藏的责任，这些数据会将缺陷传播到生成的代码中。
   • 伦理债务（Ethical Debt）： 生成代码中偏见和公平性失败所累积的风险，进而影响最终用户。
   • 溯源债务（Provenance Debt）： 对 AI 生成逻辑的所有权或归属权不明。
3. 策略合成： 综述映射了现有的缓解策略，强调了对 人机协同（Human-in-the-Loop, HITL） 框架、提示词工程和数据质量对齐的高度依赖。
4. 差距识别： 文献明确指出，缺乏 标准化基准 和 LLM 特定指标 是系统化评估和管理这些债务的关键障碍。

研究结果

RQ1：技术债务的形式

• 传统债务： 代码债务是最常被提及的问题（56 个灰色来源，14 个正式来源），其驱动因素是开发者在未完全理解逻辑的情况下集成代码，导致代码重复和复杂性。设计债务（30 个来源）和文档债务（17 个来源）也较为突出，因为 LLM 往往会忽略系统架构且无法更新文档。
• 新兴债务：
  • 治理债务（19 个来源）是讨论最多的新类别，反映了对非确定性输出进行持续监督的需求。
  • 快速集成债务（13 个来源）强调了“速度陷阱”，即快速采用的速度超过了验证可维护性的能力。
  • 提示词、伦理和溯源债务被视为需要新管理方法的独特挑战。

RQ2：缓解策略

• 人机协同（Human-in-the-Loop）： 两种文献中占主导地位的策略是将 LLM 视为“初级开发人员”，要求在集成前进行严格的代码审查、测试和验证。
• 提示词工程： 结构化提示词、版本控制和清晰的上下文被认为是减少提示词债务并提高输出质量的关键。
• 数据质量： 正式文献强调通过预处理训练数据并使其符合标准（如 ISO/IEC）来减轻数据债务。
• 工具链： 虽然存在工具，但大多是功能复用。

RQ3：工具与技术

• 现状： 从业者高度依赖通用的静态分析工具，如 SonarQube、ESLint 和 Pylint，来检测代码异味（code smells）和漏洞。
• 新兴工具： 商业工具如 Amazon CodeWhisperer、GitHub Copilot（带有负责任 AI 功能）、Snyk 和 Swimm 开始提供针对安全性、可解释性和文档的功能。
• 研究原型： 学术界的努力包括 CodeSmellEval（用于衡量 LLM 中代码异味的倾向）和 QualAI（用于监控 AI 系统质量），但这些尚未实现标准化或广泛应用。

RQ4 & RQ5：基准与指标

• 基准： 综述发现 没有任何专门设计的标准化基准或数据集 用于评估 LLM 生成代码中的技术债务。现有基准侧重于二元正确性（如 CodeXGLUE），而非长期的可维护性或债务累积。
• 指标： 当前指标（如 SonarQube 规则）是不够的，因为它们无法捕捉语义准确性、架构契合度以及 LLM 特有的风险（如提示词可靠性或溯源问题）。
• 建议维度： 文献表明需要新的指标，涵盖 上下文敏感性、适应性、可审查性、提示词可靠性 以及 数据异味强度/密度。

重要性与主张

本文主张，将 LLM 集成到软件工程中不仅仅是生产力的提升，更是一种如果管理不当就会引入“更深债务”的根本性转变。作者认为：

1. LLM 放大传统债务，通过加速创建难以维护、测试和理解的代码。
2. 新的债务类别（治理、快速集成、提示词等）需要超越传统代码审查的独特管理策略。
3. 该领域目前处于碎片化状态： 虽然业界对 HITL 等策略达成广泛共识，但由于缺乏标准化的工具、指标和基准，阻碍了社区系统地衡量和减轻这些风险。
4. 未来方向： 作者呼吁软件工程界应从仅仅记录风险转向构建 可操作的解决方案，包括开发开源工具、社区驱动的基准以及追踪债务随时间累积情况的纵向研究。他们强调，如果不进行这些发展，由于技术债务管理不善，“AI 原生”的软件工程 3.0 愿景可能难以为继。