当 AI Coding 拿不到完整需求

假设你让 Agent 给订单列表增加一个导出功能。

它先问了文件格式、列顺序、按钮位置，整理出需求规格，再开始开发。代码写好了，测试也通过了。直到业务验收时，才发现：需要导出全部筛选结果，它却只导出了当前页。

整个过程有提问、有规格、有测试，仍然漏掉了决定功能行为的问题。

Agent 提出了问题，也可能没有发现最需要问的问题。

SDD（规格驱动开发）、Plan Mode，以及“先问清楚再开始”的协作方式，已经在处理需求澄清。本周值得关注的是，两项新研究进一步检验了这背后的能力：Agent 能否主动找到信息缺口，以及发现缺口后能否有效澄清。

当需求散落在资料和人的经验里

Sierra 在 9 月 8 日介绍的 Hyper-τ-bench，让编程 Agent 完成一项端到端任务：构建客服 Agent。

需求需要从企业资料和模拟客户的回答中还原。编程 Agent 要自行查找信息、设计架构、接入业务 API，交付的客服系统还要在成本预算内，通过它事先没见过的模拟任务。

研究者检查执行过程后发现，Agent 经常检索不充分、追问不足。在客户独自掌握二十多项需求的任务中，开发过程最多只提出了四个问题。

这里还涉及架构探索和成本配置等困难，不能把结果全部归因于需求澄清。但它展现了一个具体问题：即使资料可以查、客户可以问，Agent 也未必会充分利用这些信息。

知道哪里有问题，和自己发现问题

9 月 9 日提交的预印本 IdeaAMBIG，把这个问题拆得更细。

它关注科研方法的实现规格：描述是否充分，能否支持忠实实现，而不需要实现者自行补充关键假设。

评测分别考察模型自行定位缺口，以及在被告知缺口后提出澄清行动。在真实样本上，用于衡量找回已标注缺口的宏平均指标，最高为 9.6%；直接提供缺口信息后，澄清行动成功率最高为 80.6%。

两者任务和输入条件不同，不能理解为“多问几句，准确率就从 9.6% 提升到 80.6%”。研究揭示的是：在这个评测中，发现缺口比得知缺口后提出澄清行动更困难。

两项研究的场景不同。前者观察完整任务中的信息收集，后者单独检验规格缺口识别。它们共同提醒我们：提供提问工具、安排澄清步骤之后，还需要检查 Agent 实际发现了什么。

为什么有了 Spec，假设仍可能一路进入代码？

Claude Code 的官方最佳实践已经建议：较大功能先让 Agent 访谈用户，讨论边界情况和方案取舍，形成规格后再实施。

这些流程很有价值。不过，流程是否走完，与关键问题是否被发现，需要分别判断。

把研究中的发现带回日常研发，我们可以进一步考虑一种风险：Agent 可能把合理的猜测写成明确的规格，后续执行又不断强化这个猜测。

回到订单导出的例子。“只导出当前页”并非完全不合理，它实现简单，也可能符合某些产品的使用习惯。如果 Agent 没有意识到导出范围需要确认，就可能把它直接写进 Spec。

接下来，代码按当前页取数，测试验证导出条数等于当前页条数。文档、实现、测试彼此一致，却共同依赖一个未经业务确认的前提。

这是从研究延伸出的工程分析，并非两项评测直接验证的产品案例。它提示我们，审阅 Spec 时，除了检查表述是否明确，也要追问关键决定的依据。

测试通过可以证明代码符合已有断言。至于这些断言是否表达了业务需要，还需要其他证据。

让澄清留下可以检查的结果

沿着这个思路，改进流程可以先从几个具体问题入手。

首先，关键决定来自哪里？“导出全部筛选结果”是需求原文的明确要求、现有产品约定，还是 Agent 根据常见做法作出的推断？把这些来源区分开，人才能快速找到需要确认的地方。

其次，换一种解释，会改变什么？导出当前页和全部结果，会影响取数方式、数据量以及用户最终拿到的内容。这类不确定性值得优先处理。按钮间距等已有设计规范能够回答的问题，则可以先查资料，不必逐项打断用户。

最后，确认的答案怎样进入验收？如果业务明确需要全部筛选结果，就可以准备一个跨越多页的数据样例，验证导出是否完整。这个预期应来自已确认的规则，而不能仅仅照着实现生成。

这些做法无法保证发现所有遗漏，但能让澄清质量更容易被检查：哪些决定已有依据，哪些仍是假设，哪些已经通过具体样例得到确认。

需求也未必能在开工前一次说清。接入真实接口、运行现有系统时，还可能遇到新的冲突。此时同样需要判断，它是否改变了之前确认的业务规则，并把必要的问题重新带回讨论。

当 AI 能把 Spec 持续变成代码和测试，我们也需要看见：Spec 中那些决定软件行为的内容，究竟从何而来。