什么时候该用结构化表单追问，什么时候一句话就够了

如果你在和 AI 助理协作，并不是每次信息不够都该弹出一个表单。先说结论：缺的是 2 个及以上明确字段，或者用户需要在几个固定选项里做选择时，结构化表单通常更快；如果只缺 1 个开放式问题，直接追问一句自然语言往往更顺。好的 clarification 不是“尽量正式”，而是让补信息这一步刚好够用。

这也是 GoWork 和普通聊天机器人的一个重要区别。执行型助理不仅要“听懂”，还要继续创建任务、修改计划、发布内容或推进流程。一旦缺失信息本身已经是字段化的，继续靠一来一回的聊天去补，就会把简单参数采集做成低效往返；但如果问题本身是开放判断，把它硬做成表单，又会把一次自然沟通做得很僵。

如果你已经看过 Web 对话里什么时候该用表单追问和追问之前先回忆：什么时候该读记忆，什么时候才该向用户补问题，这篇文章讨论的是更靠前的一道决策：当系统已经确认需要追问时，接下来到底该给用户一个结构化表单，还是只问一句话？ 这也是 OmniGoAI 的 GoWork 在设计 clarification 体验时最常见的分界线之一。

先给结论：表单收字段，聊天补意图

最短可以记成一句话：能类型化的缺口，用表单；需要用户补想法的缺口，用聊天。

这里的“字段”通常有几个特点：

名称明确，比如日期、时间、数量、平台、模式；
类型稳定，比如 date、time、number、select；
填完后系统就可以继续执行；
不需要用户写一整段背景说明。

而更适合自然语言追问的问题，通常长这样：

“你说的‘跟进一下’是提醒我你，还是让我自动继续做？”
“这次你更看重速度还是准确性？”
“你说的‘那个任务’具体指哪一个？”

这类问题的关键不在字段，而在解释当前意图。如果问题本身就是开放式判断，做成表单反而会让用户先适应控件，再想答案，体验比一句追问更重。

为什么这不是“要不要更正式”，而是“要不要减少往返”？

很多人第一次看到结构化 clarification，会以为它只是更产品化的交互皮肤。其实它真正解决的是往返次数。

想象一个常见场景：用户说“帮我建个提醒”。系统此时可能还缺：

日期；
时间；
一次性还是重复；
提醒文案。

如果全靠聊天逐个问，常见过程会变成：

你想哪天提醒？
明天下午。
具体几点？
三点。
一次性还是每天？
一次性。
提醒文案写什么？

这类场景的问题不在于“信息多”，而在于信息天然就是几个独立字段。 一旦字段稳定，Web 里的结构化表单就能把四轮来回压成一次提交。对于执行型系统来说，这种压缩不只是省时间，也是在降低歧义和误填概率。

什么时候最适合用结构化表单？

一个简单判断法是：如果下面四条里命中两条以上，通常就值得上表单。

1. 缺少 2 个及以上明确字段

这是最常见也最稳的门槛。

例如：

提醒任务缺日期和时间；
发文任务缺平台和发布模式；
导出报表缺开始日期、结束日期和格式。

只缺一个字段时，自然语言通常更轻；一旦缺多个字段，表单的固定成本很快会被节省的往返摊薄。

2. 缺失信息本来就有明确类型

典型例子包括：

日期；
时间；
数字；
单选项；
多选项；
checkbox。

这些输入天然适合表单，因为用户看到控件就知道系统期待什么答案，不必猜“应该怎么说才会被理解”。

3. 选项范围是已知的

如果问题本质上是“从支持的几个值里选一个”，表单通常比开放提问更自然。

例如：

recurrence 是 once / daily / weekly；
发布模式是 draft / publish；
通知范围是当前会话 / 全局 / 静默后台。

如果继续用自然语言问，用户仍然得自己猜系统支持哪些值。表单把边界直接摆出来，能少掉很多无效答案。

4. 填完之后系统就能立刻继续执行

表单最擅长的不是帮用户“想”，而是帮用户把已经想好的参数一次性交代清楚。

如果用户填完几个字段后，GoWork 就能立刻创建提醒、生成计划、启动任务或发起发布动作，这通常就是一个很好的表单场景。

什么时候不该用表单，而该直接问一句？

很多失败的追问，并不是系统没表单，而是本来该聊天的地方硬上了表单。

1. 只缺 1 个开放式问题

例如：

“你是要我继续执行，还是只提醒你一下？”
“这里说的‘这个平台’是知乎还是掘金？”
“你更想要简洁版还是详细版？”

这些问题不是多字段采集，而是补一句意图。一句自然语言通常比打开表单更顺。

2. 系统自己还没把问题建模清楚

如果助手只知道“信息不够”，但自己都还没判断清楚到底缺哪几个稳定字段，这时上表单往往是在把建模压力转嫁给用户。

比如用户说“帮我安排一下下周内容”，系统甚至还没判断这是提醒、日历、选题计划还是发布排期，就先甩一个表单让用户填日期、平台、标题、备注。这不是高效，而是过早结构化。

更好的做法通常是先问一句开放问题，把任务形状问清楚，再决定后面是否值得用表单一次性收字段。

3. 用户需要表达偏好、背景或取舍

例如：

“这次你最在意速度、准确性还是成本？”
“有哪些平台这次不要发，为什么？”
“你为什么想把时间改到这个点？”

这类回答通常带原因、背景和取舍。表单能收参数，但不擅长收动机。

一个好用的判断法：先看字段数，再看问题形状

如果你想快速判断该用哪种 clarification，可以先问自己两个问题。

问题 1：现在缺的是几个明确字段？

0 到 1 个：优先自然语言；
2 个及以上：优先考虑表单。

这不是绝对规则，但已经能覆盖绝大多数执行场景。

问题 2：这些缺失信息能不能被可靠地类型化？

如果能清楚映射成日期、时间、数字、单选、多选，表单通常值得；
如果答案更像解释、判断或背景描述，继续聊天更合适。

把这两个问题连起来，基本就能避免两类常见错误：

明明是多字段采集，却还在一轮轮聊天追问；
明明是开放式澄清，却被硬塞进字段表单。

为什么“两个及以上字段”是一个实用分界线？

因为从一个字段到多个字段，交互成本结构会出现明显拐点。

只缺一个字段时，表单会带来这些额外成本：

渲染一个表单；
让用户切到填写模式；
再点一次提交。

但当缺的是两个、三个、四个字段时，成本结构会反过来。此时如果还继续聊天，用户要不断等待、回答、再等待。字段一多，表单的固定成本会很快被减少的往返抵消。

所以“两个及以上字段”不是一个任意拍脑袋的产品规则，而是一个很实用的协作断点。

哪些 GoWork 场景最适合结构化表单？

在 GoWork 里，下面几类任务尤其适合上表单。

1. 提醒和定时任务

常见缺口包括：

日期；
时间；
recurrence；
提醒文案；
通知范围。

这类字段天然结构化，而且一旦收齐，系统通常就能直接创建任务。

2. 带多个明确参数的执行请求

例如：

导出报表需要时间范围和导出格式；
发布任务需要目标平台和发布模式；
搜索或过滤需要关键词、范围和结果上限。

3. 字段填错会导致结果明显不同的任务

例如：

日期错一天，提醒就失去意义；
草稿和正式发布，影响完全不同；
7 天报表和 30 天报表，结果会明显变化。

这类任务的问题不只是“缺信息”，而是“字段不准会直接改变执行结果”。 表单能把这种风险显式化。

为什么 IM 渠道不能简单照搬 Web 表单？

这个边界也很重要。

Web 对话可以渲染原生表单，所以结构化 clarification 的体验完整；但钉钉、飞书、Telegram、微信这类 IM 渠道通常没有同样的表单承载能力。此时更合适的做法通常是：

继续用自然语言；
如果必须一次问多个字段，就发编号问题列表。

所以原则不是“表单越多越好”，而是：当渠道支持、字段足够明确、且一次收齐确实能减少往返时用表单；否则就继续像人一样问一句清楚的话。

常见问题

只有一个字段缺失时，表单一定不该用吗？

不一定，但默认不值得。只有当这个字段本身特别容易误填、或者必须强约束输入类型时，单字段表单才可能有价值。大多数情况下，一句自然语言更轻。

为什么执行型助手比聊天机器人更需要区分这条边界？

因为执行型助手不是只负责回答，还要继续创建任务、改计划、发内容或跑工具。追问方式选错，不只是聊天变慢，而是会直接拖慢后续执行。

结构化表单是不是比自然语言更“专业”？

不是。更专业的标准不是更正式，而是更合适。缺字段时表单更专业；缺意图时，一句自然语言反而更专业。

如果问题里既有字段，又有开放式判断怎么办？

通常先用一句开放问题把任务形状问清，再决定是否进入表单。先把开放判断压清楚，再收字段，效果通常比一上来就混合表单更好。

如果你在设计一个会执行任务的 AI 助理，clarification 的关键从来都不是“问得多正式”，而是系统有没有用对追问形状。当缺口是字段时，结构化表单能显著减少往返；当缺口是意图、偏好或判断时，一句自然语言往往更像一个真正会协作的人。想继续看这条边界在产品里如何落地，可以从 GoWork 开始： https://omnigoai.com/zh/download/gowork/