arXiv 每日速递 2026-04-29

今日总结

今天 cs.SE 罕见地集中爆发，4 篇值得读的论文围绕同一根主线：LLM × SE 评估的舒服假设正在被实证逐条拆掉。 Akli 等卢森堡团队同日放出姐妹工作 [9][14]，前者发现 prompt 欠规范有时反而能提升 code 正确性，后者训了一个小模型分类器 SpecValidator 在缺陷 task description 检测上吊打 GPU-5-mini 和 Claude Sonnet 4；[37] 是一份血淋淋的 5 天 / 204 commit 工程日志，把 on-device SLM 在 Android 真实产品上的 5 类失败模式逐条记账；[42] 则在更高一层喊话：AI4SE 工具评估的"单一 ground truth、确定性输出、客观正确性"这三大支柱在 LLM 时代全部不成立。今天读这 4 篇，比读过去一周很多 LLM-coding 论文都更"扎心"。

今日全览

论文	方向	核心贡献	与我们的相关度
When Prompt Under-Specification Improves Code Correctness	prompt robustness	HumanEval 上 prompt mutation 是否伤害正确性高度依赖 benchmark 结构冗余度，LiveCodeBench 上欠规范甚至能修正"误导性词汇线索"	⭐⭐⭐
Defective Task Descriptions in LLM-Based Code Generation	spec quality	SpecValidator（小模型 LoRA 微调）F1 = 0.804 检测 task 缺陷，远超 GPT-5-mini / Claude Sonnet 4	⭐⭐⭐
Less Is More: On-Device SLM Engineering Challenges	local LLM × mobile	一份 Palabrita Android 游戏的 5 天集成实录，从"LLM 全权生成"退化到"LLM 只生成 3 个 hint"	⭐⭐⭐
Evaluation of LLM-Based SE Tools	evaluation methodology	Position paper：LLM 时代 AI4SE 评估的三大假设（ground truth / 确定性 / 客观正确）全面失效	⭐⭐⭐

今日主题：评估范式的塌方与新地基的建造

如果你这一年只读一天的 SE 论文，今天可能是个不错的选择。这 4 篇出奇地咬合在一起，它们共同指向一个判断——过去十年支撑 SE 评估的方法论假设，正在 LLM 这把锤子下被一锤一锤敲松。

[42] 是这场塌方的"理论挽歌"——它把"为什么 SE 评估在 LLM 时代变得困难"提炼成五点：缺乏稳定 ground truth、主观与多维度质量、非确定性带来的评估不稳定、自动化与 model-based 评估的失真、评估实践的碎片化。这听起来像务虚，但 [9] 和 [14] 紧接着用实证数据把这几条全部钉死：[9] 直接发现 HumanEval 这种"最小规范"benchmark 上，prompt 微小扰动能戏剧性改变 pass@1，而 LiveCodeBench 这种"结构冗余"benchmark 上同样的扰动几乎无影响——也就是说，过去三年大量"我们的 prompt 方法在 HumanEval 上提升了 X%"的论文，其结论很可能是 benchmark artifact 而不是模型行为。[14] 进一步说：连 task description 本身的"质量"都不是模型自己能感知的——一个 7B 微调出来的小分类器在检测 description defect 上吊打 GPT-5-mini 和 Claude Sonnet 4，这反过来说明大模型对"自己输入是不是欠规范"几乎是盲的，所谓"模型自己能澄清"是评估上的幻觉。

[37] 则提供了塌方现场最真实的工程肖像：一个开发者用 5 天、204 个 commit、两次架构推倒重来，从"让 SLM 生成完整 puzzle JSON（word + 五个 hint + 难度）"退化到"SLM 只生成 3 个 hint，剩下全部 deterministic fallback"。这正是 [42] 那条"non-determinism + lack of ground truth"在产品端的物质化——你以为你在评估"模型能不能生成完整 puzzle"，其实你在评估"模型在 17 种已知失败模式下还能不能凑合"。

这四篇论文合在一起的隐含信息是：从今往后，任何不报告 benchmark 结构冗余度、不汇报 prompt 鲁棒性、不区分"主观质量 vs 客观正确"的 LLM-coding 论文，都应当被默认怀疑。 这跟博主一直在做的"边际价值量化 + benchmark 合理性批判"是同一条战壕的方向。

---

When Prompt Under-Specification Improves Code Correctness

推荐理由：直接给"prompt 微扰 → pass@1 暴跌"这类老生常谈的实验设计判了死刑，是 benchmark 方法论批判的扎实弹药。和你做"agent 单步设计动作的边际价值量化"是同一种实证哲学。

📌 论文信息：Amal Akli, Mike Papadakis, Maxime Cordy, Yves Le Traon（卢森堡大学 SnT）| arXiv:2604.24712 | cs.SE

TL;DR

在 HumanEval 上"prompt 欠规范摧毁 LLM"的故事，在 LiveCodeBench 这种结构冗余的 benchmark 上几乎不成立——更反直觉的是，欠规范有时通过"打掉误导性词汇线索"反而提升正确性。10 个模型 × 2 个 benchmark 的系统对照实验。

问题是什么？

过去三年关于 prompt robustness 的论文几乎都遵循同一个套路：从 HumanEval / MBPP 起步，做几种 prompt mutation（删词、模糊化、词序变换），观察 pass@1 暴跌，得出结论"LLM 对 prompt 极度脆弱"。但这里有个根本性的方法论盲点——HumanEval 的描述本来就极度精炼（一句话 + 一个 docstring），任何 mutation 都会触发"信息瓶颈"，所以"鲁棒性差"很可能是 benchmark 本身设计造成的人造现象，而不是模型的真实属性。论文要回答的具体问题是：当 task description 自带描述、约束、示例、I/O convention 这种结构冗余时，欠规范扰动还会不会致命？以及——会不会有反向效果？

他们怎么做的？

核心 Insight：prompt 鲁棒性不是"模型属性"，而是"模型 × 任务结构"的联合属性。结构冗余的 task description 会自带 error correcting code，欠规范扰动甚至能解除"误导词汇 → 错误 retrieval"的捷径。

具体方法流程：

1. 选 10 个不同规模的 LLM（含开源和闭源），固定生成参数
2. 在 HumanEval（最小规范）和 LiveCodeBench（结构冗余）上施加同一组 under-specification mutation
3. 对每个 model × benchmark × mutation 组合算 pass@1 的 net effect（不只看 degradation，也看 improvement）
4. 对 LiveCodeBench 上 mutation 提升正确性的样例做手工分析，归纳"为什么扰动反而帮了忙"

跟之前方法的本质区别：之前的工作只在 HumanEval/MBPP 上跑、只统计 degradation、只报告平均值。本文同时报告 +/- 双向效果，并且把 benchmark 结构冗余度作为一个新自变量——这一点决定性地动摇了"prompt 鲁棒性"这一概念的可比较性。

关键结果

维度	HumanEval	LiveCodeBench
Under-spec mutation 平均 net effect	显著下降	接近零
出现 mutation 提升正确性的比例	极少	显著存在
鲁棒性与模型规模的相关性	中等	弱

结果解读：

• "鲁棒性差"主要是 minimal-spec benchmark 的 artifact——同一个模型换到 LiveCodeBench 后看起来"突然变鲁棒"，实际上只是输入冗余度变了
• 提升的来源被作者归纳为：打掉过拟合术语、移除误导约束、消除虚假标识符触发器——本质上是欠规范在做"反 retrieval shortcut"
• 这意味着 prompt-robustness 文献需要重新校准：很多在 HumanEval 上汇报的 +X% 鲁棒性，在结构冗余 benchmark 上根本不成立

局限性与开放问题

• 局限 1：作者没有跨模型 family 报告 mutation 反向提升的具体出现率分布——读者无法判断这是"普遍现象"还是"个别样本上的随机扰动"
• 局限 2：LiveCodeBench 本身是一个"防污染优先"的 benchmark，结构冗余只是它的 side effect 而不是主诉求；论文需要更显式的 benchmark 结构冗余度量化指标，而不是用一个具体 benchmark 来代表整个"冗余"维度
• 开放问题：如果欠规范有时能提升正确性，那么"prompt 自动优化"的目标函数应该是什么？最大化 spec 信息量并不一定最大化 pass@1，这个张力没有解决方案

💡 对我们的启发

1. 直接可用的技术点：你现有的 SWE-bench / HumanEvalPack 之类的 trace 分析项目，应该把"benchmark 结构冗余度"作为一个 covariate 加入回归。具体：对每个 task 计算 description / constraint / example 的 token 配比，看看 agent 步骤的边际价值（test execution、structure injection 等）是否跟冗余度交互——这能给 [SWE-bench Verified Lite, 2025] 之类工作的 1.25pp 这种数字加上结构性的解释而不是仅仅汇报一个均值
2. 具体实验想法：选 50 个 LiveCodeBench task，做最小化 mutation（去掉 1 句 + 去掉 1 个 example + 模糊一个约束），用 DeepSeek-Coder-7B 跑 pass@1，对每个 task 标注是 + / - / 0 三类——一周内可以做完，预期发现"约 10-20% 任务 mutation 反而提升"这个现象在小开源模型上同样存在。如果存在，这就是一个非常直接的"小模型 prompt 优化"的发现
3. 研究趋势判断：这一类"benchmark 是否在测它声称要测的东西"的论文，会在 2026 年继续涌现。和你"benchmark 合理性批判"主线完全一致，可以提前布局一篇"AI4SE benchmark 偏差综述 + 实证"——这个 niche 现在没人占，但今年很可能会成为热点

---

Defective Task Descriptions in LLM-Based Code Generation: Detection and Analysis

推荐理由：和 [9] 是同一个团队的姐妹论文，但路线是构造性的——证明一个 7B 小模型 LoRA 微调后在"检测 task description 是不是有缺陷"上吊打 GPT-5-mini / Claude Sonnet 4，这是"小模型替代大模型 + 静态分析职责切分"哲学的标准教科书案例。

📌 论文信息：Amal Akli, Mike Papadakis, Maxime Cordy, Yves Le Traon | arXiv:2604.24703 | cs.SE, cs.AI

TL;DR

作者训了 SpecValidator——一个对小模型做参数高效微调的轻量分类器，专门识别 task description 的三类缺陷：Lexical Vagueness、Under-Specification、Syntax-Formatting。在 3 个 benchmark 上 F1 = 0.804、MCC = 0.745，比 GPT-5-mini（F1=0.469）和 Claude Sonnet 4（F1=0.518）高出近一倍，并且能泛化到训练集中未见过的"野生"under-specification 样本。

问题是什么？

LLM code generation 的隐含前提是"task description 是 well-formed 的"，但真实开发场景里描述经常糟糕：术语模糊、关键约束缺失、格式紊乱。问题在于——LLM 自己识别不出输入有缺陷，它会假装看懂然后生成自信但错误的代码。所以缺陷检测必须由独立的轻量组件做，而不是寄希望于 LLM 自检。但谁来判定"defect"？以前用 GPT-4o 之类大模型当 oracle，结果一致性差、成本高、还容易被自己的偏见污染。这篇论文要造一个能跑在 CI 上、还比大模型更准的小检测器。

他们怎么做的？

核心 Insight：spec defect detection 不是 reasoning 问题，是 pattern recognition 问题——一个用专属数据 LoRA 出来的小模型对这种边界清晰的二分类任务有天然优势，不需要 GPT-5 级别的世界知识。

具体方法流程：

1. 定义三种 defect 类型并构造带标注的训练集（lexical vagueness、under-spec、syntax-formatting）
2. 选一个开源小模型基座，做 PEFT（论文里是 LoRA / QLoRA 风格），仅微调 spec defect 分类头
3. 用 3 个 benchmark（最小规范的 HumanEval、中规模、结构丰富的 LiveCodeBench）做 zero-shot 泛化测试
4. 关键的"野外检测"实验：让 SpecValidator 扫描 benchmark 的原始描述（不是合成扰动版），看能不能找到原本没标注但实际上欠规范的描述

跟之前方法的本质区别：以前要么用通用大模型当 spec critic（贵且不稳），要么用规则系统（覆盖率差）。本文坚持"小模型 + 专属任务 + 高质量标注"路线，把"spec quality" 这件事变成一个独立的、可重复的、便宜的预处理步骤——这非常接近你"静态分析做定位、LLM 只做修复"的职责切分哲学。

关键结果

模型	F1	MCC	推理成本
SpecValidator (小模型 LoRA)	0.804	0.745	极低（本地）
GPT-5-mini	0.469	0.281	中等（API）
Claude Sonnet 4	0.518	0.359	高（API）

结果解读：

• F1 0.804 vs 0.469 不是"略好"，是把对方按在地上摩擦——这强烈说明 spec defect detection 是一个高度任务特异的 pattern recognition，大模型的 generalist capacity 在这里没有任何优势
• 一个亮点是 SpecValidator 在 LiveCodeBench 原始描述里找出了未被人工标注的 under-spec 样本——也就是说连人类标注员都漏掉的 spec 缺陷它能发现，而 GPT-5-mini 和 Claude 看不见
• Under-Spec 是三类缺陷里影响代码正确性最严重的——这跟 [9] 的发现交叉印证：under-spec 在 HumanEval 上是致命的，但配合结构冗余 benchmark 可以抵消

局限性与开放问题

• 局限 1：训练数据是合成扰动出来的（在 well-formed 描述上人工注入缺陷），野外评估虽然有但量级不够，无法证明在真实工业 issue tracker 文本上同样有效
• 局限 2：三类 defect 是先验给定的，但真实 task description 的失败模式远比这丰富（举例错误、约束矛盾、隐藏假设、格式错误等），分类粒度天花板很低
• 开放问题：SpecValidator 检测到 defect 之后下一步该怎么处理？论文没探讨——"检测但不修复"的工具在工程上价值有限，下游需要 spec rewriter 才能闭环

💡 对我们的启发

1. 直接可用的技术点：你的 ArkTS / HomeCheck 路线非常适合复刻这个范式——HomeCheck 静态分析做"代码是否符合 ArkTS 规范"，可以直接添加一个对偶组件做"task description / commit message 是否欠规范"。技术栈完全相同（小模型 LoRA），数据可以从 OpenHarmony 历史 issue 里挖
2. 具体实验想法：用 DeepSeek-Coder-1.3B 做基座，从 SWE-bench / SWE-bench Verified 的 issue description 标注 200 个 spec defect 样本（under-spec / vague / 矛盾约束），LoRA 微调后在 SWE-bench 全集上做 spec defect 扫描——预期能发现 30-40% 的 issue 实际上是 under-spec 的，这立刻可以解释为什么 SWE-bench 上 agent pass rate 长期卡在 50% 附近——不是 agent 不行，是 task spec 本身就有缺陷。这个发现单独可以写一篇 ESEC/FSE level 的 paper
3. 研究趋势判断：这一篇 + [9] 组合起来形成了一个新的 niche——"spec engineering"，把 prompt engineering 升级成对 task description 的工程化处理。这条路博主完全有先发优势，因为博主的程序修复 + 兼容性迁移工作里 task description 质量的变异度本来就很大

---

Less Is More: Engineering Challenges of On-Device SLM Integration in a Mobile Application

推荐理由：对你 OpenHarmony / ArkTS 工具链方向是教科书级别的工程参考——一份 5 天、204 commit、两次架构 pivot 的真实日志，把 on-device SLM 在生产 Android app 上的失败模式做了五分类。直接可以平移到 ArkTS 应用里 device-side 模型集成的研究问题。

📌 论文信息：William Oliveira | arXiv:2604.24636 | cs.SE, cs.AI, cs.CL

TL;DR

作者把 Gemma 4 E2B (2.6B) 和 Qwen3 0.6B 集成进一个生产 Android 拼词游戏 Palabrita，5 天内从"LLM 全权生成完整 puzzle"被迫退化到"LLM 只生成 3 个 hint，剩下都是规则化 fallback"。论文用 5 类失败模式（output format violation / constraint violation / context quality degradation / latency incompatibility / model selection instability）系统化记录了为什么 on-device SLM 在产品里"the most reliable feature is one where the LLM does the least"，并提炼出 8 条工程启发。

问题是什么？

on-device SLM 卖点很美：不联网、不上传数据、零延迟、零成本。但当真把一个 2.6B / 600M 参数模型塞进一个真实的 Android 用户面前的产品里，它能不能稳定生成"4 选 1 难度的拼词题目 + 5 条 hint + JSON 格式"？这种"看起来像 trivial 任务"的问题在生产里几乎全军覆没。论文要给出的不是新算法，而是一份实战教训手册：这个 size 的模型在哪些点上必然失败、用什么工程手段能续命、什么任务不能交给它。

他们怎么做的？

核心 Insight：on-device SLM 的可靠性边界由"任务的最低职责"决定，而不是模型的最大能力——产品稳定性来自系统化地从 LLM 手里拿走责任，而不是不断 jailbreak 它去承担更多。

具体策略：

1. 多层防御性 parsing（一旦 JSON 格式跑偏，分级 fallback 到松散的 key-value，再到纯文本提取）
2. 失败反馈的上下文重试（让模型看到自己上一次的错误并给出修正机会，但限次数）
3. session rotation（避免长期上下文累积让模型 drift）
4. 进阶式 prompt 加固（让 prompt 在每次失败后变得更冗长更约束）
5. 系统性责任压缩（这是核心策略——把 LLM 的输出域从"完整 puzzle"压到"3 个 hint"）

跟之前方法的本质区别：传统的 SLM 论文都在比 benchmark 分数，没人把"产品里到底咋用"写成 case study。本文把工程现实写成了五类失败模式 + 八条启发，结构上接近 Google SRE Book 那种行业教训文档。

关键结果

维度	初版架构（LLM 全权生成）	终版架构（LLM 仅生成 hint）
LLM 输出维度	word + 难度 + 5 hint + JSON	3 个短 hint
失败时行为	整局游戏崩溃	静默 fallback 到 deterministic hint
用户可见错误率	高	接近零
开发周期	5 天 / 204 commits / 2 次架构推倒	当前最终版本

结果解读：

• 这不是"模型不够大"问题——作者尝试 Gemma 4 E2B (2.6B) 和 Qwen3 0.6B，failure mode 是相似的，只是分布不同
• 真正的产品收益不是 LLM 能不能生成 puzzle，而是 LLM 能不能可靠提供"最后一英里"的内容润色——这跟工业上 RAG 系统现在的做法（LLM 只做生成，retriever 做事实）哲学一致
• 8 条启发里最值得记住的一条："the most reliable on-device LLM feature is one where the LLM does the least"

局限性与开放问题

• 局限 1：N=1（一个游戏 app），不能确认这些失败模式在更复杂的 app（输入法、写作助手、阅读理解）里同样表现
• 局限 2：作者没有给出量化的失败率数据（多少 prompt 触发 format violation、多少触发 constraint violation），失败模式分类很有用但缺乏数字支撑
• 开放问题：模型选型不稳定（model selection instability）这条很有意思但论文没深入——同一个产品换模型重新调教需要多少工程投入？这是 OpenHarmony 这种新生平台必须回答的问题

💡 对我们的启发

1. 直接可用的技术点：你做 ArkTS / OpenHarmony 工具链时，这 5 类失败模式可以直接平移到 ArkUI 端侧 LLM 应用研究——把"on-device SLM 集成"作为 OpenHarmony 生态工具链的下一个 vertical，写一篇 OpenHarmony 上 SLM (Cangjie 模型 / 小型开源代码模型) 的工程挑战实证研究。技术现成、生态空白、社会价值清楚
2. 具体实验想法：在你已有的 HomeCheck pipeline 里加一个"端侧 LLM 修复"模块：用 Qwen3 0.6B 或 Phi-3-mini 在 HarmonyOS 设备上做"局部 ArkTS 代码修复"，跟踪 24 小时内的 5 类失败率分布——一周内可以拿到第一份数据。如果分布跟 Palabrita 类似，这就是 OpenHarmony 端侧 LLM 工具链的第一份基线报告
3. 研究趋势判断：on-device SLM 在 2026 年会从"benchmark 论文阶段"进入"工程落地论文阶段"——这一篇是这个转换的标志。早期占据"端侧 LLM 工程模式"这个 niche 的人会非常有话语权，而 OpenHarmony 是天然的实验平台

---

Evaluation of LLM-Based Software Engineering Tools: Practices, Challenges, and Future Directions

推荐理由：position paper，但是把"LLM 时代 AI4SE 评估方法论的根本缺陷"写得很清楚——博主 PhD 阶段的一个核心方向就是 evaluation methodology，这篇可以作为对外的"方法论框架引用"，也是做综述的优秀骨架。

📌 论文信息：Utku Boran Torun, Veli Karakaya, Ali Babar, Eray Tüzün | arXiv:2604.24621 | cs.SE

TL;DR

LLM-based AI4SE 工具的评估方法论从根上塌方了——传统 SE/ML 评估假设的"单一 ground truth、确定性输出、客观正确性"在 LLM 时代全部不成立。论文系统列出 5 类核心挑战和未来方向，是 2026 年想做 SE evaluation 方法论研究的人必读的对位锚点。

问题是什么？

过去 30 年的 SE 评估传统几乎全部建立在三个隐含假设上：(1) 每个任务有唯一正确答案；(2) 系统输出可重复；(3) 正确性可客观判断。这三条对编译器、静态分析、传统 ML 模型基本都成立，但对"GPT-5 给出的 PR 审查意见好不好"、"Claude 写的 docstring 是否符合工程文化"这类任务全部失败——多种正确答案并存、同一 prompt 多次运行结果不同、什么算"好"高度主观。问题是大量 AI4SE 论文还在用旧框架做评估，得到的数字根本不能支持其结论。论文要做的就是把这个问题完整摊开。

他们怎么做的？

核心 Insight：LLM-based SE 评估不是"找一个更好的 metric"的问题，是从"single oracle"范式整体迁移到"distribution-aware + multi-stakeholder"范式的问题。

论文系统化讨论了 5 类挑战：

1. 缺乏稳定 ground truth：很多 SE 任务（commit message、code review）没有唯一正确答案
2. 主观性与多维度质量：可读性、维护性、风格一致性都不可单一量化
3. 非确定性带来的评估不稳定：同一 prompt × 同一模型 × 不同 seed → 不同结果，传统单次评估失效
4. 自动化与 model-based 评估的局限：用 LLM-as-judge 引入 judge 自身偏见，污染评估结果
5. 评估实践碎片化：每篇论文用不同 benchmark + 不同 metric + 不同设置，论文之间无法横向比较

并指出未来方向：rubric-based evaluation、LLM-as-judge 的标定与去偏、distribution metrics（不是 mean 而是 confidence interval）、多 stakeholder 评估视角、跨工具的统一 evaluation reporting standard。

跟之前方法的本质区别：position paper 不出新方法，但提供了一个统一的语言让批判变得清晰——之前你只能说"我觉得这个 benchmark 不行"，读了这篇你可以指着 challenge #3 说"这是 stability under non-determinism 问题"。

关键结果

position paper 没有实验，关键贡献是清晰的分类法：

评估挑战	受影响的 SE 任务（示例）	现行做法的失败点
缺乏 stable ground truth	commit message、code review	单一 reference 无法表征合法答案空间
主观性 / 多维度	docstring、refactoring	单一标量得分丢失维度信息
非确定性	几乎所有 LLM-based 工具	单 run 报告掩盖方差
Automated / LLM-as-judge	评估 LLM 输出的 LLM	judge 偏好污染评估
实践碎片化	跨论文复现	设置差异让 meta-analysis 无法做

局限性与开放问题

• 局限 1：position paper，没给出"该怎么做"的具体协议——5 类挑战识别得清楚，但读者真要落地评估改进还得自己造工具
• 局限 2：没有引用最近一些 rigorous evaluation 工作（McNemar、TOST 等价检验、Cohen κ 一致性），这意味着论文虽然在喊"我们需要严谨评估"，但实操指引不够具体
• 开放问题：当 ground truth 不稳定时，如何防止"只换 evaluator 就能改变 ranking"这类操作？论文意识到了 LLM-as-judge 的偏见问题但没给出可执行的解决方案

💡 对我们的启发

1. 直接可用的技术点：你做 SWE-bench trace 分析时引用的统计严谨性（McNemar、TOST、Cohen κ / Gwet AC1）刚好是这篇 position paper 缺的"实操层"。可以写一篇"AI4SE Evaluation: From Position to Protocol"——以这篇为引子，给出具体的 evaluation reporting checklist（哪些方差必须报告、何时必须做等价检验、何时必须做一致性指标），完美延伸博主已有的边际价值量化主线
2. 具体实验想法：把博主已有的"agent 单步设计动作贡献"实验，按照这篇论文的 5 类 challenge 重新审视——比如 test execution 的 1.25pp 贡献是 mean over runs，但报告了 confidence interval 没？是单一 LLM-as-judge 给的还是多 judge 投票的？跨任务 fragmentation 系数多少？这些再做一次能直接成为博主"实证评估方法论"的旗舰章节
3. 研究趋势判断：2026-2027 年 AI4SE 评估方法论会变成一个独立的 niche——不会有人再接受"我在 HumanEval 上做了一次实验"作为可信结论。博主的 SWE-bench trace 分析路线刚好踩在这个时间窗的开端，可以提前布置"evaluation rigor 工具链"作为长期主线

---

方法对比

[9] 和 [14] 是同一团队的姐妹工作，可以放在一张对比表里看清楚思路结构：

维度	[9] When Prompt Under-Spec Improves	[14] SpecValidator
路线	实证发现（"是什么"）	构造性方法（"如何检测"）
核心方法	10 模型 × 2 benchmark × prompt mutation 的对照实验	小模型 LoRA 微调，三类缺陷分类
数据需求	现有 benchmark + mutation 脚本	合成 spec defect 标注集
主要 finding	benchmark 结构冗余度决定鲁棒性，欠规范有时反提升	7B 小模型微调可在 spec defect 检测上吊打 GPT-5-mini / Claude Sonnet 4
适用场景	benchmark 方法论批判 / prompt 鲁棒性研究	工业 CI 集成 / spec quality 检测
主要局限	LiveCodeBench 单 benchmark 代表"冗余"维度	三类 defect 分类粒度低

[37] 与 [42] 看似不同层次（一个工程实录、一个 position paper），但实际是相互印证的关系——[42] 提出的"non-determinism + lack of ground truth + subjective quality"在 [37] 的 5 类失败模式里完整复现：output format violation 是非确定性的具体表现、constraint violation 是 ground truth 含糊的具体表现、context quality degradation 是主观质量的具体表现。[42] 是症状学，[37] 是临床记录。

把今天 4 篇论文一起读：你会发现"AI4SE 评估范式塌方"在三个层次同步发生——理论上（[42]）、benchmark 上（[9][14]）、产品上（[37]）。这不是巧合，而是 LLM 把以前"工程"和"评估"两个分离环节强行耦合了。博主的边际价值量化主线 + OpenHarmony 工具链方向，刚好同时处于这三个塌方层次的交叉点上——这是一个时间窗口非常清晰的研究机会。