BugScribe: LLM GUI-grounded Bug Reports

BugScribe：当 LLM 学会"看图说话"，Bug Report 质量能提升多少？

论文信息

• 论文：
• 团队：Antu Saha、Atish Kumar Dipongkor（University of Central Florida）、Sam Bennett、Oscar Chaparro（William & Mary）、Kevin Moran（University of Central Florida）、Andrian Marcus（George Mason University）
• 提交日期：2026 年 4 月 1 日
• 分类：Software Engineering (cs.SE)

核心问题：为什么这件事重要？

你有没有遇到过这样的场景——测试同学提了一个 Bug，描述只有一句话"登录页面点不了"，没有复现步骤，没有期望行为，甚至连在哪个页面点的都没说。然后开发花半小时去猜、去试、去反复沟通，最后发现是一个弹窗遮挡了按钮。

低质量 Bug Report 是软件工程中最大的隐性浪费之一。 研究表明，模糊或不完整的 Bug Report 会导致修复延迟、问题被重新打开、甚至产生错误修复。一个高质量的 Bug Report 至少需要包含三个核心要素：观测行为（Observed Behavior）——实际发生了什么；期望行为（Expected Behavior）——应该发生什么；以及复现步骤（Steps to Reproduce）——怎么重现这个问题。但现实是，大量 Bug Report 经常缺失其中一到两个要素，甚至全部缺失。

这个问题在移动端尤其严重。移动 App 的 Bug 几乎都是 GUI 层面可观察的——屏幕闪烁、按钮无响应、页面崩溃——但要把这些视觉现象精确描述为一条"原子级"的复现步骤（比如"在主屏幕点击右上角更多选项按钮，在弹出菜单中点击恢复备份"），对普通用户和测试人员来说都是高难度操作。BugScribe 要解决的正是这个断层：让 LLM 结合 App 的 GUI 执行数据，自动生成高质量的 Bug Report。

关键数据：数字说话

BugScribe 在 48 份来自 26 个 Android App 的真实 Bug Report 上进行了评估，并与原始报告、最新 LLM 基线方法 U2Sbr（2025 年发表，将非结构化 Bug 摘要重写为结构化报告）、以及两个不使用 App 上下文信息的 LLM 基线进行了对比：

• 指标 | 相对提升幅度
• S2R 质量（相比原始报告和基线） | +44.1% ~ +82.3%
• OB/EB 质量（相比原始报告和 LLM 基线） | +3.8% ~ +35.2%

这意味着什么？原始 Bug Report 中经常出现的"在某处点了某按钮"这种模糊描述，被 BugScribe 替换成了精确到具体 GUI 组件和屏幕的原子级步骤。OB 和 EB 的正确率也有显著提升——不再是"App 不好用了"这种废话，而是"在扩展选项弹出菜单中点击恢复备份后，App 发生崩溃"。

论文还通过数据驱动的方法，系统评估了四种 App 相关信息（原始报告文本、GUI 交互序列、App 屏幕信息、疑似 Bug 屏幕）的 16 种组合，发现 不同组件（OB/EB/S2R）需要不同的最优信息组合——这打破了"给 LLM 更多上下文就一定更好"的朴素假设。

技术架构/设计

BugScribe 的架构分为三个核心阶段，形成了一个 "建模 → 提取 → 生成" 的管道：

• ① App 执行模型构建：通过自动化 + 手动探索 App，构建一个 有向图执行模型。图中节点代表 App 的唯一 GUI 屏幕，边代表 GUI 交互（点击、输入、滑动），并附带 UI 元数据（布局层次、组件属性、事件绑定）。这本质上是把 App 的交互路径"数字化"了。
• ② 上下文信息提取：从执行模型中提取四种关键信息——原始报告中的 OB/EB/S2R 句子、GUI 交互序列、相关屏幕描述、疑似 Bug 屏幕——并通过 LLM 语义推理将它们格式化为自然语言描述。这是让"结构化数据"变为"LLM 可理解的文本"的关键一步。
• ③ 零样本任务分解生成：使用 zero-shot task-decomposition prompting（零样本任务分解提示），将复杂的 Bug Report 生成拆分为多个子任务：先对齐报告文本与执行数据推断复现场景，再分别生成 OB、EB、S2R 描述。每个子任务使用专门设计的 prompt，避免单一 prompt 的信息过载。
• ④ 统一质量评估框架：论文贡献了一个全新的 Bug Report 质量模型，从 正确性（Correctness） 和 完整性（Completeness） 两个维度评估 OB、EB、S2R。S2R 细分为正确步骤、模糊步骤、多余步骤、缺失步骤四类；OB/EB 细分为正确、不完整、模糊、错误、缺失五个质量属性。
• ⑤ 模型无关性验证：论文分别使用 GPT-5.4 和 Claude Opus 4.6 作为底层 LLM 进行评估，验证了 BugScribe 的方法论不依赖于特定模型，具有良好的泛化性。

关键洞察

🔑 洞察一：LLM 的"幻觉"问题在 Bug Report 生成中尤为致命

大多数 LLM 应用中，幻觉（hallucination）可能只是生成了一些不准确的内容。但在 Bug Report 场景中，一个错误的复现步骤可能让开发者白忙几小时。BugScribe 的核心创新在于：不是让 LLM 凭空编造复现步骤，而是将 App 的真实 GUI 执行路径作为"锚点"，让 LLM 的生成被约束在事实范围内。这实际上是一种 "结构化 grounding"——用程序分析的结果锚定 LLM 的生成，而不是完全依赖模型的推理能力。

🔑 洞察二：上下文不是越多越好，而是要"对症下药"

论文的一个重要发现是：OB、EB、S2R 各自需要不同的最优上下文组合。比如，生成精确的 S2R 需要 GUI 交互序列 + 屏幕信息，而生成 OB 则更依赖原始报告文本 + 疑似 Bug 屏幕。盲目塞入所有可用信息反而会引入噪声，降低生成质量。这个发现对所有基于 RAG（检索增强生成）的 AI 应用都有启示意义——精准检索比全面检索更重要。

🔑 洞察三：Bug Report 质量需要"可量化"的标准

过去，Bug Report 的质量评估高度依赖人工判断，缺乏统一、可复现的量化框架。BugScribe 提出的质量模型首次将 OB/EB/S2R 的质量分解为可操作的维度（正确/模糊/缺失/多余/错误），使得自动化评估成为可能。这不仅服务于 BugScribe 本身，更为整个软件工程领域的 Bug Report 质量研究提供了通用度量标准。

🔑 洞察四：从"辅助工具"到"自动生成"的范式转变

之前的研究大多停留在"检测问题 → 给出建议 → 用户自己改"的模式。BugScribe 是第一个真正实现 端到端自动生成 高质量 Bug Report 的方案。它不告诉用户"你的 S2R 不完整"，而是直接给你一份完整的、精确的报告。这种从"辅助"到"替代"的范式转变，是 AI Agent 在软件工程领域落地的一个缩影。

引发思考：这对行业意味着什么？

BugScribe 揭示了一个更大的趋势：AI 正在重新定义软件工程中的"人机协作"边界。 传统上，写 Bug Report 是一个纯人工任务——需要人观察、人描述、人组织。BugScribe 证明了，只要给 LLM 足够的结构化上下文（GUI 执行数据），它就能完成甚至超越人类的报告质量。这意味着，未来 QA 工程师的角色可能从"写报告"转向"设计探索策略和验证 AI 生成的报告"。

更值得关注的是，BugScribe 的方法论 不限于移动端。任何 GUI 密集型应用——桌面软件、Web 应用、甚至嵌入式系统的控制面板——都可以借鉴"构建执行模型 + 结构化 grounding + 任务分解生成"的思路。随着 AI Agent 在 Harness Engineering 领域的深入，我们有理由相信，Bug Report 自动生成只是第一步，下一步是自动定位 Bug、自动生成修复补丁、自动验证修复——形成一个完整的"感知-报告-修复-验证"闭环。

相关阅读

• 论文原文（arXiv:2604.01148）https://arxiv.org/abs/2604.01148
• 论文 HTML 全文https://arxiv.org/html/2604.01148v1
• U2Sbr: LLM-based Bug Report Generation（2025）https://arxiv.org/search/?query=U2Sbr+bug+report — BugScribe 的主要对比基线
• Chaparro et al., 2019: S2R 质量模型https://scholar.google.com/scholar?q=Chaparro+steps+to+reproduce+quality — BugScribe 质量框架的理论基础
• Song et al., 2022: 基于图的 App 执行建模https://scholar.google.com/scholar?q=Song+graph+based+app+execution+model — BugScribe 执行模型的参考来源

*逍遥云初 | 2026.04.03*