该论文聚焦生成式 AI 编码助手在软件开发中带来的一个被忽视的环节：开发者对 AI 生成代码的“评估行为”，而非最终产出的代码本身。研究背景是：AI 编码助手（自动补全、对话式工具、AI Agent）正迅速改变开发流程，且已被证实会生成不安全代码。既有工作多测量“AI 辅助开发者最终产出的代码是否安全”，但很少有人系统研究开发者在采纳前如何评估这些建议——他们能否识别其中的漏洞、依据哪些线索做出判断、以及信任程度如何影响其选择。作者认为，无论使用何种形态的 AI 编码工具，这个“人工评估”步骤都是安全开发的基础环节，因此需要先把它单独隔离出来研究。 方法上，作者开展了一项远程观察性研究，共招募 100 名参与者，实验设计刻意切断“写代码”与“评估代码”的耦合：参与者需针对四个 C 语言链表（linked-list）编程任务产出既安全又可用的代码。在每个任务中，参与者可以浏览五条 AI 生成的候选建议，这些建议在“安全性”和“功能正确性”两个维度上被有意设计成不同组合；参与者从中选择一条，并在此基础上编辑成最终提交版本。实验后，所有参与者填写问卷，测量其决策过程、对 AI 生成代码安全性的感知与信任；此外还有 23 名参与者接受了更深入的访谈，用于挖掘其判断依据与推理过程。 主要贡献可概括为：首次以较大样本（100 人）并通过观察 + 问卷 + 访谈三重手段，专门刻画开发者对 AI 生成代码的安全评估过程，识别其使用的判断线索、信任对采纳行为的影响，以及评估能力的局限；研究设置（可循环浏览五条不同安全/功能权衡的建议再选择）也为后续人因安全研究提供了可复用的实验范式。需要注意的是，本条目仅基于论文摘要，摘要未披露具体定量结果（如漏洞识别率、信任与选择之间的相关性方向等），这些结论需查阅全文。适合人群：AI 编码助手研发与产品团队、安全编码培训设计者、软件工程与人机交互（HCI/Security）研究者、以及负责 AI 代码审查流程的 AppSec 团队。

本文针对自动化代码审查工具在拉取请求（PR）安全把关中的评估缺陷展开了研究。作者指出，现有的评估指标只关注审查器是否“阻止”了恶意PR，却忽略了阻止的原因可能与该PR真正存在的漏洞无关。这种“审查结论”与“缺陷诊断”之间的不一致被称为Verdict-Diagnosis（VD）差距。为了系统量化这一差距，作者构建了MalPR-Bench基准，包含来自44个仓库、8种语言家族的89个恶意PR和50个配对良性对照。每个恶意案例都附带预提交的评分规则，明确目标漏洞、可接受的机制描述、所需的仓库证据以及不获认可的无关发现。审查结果分别从结论正确性、目标漏洞识别能力和证据验证三个维度打分，只有三者同时满足才算“可归因的阻止”。同时，作者提出了PRGuard，一种可归因的PR安全审查器，它通过确定性的非执行工具和有界检索，在仓库证据基础上验证候选漏洞前提。在31个公共覆盖的留出恶意PR上，PRGuard和CodeRabbit的阻止总数接近（22/31对比24/31），但PRGuard识别出22个目标漏洞，而CodeRabbit仅识别出16个，差距为1.38倍。在14个缺失型案例中，两者都阻止了9个，但PRGuard识别出9个目标，而CodeRabbit仅识别出3个。当所需证据位于修改文件内时，CodeRabbit能识别16/24个目标；当证据在修改文件之外时，它只能识别0/7个。最后，PRGuard在五个项目中发现了12个此前未公开、且有概念验证支持的漏洞。在发现型PR上，PRGuard/DeepSeek和CodeRabbit都阻止了10/12个，但产生可归因的阻止数分别为10/12和4/12。研究表明，仅依赖“阻止与否”的评估会严重高估自动化审查的安全价值。

该论文关注基于大语言模型（LLM）的代码审计器在 pull-request（PR）工作流中的可靠性问题。尽管这类审计器已被广泛集成，但其对跨仓库演进过程中分布式恶意更改的抵御能力仍缺乏系统研究。为此，作者提出了 PRWeaver 基准，包含从十个真实仓库中提取的 208 个经过执行验证的攻击实例，并为每个实例构造四种匹配的审查渲染方式，总计 832 个渲染。研究评估了三个 PR 审计代理与六个审计器-模型系统的组合。实验结果表明，将恶意更改拆分为独立提交仅能使检测率最多改变五个百分点，说明提交边界本身不是导致逃逸的关键因素；相比之下，在单个 PR 内部以 N=16 的粒度交错放置恶意代码可将检测率降低 5-13 个百分点，而通过连贯的载体融合（将良性变更与恶意载荷包装成一致的叙事）可进一步降低 10-18 个百分点。当审查窗口扩大到整个仓库历史（N=24）时，检测率降至 16-22%，远低于按 PR 独立审查时的 50-60%。这些发现表明，仅仅让审计器访问完整历史记录并不能有效防御隐蔽攻击；攻击者更可能在良性变更与恶意更改共同占据审计上下文时，或通过构造貌似合理的 PR 描述来掩盖异常 diff。该研究为 LLM 驱动的代码审计系统提供了首个系统性的对抗性评估框架，揭示了当前方法在长程、上下文融合攻击下的显著弱点。

本研究针对自主编码智能体（Autonomous Coding Agents）在代码生成过程中引入的安全债务（Security Debt）进行了大规模实证分析。随着AI驱动的编码工具日益普及，它们能够自动生成并提交拉取请求（PR），但由此产生的安全风险尚未得到系统评估。作者利用AIDev数据集，对3,022个由智能体生成的PR中的16,112个文件变更进行了研究，采用经过验证的LLM-as-a-Judge框架结合人工定性分析，分类统计了安全代码异味（Security Code Smells）。研究发现，38.9%的智能体生成PR至少包含一个安全异味，其中供应链完整性问题占所有检测到的安全异味的82.3%（如依赖注入、包篡改等）。更为关键的是，严重程度最高的安全异味中，硬编码凭证（如明文API密钥、密码）占比高达99.6%。进一步分析表明，在智能体辅助的工作流中，人类协作者实际引入了67.6%的真实机密泄露，而现有的自动和人工审查流程在集成前未能检测到81.1%的这类凭证。这些结果揭示了智能体辅助软件开发中存在的实质安全风险，并暗示开发者警惕性可能因依赖AI而下降。研究强调了在人类-AI协作点直接实施上下文感知的安全护栏（Context-Aware Security Guardrails）的迫切性。该工作为安全从业者理解LLM编码工具的风险提供了量化依据，并呼吁将安全审查机制前置。

该论文提出将代码审查作为在线安全研究的新方法，以解决传统编程任务耗时、成本高、样本量小的问题。作者招募自由职业开发者对密码存储代码片段进行代码审查，以评估其安全意识和行为。实验中，一半参与者被明确提示关注安全性，另一半未提示。结果显示，尽管开发者自认为对安全负有责任，但大多数人在代码审查中并未关注安全，近半数甚至希望发布有安全漏洞的代码。然而，安全提示显著提升了安全关注度。论文还将结果与先前使用编程任务的密码存储研究进行对比，讨论了代码审查方法的优劣。该研究为未来开发者安全研究提供了低成本、高效率的替代方案，适合研究人机交互安全、开发者行为和安全教育的学者阅读。