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

本期避开历史已覆盖的 Harness Engineering、PTA-IRT、CordisBench、SNC、ACToR 等主题，改从「需求时序性」「提示复合退化」「PR 评审门禁」三个未被前序日报触及的角度切——都是 2026 下半年 Agent 从”会写”往”能进生产”拐弯时踩到的软坑，而非模型能力本身。

1. 需求在第一次编辑之后才来：编码 Agent 真实会话里的晚期需求涌现

论文：arXiv:2609.03028

核心问题：编码 Agent 经常在用户把需求说清之前就开始改代码——这是需求工程里”系统先存在、约束才被反推出来”的老毛病在 Agent 时代的重演。

方法：爬了 3,553 条真实 SWE-chat 会话，对”实现后到达的需求”沿三个维度标注，在可重放仓库状态下把它和”此前 Agent 写过的行被删/替”做代理关联。

关键发现：

  • 需求在后半程到达后，带来的代码失效量约为同等非需求编辑的 2 倍
  • 这种负担在会话内不随时间下降
  • 延迟披露会把实现推到揭示之后，但提前警告并不显著降低覆盖式重写

结论：把”晚期需求涌现”做成了可量化指标——不是玄学，是真实存在的代码失效来源。

产品启示：把”用户首轮 prompt”当 spec 是错的。会话内要留”需求可达性”缓冲与回滚面。早期快速实现不等于节省时间——它可能只是制造了两倍于后期的清理成本。

2. 复合提示约束：格式 × 人设 × 紧急程度的超加性退化

论文：arXiv:2609.03156

核心问题：生产态 prompt 从来不是单约束，而是”输出格式 + 人设 + 紧急程度”叠加，但实验往往只测单因子。

方法：3×3×3 全因子（27 组合）× 164 道 HumanEval+ × 5 个模型（GPT-4o 家族、GPT-4.1 家族、o3-mini）= 22,140 次贪心解码。把复合效应拆成加法项 + 超加性残差。

关键发现：

  • 复合约束产生单因子实验预测不到的架构依赖退化
  • GPT-4o 家族出现稳定超加性，pass@1 比加法预测再掉 3–12 个百分点；最大交互是 GPT-4o-mini + JSON + 专家人设 + 中度紧急，下跌 12.2pp
  • GPT-4.1 家族基本不受影响；o3-mini 出现相反模式，结构化输出约束反而提升性能
  • JSON 组合的交互大于 XML

结论：提示工程里加约束不是线性叠加，某些组合会塌方。评测 Agent 不能只测裸 prompt——复合约束下的退化是真实的生产风险。

反直觉结论：单人设、有”尽快”、有”用 JSON 输出”每个单独看都没问题，叠加在一起反而可能比什么都不加还差。

3. SWE-Gate：功能测试过了 ≠ 能合进主干

论文：arXiv:2609.04167

核心问题：现有仓库级 SWE benchmark 只判”功能测试过没过”，忽略真实 PR 里 reviewer 留下的接受约束——命名规范、错误处理、弃用 API、日志规范等。

方法：SWE-Gate 从真实 PR review comment 抽约束，构造 303 个修复实例横跨 75 个 Python 仓库，每个实例配”功能测试 + 约束测试 + 违规补丁 + 金补丁”。

关键发现：

  • 644 个通过功能测试的修复里，221 个不满足 review 约束
  • 功能正确 ≠ 可合并，比例约 34% 被功能-only 评测漏掉
  • 功能-only 评测系统性高估 Agent 产能

结论：把”能跑”和”能合进主干”切开，是 Agent 评测从 demo 走向 CI 的必经一步。这也解释了为什么仓库维护者仍不敢全自动 merge——功能过了，review 约束还差一截。

工程含义：Agent 的评测标准要从”功能 pass”升级到”功能 pass + 约束 pass 双门禁”，否则跑分再高也只是自嗨。

视角小结

三个角度合在一起：

  • 需求侧：晚期需求是代码失效的独立来源，不因为 Agent 变强而自动消失
  • 提示侧：复合约束的退化是架构相关的，不是越大越贵越好——评测要覆盖真实约束组合
  • 评测侧：功能测试是必要条件，不是充分条件；review 约束才是进入主干的真正门槛

都是”看起来是工程问题，但测不出来就会变成模型问题”的那种软坑。