公开论文雷达

公开 arXiv 研究简报 · 2026-08-21T00:47:32.421252+00:00

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

别把"测试通过"当"真修好":四篇怎么读

四篇都在同一个点上较劲:补丁通过测试、输出读着流畅,都不等于语义真正正确。OdinEval和ORCA用两状态执行与遥测回放拆穿假阳性,TDD-Agent把测试提到实现之前,规格说明悖论则从需求侧说清为什么AI越强越离不开可验证规约。

推荐阅读顺序

  1. 2608.18595:先看最硬的证据:修复率和可复现率由不同模型领先,单一指标会系统性高估修复能力。
  2. 2608.17018:再把同样教训搬到线上:113个补丁通过有效性校验,但只有45个遥测回放真缓解。
  3. 2608.16742:转到生成侧:先写可执行测试再写实现,别把自生成测试当成固定的后验校验器。
  4. 2608.16618:最后退一步看原则:AI生成能力越强,对完整、可验证人工规约的依赖越深。
共性方法
四篇打的是同一个靶:"表面通过"不等于"真正正确"。都主张把通过信号和正确性解耦,用独立证据单独验证——两状态执行、遥测回放、测试先行、规约一致性检查,而不是拿单一通过率下结论。
关键分歧
分歧在证据强度和作用环节。OdinEval、ORCA是带量化数值的实证基准,分别落在离线评测和线上运维;TDD-Agent有实验但摘录未给数值,作用在代码生成阶段;规格说明悖论是无实验数据的立场文章,作用在需求规约阶段。
选择准则
要做修复评测或线上事故修复,读OdinEval和ORCA拿可审计的验证做法;要改代码生成流程,用TDD-Agent;只想说服团队重视规约,看规格说明悖论。

重点深读(4 / 4 篇)

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

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

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

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

OdinEval: A Reproducible Benchmark for LLM-Based Program Repair in the Odin Programming Language

OdinEval:修复率和可复现率是两回事,Odin系统语言修复评测必须绑定两状态执…:如果你用LLM修系统语言的bug,光看“补丁通过测试”会高估模型能力。OdinEval给出一种可审计的做法:从公开Odin仓库构建168个实例,每个实例绑定issue、基础提交、金标补丁、issue专用测试和历史工具链,用“缺陷版失败、修复版通过”两状态证据验证测试有效性。

两句看懂

现有基准主要覆盖Java和Python,无法判断LLM修复方法能否迁移至Odin系统语言,OdinEval通过两状态执行证据和历史工具链绑定构建了可审计的168实例基准。六模型统一协议评测中Resolved最高66.7%、Repro最高96.4%,两指标领先者不同,说明修复率与可复现率相互独立。

核心判断

在Odin语言上绑定历史工具链与两状态执行证据,可以建立可审计的系统语言修复基准;168实例评测显示Resolved与Repro两项指标由不同模型领先,二者不等价。

关键要点

1. 旧基准(Defects4J、BugsInPy、SWE-bench)集中在Java和Python,且不保证issue专用测试能区分缺陷与修复版本,环境变更或断言抄录实现细节会造成假阳性。 2. OdinEval对168个实例强制两状态验证:基础版本+测试必须FAIL,基础版本+金标补丁+测试必须PASS;无开发者测试时由同一模型三个独立实例生成黑盒测试并在两历史状态执行修订,工具链描述符和执行证据随实例冻结发布。 3. 六模型统一评测:Kimi-K3 Resolved最高66.7%,Qwen3.8-Max Repro最高96.4%,领先者不同;结论是评测时分开报告Resolved与Repro,并把环境失败从修复证据中剔除。

证据与结果

168个实例来自公开Odin仓库,经两状态执行验证过滤。六个大模型在同一修复提示、源码范围、验证器和报告分类下评测,设Resolved(补丁通过issue专用测试)和Repro(基础状态可复现)两类指标。结果:Kimi-K3 Resolved最高66.7%,Qwen3.8-Max Repro最高96.4%。失败诊断区分补丁应用失败、依赖解析失败、编译失败、测试发现失败和超时配置失败,保留为诊断记录但不计入fail-to-pass证据;补丁语法合法但无法在相关编译器和命令契约下求值,不计为完成修复。

打开论文原文
它要解决什么
现有修复基准集中在Java和Python,LLM修复方法能否迁移到Odin这类系统语言?更实际的问题是:怎么保证issue专用测试真的能区分缺陷版本和修复版本,而不是因环境变化或断言抄录实现细节给出假阳性?
研究路径
从公开Odin仓库挖掘issue关联提交,绑定基础提交、修复提交和金标补丁。优先使用开发者回归测试;没有时,由同一模型三个独立实例生成黑盒测试,在两个历史状态执行后依记录反馈迭代修订,版本化Test Writing Skill管理每次修订。只有测试在基础版本失败且金标修复后通过,实例才被录入。命令、容器摘要、返回码、测试输出和校验和写入审计清单,随实例一起发布。
这对工程意味着什么
第一件事:评测修复系统前,先验证测试在基础版本实际失败、在修复版本通过,而不是只检查补丁语法是否合法。要避开的捷径:把构建失败或环境异常计为修复成功——这类假阳性会系统性高估模型能力,而且事后很难区分。
证据定位
六模型在168个统一实例上评测:Kimi-K3的Resolved得分最高,为66.7%;Qwen3.8-Max的Repro得分最高,为96.4%。两项指标由不同模型领先,说明修复率与可复现率相互独立,不能用单一指标衡量修复能力。(筛选维度:可复核评测、软件工程方法)
适用边界
仅覆盖Odin语言,168个实例规模有限;无开发者测试时由同一模型的三个实例生成黑盒测试,存在模型内同质化偏差;论文明确说明测试预言充分性是独立挑战,通过测试不等于语义正确。
方法与英文摘要

从公开Odin仓库挖掘issue关联缺陷,每个实例绑定基础提交、修复提交、金标补丁、issue专用测试、历史工具链描述符和执行记录。录入条件很硬:测试必须在基础版本失败、在金标修复后通过。没有开发者测试时,由同一模型的三个独立实例生成黑盒测试,在两个历史状态下执行,依执行记录反馈迭代修订,用版本化的Test Writing Skill管理每次修订。六个大模型在168个过滤实例上用统一修复提示、源码范围、验证器和报告分类评测。

Repository-level repair benchmarks still center on a few mainstream languages, leaving systems languages such as Odin largely untested. We present OdinEval, a reproducible benchmark built from documented defects in public Odin repositories. Each instance binds an issue to base and fix commits, a gold patch, an issue-specific regression test, a historical toolchain, and execution records. Admission requires the test to fail on the base revision and pass after the gold fix. When no usable developer test exists, a black-box test is reviewed independently by three instances of the same model, executed in both historical states, and revised from recorded feedback under a versioned Test Writing Skill. We evaluate six language models on 168 filtered instances under one shared protocol. Kimi-K3 records the highest Resolved score at 66.7%, while Qwen3.8-Max has the highest Repro score at 96.4%. The release includes frozen data, source archives, containers, validators, model patches, and audit manifests.

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

ORCA: Observability-Grounded Program Repair for Microservice Incidents

ORCA:遥测驱动微服务自动修复:现有APR系统在issue或测试设定下开发,与微服务运维遥测脱节。ORCA将成对故障与参考遥测蒸馏为故障签名,定位代码与配置候选,生成unified-diff patch,以遥测回放验证;575案例基准上以约1/25的token消耗超越所有基线。

两句看懂

现有APR系统在issue或测试设定下开发,无法将微服务运维遥测转化为定位与验证信号;ORCA以成对故障与参考遥测为输入,经蒸馏、定位、修复图智能体生成patch。150真实事故子集中,TGPV遥测回放验证显示ORCA缓解45例,最强基线23例,ORCA均值token约26k,为其约1/25。

核心判断

运维遥测可从诊断证据转化为修复行动上下文:成对遥测支持修复定向定位,修复图智能体将定位结果转化为约束patch生成上下文,遥测回放验证揭示仅凭issue或测试评测会遗漏的修复结果。

关键要点

1. 现有APR基准以issue与测试结果为输入,微服务RCA系统止步于服务/路径诊断,两者均无法将日志、追踪、指标直接映射至代码或配置位置并生成可验证patch。 2. 575案例基准分合成代码、合成配置、真实事故(150案例)三子集;TGPV设补丁有效性、语法语义、测试预言、遥测回放四个独立验证层各自上报;真实事故issue文本经脱敏以减少解法泄露。 3. 150真实案例中ORCA获遥测回放缓解45例、有效性通过113例,最强基线分别为23和74,均值token约640k vs ORCA约26k;113对45的落差揭示补丁有效性与遥测回放缓解之间存在显著断层。

证据与结果

575案例基准含三子集:合成代码、合成配置、真实事故(150案例)。对比六类基线,含issue驱动智能体APR、单步推理、无智能体APR、经典遗传修复、微服务RCA及配置诊断工具。主要指标:遥测回放缓解数、补丁有效性通过数、均值token消耗。150真实案例:ORCA 113例通过有效性、45例遥测回放缓解,均值token约26k;最强基线74/23,均值token约640k。合成子集ORCA各验证指标计数均最高。失败诊断:113例通过有效性但仅45例完成遥测回放缓解,揭示补丁有效性与实际缓解之间的显著落差。

打开论文原文
它要解决什么
能否将运维遥测(日志、追踪、指标)直接转化为微服务修复patch的定位依据与验证信号,从而跨越APR系统在issue-to-patch设定下的诊断-修复鸿沟?
研究路径
蒸馏引擎对比故障与参考遥测包,输出紧凑故障签名;SBFL用签名排序top-K代码候选,配置提取器选配置候选;代码修复图智能体与配置修复图智能体各自构建受约束patch生成上下文并输出unified-diff;若均未产出可接受patch,Exploration智能体接管;TGPV依序检查补丁有效性、语法语义、测试预言完整性、遥测回放,各层独立报告。
这对工程意味着什么
构建微服务修复系统时,应将成对遥测(故障+参考)作为定位与验证主信号;遥测回放验证可暴露patch有效性所遗漏的修复失败。避免以测试通过率作为唯一验证指标,因其无法反映遥测层面的实际缓解效果。
证据定位
150真实事故案例中,ORCA生成113个通过有效性校验的patch、遥测回放缓解45例,均值token约26k;最强基线分别为74和23,均值token约640k,约为ORCA的25倍。(筛选维度:可复核评测、软件工程方法)
适用边界
真实事故子集仅150案例,规模有限;基准含合成案例,合成与真实分布存在偏差;遥测回放依赖成对参考遥测可获取;真实事故issue文本经脱敏处理以减少解法泄露,脱敏程度对结果的影响未量化。
方法与英文摘要

基准575案例,分合成代码、合成配置、真实事故(150案例)三子集。输入为成对故障与参考遥测包及项目工作区。蒸馏引擎生成故障签名;SBFL排top-K代码候选,配置提取器选配置候选;代码修复图智能体和配置修复图智能体生成unified-diff;Exploration智能体兜底;TGPV分补丁有效性、语法语义、测试预言、遥测回放四层独立验证。

Microservice failures are often diagnosed from operational telemetry. However, automated program repair systems usually start from issue reports, localized code context, or failing tests. This mismatch leaves a gap between telemetry-based diagnosis and patch generation. We present ORCA, an observability-grounded APR pipeline for microservice incidents. ORCA first distills the differences in paired failure and reference telemetry into a fault signature, then uses the signature to identify candidate code and deployment-configuration locations. Repair graph agents and an Exploration agent generate unified-diff patch candidates from these locations. ORCA evaluates generated patches with a Telemetry-Grounded Patch Verifier that separates patch validity, syntactic and semantic correctness, test-oracle integrity, and telemetry replay. On a 575-case benchmark, ORCA outperforms all evaluated baselines in terms of cost-effectiveness. Results show that operational telemetry can be transformed from diagnostic evidence into actionable repair context: paired telemetry supports repair-oriented localization, while repair graph agents convert localized code and configuration evidence into constrained patch-generation context for the LLM. Telemetry-grounded verification then exposes repair outcomes that issue- or test-only evaluation would miss.

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

TDD-Agent: Test-Driven Reasoning for Code Generation

测试先行推理驱动代码生成正确性:已有LLM代码生成将自生成测试固定为后验校验器,测试偏差导致误导性反馈。TDD-Agent改为先生成可执行测试、再写实现,并对代码与测试双轨迭代精化,在函数级和仓库级基准上均持续优于基线。

两句看懂

已有方法将LLM自生成测试固定为后验校验器,测试不完整或存在偏差时会向实现阶段持续输出误导性信号;TDD-Agent改为先生成可执行测试、再写实现,并用执行反馈双轨迭代精化代码和测试。在LiveCodeBench和RepoEval上实验,TDD-prompt和TDD-Agent均持续优于对应基线,迭代精化同步提升测试通过率、覆盖率和变异分数。

核心判断

先写测试后写实现使模型显式界定行为边界,双轨迭代精化同步提升代码和测试质量;LiveCodeBench和RepoEval实验均持续优于对应基线,具体数值未在摘录中提供。

关键要点

1. 旧假设与评测缺口:已有测试驱动代码生成将自生成测试在产出后固定为静态验证器,测试本身的不完整性和偏差持续向实现精化阶段输出错误信号;现有研究大多局限于函数级任务,仓库级场景因依赖关系和环境模拟复杂,测试生成难度显著更高,测试先行策略是否在此场景仍然有效此前尚无明确答案。 2. 构建协议与控制变量:TDD-Agent分两阶段——Phase 1通过工具读取仓库上下文,在任何实现前生成初始单元测试套件U0,强迫模型显式声明输入约束、张量形状和边界条件;Phase 2基于执行反馈同时精化代码和测试(双轨迭代)。另设仅提示词变体TDD-prompt(不含代理框架),在LiveCodeBench上独立验证测试先行推理效应,与完整框架效果分开评估。 3. 决定性结果与边界:TDD-prompt在LiveCodeBench上持续优于推理型提示基线;TDD-Agent在RepoEval上持续优于检索型和代理型基线;双轨精化同步提升测试通过率、覆盖率和变异分数,验证测试可作为可演化推理制品而非固定校验器;具体数值和效果边界未在供文摘录中提供。

证据与结果

函数级基准LiveCodeBench:仅使用TDD-prompt(提示词变体,无代理框架)与推理型提示基线对比,隔离测试先行推理的独立效应,结果持续优于基线。仓库级基准RepoEval:部署完整TDD-Agent框架,与检索型和代理型基线对比,持续优于所有基线。额外分析:双轨迭代精化同步提升测试通过率、覆盖率和变异分数,验证测试可作为可演化推理制品。具体数值及数据集规模未在供文摘录中提供。

打开论文原文
它要解决什么
LLM将自生成测试固定为后验校验器时,测试偏差如何损害实现质量?测试先行推理能否在仓库级任务中同样有效?
研究路径
Phase 1:代理利用工具读取仓库上下文,在任何实现代码生成前输出初始单元测试套件U0,强迫模型声明输入约束、输出张量形状、像素值等精确边界条件。Phase 2:执行测试获取反馈,同时精化实现代码和测试,双轨迭代;测试不再固定,而是随执行反馈持续演化为可验证的推理制品。
这对工程意味着什么
仓库级代码生成中应先让模型生成可执行测试(作为需求消歧步骤)再写实现,并同步迭代精化代码和测试;这减少测试偏差引入的误导反馈;避免的误区是将自生成测试固定为后验校验器后仅精化实现代码。
证据定位
TDD-prompt在LiveCodeBench上持续优于推理型提示基线;TDD-Agent在RepoEval上持续优于检索型和代理型基线;双轨精化同步提升测试通过率、覆盖率和变异分数。摘录未提供具体数值。(筛选维度:可复核评测、软件工程方法)
适用边界
摘录未提供具体数值,无法评估效果量级;仓库级测试生成质量受仓库依赖复杂度和工具上下文提取准确性制约;测试先行在极度依赖环境模拟场景下的效果边界未作量化说明。
方法与英文摘要

评测数据集:LiveCodeBench(函数级)和RepoEval(仓库级)。框架分两阶段:Phase 1提示模型在任何实现前通过工具读取仓库上下文并生成初始单元测试套件,强迫模型显式界定输入约束和边界行为;Phase 2基于执行反馈同时精化代码和测试(双轨迭代)。另设TDD-prompt变体(仅改提示词、不加代理框架)在LiveCodeBench上隔离测试先行推理的独立效应。

Large Language Models (LLMs) have achieved remarkable progress in code generation, yet ensuring correctness in complex, repository-level tasks remains challenging. Existing approaches often use generated tests as static post-hoc validators, which limits their ability to guide implementation and may introduce misleading feedback when the tests themselves are incomplete or incorrect. In this paper, we introduce TDD-Agent, which operationalizes the test-driven development paradigm for code generation. TDD-Agent first prompts the model to generate executable tests, encouraging it to clarify expected behaviors before implementation, and then performs iterative dual-track refinement over both the generated code and tests using execution feedback. We first isolate the effect of test-first reasoning through a prompt variant TDD-prompt on LiveCodeBench, where it consistently improves upon reasoning-based prompting baselines. Building on this finding, we evaluate the full TDD-Agent framework on RepoEval, a repository-level benchmark, and show that it consistently outperforms retrieval-based and agent-based baselines. Additional analyses show that iterative refinement improves not only code correctness but also the effectiveness of the generated tests, yielding higher pass rates, coverage, and mutation scores, suggesting that tests can serve as evolving reasoning artifacts rather than fixed validators. Our source code is available at https://anonymous.4open.science/r/TDD-Agent-Framework-6370/.

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

The Specification Paradox: Rethinking Requirements Engineering in the Age of AI

AI写代码越快,规格说明越不能省——这就是规格说明悖论:如果你的团队用LLM生成代码,真正决定软件质量的已经不是写代码的速度,而是需求规约写得完不完整、能不能验证。这篇立场性文章提出"规格说明悖论":AI生成能力越强,对完整、可验证人工规约的依赖越深。

两句看懂

LLM大幅减少了写代码的工作量,但软件的本质复杂性没有消失,只是从实现层转移到了需求定义与规格说明层。论文基于Brooks偶然/本质复杂性框架推导出规格说明悖论:AI生成能力越强,对完整、可验证人工规约的依赖越深。

核心判断

AI代码生成降低偶然复杂性,但放大规格缺陷的影响。这就是规格说明悖论:生成能力越强,人工规约的质量越成为软件质量的决定性约束。依据是Brooks复杂性理论推导,无实验数据支撑。

关键要点

1. 旧假设被推翻:代码自动化不等于消除软件复杂性。LLM只降低偶然复杂性,领域约束、需求歧义、系统演化这些本质复杂性无法被技术手段消除,生成物的流畅性还可能诱使开发者跳过一致性验证。 2. 方法与受控检查:论文构建规格驱动开发(SDD)演进框架,识别四类可对照检查的风险变量——自动化偏差(高估模型能力)、歧义传播(模糊规约放大错误)、规格过拟合(规约与特定实现耦合)、规格债务(规约维护滞后于系统演化)。 3. 决定性结论与行动:AI生成能力提升会使规格缺陷的影响范围等比扩大,质量瓶颈从"如何写代码"转移到"如何正确规约待构建系统";团队应把规格作为一等工程产物纳入版本管理,并在每次AI生成后强制做规约-生成物一致性验证。

证据与结果

论文是立场性综述,没有实验数据集和基准测试,结论依赖概念推导与文献援引,主要是Brooks关于本质/偶然复杂性的分析。识别的四类风险为:1)自动化偏差——流畅输出掩盖一致性缺陷;2)歧义传播——模糊规约在生成链中放大错误;3)规格过拟合——规约与特定实现耦合;4)规格债务——规约维护滞后。四类风险的相对权重和实际发生率均未量化,没有对照实验。

打开论文原文
它要解决什么
AI自动生成代码,到底是真的降低了软件开发的根本复杂性,还是只是把瓶颈从写代码挪到了写规格?
研究路径
LLM以自然语言规约为输入生成代码。规约有歧义或过拟合时,生成结果可能局部通过测试,却与领域意图不符。自动化偏差让开发者看到流畅的生成物就接受,省略批判性评估;规格债务随迭代不断累积,到系统演化阶段才集中暴露,修复成本显著上升。
这对工程意味着什么
第一步行动:把需求工程和规格说明评审正式纳入AI辅助开发流程,并在每次AI生成后做一致性检查。要避免的捷径:不要因为LLM生成结果读起来流畅,就认定规约已被正确理解,从而跳过一致性与领域对齐验证。
证据定位
论文是概念论证,没有实验基准数据。核心论据来自Brooks复杂性理论的推导:LLM消除的是偶然复杂性,不消除本质复杂性;流畅的生成物可能掩盖一致性缺陷和领域对齐缺陷。(筛选维度:形式化验证、软件工程方法)
适用边界
论文是论证性文章,没有实验验证。所有结论依赖概念推导与文献援引,缺乏跨项目或跨领域的实证数据;四类风险机制的相对权重与实际发生频率未经量化评估。
方法与英文摘要

这是一篇立场性分析文章,没有实验数据集。作者以Brooks的偶然复杂性与本质复杂性区分为理论框架,梳理从代码中心开发向规格驱动开发(SDD)的演进,识别出四类风险:自动化偏差、歧义传播、规格过拟合、规格债务,并在此基础上形式化提出规格说明悖论。

The growing adoption of Large Language Models (LLMs) in Software Engineering has reinforced the expectation that coding activities can be largely automated. However, this perception may represent yet another historical search for a solution capable of eliminating the inherent challenges of software development. This article discusses the transition from a code-centered paradigm to Specification-Driven Development. We argue that artificial intelligence reduces some of the effort associated with writing source code, but it does not eliminate the complexity of developing professional software systems. Instead, it shifts this complexity toward domain understanding, requirements elicitation, specification development, validation, maintenance, and software evolution. Building on this perspective, we discuss the renewed centrality of Requirements Engineering, considering its implications for productivity and software quality, as well as risks associated with automation bias, ambiguity propagation, Specification Overfitting, and the accumulation of Specification Debt. Finally, we propose the Specification Paradox: the more capable artificial intelligence systems become at automatically generating software, the greater the dependence on correct, complete, verifiable, and explainable human-produced specifications. We conclude that the future of Software Engineering will depend not only on machines' ability to generate code, but also on humans' ability to correctly specify, evaluate, and evolve what is intended to be built.

代码质量与优化(0 篇)

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

UI 与 GUI Agent(0 篇)

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

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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

本轮分类概览

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

赛道新增候选重点
形式化与程序验证20
软件工程与仓库智能14
代码质量与优化10
UI 与 GUI Agent00
个人知识与本体00
人机协同与对齐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 次监测窗口

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

本轮新增候选(4 篇)

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

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

形式化与程序验证 · 3/30 · 2026-08-19从盲区自我演化的评估指标借鉴程序验证的反例引导抽象精化,从评估器盲区碰撞中自动演化缺陷标记算子Metrics That Write Themselves: Evolving an Evaluator from Its Own Blind Spots

Agents improve quickly against a reliable automatic metric and stall without one, and the applications that need them most, report generation among them, are the ones nobody knows how to score. Can the metric write itself? Saying what makes an answer good is hard; pointing at something wrong with one is easier, so the metric we evolve is a pool of small Python operators that each flag a candidate for one named defect, or abstain, and vote. Asking a model for operators directly does not work: 183 candidates realise only 96 distinct behaviours, from one narrow region of an enormous space. EvalCEGAR instead borrows counterexample-guided abstraction refinement from program verification. It reads the pool as an abstraction and searches for a collision, two answers the operators score identically, one correct and one not. That pair, not a prompt, is the authoring request, and when a collision defeats every attempt the loop widens what an operator may read rather than resampling. On MBPP+ and HumanEval+, a sandbox whose hidden unit tests give exact ground truth, the loop writes a 55-line operator that closes 15.4% of the gap between flagging nothing and a perfect filter on 428 unseen tasks (+0.0065, p=0.0010) at a quarter of our best hand-written operator's flags. On the benchmark it never saw it matches that operator's effect exactly on a third of the flags. Six of eight runs admit such an operator and all six help out of sample; our 15 hand-written operators applied together as one filter lose accuracy. An LLM judge on the same information ties that delta on a nearly disjoint set of candidates, and charges a model call per candidate forever where the operator charges none.

阅读 arXiv 原文
形式化与程序验证 · 3/30 · 2026-08-19覆盖驱动的RTL断言生成框架结合形式化迹生成、语法引导合成与神经符号精化,提升硬件断言覆盖完备性Coverage-Driven RTL Assertion Generation with Formal Exploration and Neuro-Symbolic Refinement

Hardware functional verification relies on high-quality assertions to expose design bugs and establish confidence in Register Transfer Level (RTL) designs. Yet existing assertion mining methods still struggle to produce complete and reliable assertion sets: random or limited traces fail to cover hard-to-reach behaviors, and one-shot generation provides little feedback about what remains unverified or how the assertion set should be improved. As a result, critical design behaviors can remain uncovered even when many assertions are generated. We present NeuroAssertion, a coverage-driven assertion generation framework that combines formal trace generation, syntax-guided synthesis (SyGuS), and an agent-inspired refinement process within a unified framework. Our framework first converts hard-to-reach control-flow conditions into formal reachability objectives, uses model checking to generate behaviorally diverse traces, and mines initial assertions from these traces with SyGuS. It then performs targeted agent-inspired refinement under verification feedback: one LLM first proposes candidate assertions for uncovered regions, and if a candidate fails formal checking, a second LLM generates a repair grammar that guides constrained symbolic synthesis in a neuro-symbolic repair procedure. Experimental results show that this framework delivers around 2X more assertions and about 2X higher mutation coverage than traditional assertion mining methods.

阅读 arXiv 原文

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

软件工程与仓库智能 · 9/30 · 2026-08-19Odin语言程序修复基准OdinEval基于公开仓库缺陷构建的可复现基准含168实例,评估六个语言模型的修复与复现表现OdinEval: A Reproducible Benchmark for LLM-Based Program Repair in the Odin Programming Language

Repository-level repair benchmarks still center on a few mainstream languages, leaving systems languages such as Odin largely untested. We present OdinEval, a reproducible benchmark built from documented defects in public Odin repositories. Each instance binds an issue to base and fix commits, a gold patch, an issue-specific regression test, a historical toolchain, and execution records. Admission requires the test to fail on the base revision and pass after the gold fix. When no usable developer test exists, a black-box test is reviewed independently by three instances of the same model, executed in both historical states, and revised from recorded feedback under a versioned Test Writing Skill. We evaluate six language models on 168 filtered instances under one shared protocol. Kimi-K3 records the highest Resolved score at 66.7%, while Qwen3.8-Max has the highest Repro score at 96.4%. The release includes frozen data, source archives, containers, validators, model patches, and audit manifests.

阅读 arXiv 原文

代码质量与优化(1 篇)

代码质量与优化 · 3/30 · 2026-08-19攻破视觉语言模型的薄弱环节研究视觉语言模型在视觉输入对抗扰动下的逃逸攻击,提出基于梯度的攻击方法,覆盖目标与非目标场景Breaking the weakest link to evade vision language models

Vision Language Models (VLMs) have recently emerged as a critical component of multimodal AI systems, enabling joint reasoning over visual and textual inputs in real-world and safety-critical applications. Despite their growing deployment, the robustness of VLMs against adversarial threats remains insufficiently explored, particularly in the context of evasion attacks targeting multimodal alignment. In this work, we investigate the vulnerability of VLMs to adversarial perturbations applied to visual inputs and study two attack settings: untargeted attacks, where the goal is to disrupt the model's interpretation of the original image, and targeted attacks, where the adversary aims to force the model to generate a specific semantic description unrelated to the original image. To efficiently generate adversarial examples, we propose a gradient-based attack method that performs optimization exclusively on the vision encoder of the VLM rather than on the entire multimodal architecture. This design significantly reduces the computational cost and resource requirements of the attack while maintaining strong effectiveness. We evaluate our approach on several open-source VLMs, including Qwen2.5-VL, Granite-Vision, FastVLM, and Phi-3.5-Vision, and show that small, human-imperceptible perturbations can substantially alter the textual interpretation produced by the models. Our findings highlight the vulnerability of modern VLMs to adversarial manipulation and emphasize the need for improved robustness and security mechanisms in multimodal AI systems.

阅读 arXiv 原文

UI 与 GUI Agent(0 篇)

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

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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