每日三条 · 2026-09-07：软件 / AI / 软件工程前沿

本期避开历史已覆盖的「Spec-First 重构 / Harness / 轨迹评估 / 复合 Prompt 退化」主线，改从「编辑保真度」「LSP×形式化验证闭环」「需求后至式涌现」三个未被近期日报触碰的子方向切入——三个方向共同指向一个迁移：2026 年 9 月的 SE+LLM 研究正在从「Agent 能不能写对」转向下沉指标：diff 是否最小、输出能否被验证器收敛、需求在会话中如何迟到。

1. 当模型改太多：最小代码编辑保真度问题

论文：arXiv:2609.04061

核心问题：LLM 做 bug fix 时经常顺手改掉无关行、重排导入、顺带做点小重构——这些”顺手”在单次通过率上无害，但在工程上制造了三个麻烦：diff 噪声让 reviewer 成本反升、跨仓库泛化时把目标外的代码也改坏了、训练数据里的损坏模式被 SFT 过拟合继承下来。

方法：把「编辑保真度（edit fidelity）」单列为独立评测维度——定义「最小必要编辑」为只改能修 bug 的那几行，其他所有变更都是噪声。构造了跨多语言、多损坏模式的编辑保真度 benchmark，对比 SFT 和 RL 两种训练范式在域内外的保真度表现。

关键发现：

  • SFT 过拟合到训练集的特定损坏模式，域外编辑保真度显著下降
  • RL 在域外编辑保真度与任务性能保持上更优——保真度是可学习的目标
  • 导入重排、无关格式改动占低保真度案例的主要来源

结论：编辑保真度是可度量、可训练的一阶目标，不只是「顺便做好」的可选项。

产品启示：Agent 写代码从「能跑」走向「能合入」，diff 可读性比一次通过率更决定生产接受度。未来的 Agent 评测要加「编辑规模」门禁——通过率够高但改了 500 行的方案不该和只改 3 行的方案得同分。

2. LSP 是 LLM 与形式化验证器之间的那层协议

论文：arXiv:2609.03086

核心问题：自然语言规格转代码容易，但自然语言规格本身可能有歧义或遗漏。”Spec-Driven”依赖人先把 spec 写对，但现实里的规格是在「写代码→验证→反推规格」迭代中逐渐清晰的。

方法：Eiffel-tools 把 LSP（Language Server Protocol）作为 LLM 与静态验证器之间的中间层——

  • LSP 层：提供精确的语言/项目级上下文，构造 programmatic prompt（而非自然语言 prompt）
  • LLM 层：根据上下文生成代码与规格
  • 形式化验证器层：对输出做证明，不通过则返回反例
  • 重试层：工具自动把验证器反馈灌回 prompt，直到通过

在 2 个公开数据集、3 个模型上，bug 修复率达到 76%–95%。

关键洞察：把「LLM 负责猜想、验证器负责证伪」做成了工程化的分工协议——不是让 LLM 自己保证正确，而是把它嵌进一个可重试的收敛环里。

结论：把「自然语言编译」从比喻变成可重试的协议闭环，是 Spec-Driven 之外另一条更硬核的收敛路径。LSP 提供了项目级语义，验证器提供了证明级保真度，两者叠加让 LLM 的输出不再是黑箱。

产品启示：这条路线对 IDE 原生集成更自然——不是给 LLM 一个更好的 prompt，而是给 LLM 一个有上下文、有反馈、可重试的工作流。如果你的 Agent 还在靠「prompt 优化」对抗幻觉，这篇论文指向了另一条路。

3. 需求在第一次编辑之后才来（续）：晚期需求涌现的量化证据

论文：arXiv:2609.03028

核心问题：上期日报（2026-09-05）已经覆盖了「需求后至式涌现」的概念，本期补充这篇的量化细节——它把现象做实了，而不只是定性描述。

方法：基于 3,553 条真实 SWE-chat 会话，量化「用户看到部分实现后才说出新约束」的现象。会话可重放，在仓库状态快照上标注”需求到达时机”与”此前 Agent 写过的行被删/替”的关联。

关键发现：

  • 需求到达后，Agent 已写代码被删除/替换量约为普通非需求编辑的 2 倍
  • 延迟披露会把实现推到揭示后重做
  • 提前警告并未显著降低覆写——说明问题不在于”用户没说清楚”，而在于”看到实现之前用户不知道要说什么”

结论：晚期需求涌现是可度量的代码作废源，不是用户的沟通问题，而是人机协作系统的结构性问题。

产品启示：解释了为什么「先写 AGENTS.md 再跑 Agent」仍会返工——需求缓冲层（而不是更好的 prompt）才是解法。具体来说：Agent 要支持「需求冻结窗口」（先跑不依赖需求的脏实现，后续用需求补充覆盖），或者 CI 层要有识别「需求后至覆写」并降低其惩罚的机制。

视角小结

三个角度合在一起：

  • 编辑侧：最小 diff 是独立目标，SFT 会把它学坏，RL 才能保持
  • 验证侧：LSP+LLM+形式化验证器构成可重试闭环，让「自然语言编译」变成工程协议
  • 需求侧：晚期需求是会话级结构问题，单次 prompt 优化无法消除，需要需求缓冲层

共同信号：2026 年 9 月的 SE+LLM 研究正在从「能不能写对」下沉到「怎么保证合入质量」。这比跑分更重要，因为生产看的是 diff，不是 benchmark 分数。