"TODO: 修复 Gemini 搞砸的代码"：理解生成式 AI 引发的自认技术债务 "TODO: Fix the Mess Gemini Created": Towards Understanding GenAI-Induced Self-Admitted Technical Debt
首次实证研究LLM辅助开发中开发者自认技术债务的分布与AI角色
前置知识
自认技术债务 (Self-Admitted Technical Debt, SATD)
SATD 是指开发者在代码注释中主动承认的技术债务，通常以 TODO、FIXME、HACK、XXX 等关键词标记。与隐式技术债务不同，SATD 是开发者有意识地记录下来需要后续处理的问题，反映了开发者对代码质量的自我认知。Maldonado 等人提出了经典的五类分类法：设计债务、缺陷债务、文档债务、需求债务和测试债务。SATD 的研究价值在于它提供了开发者内心视角，揭示了代码库中需要改进的区域。
本文的核心研究对象就是 AI 辅助开发场景下的 SATD，理解 SATD 的定义、分类和检测方法是阅读本文的基础。
大型语言模型 (Large Language Models, LLMs)
LLM 是基于 Transformer 架构的大规模预训练语言模型，如 ChatGPT、GitHub Copilot、Claude、Gemini 等。这些模型能够根据上下文生成代码、回答编程问题、进行代码补全和重构建议。在软件开发中，LLM 已被集成到 IDE 和工作流中，成为开发者的辅助工具。然而，LLM 生成的代码可能存在逻辑错误、冗余实现或不完整的功能，开发者需要评估和维护这些 AI 生成的代码。
本文研究的是开发者在使用 LLM 工具后留下的代码注释，LLM 工具的特性和使用方式直接影响技术债务的产生模式。
人机协作 (Human-AI Collaboration)
在 AI 辅助软件开发中，人机协作是指开发者与 AI 工具共同完成编程任务的过程。开发者保留最终决策权，负责审查、修改和验证 AI 生成的代码。这种协作模式改变了传统的开发流程，开发者从完全自主编写代码转变为评估和整合 AI 建议。研究表明，开发者对 AI 生成代码的信任程度、理解深度和验证行为会显著影响最终代码质量。
本文提出的 GIST 概念本质上描述了人机协作中因不确定性而产生的技术债务，理解人机协作模式有助于把握论文的核心洞察。
开放编码 (Open Coding)
开放编码是质性研究中的一种数据分析方法，属于扎根理论（Grounded Theory）的核心技术。研究者从原始数据中归纳性地提取概念和类别，而不是使用预定义的分类框架。在本文中，两位作者独立阅读 81 条代码注释，通过迭代讨论归纳出 AI 在技术债务中的四种角色：来源（Source）、催化剂（Catalyst）、缓解者（Mitigator）和中性（Neutral）。这种方法确保了分类体系是从实际数据中自然涌现的。
本文的 RQ2 采用开放编码方法来识别 AI 的角色分类，理解这一方法论有助于评估研究结论的可靠性和有效性。
研究动机
随着 GitHub Copilot、ChatGPT、Gemini 等 LLM 工具深度融入软件开发工作流，开发者越来越多地在代码注释中留下 AI 参与的痕迹。然而，现有研究主要关注 AI 辅助开发的生产力提升（如 Barke 等人 2023 年的研究），而忽视了 AI 工具本身可能引入的新型技术债务。传统技术债务研究（如 Potdar 和 Shihab 2014 年的开创性工作、Maldonado 等人 2015 年提出的五类分类法）聚焦于人类开发者因时间压力或权衡取舍而主动积累的债务，但当代码部分由非人类智能体生成时，技术债务的成因、分布和性质可能发生根本性变化。开发者必须评估、纠正和维护由 AI 部分编写的代码，但目前缺乏对这一新兴现象的系统性实证研究。
本文的目标是本文旨在填补这一研究空白，通过系统分析代码注释中同时引用 LLM 使用和技术债务标记的实例，回答两个核心研究问题：（1）在开发者同时承认 LLM 参与和技术债务的注释中，出现了哪些类型的自认技术债务？（2）开发者如何归因 AI 在生成式 AI 诱导的技术债务中的角色？研究目标是揭示 AI 辅助开发如何重塑技术债务的分布模式，并提出一个描述这种新型债务的概念框架。
与已有工作不同的是，本文的独特切入角度在于关注开发者代码注释中的双重承认——同时承认 AI 参与和技术债务的存在。与以往仅研究 SATD 或仅研究 AI 辅助开发的工作不同，本文聚焦于这两个领域的交集。通过分析开发者自己的话语，本文能够捕捉到开发者对 AI 生成代码的真实态度和不确定性，而不仅仅是代码质量的客观指标。这种开发者视角的分析揭示了一种新的技术债务形态：当开发者整合 AI 生成的代码但对其正确性或逻辑缺乏充分理解时产生的债务，本文将其命名为 GenAI-Induced Self-admitted Technical Debt（GIST）。
核心方法
本文采用两阶段过滤加人工标注的研究方法。第一阶段通过 GitHub Code Search API 收集包含 LLM 相关关键词的代码注释；第二阶段在这些注释中筛选同时包含 SATD 标记的实例；最后通过人工标注和开放编码进行深入分析。整个方法论遵循经验软件工程的标准范式，结合定量统计和定性分析，从大规模代码库中提取有意义的模式。
本文的核心创新在于提出双重过滤策略和 GIST 概念框架。双重过滤策略先识别 LLM 引用的注释，再从中筛选 SATD 标记，确保研究对象精确对应 AI 参与和技术债务的交集。更本质的创新是 GIST 概念的提出，它描述了一种前所未有的技术债务形态：开发者因对 AI 生成代码的理解不足而产生的认知债务。与传统技术债务源于有意识的权衡不同，GIST 源于对 AI 输出的不确定性和部分依赖，这反映了人机协作中责任分担的模糊性。
方法步骤详情
方法分为三个主要步骤。第一步是数据收集：研究者构建了 196 个结构化搜索查询，组合 7 个 AI 相关术语（如 LLM、AI、GPT、ChatGPT、Copilot、Gemini、Claude）、6 个生成动词（如 generated、suggested、written）和 4 个连接词（by、from、with、using），通过 GitHub Code Search API 在 2022 年 11 月至 2025 年 7 月期间的公开 Python 和 JavaScript 仓库中搜索，获得 37,234 个文件。使用 AST 解析提取匹配的注释，去重后得到 6,540 条唯一注释。第二步是债务标记检测：在 LLM 引用集合中应用正则表达式匹配 TODO、FIXME、HACK、XXX 等 SATD 关键词（不区分大小写），得到 96 条同时满足两个条件的注释。第三步是人工标注和开放编码：两位标注者独立按照 Maldonado 等人的分类指南对 96 条注释进行分类，Cohen's $\kappa = 0.896$ 表明高度一致性。在标注过程中发现 10 条假阳性（提及 AI 但未实际使用）和 5 条不含技术债务的实例，移除后得到最终的 81 条标注数据集。随后，两位作者通过开放编码归纳出 AI 的四种角色分类。
技术新颖性
本文的技术新颖性体现在三个层面。首先，这是首个系统性研究生成式 AI 诱导的自认技术债务的实证工作，填补了 SATD 研究在 AI 时代的空白。其次，研究方法上的创新——双重过滤策略结合 AST 解析，能够从海量代码库中精确识别 AI 参与和技术债务的交集实例。第三，GIST 概念的提出具有理论贡献，它引入了两个关键维度：知识缺口与延迟质量保证（Knowledge Deficit and Deferred Quality Assurance）、信任缺失与责任委托（Lack of Trust and Delegated Responsibility）。这两个维度揭示了 AI 辅助开发中技术债务的认知和组织层面，超越了传统的代码质量视角。此外，AI 角色四分类法（Source、Catalyst、Mitigator、Neutral）为理解人机协作中 AI 的多重作用提供了新的分析框架。
实验结果
本文的核心发现可以从两个研究问题来分析。在 RQ1（SATD 类型分布）方面，研究发现设计债务（Design Debt）最为常见，出现在 33/81 条注释中（40.74%），反映了代码位置不当、实现质量差或临时变通方案等问题。需求债务（Requirement Debt）和测试债务（Test Debt）各占 17/81 条（20.98%），前者表示代码功能的不完整性，后者表示对 AI 生成代码的验证延迟。缺陷债务（Defect Debt）出现在 11/81 条注释中（13.58%），文档债务（Documentation Debt）最少，仅 3/81 条（3.70%）。与 Maldonado 等人的经典研究相比，设计债务的比例显著降低（40.74% vs 71.84%），而需求债务（20.98% vs 14.24%）和测试债务（20.98% vs 2.09%）明显升高。这表明 AI 辅助开发改变了技术债务的分布：开发者依赖 AI 生成初始结构，但延迟了功能完成和验证活动。在 RQ2（AI 角色归因）方面，AI 最常被归因为催化剂（Catalyst），占 34/81 条（41.98%），表示 AI 生成的代码引发了对潜在问题的关注，但并非直接导致债务。AI 被归因为来源（Source）的情况占 22/81 条（27.2%），开发者明确指出 AI 生成的代码引入了错误或冗余逻辑。缓解者（Mitigator）角色占 19/81 条（23.5%），表示 AI 帮助解决了现有债务。中性角色仅占 6/81 条（7.4%）。跨债务类型的分析显示，当 AI 作为来源时，最常关联设计债务（9 例）；作为催化剂时，主要关联测试债务（15 例）和设计债务（13 例）；作为缓解者时，主要关联需求债务（9 例）和设计债务（8 例）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SATD 类型分布对比 | 设计债务占比 | 40.74%（33/81） | Maldonado 等人：71.84% | 降低 31.1 个百分点，表明 AI 辅助开发减少了设计阶段的债务 |
| SATD 类型分布对比 | 需求债务占比 | 20.98%（17/81） | Maldonado 等人：14.24% | 增加 6.74 个百分点，表明 AI 生成代码常留下未完成的功能 |
| SATD 类型分布对比 | 测试债务占比 | 20.98%（17/81） | Maldonado 等人：2.09% | 增加 18.89 个百分点，表明 AI 生成代码的验证被显著延迟 |
| 标注一致性 | Cohen's κ | 0.896 | 通常 >0.7 视为可接受 | 达到高度一致性标准 |
局限与改进
本文存在多方面的局限性。首先，数据规模有限：最终分析仅基于 81 条 AI 相关的 SATD 实例，这限制了定量推广的可信度，作者也承认这些发现应被视为探索性结论。其次，检测方法的局限性：基于关键词的检测策略可能导致假阳性和假阴性，开发者可能使用未被查询覆盖的替代表述引用 AI 生成代码，而 TODO 或 FIXME 标记也不一定都表示真正的技术债务。第三，语言和生态系统的限制：分析仅涵盖 Python 和 JavaScript 仓库，可能无法推广到其他编程语言或专有项目。第四，时间窗口的限制：数据收集截止到 2025 年 7 月，随着生成式 AI 工具和开发者工作流的快速演变，技术债务模式可能发生变化。此外，人工标注虽然经过双人独立编码和讨论解决分歧，但仍存在主观性。从独立观察来看，81 条样本中可能存在选择偏差——只有那些对 AI 参与有明确意识的开发者才会留下相关注释，这可能低估了实际的 GIST 普遍程度。同时，研究无法区分开发者使用 AI 工具的具体方式（如代码补全 vs 完整函数生成），这可能影响对债务成因的深入理解。
独立分析的弱点
本文存在几个值得关注的弱点。第一，样本量较小且可能存在选择偏差：81 条注释来自 6,540 条 LLM 引用注释（占比仅 1.47%），这意味着绝大多数使用 AI 工具的开发场景未被捕捉。改进方向是扩大搜索范围，纳入更多关键词变体和编程语言，或采用机器学习分类器替代关键词匹配。第二，角色分类的主观性：虽然采用开放编码方法，但 Source、Catalyst、Mitigator 的边界有时模糊，同一注释可能被不同研究者归入不同类别。改进方向是制定更明确的编码指南，或引入计算方法辅助分类。第三，缺乏纵向分析：研究仅捕捉了静态快照，无法追踪技术债务随时间的演变——这些 GIST 实例是被解决了还是持续积累？改进方向是结合 Git 历史进行纵向追踪研究。第四，未考虑开发者特征：不同经验水平的开发者对 AI 生成代码的理解和处理方式可能不同，但本文未分析开发者维度。第五，因果关系难以确立：研究只能展示关联性，无法确定 AI 使用是否真的导致了技术债务增加，还是这些债务在没有 AI 的情况下也会以其他形式出现。
未来方向
作者和本文提出了多个有前景的未来研究方向。首先，扩大研究范围：将分析扩展到更多编程语言（如 Java、C++、Rust）和生态系统，验证 GIST 模式的普遍性。其次，纵向仓库研究：追踪包含 GIST 注释的代码库随时间的演变，分析这些债务是被解决还是积累，以及解决的方式和效率。第三，自动化检测工具：开发能够自动识别 GIST 实例的工具，帮助开发团队在代码审查中及时发现和处理 AI 相关的技术债务。第四，实践改进研究：探索将可解释 AI（Explainable AI）和负责任 AI（Responsible AI）原则融入 AI 辅助开发流程，促进代码生成过程的透明度，记录决策依据，明确 AI 使用时的责任归属。第五，团队实践研究：调查不同团队如何制度化地管理 AI 辅助开发中的技术债务，例如制定 AI 生成代码的审查规范、建立 AI 使用的文档标准等。第六，开发者认知研究：深入理解开发者对 AI 生成代码的心理模型，研究不确定性如何影响验证行为和代码维护决策。第七，工具集成研究：探索将 GIST 检测集成到现有开发工具（如 IDE、CI/CD 流水线）中的可行性和效果。
复现评估
本文在复现性方面提供了较好的支持。作者声明数据集已在 Zenodo 上公开发布（doi:10.5281/zenodo.18194031），包含完整的 81 条标注注释和开放编码的标注指南。GitHub Code Search API 的使用方法和 196 个搜索查询的构建规则在论文中有详细描述，理论上可以复现数据收集过程。然而，完全复现存在一些挑战：GitHub 仓库是动态变化的，随着时间推移，部分仓库可能被删除、重命名或修改，导致无法精确复现原始数据集。AST 解析工具（tree-sitter）和正则表达式的具体实现细节需要参考复现包。人工标注过程虽然有指南，但标注者的背景和判断可能引入变异。总体而言，对于经验软件工程领域的定性研究，本文的复现性处于较好水平，数据公开和方法透明度值得肯定。
论文图表
该图展示了一个 Python 函数 generate_content_with_function_calling 的代码片段，其中包含注释 TODO created by Gemini、print(TODO implement me) 和 pass。这表明该函数最初由 Gemini 生成，但实现不完整，开发者留下了 TODO 标记表示需要后续完善。
这张图是理解论文核心概念的直观入口，它展示了 GIST 的典型形态：AI 生成的代码被整合到项目中，但开发者明确标注了其不完整性，形成了需求债务。