当助手说 Could you clarify
有一次用户只给了一个模糊指令，助手没有直接执行，而是问：“Could you clarify what you mean by login?” 它还举了例子：是登录某个服务，比如 AWS、gcloud、GitHub CLI，还是在项目里实现登录功能。这个回复看起来很普通，却很适合拿来观察 Agent 的判断链。
很多人看到这类澄清，会觉得 Agent 在拖延。其实更准确地说，它遇到了一个多义词，选择了低风险路径。login 这个词既可以是操作动作，也可以是功能模块，还可能是某个命令行工具的认证过程。如果上下文不足，直接执行就可能走错方向。
澄清不是失败，而是暴露分岔
“Could you clarify”最有价值的地方，是它把分岔点暴露出来了。用户原本可能只觉得自己说得很清楚，但 Agent 看到的是多个可能路径。它问清楚，并不一定是在逃避，而是在避免把错误理解推进到执行层。
当然，澄清也有质量高低。低质量澄清只是把问题推回给用户：“你想要什么？”高质量澄清会列出可能解释，让用户选择。素材里的助手至少给出了方向：登录服务，或者实现登录功能。这让用户能看到 Agent 为什么停下。
用户如果想继续提高协作质量，就不要只回答选项，而可以追问：“你为什么判断这里需要澄清？”这个问题会把对话从选项选择带到判断复盘。Agent 需要说明它发现了哪些不确定性，哪些上下文不足以消除歧义。
用户可以引导 Agent 先基于上下文推断
有些场景确实需要澄清，有些场景则可以先推断。关键在于用户要明确自己愿意承担哪种协作方式。如果用户希望 Agent 更主动，可以说：“请先基于上下文推断，并说明你的假设。”这样 Agent 就不会停在澄清句，而会给出一个可检查的判断。
这句话很有用，因为它同时给了 Agent 权限和约束。权限是可以推断，不必每次都等待确认；约束是必须说明假设，不能把推断伪装成事实。用户看到假设后，可以快速纠正方向。
在 login 这种词上，这个方法尤其适合。Agent 可以说：如果我们当前在讨论命令行工具，我会把它理解为登录服务；如果在讨论产品功能，我会理解为实现登录模块。这样用户不需要从零解释，只要确认哪条路径更接近。
判断链要把不确定性说出来
人类对模糊语言的容忍度很高，常常靠上下文自动补全。Agent 更倾向于降低误解风险，所以遇到多义词会请求澄清。两者没有谁绝对更好，关键是要让不确定性变得可见。
如果 Agent 不澄清，直接执行，用户可能要在错误结果后返工。如果 Agent 过度澄清，用户会觉得效率低。好的协作是在两者之间找到节奏：低风险时先推断，高风险时先确认；能列选项时列选项，不能列选项时说明缺少什么信息。
用户的提问方式会影响这个节奏。说“login”是模糊指令，说“在当前项目里实现登录功能”就明确很多；说“登录 GitHub CLI”又是另一条路径。如果用户暂时不想补细节，就让 Agent 明确假设。这样对话不会卡住，风险也不会被隐藏。
下次遇到澄清句怎么复用
我会把“Could you clarify”当成一个提示，而不是一个阻碍。看到它时，先问自己：这里是不是真的有多个解释？如果有，就让 Agent 列出分岔；如果没有，就把上下文补给它，或者要求它基于上下文推断。
也可以反过来训练 Agent：当你需要澄清时，请同时给出你看到的两到三个可能解释，并说明你倾向哪一个。这个要求能让澄清变得更有信息量。用户不再只是被动回答，而是在和 Agent 一起选择路径。
这次小卡点提醒我，人机协作的关键不是消灭模糊，而是管理模糊。模糊指令不可避免，尤其在真实工作里，用户常常不会一开始就把所有背景说完整。Agent 的价值不是机械追问，也不是盲目执行，而是在不确定处把判断链展开。
所以下次助手说“Could you clarify”时，我不会马上觉得它没懂。我会先看它有没有把分岔说清楚，再决定是补充上下文，还是让它带着假设继续。澄清句背后，其实是一次选择协作节奏的机会。
把澄清变成可复用约定
如果一个团队经常和 Agent 协作，可以提前约定澄清规则。比如遇到低风险歧义时，Agent 先给出默认推断；遇到会写文件、登录服务、修改配置这类高风险动作时，必须先澄清。这样用户不会被无意义的追问打断，Agent 也不会在关键地方擅自行动。
这个约定比单次提示更有价值。它把“你为什么又问我”变成“我们约定什么时候需要确认”。用户的耐心会变好，Agent 的判断也会更稳定。login 这个例子提醒我们，模糊词并不可怕，可怕的是双方没有约定如何处理模糊。只要规则清楚，澄清就不再是阻塞，而是协作里的安全阀。