arXiv 每日速递 2026-06-11

今日总结

今天是"评估方法论"的大日子，四篇论文从四个完全不同的角度敲打同一个钉子：你的测量方式决定了你的结论，而大多数人的测量方式有问题。一篇用数据分析任务实测发现人类专家在 variance 和 error magnitude 上全面优于 frontier LLM；一篇证明在入侵检测里 padding 约定对 Transformer 性能的影响比架构选择本身还大；一篇把 property-based testing 系统化地搬进大数据框架，用语义不变量替代浅层 crash oracle；还有一篇造了 6 万个"不存在的概念"来测模型敢不敢说"我不知道"。如果你关心 benchmark 设计和 evaluation rigor（我们的主线之一），今天每一篇都值得精读。

今日全览

论文	方向	核心贡献	与我们的相关度
Flaws in the LLM Automation Narrative	LLM evaluation	用数据分析编码任务实测 LLM vs 人类专家，证明 variance 和 error magnitude 是被忽视的关键维度	⭐⭐⭐
Operationalizing Property-Based Testing for DISC Systems	SE / testing	8 个可复用 meta-property 把 PBT 落地到 Spark，发现 fuzzing 抓不到的语义漂移	⭐⭐⭐
Do Transformers Actually Help Intrusion Detection?	evaluation methodology	实证证明 padding 约定和 split 协议对结果的影响超过架构选择	⭐⭐
PhantomBench	benchmark / hallucination	6 万个程序化构造的"不存在概念"，frontier 模型 hallucination 率最高 86.7%	⭐⭐

今日主题：当测量本身成为研究对象

今天四篇论文有一条非常清晰的暗线：它们测的都不是"系统好不好"，而是"我们现在测系统的方式靠不靠谱"。

Perrett 等人那篇（Flaws in the LLM Automation Narrative）直接挑战 "LLM 已达人类专家水平" 的叙事——他们指出主流 benchmark 只报 average performance，从不报 variance 和 error magnitude，而在高风险场景里恰恰是后两者决定能不能用。Moczkodan 和 Ragab 那篇入侵检测论文用一个更具体的案例佐证了同一观点：同一个 Transformer，换一种 padding 约定，macro-F1 掉 0.24；换成 leakage-free split，false alarm rate 暴涨 67 倍——这些差异全都"invisible under conventional protocols"。这两篇放在一起读，几乎就是我们"agent 边际价值量化"哲学的两个新案例：当你把测量做严格，很多被吹起来的结论会缩水甚至翻转。

另外两篇则是在"造更好的 oracle"。DiscPBT 的出发点是 fuzzing 的 crash oracle 太浅，抓不到 semantic drift，于是把领域知识编码成 8 个可复用的 meta-property；PhantomBench 的出发点是现有 hallucination 评估都在"存在的知识"上打转，于是用频率过滤造出保证不存在的概念，把"敢不敢 abstain"变成可以规模化测量的指标。两者方法论同构：与其依赖 ground truth 标注，不如构造一个"按构造方式即正确"（correct-by-construction）的测试信号。这个思路对我们做 benchmark 的人来说太熟悉了——也太值得偷了。

---

Flaws in the LLM Automation Narrative

推荐理由：这篇几乎就是为我们的 "benchmark 合理性 + 统计严谨性" 主线写的——它用一个无法被训练数据污染的真实数据分析任务，实测了 frontier LLM 和人类专家在 variance 与 error magnitude 上的差距。

📌 论文信息：George Perrett, Javae Elliott, Jennifer Hill, Marc Scott | arXiv:2606.11166 | stat.OT, cs.AI

TL;DR

用一个需要写代码完成的真实数据分析任务对比 frontier LLM（ChatGPT Codex 5.2）与人类专家：人类不仅平均更好，而且方差显著更小——LLM 的问题不是"平均水平不够"，而是"偶尔会错得离谱"。

问题是什么？

"LLM 已达到人类专家水平"的说法满天飞，但支撑它的 benchmark 有两个系统性缺陷。第一，很多 benchmark 的内容直接出现在训练数据里，测的是记忆不是能力。第二，也是这篇论文真正的刀刃：几乎所有 benchmark 只报平均性能，不报可靠性（variance）和错误幅度（error magnitude）。打个比方：一个平均打 85 分但偶尔打 20 分的系统，和一个稳定打 80 分的系统，在 average-only 的 leaderboard 上前者赢，但在任何高风险场景（医疗、金融、生产代码）里你只敢用后者。现有评估范式根本看不见这个区别。

他们怎么做的？

核心 Insight：把评估从"对不对"升级成"错的时候错多少、多稳定地对"——用统计学的 RMSE、standardized bias 和 interval coverage 三件套替代单一准确率。

具体做法：

1. 设计一个新的 benchmark 任务：写代码完成一个真实数据分析问题（因果推断类），任务本身不在训练数据里，杜绝 contamination
2. 收集人类专家提交和多次独立的 LLM（ChatGPT Codex 5.2）提交——注意是多次采样，这是能测 variance 的前提
3. 在三个维度上对比：RMSE（误差大小）、standardized bias（系统性偏差）、coverage（不确定性区间的校准），外加一个 historical strawman 作为下限锚点

跟之前方法的本质区别：传统 LLM benchmark 是"一次提交、一个分数、排个名"；这里是"多次提交、看分布、测尾部"。方法上没有任何花哨的东西，但问的问题完全不同——前者问 can it do well，后者问 can you rely on it。

关键结果

维度	人类专家	ChatGPT Codex 5.2	解读
RMSE 平均水平	更低（更好）	更高	平均性能人类占优
表现方差	小	大，含 5 个极端离群提交	LLM 可靠性显著更差
极端错误	基本没有	出现 RMSE 极端值，需在图中单独截断展示	尾部风险是 LLM 独有的

结果解读：最有信息量的不是"人类平均更好"（这个结论本身会随模型迭代过时），而是 Figure 1 右侧面板那个细节——有 5 个 LLM 提交错得太离谱，以至于画图时不得不把它们截掉才能看清其余分布。人类专家提交里没有这种尾部。这说明 LLM 的失败模式是重尾的：大多数时候像个合格分析师，少数时候产出灾难性结果且自己毫无察觉。对于"自动化高风险知识工作"的叙事，重尾比均值低更致命。

局限性与开放问题

• 单模型单任务：只测了一个 frontier LLM 和一个数据分析任务，结论的外推性存疑——换 Claude 或换成 SE 任务，尾部行为是否同样重尾？论文没有回答
• 人类基线的选择偏差：愿意提交的"人类专家"本身经过自我筛选，可能高估了人类平均水平；LLM 是无条件多次采样，两边的采样机制不对称
• 开放问题：variance 能不能被工程手段压掉？比如 self-consistency、多次采样取中位数、或 agent 自检——如果 5 次采样投票就能消除尾部，这篇论文的实践含义会大幅减弱。这恰恰是一个值得马上做的后续实验

💡 对我们的启发

1. 直接可用的技术点：我们做 agent trace 事后分析时，一直以 pass@1 / resolve rate 这类均值指标为主。这篇论文提示应该把 per-instance variance 和 failure magnitude 加入分析维度——SWE-bench 的公开 trace 里同一 instance 往往有多个 agent 的多次尝试，完全可以测"同一题不同 run 的结果方差"，这是现成数据、零额外成本的分析角度
2. 具体实验想法（1-2 周可验证）：取 SWE-bench Verified 上某个公开 agent 的多 seed 运行结果（或自己用小模型跑 5 seeds），按 instance 统计 resolve 的方差，回答一个问题：leaderboard 上相差 3pp 的两个 agent，它们的差距是否小于单个 agent 自身的 run-to-run 方差？ 如果是，整个 leaderboard 排序的统计意义都要打问号——这是一篇典型的"我们风格"的论文
3. 研究趋势判断：评估界正在从 "average-only" 转向 "distribution-aware"。我们已有的 McNemar / TOST 工具箱在这个浪潮里是先发优势，应该尽快把 variance-aware evaluation 做成方法论论文占住位置

---

Operationalizing Property-Based Testing for Data-Intensive Scalable Computing Systems

推荐理由：正统 cs.SE 论文，把 property-based testing 系统化落地到 Apache Spark。它的 meta-property 设计哲学（用语义不变量替代具体期望输出）可以直接迁移到我们的 HomeCheck 规则验证和兼容性修复的 patch 正确性校验上。

📌 论文信息：Yaoxuan Wu, Ingrid Lee, Ahmad Humayun, Muhammad Ali Gulzar, Miryung Kim | arXiv:2606.11132 | cs.SE

（arXiv HTML 版的图为内嵌渲染，无可直接引用的图片 URL，本篇暂无配图）

TL;DR

DiscPBT 为 Apache Spark 定义了 8 个可复用的 meta-property（等价重写、数据分解、计算分解、算子局部语义关系），并提供自动实例化框架把它们变成可执行测试——发现了 crash-based fuzzing 完全抓不到的跨版本语义漂移和 NaN/空输入边角 bug。

问题是什么？

大数据框架（Spark 这类 DISC 系统）的测试有个根本困境：fuzzing 能抓 crash，但最危险的 bug 不 crash——查询优化器把你的查询改写错了，结果悄悄少了几行数据，程序正常退出，没人知道。这类 semantic drift 需要语义 oracle，而语义 oracle 的经典答案是 property-based testing（PBT）。但 PBT 在 DISC 系统上一直停留在"纸上谈兵"：你需要既定义出可复用的 property，又能把它们自动实例化成 schema 合法、算子兼容的真实 workload——后者是真正的工程深水区，之前没人系统做过。

他们怎么做的？

核心 Insight：把"领域语义知识"压缩成 8 个 meta-property（属性模板），再用生成器框架解决"模板→合法可执行测试"的自动实例化问题——属性定义一次，实例化无限次。

具体流程：

1. 定义 8 个 meta-property，覆盖四类语义不变量：等价重写（同一查询的两种写法结果必须一致）、数据分解（对分片数据分别计算再合并 = 对全量计算）、计算分解、算子局部语义关系。这些是 DISC 系统的"物理定律"，不依赖任何具体期望输出
2. 生成 workload skeleton：用 TreeGen / SingleSinkDAG 生成带预留插入点的查询骨架，再物化出 schema 兼容的输入数据
3. 绑定实例化：在插入点把 meta-property 的占位符绑定为兼容的算子、表达式和 UDF，生成只在局部重写点不同、其余上下文完全相同的成对 workload，对比执行结果

跟之前方法的本质区别：CometFuzz 这类 fuzzer 问"这个输入会不会让系统崩"；DiscPBT 问"这两个语义等价的程序输出是否一致"。前者的 oracle 是免费的（crash 自己会暴露），后者的 oracle 是构造出来的——成本高一个数量级，但能看见 fuzzing 的盲区。

关键结果

指标	DiscPBT	CometFuzz（baseline）	提升
Branch coverage	1.2×	1×	+20%
Query plan diversity	1153×	1×	三个数量级
发现的 bug 类型	跨版本 semantic drift、NaN/空输入语义错误	crash 类	互补而非替代

结果解读：branch coverage 只高 20%，但 plan diversity 高 1153 倍——这个组合很说明问题：代码覆盖率不是语义覆盖率。两个工具走过的代码行差不多，但 DiscPBT 探索的查询计划空间完全不在一个量级，而优化器 bug 恰恰藏在 plan 空间里。这也是对"以 coverage 论英雄"的测试评估传统的一次实证打脸。66 个具体 property 抓到的跨版本语义漂移（同一查询在不同 Spark 版本结果不同）尤其有价值——这正是 crash oracle 在原理上不可能发现的。

局限性与开放问题

• 平台绑定：8 个 meta-property 是对 Spark/DataFrame 语义量身定制的，迁移到其他系统（Flink、Ray、甚至单机 pandas）需要重新做领域分析，"可复用"目前只在 PySpark 生态内成立
• 误报处理语焉不详：浮点聚合在分布式环境下天然不满足严格结合律，等价重写类 property 必然产生需要容差判定的灰区，论文对 tolerance 的设定原则讨论不够
• 开放问题：meta-property 的提炼目前靠专家手工——能否让 LLM 从 API 文档和语义规范里自动提炼候选 property，再用执行反馈过滤？这是 PBT 规模化的下一步，也是 LLM × SE 的天然结合点

💡 对我们的启发

1. 直接可用的技术点：我们的 whole-repository compatibility repair 一直缺一个好的 patch 正确性 oracle——测试套件往往不够。DiscPBT 的"等价重写"思路可以直接搬：升级前后的 API 调用对在相同输入下应当产生等价输出，这本身就是一个 metamorphic property。对 Python 版本演化修复，可以自动生成"旧 API 调用 vs 修复后新 API 调用"的成对执行对比，作为测试套件之外的第二层校验
2. 具体实验想法（1-2 周可验证）：从我们的兼容性修复数据集中抽 50 个已确认正确的 patch 和 50 个已知错误的 patch，对每个 patch 构造"新旧调用等价性"差分执行检查，测这个 oracle 的 precision/recall。预期：等价性 oracle 能以接近零误报的代价抓出 30-50% 的错误 patch——如果成立，这就是修复 pipeline 里一个免费的质量门
3. 研究趋势判断：测试研究正在从"输入生成"（fuzzing 卷了十年）转向"oracle 构造"。对 OpenHarmony 工具链来说，ArkTS/ArkUI 的语义不变量（渲染幂等性、状态-UI 一致性）还没人系统整理过——做一套 ArkUI 版 meta-property，既是论文也是 HomeCheck 的新检查器来源

---

Do Transformers Actually Help Intrusion Detection? A Temporal Sequence Evaluation on CIC-IDS2017

推荐理由：应用领域是入侵检测，但这是一篇假面的 evaluation methodology 论文——"padding 约定比架构选择对结果影响更大"的实证结论，和我们"量化每个设计动作真实边际价值"的研究哲学完全同频。

📌 论文信息：Zach Moczkodan, Hany Ragab | arXiv:2606.11098 | cs.CR, cs.LG

TL;DR

把 CIC-IDS2017 重构成真正的时序检测任务后系统对比 9 种模型：Transformer 的性能由 padding 约定决定而不是由架构决定（同一模型 ±0.24 macro-F1），且 leakage-free split 下 Random Forest 才是最稳的——大量"Transformer 提升入侵检测"的已发表结论可能是评估协议的产物。

问题是什么？

入侵检测文献里有一波"上 Transformer，刷出近乎完美指标"的论文。但作者发现两个普遍的方法论漏洞：很多工作号称用了时序架构，却根本没有喂真正的序列输入；评估几乎都用 random split，同一会话的流量被切进训练集和测试集——典型的数据泄漏。于是真正的问题变成：剥掉这两层评估的水分之后，时序架构到底还剩多少真实优势？这个问题的形态对任何领域都成立：把 "Transformer" 换成 "agent"，把 "padding" 换成 "scaffold 设计"，就是我们天天在问的问题。

他们怎么做的？

核心 Insight：不提任何新方法，而是把"评估协议本身"作为实验变量——固定模型，系统地翻转 split 策略和 padding 方案，测量每个协议选择对结论的影响量。

具体做法：

1. 把 CIC-IDS2017 从单流分类重构为基于 conversation 的有序流序列任务，让时序模块第一次拿到真正的序列输入
2. 在 9 种经典与深度模型上跑三种 split（random、两种 leakage-free）做交叉对照
3. 做 padding 方案 ablation：non-padded 真实序列 vs zero-pad+mask vs repeat-last padding，分离"架构能力"和"协议假象"

跟之前方法的本质区别：之前的工作是"提出新架构 → 在宽松协议下报一个高分"；这篇是"固定所有架构 → 量化协议每个自由度的影响"。结论的单位不是"我的方法好 X%"，而是"你的协议选择值 X%"——后者对整个子领域的可信度有矫正作用。

关键结果

实验条件	模型	macro-F1 / 指标	说明
真实序列（non-padded）	Transformer	0.89（全场最高）	架构确实有潜力
zero-pad + mask	Transformer	下降 0.24	协议选择 > 架构差异
zero-pad + mask	LSTM / GRU / 1D-CNN	基本稳定	脆弱性是 Transformer 特有的
leakage-free group split	Random Forest	最稳健（+0.009）	经典方法赢了鲁棒性
random → leakage-free	Transformer false alarm rate	0.04% → 2.7%（67×）	常规协议下完全不可见

结果解读：最锋利的数字是那个 67 倍的 false alarm 暴涨——在 random split 下 Transformer 看起来近乎完美（FAR 0.04%），换成无泄漏的 group split 后 FAR 飙到 2.7%，而这个量级的恶化在传统评估协议下根本测不出来。同时 0.24 的 padding 效应意味着：文献里不同论文之间的"架构对比"，如果 padding 约定不一致，对比根本不成立。作者的处方很朴素：leakage-free split、显式披露 padding 方案、sequence-aware 评估——朴素，但整个子领域都没做到。

局限性与开放问题

• 单数据集：所有结论建立在 CIC-IDS2017 一个数据集上，而这个数据集本身的标注质量早有争议（已有专门论文修订其标签），协议效应的量级在其他数据集上可能不同
• Transformer 调参充分性：Transformer 对 padding 的异常敏感也可能部分源于训练配置（位置编码方式、mask 实现细节），论文没有完全排除"实现问题"与"架构固有缺陷"的混淆
• 开放问题：协议敏感度能否成为模型选型的一等指标？一个在协议扰动下波动 ±0.24 的模型和一个波动 ±0.01 的模型，部署时该选谁——这其实又回到了第一篇论文的 variance 命题

💡 对我们的启发

1. 直接可用的技术点：我们做 agent trace 事后分析时也面临"协议自由度"问题——trace 截断方式、context window 对齐、instance 排序都可能影响结论。这篇论文的"固定系统、翻转协议、量化每个自由度的影响"实验设计可以直接套用：在我们下一篇 marginal value 论文里加一节 protocol sensitivity analysis，会显著加强审稿防御力
2. 具体实验想法（1 周可验证）：取我们已有的 tangled patch splitting 评估数据，翻转两个协议自由度（patch 内 hunk 排序方式 × 评估时的 ground truth 对齐策略），构造 2×2 协议矩阵重算指标。预期：如果指标波动超过方法间差异的一半，就说明该 benchmark 的协议需要先标准化——这本身就是一个 workshop 论文级别的发现
3. 研究趋势判断："评估协议作为研究对象"正在各个应用领域独立兴起（今天这篇在 IDS，之前 SWE-bench 社区在 contamination）。SE 领域 agent 评估的协议自由度（重试次数、环境镜像、测试超时）还没人系统量化过——这是我们 benchmark methodology 主线上一个空着的坑

---

PhantomBench: Benchmarking the Non-existential Threat of Language Models

推荐理由：用"保证不存在的概念"测模型的 abstention 能力，构造 pipeline 完全自动化——这套方法可以直接迁移成"不存在的 API" benchmark，用于量化低资源语言（ArkTS / Cangjie）代码生成中的 API hallucination。

📌 论文信息：Haeji Jung, Hila Gonen | arXiv:2606.11105 | cs.CL, cs.AI

TL;DR

6 万个程序化构造、经语料频率过滤保证不存在的术语和实体，测 21 个模型敢不敢说"这东西不存在"——结果是普遍不敢：部分设置下平均 hallucination 率高达 86.7%，frontier 模型也一样，尤其当 prompt 预设了概念存在时。

问题是什么？

Hallucination 研究有个测量学死角：要测模型"知道自己不知道"，你需要确定无疑不在训练数据里的查询对象。用真实但罕见的概念做不到这一点（你无法证明模型没见过），人工编造又无法规模化。所以现有评估大多绕开了这个最尖锐的设置，转而测"对已知事实的忠实度"。PhantomBench 的目标就是把"对不存在之物的反应"变成可以 60K 规模自动化测量的东西——本质上是给 abstention 能力造一个 correct-by-construction 的 ground truth。

他们怎么做的？

核心 Insight：不存在性无法标注但可以构造——把真实概念拆成组件再重组，然后用大语料频率过滤，零匹配即不存在。ground truth 来自构造过程本身，不需要任何人工标注。

具体流程：

1. 从种子术语和实体出发，分解为词与 n-gram 组件，重组生成大量候选新概念（保持表面合理性，使其"看起来像真的"）
2. 频率过滤：在大语料中检索每个候选，丢弃所有有匹配的，剩下的就是保证不存在的概念——这一步是整个 benchmark 可信度的来源
3. 用多种 prompt 模板查询概念的不同属性，特别设计了"预设存在"的措辞（如"请解释 X 的原理"），测模型在语用压力下的表现
4. 在 21 个不同类型和规模的模型上评估，并提供完整构造 pipeline 供研究者按需定制自己的 phantom 概念集

跟之前方法的本质区别：TruthfulQA 等已有 benchmark 测"已知事实上的忠实度"，依赖人工标注且会随训练数据更新而失效；PhantomBench 的 ground truth 由构造方式保证，可无限再生成（防止 benchmark 本身泄漏进训练数据）——benchmark 污染问题在这里被设计层面解决了。

关键结果

设置	结果	说明
规模	60K+ 不存在的术语和实体	全自动构造 + 频率过滤
覆盖	21 个模型（含 frontier）	各类型、各规模
平均 hallucination 率	部分设置高达 86.7%	普遍性失败，不是个别模型的问题
预设存在的 prompt	显著更高的 hallucination 率	语用压力压倒知识边界意识

结果解读：86.7% 这个数字的可怕之处在于它的普遍性——frontier 模型并没有比小模型好到哪里去。更有信息量的是 prompt 措辞效应：同一个不存在的概念，中性询问时模型还有机会 abstain，一旦 prompt 预设其存在（"解释 X 的原理"），模型几乎总是顺着编。这说明 hallucination 在很大程度上是语用服从问题而不是知识检索问题：模型把"配合用户的预设"放在了"忠于知识边界"之前。作者还验证了 PhantomBench 可以作为"罕见真实概念"行为的代理——在不存在概念上的表现预测了模型在长尾知识上的可靠性。

局限性与开放问题

• 频率过滤的不完备性：过滤语料再大也不等于训练语料，"零匹配"是不存在的必要非充分证据；且组合而成的概念可能与某个真实概念语义等价（换了说法的同一事物），此时模型"编造"的解释其实部分正确
• abstention 的判定：什么算合格的 abstain（明确否认存在 vs 表达不确定 vs 反问澄清）存在灰区，论文虽然做了细粒度 abstention 分类，但类别边界的判定依赖自动分类器，本身有误差
• 开放问题：在 instruction tuning 阶段注入 phantom 负样本能不能教会模型 abstain，且不损伤对真实罕见概念的 recall？这是从测量走向干预的下一步

💡 对我们的启发

1. 直接可用的技术点：这套构造方法几乎可以一比一搬到代码领域——Phantom API benchmark。用 ArkTS / Cangjie 的真实 API 名拆解重组（getContext + ApplicationInfo → getApplicationInfoContext），再对官方 SDK 全量符号表做"频率过滤"（零匹配即不存在），就得到保证不存在但形态逼真的 API 集合。低资源语言的 API hallucination 是我们 Cangjie continued pretraining 工作里实际观察到的痛点，但一直没有量化工具
2. 具体实验想法（2 周可验证）：构造 500 个 phantom ArkTS API，设计两组 prompt（中性："这个 API 存在吗" vs 预设存在："用这个 API 写个例子"），测 DeepSeek-Coder / Qwen-Coder 7B-14B 的 hallucination 率，并对照我们 decoding 干预（prefix-matching constrained decoding）开关前后的变化。预期：constrained decoding 能把 phantom API 的生成率压到接近零——这直接给我们的 decoding 干预方法提供了一个新的 evaluation 维度和卖点
3. 研究趋势判断："correct-by-construction 的 benchmark"是对抗训练数据污染的根本解法（今天 DiscPBT 的 meta-property 是同一思想在测试领域的投影）。对低资源语言生态，这类自动构造 + 可再生成的评估资产尤其稀缺——先做出来的人定义标准

---

方法对比

今天四篇本质上都在回答"如何获得可信的测量信号"，但路径各异：

维度	LLM Automation Narrative	DiscPBT	Temporal IDS Bench	PhantomBench
测量对象	LLM vs 人类的可靠性差距	DISC 系统语义正确性	评估协议自身的影响量	模型的知识边界意识
Oracle 来源	统计三件套（RMSE/bias/coverage）+ 多次采样	correct-by-construction 的语义不变量	协议变量的受控翻转	correct-by-construction 的不存在性
数据需求	人类专家提交（贵、难规模化）	自动生成 workload（便宜）	已有数据集重构（便宜）	全自动构造（便宜、可再生成）
关键发现	LLM 失败模式重尾	coverage ≠ 语义覆盖（plan diversity 差 1153×）	协议效应（0.24）> 架构效应	hallucination 是语用服从问题
主要局限	单模型单任务	meta-property 绑定 Spark 语义	单数据集	频率过滤非充分证据
对我们的迁移点	agent 评估加 variance 维度	兼容性修复的等价性 oracle	marginal value 论文加协议敏感性分析	Phantom API benchmark for ArkTS/Cangjie

四篇连起来看，"evaluation as a first-class research object" 已经不是一个口号而是一个正在各领域同时落地的研究纲领——而这正是我们已经站着的位置。

---

本文由 AI 辅助生成，论文解读基于 arXiv 公开摘要与原文图表，深入了解请阅读原论文。