arXiv 每日速递 2026-05-01

今日总结

今天的 arXiv 难得地"一题多面"——四篇论文从不同角度直击同一个问题：AI 在 SE 流程里到底值多少。Hot Fixing in the Wild 用 6.1 万仓库的真实数据告诉你 AI agent 修紧急 bug 时和人到底差在哪；ClassEval-Pro 把前沿模型放到 class 级合成上，发现最强者也只能 Pass@1 45.6%，整整 17.7 pp 的模型间差距说明 benchmark 还在洗牌；Select to Think 揭示一个反直觉事实——1.5B 小模型的 top-8 候选里有 95% 概率藏着 32B 大模型的最终答案；最后是一篇 SE 立场论文，警告 AI 依赖正在悄悄掏空工程师的"根因分析肌肉"。如果你像我一样在做 agent 边际价值量化或小模型代码生成，今天值得花一小时通读。

今日全览

论文	方向	核心贡献	与我们的相关度
Hot Fixing in the Wild	empirical SE / AI agent	6.1 万仓库 hot fix 行为画像，量化 human vs AI agent 修复行为 10+ 项差异	⭐⭐⭐
ClassEval-Pro	code benchmark	300 个 class 级任务跨 11 领域，真实 GitHub 代码 + LLM Judge Ensemble，前沿模型最高 45.6%	⭐⭐⭐
Select to Think (S2T)	SLM reasoning	1.5B SLM 的 top-8 命中 32B LLM 选择 95%，蒸馏选择逻辑后无需 LLM 调用	⭐⭐⭐
Cognitive Atrophy in AI-Dependent SE	position / SE socio-tech	"Epistemological Debt" 概念 + 2026 Amazon 宕机案例，警示 AI 依赖侵蚀工程能力	⭐⭐

今日主题：AI for SE 的"边际价值"——三种实证路径与一个反思

如果你在做 AI 编码 agent 评估，今天的四篇论文几乎构成了一个完整的方法论谱系。

第一条路径是事后 trace 分析——Hot Fixing in the Wild 不重跑实验，直接挖 6.1 万仓库的 commit history，从 hot fix 这个特定子任务切入，看 AI agent 和 human 行为差在哪。这种"现象实证"风格正是我自己最近在做的事情，比起端到端跑 SWE-bench 便宜 100 倍且更接近真实生态。

第二条路径是benchmark 重建——ClassEval-Pro 抓住一个被忽视的中间地带（function 级和 repo 级之间的 class 级合成），用三阶段自动 pipeline（complexity enhancement + cross-domain composition + post-2025 GitHub）+ LLM Judge Ensemble 解决数据污染和扩展性问题。它的 45.6% 上限和 17.7 pp 模型间差距，正好说明这个粒度还没饱和，是 partition / ordering metrics 大有可为的地方。

第三条路径是机理拆解——Select to Think 不假设小模型必须模仿大模型分布，而是观察到一个简单事实：在推理分歧点，SLM 的 top-K 候选里 95% 时候藏着 LLM 的最终选择。这把"模仿生成"问题降维成"候选排序"问题，也意味着我们做 small-LLM code generation 时，过去过度悲观了——差距没那么大，大模型的价值更多在"选对"而不是"想到"。

第四篇是反思：Cognitive Atrophy 提出 "Epistemological Debt"——工程师把 logical derivation 外包给 AI 验证，正在丢掉根因分析能力。它没有 benchmark，但提出了一个值得做实证的假设——这正好是我们 marginal value 路线天然能接的研究问题。

把这四篇放在一起，你会发现 AI for SE 的研究正在从"做出来"过渡到"算清楚"：算 agent 真正贡献多少，算小模型能省多少，算人类能力被替换了多少。这正是我赌的方向。

---

Hot Fixing in the Wild

推荐理由：直接命中"agent 边际价值实证"主线。6.1 万仓库的事后 trace 分析，没有重跑 SWE-bench，方法论可以直接复用到我们的 agent partition / ordering metrics 工作

📌 论文信息：Carol Hanna, Karine Even-Mendoza, W. B. Langdon, Mar Zamorano López, Justyna Petke (UCL) | arXiv:2604.26892 | cs.SE

TL;DR

基于 Hao-Li/AIDev 数据集的 61,000+ 仓库，第一篇用 repository 级 urgency 操作化定义 hot fix 的大规模实证；同时拆出 human-authored 和 AI-agent-authored 两类 hot fix，发现至少 10 种行为模式差异。

问题是什么？

Hot fix（紧急修复）是工业界最敏感的代码改动场景：生产系统挂了，时间紧、责任重、改错代价高。但学界对它的认识基本停留在小样本访谈或个案分析层面。更关键的是，AI coding agent（Devin、SWE-agent 等）已经开始在生产环境里被用来打 hot fix，可没人系统地比较过 agent 和 human 在"被赶时间"这个特殊压力下行为到底有什么不同——是 agent 同样快、同样保守，还是会出现一些值得警惕的偏离？过去这种问题做不动，是因为没有规模化的数据集和"urgency"的可操作定义。

他们怎么做的？

核心 Insight：把"urgency"翻译成 repository 级别的可观测信号——commit message 关键词、reviewer 数量骤降、test 文件改动稀少、改动行数小但分散——然后在 Hao-Li/AIDev 这个已经标注了 AI-agent contribution 的大规模数据集上做组间对比。

具体方法流程：

1. 用关键词 + commit metadata 启发式从 6.1 万仓库里抽出 hot fix commit，验证其 urgency signature（中位数 2-3 commits / 2-3 files / <10 line changes）
2. 把 hot fix 拆成 human-authored vs AI-agent-authored 两组，按 commit author / co-author 标识划分
3. 在多维度上（协作模式、变更范围、review 强度、test 修改频率、修复行为类型）做对比，归纳出 10+ 种行为差异

跟之前方法的本质区别：以往 hot fix 研究要么是访谈（n<100），要么是单仓库案例，没有 urgency 的可观测定义；这篇用 repository-level signature 让 urgency 第一次变成 scalable 的过滤器。

关键结果

维度	Hot Fix	Regular Bug Fix	解读
协作人数中位数	1	>1	紧急时单人独干
commits / files 中位数	2-3 / 2-3	更高	改动小而精
改动行数中位数	<10 行	显著更高	外科手术式修复
reviewer 数量	常 <2	更多	review 被压缩
修改 test 文件比例	显著更低	更高	"先救火再补 test"

结果解读：

• urgency signature 在统计上非常显著、几乎跨所有仓库类型一致——说明这是个真实的 universal pattern，而不是某些公司的内部流程
• 关键发现是 test 修改频率显著更低——这暗示 hot fix 留下的技术债很难通过 regression test 自然回归，是个值得跟进的 follow-up 方向
• AI agent 和 human 在 hot fix 里的 10+ 项行为差异里，很多和 agent 习惯性引入更广泛改动、更愿意调 dependency 有关——这意味着 agent 在紧急场景下的 "blast radius" 控制能力差于 human

局限性与开放问题

• 局限 1：urgency 完全靠 keyword + metadata 启发式定义，没有 ground truth 验证。可能漏掉那些没在 commit message 里写"hotfix/urgent"的真紧急修复，也可能误收录命名 emoji 党的普通改动
• 局限 2：human vs AI agent 的归属判定依赖 AIDev 数据集已有的标注，而 AIDev 本身的 author 标注可能存在 ghost-write 误差（人类用 AI 辅助但不署名 / agent 跑完 human 收尾）
• 开放问题：这篇只描述行为差异，没有把"行为差异"和"修复质量"挂钩——AI agent 的 hot fix 是不是更容易 revert？是不是更容易引入 regression？这其实才是工业界最关心的"边际价值"问题

💡 对我们的启发

1. 直接可用的方法：urgency-as-repository-signature 这个操作化定义，可以直接搬到我们的"tangled commit detection"和"atomic commit"工作里。我们之前做 atomic commit reorganize 时一直缺一个客观的"上下文紧急度"信号——用类似 hot fix 的 metadata signature，可以把"这个 tangled commit 是赶工产物 vs 真应该一次性提交"区分出来
2. 具体实验想法：拿这篇的 hot fix 子集（约 6.1 万仓库的子集），交叉 run 我们的 atomic commit evaluator，看 hot fix 的 atomicity 分布和 regular bug fix 是否有显著差异。预期：hot fix 的 atomicity 显著差，且 AI agent hot fix 比 human 更差。这个实验 1 周内可以做完，结果如果成立就是个很好的 follow-up paper 切入点
3. 趋势判断：今年（2026）开始，"AI agent 在生产环境的真实行为审计"会变成新热点。SWE-bench 这种 controlled benchmark 的边际信息量在下降，"in-the-wild" 的 trace 分析会替代它。这条路对我们这种没有大量 commercial API budget 的研究者非常友好——数据全在 GitHub 上，方法靠 SQL 和静态分析

---

ClassEval-Pro: A Cross-Domain Benchmark for Class-Level Code Generation

推荐理由：和我们的 benchmark methodology 主线高度对齐——既是新基准，也展示了如何在 LLM Judge Ensemble + 真实 GitHub 数据下解决数据污染问题，方法论可以直接借鉴

📌 论文信息：Yeheng Chen, Chaoxiang Xie, Yuling Shi, Wenhao Zeng, Yongpan Wang | arXiv:2604.26923 | cs.SE, cs.CL

TL;DR

LLM 在 function 级 (HumanEval) 和 repo 级 (SWE-bench) 都很强，但介于两者之间的 class 级合成——给一个 spec 写一整个内部结构完整的 class——一直没被认真评估过。ClassEval-Pro 用 300 个跨 11 领域的任务、自动化三阶段构造 pipeline + LLM Judge Ensemble + >90% 行覆盖测试，把这个空白填上了。最强前沿模型 Pass@1 只有 45.6%，最强弱模型差 17.7 pp，证明这个粒度还远未饱和。

问题是什么？

现有 code generation benchmark 有两个老问题：（1）function 级太碎，HumanEval 早被刷穿，对前沿模型没区分度；（2）class 级或 repo 级数据要么人工 curate 太贵，要么直接从 GitHub 抓——后者的死结是数据污染：模型预训练里很可能见过原 repo。class 级是工程实际中最常出现的粒度——你写一个 Order 类，里面 5-10 个方法互相调用，需要一致的状态管理和接口设计——但这个粒度的能力评估几乎是空白的。更糟的是，"compositional code creation"（多方法协调）一旦失败，错误模式和 function 级完全不同，之前的 metrics 抓不住。

他们怎么做的？

核心 Insight：要造一个抗污染、可扩展、能区分模型的 class 级 benchmark，必须同时解决三个矛盾——构造成本（automate）、污染风险（用 2025 年 1 月之后的 GitHub 代码）、质量保证（LLM Judge Ensemble 替代人工标注）。

具体方法流程：

1. Complexity enhancement：从已有 class-level seed 任务出发，用 LLM 系统性地增加方法间依赖、内部状态、跨方法约束
2. Cross-domain composition：把 11 个领域（金融、生物、Web 等）的真实 class 结构组合，避免模型在单一领域形成 shortcut
3. Real-world GitHub integration：所有任务包含 2025 年 1 月之后提交的代码（前沿模型预训练 cut-off 之后），降低污染概率
4. LLM Judge Ensemble + 测试：每个任务被 LLM 评审团交叉验证，并必须通过 >90% 行覆盖率的测试套件，过滤掉模糊或不可解任务

跟之前方法的本质区别：ClassEval（原版）依赖人工 curate，规模上不去；HumanEval-X 系列是 function 级；SWE-bench 是 repo 级 issue resolution，不是 from-scratch 合成。ClassEval-Pro 是第一个 automated + 防污染 + class 级 + cross-domain 四维都覆盖的 benchmark。

关键结果

配置	数值	含义
任务总数	300	跨 11 个领域
测试覆盖率门槛	>90% line coverage	严格过滤
最强前沿模型 Pass@1	45.6%	远未饱和
最强-最弱模型差距	17.7 pp	高区分度
Bottom-up 策略对弱模型提升	+9.4 pp	策略-能力强交互
Compositional 生成对弱模型 Pass@1	低至 1.3%	弱模型在协调任务上几乎崩盘

Error 分布（500 个手工标注的失败案例）：

• Logic errors: 56.2%
• Dependency errors: 38.0%
• 其余 5.8% 为语法 / 接口

结果解读：

• 45.6% Pass@1 这个数字本身就是论文最强的卖点——说明前沿模型在 class 级远未到 saturation，benchmark 不会一年就过期
• 17.7 pp 的模型间差距非常大（比 HumanEval 现在的 1-2 pp 区分度高一个数量级）说明这个粒度真的还在 useful region
• 错误分布的真正洞察是 dependency errors 占 38%——也就是说，class 内方法间的调用约束、状态依赖才是模型真正卡住的地方。这和我们做 program repair 时观察到的"LLM 改一个 method 容易，但不会处理跨 method 一致性"的现象完全吻合
• 弱模型用 bottom-up 策略涨 9.4 pp、用 compositional 反而崩到 1.3%——这是个非常强的交互效应，意味着 strategy choice 不是 model 无关的，应该和 model capability 联合 report

局限性与开放问题

• 局限 1：LLM Judge Ensemble 自身的可靠性没有用人工对比验证。Judge 之间的一致性 (Cohen κ) 没有 report，可能存在 Judge 集体偏向某种风格的代码
• 局限 2：post-2025-Jan GitHub 代码降低了污染但没消除——仓库级污染（模型见过 sister files）依然可能存在
• 开放问题：错误分类是手工标注的，能不能自动化？以及 cross-method coordination 这个核心 bottleneck 能不能用 static analysis 工具辅助 LLM 解决——这正是我们 program repair 工作的菜

💡 对我们的启发

1. 直接可用的技术点：他们的"complexity enhancement → cross-domain composition → post-cutoff GitHub → LLM Judge"四阶段 pipeline，可以直接搬到我们做的 OpenHarmony / ArkTS benchmark 上。ArkTS 是 2024 才大规模公开的语言，污染风险天然小，再叠加 post-cutoff GitHub filter 几乎可以零污染。我们之前做 HomeCheck 评估时受困于"哪些规则真有效 vs 哪些是 cherry-picked example"，用类似 cross-domain composition 可以系统化解决
2. 具体实验想法：把 ClassEval-Pro 的 300 个任务跑一遍 Qwen-Coder 7B / DeepSeek-Coder 6.7B，看小模型在哪个领域 / 哪个 dependency 类型上 collapse。如果 dependency error 在小模型上占比比 logic error 还高，说明小模型可以靠"static analysis 注入 dependency 信息"补刀——这就是我们的"职责切分"哲学的另一个落点。1-2 周内可以跑完，预期看到 dependency error 占比 >50%
3. 趋势判断：自动化构造 + 自动化裁判 + 防污染 三件套正在成为 code benchmark 的新标配。如果你今年要发 benchmark 论文，没有这三件套很难被接收——这是我们做 RepoRescue / 跨语言 benchmark 时必须考虑的设计约束

---

Select to Think: Unlocking SLM Potential with Local Sufficiency

推荐理由：直接命中"小模型代码能力 + 静态信号驱动"主线。1.5B SLM 的 top-8 命中 32B LLM 选择 95%——这个数字如果在 code 上成立，意味着我们整个 small-LLM-for-code 路线的天花板比想象高得多

📌 论文信息：Wenxuan Ye, Yangyang Zhang, Xueli An, Georg Carle, Yunpu Ma | arXiv:2604.26940 | cs.CL

TL;DR

SLM 不是"想不到"正确答案——它的 top-K next-token 候选里 95% 时候藏着 32B LLM 的选择，问题是它"top-1 选错了"。S2T 把 LLM 角色从"open-ended generation"降级为"在 SLM 候选里选"，再把这个选择逻辑蒸馏回 SLM，得到 S2T-LOCAL：纯单轨 greedy 解码就涨 24.1%，已经可以和 8-path self-consistency 持平，但只用 1/8 算力。

问题是什么？

小模型的推理差距长期以来被默认是"能力差距"——SLM 想不到 LLM 能想到的东西。现有的两条解决路径都不令人满意：（1）推理时调大模型 generate（latency 高 + cost 高），（2）标准蒸馏让 SLM 模仿 LLM 完整分布——但 SLM 容量有限，根本学不会 LLM 复杂分布。这两条路一个是"用大模型替代 SLM"，一个是"想让 SLM 变成 LLM"。本质问题没解决：SLM 到底缺的是"想到"还是"选对"？

他们怎么做的？

核心 Insight：在推理分歧点（divergence point，下一 token 概率分布熵高的位置）观察 SLM 的 top-K 候选——LLM 的最终选择 95% 时候就在 SLM 的 top-8 里。也就是说，SLM 不缺生成能力，缺的是 ranking 能力。把"生成"问题降维成"ranking"问题，监督信号从 KL divergence 变成 discrete ranking，难度立刻降一个数量级。

具体方法流程：

1. 观察 local sufficiency：在每个 divergence point，SLM 给出 top-K（典型 K=8）候选，跑一次 LLM 让它从这些候选里选——发现 hit rate 95%
2. S2T (基线版本)：推理时让 SLM 生成 top-K 候选 → LLM 做 selection → 拼接，依然有 LLM 调用但 token 数极少（一次 selection 远便宜于 open-ended generate）
3. S2T-LOCAL (蒸馏版)：把 selection logic 蒸馏到 SLM 里——SLM 学会自己识别 divergence point + 自己 rerank top-K，完全消除推理时 LLM 调用

跟之前方法的本质区别：标准 distillation 让小模型模仿大模型 logit 分布（连续、复杂、容量受限）；S2T 让小模型只学一个 discrete classifier（在自己的 top-K 上 rerank）。监督信号从"复杂概率分布"压到"K 选 1"，loss landscape 简单得多。

关键结果

设置	平均得分提升	推理时 LLM 调用
SLM (1.5B) baseline greedy	0	0
8-path self-consistency	+24.5%	0（但 8x 算力）
S2T (推理时调 LLM 32B)	+25%+	有
S2T-LOCAL (蒸馏后)	+24.1%	0
关键事实：SLM top-8 命中 LLM 选择	95%	—

结果解读：

• 24.1% greedy 提升 ≈ 8-path self-consistency，意味着 S2T-LOCAL 用 1/8 算力达到同等效果——这是真正意义的"免费午餐"
• 95% 这个 top-K hit rate 是全文最反直觉的数字。它直接挑战了"小模型容量天花板"的传统叙事——容量限制可能更多体现在 ranking 而不是 generation
• 论文没有专门跑 code benchmark（主要是数学和推理），但 code generation 的 token-level decision 本质上和数学推理类似（都是 deterministic 后续展开），这个结论很可能迁移

局限性与开放问题

• 局限 1：95% hit rate 只在数学和通用推理上验证，code generation 的 divergence point 分布更复杂（语法约束 + 语义约束同时存在），top-K hit rate 可能下降
• 局限 2：K=8 的选择没有详细 ablation——K 太小漏正解，K 太大相当于又回到 open-ended ranking。code 上最优 K 可能不同
• 开放问题：SLM 学会 selection 后，会不会丧失原有的 ranking 多样性？长链条推理（很多 divergence point 累积）下 95% hit rate 会不会衰减成 0.95^N？

💡 对我们的启发

1. 直接可用的技术点：S2T-LOCAL 这个想法可以直接搬到 code completion / fill-in-the-middle 场景。我们之前在做 prefix-matching decoding 时一直在想"小模型的 top-K 候选里有多少包含正确答案"——S2T 给了一个具体的测量方法和 24.1% 的可达上限。直接的实验：用 DeepSeek-Coder 1.3B 在 HumanEval 上测 top-K hit rate（用 GPT-4-Coder 选择），如果 hit rate 也是 90%+ 范围，那"小模型 + 一次 LLM 选择"的工程方案就立刻可行
2. 具体实验想法：在我们 program repair 项目里，patch 生成本质就是一系列 divergence point。可以做一个实验：让 6.7B 小模型生成 top-K patch 候选（K=4-8），用一次 LLM 选择——和 8-sample beam search 对比 plausible 率和 correct 率。预期：cost 降 8x，性能持平甚至更好。1-2 周可完成
3. 趋势判断：local sufficiency 这个观察会催生一波"select instead of generate"的工作。从研究哲学上讲，这正是我喜欢的"边际价值精确量化"——不是宣称小模型比大模型强，而是精确测出大模型在哪个具体 token 上贡献了 marginal value。这个思路可以反过来用在 agent 评估：测每个 agent step 的 marginal contribution，类似 test execution 只贡献 1.25 pp 的发现

---

Cognitive Atrophy and Systemic Collapse in AI-Dependent Software Engineering

推荐理由：一篇 SE 立场论文，没有实验但提出了一个值得做实证的概念——"Epistemological Debt"。我们的 marginal value 路线正好可以接这个假设的测量

📌 论文信息：Frank Ginac | arXiv:2604.26855 | cs.SE, cs.CY

TL;DR

LLM 进入 SDLC 不只是工具替换，而是引入一种"Epistemological Debt"——工程师把 logical derivation 外包给 AI passive verification，根因分析的心智模型在退化。论文用 2026 年 Amazon outages 作为案例，论证这种"mechanized convergence"如何让系统脆弱性放大。

问题是什么？

绝大多数 AI for SE 论文在测"AI 让人写代码更快了"这种正面效应，但没人系统地讨论 AI 让工程师更不会调 bug 这种隐性成本。当工程师习惯了"AI 写 → AI 验证 → 通过"的循环，他们的 mental model（对系统状态、依赖、不变量的理解）就在持续萎缩。这种萎缩的代价不是日常可见的——日常工作 AI 都能 cover——而是在罕见事件（生产事故、复杂 root cause）时集中爆发。

他们怎么做的？

核心 Insight：把"AI 编码生产力提升"和"工程师认知能力退化"当作同一现象的两面，用经济学债务比喻（Epistemological Debt）让这个无形成本变得可量化、可讨论。

论文不做实验，做三件事：

1. 概念建模：定义 Epistemological Debt = (system complexity) - (human comprehension)，类似 technical debt 的认知版本
2. case study：把 2026 年 Amazon outages 重新解读为 mechanized convergence 的后果——所有团队用同一套 AI 工具生成相似代码，集体盲点同时暴露
3. 政策建议：human-in-the-loop pedagogical standards 取代 prompt-based development

关键结果

这是一篇立场论文，没有定量结果。但提出了 3 个值得实证的命题：

• 命题 1：长期使用 LLM 辅助开发的工程师，root cause analysis 任务表现下降
• 命题 2：使用同一 LLM 工具的不同团队，代码风格 / 错误模式趋同（mechanized convergence）
• 命题 3：合成代码递归训练会减少 global software reservoir 的多样性

局限性与开放问题

• 局限 1：完全没有 empirical evidence，所有论断靠类比和单一 case study 支撑
• 局限 2：Amazon outages 作为案例选择有 cherry-picking 嫌疑——其他大型 outage（如 2023 Cloudflare）的 root cause 不一定支持同样叙事
• 开放问题：Epistemological Debt 怎么测量？最直接的测量是 controlled study——让两组工程师（AI-assisted vs not）做同一组 root cause analysis 任务，比较 time-to-diagnose 和 hypothesis quality

💡 对我们的启发

1. 直接可用的技术点：这篇本身没什么"技术"，但它提出的三个命题里命题 2（mechanized convergence）可以直接做实证——抓 GitHub 上 AI-assisted commits 和 human commits，跑 code style clustering 看 AI 组的 diversity 是否下降。这个实验和 Hot Fixing in the Wild 用的同一份 AIDev 数据完全兼容
2. 具体实验想法：构造一个 "RCA Marginal Value" benchmark——给一组真实生产 bug，分别让 (a) 完全人工 (b) 人 + AI assistant (c) 纯 agent 三组解决，记录 time-to-root-cause、wrong-hypothesis count、final fix correctness。这是个工业界刚需而学界几乎空白的方向。如果做出来，发顶会几乎是稳的，且和我们 marginal value 主线完全契合
3. 趋势判断：AI 工具进入 SE 的"反作用"会成为 2026-2027 年新热点。今天这篇是早期信号，方法论上不够硬，但提出的问题正确。我们如果能在他们之前用真实数据测出 Epistemological Debt 的存在性，就是在领域里抢到一个 framing position

---

方法对比

维度	Hot Fixing	ClassEval-Pro	Select to Think
核心方法	大规模 trace 分析 (61K repos)	自动化 benchmark 构造 + LLM Judge	local sufficiency 观察 + selection 蒸馏
数据需求	现有 GitHub + AIDev 标注	post-2025-01 GitHub + 11 领域 seeds	数学/推理任务 + LLM teacher
计算开销	SQL + 静态分析（极低）	一次性构造（中），评估时按模型规模	训练 1.5B SLM（中等），推理 0 LLM 调用
适用场景	生态级现象描述、agent 行为审计	模型 class 级合成能力对比	SLM 部署、推理时无 LLM 依赖
主要局限	urgency 启发式定义、质量未挂钩行为	LLM Judge 一致性未验证、污染未完全消除	95% hit rate 仅在数学验证、code 未测
可借鉴点	用 metadata signature 操作化抽象概念	三阶段 + Judge Ensemble + post-cutoff 防污染	"select instead of generate" 思路

今天的四篇论文都把"AI 在 SE 里的边际价值"这个抽象问题翻译成了可以测量、可以对比、可以反驳的具体设计。我们做这条路线的研究者，今天值得把 Hot Fixing 和 S2T 这两篇至少精读一遍。