AI 代码越来越强，为什么项目还是做歪？Opus 5 连需求都漏掉 27%

结论

Datafruit 在 2026 年 8 月 24 日发布 Requirements Discovery Benchmark，用模拟自真实企业实施项目的多轮会议记录，测试 Agent 能否整理出最终业务需求。表现最好的 Claude Opus 5 找回了 73.1% 的标准需求，仍漏掉约 26.9%；它同时输出了大量额外判断，去重后的 Precision 只有 22.4%。

这不等于 Opus 5 只有 22.4% 正确率，也不能证明某个模型“不会听人话”。两个指标测的是不同风险：Recall 看漏了多少，去重 Precision 看新增的独立主张中有多少能与标准答案匹配。Opus 5 选择多找、多写，GPT-5.6 Terra 更保守，却只找回 37.3% 的标准需求。

这组结果真正提醒 Coding Agent 用户：代码生成之前的需求发现，仍然是工作流里最薄弱的一段。模型可以把错误理解实现得非常漂亮。重要任务最好先经过澄清、规格确认和验收标准，再允许 Agent 修改代码。

最强模型，还是漏掉了四分之一需求

Datafruit 测的不是算法题。每个任务都包含一组 discovery meeting transcripts，模拟客户、顾问和实施团队在多次会议里逐步谈清一个软件项目。

里面故意放进三类现实麻烦：讨论过但后来否决的方案；必须结合多次谈话才能推断的隐含需求；以及客户嘴上要 A、平台经验却表明应该做 B 的“Do what I mean”场景。

Agent 要在 Bash 工作区里阅读这些材料，最后交出结构化的 requirements.json。各模型的平均 Recall 如下：

| 模型 | 标准需求 Recall | | --- | ---: | | Claude Opus 5 | 73.1% | | Claude Fable 5 | 65.2% | | Kimi K3 | 59.1% | | GPT-5.6 Sol | 55.0% | | GLM 5.2 | 52.0% | | Claude Sonnet 5 | 49.6% | | DeepSeek V4 Pro | 45.9% | | GPT-5.6 Terra | 37.3% | | GPT-5.6 Luna | 33.8% |

Opus 5 明显领先，但 73.1% 的另一面仍是：平均每四条真正需求，就有一条以上没有被完整找回。后续编码、测试和部署能力再强，也无法自动补回一开始没有进入规格的东西。

第一个反转：听得最多，也脑补得最多

只看 Recall，Opus 5 是冠军。Datafruit 再看去重后的 Precision，排序却翻了过来：Terra 为 36.7%，Sol 为 32.7%，Sonnet 5 为 32.5%，Opus 5 则为 22.4%。

原因不难理解。Opus 5 平均输出的需求数量相当于标准需求的 1.88 倍。它宁愿多抓一些可能有用的线索，也不愿轻易漏掉；代价是把推断、展开或讨论中的想法写成更多独立主张。

Terra 的路线相反。它输出量接近标准答案，额外主张少一些，因此去重 Precision 最高；但它只找回 37.3% 的标准需求。

所以这场测试没有一个可以闭眼选的赢家。Opus 的风险是范围膨胀，Terra 的风险是需求缺失。真实项目需要的不是单独追求一个分数，而是先高召回地收集候选，再让人确认哪些需求有效、哪些只是猜测。

真正难的，是客户没有明说的部分

Datafruit 还把需求分成 explicit 和 implicit。Opus 5 对明确需求的 Recall 达到 91.1%，对隐含需求则降到 68.9%。其他模型也出现相同落差，隐含需求比明确需求低 24.4 至 44.6 个百分点。

这很接近真实软件项目。客户通常不会直接说“请加入幂等键并处理 webhook 重试”，他更可能说“订单偶尔会重复”。工程师要把业务现象翻译成数据、权限、并发、异常和验收条件。

Agent 读懂一句明确指令已经越来越强。它能否从分散信息里发现矛盾、承认不确定，并提出刚好能消除歧义的问题，仍是另一种能力。

更多工具，没有自动带来业务判断

Datafruit 还用 Opus 比较了一次性 Prompt 和 Coding Agent 式 Harness。一次调用的 Recall 是 67.9%，Agent Harness 提升到 73.1%；去重 Precision 却几乎不变，分别是 22.6% 和 22.4%。

工具让模型读更多文件、维持更长流程，也确实找回了更多需求。但“哪些讨论最终算正式需求”仍然是判断问题，不会因为多了 Bash、文件搜索和长上下文就自然解决。

这也是为什么 Coding Benchmark 的进步不能直接等同于完整的软件交付能力。SWE-bench 测修复，Terminal-Bench 测终端工作；需求发现发生在这些动作之前。

另一项研究发现：Agent 信息不够时，常常直接猜

ICLR 2026 的 AMBIG-SWE 从真实软件工程任务中制造信息不完整的版本，专门测试 Agent 能否发现歧义、提出问题，再把回答用于修复。论文报告，在部分实验设置下，允许交互澄清可让成功率相对不交互版本最高提升 74%。

这里的“最高”很重要：它不是所有模型、所有任务的统一增幅。但两项研究指向同一个工作流缺口。模型并非总是完全做不了；它有时只是没有停下来确认自己是否理解正确。

Anthropic 的 40 万次会话说明，人仍在决定“做什么”

Anthropic 对约 40 万个 Claude Code 会话的隐私保护分析也给出了相似背景。在典型会话中，人类作出约 70% 的规划决策，Claude 作出大部分执行决策。用户在具体任务上的领域经验越强，Claude 每次收到指令后通常能独立完成更多动作。

这不意味着新人不能使用 Coding Agent。它说明当前分工仍很清楚：模型擅长搜索、编辑、运行和迭代；人需要提供目标、边界、业务规则和判断标准。

同一个 Agent 在资深用户手里显得更可靠，未必因为 Prompt 更花哨，而是对方更早指出了什么不能改、什么必须兼容，以及怎样才算完成。

现在就能改的工作流：前十分钟禁止写代码

遇到跨页面、跨服务、涉及权限或业务规则的任务，可以先让 Agent 只做需求发现：

1. 用自己的话复述目标、用户和当前痛点；
2. 把已确认事实、合理推断和未知项分开；
3. 列出会改变实现方案的最少数量澄清问题；
4. 写出范围内与范围外事项；
5. 给出可以验证的验收标准；
6. 等人确认规格后，才允许修改代码。

可以把下面这段放进项目的 AGENTS.md 或 CLAUDE.md：

如果缺失信息会影响数据结构、权限、兼容性、外部接口或验收结果，不要自行选择一个假设并开始实现。先检查仓库和已有文档；仍有多个合理方案时，提出最少数量的关键问题。动手前，用自己的话复述目标、约束、范围外事项和验收标准，并标出所有暂定假设。

它不会让 Agent 突然拥有高级顾问的业务经验，但能减少一种代价很高的失败：沿着错误理解连续工作一小时。

我们的判断

Datafruit 的新 Benchmark 很有价值，因为它把“AI 做出来了，但不是我要的”变成了可测量问题。最好的模型仍在漏需求与加需求之间艰难取舍，说明软件 Agent 的瓶颈正在从单纯执行转向人与模型怎样共同定义问题。

不过它仍是 Datafruit 自建评测。会议文本由内部匿名实施数据衍生并通过生成流程构造，标准需求和 LLM verifier 也由团队设计。Datafruit 做了人工检查、gold replay 和重复评分稳定性测试，但目前没有外部团队的大规模复现。

因此，73.1% 不能当成 Opus 5 在所有客户项目里的固定“听懂率”。更稳妥的结论是：在这套接近实施咨询的任务设计里，前沿模型也没有稳定完成需求发现；而且不同模型会以完全不同的方式失败。

仍然要观察

• 外部团队能否在真实、未经生成的会议记录上复现这些差距；
• 允许 Agent 主动向客户提问后，Recall 和 Precision 能否同时提高；
• 两阶段流程“候选需求提取 + 人工确认”能否显著减少返工；
• 不同模型在权限、安全、合规与异常流程上的隐含需求表现；
• 需求发现分数能否预测最后的软件交付成功率。

来源与证据边界

• 一手 Benchmark：Datafruit《Evaluating Agents on Requirements Discovery》，2026 年 8 月 24 日
• 同行评审论文：AMBIG-SWE，ICLR 2026
• 一手使用研究：Anthropic《Agentic coding and persistent returns to expertise》，约 40 万次 Claude Code 会话

本文中的 73.1%、22.4% 和 37.3% 来自 Datafruit 自建 Benchmark，不是整个行业的通用准确率。AMBIG-SWE 的 74% 是部分设置下的最高相对提升，不应推广到所有 Coding Agent。