公开论文雷达

公开 arXiv 研究简报 · 2026-09-08T01:02:04.496662+00:00

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

先修检索和需求,再谈多智能体

八张卡片放一起看,主线是同一件事:多加角色、多加模型不等于更好。有对照数字的几篇给出可直接照做的动作——先接结构检索、需求没说清别大改、模型评审别全自动放行;剩下几篇给的是评测机制和判定门禁的设计参考,数字不足,只能当模板。

推荐阅读顺序

  1. 2609.04898:先读它:检索86%对委派66%,且委派能过的题检索全过,直接推翻加角色就更强的默认做法。
  2. 2609.03028:接着读:3553个真实会话显示需求迟到带来约两倍代码作废,且全程不衰减,决定你什么时候让代理动手。
  3. 2609.03230:配上一篇看:最佳模型只命中47%、误报11%,必要性正确性几乎全漏,说明需求关口必须留人。
  4. 2609.03592:再读落地路子:让模型产出Comby等DSL规则批量套用,比逐文件改可解释;但只有强模型撑得住复杂迁移。
  5. 2609.05364:第五读:文档当主干、代码整体重生成的做法值得参考,但只有一致性核验,没给样本量和成功率。
  6. 2609.00081:第六读:代码驱动自主探索替代清单验收的思路可借鉴,结论只说主流模型都不佳,没给具体数值。
  7. 2609.05157:做形式化评测再看:1019个Lean任务,内核判定加私有参考解,是防作弊评测集的现成模板。
  8. 2609.05157:占位
  9. 2608.28433:最后读:只有mission加proof-sketch的机制设计,没给完成量和对比数据,当协作模式草图看。
共性方法
八篇都在拆同一个默认假设:加智能体、换新模型、调温度不会自动变好。它们的共同做法是把成败交给机器能判的门禁——AST单测、编译、RefactoringMiner、Lean内核、行级回放、专家标注,而不是看表面结果或模型自述。
关键分歧
差别在证据硬度。重构评测台、需求返工、需求评审三篇给了可对照的数字(86%对66%、约两倍作废、47%命中11%误报);网页测试、设计文档重生成、Prove2Me只给机制或定性结论,样本量、成功率、对比数据都缺。
选择准则
有对照数字加自动判定的先照做;只给机制没给数字的,当设计模板用,自己先跑一轮小规模对照再决定要不要上生产。

重点深读(8 / 8 篇)

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

形式化与程序验证 8/30

RefactorPlatform: An Open-Source Harness for Controlled Evaluation of Repository-Scale Refactoring Agents

仓库级重构里,结构检索单智能体86%胜过新增多智能体委派66%:你要给团队接入重构智能体时,先别急着堆角色;真正该先测的是检索方式。开源评测台RefactorPlatform固定运行环境,在RefactorBench的100个多文件任务上分别切换模型、执行方式和提示详细度,量化哪种设计有效。

两句看懂

多智能体委派常被默认能提高重构成功率,但仓库级重构上缺少把模型、执行方式、提示详细度分开的对照。RefactorPlatform在100个任务上对照后发现,S2结构检索单智能体86%明显高于S3多智能体委派66%。

核心判断

在同一批仓库级重构任务上,结构化检索单智能体比多智能体委派更可靠:检索86%,委派66%,且委派能过的任务检索全覆盖。

关键要点

1. 旧假设:多智能体委派和示例检索被默认有效,但此前没有受控实验分离模型、执行方式、提示详细度各自的贡献。2. 方法与检查:100个RefactorBench多文件任务,四类模型接入;S1基线、S2 MCP结构检索、S3委派三档执行,配Descriptive/Base/Lazy三档提示;Python用AST单测,Java用抽取-编译-测试-RefactoringMiner门禁判定行为保持。3. 结果与行动:AST分块高25-30个百分点,朴素检索低于无检索;S2 86%对S3 66%,委派通过集合被检索全覆盖;先接AST感知结构检索,再评估是否要委派。

证据与结果

评测集是RefactorBench的100个多文件任务,四类模型经OpenRouter或GitHub Copilot CLI接入。变量为三种执行regime:S1基线、S2检索增强、S3多智能体委派;配三档提示:Descriptive、Base、Lazy。结果是AST分块超过token窗口分块25-30个百分点,朴素检索低于无检索基线;S2通过率86%,S3为66%;委派通过集合被检索通过集合完全覆盖;检索token开销被准确率收益抵消,单次成功成本不变。

打开论文原文
它要解决什么
仓库级行为保持型重构中,AST感知检索、多智能体委派和提示详细度,哪一项才真正提高成功率?
研究路径
平台给每个任务开独立工作区,终端实时流式记录token、diff和transcript。S2通过MCP做AST感知结构检索,用来替代示例检索。任务完成后,Python跑AST单测;Java按抽取、编译、测试、RefactoringMiner四步门禁判断行为是否保持。
这对工程意味着什么
第一步先给智能体接AST感知结构检索,并跑S1/S2/S3对照。要避开的捷径是默认增加智能体角色;本例中委派只有66%,低于检索86%,还不省单次成功成本。
证据定位
AST感知分块比token窗口分块高25-30个百分点;朴素检索反而低于无检索基线。S2单智能体结构检索通过率86%,S3多智能体委派66%;委派能通过的任务,检索全部能通过,反过来不成立。检索带来的准确率收益抵消token开销,单次成功重构成本基本不变。(筛选维度:可复核评测、软件工程方法)
适用边界
示范campaign只覆盖100个任务、四类模型;多智能体配置是作者自评的一种委派方案。结论范围限于RefactorBench这类AST可验证的多文件重构任务,未必推广到其他代码变更类型。
方法与英文摘要

数据用RefactorBench的100个多文件重构任务,四类模型经OpenRouter或GitHub Copilot CLI接入。执行分三档:S1基线、S2经MCP做AST感知结构检索、S3多智能体委派;提示分Descriptive、Base、Lazy三档。判定不看过表面diff:Python跑AST单测,Java跑抽取、编译、测试、RefactoringMiner门禁。

Repository-scale refactoring requires coding agents to propagate a single change across many interdependent files without altering program behavior, yet to our knowledge no existing harness isolates the design choices that determine agent success on this task. We present RefactorPlatform, an open-source evaluation harness that holds the environment fixed and varies each design axis explicitly: model backbone (via OpenRouter and GitHub Copilot CLI), execution regime (baseline, retrieval-augmented, and multi-agent), and prompt specificity. Each run executes in an isolated workspace with live terminal streaming, per-task logging of tokens, diffs, and transcripts, AST-based verification, and exportable telemetry for audit and reproduction. Demonstrating the platform on 100 multi-file RefactorBench tasks across four model families, we illustrate the analyses it supports: AST-aware chunking outperforms naive token-window chunking by 25-30% across prompt modes, whereas naive retrieval falls below the retrieval-free baseline; a lean retrieval-augmented single agent (86%) beats the sub-agent configuration we evaluated (66%) on matched tasks with no task passing under delegation that fails under retrieval; and retrieval's accuracy gains absorb its token overhead, leaving cost per successful refactoring unchanged. RefactorPlatform is open-sourced to make refactoring-agent evaluation reproducible and auditable.

形式化与程序验证 6/30

AxQM: A Textbook-Scale Benchmark for Formal Proof Synthesis in a Library of Finite-Dimensional Quantum Mechanics

AxQM:用1019个Lean任务给出物理证明合成的确定性评测,规模为此前最大基准的…:如果你要评测大模型能否自动补全物理证明里的隐藏步骤,以前没有可机器检验的物理证明基准可用。AxQM解决了这个问题:它取自Nielsen&Chuang教科书,含479个条目、1019个Lean 4证明任务,由内核判定编译通过、无sorry、无新增公理。

两句看懂

物理论证中的理想化假设常被省略,却缺少可机器检验的证明合成评测集来衡量自动形式化系统能否补全这些隐藏步骤。作者发布AxQM,取自Nielsen&Chuang教科书,含479个条目共1019个Lean证明任务,由内核检查编译通过、无sorry、无新增公理,任务规模为此前最大物理证明基准的4倍。

核心判断

能否用机器可检验方式评测物理证明自动形式化?可以。AxQM以1019个Lean任务、479个条目提供内核判定的确定性评测,规模达此前最大物理证明基准的4倍,且每题参考解私有保存。

关键要点

1.物理论证缺乏类似数学Mathlib的机器可检验规范,理想化假设常未写全,以往物理形式化基准规模零散、多为单个定理级。2.AxQM从Nielsen&Chuang教科书形式部分近乎完整形式化而来,拆出1019个Lean 4任务,由内核统一判定编译通过、无sorry、无新增公理。3.按任务数它是当前物理最大证明合成基准,为此前最大的4倍;做物理证明评测时可直接用它做确定性验收。

证据与结果

覆盖Nielsen&Chuang教科书形式化部分的大部分定理与习题;479个条目对应1019个证明合成任务;统一由Lean 4内核判定,无人工评分;与此前最大物理证明合成基准相比,AxQM任务数为其4倍。

打开论文原文
它要解决什么
能否用机器可检验的方式评测AI系统在量子力学教科书证明自动形式化中的正确性?
研究路径
从教科书近乎完整形式化出发提取479个条目;每条目拆分为一个或多个Lean语句,证明留空;限定有限维希尔伯特空间,复用Mathlib的有限维线性代数、谱定理、迹、张量积;参考解私有保存不公开;评测时Lean内核编译候选证明,检查无sorry、无新增公理,编译通过即判定正确。
这对工程意味着什么
第一步:构建形式化证明评测集时,用证明助手内核做判定,而不是人工评分或字符串匹配。要避免的捷径:不要拿模型自述的"证明正确"当验收标准。
证据定位
AxQM含479个条目、1019个任务,按任务数统计是当前物理学最大的证明合成基准,规模为此前最大基准的4倍。每题保证有解但解私有保存,防止泄漏。判定完全自动化,由Lean 4内核完成,无人工评分环节。(筛选维度:形式化验证、可复核评测)
适用边界
基准限定有限维希尔伯特空间,不覆盖无限维系统与无界算子;来源仅为Nielsen&Chuang一本教科书,覆盖其形式部分的大部分但非全部定理与习题。
方法与英文摘要

来源为Nielsen&Chuang《量子计算与量子信息》;将479个条目拆分为1019个Lean 4证明合成任务(证明留空);限定有限维希尔伯特空间,复用Mathlib有限维线性代数库;参考解私有保存;评测时由Lean内核编译候选证明,检查无sorry、无新增公理,通过即判定正确。

Formalizing mathematics in a proof assistant, where a machine checks every definition, statement and proof, has set a new standard of rigor. Large language models are now capable of formalizing autonomously, even at the scale of whole textbooks. We bring this standard of rigor to physics, where theoretical arguments carry idealizations that are rarely stated fully, and any logical gaps could have a cascading effect on interdependent results. Recognizing the need to evaluate autoformalization systems for physics, we release AxQM, 1,019 kernel-checkable proof-synthesis tasks over 479 items drawn from the textbook Quantum Computation and Quantum Information by Nielsen and Chuang. The tasks are stated in a custom Lean library of finite-dimensional quantum mechanics. By task count, it is the largest proof-synthesis benchmark in physics by a factor of four. AxQM is derived from a near-complete formalization of the formal portions of the textbook, so every task is guaranteed a solution, which we keep private. Grading of the benchmark is done deterministically by the Lean kernel, which checks that the proof compiles, that no sorry appears in it or in any declaration it depends on, and that it introduces no new axioms.

形式化与程序验证 4/30

Prove2Me: An Open Collaborative Platform for Scaling Math Formalization

Prove2Me:AI众包做Lean定理形式化:开放平台Prove2Me让持有AI智能体的用户发起数学形式化missions,人工审核只覆盖核心陈述,AI智能体用proof-sketch把证明拆成原子子任务并复用已完成结果,应对既有AI形式化的审核、复用与算力集中三大瓶颈。

两句看懂

过去大规模数学形式化依赖少数精通数学与Lean的专家,人工审核与复用瓶颈难以扩展到AI生成的海量定理。论文用mission机制把审核收窄到核心陈述、用proof-sketch把证明拆成原子子任务供多智能体复用,但摘录未给出已完成任务数或效果对比数据。

核心判断

答案:通过mission限定审核范围、proof-sketch实现任务拆解与跨智能体复用,可让无Lean背景者借助AI智能体参与大规模形式化;依据为平台机制设计本身,文中未给出量化效果证明。

关键要点

1. 既有AI辅助形式化工作依赖单一机构内部算力(如千级智能体规模项目)或需人工逐条核验AI生成定理,难以扩展到数十万条定理的审核与复用,Tau Ceti等项目也排除前沿研究论文形式化并要求衔接已有Mathlib材料。 2. Prove2Me让用户发起形式化mission,人工审核范围仅限mission对应核心陈述;通过type-based verification校验证明步骤类型;proof-sketch机制把复杂定理拆解为原子子问题,交由多个AI智能体分别求解并互相复用中间结果,已完成子证明进入可引用library。 3. Section5报告社区已完成的missions,Section6提供无需Lean或数学背景即可贡献的教程,但论文摘录未给出已完成任务数量、证明规模或与既有形式化项目的量化对比,决定性效果和失败模式仍待补充。

证据与结果

论文未提供基准数据集规模、任务难度分层或数值评测指标;Section5仅定性描述社区在平台上已完成的形式化missions,Section6是面向无Lean或数学背景贡献者的操作教程;摘录中未见与既有Lean库(如Mathlib、Tau Ceti)或其他AI形式化系统的对照实验、通过率或失败案例统计。

打开论文原文
它要解决什么
如何在无需人人精通Lean与专业数学的前提下,让任意持有AI智能体的个人协作完成大规模、可核验的数学形式化?
研究路径
用户在Prove2Me发起mission,提出待形式化定理;平台用type-based verification校验中间证明步骤类型是否匹配;AI智能体依proof-sketch把该定理拆解为若干原子子命题;各智能体分别对子命题求证并可调用他人已完成结果;完成的子证明进入可复用library;人工审核仅针对mission对应的核心陈述而非全部中间定理。
这对工程意味着什么
引入AI辅助形式化协作时,可参考核心陈述人工审核加子任务智能体自动分解求证加结果入库复用的分层设计;避免误以为增加智能体数量本身就能保证证明质量而省略核心陈述的人工核验。
证据定位
文中未给出已完成missions数量、证明产出规模或与Tau Ceti、Mathlib等既有库的量化对比数据,决定性效果证据在摘录中不足。(筛选维度:形式化验证)
适用边界
摘录未给出已完成missions的数量、任务来源分布或代表性说明,也未提供与Tau Ceti、Mathlib等既有形式化库的正式效果对比数据,量化边界和失败模式暂不明确。
方法与英文摘要

平台以用户发起的形式化mission为输入;通过type-based verification校验证明步骤类型;经proof-sketch机制把复杂定理拆解为原子子问题分派给多个AI智能体求解;已完成子证明进入可复用library;人工审核只覆盖mission对应核心陈述;Section5记录社区已完成missions,Section6为无Lean背景贡献教程。

Proof assistants such as Lean 4 promise the paradigm of formally verified mathematics, but large-scale formalization projects have faced major barriers to entry, including the need for expertise in formal verification (as well as the underlying mathematics) and the significant time required for writing formal proofs. AI coding agents have dramatically reduced these barriers; human users can now use natural language to prompt agents to write complex proofs in Lean. This opens up the intriguing possibility of internet-scale mathematical collaboration involving both humans and AI agents, where correctness is machine-checked. To realize this possibility, we introduce Prove2Me (https://prove2.me), an open collaborative platform for formalizing mathematics. Users launch formalization "missions", to which AI agents contribute formal proofs toward completion. We designed mechanisms and a specialized harness in Prove2Me that enable large-scale collaboration so that agents can build on one another's work and freely reuse existing results. In doing so, Prove2Me aims to turn math formalization into a scalable, crowd-sourced effort open to anyone with an agent.

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

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

Code Transformation Rule Synthesis using LLMs: Potential and Limits

LLM生成代码转换规则可行,但只限于强模型;复杂迁移任务小模型明显不行:大规模代码库演化时,直接让LLM逐文件改代码缺乏可解释性、结果不确定、成本高。这项研究给出另一条路:让LLM从代码变更前后对生成Comby、GritQL、Ast-Grep三种DSL的转换规则。评测显示GPT-5.4规则适用率和贴近真值程度在多数基准上最高,而小模型在复杂迁移场景表现明显下降。

两句看懂

直接用LLM改代码可解释性差、结果非确定、大规模场景成本高,该研究改为让LLM生成DSL转换规则。在六个数据集、四类演化任务上测试后,GPT-5.4规则适用率与贴近真值程度最高,小模型在复杂迁移任务上表现明显下降。

核心判断

LLM能否生成可用的代码转换规则?能,但有条件。GPT-5.4在六个数据集、四类任务上规则适用率和贴近真值程度均领先,证据是其规则适用率和与ground truth相似度的评测结果;小模型只在简单局部改动上有效。

关键要点

1. 旧做法的两难:DSL规则手写门槛高、维护贵,直接用LLM改代码又不可解释、不确定、成本高,此前缺少对LLM生成规则能力的实证评测。2. 方法与受控设置:三款模型在三种DSL、六个数据集、四类任务上,用变更前后代码对生成规则,部分实验加文档提示和Comby有限检索,并与反统一算法对比。3. 结果与行动:GPT-5.4适用率和贴近真值程度领先,可投入试用;小模型只胜任简单局部改动;LLM比反统一算法正确率高但适用率低,复杂迁移场景必须人工校验。

证据与结果

六个数据集覆盖API误用修正、程序修复、API迁移、语言版本迁移四类任务;GPT-5.4、GPT-oss-120B、Llama3.1-8B分别生成三种DSL的规则。评测维度为规则适用率、与真值接近程度、元变量泛化性和复用得分。结果:GPT-5.4多数基准最优;小模型在复杂迁移任务上表现下降;LLM较反统一算法正确率更高但适用率更低;多数数据集第一四分位复用得分较高。

打开论文原文
它要解决什么
能否让LLM从代码变更前后对推断出可复用、确定性的DSL转换规则,替代直接让LLM改代码?
研究路径
给LLM输入原始代码与演化后代码的配对,让它推断DSL(Comby/GritQL/Ast-Grep)的匹配-重写规则;部分实验追加DSL文档与规则示例提示,并对Comby加入有限检索。之后按规则适用率、与真值接近程度、元变量泛化性、复用得分四项指标评测,并与反统一算法对比。
这对工程意味着什么
第一步行动:对重复性代码演化任务,先让LLM生成DSL规则再批量应用,不要逐文件调用LLM改写。要避开的捷径:不要只看规则正确率一个指标,复杂迁移场景下规则适用性会明显打折,必须人工校验。
证据定位
GPT-5.4的规则适用率和贴近真值程度在多数基准上最高;GPT-oss-120B和Llama3.1-8B能处理简单局部改动,但在复杂迁移场景表现差;与反统一算法相比,LLM正确率更高,但规则适用性更低;多数数据集第一四分位复用得分较高。(筛选维度:可复核评测、软件工程方法)
适用边界
复杂迁移场景下小模型表现明显下降;规则适用性与正确性存在权衡,LLM相比反统一算法适用范围可能更窄;检索增强只在Comby上做了有限实验。
方法与英文摘要

用三款LLM(GPT-5.4、GPT-oss-120B、Llama3.1-8B)在六个数据集上生成Comby、GritQL、Ast-Grep三种DSL规则,覆盖API误用修正、程序修复、API迁移、语言版本迁移四类任务。输入是原始代码与演化后代码的配对,部分实验加入DSL文档和规则示例提示,并对Comby加入有限检索增强,同时与反统一算法(anti-unification)对比。

Due to their black-box nature, LLMs suffer from limited explain- ability and a lack of determinism. Their usage cost can also rise, particularly with repetitive tasks on large codebases. To mitigate this, we conduct a novel empirical study targeting three domain- specific languages for transformation rules, namely Comby, GritQL, and Ast-Grep. We evaluate three LLMs (GPT-5.4, GPT-oss-120B, and Llama3.1-8B) on six diverse datasets covering four software- evolution tasks: API misuse correction, program repair, API migra- tion, and language version migration. Our results provide evidence that transformation rule synthesis moves beyond proof-of-concept with strong frontier models. GPT-5.4 achieves consistently high rule applicability rates and produces transformations closest to the ground truth across most benchmarks. Smaller and open-weight GPT-oss-120B and Llama3.1-8B models remain effective for simpler, localized changes but struggle with complex migration scenarios. We also observe non-negligible generalizability through the usage of meta-variables and through a high reuse score in the first quartile of many datasets. Finally, when compared to the anti-unification algorithm, LLMs outperform it in correctness, but underperform in rule applicability. Overall, our results show great potential for LLMs to generate sound, correct, generalizable, and reusable rules.

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

Two Truths and A Lie? Benchmarking Off-the-Shelf LLMs for Requirements Quality Assessment: Performance, False Alarms, and Misses

现成大模型评审需求质量不可靠:最佳模型漏检过半、误报11%:如果你打算让大模型自动把关工程需求的质量,这项研究给出了直接的警示:十款主流模型中表现最好的也只检出专家标注问题的47%,还附带11%误报。研究用INCOSE标准建专家标注基准,对十款现成大模型做了五种温度各100次独立运行的系统测试。

两句看懂

现成大模型常被期待自动评审需求质量,但其可信度缺乏系统实证。研究以INCOSE标准建专家标注基准,对十款模型作五种温度各100次独立运行测试,发现最佳模型仅检出47%专家标注问题、误报11%,代际与温度变化对此均非单调改善。

核心判断

现成大模型尚不能可靠承担需求质量评审:最佳模型仅识别中位数47%的专家标注问题、误报11%,且需工程判断的必要性、正确性类问题几乎全部漏检。

关键要点

1.行业期待大模型自动承担需求质量评审,但此前研究多止步于可行性展示,缺乏对错误类型与可靠性的系统量化。2.研究以INCOSE标准构建专家标注基准,覆盖两套需求文本,对OpenAI与Anthropic各五代共十款模型,在五种温度下各独立运行100次,统计命中、漏检、误报。3.最佳模型仅检出中位数47%、误报11%,必要性、正确性类问题几乎全部漏检,代际与温度改善均非单调;结论是保留人工复核,不要全自动放行。

证据与结果

数据为两套工程需求文本,专家依INCOSE标准逐条标注缺陷作为基准。评测十款模型(OpenAI、Anthropic各五代),五种采样温度,每种设置独立运行100次,以命中率、漏检率、误报率为指标。结果:最佳Anthropic模型中位数命中47%、误报11%;必要性与正确性类问题几乎全部漏检;新一代模型未必优于旧代;温度变化对错误模式影响小且非单调。

打开论文原文
它要解决什么
现成大模型能否替代专家判断需求质量,既准确识别缺陷又不乱报误报?
研究路径
先由专家依据INCOSE标准对两套需求文本逐条标注缺陷类型,形成基准。再让十款大模型(OpenAI、Anthropic各五代)在五种采样温度下分别独立运行100次,对同一需求文本输出质量判断。最后逐条比对模型输出与专家标注,统计命中、漏检、误报,并按温度和代际分组比较,从而区分能力缺陷与随机波动。
这对工程意味着什么
第一步行动:部署大模型做需求质量评审时保留人工复核环节,把模型定位为决策支持,因为必要性、正确性类问题几乎全部漏检。要避开的捷径:不要假设换用更新代模型或调温度就能解决问题,代际提升和温度影响都非单调。
证据定位
最佳Anthropic模型仅检出专家标注问题的中位数47%,同时误报11%。必要性、正确性这类需要工程判断的问题几乎全部漏检。模型代际更新表现非单调,新一代未必优于旧代;温度变化对错误模式影响小且也非单调。(筛选维度:可复核评测、软件工程方法)
适用边界
仅评测两套需求文本、十款现成大模型(OpenAI、Anthropic各五代),未测试专门微调或多智能体编排方案,结论范围限于现成模型的直接调用场景。
方法与英文摘要

专家依据INCOSE需求质量标准,对两套工程需求文本逐条标注缺陷,形成基准。然后让OpenAI、Anthropic各五代共十款现成大模型,在五种采样温度下各独立运行100次,直接判定每条需求的质量缺陷,再与专家标注逐条比对,统计命中、漏检、误报三类结果。

Requirements engineering (RE) governs the quality of everything downstream in systems engineering (SE); defective requirements that survive review cycles propagate into design rework, schedule delays, and cost overruns. Because requirements are often written in natural language, recent advances in generative AI have raised expectations that large language models (LLMs) can absorb requirement quality assessment, a task otherwise slow and human expertise-intensive. Yet empirical evidence on whether LLMs can be trusted to do so remains scarce. This study presents the first benchmarking analysis of off-the-shelf LLM performance for requirement quality evaluation. Against an expert-derived ground truth built on INCOSE quality criteria, we evaluate ten models spanning two families (OpenAI and Anthropic) and five generations each, across one hundred independent runs, two requirement sets, and five sampling temperatures. Four contributions follow. First, we quantify a strongly asymmetric error profile: across all models and runs, the best-performing Anthropic model detects a median of only 47% of expert-identified issues while false-flagging 11%. Second, performance degrades significantly where SE judgment is required, as necessity and correctness issues are almost always missed. Third, generational progress is non-monotonic, so newer models cannot be assumed better. Fourth, this error behavior shifts only modestly and non-monotonically across sampling temperatures, indicating characteristic model deficiencies rather than inherent stochasticity. Off-the-shelf LLMs are therefore not yet trustworthy autonomous evaluators. Findings also warrant caution for Agentic AI developers: orchestrating these LLM modules in specialized architectures risks compounding these deficiencies rather than correcting them. Their defensible near-term role is human-in-the-loop decision support.

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

Requirements After the First Edit: Mining Late Requirement Emergence and Rework in Real-World Coding-Agent Sessions

需求迟到,编码代理的返工量翻倍:如果你在编码代理还没拿到完整需求时就让它改代码,这篇研究值得一看:对3553个真实编码代理会话的回放分析发现,需求在实现之后才到达时,先前写下的代码被删除或替换的量约为匹配非需求编辑的两倍,而且这个负担在整个会话内不随时间下降。这是首次把迟到需求和行级代码作废直接关联的测量。

两句看懂

编码代理常在需求说清楚前就动手改代码,但此前没人测量这类迟到需求造成多少无效劳动。研究对3553个真实会话回放核验,发现需求到达后代码被删除或替换的量约为匹配对照编辑的两倍,且该负担全程不随会话推进而减少。

核心判断

迟到需求确实显著增加代码作废:需求到达后作废量约为对照编辑的两倍,负担不随会话推进衰减,证据来自3553个真实会话的行级回放。

关键要点

1. 旧假设:策划基准要求需求先行、实现前固定;观察性研究只数用户"推回"频率,从未把某次需求到达与行级代码作废直接关联。 2. 方法:在SWE-chat数据集3553个会话中按三维度标注实现后新增需求,用可回放仓库状态计算先前写入行被删除/替换的行数作为作废指标,与匹配的非需求编辑对照,并用对照实验分别测试延迟披露与提前预警。 3. 结果与行动:迟到需求带来约2倍作废量且全程不衰减——在需求未澄清前应延迟大范围实现或采用小步可撤销编辑,不要用"推回"频率当返工成本。

证据与结果

数据源为SWE-chat数据集,3553个可用会话,子集限定为仓库状态可回放者;作废指标为先前代理写入行的删除/替换比例,与匹配的非需求编辑对照。结果:约2倍作废量;用户轮次控制和净删除量敏感性分析下方向不变;未见随会话时间下降;控制需求多重性后操作类型无可测关联;部分置信区间较宽;对照实验区分延迟披露与提前预警两种处理。

打开论文原文
它要解决什么
编码代理边写边改、需求中途才说清时,迟到需求是否会在同一会话内可测量地让先前代码作废?作废多少?
研究路径
对3553个SWE-chat会话逐轮标注需求到达,按三个需求工程维度分类;在可回放子集重建仓库状态,计算需求到达后先前代理写入行被删除或替换的比例,作为作废代理;用用户轮次匹配和净删除量做稳健性检验;另跑对照实验,操控需求披露时机(延迟披露 vs 提前预警)观察后续覆写变化。
这对工程意味着什么
第一步行动:需求未完全澄清前,延迟大范围实现,或采用小步可撤销编辑,因为迟到需求平均带来约两倍作废。要避免的捷径:不要仅凭用户"推回"频率评估返工成本,那忽略了行级代码作废的真实规模。
证据定位
需求到达后的作废量约为匹配非需求编辑的两倍;按用户轮次匹配和净删除量做稳健性检验,方向保持一致。会话内该负担未见随时间下降;控制需求多重性后,操作类型与作废无可测关联,部分置信区间仍较宽。对照实验显示,延迟披露把实现推迟到披露之后而非增加额外返工,单纯提前预警对覆写无可测效应。(筛选维度:可复核评测、软件工程方法)
适用边界
结果限于仓库状态可回放的会话子集;作废是删除/替换行数的代理指标,而非语义因果验证;观察到的是时间先后关联,未证实因果或语义联系;部分置信区间仍较宽。
方法与英文摘要

研究基于SWE-chat数据集的3553个可用会话,按三个需求工程维度标注实现之后才新增的需求;在仓库状态可回放的子集中,把先前代理写入代码被删除或替换的行数作为作废的代理指标,并与匹配的非需求编辑对照;另设对照实验,分别操控需求延迟披露和提前预警(不含需求内容),观察对后续覆写的影响。

Coding agents often implement changes before users have fully articulated their requirements, echoing a pattern from requirements engineering: stakeholders cannot express a constraint until part of the system exists to react to. This volatility is associated with schedule and budget overruns in traditional projects, but only at release-cycle granularity. Existing work on coding agents narrows this gap only partway: curated benchmarks fix requirements before implementation by design, and observational studies report pushback frequency without linking arrivals to the code invalidation they cause. We address this using 3,553 eligible SWE-chat sessions, coding post-implementation requirement arrivals along three dimensions and, where repository state can be replayed, linking each arrival to a proxy: deletion or replacement of prior agent-authored lines. A requirement's arrival is followed by roughly twice as much invalidation as matched non-requirement edits, robust to user-turn and net-deletion checks, though not demonstrated as causal. This burden shows no detectable decline over a session and no detected association with operation type once multiplicity is accounted for; several intervals remain wide. A controlled experiment shows delayed disclosure relocates implementation post-reveal, while advance warning produces no detected effect on overwriting. These results establish late requirement emergence as a measurable source of code invalidation.

代码质量与优化(1 篇)

代码质量与优化 6/30

Design Docs Are All You Need: An AI-native Machine-Learning Performance Tool

设计文档可以取代代码成为主干:AI按文档整体重生成性能建模库,精度达到舍入误差级:如果你的性能建模工具规格天天变、补丁越打越乱、AI代理又看不全整个仓库,这条经验值得看:把代码降级为临时产物,让人只维护自然语言设计文档,由子代理按依赖顺序整体重生成实现,再和人工审校的参考模型核验。重生成结果与参考模型(含DeepSeek-V3在TPU pod slice上的服务模型)一致,达到舍入误差精度。

两句看懂

增量打补丁的ML性能建模框架随规格演化持续积累技术债,AI代理又受上下文窗口限制难以全局重构,SMART改用设计文档DAG驱动子代理按拓扑序整体重生成实现。与人工审校参考模型(含DeepSeek-V3在TPU pod slice上的服务模型)核验,重生成结果一致,达到舍入误差精度。

核心判断

设计文档能否取代代码成为主干?可以:重生成实现在人工审校参考模型(含DeepSeek-V3/TPU pod)上与参考结果一致,达到舍入误差精度。

关键要点

1. 旧假设失效:增量打补丁让技术债随规格变化持续累积(文中记为Dt+1=G(St+1,Ct)-G(St+1)),AI代理又只能看到局部代码,改动局部合理、全局次优。 2. 方法加受控检查:主干是markdown设计文档DAG,只读代理推断依赖边,编排代理按拓扑序派专属子代理整体重生成,再经参考模型协调核验、参数范围守卫、单元测试三关后才替换旧版。 3. 决定性结果与动作:重生成实现在含DeepSeek-V3/TPU pod slice在内的多个人工审校参考模型上达到舍入误差精度;对快速演化的性能建模工具,可改为维护文档、定期整体重生成并核验。

证据与结果

论文没有独立测试集,也没有量化基准表。核验方式是把子代理重生成的实现与人工审校过的参考模型逐一比对,包括DeepSeek-V3在TPU pod基座切片上的服务模型,报告重生成结果达到舍入误差精度。论文未提供样本规模、重生成成功率,也未给出多次重生成的稳定性统计。

打开论文原文
它要解决什么
增量打补丁不断积累技术债、AI代理受上下文窗口限制只能做局部改动时,能否让自然语言设计文档取代代码,成为性能建模框架的长期可维护主干?
研究路径
只读代理解析每份设计文档并推断依赖边,构成DAG;编排代理按拓扑序给每份文档派发专属编码子代理生成实现,并维护日志,记录子代理理解困难和早期波次遗留的bug;生成结果依次过参考模型协调核验、参数范围守卫检查、单元测试;全部通过才替换旧实现;此后人只改文档文字,不碰代码。
这对工程意味着什么
第一步:对快速演化的性能建模工具,先把设计文档设为可维护主干,安排定期整体重生成并做参考结果核验。要避免的捷径:不要因为AI能改代码,就跳过参考模型核验和测试这三道关。
证据定位
重生成实现与人工审校的参考模型逐一比对,结果一致,达到舍入误差精度。参考模型包括DeepSeek-V3在TPU pod基座切片上的服务模型。具体差异数值、样本规模、测试数量,论文未给出。(筛选维度:可复核评测、软件工程方法)
适用边界
论文未给出独立测试集规模、重生成成功率或失败案例的量化统计;核验只是与若干人工审校参考模型做一致性比对,代表性范围有限。
方法与英文摘要

主干仓库几乎不放代码,放的是自包含markdown设计文档组成的DAG。只读代理读文档并机器推断依赖边,不靠人工维护。编排代理按拓扑序,给每份文档派一个专属编码子代理,整体重生成实现。生成后过三道关:与人工审校参考模型做协调核验、参数范围守卫、单元测试,全部通过才替换旧版本。人只改文档文字,不直接改代码。

Machine-learning performance modeling is a uniquely hostile terrain for long-lived software: the assumptions baked into today's abstractions are invalidated by tomorrow's models and systems, forcing perpetual refactoring of performance-modeling frameworks. Meanwhile, AI coding agents have become fast and capable enough that regenerating an entire library is cheaper than paying down the tech debt of incrementally patching it. We describe SMART, a rigorous symbolic performance-modeling library for ML systems whose main branch contains almost no code: the repository is a DAG of self-contained natural-language design docs, coding sub-agents regenerate the implementation from only the docs on new version updates, and every human change is a natural-language edit to a doc--self-documenting by construction. Two ingredients make regeneration reliable: (i) a design-doc style built around step-by-step worked examples that act as in-context demonstrations for the generating agents, and (ii) a minimal, recursively defined operator IR with symbolic (SymPy) cost expressions, a fast analytical roll-up mode for large sweeps, and a slow modulo-scheduling mode for fine-grained schedule studies. Regenerated implementations reproduce hand-audited reference models--including DeepSeek-V3 serving on a TPU pod slice--to round-off precision, suggesting that design docs--not code--can be the durable artifact for ML-systems co-design tools.

UI 与 GUI Agent(1 篇)

UI 与 GUI Agent 4/30

Framework and Benchmark for Code-Driven Agentic Testing in Web Development

主流VLM在代码驱动网页测试中全线查错不佳:如果你用AI生成网页,靠预定义清单做验收正在失效:清单覆盖不了网页自己长出来的功能和隐蔽缺陷。这项研究用CAT方法让智能体自己写Playwright脚本探索页面找漏洞,并在102个人工标注漏洞的网页基准CATTest上实测,结果所有主流VLM表现都不理想。

两句看懂

既有网页测试依赖预定义清单,难以覆盖AI生成网页超出预期的功能与隐蔽缺陷,这项研究改用代码驱动智能体自主编写Playwright脚本探索发现漏洞。研究在102个人工标注漏洞的AI生成网页组成的CATTest上测试主流VLM,结果显示所有模型表现均不佳。

核心判断

清单式评测衡量不了VLM的真实查错能力。证据是:在代码驱动自主探索测试CATTest上,所有被测主流VLM表现均不佳,能力与真实测试需求差距明显。

关键要点

1. 旧假设失效:清单式GUI用例只能验证模型会不会执行预定步骤,AI生成网页常有清单没预料的功能,网页越复杂清单成本越高、效率与可靠性越低。 2. 方法与受控检验:CATJudge在同一环境统一Browser-Use与Computer-Use工具,智能体写Playwright代码驱动浏览器并采集文本与视觉反馈,在102个人工标注漏洞的AI生成网页基准CATTest上对照检验。 3. 决定性结果与行动:所有被测主流VLM漏洞发现表现均不佳,验收AI生成网页时应让智能体自主探索,而不是只核对清单。

证据与结果

CATTest含102个AI生成网页应用,漏洞经人机协作迭代标注,涵盖复杂交互与隐蔽缺陷;CATJudge统一两类GUI工具执行代码驱动测试。多款主流VLM在该基准上的具体准确率数值与错误类型分布文中未给出,结论是所有被测模型漏洞发现表现均不佳。

打开论文原文
它要解决什么
预定义清单式评测,能不能衡量视觉语言模型在真实网页应用里发现漏洞的能力?
研究路径
智能体接收AI生成网页任务后,编写Playwright代码执行点击、输入等操作驱动浏览器;从渲染结果读取文本与视觉反馈;基于反馈自主决定下一步探索路径;持续迭代,直到发现与人工标注一致的漏洞或耗尽探索预算。
这对工程意味着什么
第一步行动:给AI生成网页做质量验收时,先让智能体自主编写浏览器操作脚本去探索缺陷,而不是逐条核对预定义清单。要避免的捷径:只靠清单验证,它会随网页复杂度上升逐渐失效。
证据定位
在CATTest上对多款主流VLM做代码驱动测试,所有被评估模型的漏洞发现表现均不佳。具体准确率数值与错误类型分布原文未给出,但结论明确:当前VLM能力与真实网页开发测试需求之间存在明显差距。(筛选维度:可复核评测)
适用边界
CATTest规模为102个AI生成网页应用,标注依赖人机协作;文中未提供具体准确率数值与更细分的错误类型分布,结论代表性以此规模为限。
方法与英文摘要

研究构建CATJudge框架,把Browser-Use与Computer-Use两类GUI智能体工具放进同一环境。智能体拿到网页任务后自己编写Playwright代码驱动浏览器,采集文本与视觉反馈,自主决定下一步操作来发现异常。配套基准CATTest含102个AI生成网页应用,漏洞由人机协作反复标注,覆盖复杂交互与隐蔽缺陷。

End-to-end GUI testing is essential for verifying web applications, yet existing evaluations rely on predefined checklists and are confined to the data and frameworks of web generation benchmarks, leaving the bug-discovery ability of vision-language models (VLMs) systematically untested. We introduce \textbf{C}ode-driven \textbf{A}gentic \textbf{T}esting (CAT), a paradigm in which the agent writes Playwright code to drive the browser, gathers feedback, and autonomously explores web applications to uncover bugs. We instantiate CAT with CATJudge, an agentic framework that unifies Browser-Use and Computer-Use tools within a single environment and CATTest, a benchmark of 102 AI-generated web applications with carefully annotated bugs, built through close human-AI collaboration to feature complex interactions and subtle defects. Experiments with mainstream VLMs show that all evaluated models perform poorly, revealing a clear gap between current VLM capabilities and the demands of real-world testing in AI web development. We release our code and data at https://github.com/SleepyWithoutCoffee/CATJudge.

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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

本轮分类概览

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

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

近一个季度监测日历

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

近 14 次监测窗口

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

本轮新增候选(6 篇)

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

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

形式化与程序验证 · 6/30 · 2026-09-04量子力学教材规模证明综合基准AxQM 含 1,019 个 Lean 可校验任务与 479 条目,取材 Nielsen-Chuang;称物理AxQM: A Textbook-Scale Benchmark for Formal Proof Synthesis in a Library of Finite-Dimensional Quantum Mechanics

Formalizing mathematics in a proof assistant, where a machine checks every definition, statement and proof, has set a new standard of rigor. Large language models are now capable of formalizing autonomously, even at the scale of whole textbooks. We bring this standard of rigor to physics, where theoretical arguments carry idealizations that are rarely stated fully, and any logical gaps could have a cascading effect on interdependent results. Recognizing the need to evaluate autoformalization systems for physics, we release AxQM, 1,019 kernel-checkable proof-synthesis tasks over 479 items drawn from the textbook Quantum Computation and Quantum Information by Nielsen and Chuang. The tasks are stated in a custom Lean library of finite-dimensional quantum mechanics. By task count, it is the largest proof-synthesis benchmark in physics by a factor of four. AxQM is derived from a near-complete formalization of the formal portions of the textbook, so every task is guaranteed a solution, which we keep private. Grading of the benchmark is done deterministically by the Lean kernel, which checks that the proof compiles, that no sorry appears in it or in any declaration it depends on, and that it introduces no new axioms.

阅读 arXiv 原文
形式化与程序验证 · 8/30 · 2026-09-04仓库级重构智能体评测平台开源评测框架,固定环境并变换模型、执行方式与提示;在 100 个 RefactorBench 任务、四类模型上RefactorPlatform: An Open-Source Harness for Controlled Evaluation of Repository-Scale Refactoring Agents

Repository-scale refactoring requires coding agents to propagate a single change across many interdependent files without altering program behavior, yet to our knowledge no existing harness isolates the design choices that determine agent success on this task. We present RefactorPlatform, an open-source evaluation harness that holds the environment fixed and varies each design axis explicitly: model backbone (via OpenRouter and GitHub Copilot CLI), execution regime (baseline, retrieval-augmented, and multi-agent), and prompt specificity. Each run executes in an isolated workspace with live terminal streaming, per-task logging of tokens, diffs, and transcripts, AST-based verification, and exportable telemetry for audit and reproduction. Demonstrating the platform on 100 multi-file RefactorBench tasks across four model families, we illustrate the analyses it supports: AST-aware chunking outperforms naive token-window chunking by 25-30% across prompt modes, whereas naive retrieval falls below the retrieval-free baseline; a lean retrieval-augmented single agent (86%) beats the sub-agent configuration we evaluated (66%) on matched tasks with no task passing under delegation that fails under retrieval; and retrieval's accuracy gains absorb its token overhead, leaving cost per successful refactoring unchanged. RefactorPlatform is open-sourced to make refactoring-agent evaluation reproducible and auditable.

阅读 arXiv 原文

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

软件工程与仓库智能 · 4/30 · 2026-09-04挖掘GitHub软件过程非代码产物Ritgard 抽取 GitHub Issues/PR 等非代码社会技术产物,补足代码之外的项目脉络;无效果数Ritgard: T(r)opical Islands of Socio-Technical Artifacts on GitHub

A software project is more than just code. Non-code artifacts often document the human processes and decisions behind source code. The rationale behind a library change, an architectural decision, a problem encountered by a user are all examples of information typically present in socio-technical artifacts (STAs), created and persisted in channels separate from the repository itself (yet sometimes very close---e.g., GitHub Issues with GitHub repositories). These STAs are a trove of information about the project's architecture and its evolution, containing details and insights that code alone cannot provide. Unfortunately, this information is not easily extracted and explored as STAs are frequently fragmented over different communication channels, and are written in natural language. We present Ritgard, a tool that mines GitHub repositories for their STAs, namely Issues, Pull Requests, and Discussions, and visualizes them as 3D islands covered with trees. Each tree represents a single artifact and each island is a topic extracted from the artifacts through a combination of text embedding and text summarization. The terrain of the islands rises out of the ocean as the topic becomes active and sinks back in when it becomes stale, thus depicting the evolution of features and concerns throughout the project's lifetime. We describe the tool's usage and implementation, showing the numerous technical challenges behind Ritgard's visualization.

阅读 arXiv 原文
软件工程与仓库智能 · 6/30 · 2026-09-04LLM程序修复中的幻觉分析对 832 个 Defects4J 缺陷、三种代表性 LLM 分析补丁与中间产物的幻觉;摘要未给修复成效结论。Better Understanding, Better Fixes? A Study of Hallucination in LLM-based Automated Program Repair

Large language models (LLMs) have significantly advanced automated program repair (APR), yet existing evaluations remain largely result-centric and provide limited insight into hallucination during repair. In APR, hallucination may arise not only in final patches but also in the intermediate artifacts that guide patch generation. To address this gap, we perform a multi-layered analysis of hallucination throughout the APR process. Specifically, we characterize hallucination as the production of patches or intermediate artifacts that are not faithfully grounded in the available repair evidence. We examine repair hallucination in final patches and understanding hallucination in intermediate artifacts through three tasks, namely triggering testcase identification, line coverage prediction, and additional testcase generation.We then evaluate three representative LLMs on 832 Defects4J bugs through automatic evaluation and manual analysis. Our results show that both repair and understanding hallucinations remain prevalent. Across models and settings, only 21.0%-55.9% of generated patches pass the developer-written test suite. Moreover, although more accurate intermediate artifacts are generally associated with successful repairs, this relationship does not always hold. Manual analysis of 812 sampled repairs identifies repair hallucinations in 72.7% of cases, including patches that pass all available tests; incorrect causal localization and incorrect repair strategies account for 45.9% and 18.5% of these hallucinations, respectively. Meanwhile, models frequently misidentify triggering testcases, mispredict line coverage involving branching control flow, and generate additional testcases with missing bug-triggering conditions or incorrect expected behavior.

阅读 arXiv 原文
软件工程与仓库智能 · 6/30 · 2026-09-04智能体软件交付瓶颈与成本综述综述代码智能体从生成到交付的收益衰减与成本变化:评审、集成、测试等成瓶颈;属综合观点而非新实验。Beyond Code Generation: Reliability, Verification, and Cost Economics in the Agentic Software Development Lifecycle

AI coding systems are moving from autocomplete and chat toward agents that can inspect repositories, edit multiple files, run tools, write tests, open pull requests, and work for long periods with limited supervision. This capability changes the bottleneck in software delivery. Recent field studies show meaningful gains in coding activity, but newer evidence also shows that those gains attenuate sharply between writing code and shipping reliable software. Review, integration, testing, security, deployment, and production operations remain constraining stages, while the economics are shifting from predictable per-seat licensing toward variable token, tool, sandbox, CI, and rework costs. This paper synthesizes peer-reviewed software-engineering research, university studies, benchmark audits, production reports from major technology companies, developer telemetry, and cost-management evidence released primarily from 2024 through September 2026. No new model experiment is claimed; numerical findings remain attributed to their original studies. The synthesis proposes four engineering concepts: the Agentic SDLC Throughput Paradox, Production-Qualified Change (PQC), the Verification Tax, and an Agentic SDLC Control Plane that allocates autonomy subject to cost, reliability, and human-attention budgets. An evidence-based horizon then maps today's supervised agents to future policy-bounded software factories. The central research question shifts from how much code an agent can generate to how much production-qualified value an engineering system can deliver per dollar, per reviewer-hour, and per unit of operational risk.

阅读 arXiv 原文

代码质量与优化(1 篇)

代码质量与优化 · 6/30 · 2026-09-04设计文档驱动的ML性能建模库提出 SMART:仓库以自然语言设计文档 DAG 为主,由编码智能体据文档重新生成实现;未见定量评测。Design Docs Are All You Need: An AI-native Machine-Learning Performance Tool

Machine-learning performance modeling is a uniquely hostile terrain for long-lived software: the assumptions baked into today's abstractions are invalidated by tomorrow's models and systems, forcing perpetual refactoring of performance-modeling frameworks. Meanwhile, AI coding agents have become fast and capable enough that regenerating an entire library is cheaper than paying down the tech debt of incrementally patching it. We describe SMART, a rigorous symbolic performance-modeling library for ML systems whose main branch contains almost no code: the repository is a DAG of self-contained natural-language design docs, coding sub-agents regenerate the implementation from only the docs on new version updates, and every human change is a natural-language edit to a doc--self-documenting by construction. Two ingredients make regeneration reliable: (i) a design-doc style built around step-by-step worked examples that act as in-context demonstrations for the generating agents, and (ii) a minimal, recursively defined operator IR with symbolic (SymPy) cost expressions, a fast analytical roll-up mode for large sweeps, and a slow modulo-scheduling mode for fine-grained schedule studies. Regenerated implementations reproduce hand-audited reference models--including DeepSeek-V3 serving on a TPU pod slice--to round-off precision, suggesting that design docs--not code--can be the durable artifact for ML-systems co-design tools.

阅读 arXiv 原文

UI 与 GUI Agent(0 篇)

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

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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