为什么AI生成的拉取请求无法检测自身的不安全代码？
核心问题在于，AI代码生成器的训练目标是生成看似合理的代码，而非可验证安全的代码。2025年一项针对AI生成的安全相关拉取请求（PR）的研究发现，这些PR频繁引入可通过Semgrep等静态分析工具检测到的漏洞[1]。该研究通过筛选GitHub高星仓库中的PR并人工验证其安全相关性，表明AI生成的代码变更已成为真实存在的安全风险来源，而非假设性担忧。
此外，2023年一项针对25个热门Java项目中2.1万个拉取请求的研究发现，代码坏味（常导致故障的不良设计指标）存在于37%的已接受PR和44%的已拒绝PR中[2]。最常见的坏味是“上帝类”（承担过多功能的类）和“长方法”——两者都会使代码更难理解且更易出错。该研究还发现，存在坏味的PR更复杂、审查时间更长，且由经验较少的贡献者提交[2]。这表明，缺乏人类判断力的AI生成代码尤其容易出现这些质量问题。
AI 审查工具能发现什么，不能发现什么
基于Falcon40-B模型在WatsonX平台上运行的2024年研究所述，AI驱动的代码审查助手能够就代码格式、最佳实践及细微问题提供初步反馈[4]。这类工具还可自动分配审查员并发送通知。然而，研究者明确指出，其目标是让该机器人逐步进化为"能够从功能角度评估代码的智能审查员"——这意味着它目前尚不具备深层的安全性或正确性分析能力[4]。该工具旨在简化审查流程，而非捕捉不安全的代码变更。
类似地，2024年一项针对GitHub Copilot拉取请求功能的研究发现，尽管AI生成的描述缩短了审查时间并提高了合并概率，但开发者仍需频繁手动编辑AI的输出内容[3]。该研究分析了18,256个拉取请求，发现开发者“经常用人工输入来补充自动生成的描述”[3]。这表明AI的输出在可信度或准确性上尚不足以独立使用，尤其是在安全关键环节。AI虽能加速常规任务，但无法依赖其自行检测错误。
核心结论：AI生成的代码需要人工验证
四项研究从不同角度得出了相同结论：AI生成的拉取请求并非自我验证。安全研究[1]表明，AI代码确实存在真实漏洞；代码异味研究[2]指出，类似AI生成的代码（来自经验较少的贡献者）更可能出现质量问题；Copilot研究[3]显示，开发者必须手动修正AI输出；而AI审查助手研究[4]则表明，当前AI工具仅能进行表面检查。
这些研究中没有任何证据表明AI能够检测自身生成的不安全代码变更。事实上，恰恰相反：现有工具的设计初衷是辅助人工审查，而非取代人工。如果你正在使用AI生成拉取请求，应当计划进行彻底的人工审查，尤其是在安全性和设计质量方面。AI有助于提升速度和格式规范，但安全底线必须由人类把控。
关于这些来源
该回答基于4项研究（3篇经同行评审，1篇为预印本）——发表于2023年至2025年间，其中3篇来自2024年及以后，1篇发表于Q1–Q2期刊——这些研究是从通过质量筛选的4项研究中选出的最具相关性的成果，而后者又源自从超过5亿篇论文的数据库中检索到的28篇文献。
本文引用的文献
复现包：《关于安全相关AI生成拉取请求的见解》
一项2025年针对GitHub高星仓库中与安全相关的AI生成拉取请求的研究，采用静态分析工具（Semgrep）检测漏洞，证实AI代码变更经常引入安全风险[1]。
拉取请求中的代码异味：一项探索性研究
一项2023年针对25个Java项目中21,000个拉取请求的研究发现，37%被接受的PR和44%被拒绝的PR包含代码坏味（上帝类、长方法），且存在代码坏味的PR复杂度更高、审查时间更长[2]。
生成式AI在拉取请求描述中的应用：采纳情况、影响与开发者干预
一项2024年针对18,256个拉取请求（PR）的研究，使用了GitHub的Copilot for PRs功能，发现AI生成的描述缩短了审查时间并提高了合并可能性，但开发者经常需要手动编辑AI的输出内容[3]。
AI驱动的代码审查助手：简化拉取请求合并流程
一项2024年的研究引入了一款基于WatsonX平台、使用Falcon40-B模型的人工智能机器人，用于初步的代码审查，重点关注格式规范和最佳实践，但指出该机器人尚不具备功能或安全评估能力[4]。