[Paper] 研究与自动化软件质量问题的解决

Source: arXiv - 2512.10238v1

概览

本文解决了开发者日常工作中最痛苦的环节之一：将嘈杂、不完整的 bug 报告转化为可工作的修复。通过将大语言模型（LLM）与领域特定线索相结合，作者不仅揭示了当前问题追踪流水线为何会失效，还提供了具体工具，能够自动提升报告质量、映射真实的开发者工作流，甚至为 UI 相关的 bug 提出修复建议。其结果是一条将问题解决转变为更数据驱动、AI 辅助的流程路线图。

关键贡献

• LLM 增强的 issue 报告润色： 一种利用 LLM 推理结合项目特定元数据（如堆栈跟踪、组件映射）自动重写低质量 bug 报告，使其更清晰、可操作的技术。
• 经验工作流特征化： 对开发者在传统（手动）和 AI 增强环境中处理 issue 的大规模研究，揭示瓶颈、决策点以及 AI 建议对解决时间的影响。
• 自动化 UI‑bug 定位： 一个机器学习流水线，精准定位导致视觉缺陷的 UI 组件，减少开发者通常花费的“搜索‑替换”工作量。
• 通过 LLM 进行解决方案识别： 一种方法，使用精心设计的提示并检索相关代码片段，查询 LLM 以提出具体的补丁或配置更改。
• 开源工具套件： 作者发布了一套脚本、模型以及面向流行 issue 跟踪系统（GitHub、Jira）的集成钩子，开发者可以立即将其接入 CI/CD 流水线。

方法论

1. 数据收集： 本研究从开源仓库中挖掘了数百万条 issue 报告，提取了高质量（描述详尽）和低质量（信息稀疏）的工单。
2. LLM 提示工程： 定制提示用于让模型“澄清”“扩展”或“概括”报告，同时输入文件路径、最近提交、组件层级等辅助数据。
3. 工作流观察： 研究人员在开发环境中植入仪器（IDE 插件、Git 钩子），记录开发者在有无 AI 辅助下与工单的交互方式。
4. UI 定位模型： 将静态 UI 元数据（布局树）与动态截图结合，输入到基于 CNN 的分类器中，以预测出错的 widget。
5. 解决方案生成： 检索增强生成（RAG）流水线检索相似的历史 bug，将其喂给 LLM，并对输出进行后处理，生成可自动审查的 diff。
6. 评估： 团队测量了 (a) 报告完整性提升（相对于人工重写工单的 BLEU/ROUGE 分数），(b) 平均解决时间（MTTR）下降，和 (c) UI 定位及建议补丁的精确率/召回率。

结果与发现

关键要点：LLM 辅助的重写使工单更具可操作性，AI 增强的工作流将解决时间缩短约三分之一，UI 定位模型在大多数情况下能够正确识别有问题的 widget，从而加速调试。补丁建议引擎虽不完美，但接受率翻倍，显著提升了 AI 生成修复的实用性。

实际意义

• 更快的分流： 团队可以将报告润色服务接入 issue 跟踪器的 webhook，自动在工单进入待办列之前升级模糊的 ticket。
• 降低调试开销： UI 团队可将定位模型集成到测试流水线；一次失败的视觉测试即可即时指向可疑组件。
• AI 优先的代码审查： 解决方案识别流水线可以作为 Pull Request 的“建议修复”评论，给审查者提供起点，缩短审查周期。
• 基于指标的流程改进： 通过记录 AI 增强工作流数据，管理者能够 pinpoint 人工交接仍导致延迟的环节，并针对性地投入培训或工具。
• 开源采纳： 由于作者在 MIT 许可证下发布工具，小团队可以无供应商锁定地进行实验，大企业则可在专有数据上微调模型以获得更高准确率。

局限性与未来工作

• 领域特异性： LLM 提示策略依赖项目特定元数据；在全新领域的应用可能需要额外的微调。
• UI 多样性： 定位模型主要在基于 Web 的框架（React、Angular）上训练，原生移动或桌面 UI 堆栈的精度较低。
• 仍需人工监督： 建议的补丁并非可直接投产，开发者必须审查并测试，这限制了自动化的上限。
• 数据收集的可扩展性： 大规模对开发者工作流进行仪器化会引发隐私和性能问题，需要谨慎处理。

未来方向包括将 UI 定位流水线扩展到跨平台框架，探索 few‑shot 提示以降低对大量项目元数据的依赖，并构建一个反馈回路，使被接受的 AI 修复持续微调底层模型。

作者

• Antu Saha

论文信息

• arXiv ID: 2512.10238v1
• 分类: cs.SE
• 发表时间: 2025 年 12 月 11 日
• PDF: Download PDF