公开论文雷达

公开 arXiv 研究简报 · 2026-07-31T01:03:26.770285+00:00

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

六张卡的共识:别让LLM单打独斗,先拆阶段再收口

六篇都在同一件事上使劲——把LLM关进流水线:先产出结构化中间物(规格、约束、特征、分类),再交给专门环节验证或兜底。SpecFirst、VeriSynth、原型插件证明拆分后能量化提升;协议评测与ABM则划出LLM独自下判断的失效边界;OAS换个轴讲何时该压缩记忆。想抓主线先读SpecFirst。

推荐阅读顺序

  1. 2607.27167:主线最清晰:把"探测出规格"与"照规格编码"彻底分开,通过率最高提升21.3%,先看它建立框架。
  2. 2607.19795:同一招的形式化版:LLM只当翻译前端,SMT求解器做最终裁判,看约束如何给出形式保证。
  3. 2607.20712:反面证据:LLM直接判协议安全,chat精度低于31%、推理漏检过半,看清模型独判的边界。
  4. 2607.17948:更极端的边界:小模型连重复工具调用都失败,讲怎么用统计检验先验证再谈集成。
  5. 2607.17545:换个轴:不是拆阶段而是按预算选算子,预算紧就合并、宽就保留,最高差48个百分点。
  6. 2607.14830:收尾看落地:特征分解+RAG+渲染前人工审查,但评测偏初步,结论只看方向不看数字。
共性方法
都不让LLM一步到位:先让它产出结构化中间物(规格、Z3约束、特征列表、邻居分类),再交给独立环节收口——合成智能体、SMT求解器、形式化工具或人工审查,并在公开基准上量化增益。共同信念是把探索/翻译与验证/落地拆开。
关键分歧
分歧在LLM能否顶替传统方法。SpecFirst、VeriSynth、原型插件显示拆分后LLM带来实测提升;协议评测与ABM则显示LLM独自下判断会漏检、精度崩塌,仍须形式化工具兜底;OAS的答案是"看预算再定",紧则合并、宽则保留,没有固定赢家。
选择准则
凡让LLM出最终结论,必须配一个独立验证环节兜底(求解器、形式化工具、测试或人工审查);能形式化验证的场景别信模型自报置信度,策略按预算压力与证据长度动态切换。

重点深读(6 / 6 篇)

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

形式化与程序验证 8/30

Towards Automated Formal Verification of zkEVMs Using LLM-Guided Constraint Synthesis

VeriSynth:LLM引导的zkEVM形式化验证框架:zkEVM的隐性语义错误可以绕过密码学证明验证。VeriSynth将LLM严格限制为Rust操作码的翻译前端,输出Python/Z3符号约束,用SMT求解器做最终的正确性仲裁。在首个源码级基准上,检测率超过90%,比生产级手写变异测试套件多发现32个漏洞。

两句看懂

zkEVM手写规范随实现迭代无法扩展,纯LLM方案幻觉频发且缺乏形式保证;VeriSynth将LLM限定为Rust到Z3约束的翻译前端,SMT求解器作为仲裁后端。在首个源码级基准(95个注入漏洞)上,检测率超过90%(87/95),比生产级手写变异测试套件多发现32个漏洞。

核心判断

将LLM严格限定为Rust到符号约束的翻译前端、SMT求解器作为正确性仲裁后端,可自动化zkEVM形式化验证;首个源码级基准上检测率超过90%(87/95),优于直接LLM基线和生产级手写变异测试(55/95)。

关键要点

1. 现有zkEVM验证依赖人工编写规范(如手写变异测试),随低层Rust实现频繁优化无法扩展;纯LLM直接生成约束存在幻觉且无形式保证,缺少将Rust操作码隐性语义自动转化为求解器可用约束的工具链,且此前无源码级标准基准。 2. VeriSynth构建闭环流水线:语义分解将栈、内存、存储、gas等多组件状态转换拆分为子任务,检索增强提示提供代码上下文,LLM生成候选Python/Z3约束,验证引导自动修复纠正语法与排序错误,SMT求解器最终仲裁;基准含95个注入漏洞,覆盖正确与错误两类操作码实现。 3. VeriSynth检测87/95漏洞(超过90%),生产级手写变异测试套件仅检测55个(约58%);消融实验显示去除自动修复使检测率从91.6%骤降至66.3%,早期失败主要源于语法与排序错误而非语义理解不足,检索增强和语义分解各自提供独立增益。

证据与结果

首个源码级zkEVM Rust实现验证基准,含正确与错误两类操作码实现,共注入95个漏洞。指标:漏洞检测率。对比:直接LLM基线、对话式LLM基线、生产级手写变异测试套件(检测55/95,约58%)。VeriSynth检测87/95(超过90%)。消融:去除自动修复使检测率从91.6%降至66.3%,早期失败主要为语法与排序错误而非语义理解不足;检索增强与语义分解各自提供独立增益。

打开论文原文
它要解决什么
如何将Rust实现的zkEVM操作码自动转化为可执行形式化验证模型,同时避免LLM幻觉并提供形式化保证?
研究路径
Rust操作码处理器经语义分解拆分为栈、内存、存储、gas等子组件;检索增强提示将相关代码上下文注入LLM;LLM生成候选Python/Z3符号约束;验证引导自动修复识别语法或排序错误并在闭环中重新生成;SMT求解器对最终约束执行可满足性检验,判定实现是否违反操作码规范。
这对工程意味着什么
在形式化验证规范编写代价高的场景,可采用LLM翻译+SMT仲裁+验证引导自动修复闭环;有效性依赖自动修复消除语法错误,切勿直接将LLM输出作为最终约束并略过求解器仲裁步骤。
证据定位
VeriSynth在95个注入漏洞中检测87个(超过90%),显著优于直接LLM和对话式LLM基线;生产级手写变异测试套件仅检测55个。消融:去除自动修复使检测率从91.6%骤降至66.3%,各组件均有独立贡献。(筛选维度:形式化验证、可复核评测)
适用边界
基准仅覆盖zkEVM操作码层Rust实现,不涵盖更高协议层或其他语言;注入漏洞的数量(95个)和类型由构建者决定,代表性有限;论文摘录未说明基准覆盖的操作码种类及数量边界。
方法与英文摘要

数据集:首个源码级zkEVM Rust实现验证基准,包含正确与错误两类操作码实现,共注入95个漏洞。流程:①语义分解将栈、内存、存储、gas等多组件状态转换拆分为子任务;②检索增强提示为LLM提供相关代码上下文;③LLM将Rust操作码翻译为候选Python/Z3符号约束;④验证引导自动修复在闭环中纠正语法与类型错误;⑤SMT求解器执行最终正确性仲裁。

Zero-Knowledge Ethereum Virtual Machines (zkEVMs) secure Ethereum rollups by generating zero-knowledge proofs that guarantee off-chain execution correctness. However, subtle implementation bugs (e.g., incorrect gas accounting) can lead to valid proofs certifying semantically faulty states, thereby silently defeating cryptographic guarantees. Formal verification via SMT solvers can prevent this, but is bottlenecked by specification: current zkEVM development practice lacks automated methods to translate Rust opcode handlers into verification models. Current practices rely on unsustainable manual specifications, while LLM-based approaches suffer from hallucination and lack formal guarantees. To address this, we propose VeriSynth, a framework that synthesizes executable Python/Z3 verification models from Rust zkEVM code. VeriSynth enforces a hybrid paradigm: an LLM acts strictly as a formalization frontend to translate code into symbolic constraints, while an SMT solver serves as the correctness arbiter. To handle complex multi-component state transitions, VeriSynth integrates semantic decomposition, retrieval-grounded prompting, and verification-guided auto-repair into a closed-loop pipeline. We evaluate VeriSynth on the first source-level zkEVM verification benchmark, encompassing both correct and faulty opcode implementations. VeriSynth achieves a bug detection rate of over 90%, substantially outperforming direct and conversational LLM baselines, as well as a production-grade handwritten mutation-testing suite. Ablation studies confirm that each pipeline component is critical to the framework's overall effectiveness.

形式化与程序验证 6/30

Evaluating Large Language Models for Symbolic Security Protocol Analysis

LLM在安全协议形式化分析中的能力评测:针对130个经过名称与角色混淆的AnB/AnBx协议,覆盖388个安全目标,系统评测了chat与推理两类配置的LLM在安全判定上的表现。基准采用无界会话形式化验证工具(主)和有界一/两会话工具(辅)。chat模式召回率高(69-81%)但精度极低(低于31%);推理模式精度有所提升(共享底层模型对比从27.2%升至45.4%),但认证目标漏检超过一半(检出率低于41%)。

两句看懂

针对130个经混淆的AnB/AnBx协议与388个安全目标,系统评测了LLM在chat与推理两种配置下能否生成与形式化验证工具等效的安全判定。chat模式召回高(69-81%)但精度低于31%,推理模式精度提升(共享底层模型对比27.2%→45.4%)但认证目标检出率不足41%,两类模式均无法替代形式化验证。

核心判断

大型语言模型直接输出的安全判定无法替代形式化验证:chat配置精度低于31%,推理配置漏检超过一半,认证目标检出率不足41%;模型自报置信度与判定正确性无关。以上结论基于388个安全目标的三轮评测,以形式化工具输出为基准。

关键要点

1. chat与推理模式失效方向相反——chat精度低于31%(过度标注攻击),推理召回仅过半(保守判定),两者均无法同时满足精度与召回实用门限,不存在LLM整体替代路径。 2. 评测使用130个混淆AnB/AnBx协议、388个安全目标,以无界会话形式化工具为主基准、有界工具为辅,瀑布优先合并标签;其中一组配置共享底层模型以隔离推理链效果,另一组跨模型版本结论为参考。 3. 推理链使同底层模型精度从27.2%升至45.4%;injective agreement检出率仅38.5-40.2%(最差目标类型);机密性F1达95.7%(唯一强项);跨轮一致率最低74.0%;模型自报置信度94-99%与正确性无统计相关,不可用作质量信号。

证据与结果

数据集包含130个经过名称和角色混淆的AnB/AnBx安全协议,共388个安全目标,分为机密性、injective agreement和non-injective agreement三类。基准:主基准为无界会话形式化工具,辅以有界一/两会话工具,三源通过瀑布优先方案合并。评测:chat与推理配置各独立运行三轮,使用协议级cluster bootstrap计算95%置信区间,指标包括precision、recall、F1和accuracy。结果:chat配置recall 69-81%、precision低于31%;推理配置A(跨模型版本)precision 66.5%,推理配置B(同底层模型)precision 45.4%(其chat基准为27.2%);injective agreement检出率仅38.5-40.2%;机密性F1最高95.7%;跨轮一致率分别为89.7%和74.0%;模型自报置信度94-99%与正确性无显著相关。

打开论文原文
它要解决什么
大型语言模型能否直接输出与形式化验证工具相当的协议安全判定?chat与推理两类配置各在何处失效?
研究路径
流水线首先对协议名称和角色进行混淆,然后通过API提交零样本提示,要求模型返回结构化JSON,包含二元判定、0-100置信分、文字理由以及可选的攻击追踪(两会话)。其中一对配置共享同一底层模型,仅通过开关推理链来隔离推理效果;另一对配置跨模型版本,推理增益不可完全归因于推理链。无界会话形式化工具处理无界情形,有界工具处理一/两会话,三个来源通过瀑布优先方案合并生成最终基准标签。
这对工程意味着什么
在实际协议安全分析流水线中,推荐使用推理模式LLM对机密性目标进行预筛查(F1≈96%),以节省形式化工具的计算开销。认证目标必须直接使用形式化工具验证。避免的误区:不要依赖模型自报置信度(高达99%)来判断输出可靠性,因为置信度与正确性无统计相关;若据此过滤,会造成高置信漏检。
证据定位
共享底层模型的对照实验显示,推理链使精度从27.2%提升至45.4%,隔离开了推理效果。chat配置召回69-81%但精度低于31%。推理配置在认证目标上检出率不足41%(injective agreement仅38.5-40.2%)。机密性目标的推理模式F1达到95.7%。跨三轮判决一致率最低74.0%,模型自报置信度94-99%但与正确性无统计相关。(筛选维度:形式化验证、可复核评测)
适用边界
本评测仅覆盖AnB/AnBx记号下的130个协议,未包含TLS等工业级协议;基准标签由形式化工具生成,工具本身存在终止问题和状态爆炸局限;其中一对配置是跨模型版本对比,推理增益不能完全归因于推理链;评测仅涉及两家供应商的四种模型配置。
方法与英文摘要

构建Python自动化流水线,对130个经混淆的AnB/AnBx协议进行零样本提示。分别以chat和推理模式调用两家供应商的模型API,每次请求返回二元安全判定、0-100置信分及可选的攻击追踪。采用无界会话形式化工具作为主要基准,有界一/两会话工具作为辅助,通过瀑布优先方案合并产生388个安全目标的标签。每种配置独立运行三轮,使用协议级cluster bootstrap计算95%置信区间。其中一对配置共享同一底层模型,仅开关推理链,干净隔离了推理效果。

Security protocol verification relies on formal tools such as ProVerif and OFMC. This study evaluates whether Large Language Models (LLMs) can perform comparable analysis. We test GPT and DeepSeek in chat and reasoning modes over three runs on 130 obfuscated AnB/AnBx protocols covering 388 security goals, scored against ProVerif and OFMC. Chat models reach 69 to 81% recall at precision below 31%. Reasoning models reverse this trade-off, reaching 66.5% precision for GPT and 45.4% for DeepSeek, but detect just over half the attacks. DeepSeek's two modes share one underlying model, so the comparison isolates reasoning itself, which raises precision from 27.2% to 45.4%. The GPT contrast spans a model-version change and is only suggestive. All models perform worst on authentication goals: reasoning models detect well under half of injective and non-injective agreement attacks, whereas chat models over-flag them at low precision. Confidentiality is the exception, with F1 up to 95.7% in reasoning mode. Verdicts are unstable across runs, identical on 89.7% of goals for GPT but 74.0% for DeepSeek. Self-reported confidence is uniformly high yet shows no meaningful correlation with correctness. On this benchmark LLMs do not match formal verification, but may serve, at best, as pre-screening filters.

形式化与程序验证 6/30

Towards Agentic Agent-based Models: Feasibility, Performance, and Statistical Model Checking

LLM嵌入ABM仿真的可行性与统计验证:在经典Schelling分群模型中用单个LLM代理替换符号分类规则,通过MultiVeStA统计模型检验量化语义分类准确性与工具调用操作成功率。小规模本地LLM在重复工具调用时语义分类失败或工具不可用,较大模型通过了初步检验。

两句看懂

传统ABM用显式符号规则保证可复现性,而将局部规则替换为LLM工具调用后,语义错误和工具调用失败会传播到全局涌现行为。本文在Schelling分群模型中构建了一个单LLM代理混合基准来隔离该风险,并用MultiVeStA对不同规模本地LLM进行统计检验:小模型在重复工具调用时语义分类失败或操作不可用,较大模型通过了初步检验。

核心判断

在ABM中将单个代理的符号规则替换为LLM工具调用在技术上是可行的,但小规模本地模型在语义分类和工具调用操作层面均失败,较大模型通过了初步检验。统计模型检验(MultiVeStA)可以量化这种替换对系统级可观测量的影响。

关键要点

1. 传统ABM的符号规则保证可复现性,但引入LLM后语义错误和工具调用失败等新变量无法被现有分析框架量化。 2. 构建方法:基于Mesa Schelling模型,保留原始动力学不变,仅将一个代理的邻居相似性分类替换为LLM工具调用,控制LLM规模为唯一变量。 3. 决定性结果:小模型在语义分类或工具调用操作上失败,较大模型通过初步检验;MultiVeStA可估计LLM组件对仿真观测量的量化影响;但未报告具体准确率、失败率或置信区间。

证据与结果

基准:Mesa Schelling分群模型,混合种群(多数符号代理 + 一个LLM代理)。评估维度:(1) 语义可行性——LLM能否正确分类邻居相似性;(2) 操作可行性——LLM在重复工具调用中是否保持可用;(3) 计算开销。测试对象:多个规模的本地部署LLM(具体模型名称与参数量未披露)。结果:小模型在语义或工具调用操作层面失败;较大模型通过初步检验。本实验为初步研究,未报告具体准确率、失败率或样本数量数值。

打开论文原文
它要解决什么
将ABM中单个代理的符号分类规则替换为LLM工具调用,对仿真的可靠性、计算代价和涌现行为有哪些量化影响?
研究路径
LLM代理收到邻居的自然语言描述后,通过工具调用对每个邻居标记为相似或不同,每次调用递增相应计数器。计数器的值输入原始的Schelling幸福函数,决定该代理是否移动。MultiVeStA作为黑盒外部驱动Mesa仿真,自动执行多次模拟,并为可观测量提供具有统计保证的估计。
这对工程意味着什么
在将LLM代理集成到ABM仿真之前,务必先用统计模型检验框架单独验证其语义分类准确性和工具调用操作的可行性。不要因为模型规模较大就跳过操作可行性测试,直接将其集成到仿真循环中。
证据定位
小规模本地LLM在重复工具调用时语义分类错误或工具调用操作完全失败;较大规模LLM通过了初步的语义和操作可行性检验。MultiVeStA可量化LLM组件对ABM可观测量的影响。本实验为初步研究,未报告具体的准确率数值。(筛选维度:形式化验证、可复核评测)
适用边界
本实验仅测试了单LLM代理嵌入Schelling模型这一种场景,属于初步研究。LLM的具体规模和名称未披露,未提供准确率、失败率或置信区间数值。结论不适用于多LLM代理或其他ABM架构。
方法与英文摘要

基于Mesa Schelling分群模型,构建混合种群:多数代理使用符号规则计数相同邻居,一个代理将邻居相似性分类委托给本地LLM。LLM代理接收邻居的自然语言描述,通过工具调用递增相似/不同邻居计数器,计数器值输入原始Schelling幸福函数决定移动意愿。使用MultiVeStA对不同规模的本地LLM进行黑盒统计模型检验,分别评估语义分类准确性、工具调用操作成功率和计算开销。

Agent-based models (ABMs) rely on simple, explicit and reproducible rules for individual decision making, while complex collective behavior emerges from interactions among agents. Recent advances in large language models (LLMs) make it tempting to replace, enrich, or perturb these rules with LLM-based agentic capabilities. However, this raises a methodological question: how does introducing LLM-driven decisions affect the reliability, computational cost, and behavior of ABM simulations? We investigate this for Mesa ABM models, a popular Python library for ABMs, analyzed by statistical model checking. Building on Mesa's integration with the statistical model checker MultiVeStA, we extend the classical Schelling segregation model with a hybrid population: ordinary agents classify neighbors using the standard symbolic rule, while one agent delegates this task to an LLM through tool calls. The LLM-enabled agent receives natural-language descriptions of neighboring agents and invokes tools that increment counters of similar/different neighbors; these counters determine its happiness according to the original Schelling dynamics. This provides a minimal but controlled setting where the semantic, operational, and computational behavior of LLM-based decisions can be studied inside an otherwise standard ABM. We report preliminary experiments with locally served LLMs of different sizes, showing that smaller models may fail simple semantic classification experiments or become operationally unusable during repeated tool-call generation, while larger tested models pass these preliminary checks. We discuss how statistical model checking can estimate classical ABM observables and quantify the impact of introducing agentic LLM components into simulation models.

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

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

SpecFirst: Behavioral Specification Elicitation as a First-Class Step in Agent-Based Program Synthesis from Scratch

SpecFirst:规格先行将零起点代码合成通过率提升21%:现有框架将探索与合成混入单循环,致边界探测不足、行为意图漂移与错误持续累积。SpecFirst分两阶段:规格智能体先探测只读二进制生成结构化规格,再由合成智能体依此编码。在ProgramBench 200道实例、4个模型上,测试通过率提升6.9%–21.3%,覆盖率提升9.4%–18.5%,全部统计显著。

两句看懂

现有框架将探索与合成混入单循环,致边界探测不足、行为意图随上下文漂移丢失及错误持续累积;SpecFirst将规格提取设为独立前置阶段,规格智能体先探测只读二进制生成结构化规格,再由合成智能体依此编码。在ProgramBench全部200道实例、4个模型上对比单循环基线,测试通过率提升6.9%–21.3%,覆盖率提升9.4%–18.5%,全部统计显著。

核心判断

将行为规格提取独立为前置阶段可系统提升零起点程序合成质量:ProgramBench上测试通过率提升6.9%–21.3%、覆盖率提升9.4%–18.5%(统计显著),行为分析确认规格锚点使合成更早启动且持续更久。

关键要点

1. 现有单循环框架假设智能体可在同一轮次内兼顾探测与编码,但这导致三类系统性缺陷:边界条件与标志交互探测不足;长上下文中行为意图因推理令牌剥离和摘要压缩而漂移丢失;早期文档误读沿依赖链累积而无规格锚点可纠正——即使最强前沿模型在该基准上完整解题率仍低于1%。 2. SpecFirst在ProgramBench全部200道实例上将流程拆为两个独立阶段:规格智能体专项探测只读二进制,将观测与文档整合为结构化规格;合成智能体仅依规格编码。跨两个模型族系、能力跨量级的4个模型独立对比单循环基线,轮次预算一致,确保结论具有鲁棒性。 3. SpecFirst在4个模型上测试通过率提升6.9%–21.3%,二进制探测覆盖率提升9.4%–18.5%,全部统计显著。行为分析表明预先规格使合成智能体更早进入编码阶段且持续更久,而非在探测与编码间反复切换;绝对通过率仍低说明零起点合成是开放难题,规格分离是必要条件而非充分条件。

证据与结果

基准为ProgramBench,200道实例,每题仅提供自然语言文档和只执行二进制(无源码、无内部结构)。评测覆盖4个模型,跨两个模型族系、能力跨量级。指标为测试通过率和二进制探测覆盖率,与单循环基线对比。SpecFirst通过率提升6.9%–21.3%,覆盖率提升9.4%–18.5%,全部统计显著。行为分析追踪每轮次行为类型,显示规格前置使合成更早启动并持续更久。即使最强模型在原始基准上完整解题通过率仍不足1%,表明任务整体极难,规格分离是显著改善但非根本突破。

打开论文原文
它要解决什么
在零起点程序合成中,将行为规格提取独立为前置阶段能否系统性提升探测覆盖率与测试通过率?
研究路径
规格智能体系统调用只执行二进制的各种输入组合,发现文档未记载的边界条件、错误路径和标志交互,将全部观测与文档整合为结构化规格文档。合成智能体随后以该规格为唯一参考编码,无需再探测二进制,从而切断长上下文意图漂移和无锚点错误累积的来源。
这对工程意味着什么
构建零起点程序合成流水线时,应先用独立规格智能体全面探测目标行为并输出结构化规格,再启动合成智能体编码;将探测与合成混入单循环是常见捷径,但会导致边界行为漏测和行为意图在长上下文中漂移,最终拉低通过率。
证据定位
与单循环基线相比,SpecFirst在4个模型上测试通过率提升6.9%–21.3%,二进制探测覆盖率提升9.4%–18.5%,全部统计显著。行为分析显示预先规格使合成智能体更早编码且持续更久,而非在探测与编码间反复切换。(筛选维度:形式化验证、可复核评测、软件工程方法)
适用边界
评测仅限ProgramBench 200道实例(只执行二进制场景);规格智能体的探测策略与提示格式对结果的独立影响未系统量化;不同结构化规格格式对合成质量的敏感性及在有源码场景中的适用性均未报告。
方法与英文摘要

基准为ProgramBench全部200道实例,每题仅提供自然语言文档和只执行二进制(无源码)。SpecFirst分两阶段:①规格智能体系统探测二进制,覆盖边界条件、错误路径和标志交互,将观测与文档整合为结构化规格;②合成智能体以该规格为唯一锚点编码,不再探测。跨两个模型族系、能力跨量级的4个模型独立运行,与单循环基线对比,轮次预算保持一致。

LLM-based agents excel at software engineering tasks where an existing codebase provides context, but constructing a program from scratch remains fundamentally harder. Recent benchmarks such as ProgramBench quantify this gap: given only natural-language documentation and an execute-only binary as a behavioral oracle, even frontier models solve fewer than 1% of instances. Existing frameworks conflate documentation reading, behavioral exploration, and code synthesis into a single pass, causing agents to probe insufficiently, lose behavioral intent as context drifts, and propagate early misinterpretations into the final implementation. Inspired by classical requirements engineering, we argue that behavioral specification elicitation should be a first-class phase that precedes implementation. We present SpecFirst, a two-stage framework that forces the specification elicitation before code synthesis. A dedicated spec agent first probes the binary and combines observations with documentation into a structured specification. Next, a code synthesis agent then uses this specification to drive implementation. This decomposition resolves documentation ambiguities before coding begins and provides a stable behavioral reference throughout synthesis. We evaluate SpecFirst on all 200 ProgramBench instances across four models spanning two families and an order of magnitude of capability. SpecFirst consistently outperforms the single-loop baseline, improving test pass rates by 6.9%-21.3% and binary exploration coverage by 9.4%-18.5%, all statistically significant. Behavioral analysis on code synthesis further shows that a prior specification enables earlier and more sustained code construction. Our results demonstrate that an explicit requirements-engineering phase is an effective paradigm for from-scratch program construction.

代码质量与优化(0 篇)

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

UI 与 GUI Agent(1 篇)

UI 与 GUI Agent 7/30

AI Prototyper: A Figma Plugin for Decomposition-Based GUI Prototyping with LLMs

特征分解+RAG流水线驱动GUI原型自动生成:单提示LLM生成GUI时组件遗漏、布局不一致。该插件将自然语言描述分解为离散特征JSON数组,经RAG检索32个自定义组件(7类)后渲染为可编辑设计图层,并在渲染前插入人工审查节点。初步两阶段评测中,插件组在完成数量和专家9维度质量评分上均优于手动基线。

两句看懂

单提示GUI生成因遗漏关键组件、布局不一致且小改动须全量重生成而难以实用,该插件以特征分解+RAG+人工审查三段流水线将整屏生成拆解为可管控子步骤。两阶段初步评测显示,插件用户在固定时间内完成更多原型,专家在9个质量维度对AI输出的评分优于手动基线。

核心判断

将自然语言屏幕描述分解为离散特征列表再逐一检索32组件库,可解决单提示生成的组件遗漏和布局不一致;初步两阶段评测中,插件组在完成量和专家9维度评分上均优于手动基线。

关键要点

1. 单提示GUI生成的核心问题是将整屏作为单一生成目标,导致组件遗漏、布局不一致,且任何需求变更必须全量重生成,这是原型开发瓶颈的根本原因。 2. 方法构造为四阶段流水线:NL特征分解→两阶段RAG检索→人工审查→逐特征渲染,在检索与渲染之间插入人工审查节点;评测以手动制作为基线,专家评分覆盖9个质量维度。 3. 结果与边界:固定时间内插件组完成更多原型,专家9维度评分均高于手动基线;但评测为初步性质,未报告参与者人数、时间窗口时长、统计显著性;32组件库的范围是主要边界条件。

证据与结果

两阶段初步评测:第一阶段参与者在固定时间窗口内完成原型任务,记录插件组与手动组的完成数量;第二阶段专家从9个质量维度对AI生成原型与手动原型评分,AI组在所有维度评分更高。论文未报告参与者人数、固定时间窗口时长、9个维度名称、原始分数均值或置信区间,量化统计不足,结论应以定性方向为主。多语言测试覆盖泰语、英语、普通话,但具体测试规模未量化。

打开论文原文
它要解决什么
将GUI需求分解为离散特征列表再逐一RAG检索,能否解决单提示生成中组件遗漏、布局不一致以及小改动需全量重生成的问题?
研究路径
①系统提示将LLM设定为产品经理角色,输出含名称和用途的特征JSON数组,语言规则检测输入语种并令所有用户可见文本使用同一语言;②后端对32组件库执行两阶段RAG:先用每组件单行摘要选出候选,再匹配完整JSON schema(含必填项、可选项及类型约束);③用户可在渲染前增删改特征列表;④每个特征渲染为独立带auto-layout的图层。
这对工程意味着什么
构建LLM驱动的UI生成系统时,维护小型精选组件库(约32个)并在渲染前设置特征列表审查节点。应避免直接用单提示生成完整屏幕——该模式组件遗漏率高,且任何局部修改都会触发全量重生成。
证据定位
固定时间窗口内,插件组完成原型数量多于手动组;专家在9个质量维度对AI生成原型的评分均高于手动原型。(筛选维度:可复核评测、GUI Agent 方法)
适用边界
评测为初步性质:未报告参与者人数、固定时间窗口时长、9个质量维度名称、原始分数或置信区间;32组件库覆盖场景有限;多语言测试规模未量化;对照设计不含统计显著性检验。
方法与英文摘要

四阶段流水线:①LLM将自然语言描述解析为含名称和用途的特征JSON数组,语言规则同步检测输入语种;②后端对32组件库(7类:排版4、表单6、操作3、展示5、导航4、反馈4、布局6)执行两阶段RAG检索;③人工审查/增删特征列表;④逐特征渲染为带auto-layout的可编辑设计图层。评测分两阶段:参与者完成量(插件组 vs 手动组)和专家9维度质量评分。

Graphical user interface (GUI) prototyping remains a time-consuming activity that demands both design expertise and considerable manual effort. As GUI prototypes are non-code artifacts that evolve alongside requirements throughout the development cycle, automating their generation is directly relevant to software maintenance and evolution. We present AI Prototyper, an open-source Figma plugin that automates GUI prototyping through a decomposition and retrieval-augmented generation (RAG) pipeline. Given a natural-language description of a desired screen, such as a login page or a product detail card, the plugin decomposes the request into discrete GUI features, retrieves matching components from a custom 32-primitive library, and renders each component as a fully editable Figma layer with auto-layout. The pipeline uses Gemini 2.5 Flash as its LLM back-end and a Node.js Express service. Unlike existing decomposition-based tools, AI Prototyper introduces a human-in-the-loop editing step that lets users review, modify, or extend the generated feature list before rendering, uses a different technology stack and LLM family, and supports multilingual input, producing correctly labelled interfaces in Thai, English, and Mandarin Chinese. In a preliminary evaluation, participants using AI Prototyper completed more prototypes in a fixed time window than those working manually, and expert practitioners rated the AI-generated prototypes higher across nine quality dimensions. A demonstration video is available at https://youtu.be/pRoFAH7MQaE. The source code and component library are available at https://github.com/tongsalangsingha/AI-prototyper-tool

个人知识与本体(1 篇)

个人知识与本体 7/30

Retain or Consolidate? Budget-Dependent Operator Selection for Language Agent Memory

预算紧时合并,预算宽时保留:记忆算子选择取决于预算压力:语言智能体的记忆管理有个根本取舍:预算充足时保留原始记录,预算紧张时得压缩。本文把每种操作(保留、合并、抽象、改写)的价值拆成覆盖效应和替换效应,设计了一个轻量级选择器OAS。在LongMemEval上,预算紧的时候用合并比保留最多能高48个百分点的准确率;跨条目的抽象和合并优于局部改写。LoCoMo上同样出现预算依赖的交叉模式。

两句看懂

现有语言智能体记忆系统缺少统一原则来决定何时用压缩替代原始记录以及选哪种算子,本文通过分解算子的覆盖效应与替换效应并引入OAS轻量级选择器来解决。在LongMemEval和LoCoMo两个公开基准上,紧预算条件下合并最高提升48个百分点准确率,两个数据集均复现了预算依赖的保留与合并交叉模式。

核心判断

记忆保留与合并的优劣不是由固定阈值决定,而是由证据长度相对预算压力决定:紧预算时跨条目合并最高提升48个百分点准确率,宽松预算时保留更优。OAS通过生成前可观测特征估计算子效用实现轻量级自动选择。

关键要点

1. 保留与合并的选择依赖证据长度相对预算压力,而不是固定令牌阈值:预算宽时保留占优,预算紧时合并补回被排除的证据覆盖。 2. 在LongMemEval和LoCoMo上固定查询、检索器和推理模型,仅改变记忆表示,把Merge、Abstract、Rewrite和保留形式化为有限动作集;OAS从预算规模、证据适配压力、聚类几何等生成前特征估计效用,校准版在留出集上标定安全阈值抑制有害替换。 3. 紧预算下合并比保留提升最高48个百分点准确率;跨条目Abstract和Merge优于局部Rewrite,说明局部改写无法有效消除跨记录冗余。

证据与结果

在LongMemEval和LoCoMo两个公开基准上评测,固定查询、候选证据集、检索器、推理模型和回答时的令牌预算,只改变记忆表示形式来隔离算子效果。LongMemEval做长记忆对话评测,紧预算下合并最高提升48个百分点绝对准确率,宽松预算下保留优于合并。LoCoMo证据较短,交叉点出现在更小绝对预算处,与证据长度特点一致。两个数据集都显示跨条目Abstract和Merge在必须压缩时优于局部Rewrite,说明局部改写无法有效消除跨记录冗余。

打开论文原文
它要解决什么
固定令牌预算下,语言智能体什么时候该用压缩记忆替代原始记录?该选Merge、Abstract还是Rewrite?
研究路径
OAS把保留和三种合并算子建模为有限动作集,每个动作有对应的条件期望效用。从预算规模、证据适配压力、聚类几何、查询类型等生成前特征训练轻量级效用估计器,然后用插件最大化器选最优动作。决策分两步:先判断要不要合并(when),即预测收益是否超过安全阈值;再选具体算子(which)。校准版在留出问题集上标定阈值抑制有害替换;直接版阈值为零。
这对工程意味着什么
具体行动:当记忆预算紧张(相关证据放不下)时,优先使用跨条目合并或抽象提升覆盖率;预算充裕时直接保留原始记录,避免生成引入细节损失。误导性捷径:固定使用单一策略(全保留或全压缩),忽视预算压力的动态变化会导致系统在极端条件下大幅退化。
证据定位
LongMemEval上,紧预算下合并比保留提升最高48个百分点绝对准确率,宽松预算下保留更优。LoCoMo上证据更短,交叉点出现在更小的绝对预算处,复现了相同的预算-算子依赖模式。两个数据集都显示:必须压缩时,跨条目Abstract和Merge优于局部Rewrite。(筛选维度:置信度与不确定性、可复核评测)
适用边界
评测只限于LongMemEval和LoCoMo两个公开基准,证据长度分布不同(LoCoMo证据较短,交叉点出现在更小绝对预算处);未执行动作的效用在部署时不可直接观测,只能通过生成前特征估计,估计误差对选择质量的影响没有单独报告。
方法与英文摘要

在LongMemEval和LoCoMo两个基准上,固定查询、候选证据、检索器、推理模型和回答时的令牌预算,只改变记忆表示形式,以此隔离算子效果。把保留与三种合并算子(Merge、Abstract、Rewrite)形式化为有限动作集,每个动作对应一个条件期望效用。OAS是轻量级学习器,从生成前的特征(预算规模、证据适配压力、聚类几何、查询类型)估计每个动作的效用,然后通过插件最大化器选最优动作。两个版本:校准版用留出集标定有害替换的安全阈值;直接版阈值为零。

Language agents depend on memory across interactions. However, the limited context windows of large language models (LLMs) and their inference costs constrain how much memory can be used at once. Existing systems mainly follow two strategies: memory retention and memory consolidation. Retention keeps raw records and preserves exact details, but relevant evidence may not fit under a tight budget; consolidation compresses and combines records, improving coverage per token but risking the loss of query-critical details. Neither strategy is universally preferable. This raises two central questions: when should consolidation replace retention, and which operator -- Merge, Abstract, or Rewrite -- should be selected? We formalize this decision by decomposing each operator's utility into a coverage effect on evidence omitted by retention and a signed replacement effect on raw evidence that already fits. Their balance explains why the preferred action changes with relative budget pressure. We implement this mechanism with Offline Abstraction-Safety (OAS), a lightweight learner that estimates action utilities from pre-generation features with held-out harm calibration. The public LongMemEval and LoCoMo benchmarks show the same budget-dependent pattern. On LongMemEval, consolidation improves absolute accuracy by up to 48% under tight budgets, whereas retention is preferable under loose budgets; LoCoMo replicates this crossover at a smaller budget, consistent with its shorter evidence. On both datasets, cross-note abstraction and merging generally outperform local rewriting when compression is necessary.

人机协同与对齐(0 篇)

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

本轮分类概览

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

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

近一个季度监测日历

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

2026 年 5 月

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无记录31无记录

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 次监测窗口

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

本轮新增候选(0 篇)

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

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

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

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

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

代码质量与优化(0 篇)

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

UI 与 GUI Agent(0 篇)

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

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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