公开论文雷达

公开 arXiv 研究简报 · 2026-08-11T00:48:51.894949+00:00

先看结论和关键数字,再决定要不要读原文。候选只在首次出现时展示;旧候选若后来通过深读门槛,仍会进入重点。

别信标签:VRT和重构的隐藏效应都得实测

两篇都在拆同一个假设:某个动作只影响它名义上的范围。VRT不止查样式,18.5%失败根因是功能缺陷;重构不改功能却会改能耗,51.8%受控配对差异显著;共同结论:别拿类型标签或LLM当结论,得实测。先读VRT,落地成本低。

推荐阅读顺序

  1. 2608.07020:落地成本低:直接改你PR里的报警处置——先查根因再定是不是样式误报。
  2. 2608.06620:再读它补测量方法论:重构要在多负载下实测,别信度量或LLM预测。
共性方法
两项都是实证研究,都在推翻一个省事的默认:把动作限定在名义范围内(VRT=只查样式,重构=零风险不改行为)。都发现范围外的真实效应,也都警告别用便捷代理(把报警当误报关掉、用类型或LLM下结论)替代对根因和实测的检查。
关键分歧
方向相反:VRT那篇说工具比预想更有用(额外抓到功能缺陷),且信号在真实PR里很强(评论数是对照10倍);重构那篇讲的是隐藏风险,而且信号在真实提交里偏弱(仅7.5%显著),换负载还会让结论反转(45.3%跨负载改分类)。
选择准则
看到VRT报警,先查根因是不是功能缺陷,别默认样式误报关掉;要评估重构能耗,就在多种代表性负载下实测前后,别拿重构类型或LLM预测当依据。

重点深读(2 / 2 篇)

形式化与程序验证(0 篇)

本轮没有通过深读证据门的重点论文。

软件工程与仓库智能(1 篇)

软件工程与仓库智能 7/30

What Are Developers Actually Discussing When Visual Regression Tests Fail?

视觉回归测试抓到的不只是样式:18.5%的失败根因是功能性缺陷:如果你把视觉回归测试(VRT)只当作查样式跑偏的工具,这条结论会影响你怎么处理它的报警:实证分析显示,VRT标记的问题中有18.5%(35/189)根因是非样式缺陷,比如内容消失和未定义组件状态。研究者对103个GitHub仓库的307个VRT-PR和299个对照PR做了对比,并人工分类了189个VRT标注问题。

两句看懂

主流假设VRT只检测样式回归,这项研究对307个VRT-PR和299个对照PR做了实证比较,并人工分类了189个已标注问题。结果显示VRT-PR的中位解决时间是对照组3.8倍、评论数10倍,且18.5%(35/189)问题的根因是非样式缺陷。

核心判断

VRT不只是样式检查器,还能检测非样式的功能回归(18.5%,35/189)。证据来自307个真实PR的实证对比和189个问题的人工分类,确认的根因包括未定义组件状态,以及无关文件变更引发的非本地视觉副作用。

关键要点

1. 旧假设:VRT只捕获布局偏移、颜色不一致、字体变化等样式问题,此前没有实证研究在PR评审语境中分析它的实际作用。 2. 方法与对照:从103个GitHub仓库收集307个Chromatic VRT-PR与299个含图片但无VRT的Visual PR,对189个标注问题卡片分类为7类,并对比接受率、解决时间、评论数、变更文件数。 3. 结果与行动:样式类占主导(Layout 39.7%),但35/189(18.5%)是非样式根因,VRT-PR评论数是对照组10倍——VRT报警应先查根因,不能直接当误报关闭。

证据与结果

数据集:103个GitHub公开仓库,307个VRT-PR(使用Chromatic/Storybook)和299个Visual PR(含图片附件但无VRT)。问题层面:189个VRT标注问题,7类分布为Layout 39.7%、Appearance 27.5%、Color 14.8%、Text 9.5%、State 6.9%、Test 6.3%、Image 4.2%。PR级别:接受率无显著差异;VRT-PR中位解决时间是Visual PR的3.8倍,评论数10倍,代码变更量1.75至4.5倍,变更文件数中位数1.75倍。非样式根因35/189(18.5%):内容消失17例、未定义组件状态13例、视觉不可感知回归5例。

打开论文原文
它要解决什么
视觉回归测试在真实PR评审中到底捕获哪些缺陷?它的检测范围是否超出了设计预设的纯样式回归范畴?
研究路径
研究者通过GitHub识别与Chromatic关联的PR,提取VRT截图和评论内容;对189个VRT标注问题用卡片分类法归入7个缺陷类别;对307个VRT-PR和299个Visual PR统计接受率、中位解决时间、评论数、变更文件数,量化两组PR级别差异;同时记录VRT结果在PR时间线中的共享位置,判断它在评审流程中的作用节点——结果多在中点共享,说明它能持续驱动评审讨论。
这对工程意味着什么
第一步行动:VRT标记问题时,先检查根因是否为非样式缺陷(组件状态、内容消失),再决定如何处理。要避免的捷径:把VRT报警默认当作样式误报直接关掉,或只把它放在流程末尾当检查门。
证据定位
VRT-PR的中位解决时间是对照组的3.8倍,评论数是10倍,代码变更量是1.75至4.5倍,变更文件数中位数是1.75倍;接受率无显著差异。189个问题中,Layout占39.7%、Appearance 27.5%、Color 14.8%、Text 9.5%、State 6.9%、Test 6.3%、Image 4.2%;(筛选维度:软件工程方法、GUI Agent 方法)
适用边界
数据只覆盖使用Chromatic和Storybook的公开GitHub仓库,不代表使用Percy等其他VRT工具的团队;189个问题的卡片分类存在主观性,类别边界依赖编码者判断;样本限于公开仓库,私有项目的VRT实践模式可能不同。
方法与英文摘要

从GitHub识别与Chromatic关联的PR,收集103个仓库的307个VRT-PR,以及299个含图片附件但无VRT的Visual PR作对照。对VRT-PR中189个已标注问题做人工卡片分类,归入Layout、Appearance、Color、Text、State、Test、Image七类;同时统计PR级别指标:接受率、中位解决时间、评论数、变更文件数和代码行数变化,并记录VRT结果在PR时间线中的共享位置。

Visual Regression Tests (VRTs) are widely adopted as a mechanism for detecting unintended visual changes in user interfaces. By design, VRTs operate on rendered pixel output, and the prevailing assumption is that they catch stylistic regressions such as layout shifts, color mismatches, and font alterations. We conduct an empirical analysis of 307 pull requests (PRs) from 103 GitHub repositories that incorporate VRT results via Chromatic, comparing them against 299 PRs that contain image attachments but no VRT (Visual PRs). Quantitatively, VRT-PRs show no significant acceptance-rate difference, but exhibit a 3.8 times longer median resolution time, 10 times more discussion comments, and 1.75 to 4.5 times larger code changes than Visual PRs. VRT results are typically shared around the midpoint of the review process, sustaining ongoing discussion rather than serving only as a final check. Through a card-sorting analysis of 189 VRT-flagged issues, we identify seven defect categories assigned to the analyzed issues: Layout (39.7\%), Appearance (27.5\%), Color (14.8\%), Text (9.5\%), State (6.9\%), Test (6.3\%), and Image (4.2\%). The three most frequent categories are stylistic, while approximately 18.5\% of analyzed issues (35/189) involve non-stylistic origins, including undefined component state (13 cases), content disappearance (17 cases across multiple categories), and visually imperceptible regressions (5 cases). We further document cases in which VRT detected visual regressions originating from code changes in seemingly unrelated files, exposing non-local effects that no targeted test would have been written to catch. These observations indicate that, in addition to its primary role as a stylistic checker, VRT functions as a secondary detector of unintended consequences of code changes, with implications for how VRT should be integrated into the maintenance toolchain.

代码质量与优化(1 篇)

代码质量与优化 7/30

Understanding the Energy Impact of Software Refactoring: A Workload-Aware Study of Controlled Examples and Real-World Commits

重构不改功能,却会改能耗:近一半受控配对差异显著,类型判断和LLM都靠不住:如果你把重构当成“零风险”提交,这份数据会直接推翻这个假设。作者用两套Java基准做重复配对能耗测量:68种重构类型×多负载组成384个受控配对,再从430个GitHub项目取481条真实重构提交。结果是51.8%受控重构-负载对能耗差异显著,45.3%跨负载改变分类;代码度量和LLM预测器都不能可靠识别能耗回归。

两句看懂

过去常在固定或简单负载下评测孤立重构,覆盖不了负载变化和真实提交的能耗行为;这项研究用两套Java基准加多负载重复配对测量补齐这块。受控384对中51.8%能耗差异显著且45.3%跨负载改分类,真实481条提交中度量和LLM预测都不可靠。

核心判断

行为等价不等于能耗中立:51.8%受控重构-负载对能耗差异显著,45.3%跨负载改变分类;度量和LLM预测器都不能可靠识别回归,多负载实测是必要条件。

关键要点

1. 旧假设是固定负载下的重构能耗结论可泛化,但45.3%实例跨负载改变分类,单一负载测试有系统性盲区。 2. 方法用68种重构类型×多负载生成384个受控配对并重复测量,再用430个GitHub项目481条真实提交核对,同时对照代码度量和LLM两类识别。 3. 384对中199对(51.8%)显著;真实提交仅36/481(7.5%)显著但三分之二偏差≥10%;度量和LLM均不可靠,所以要在多负载下实测,不要用类型或预测替代。

证据与结果

受控侧:68种重构类型×多工作负载=384对,199对(51.8%)能耗差异显著,45.3%实例跨负载改变能耗分类。真实侧:430个GitHub Java项目、481条重构提交,仅36条(7.5%)显著,但三分之二偏差≥10%。执行时间在受控基准中稳定解释能耗,在实用基准中相关性弱。代码度量和LLM回归识别均不可靠。特定重构组合与能耗降低相关,但单一重构类型不足以预测能耗结果。

打开论文原文
它要解决什么
代码重构会不会改变能耗?换负载后结论会不会反转?现有代码度量和LLM方法能否识别重构引入的能耗回归?
研究路径
微基准对68种重构类型在多种工作负载下生成384个配对,重复配对测量重构前后能耗。实用基准从430个GitHub Java项目提取481条真实重构提交,做同样配对测量。两套基准分别检查执行时间变化的解释力,并把代码度量和LLM的识别结果与实测结果对比。
这对工程意味着什么
第一步行动:在CI或代码审查里,给重构提交补一组多负载能耗实测。要避开的捷径:别用重构类型判断或LLM预测替代实测,两者在真实提交中都不可靠,负载不匹配时分类还会反转。
证据定位
微基准384对中199对(51.8%)能耗差异显著,45.3%实例跨负载改变分类。实用基准481条提交中仅36条(7.5%)显著,但三分之二偏差≥10%。执行时间只在受控基准中稳定解释能耗,在真实提交中相关性弱。度量和LLM识别均不可靠。(筛选维度:可复核评测、软件工程方法)
适用边界
研究限于Java生态。微基准是受控人工示例,可能覆盖不了所有真实代码结构。实用基准481条提交中只有7.5%达到统计显著,能效信号整体偏弱。LLM预测器的提示配置在摘录中未充分说明。
方法与英文摘要

做两套Java基准并重复配对测能耗。微基准用68种重构类型×多种工作负载形成384个配对;实用基准从430个GitHub Java项目取481条真实重构提交。两套都分析负载敏感性、重构组合、执行时间等解释因素,并对照评估代码度量和LLM两类回归识别手段。

Refactoring improves software maintainability while preserving functional behavior, yet behavior preservation does not imply energy neutrality. Existing studies primarily examine isolated refactorings under fixed or simple workloads, leaving the effects of workload variation, real-world refactoring practices, explanatory factors, and energy regression identification insufficiently understood. We present the first large-scale empirical study of the energy impact of refactoring across two complementary Java benchmarks: a Micro-benchmark, comprising 68 refactoring types evaluated under diverse workloads, and a Practical-benchmark, containing 481 real-world refactoring commits from 430 GitHub projects. Using repeated paired energy measurements, we analyze workload sensitivity, refactoring patterns, explanatory factors, and the effectiveness of metric- and LLM-based regression identification. In the Micro-benchmark, 199 of 384 refactoring-workload pairs (51.8%) exhibit statistically significant energy differences, and 45.3% of refactoring instances change energy-impact classification across workloads. In the Practical-benchmark, only 36 commits (7.5%) show significant energy changes, although two-thirds differ by at least 10%. Refactoring type alone is insufficient to predict energy outcomes, while certain recurring refactoring combinations are associated with energy reductions. Changes in execution time consistently explain energy variation in the controlled benchmark but correlate weakly with energy changes in real-world commits. Our findings highlight the need for workload-diverse evaluation of the energy impact of refactoring; neither existing metric-based approaches nor LLM-based predictors can reliably identify refactoring-induced energy regressions, motivating the development of more accurate techniques for predicting the energy impact of refactoring.

UI 与 GUI Agent(0 篇)

本轮没有通过深读证据门的重点论文。

个人知识与本体(0 篇)

本轮没有通过深读证据门的重点论文。

人机协同与对齐(0 篇)

本轮没有通过深读证据门的重点论文。

本轮分类概览

同一论文只归入一个最先命中的赛道,避免重复计数;“新增候选”只统计首次展示的论文。

赛道新增候选重点
形式化与程序验证00
软件工程与仓库智能21
代码质量与优化11
UI 与 GUI Agent00
个人知识与本体30
人机协同与对齐00

近一个季度监测日历

北京时间。绿色表示有可阅读的新候选,灰蓝表示已监测但无新增,橙色表示部分降级;“无记录”不等于失败。

2026 年 6 月

1无记录2无记录3无记录4无记录5无记录6无记录7无记录8无记录9无记录10无记录11无记录12无记录13无记录14无记录15无记录16无记录17无记录18无记录19无记录20无记录21无记录22无记录23无记录24无记录25无记录26无记录27无记录28无记录29无记录30无记录

近 14 次监测窗口

仅展示公开源的聚合运行状态,不含提示词、全文或个人数据。

本轮新增候选(6 篇)

按赛道、评分和日期展开;中文标签用于导航,英文摘要用于核验。已展示过的旧候选不会每日重复。

形式化与程序验证(0 篇)

本轮该赛道没有候选论文。

软件工程与仓库智能(2 篇)

软件工程与仓库智能 · 7/30 · 2026-08-07视觉回归测试失败时开发者在讨论什么基于307个含视觉回归测试的PR与299个普通PR对比:修复耗时与讨论量显著更高,代码改动更大。What Are Developers Actually Discussing When Visual Regression Tests Fail?

Visual Regression Tests (VRTs) are widely adopted as a mechanism for detecting unintended visual changes in user interfaces. By design, VRTs operate on rendered pixel output, and the prevailing assumption is that they catch stylistic regressions such as layout shifts, color mismatches, and font alterations. We conduct an empirical analysis of 307 pull requests (PRs) from 103 GitHub repositories that incorporate VRT results via Chromatic, comparing them against 299 PRs that contain image attachments but no VRT (Visual PRs). Quantitatively, VRT-PRs show no significant acceptance-rate difference, but exhibit a 3.8 times longer median resolution time, 10 times more discussion comments, and 1.75 to 4.5 times larger code changes than Visual PRs. VRT results are typically shared around the midpoint of the review process, sustaining ongoing discussion rather than serving only as a final check. Through a card-sorting analysis of 189 VRT-flagged issues, we identify seven defect categories assigned to the analyzed issues: Layout (39.7\%), Appearance (27.5\%), Color (14.8\%), Text (9.5\%), State (6.9\%), Test (6.3\%), and Image (4.2\%). The three most frequent categories are stylistic, while approximately 18.5\% of analyzed issues (35/189) involve non-stylistic origins, including undefined component state (13 cases), content disappearance (17 cases across multiple categories), and visually imperceptible regressions (5 cases). We further document cases in which VRT detected visual regressions originating from code changes in seemingly unrelated files, exposing non-local effects that no targeted test would have been written to catch. These observations indicate that, in addition to its primary role as a stylistic checker, VRT functions as a secondary detector of unintended consequences of code changes, with implications for how VRT should be integrated into the maintenance toolchain.

阅读 arXiv 原文
软件工程与仓库智能 · 3/30 · 2026-08-06由解答自动生成评测器加速题目编写利用题目作者可提供解答这一特点,绕过手工枚举测试用例,更快更准确地生成自动评分器。Accelerating Accurate Assignment Authoring Using Solution-Generated Autograders

Students learning to program benefit from access to large numbers of practice problems. Autograders are commonly used to support programming questions by providing quick feedback on submissions. But authoring accurate autograders remains challenging. Autograders are frequently created by enumerating test cases--a tedious process that can produce inaccurate autograders that fail to correctly classify submissions. When authoring accurate autograders is slow, it is difficult to create large banks of practice problems to support beginning programmers. We present solution-generated autograding: a faster, more accurate, and more enjoyable way to create autograders. Our approach leverages a key difference between software testing and autograding: The question author can provide a solution. By starting with a solution, we can eliminate the need to manually enumerate test cases, validate the autograder's accuracy, and evaluate other aspects of submission code quality beyond behavioral correctness. We describe Questioner, an implementation of solution-generated autograding for Java and Kotlin, and share experiences from four years using Questioner to support a large CS1 course: authoring nearly 800 programming questions used by thousands of students to evaluate millions of submissions.

阅读 arXiv 原文

代码质量与优化(1 篇)

代码质量与优化 · 7/30 · 2026-08-06软件重构能耗影响的大规模实证研究基于68类微基准重构与481个真实重构提交,在不同工作负载下测量能耗,并考察指标与LLM回归识别。Understanding the Energy Impact of Software Refactoring: A Workload-Aware Study of Controlled Examples and Real-World Commits

Refactoring improves software maintainability while preserving functional behavior, yet behavior preservation does not imply energy neutrality. Existing studies primarily examine isolated refactorings under fixed or simple workloads, leaving the effects of workload variation, real-world refactoring practices, explanatory factors, and energy regression identification insufficiently understood. We present the first large-scale empirical study of the energy impact of refactoring across two complementary Java benchmarks: a Micro-benchmark, comprising 68 refactoring types evaluated under diverse workloads, and a Practical-benchmark, containing 481 real-world refactoring commits from 430 GitHub projects. Using repeated paired energy measurements, we analyze workload sensitivity, refactoring patterns, explanatory factors, and the effectiveness of metric- and LLM-based regression identification. In the Micro-benchmark, 199 of 384 refactoring-workload pairs (51.8%) exhibit statistically significant energy differences, and 45.3% of refactoring instances change energy-impact classification across workloads. In the Practical-benchmark, only 36 commits (7.5%) show significant energy changes, although two-thirds differ by at least 10%. Refactoring type alone is insufficient to predict energy outcomes, while certain recurring refactoring combinations are associated with energy reductions. Changes in execution time consistently explain energy variation in the controlled benchmark but correlate weakly with energy changes in real-world commits. Our findings highlight the need for workload-diverse evaluation of the energy impact of refactoring; neither existing metric-based approaches nor LLM-based predictors can reliably identify refactoring-induced energy regressions, motivating the development of more accurate techniques for predicting the energy impact of refactoring.

阅读 arXiv 原文

UI 与 GUI Agent(0 篇)

本轮该赛道没有候选论文。

个人知识与本体(3 篇)

个人知识与本体 · 3/30 · 2026-08-07层级教师记忆蒸馏赋能小型智能体通过工作流、子任务、函数三类层级记忆,将大教师智能体知识迁移给小模型,无需训练;在三个工具使用基准上评估。Agent Memory Distillation: Empowering Small LLM Agents with Hierarchical Teacher Memory

Memory systems have shown promise for improving agent performance, but their potential remains largely unexplored for small language models, which struggle to generate sufficient successful trajectories on their own. We propose Agent Memory Distillation (AMD), a training-free framework that transfers structured knowledge from a large teacher agent to a small student agent through hierarchical memory. AMD constructs three complementary memory types from successful teacher trajectories: Workflow memory encodes task-level strategies, Subtask memory provides concrete behavioral examples at an intermediate granularity, and Function memory captures per-function calling conventions and common pitfalls. Workflow and Subtask memories are injected proactively at the start of each task, while Function memory is retrieved reactively upon tool-calling errors. We evaluate AMD on three tool-use benchmarks using four student models (4B-8B parameters) with GPT-5-mini as the teacher, achieving average accuracy gains of 27.2%p, 11.2%p, and 3.4%p on AppWorld, BFCL V3, and ToolSandbox, while consistently outperforming existing memory-based baselines. Further analysis shows that Subtask memory contributes the largest gains, teacher effectiveness depends on both teacher capability and student compatibility, and 4B-sized students benefit most from AMD.

阅读 arXiv 原文
个人知识与本体 · 3/30 · 2026-08-07跨楼层多目标导航的持久3D语义记忆在未知多楼层环境中,以共享稀疏3D语义体素记忆持续累积场景信息,支持楼梯感知与跨楼层多目标搜索。LifelongCrossNav: Persistent 3D Semantic Memory for Cross-Floor Multi-Object Navigation

Object-goal navigation has made substantial progress in semantic perception and exploration, yet persistent memory for multi-object navigation and cross-floor navigation are still commonly addressed separately. We present LifelongCrossNav, a framework for sequential multi-object ObjectNav in unknown multi-floor indoor environments. Within each episode, the agent receives an ordered sequence of object-goal queries while continuously maintaining a shared sparse 3D semantic voxel memory. This memory incrementally accumulates geometric structure, traversability states, and vision-language features, allowing subsequent object-goal queries to retrieve previously acquired scene information without rebuilding the map. To support persistent search across floors, LifelongCrossNav combines support-aware 3D traversability mapping, stair-specific perception, and direction-aware stair traversal. A unified navigation policy coordinates same-floor frontier exploration, live and historical point-of-interest retrieval, stair navigation, and target-object search and approach. We further introduce HM3D-MFMON, a benchmark for sequential Multi-Floor Multi-Object Navigation built on HM3D scenes, including a dedicated subset in which completing the full sequence of object-goal subtasks requires at least one floor transition. Experimental results show that LifelongCrossNav consistently outperforms a representative planar persistent semantic-map baseline on HM3D-MFMON, demonstrating that persistent 3D semantic memory and cross-floor traversability modeling effectively support sequential multi-object navigation in multi-floor environments. Project page: https://flageval-baai.github.io/LifelongCrossNavPage.

阅读 arXiv 原文
个人知识与本体 · 4/30 · 2026-08-07显式立场标注更能在记忆压缩中幸存让立场成为标注字段而非括号附注,可显著提升压缩后保留率;预注册复制实验得到一致结论。Explicit, Not Longer: What Makes Epistemic Stance Survive Memory Compression

Agent memory systems compress what they store, and compression is built to drop qualifiers, so a claim's epistemic standing tends not to survive being written to memory. We ask what governs whether it does. Matched notes carry the identical claim and identical stance and differ only in where that stance sits; one model compresses both under the same budget among the same filler notes, and a blind reader that never sees the condition scores the result. Across 60 claims in seven registers, writing the stance as a labelled field rather than a bracketed aside raises retention by about 15 points on two models (37 claims to 2 on one, 30 to 8 on the other; permutation p=0.00005), and a pre-registered replication on Haiku, its prediction and decision rule committed before the run, gives +15.6 points, 38 claims to 1. Ablating the format on both models gives the same net effect from different parts: labels help on both (+9.7 and +12.8) and length helps on neither, but wording the stance as a full sentence is the largest component on one model (+12.5) and worth nothing on the other (+0.6). Either model alone would have licensed a confident and different mechanism, so we claim only the intersection: make the stance explicit, not merely longer, and expect the best way of being explicit to depend on the model. A deterministic readout with no model reproduces the two-cell direction and five of seven ablation contrasts, but not length or labels, which we therefore do not claim on one instrument. Fifty hand labels (kappa=0.75) agree on direction; we print their seven disagreements in full. We also report nine withdrawn claims, three of them former title claims of this paper.

阅读 arXiv 原文

人机协同与对齐(0 篇)

本轮该赛道没有候选论文。