公开论文雷达

公开 arXiv 研究简报 · 2026-09-11T00:40:46.758545+00:00

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

先看有实测的两篇:覆盖率和竞赛分数都在骗你

四张卡里只有两篇拿出了自己的实测数字。测试标准那篇在6066个较难缺陷上发现覆盖率和变异测试几乎查不出来,漏掉约99%;StochBench那篇450道随机过程Lean4题,最强agent只证出34.9%。另外两篇一篇是文献综述、一篇只是研究计划,没有自有实验,只能当方向提醒。

推荐阅读顺序

  1. 2609.09315:先读它。5个模型×4个基准的受控实验,6066个较难缺陷漏掉约99%,今天就能改你的代码验收方式。
  2. 2609.09264:第二读。450道题只证出34.9%,给了按领域分开测证明agent的具体做法,数字可复核。
  3. 2609.05667:第三读。没有自有实验,只引二手调查,当作把资源往需求侧挪的方向参考,别当证据。
  4. 2609.09975:最后读。只是立项计划,3-4对开源项目的案例还没做,眼下能拿走的只有一份检查清单思路。
共性方法
四篇讲的是同一件事:指标达标不等于问题被解决。覆盖率满分不代表缺陷被抓到,竞赛基准高分不代表随机过程题能证明,代码生成变快不代表需求说清楚了,项目能跑不代表架构决策有记录。
关键分歧
分歧在证据强度。两篇有自己的受控实验和数字(6066个缺陷、450道题),结论可以直接拿去改流程;另外两篇一篇只引二手调查、作者自己标注那是预期性证据,一篇连案例研究都还没开始。
选择准则
要动评测或验收流程,只认前两篇的数字;要定下一步投入方向,可以看后两篇,但别把它们的结论当成已验证的证据去说服别人。

重点深读(4 / 4 篇)

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

形式化与程序验证 6/30

StochBench: A Domain-Specific Benchmark for Stochastic Processes in Lean

最强证明agent在随机过程Lean4题目上只解出34.9%:竞赛基准测不出真实短板:如果你的团队用MiniF2F或PutnamBench的分数来判断证明agent能不能用在应用数学上,这个分数会误导你。StochBench用450道研究生随机过程Lean4证明题实测,Claude Opus 4.8驱动的agent只证出157题(34.9%),近三分之二在15分钟限时内失败。

两句看懂

竞赛数学基准无法反映随机过程等应用数学领域的证明能力,StochBench构建450道研究生级Lean4证明题填补这一空白。用Claude Opus 4.8驱动的编译器引导agent在15分钟/题限时下测试,整体证明率仅34.9%(157/450)。

核心判断

竞赛基准不能代表应用数学证明能力。证据:StochBench 450题上Opus 4.8代理证明率仅34.9%(157/450),15分钟限时下大量失败。

关键要点

1. 旧假设失效:MiniF2F、PutnamBench等竞赛基准规模小、覆盖窄,聚合分数掩盖领域强弱项,且随机过程在Mathlib中代表性不足。 2. 方法与受控检查:数学家从研究生教材人工构造450道Lean4题(114个direct、336个abstracted,覆盖8个主题),用Opus 4.8编译器引导agent证明,单题限时15分钟,Lean编译器验证结果。 3. 决定性结果:整体证明率仅34.9%(157/450)。做法是按领域细分单独评测,不要只看竞赛基准的聚合分数。

证据与结果

数据共450个Lean4定理目标,全部配自然语言原文,来自研究生教材与课堂讲义。分层:114个direct(25.3%,直接用Mathlib定义)与336个abstracted(74.7%,性质作为假设给出)。8个主题分布:DTMC 96、鞅94、随机游走62、布朗运动45、泊松40、CTMC 55、更新41、弱收敛17。评测按主题与表征方式分别报告,整体证明率34.9%(157/450)。

打开论文原文
它要解决什么
竞赛数学基准能否反映大模型在随机过程等应用数学领域的真实形式化证明能力?
研究路径
流程分四步:1)数学家从教材和讲义选取随机过程问题,配自然语言原文;2)人工加LLM辅助形式化为Lean4定理,复用共享Mathlib定义;3)按基础设施可用性分为direct和abstracted两类;4)Claude Opus 4.8驱动的agent根据编译器反馈逐题证明,单题15分钟上限,Lean编译器判定证明是否成立。
这对工程意味着什么
第一步行动:评测你的证明agent时,按领域(如随机过程)单独出题测试,看分主题结果。要避开的捷径:不要把竞赛基准的高分等同于应用数学场景下的可靠证明能力,34.9%的通过率说明鞅、停时等主题仍需专项支持。
证据定位
Opus 4.8代理在450题上整体证明率仅34.9%(157/450)。15分钟/题的限时下,近三分之二题目失败。结果按主题与direct/abstracted表征方式分别报告,说明当前最强证明agent在应用数学方向仍有明显短板。(筛选维度:形式化验证、可复核评测)
适用边界
题目的形式化定义与假设全部人工编写,作者说明其忠实性有待进一步同行评审。基准只聚焦随机过程单一领域,不代表其他应用数学子领域的证明难度。
方法与英文摘要

数学家从研究生随机过程教材与课堂讲义人工选题并配自然语言原文,再用LLM辅助形式化为Lean4,共450题。题目分两类:114个direct直接复用Mathlib共享定义,336个abstracted把所需性质作为假设给出。覆盖8个主题:DTMC 96、鞅94、随机游走62、布朗运动45、泊松40、CTMC 55、更新41、弱收敛17。评测用Claude Opus 4.8驱动的编译器引导agent逐题证明,单题限时15分钟,Lean编译器验证证明是否成立。

Leading benchmarks for formal theorem proving with large language models are small collections drawn from competition math, such as the IMO and Putnam, that poorly represent field-specific applications. We introduce StochBench, a Lean 4 benchmark of 450 graduate stochastic-processes problems at varying abstraction levels, each paired with its natural-language source. Addressing a field underrepresented in Mathlib, it covers finite and countable Markov chains, renewal processes, random walks, martingales, stopping times, queues, Brownian motion, stochastic calculus, weak convergence, and Poisson and continuous-time Markov processes. Our Opus 4.8-based agent achieves a 34.9% proof rate (157/450) under a 15-minute per-problem limit. StochBench better represents domain-specific applied mathematics while remaining challenging for advanced provers.

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

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

Socio-technical and Ethical Dimensions of Architecture Practices in FLOSS

开源架构决策为何总零散:这只是研究计划,尚无实证结果:你在开源项目里找不到当初为什么这样设计,这很常见:决策散落在issue、PR和邮件列表里,治理和伦理如何影响架构也没人整合研究过。这篇论文(ICSME 2026)提出一个三阶段方案去查清这件事——但它目前只是立项计划,没有案例结果,没有数据,没有可直接用的工具。

两句看懂

开源项目的架构决策常散落于issue、PR和邮件列表且未成文,该研究计划拟用案例研究、框架设计与试点评估三阶段来改善这一状况。论文目前只完成了研究设计和目标(O1-O4)的界定,3-4个FLOSS项目的案例研究尚未开展,没有任何实证数据。

核心判断

研究认为开源架构实践的关键问题在于制品记录、社区沟通、治理角色与伦理关切彼此割裂;但论文只提出了三阶段研究设计和四个目标(O1-O4)作为待验证方案,没有给出实证证据。

关键要点

1.旧问题:先前研究分散在五个方向(制品与架构侵蚀S1、知识沟通S2、治理与角色S3、伦理与生态健康S4、FLOSS教育S5),很少把架构工作与治理、伦理整合考察,所以决策为何不成文仍不清楚。2.方法与检验:三阶段协议——对3-4对同领域FLOSS项目做多方法案例研究,与实践者和教育者共同设计框架与轻量干预,再在真实项目与课程中试点评估,对应O1-O4。3.结论与行动:论文是研究计划,未报告任何结果、指标或有效性数据;读者现在能做的只是先自行把决策写成ADR并关联issue/PR,别等这个框架。

证据与结果

数据来源为3-4对同领域、架构非平凡的FLOSS项目(具体项目未列出)。评估分三阶段:案例研究(制品/沟通/治理多方法分析)、框架与干预设计(协作进行)、试点评估(真实项目与课程)。论文未报告任何指标、对比数字或案例结果,评估方式和成功标准在摘录中也未给出。

打开论文原文
它要解决什么
开源项目的架构决策为什么长期不成文、散落各处?治理机制和伦理关切如何塑造架构实践?教育中又该怎样呈现这些议题?
研究路径
机制分三步:①选取3-4对同领域、架构复杂的FLOSS项目做多方法案例研究,梳理制品(ADR、模块边界)、沟通渠道(issue/PR/邮件列表)与治理决策点;②与实践者和教育者协作,把案例发现转化为概念框架和轻量干预/教学形式;③在真实项目与课程中试点评估框架和教学形式的可用性。
这对工程意味着什么
第一步行动:现在就把关键架构决策写成ADR,并关联到对应的issue/PR,明确谁有权批准变更。要避免的捷径:不要以为这篇论文已经给了现成框架或工具——它只是研究计划,等它的结论再动流程会落空。
证据定位
论文是研究计划(ICSME 2026),尚未开展任何案例研究或试点评估,没有对比数据、指标或数字结果。案例样本仅3-4对项目,且具体项目未列出。(筛选维度:可复核评测、软件工程方法)
适用边界
案例样本仅3-4对FLOSS项目,代表性有限;框架与干预依赖与特定实践者、教育者协同设计,可能带有场景偏向;论文处于立项阶段,尚无实证验证结果。
方法与英文摘要

三阶段设计:(1)选3-4对同领域、架构非平凡的FLOSS项目做多方法案例研究,考察制品、沟通渠道与决策机制;(2)与实践者和教育者共同设计概念框架及轻量干预措施;(3)在真实项目与课程中做试点评估,对应目标O1-O4。

This project investigates how software architecture practices in Free/Libre Open Source Software (FLOSS) are shaped by socio-technical and ethical factors, and how education can support more explicit, inclusive, and reflective architectural work. Motivated by FLOSS's role in digital sovereignty, it is observed that architectural decisions are often undocumented and scattered across issues, pull requests, and mailing lists. While prior research has studied architectural artifacts, erosion, and communication, the interplay between architectural work, governance arrangements, and ethical commitments in FLOSS remains underexplored. The research follows a three-phase design: (1) multi-method case studies of 3-4 domain-pairs of architecturally non-trivial FLOSS projects, (2) framework and intervention design with practitioners and educators, and (3) pilot evaluations in projects and courses. It will produce (i) cross-case empirical evidence on FLOSS architecture practices, (ii) a conceptual framework linking architecture practices to socio-technical conditions and ethical dimensions, and (iii) lightweight practices and teaching formats that render architectural work more explicit and inclusive.

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

How effective are traditional test criteria at detecting bugs in large language models generated code?

传统覆盖率几乎查不出LLM代码里的难缺陷:该担心:团队常用语句覆盖、分支覆盖、变异分数判断AI生成代码是否测够;这项评测显示,在6066个较难缺陷上,三类标准检测率接近于零,遗漏约99%。方法是用5个LLM在4个基准上生成代码与测试,再按缺陷难度做受控检查。

两句看懂

传统语句覆盖、分支覆盖和变异测试按人写代码的错误模式设计,是否适用于LLM生成代码此前缺少验证。5个LLM×4个基准的受控评测显示,对6066个较难缺陷检测率接近于零、遗漏约99%,变异测试仅略好但成本高得多。

核心判断

传统测试标准基本查不出LLM生成代码中的难缺陷:对6066个较难缺陷,语句/分支覆盖与变异测试检测率接近零,遗漏约99%;证据来自5个LLM和4个基准的受控实验。

关键要点

1. 旧假设:覆盖率和变异测试按人工代码缺陷模式设计,LLM代码是否仍符合未验证。 2. 方法:4个基准补测试到近饱和,5个LLM生成代码,比对参考实现并从73785个缺陷中筛出6066个较难缺陷。 3. 结果与动作:检测率接近零、遗漏约99%;验收时查断言和关键分支,别只看覆盖率或变异分数。

证据与结果

基准为HumanEval+、MBPP、BigCodeBench、NaturalCodeBench;模型为GPT-5-Mini、GPT-4.1-Mini、Claude-Haiku4.5、Deepseek-v4-flash、Llama3.3-70B-Instruct。共收集73785个有效缺陷,剔除43272个易检测缺陷后余30513个较难缺陷,再按每任务最难1个取6066个做最终评测。比较语句覆盖、分支覆盖、变异测试的触发率与检测率:检测率接近0,遗漏约99%;变异测试仅略优于覆盖率,成本显著更高;prompt-aware oracle只部分提升检测且效果有限。

打开论文原文
它要解决什么
语句覆盖、分支覆盖、变异测试这些传统充分性标准,面对大语言模型生成代码时,还能否真正发现缺陷?
研究路径
失败点在断言,而不只在执行。实验先补测试使覆盖率/变异分数近饱和,再让5个LLM写代码,与参考实现比对得到73785个缺陷;剔除43272个易检测缺陷后,每任务只留最难1个,共6066个。随后按各标准采样达标测试,统计触发率与检测率;常见情况是测试前缀触发了错误行为,但断言没有捕捉到,所以覆盖达标仍漏缺陷。
这对工程意味着什么
第一步行动:抽查LLM代码的测试断言,确认错误行为被触发后断言真的会失败。要避开的捷径:把“覆盖率100%”或“变异分数高”当成缺陷已检测到的证明。
证据定位
对6066个较难缺陷,语句覆盖、分支覆盖、变异测试的实际检测率接近于零,遗漏约99%;变异测试只略优于覆盖率标准,但应用成本高得多;prompt-aware oracle可提升部分检测,效果仍有限。(筛选维度:可复核评测、软件工程方法)
适用边界
范围限于4个公开基准和5个特定LLM生成的代码与测试;缺陷样本经过“剔除易检测缺陷、每任务只取最难一个”筛选,不代表LLM生成缺陷的自然分布;未覆盖全部测试标准或全部LLM。
方法与英文摘要

数据来自HumanEval+、MBPP、BigCodeBench、NaturalCodeBench四个基准。先让LLM生成测试,把原测试集的覆盖率和变异分数推到近饱和;再用GPT-5-Mini、GPT-4.1-Mini、Claude-Haiku4.5、Deepseek-v4-flash、Llama3.3-70B-Instruct生成代码,与参考实现比对行为差异,得到73785个缺陷;剔除43272个易检测缺陷后,每任务保留最难1个,形成6066个较难缺陷,用来评测语句覆盖、分支覆盖、变异测试。

Test adequacy criteria are widely used to evaluate and guide software testing. Although prior research has extensively examined these criteria using human-written programs, faults, and tests, the increasing adoption of Large Language Models (LLMs) for code generation raises important questions about their effectiveness in detecting LLM-induced faults. To investigate this, we conduct an empirical study involving 5 LLMs and 4 benchmarks, simulating end-to-end workflows in which both code and tests are automatically generated. We collect 6,000+ faulty program instances and evaluate the effectiveness and efficiency of 3 widely used adequacy criteria: statement coverage, branch coverage, and mutation testing. Our findings reveal several key insights. First, most faults introduced by LLMs are relatively trivial to catch. Second, the challenging faults are difficult to trigger using either traditional coverage-based or mutation-based criteria. Third, actual fault detection rates remain extremely low, often near zero, because test oracles fail to capture faulty behavior triggered by the generated test prefixes, exposing a critical limitation of automated test generation. Fourth, prompt-aware oracles can improve fault detection, but their overall effectiveness remains limited, highlighting the need for users to manually reason about test assertions. We further observe that mutation testing only marginally outperforms traditional coverage criteria in both triggering and detecting faults, raising questions about whether its significantly higher application cost is justified in this context.

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

The Impact of GenAI on the Future of Requirements Engineering

代码生成变便宜后,需求工程的重心应从写代码转向验证需求:如果你正在引入AI编程智能体,这篇综述提醒你:真正的瓶颈会转移到需求侧——需求有没有表达清楚、能不能验证。作者综述了AI用于需求工程的历史和LLM智能体现状,论证实现成本下降后,工程资源应投向需求表达、情境整理与产出验证。

两句看懂

AI智能体使编码成本骤降,敏捷时代'弱化需求文档'的做法难以为继,本文综述AI用于需求工程的路径,主张转向规格表达、情境整理与验证评估。作者引用2025年1006名高管调查佐证转型压力——60%已因预期AI自动化裁员、21%为大幅裁员——但强调这只是预期性证据,不是实测效能。

核心判断

需求工程应从依赖开发者经验转向操作性规格表达、情境整理、验证与评估。这一判断的依据是文献综述归纳的趋势和外部裁员/效率调查数字,而非本文自己的实验证据。

关键要点

1.旧假设失效:敏捷方法假设开发者经验可替代需求文档分析,但生成式AI使实现成本骤降后,风险从'代码是否正确'转移到'需求是否表达清楚、可验证';2.方法与核查:用四类任务分类表(表1:引出、提取、生成、分析,各附代表性研究)组织文献,再叠加提示编程与通用SE智能体两条新研究线,区分哪些任务已可自动化、哪些仍需人工验证;3.结论与行动:论文无自有实验,引用的60%裁员(2025年,1006名高管)是预期性证据、Copilot完成率+26%(2026年,4867名开发者)可能已过时——结论仍是方向性的:把资源投向需求表达与验证,而非代码生成本身。

证据与结果

无正式数据集或基准测试。证据全部来自二手引用:表1据参考文献列出RE四类任务代表作;2025年1006名高管调查(60%已裁员,21%大幅裁员)与2026年4867名开发者研究(Copilot任务完成率+26%)仅作产业信号。作者自陈前者是'预期性'而非'已证实性能'证据,后者'可能已过时'。

打开论文原文
它要解决什么
当生成式AI智能体能自动写代码后,需求工程的研究重点应如何调整?
研究路径
综述分四步:1)回顾AI用于RE的历史,建立四类任务分类表(引出/提取/生成/分析,附代表文献);2)综述LLM本身进展;3)综述提示编程(把LLM指令当程序对待)与通用SE智能体(组合多种LLM能力完成半自主SE任务);4)沿'SE过程与需求交互'和'开发者/干系人体验需求'两条轴展望未来方向。
这对工程意味着什么
第一步行动:在部署代码生成智能体之前,先补齐需求表达、情境整理与产出验证流程,因为实现成本下降会把风险转移到需求侧。要避开的捷径:不要把60%裁员这类调查数字直接当作AI已证实提升生产力的证据——作者自己标注它是预期性的。
证据定位
论文本身无对照实验,只引用外部调查作产业信号:2025年1006名高管调查显示60%因预期AI自动化裁员(21%为大幅裁员);2026年4867名开发者研究称Copilot使任务完成率+26%。作者明确前者是'预期性'证据而非实测性能,后者可能已过时。(筛选维度:软件工程方法)
适用边界
全文为文献综述,无自有实验数据集或统计检验。所引裁员比例与效率提升数字均来自第三方调查,作者自陈裁员证据是预期性而非实测性,且Copilot研究可能已过时。
方法与英文摘要

纯文献综述,无自有实验。作者先按参考文献建立RE任务四分类表(引出、提取、生成、分析,各附代表性研究),再综述LLM进展、提示编程与通用SE智能体,最后沿两条轴展望:'SE过程如何与需求交互'和'开发者/干系人如何体验需求'。

Recent advances in artificial intelligence (AI), particularly large language models (LLMs), are transforming how we design and build systems by increasing access to domain knowledge and by providing automation support to software engineering (SE). As implementation becomes less expensive through generalist SE agents, engineering effort shifts away from writing correct code and toward expressing, curating, verifying, and evaluating requirements. In this paper, we survey the state of the art in AI for requirements engineering (RE) research leading up to the transformation, before reviewing advances in LLMs. We survey two subsequent research areas: prompt programming, which treats LLM instructions as a program in SE vernacular, and generalist SE agents, which combine multiple LLM advances to yield semi-autonomous processes that complete SE tasks. Finally, we explore the future of requirements engineering along two axes: matters changing how we interact with requirements through the SE process, and matters changing how requirements are experienced by software developers and stakeholders more broadly, including end-users. This article aims to inform how RE researchers can navigate this transformation in the selection of future research priorities.

代码质量与优化(0 篇)

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

UI 与 GUI Agent(0 篇)

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

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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

本轮分类概览

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

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

近一个季度监测日历

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

近 14 次监测窗口

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

本轮新增候选(7 篇)

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

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

形式化与程序验证 · 6/30 · 2026-09-08StochBench:Lean随机过程基准450道随机过程题,智能体15分钟限时证明率34.9%;摘要称该领域在Mathlib中覆盖不足。StochBench: A Domain-Specific Benchmark for Stochastic Processes in Lean

Leading benchmarks for formal theorem proving with large language models are small collections drawn from competition math, such as the IMO and Putnam, that poorly represent field-specific applications. We introduce StochBench, a Lean 4 benchmark of 450 graduate stochastic-processes problems at varying abstraction levels, each paired with its natural-language source. Addressing a field underrepresented in Mathlib, it covers finite and countable Markov chains, renewal processes, random walks, martingales, stopping times, queues, Brownian motion, stochastic calculus, weak convergence, and Poisson and continuous-time Markov processes. Our Opus 4.8-based agent achieves a 34.9% proof rate (157/450) under a 15-minute per-problem limit. StochBench better represents domain-specific applied mathematics while remaining challenging for advanced provers.

阅读 arXiv 原文

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

软件工程与仓库智能 · 3/30 · 2026-09-09多模型集成生成安全需求研究用信息检索数据融合聚合多次LLM运行,比较均匀与朴素贝叶斯融合策略;摘要未给出最终结论。Ensembling LLMs for AI-Augmented Cybersecurity Software Requirements Generation

Translating high-level controls from security standards into concrete, system-specific requirements is central to cybersecurity requirements engineering. Large language models (LLMs) can accelerate this labor-intensive, recall-sensitive task, but any single run is unreliable: it misses valid safeguards while introducing plausible hallucinations, and outputs shift across runs and models. We reframe this variability as a resource: rather than selecting one output, we study post-generation ensembling, aggregating stochastic runs with information-retrieval data-fusion operators. We propose two strategies: Uniform fusion rewards mere cross-run agreement, whereas Naive-Bayes fusion weights each run by its estimated reliability. We evaluate both over 24 runs from 12 configurations across four model families, generated for ten ISO/IEC 27002:2022 controls and expert-judged against a gold standard of 72 valid requirements. Pooling every run's output recovers all 72 (whereas single configurations recover on average under half) but also 111 hallucinations. Fusion separates the wheat from the chaff, ranking valid requirements well ahead of hallucinations. In the areas under the precision-recall and ROC curves, Uniform fusion alone largely surpasses every original run and configuration by 0.142 and 0.118 over the best configuration. Naive-Bayes weighting adds a further 0.039 and 0.052, reaching 0.864 and 0.869 while attaining useful operating points earlier. Internal validation confirms the stability of these gains: they stay positive in at least 92% of out-of-bag bootstrap resamples and every structured-perturbation sample. Post-generation fusion thus turns apparent noise into a practical asset: a lightweight layer giving analysts broader coverage and a better prioritized review queue, using affordable, below-frontier models alone.

阅读 arXiv 原文
软件工程与仓库智能 · 3/30 · 2026-09-09LLM迭代修bug的失效动态报告称LLM会在无bug程序中误报并改动,且易陷入反复增删的伪修复循环。If It's Not Buggy, Don't Fix It: On the Dynamics of Iterative Bug-fixing with LLMs

Large language models (LLMs) have become ubiquitous in software development, with LLM-based automated program repair tools increasingly used during code review. In this report, we explore the iterative blind use of LLMs as bug-fixers. Across multiple models and repair environments, we find that LLMs consistently claim to detect bugs in entirely bug-free programs while the rate of repair of buggy programs is less than that of the damage to correct programs. We also explore the long-term dynamics of this iterative process, and find that this frequently reaches a pseudo-bug-fixing cycle where the same changes are added and removed again ad infinitum. Lastly, via mechanistic probing, we unveil the existence of a steering vector which controls the editing propensity, suggesting that LLMs have an internal representation of ``buggy code", and that this representation is what is falsely activated to induce pseudo-bug fixing. These results provide insight towards the dynamics of fully autonomous bug-fixing systems, as well as stopping conditions under ambiguous goals.

阅读 arXiv 原文
软件工程与仓库智能 · 6/30 · 2026-09-09FLOSS架构实践的社会技术维度研究计划,关注FLOSS架构决策中的治理与伦理因素及教育干预,尚无实证结果。Socio-technical and Ethical Dimensions of Architecture Practices in FLOSS

This project investigates how software architecture practices in Free/Libre Open Source Software (FLOSS) are shaped by socio-technical and ethical factors, and how education can support more explicit, inclusive, and reflective architectural work. Motivated by FLOSS's role in digital sovereignty, it is observed that architectural decisions are often undocumented and scattered across issues, pull requests, and mailing lists. While prior research has studied architectural artifacts, erosion, and communication, the interplay between architectural work, governance arrangements, and ethical commitments in FLOSS remains underexplored. The research follows a three-phase design: (1) multi-method case studies of 3-4 domain-pairs of architecturally non-trivial FLOSS projects, (2) framework and intervention design with practitioners and educators, and (3) pilot evaluations in projects and courses. It will produce (i) cross-case empirical evidence on FLOSS architecture practices, (ii) a conceptual framework linking architecture practices to socio-technical conditions and ethical dimensions, and (iii) lightweight practices and teaching formats that render architectural work more explicit and inclusive.

阅读 arXiv 原文
软件工程与仓库智能 · 6/30 · 2026-09-08传统准则检测LLM代码缺陷实证5个LLM与4个基准、6000余缺陷实例,比较语句/分支覆盖与变异测试的效果。How effective are traditional test criteria at detecting bugs in large language models generated code?

Test adequacy criteria are widely used to evaluate and guide software testing. Although prior research has extensively examined these criteria using human-written programs, faults, and tests, the increasing adoption of Large Language Models (LLMs) for code generation raises important questions about their effectiveness in detecting LLM-induced faults. To investigate this, we conduct an empirical study involving 5 LLMs and 4 benchmarks, simulating end-to-end workflows in which both code and tests are automatically generated. We collect 6,000+ faulty program instances and evaluate the effectiveness and efficiency of 3 widely used adequacy criteria: statement coverage, branch coverage, and mutation testing. Our findings reveal several key insights. First, most faults introduced by LLMs are relatively trivial to catch. Second, the challenging faults are difficult to trigger using either traditional coverage-based or mutation-based criteria. Third, actual fault detection rates remain extremely low, often near zero, because test oracles fail to capture faulty behavior triggered by the generated test prefixes, exposing a critical limitation of automated test generation. Fourth, prompt-aware oracles can improve fault detection, but their overall effectiveness remains limited, highlighting the need for users to manually reason about test assertions. We further observe that mutation testing only marginally outperforms traditional coverage criteria in both triggering and detecting faults, raising questions about whether its significantly higher application cost is justified in this context.

阅读 arXiv 原文

代码质量与优化(0 篇)

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

UI 与 GUI Agent(1 篇)

UI 与 GUI Agent · 3/30 · 2026-09-09GraphDroid移动端GUI测试面向多步功能覆盖,结合历史感知探索与混合意图满足;摘要对效果仅作定性描述。GraphDroid: Asynchronous LLM-Based Mobile App GUI Testing via History-Aware Exploration and Hybrid Intent Fulfillment

Automated GUI testing is a widely adopted technique for ensuring mobile application quality by simulating user interactions to exercise functionalities. Despite the research breakthroughs in the past decades, covering complex functionalities that require multi-step action sequences still remains challenging. Traditional tools lack semantic understanding capability and can rarely synthesize such action sequences. Recent LLM-based tools can generate test intents describing target functionalities and leverage the LLM to fulfill the intents, but suffer from three key limitations: 1) loss of historical context for identifying uncovered functionalities, 2) synchronous intent generation that blocks exploration, and 3) per-step LLM-driven fulfillment incurring high cost and latency. To address these limitations, we propose GraphDroid, an intent-driven GUI testing framework that integrates a cluster-based memory mechanism to effectively identify uncovered functionalities from historically visited states for comprehensive application testing. For improving testing efficiency, GraphDroid adopts an asynchronous intent generation paradigm that eliminates the latency bottleneck and a hybrid intent fulfillment strategy that reserves the LLM for fulfilling complex intents while delegating simple intents to a lightweight heuristic algorithm. We evaluate GraphDroid on 41 real-world Android apps against six state-of-the-art baselines. Results show that GraphDroid outperforms all baselines, achieving up to 36.4% higher code coverage while incurring less than one eighth of the cost of the best pure LLM-based baseline. GraphDroid also exposes 19 bugs in the 41 apps and detects 13 of 52 crashes in the Themis bug benchmark, surpassing all the six baselines. Seven of the 19 bugs were previously unknown and we reported them to the developers. So far, four bugs have been confirmed and fixed.

阅读 arXiv 原文

个人知识与本体(1 篇)

个人知识与本体 · 0/30 · 2026-09-09小模型参数化个性化记忆将个人文本语料经DoRA写入小模型权重;摘要显示个性化适配迹象,泛化测试结论不完整。From Retrieval to Weights: Parametric Individualization of Small Language Models with Individual Text Corpora

We approach a cognitive simulation perspective on episodic and semantic memory in multiple-choice question answering by incorporating text from individual text corpora (ITC) into retrieval-augmented generation and DoRA fine-tuning. We web-crawl the search histories of 515 participants who answered 36 multiple-choice knowledge items and analyze a stratified subsample of 150 participants. For each participant, one DoRA adapter consolidates their ITC into a small language model (SLM) whose baseline correctness falls below the participants' lowest quartile. The adapter measurably writes the ITC into the weights: it fits its own participant's held-out text better than other participants' texts (dz =1.27), an individuality effect that increases with ITC size in rank order. On the generalized knowledge test, however, the adapter adds knowledge rather than alignment with the individual: log-loss match improves, whereas match accuracy under a bias-corrected PMI readout does not, and retrieval adds nothing on top. Our results demonstrate that ITCs can be consolidated into the weights of SLMs, an encouraging basis for individualized tutoring agents, and we discuss how to move from there toward a realistic simulation of episodic and semantic memory at the individual level.

阅读 arXiv 原文

人机协同与对齐(0 篇)

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