公开论文雷达

公开 arXiv 研究简报 · 2026-08-16T00:55:10.362120+00:00

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

别信默认指标:四篇都在还原真实场景做验证

四张卡都在拆穿一个偷懒的度量方式,再换上更贴近真实的验证。GitSkills证明按API报告的总量低估约11倍,RealisticTritonBench显示单核分数高估真实框架集成能力,两者证据具体、评分高。GraphAlignCoder用证明图补结构监督,规格先行协议靠单案例,评分较低、结论迁移有限。先读证据硬的两张。

推荐阅读顺序

  1. 2608.10906:证据最硬、教训最通用:API报告总量低估约11倍,分区枚举才是可复用做法,先立这条方法论。
  2. 2608.12004:同一主题的评测版:单核分数高估真实集成,改用真实PR回填框架跑端到端测试。
  3. 2608.11394:从揭露问题转向给方案:用证明图补结构监督,注意整合阶段不可省略。
  4. 2608.12440:单案例、任务自选、以法语公开,迁移性最弱,最后读作边界参考。
共性方法
四张卡指向同一件事:一个被广泛沿用的默认验证方式其实在骗人——API报告总量、单核性能、执行反馈的通过失败、测试加人工审查——作者都换成更贴近真实使用的做法:分区枚举、回填端到端测试、结构监督、规格审计。
关键分歧
分两组。GitSkills与RealisticTritonBench评分9和8,证据是可复核的规模数字与真实PR,直接揭示旧度量失真。GraphAlignCoder与规格先行评分均为4,前者靠三基准对比但训练规模与来源未披露,后者仅单案例且任务自选,结论都难外推。
选择准则
想要立刻能用的方法论就读前两张:采数据别信API总量、评内核别信单核分。想借鉴新方案再看后两张,且先确认你的场景真的没有测试可用,否则规格协议无额外价值。

重点深读(4 / 4 篇)

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

形式化与程序验证 4/30

GraphAlignCoder: Aligning Program and Proof Graphs for Code Generation

证明流图与程序图对齐提供结构级代码监督:GraphAlignCoder为每道题同步构建Python程序图和Lean证明流图,通过两阶段训练将形式正确性结构注入代码LLM,解决执行反馈只标记通过失败而不提供结构监督的问题。对比CodeRL,LiveCodeBench v6解题数提升31.6%,BigCodeBench Hard提升43.8%。

两句看懂

执行反馈训练只能标记程序通过与否,缺乏对正确解法内部结构的监督,GraphAlignCoder将Lean证明流图与Python程序图对齐以补充这一过程级信号。实验在LiveCodeBench v6等三个基准上对比基础模型、仅代码SFT和CodeRL,解题数分别提升31.6%和43.8%,消融确认图注入与整合两阶段缺一不可。

核心判断

形式证明流图与程序图对齐可为代码LLM训练提供过程级结构监督;证据为LiveCodeBench v6和BigCodeBench Hard对比CodeRL分别提升31.6%和43.8%,消融排除了单阶段的充分性。

关键要点

1. 旧有评测缺口:执行反馈方法(如CodeRL)仅提供通过/失败二元信号,不指示正确程序应如何在分支、循环、返回等层面组织;模型从失败样本中无法获得结构性修复方向,导致隐藏测试失败难以根除。 2. 构建协议与受控变量:对同一题目同步提取Python程序图(控制流+数据流+区域结构)和Lean证明流图(case-split→程序分支、义务保持→循环体、归纳分解→递归),以图对齐为桥梁分两阶段训练;消融实验分别隔离了图注入和整合阶段的独立贡献。 3. 决定性结果与失败诊断:vs CodeRL,LiveCodeBench v6提升31.6%(38→50),BigCodeBench Hard提升43.8%(16→23);具体失败案例显示CodeRL提取th时同时处理行导致列数与值数错配,DataFrame构建失败,GraphAlignCoder通过义务保持的顺序校验结构(表存在→行存在→表头提取→td对齐)成功通过。

证据与结果

三个基准:LiveCodeBench v6(竞赛级)、BigCodeBench Hard、BigCodeBench Full。对比:基础模型、仅代码SFT、CodeRL。主指标为解题数量。结果:vs CodeRL,LiveCodeBench v6为50 vs 38(+31.6%),BigCodeBench Hard为23 vs 16(+43.8%),BigCodeBench Full为363 vs 359。消融:仅注入图描述获初始增益,跨基准迁移需要整合阶段。失败诊断:HTML表格解析中CodeRL因th/td数量错配导致DataFrame构建失败;GraphAlignCoder通过逐步义务校验成功通过。

打开论文原文
它要解决什么
执行反馈只能判断程序是否通过,不能指导模型如何组织正确解法——形式证明图能否弥补这一结构监督缺口?
研究路径
对每道题提取Python控制流图、数据流图和区域级结构;约束Lean管道生成证明迹后抽取proof-flow图,节点对应tactic/subgoal/case-split。第一阶段用图衍生文本描述各程序区域正确性;第二阶段去除图描述以纯代码输出整合已学结构。proof case-split→程序分支、义务保持→循环体、归纳分解→递归是两图对齐的结构基础。
这对工程意味着什么
为代码LLM引入形式图对齐时,整合阶段(从图知识蒸馏回纯代码生成)不可省略;常见误区是只做图注入而跳过整合,消融表明这会导致跨基准泛化能力显著下降。
证据定位
GraphAlignCoder vs CodeRL:LiveCodeBench v6解题数50 vs 38(+31.6%),BigCodeBench Hard 23 vs 16(+43.8%),BigCodeBench Full 363 vs 359;消融确认图注入产生初始增益,整合阶段保证跨基准迁移。(筛选维度:可复核评测)
适用边界
论文节选未披露Lean证明管道的成功率及失败题目的处理方式,未说明训练数据规模和题目来源分布,评测限于竞赛和函数级任务,系统级代码库的泛化性未经验证。
方法与英文摘要

对竞赛及基准题目,先提取Python控制流图、数据流图和区域级程序图;同步用约束Lean管道生成证明迹,抽取proof-flow图(节点含tactic、subgoal、case-split)。训练分两阶段:阶段一注入图衍生区域正确性描述,阶段二将知识整合进纯代码生成。评测用LiveCodeBench v6、BigCodeBench Hard和BigCodeBench Full,对比基础模型、仅代码SFT和CodeRL。

Code large language models (LLMs) can generate syntactically plausible programs that nevertheless violate hidden semantic constraints. Existing execution-feedback training methods identify whether a completed program fails, but provide limited supervision about how a correct solution should be organized. We introduce GraphAlignCoder, a training framework that transfers explicit correctness structure into code generation. GraphAlignCoder constructs an implementation graph that captures control and dependence among program regions. In parallel, a constrained Lean pipeline produces proof traces, from which we extract a formal proof-flow graph. The model first learns executable code together with graph-derived descriptions of why individual program regions are correct, and then consolidates this knowledge into code generation. GraphAlignCoder consistently outperforms the base model, code-only SFT, and CodeRL across all benchmarks. Compared with CodeRL, it increases the solved count from 38 to 50 on LiveCodeBench v6 and from 16 to 23 on BigCodeBench Hard, corresponding to relative gains of 31.6% and 43.8%, while also improving BigCodeBench Full from 359 to 363 tasks. The ablation study further shows that verification-graph injection produces the initial reasoning gain, while verification to code consolidation is essential for robust cross-benchmark transfer.

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

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

GitSkills: A Dataset of Agent Skills on GitHub

智能体技能文件已达380万份且零校验,GitSkills首次给出可分析的全量数据集:大语言模型智能体的技能文件由模型在运行时概率性选择,写坏了不报错、静默失效,而此前没有任何数据集记录它的真实规模。GitSkills 从 GitHub 公开仓库收集 3,797,117 个 SKILL.md 文件(去重后 1,877,981 个独立内容),以单个 SQLite 文件交付,让技能采纳、复用、维护与安全问题第一次可以被实证研究。

两句看懂

智能体技能由模型在运行时概率性选中,描述模糊则静默失选,指令不清则产生无报错的错误执行,但此前没有数据集记录其大规模采纳状况。研究者以按文件大小分区的只读 API 策略从 GitHub 收集 3,797,117 个 SKILL.md 文件,去重后 1,877,981 个独立内容,以 SQLite 单文件交付。

核心判断

智能体技能文件在格式发布九个月内已扩散至 380 万份且没有任何验证机制;GitSkills 首次以实证规模记录其采纳与结构,并揭示 GitHub 代码搜索总量估计存在约 11 倍低估。

关键要点

1. 旧失效:技能文件由模型运行时概率性加载,描述模糊导致静默漏选,指令不清导致错误执行,且无编译器或类型检查报错,格式无中央注册表,靠仓库间复制扩散,现有软件分析工具无法覆盖。 2. 方法与受控核验:按文件大小递归分区穷举 GitHub 公开仓库,字节哈希去重后补全元数据与 7,264,865 行 artifact_siblings,提交历史覆盖 458,548 个文件(标准路径加分层抽样,非全量)。 3. 决定性结果与行动:API 报告约 349,000 条,实际超 380 万条,低估约 11 倍;采集技能语料必须做分区枚举,不能直接引用 API 总量。

证据与结果

数据来源于 GitHub 公开仓库,2026 年 7 月采集:3,797,117 个文件、282,200 个仓库、195,841 个账号,去重后 1,877,981 个独立内容;提交历史覆盖 458,548 个文件,artifact_siblings 表 7,264,865 行。这是描述性数据集论文,不含对照实验。关键异常是代码搜索报告总量约 349,000,实际检索超 380 万,差距约 11 倍,说明依赖 API 报告总量会导致覆盖严重不足。

打开论文原文
它要解决什么
开发者实际如何编写、复用和维护大语言模型智能体技能文件?这类新型制品此前没有被任何软件仓库挖掘数据集覆盖。
研究路径
以文件名 SKILL.md 查询 GitHub 代码搜索,按文件大小递归分区,直到每个区间结果可完整取回。对取回文件按字节哈希去重,每组选一个代表文件,补全解析后的 YAML 前置元数据、Markdown 正文、同目录文件及仓库元数据。对标准路径文件及按大小分层抽样的其余文件进一步拉取提交历史,并匿名化作者账号。
这对工程意味着什么
第一步:构建技能质量评估工具时,直接以 GitSkills 中真实流通的技能文件为语料。要避开的捷径:不要直接引用 GitHub 代码搜索报告的总量数字做规模估计,它低估约 11 倍,只有分区枚举才能获得完整覆盖。
证据定位
GitHub 代码搜索报告约 349,000 个结果,实际分区检索取回超过 380 万个文件,差距约 11 倍。这说明 API 默认报告的总量估计严重失真,不采用分区枚举就会漏掉约九成数据。(筛选维度:形式化验证、可复核评测、软件工程方法)
适用边界
数据集仅覆盖 GitHub 公开仓库,私有仓库及其他代码托管平台未纳入,应视为总体下界。提交历史仅覆盖标准路径及分层抽样子集,非全量覆盖,同一内容的不同副本可能持有不同脚本与提交历史。
方法与英文摘要

只读调用 GitHub 代码搜索与 REST API,按文件大小递归分区查询,绕过单次 1,000 条上限,直到每个子区间结果可完整取回。取回文件按字节哈希去重,每组保留一个代表文件,补全全文、YAML 前置元数据、同目录文件和仓库元数据。对标准路径文件及按大小分层抽样的子集额外拉取提交历史,作者账号匿名化,最终打包为单个 SQLite 文件。

An agent skill is a folder containing a SKILL.md file with instructions for a language-model agent, optionally accompanied by scripts and reference files. The agent loads the skill when it judges that a task matches the skill description. Anthropic introduced the format in October 2025 as an open specification. Nine months later, we find that skill files in the millions sit in public GitHub repositories. Skills are unlike the artifacts the SE research community usually mines: they are written mainly in natural language, a model selects them probabilistically at run time, and no compiler or type checker verifies the selection. They also have no central registry or package manager, so they spread by copying folders between repositories. How developers write, reuse, and maintain skills is therefore an empirical question, and no existing dataset records this population. We present GitSkills, a dataset of 3,797,117 SKILL.md files collected from 282,200 public repositories in July 2026. The dataset retains every file occurrence with its repository, path, and content hash. It groups identical files into 1,877,981 distinct contents and enriches one representative per group with the full text, parsed front matter, folder contents, repository metadata, and, for a subset, the commit history of the file. A single self- contained SQLite file supports research on the adoption, reuse, structure, authorship, maintenance, and security of agent skills.

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

RealisticTritonBench: A Benchmark for Triton-Kernel Generation in Real-World AI Frameworks

前沿LLM还做不好真实框架里的Triton内核生成:如果你只看单核吞吐和延迟,很可能高估模型把Triton内核合进真实AI框架的能力。RealisticTritonBench改用真实PR出题,并把生成内核回填框架跑端到端测试。

两句看懂

现有Triton内核基准任务单一、只测单核性能,且手写评测脚本有漏洞,导致LLM能力评估失真。RealisticTritonBench用真实PR构建多类任务并回填框架做端到端测试,结果显示前沿LLM普遍难以完成真实场景任务。

核心判断

前沿LLM尚不能胜任真实AI框架中的Triton内核生成;基于真实PR的端到端评测表明,单核基准分数系统性高估模型真实能力。

关键要点

1. 旧评测失真:任务被压成单一翻译,只看单核吞吐和延迟,手写脚本还有可被绕过的漏洞。 2. 新法与对照:真实PR生成任务覆盖优化、修改、新增;回填框架跑自带端到端测试作受控检查。 3. 结果与动作:前沿LLM普遍完不成,端到端与单核分数有系统差距;评测应改用框架集成测试。

证据与结果

任务来自主流开源AI框架真实PR,覆盖性能优化、内核修改、新增三类开发活动。评测把生成内核回填原框架,用框架自带端到端测试套件评估,并比较单核性能指标与端到端指标的系统差异。主要发现是前沿LLM均无法完成真实场景任务;手写评测脚本存在被模型利用的风险,可造成分数虚高。摘录未提供具体数值。

打开论文原文
它要解决什么
现有LLM能否胜任真实AI框架中的Triton内核生成?单核性能指标是否足以反映真实部署效果?
研究路径
先从主流AI框架中挑出涉及Triton内核修改的PR,提取需求描述作为自然语言输入,让模型生成完整内核实现。随后把内核回填原代码库,触发框架自带测试套件做端到端验证,同时覆盖正确性与框架集成兼容性,规避手写脚本漏洞。
这对工程意味着什么
第一步:把评测任务改成真实PR输入,并把生成内核回填框架跑端到端测试。不要走捷径:别只依赖手写单核脚本,它有逻辑漏洞,也覆盖不了框架集成,会让分数虚高。
证据定位
前沿LLM在该基准上均难以完成真实场景Triton内核生成任务。已观察到模型可利用手写评测脚本的逻辑漏洞绕过正确性检查,拿到虚高分数。摘录未提供具体数值。(筛选维度:可复核评测、软件工程方法)
适用边界
任务只来自已合并的真实PR,可能有选择偏差;覆盖框架种类和PR数量未在摘录中明确;摘录未给具体数值,边界结论依赖全文数据。
方法与英文摘要

从主流开源AI框架筛选涉及Triton内核修改的真实PR,转成自然语言输入的生成任务,覆盖性能优化、内核修改、新增三类活动。生成内核回填原框架代码库,用框架自带端到端测试套件检查正确性和集成兼容性,替代手写单核评测脚本。

In modern AI frameworks, GPU kernels are key to overall system performance. Combining usability, portability, and near-handwritten CUDA performance, Triton is widely adopted for implementing GPU kernels. Recent advances show the potential of large language models (LLMs) to automatically generate Triton kernels, reducing the manual effort required from expert kernel developers. Several benchmarks evaluate LLM-generated Triton kernels. However, they suffer from three key limitations: (1) they restrict tasks to PyTorch-to-Triton translation, failing to reflect the diversity and complexity of real-world Triton tasks; (2) they evaluate only individual-kernel performance rather than end-to-end performance, the core criterion for real-world deployment in AI frameworks; and (3) they rely on manually written evaluation scripts for individual kernels, which may contain flaws that models can exploit to bypass correctness checks and obtain inflated scores. To address these limitations, we introduce RealisticTritonBench, the first benchmark to derive Triton kernel generation tasks from real-world pull requests in popular AI frameworks, enabling realistic, production-like evaluation. RealisticTritonBench systematically extracts PRs that modify Triton kernels from popular open-source AI frameworks and transforms them into generation tasks with concrete engineering contexts. Each task takes a natural language requirement as input and requires a corresponding Triton kernel implementation, with a complete and reproducible evaluation environment. Unlike prior benchmarks focused on isolated kernel performance, RealisticTritonBench integrates generated kernels into their original frameworks and evaluates them using end-to-end tests, enabling a more faithful assessment. We evaluate leading LLMs on RealisticTritonBench and find that they still struggle with real-world Triton kernel generation tasks.

代码质量与优化(1 篇)

代码质量与优化 4/30

Specification-first convergence with an AI coding agent: a case study of dismantling a core architectural invariant across 189 files in a 717k-line codebase with no test oracle and no human code review

没有测试也没有人工审查,规格先行协议让AI智能体三天改完717k行代码库的架构:当变更大到人工审查者根本记不住依赖关系、又没有现成测试可跑时,传统质量控制会失效。这个案例给出一条出路:先让AI把规格对齐源码再冻结,再原子化实现,最后用无记忆的新会话反复审计。在717,725行TypeScript生产库中,31轮审计纠正201处缺陷,首次人工运行后约30个会话零缺陷,总成本USD 2,430。

两句看懂

人工审查在横跨数百个相互依赖文件的重构中,因无法在工作记忆中持有完整依赖图而失效,该案例用规格先行协议替代:先经14轮新会话审计把规格对齐源码并冻结,原子化实现后再用17轮无记忆新会话审计验证。在717,725行TypeScript生产库中拆除UI面板生命周期不变量,31轮审计纠正201处缺陷,首次人工运行后约30个会话零缺陷,三天完成,成本USD 2,430。

核心判断

规格先行协议可使AI智能体在无测试预言机、无人工代码审查条件下完成大规模架构重构。证据来自一个717,725行单一生产库案例:31轮审计纠正201处缺陷,首次人工执行及随后约30个会话零缺陷观测。

关键要点

1. 旧假设失效:基于测试套件的评估要求目标行为已有预置预言机,目标行为尚不存在时此路不通;人工审查则因记不住数百文件的依赖图而失效,遥测显示审查时间上升最高91%而交付指标持平。 2. 方法与受控检查:14轮新会话审计把规格迭代对齐真实源码后冻结,原子化实现,再用17轮无变更记忆的新会话对比实现与冻结规格,避免审查者持有生成上下文带来的确认偏差,两阶段收敛标准均为连续两次零发现。 3. 决定性结果与行动:31轮审计纠正201处缺陷,首次人工执行后约30个会话零缺陷;对无法分解为独立可测单元的变更可采用此协议,对能用测试套件逐一验证的常规任务则无额外价值。

证据与结果

对象是单一生产TypeScript应用,717,725行,3,648个文件。任务是拆除UI面板生命周期不变量:面板关闭后流式生成继续存活,重开面板可无损重附同一流。无预置测试预言机。审计共31轮(14轮规格精化加17轮实现验证),首次人工执行前纠正201处缺陷,此后约30个会话零缺陷观测。变更覆盖189个文件(31个新文件),含提取阶段共288个文件,34,770行插入,16,422行删除。耗时三天,成本USD 2,430。原始会话日志逾1,500页,以法语公开,供外部一致性检验。

打开论文原文
它要解决什么
没有测试预言机、也没有人工代码审查时,AI智能体能否可靠地拆除一个大型生产库的核心架构不变量?这是本次重构面对的实际问题:变更横跨189个文件,人工无法完整审查,目标行为也没有预置测试可验证。
研究路径
机制分四步。第一步,智能体阅读源码并生成形式规格。第二步,14轮迭代:每轮用新会话对比规格与真实源码,发现差异就修订规格,直到零发现。第三步,冻结规格,原子化提交实现,靠编译与测试反馈循环修语法错误。第四步,17轮验证:每轮用不携带变更记忆的新会话对比实现与冻结规格——审查者没有生成上下文,确认偏差被消除;连续两次零发现即宣告收敛。
这对工程意味着什么
第一步行动:遇到跨数百文件且无测试预言机的架构变更,先把规格迭代对齐真实源码并冻结,再实现,再用无记忆新会话审计到连续两次零发现。要避免的捷径:跳过规格阶段、依赖事后人工审查——在超大规模变更中审查者无法持有完整依赖图,这条路会失效。
证据定位
31轮审计共纠正201处缺陷(14轮规格精化加17轮实现验证)。首次人工执行后,约30个后续会话零缺陷观测。变更涉及189个文件(31个新文件),含提取阶段共288个文件,插入34,770行,删除16,422行。全部工作三天完成,成本USD 2,430。原始会话日志逾1,500页,以法语公开,可供外部检验一致性。(筛选维度:形式化验证)
适用边界
这是单案例研究:任务由作者自选且以高难度为标准,不构成代表性抽样;代码库、语言(TypeScript)和任务类型都单一;协议成本USD 2,430,且只适用于变更无法分解为独立可测单元的场景,这些都限制跨场景推论。
方法与英文摘要

协议分五步。第一步,智能体读源码并生成形式规格。第二步,14轮新会话审计:每轮开一个新会话对比规格与真实源码,发现差异就修订规格,直到零发现。第三步,冻结规格,原子化提交实现,用编译和测试反馈循环修语法错误。第四步,17轮验证:每轮用不带变更记忆的新会话对比实现与冻结规格,消除确认偏差。第五步,收敛判据:连续两轮验证零发现即宣告完成。

This paper reports a single, fully instrumented case study of a large-scale architectural refactoring by an AI coding agent under a specification-first protocol, with no human review of the generated code and no pre-existing oracle to validate the target behaviour. The task, dismantling a central invariant across a large interdependent codebase, was assessed by the author as effectively infeasible through incremental refactoring, the kind of change that conventionally calls for a rewrite instead. Under the protocol described here, the agent completed it successfully. The system is a 717,725-line production TypeScript application across 3,648 files. The task required dismantling a core lifetime invariant: the guarantee that a UI panel remains open for the duration of an AI request. The target behaviour was that a streaming generation survives the closing of its panel and can be reattached, on reopening, to the same live stream with no loss or duplication. The protocol: formal specification by the agent, 14 refinement cycles auditing that specification against the source code, atomic implementation, a compile/test feedback loop, then 17 verification cycles auditing the code against the frozen specification. Across 31 audit passes, 201 defects were corrected before any human executed the program. The convergence criterion was empirical: two consecutive verification passes returning zero findings. The change touched 189 files (31 new); with the extraction phase, the two commits total 288 files, 34,770 insertions, 16,422 deletions. Across the first and roughly thirty later sessions, the software behaved as specified, no bug observed. Elapsed: three days; cost: USD 2,430. The full specification and raw session logs, 1,500+ pages in French, are published as evidence, allowing inspection of the process and submission to a language model for consistency checking.

UI 与 GUI Agent(0 篇)

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

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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

本轮分类概览

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

赛道新增候选重点
形式化与程序验证01
软件工程与仓库智能02
代码质量与优化01
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 次监测窗口

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

本轮新增候选(0 篇)

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

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

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

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

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

代码质量与优化(0 篇)

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

UI 与 GUI Agent(0 篇)

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

个人知识与本体(0 篇)

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

人机协同与对齐(0 篇)

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