Hacker News· azhenley·· 6 天前AI 评分49
软件工厂该不该「熄灯」？CRBugBench 评测 AI 代码审查智能体
Should a software factory be lights-off?
AI 导读
研究者构建 CRBugBench 基准，用 98 个开源 GitHub 仓库的 1,000 个审查任务和某大公司 800 个专有仓库任务，评估审查智能体能否发现人工确认的 bug。
正文 · AI 翻译
摘要：随着编码智能体的进步，软件开发人员花在审查代码上的时间已超过编写代码。由于人工审查速度落后于智能体代码生成，人们很容易想要构建自动化审查智能体，以迈向一个几乎无需人工监督的“熄灯”软件工厂的未来。为评估这种完全自主软件工厂的可行性，我们构建了 CRBugBench，这是一个评估审查智能体能否检测出经人工验证的缺陷的新基准。我们构建了一条数据流水线，从仓库历史中挖掘缺陷，并将每个缺陷与其引入该缺陷的 PR 配对，形成一项审查任务。CRBugBench 包含来自 98 个开源 GitHub 仓库的 1,000 项审查任务，以及来自一家大型公司专有行业仓库的 800 项额外任务。
随后我们使用该基准研究智能体审查质量：我们发现 SOTA 审查智能体表现良好：最佳者（claude-opus-5 搭配 copilot-cli）在其前 5 条评论中捕获了 71.9% 的缺陷，而在五个月的模型演进中，这一数字从 47.7%（opus-4.6）提升而来。然而，智能体在复杂变更和需要非局部推理的缺陷上仍然效果较差，在更常需要项目上下文的专有行业仓库上性能急剧下降。为提升缺陷检测，我们发现扩展计算量最有效的途径是通过提示词变更：探索引导型提示词在成本增加 10% 的情况下可获得最高 5.8% 的性能提升。基于这些发现，我们为开发者采用审查智能体得出了具体指导——按 PR 复杂度扩展审查投入、按项目优先级引导智能体、提供仓库知识、按 PR 特征分派模型，以及随着模型演进监控质量。
| 主题： | 软件工程（cs.SE） |
| 引用为： | arXiv:2610.13668 [cs.SE] |
| （或 arXiv:2610.13668v1 [cs.SE] 用于此版本） | |
| https://doi.org/10.48550/arXiv.2610.13668 由 DataCite 颁发的 arXiv DOI（待注册） |
提交历史
来自：Chenyang Yang [查看邮箱]
[v1]
2026年10月9日星期五 14:37:15 UTC（1,096 KB）
来源：Hacker News · arxiv.org