需求在第一次编辑之后才来：3,553 条真实会话的量化证据

写 AGENTS.md → 跑 Agent → 实现跑通 → 用户说「等等，还要支持……」这是沟通问题，还是系统结构问题？

现象的量化

上一期日报（2026-09-05）已经覆盖了「需求后至式涌现」的概念定性描述，这篇论文把现象做实了。

论文：Requirements After the First Edit: Mining Late Requirement Emergence and Rework in Real-World Coding-Agent Sessions
作者： Bowen Jiang, Haowei Cheng, Yuhong Fu, Anne Koziolek, Jialong Li, Weixing Zhang（Waseda / Adelaide / KIT）
发表：待定（arXiv:2609.03028，2026-09-02）
链接：arXiv:2609.03028

研究基于 3,553 条 SWE-chat 真实会话，在可重放仓库状态下，量化了「用户看到部分实现后才说出新约束」这一现象的规模。

方法：把需求到达和代码失效关联起来

SWE-chat 数据集提供了每条会话的行级代码归属——哪些行是 Agent 写的，哪些是人写的，哪些后来被删了。这让研究者可以把「需求到达时机」和「此前 Agent 代码被删除/替换量」做关联分析。

三个编码维度（来自需求工程的经典框架）：

操作类型：需求是对实现做 addition、deletion 还是 modification
与初始 brief 的关系：补充、修改还是完全推翻
触发来源：用户自发披露 vs. Agent 询问后触发

失效代理变量：在可重放的会话子集上，以「需求到达后，Agent 已写代码被删除或替换的行数」作为代码失效量的代理指标。

核心发现：需求到达后的失效量是普通编辑的 2 倍

RQ2 的核心结果：一个需求到达之后，Agent 已写代码被删除/替换的行数，约为同等非需求编辑的 2 倍。

这个结论在以下两个控制条件下仍然成立：

只比较「用户发消息后」的编辑（控制用户再次说话的效果）
净删除量敏感度分析（控制「需求删除 vs. 需求补充」的不对称性）

论文特别指出：这是关联性发现，不是因果证明——不是说这个需求导致了这些删除，而是「需求到达后，代码确实更容易被大面积推翻」。

进一步发现：会话内没有自动衰减

RQ2b：随着会话推进，晚期需求的失效负担会降低吗？

答案：没有检测到下降趋势。这意味着晚期需求问题不是「随着 Agent 变聪明而自动消失」的那种问题——它是会话结构的固有属性，和模型能力无关。

操作类型对失效量的影响

RQ3：需求的操作类型（addition / modification / deletion）是否影响后续的代码失效量？

答案：在控制了需求数量的前提下，没有检测到显著差异。也就是说，「添加新约束」「修改已有约束」「删除已有约束」三种操作类型对后续代码失效量的影响是相似的——真正驱动失效的是「需求的数量」，而不是「需求的类型」。

这和直觉略有出入：一般会认为「删除已有约束」带来的重写最少，但数据没有支持这一点。

控制实验：提前警告有用吗？

RQ4 设计了一个对照实验来回答：晚披露需求的问题，是否可以通过「提前告知可能有后续需求」来缓解？

E1（延迟披露效应）：把需求的披露时间往后推，会发生什么？

结果：延迟披露把「本应提前做的实现」移到了「披露之后」，而不是凭空产生额外的工作量。也就是说，延迟披露的代价是把实现推迟，而不是增加总工作量。

E2（提前警告效应）：在会话开始时告诉用户「后续可能有新需求」，能减少后续的代码覆盖吗？

结果：没有检测到显著效果。提前警告并没有减少后续的代码覆盖量。

这个结果意义重大：问题不在于「用户没有意识到要说清楚」，而在于「用户在没有看到实现之前，不知道要说什么」——这是一个认知局限，不是沟通意愿问题。

为什么这个发现比听起来更悲观

一般的分析会把「晚期需求」归因于「用户 prompt 质量不高」或「没有在开始前把需求文档写完整」。这个研究的数据指向了更根本的问题：

人需要看到系统，才能对系统形成约束。

这是需求工程领域几十年来的经典发现——「stakeholders cannot express a constraint until part of the system already exists to react to」——在 AI 编程 Agent 场景下的量化复现。

在传统软件工程里，这个现象的代价是「项目周期级别的返工」；在 Agent 会话里，代价被压缩到了「几分钟内的代码覆盖」——但量级上的压缩不等于性质上的改变。

对 Agent 开发流程的实际影响

「先写 AGENTS.md」的战略局限性

现在很多 Agent 开发实践建议「先把 AGENTS.md 写完整再跑」。这篇论文说明：即使你把 AGENTS.md 写得很完整，用户仍然会在看到实现之后产生新约束，而且这些新约束带来的代码失效量是普通编辑的两倍。

这不是 AGENTS.md 写得不好的问题——这是人机协作系统的结构性问题。

解法方向一：需求冻结窗口

Agent 应该支持「分层实现」策略：

第一层：只实现与当前需求兼容的最小子集
后续层：在需求披露后扩展，而不是覆盖

这需要 Agent 有「需求兼容性判断」的能力，而不是一股脑先实现再说。

解法方向二：会话级需求追踪

把「需求到达时机」做进 Agent 的状态管理：记录哪些需求是「首轮披露」的，哪些是「实现后到达」的，对后者降低「惩罚系数」或提供更轻量的覆写机制。

解法方向三：CI 层识别需求后至覆写

在自动化评测里，如果能识别出「这次代码大量覆写是因为需求后至」而不是「模型能力不足」，就能更准确地评估 Agent 的真实能力边界，而不是把结构性问题误判为模型问题。

研究贡献的方法论价值

这篇论文的 contribution 不只是数据，还有测量框架本身：

编辑事件单元（edit-event unit）：跨标注者的可复现标注协议
聚合可靠性度量：对倾斜标签的聚合评估方法
匹配伪事件控制：用非需求编辑做对照组
自我修正实验设计：E1 和 E2 的正交设计

这些组件是可复用的，不只适用于 SWE-chat，可以迁移到其他会话数据集上做类似的分析。

小结

三个核心数字：

2 倍：需求到达后的代码失效量是普通编辑的 2 倍
0：会话内没有自动衰减，不随时间改善
无显著效果：提前警告并不能减少后续覆盖

这不是用户沟通问题，是人机协作系统的结构性问题。解法不在于更好的 prompt，而在于会话级需求缓冲层——让晚期需求的代价更低，而不是试图在事前消除晚期需求。