根据回答决定下一步

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

用户要求导出用户数据，但没有明确字段和目的位置。教学现有接口支持 id、email、phone；列存在不能说明用户想导出全部数据。你可以先检查接口能力，再解决会改变导出行为的意图缺口。

具体做法

先读取现有接口和已提供要求，避免询问能自行发现的事实。把仍缺的字段、范围与目标位置整理成简短问题，等待必要答案；同时继续不依赖答案的接口核对。收到回答后更新任务理解并沿选定分支推进，已有答案直接复用，不重新确认同一信息。

反例

因为接口支持 id/email/phone，就把全部用户字段导出到 users.json。目的位置与范围缺失也不影响执行。

改进写法

先检查上述接口能力与既有请求。字段和目的位置仍未指定，集中询问导出哪些字段、哪些记录及保存到哪里，等待这些会决定数据范围的回答。期间可核对接口格式和错误处理，不执行导出。若用户已有明确答案则复用；回答后按选定范围准备输出，不把支持字段当默认全量授权。

为什么这样改

接口事实解决“能做什么”，用户回答解决“要做什么”。让必要问题控制下一行动，避免因为一个 API 支持更多字段就多导出，也避免反复询问已经明确的选择。

如何验证

教学回答若为“只导 id，当前筛选结果，保存到本地指定目录”，后续计划只含这些条件；未回答时状态仍是范围待明确，接口检查可以继续。

检查没有猜目标、没有包含未选 email/phone，也没有把等待时间当答案。这里未读取或导出真实用户数据。

适用边界

不需要为每个任务凑固定问题数，明确任务可直接推进。提问是补信息，不是对已授权工作重复索要许可；涉及数据范围的关键未知不能被便利默认值抹掉。