这篇论文讲了一个关于"AI 编程助手”（比如 GitHub Copilot 或 Cursor）的一个有趣但有点危险的发现。我们可以把它想象成**“被遗忘的草稿纸陷阱”**。
🎭 核心故事：AI 也会“照猫画虎”吗？
想象一下，你正在和一个超级聪明的AI 学徒一起写代码。你给它看一段代码，让它接着往下写。
通常，我们会把暂时不用的代码**“注释掉”**（就像在草稿纸上把不想要的句子划掉，或者用括号括起来，告诉编译器“这段别运行”）。在人类程序员眼里，这些被划掉的代码就是“废稿”，完全不用管。
但是，这篇论文发现了一个大麻烦：
当 AI 看到这些被划掉的“废稿”时，它并没有把它们当成垃圾扔掉。相反，它觉得：“哦，原来这里以前是这么写的，虽然有点问题，但可能是个思路！”于是，AI 会主动模仿这些有问题的“废稿”，甚至把里面的错误逻辑也一起写进新的代码里。
这就好比：
你给 AI 看一张画了一半的草图，上面画了一只三条腿的狗（这是错误的），然后你把它划掉，说“别画这个”。
结果 AI 看着这张图，心想：“嗯，虽然画错了，但可能是个新风格？”于是它在新画里，认真地画了一只三条腿的狗，而且画得还特别像。
🔍 研究人员做了什么实验？
研究人员（来自中山大学）做了个“钓鱼”实验：
- 准备诱饵：他们从真实的开源项目中找出了很多带有安全漏洞的代码（比如容易让黑客入侵的代码）。
- 制造陷阱：把这些有漏洞的代码“注释掉”（变成废稿），然后放在 AI 要写代码的位置附近。
- 观察反应：让 GitHub Copilot 和 Cursor 这两个著名的 AI 编程助手，看着这些“废稿”继续写代码。
📊 发现了什么惊人的结果？
缺陷率飙升：
当 AI 看到这些有问题的“废稿”时，它生成的新代码中，错误率最高增加了 58.17%。也就是说，本来可能只有 10 个错误，现在变成了 16 个。
AI 不是简单的“复制粘贴”：
最可怕的不是 AI 直接照抄错误。研究发现，AI 会**“举一反三”**。
- 如果你把“废稿”截断一半（只留一半的错误代码），AI 依然能猜出另一半是什么，并把它补全，然后写出一个完整的错误代码。
- 这就像你只给 AI 看“三条腿的狗”的前半句，它就能自动脑补出后半句，并画出一只完整的“三条腿的狗”。
警告标签没用：
研究人员在“废稿”旁边加了标签，写着 <危险！> 或者 <别用这个>。
结果呢？AI 几乎没听进去。错误率几乎没有下降。这说明 AI 太关注代码本身的逻辑了，完全忽略了人类的文字警告。
位置很重要：
如果把有问题的“废稿”放在 AI 要写代码的后面（比如光标后面），AI 更容易中招。这就像你回头看了一眼地上的陷阱，结果脚下一滑，直接掉进去了。
环境越乱，AI 越懵：
如果代码周围空行很多，或者格式很乱（稀疏的上下文），AI 反而更容易被这些“废稿”带偏。就像在嘈杂的房间里，人更容易听信谣言一样。
💡 这对我们意味着什么？
- 不要以为“注释掉”就安全了：以前我们觉得把有问题的代码注释掉就万事大吉了。但现在看来，如果这些代码里有漏洞，它们可能会像“幽灵”一样，通过 AI 复活，变成新的安全漏洞。
- AI 需要更聪明的“过滤器”：现在的 AI 太容易受“上下文”影响了。我们需要教 AI 学会区分“正在运行的代码”和“被废弃的草稿”，并且要更聪明地忽略那些有问题的旧思路。
- 人类要更警惕：在使用 AI 编程时，不能盲目信任它。特别是当你的代码库里有很多旧的、被注释掉的代码时，要小心 AI 会不会把这些“陈年旧账”重新翻出来。
🏁 总结
这篇论文就像给 AI 编程世界敲了一记警钟：AI 很聪明，但它也会“学坏”。 如果你把有问题的旧代码留在文件里（哪怕是用注释包起来），AI 可能会把它们当成“灵感”，把错误延续下去。
一句话总结：
别把有问题的旧代码随便扔在文件里当“注释”，AI 可能会把它们当成“新菜谱”，把错误的味道也一起炒进你的新菜里。
这是一篇关于被注释代码（Commented-Out Code, CO Code）中的缺陷如何加剧 AI 辅助代码生成缺陷的学术论文总结。该研究由中山大学的研究团队完成，发表于 ACM 软件工程会议（FSE 2026）。
以下是该论文的详细技术总结：
1. 研究背景与问题 (Problem)
随着 GitHub Copilot、Cursor 等基于大语言模型（LLM）的 AI 编程助手在软件开发中的普及，代码生成效率显著提升。然而，现有研究主要关注可执行代码上下文对生成缺陷的影响，往往忽略了被注释掉的代码（CO Code）。
- 核心问题：开发者常将调试、废弃或实验性的代码以注释形式保留在源文件中。这些被注释的代码（CO Code）构成了 AI 提示词（Prompt）的一部分。如果这些被注释的代码本身包含缺陷（Defective CO Code），AI 助手是否会受其误导，从而在新生成的代码中引入或复现这些缺陷？
- 动机：初步分析显示，GitHub 上大量 Python 仓库中存在被注释代码，且其中相当一部分包含可检测的缺陷。
2. 研究方法 (Methodology)
研究团队设计了一套系统的实验流程，包含四个主要阶段：
A. 数据集构建 (Dataset Preparation)
- 数据源：从 GitHub 收集了 6,403 个高质量 Python 仓库（Star > 1000，2022 年 12 月后更新）。
- 缺陷提取：使用 CodeQL 扫描代码，识别缺陷。
- 样本构造：
- 将原始文件中的缺陷代码段提取出来，并注释掉，形成“缺陷被注释代码”（Defective CO Code）。
- 剩余部分作为“代码上下文”（Code Context）。
- 原始缺陷位置作为“补全点”（Completion Point）。
- 规模：最终构建了包含 1,000 个样本的数据集，涵盖漏洞（Vulnerability）、可靠性、可维护性等多种缺陷类型。
B. 提示词构建 (Prompt Construction)
- 将缺陷被注释代码插入到代码上下文中补全点的不同位置（补全点上方 1-8 行，下方 1-3 行），共生成 11,000 个提示词。
- 设计了多种变体以测试不同因素：
- FullInsertion：插入完整的缺陷被注释代码。
- TruncatedInsertion：截断缺陷被注释代码的后 50%。
- TaggedInsertion：在缺陷被注释代码前后添加
<Vulnerable> 标签。
- Prompt Engineering：在提示词中显式指令“不要参考被注释的代码”。
- Context Sparsity：通过调整空白行和缩进，改变代码上下文的稀疏度。
C. 代码生成 (Code Generation)
- 工具：GitHub Copilot (VS Code 插件) 和 Cursor (内置编辑器)。
- 模型：分别使用 GPT-4o 和 Claude 3.5 Sonnet 作为底层模型。
- 控制变量：确保编辑器中无其他文件打开，使用默认设置。
D. 缺陷检测 (Defects Detection)
- 使用 CodeQL 扫描 AI 生成的代码，判断是否重新引入了原始缺陷。
- 计算相对增长率 (Relative Increase, Rel. Incr.) 来量化缺陷增加的程度。
3. 关键研究问题与结果 (Key Results)
RQ1: 被注释代码对缺陷率的影响
- 结果：在提示词中包含缺陷被注释代码，显著增加了 AI 生成代码的缺陷率。
- 数据：缺陷数量相对对照组（无插入代码）最高增加了 58.17%。
- 现象：
- AI 并非简单复制被注释代码，而是基于上下文进行推理，主动补全了缺陷模式。
- 后位增强效应 (LPAE)：在 GitHub Copilot 中，位于补全点之后的缺陷被注释代码比位于之前的影响更大（缺陷增加率 >43% vs ~10%），这可能与 Copilot 使用的 Fill-In-the-Middle (FIM) 范式有关。
- Cursor 生成的缺陷总数普遍高于 Copilot。
RQ2: 截断与标签的影响
- 截断 (Truncation)：即使删除了缺陷被注释代码的后 50%，AI 生成的缺陷率依然显著上升（相对增长率仍为正）。
- 结论：证明 AI 具备推理能力，能从片段中推断出完整的缺陷逻辑，而非单纯复制。
- 标签 (Tagging)：添加
<Vulnerable> 标签试图警告 AI，但效果甚微。
- 结论：AI 依然识别并复现了缺陷，标签未能有效阻止缺陷生成。
RQ3: 提示词工程 (Prompt Engineering) 的有效性
- 方法：在提示词中显式指令“不要参考被注释代码”。
- 结果：缺陷数量有所减少，但减少幅度有限（最高仅减少 21.84%）。
- 结论：简单的指令无法完全消除缺陷被注释代码的负面影响，AI 仍倾向于受其干扰。
RQ4: 代码上下文稀疏度的影响
- 发现：对于 GitHub Copilot，上下文越稀疏（例如被注释代码前后有空白行，或缩进不匹配），AI 受其影响产生缺陷的概率越高。
- 解释：稀疏的上下文可能让 AI 将缺陷被注释代码视为独立的逻辑单元，从而更容易被其模式误导。Cursor 对此表现出不同的敏感性。
4. 主要贡献 (Key Contributions)
- 首次系统性研究：揭示了被注释代码（CO Code）中的缺陷是 AI 辅助编程中一个被忽视但严重的风险源。
- 实证数据：基于 6,400+ 个真实仓库和 1,000+ 个实验样本，量化了缺陷被注释代码导致 AI 生成缺陷率最高增加 58.17% 的事实。
- 机制分析：证明了 AI 并非简单复制，而是通过推理“补全”缺陷；发现了“后位增强效应”和“上下文稀疏度”对缺陷生成的具体影响机制。
- 评估现有缓解手段：指出简单的标签警告和提示词指令（Prompt Engineering）在缓解此类问题上效果有限。
5. 意义与启示 (Significance)
- 安全警示：开发者不能因为代码被注释掉就认为其无害。在 AI 辅助开发中，被注释的旧代码可能成为“陷阱”，诱导 AI 生成新的安全漏洞。
- 工具改进方向：现有的 AI 编程助手缺乏足够的鲁棒性来处理包含缺陷的上下文。未来的 AI 工具需要：
- 增强对注释内容的语义理解，区分“可执行逻辑”与“废弃逻辑”。
- 开发更有效的机制来过滤或隔离被注释代码中的缺陷模式。
- 优化提示词工程策略，使其能更有效地忽略有害上下文。
- 开发实践：建议开发团队在引入 AI 辅助时，定期清理源文件中的被注释代码，或在使用 AI 生成代码前对上下文进行更严格的审查。
总结：这篇论文揭示了 AI 代码生成中的一个新范式风险——“注释陷阱” (Comment Traps)。它表明，即使代码未被执行，其包含的缺陷逻辑仍能通过 AI 的推理能力被“复活”并注入到新的代码中，这对软件安全和 AI 工具的可靠性提出了严峻挑战。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。