Web 对话里什么时候该用表单追问

如果你在 Web 对话里让 GoWork 继续做事，助手并不是每次都应该追问一串自由文本问题。先说结论：当缺的是 2 个及以上明确字段，或者用户需要在几个固定选项里做选择时，用结构化表单追问通常更快、更不容易填错；如果只缺 1 个开放问题，直接问一句自然语言往往更顺。真正的边界不在“是不是要追问”，而在缺失信息是否足够结构化、是否值得一次性收齐。

这也是 GoWork 和很多聊天式助手的差别之一。普通聊天机器人常把所有补充信息都变成来回对话，但执行型助手在真正动手前，往往需要把日期、时间、数量、平台、范围、对象这些字段收准。一旦问题本身已经是结构化的，继续靠自由文本一轮轮来回补，就会把原本简单的参数采集变成低效的往返。

如果你已经看过自动同意模式不等于无限权限和定时任务跑完后怎么回报结果，这篇文章讲的是执行前的另一个高频边界：什么时候该继续像聊天一样追问，什么时候该切换成一次性可填写的结构化 clarification 表单？

先给结论：表单适合“缺字段”，自然语言适合“缺想法”

最短可以记成两句话：

缺的是字段，用表单；
缺的是想法、背景或判断，用自然语言追问。

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

可以明确命名；
有确定的数据类型，例如日期、时间、数量、单选；
填完之后，助手就可以直接继续执行；
不需要用户长篇解释上下文。

而“想法、背景或判断”往往是另一类问题，比如：

“你更偏向哪个方向？”
“这次最重要的目标是什么？”
“你说的‘弄一下’具体是想发布、保存草稿，还是只先整理内容？”

这类问题的答案不是一个表单字段能压缩清楚的。如果问题本身是开放式判断，把它硬做成表单，只会让用户先适应表单，再想答案，反而更慢。

为什么 Web 对话里的表单不是“更正式”，而是“更少往返”？

很多人第一次看到结构化表单，会以为这只是更“产品化”的交互皮肤。其实它真正解决的是往返成本。

想象一个典型场景：用户说“帮我建个提醒”。如果此时缺的是下面这些信息：

哪一天；
几点；
一次性还是每天；
提醒文案。

如果全靠自然语言逐条问，常见展开会是：

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

同样的事情，在 Web 里完全可以一次性用表单收齐。当字段本来就稳定且有限，表单的价值是把 4 次来回压缩成 1 次提交。

这不仅省时间，也减少歧义。日期字段不容易漏年，时间字段不容易出现“今晚”“晚点”这种相对表达，单选项也能把可选范围直接亮出来。

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

一个实用判断法是：同时满足下面任意两条，通常就值得上表单。

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

这是最常见的触发条件。

例如：

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

只缺一个字段时，自然语言通常更轻；一旦缺多个字段，表单往往更省总成本。

2. 字段类型本来就明确

例如：

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

这些内容天然适合结构化收集，因为用户看到控件就知道系统期待什么输入，不必再猜“要怎么表述才会被理解”。

3. 选项范围是已知的

如果问题本质上是“在 A/B/C 中选一个”，那表单比开放式追问更自然。

比如：

recurrence 是 once / daily / weekly；
发布模式是草稿 / 正式发布；
渠道是当前会话 / 全局 / 静默后台。

这类问题如果继续用自然语言问，用户依然得自己猜系统支持哪些值。表单把边界直接摊开，减少无效答案。

4. 填完就能继续执行，不需要额外解释

表单最擅长的不是“帮助用户思考”，而是“在用户已经知道自己要什么时，一次性交代清楚”。

如果填完几个字段，助手就能立刻创建任务、开始发布、生成计划，那就是典型的表单场景。

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

很多失败的交互，并不是因为没表单，而是因为该聊天时却上了表单。

下面这些情况通常更适合自然语言：

1. 只缺一个开放问题

例如：

“你说的‘跟进一下’具体是想提醒，还是想让我自动继续执行？”
“你更想要简洁版，还是详细版？”
“这里的‘这个任务’指的是哪一个？”

这些问题不是多字段采集，而是让用户补一句意图。直接问一句最自然。

2. 助手自己还没把问题想清楚

如果助手只知道“信息不够”，但并不知道到底缺哪几个稳定字段，这时上表单通常会把不确定性转嫁给用户。

例如一个糟糕的做法是：用户说“帮我安排一下下周的内容”，助手自己都还没判断是排提醒、建日历、做选题，结果先甩一个表单要用户填日期、平台、标题、描述。这不是高效，是在问题尚未建模完成时过早结构化。

更好的做法通常是先问一句开放问题，把任务类型问清，再决定后面是否需要表单。

3. 用户需要表达偏好、背景或约束

例如：

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

这些回答往往带原因、上下文和取舍，不适合压成几个控件。表单可以收参数，但不擅长收动机。

一个简单判断法：先看“字段数”，再看“问题形状”

如果你想快速判断是否该用表单，可以先问自己两个问题。

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

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

这不是绝对规则，但已经能覆盖大部分场景。

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

如果能清楚地定义成日期、时间、数字、单选、多选，表单通常值得；
如果答案更像解释、判断、描述，继续自然语言更合适。

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

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

为什么“缺两个字段”是一个特别关键的分界线？

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

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

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

但当缺的是两个、三个、四个字段时，成本结构反过来了。此时如果还用自然语言追问，用户要不断等待、回答、再等待。字段一多，表单的固定成本就会被往返节省迅速摊薄。

所以“两个及以上字段”不是随意拍脑袋的门槛，而是一个很实用的交互拐点。

表单最适合哪些 GoWork 场景？

在 GoWork 里，下面几类任务特别适合结构化 clarification 表单。

1. 提醒和定时任务

例如缺：

日期；
时间；
recurrence；
提醒文案；
是否只提醒当前会话。

这类字段天然结构化，而且填完就能直接创建任务。

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

例如：

导出报表时要时间范围 + 格式；
发文时要平台 + 模式 + 标题；
搜索或过滤时要关键词 + 范围 + 上限数量。

3. 必须一次性收准，否则后续结果差异很大的任务

比如：

日期填错一天，提醒意义就变了；
发布模式从草稿变正式发布，影响就完全不同；
时间范围从 7 天到 30 天，报表结果会显著变化。

这类任务的问题不只是“缺信息”，而是“字段不准会导致实质不同结果”。 表单能把这种风险显式化。

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

这是另一个容易忽略的边界。

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

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

所以这里的原则不是“所有地方都优先表单”，而是：Web 里有表单能力时要用好它；没有表单能力的渠道，就用最接近结构化的自然语言方式。

最容易踩的三个误区

误区 1：只要缺信息，就上表单

不对。只缺一个开放问题时，表单通常比聊天更重。

误区 2：字段多就一定要复杂表单

也不对。字段虽然多，但如果其中大半仍然是开放描述，说明问题本身还没被建模清楚，应该先聊天再结构化。

误区 3：把表单当成“更正式”的追问方式

表单不是为了显得专业，而是为了减少往返、减少误填、减少歧义。如果它没有带来这三件事，表单就很可能用错了。

常见问题

FAQ 1：只缺两个字段，就一定要上表单吗？

不一定，但通常值得优先考虑。尤其当这两个字段都有明确类型，例如日期和时间、平台和模式时，表单往往比两轮自然语言追问更顺。

FAQ 2：为什么只缺一个开放问题时不建议用表单？

因为用户还要切换到填写模式，再点提交，而这个收益通常不如直接回一句话来得大。开放问题的最佳交互通常还是开放回答。

FAQ 3：什么叫“字段”，什么叫“想法”？

字段通常是可以命名、类型明确、填完即可执行的参数；想法更像偏好、背景、判断或解释。前者适合表单，后者更适合自然语言。

FAQ 4：Web 表单最大的价值是什么？

不是看起来更整齐，而是一次性把多个明确字段收齐，减少往返、减少歧义，并让后续执行可以直接开始。

如果你希望 GoWork 的追问既不拖沓，也不把开放问题做得像办手续，关键不是“默认都用表单”或“永远只靠聊天”，而是先分清楚现在缺的是字段，还是缺想法。字段型缺口就一次性结构化收齐；开放型缺口就直接自然地问一句。想继续理解 GoWork 如何处理执行边界与对话澄清，可以继续看自动同意模式不等于无限权限、定时任务跑完后怎么回报结果和 GoWork 下载页。