TL;DR

单轮 HumanEval 高分严重高估可靠性。研究将 HumanEval+/MBPP+ 改造成 8 轮需求演化链，发现 40%–73% 的任务在后续轮次丢失早轮已满足的行为，主因是 Cross-Turn Conflict（后轮代码与早轮隐含需求冲突）。唯一稳定有效的缓解是 Verification Gate——拿新代码跑早轮测试，失败则回滚重试。DeepSeek-V3 末轮质量从 75.8% → 87.9%。

核心观点：Vibe Coding 的真实失效模式不是「写不出」，而是「改坏之前对的」。评测基准必须从单轮 Pass@1 迁移到「需求保留率」。

1. 背景：单轮评测的幻象

HumanEval Pass@1 是 2023 年的指标。彼时 50% 的通过率意味着 AI 还很差，单轮表现大致能反映真实水平。

2026 年，Claude 3.5 / GPT-4.5 / Gemini 2.0 在 HumanEval 上已经突破 90%。单轮高分成了一种幻象——它在标准评测上表现优异，但在真实的长会话场景里，行为不可预测。

根本原因：单轮评测从未模拟过「需求在多轮中演化」这个真实场景。

2. 实验设计：8 轮需求演化链

研究者做了迄今最系统的多轮对话退化研究。核心设计：

  • 任务池：HumanEval+ / MBPP+ 任务
  • 改造方式：每轮需求有增量变化（例如第 3 轮要求修改 API 签名，第 5 轮引入并发约束），形成 8 轮需求演化链
  • 规模：542 任务 × 6 模型 × 8 轮 = 26016 个实例

这个规模的意义在于：它不是几个任务跑几遍的 sample，而是系统性的统计覆盖。

3. 核心发现：40%–73% 的任务在第 2–8 轮退化

关键数据：

  • 40%–73% 的任务在后续轮次丢失了早轮已满足的行为
  • 主要失效机制不是「写不出」，而是 Cross-Turn Conflict——后轮代码与早轮隐含需求冲突，早轮行为被悄悄破坏
  • HumanEval Pass@1 与多轮需求保留率之间几乎没有相关性

第三点尤其反直觉：你在 HumanEval 上拿 95 分，不意味着你在 8 轮 Cursor 会话里能保持 95 分的质量。单轮高分严重高估了可靠性。

3.1 Cross-Turn Conflict 的本质

「改坏之前对的」背后是一个信息传递失效问题：

  • 第 1 轮：Agent 写了一个功能，满足了需求 A
  • 第 3 轮：用户提出新需求 B，Agent 在满足 B 的过程中修改了某个共享模块
  • 第 5 轮：这个修改破坏了第 1 轮满足的隐含需求 A（因为 A 依赖于那个被修改的模块，但 Agent 不知道这个依赖）

问题不在于「健忘」，而在于早轮需求的隐含假设没有在上下文中被显式追踪。

4. Verification Gate：唯一有效的缓解

研究测试了多种缓解策略：

  • 结构化提示（让 Agent 显式追踪早轮需求）
  • 需求锚定（每轮开头重述之前的需求）
  • 任务分解（把多轮拆成更小的单轮）
  • Verification Gate（拿新代码跑早轮测试，失败则回滚重试）

唯一稳定有效的是 Verification Gate。

原理朴素到几乎不值一提：

在接受新代码之前，先用新代码跑早轮的测试用例。失败则回滚重试，而不是继续往前改。

DeepSeek-V3 应用 Verification Gate 后，末轮质量从 75.8% → 87.9%。12 个百分点的提升，来源是一个大多数工程师认为「理所当然」的动作。

5. 对 Vibe Coding 的重新定性

Vibe Coding 的核心主张是「让 Flow 持续，不要打断」。这个主张本身没错——频繁中断会破坏创造性流状态。

但它有一个隐含前提：Flow 不会悄悄破坏之前完成的东西。

如果 40%–73% 的任务会在第 2–8 轮退化，「不要打断 Flow」本质上是在积累技术债，而不是在加速。

正确的表述应该是：Vibe Coding + Verification Gate，而不是 Vibe Coding 单独成立。

6. 评测基准的范式转移

这篇论文最重要的贡献可能是揭示了 Pass@1 作为评测指标的破产。

真正需要的新指标：

  • 需求保留率（Requirement Retention Rate）：多轮对话后，原有需求被满足的比例
  • 回归密度（Regression Density）：每轮引入的回归数量
  • 冲突发现延迟（Conflict Discovery Latency）：从冲突产生到被发现的时间

这三个指标还没有成为行业标准，但它们比 Pass@1 更能预测真实场景中的可靠性。

7. 可落地动作

  • 在 Cursor/Windsurf 设置「每轮提交前回跑历史测试」的习惯锚点
  • 自测练习：选一个 8 轮以上的历史会话，统计末轮 vs 首轮的需求保留率（人工即可）
  • 储备提示词模板：「请在修改前先跑原有测试，确认不破坏后再提交」

参考文献

  • Regression Accumulation in Multi-Turn LLM Programming Conversations. arXiv:2607.01855. https://arxiv.org/html/2607.01855