AI Native 产品设计 | AI 追问该放哪?B 端产品设计的一个核心判断

背景：一个讨论了很久的问题

我们在做 AI 产品时，为一个交互细节讨论了很久。

当 AI 处理复杂任务、需要用户补充信息或做分支选择时，这个追问交互到底该放在哪？

• 放在聊天对话流里？
• 在对话框上方弹出一个轻量浮层？
• 还是做成表单或配置面板？

三种方案，三种逻辑。后来我们拿一个真实业务场景去推演，才发现这表面上是 UI 布局问题，本质上是一个产品定位问题：

我们到底是在做一个"聊天共创工具"，还是在做一个"严肃的任务型业务系统"？

01

一、从一个真实场景说起：AI 处理报告到一半，卡住了

用户在系统里输入了一句明确的任务指令：

"写一份《企业经营项目调研》的 Markdown 报告，放到工作台打开。不确定的让我先选择。"

AI 开始后台检索数据、构建大纲，但在生成中途踩到了一个无法跳过的合规问题：

部分调研数据不完整，口径不统一。系统必须停下来问用户：遇到不确定的信息，你希望怎么处理？

• 选项 A：标注待确认
   — 明确标出"待确认/假设"，不编造事实
• 选项 B：给出假设
   — 基于常见口径给出合规假设，AI 继续往下写

为了完成这个确认，界面上甚至弹出了一个带有单选框、补充说明输入框、上一步/确定按钮的多步骤结构化卡片。

面对这个场景，团队里有人提出：学 Claude，把它做成悬浮在对话框上方的轻量浮层，体验更丝滑。

但我们讨论后认为，这类业务确认卡片更应该留在对话流内，而不是悬浮在对话框上方。 原因要从两种产品的本质差异说起。

02

二、为什么大家都想学 Claude 的浮层追问？

Claude 在运行某些任务时，会在输入框上方弹出一个轻量浮层，让用户快速点选"文章风格"、"输出长度"或"格式类型"：

这种交互丝滑、克制，有一种"心流不被打断"的科技感。于是很多人形成了一个直觉："Chat-centric（以聊天为中心）的浮层追问，就是 AI 时代最先进的交互范式。"

但这个直觉是有条件的，接下来我们看看具体的场景。

03

三、浮层追问的暗坑：B 端用户会很崩溃

想象一下，把浮层追问完整复制到一个需要严谨交付的企业后台：

用户点击"生成企业经营报告"，满心期待系统自动运转。

跑了 3 秒，弹出浮层："请选择报告语调：[ 商务 ] [ 严谨 ] [ 激进 ]"（点了）

又跑了 3 秒，再弹："请选择图表风格：[ 柱状图优先 ] [ 折线图优先 ]"（皱眉，点了）

接下来两分钟里，浮层一个接一个：

"数据源发生交叉，是否引入新闻舆情？"

"报告排版格式选择：[ 紧凑 ] [ 留白 ]"

"生成完毕，是否自动翻译成英文？"

这就是典型的"浮层追问"。用户连续点击了 5 次突如其来的弹窗，原本期待 AI 解放双手，结果变成了坐在屏幕前不停"伺候弹窗"的流水线工人。

问题的根源在于：Claude 是创作型工具，企业级 SaaS 是业务执行系统。两者的用户心理模型，存在非常大的区别。

04

四、核心差异：AI 是主角，还是配角？

在 B 端环境中，频繁的打断追问 ≈ 系统不够成熟。

如果 AI 做成了事事请示的弹窗狂魔，用户眼里它不是"高情商助手"，而是一个极度没有眼力见的实习生：

"老板，报告文件夹建好了，请问名字用黑体还是宋体？"

"老板，有家公司的数据没查到，我是空着还是编一个？"

"老板，这个段落间距您要 20 像素还是 24 像素？"

真正有经验的主管早就受不了了："你是专业系统，难道不能按行业标准和既定 SOP 推进吗？"

05

五、判断追问放在哪里的核心原则：一次性决策 vs 持续性状态

这是 B 端 AI 产品设计中最关键的一个分类框架：

一次性决策（Transient Decision）→ 放在聊天流内

持续性状态（Persistent State）→ 放在聊天流外（配置区）

什么是一次性决策？

只影响当次任务，是 AI 在特定上下文下的"异常分支处理"。

举例："本次项目调研，遇到不确定数据如何理？"（仅对这份报告生效）

→ 适合作为聊天流内的动态确认卡片。

什么是持续性状态？

全局偏好或长期配置，用户需要随时可见、随时修改、可复用。

举例：默认报告模板、合规风控红线、常用联网数据源

→ 适合放在顶部工具栏、左侧配置区、右侧参数面板。

06

六、为什么这类确认卡片更适合留在对话流内？

回到开头那个报告场景，我们推演了两种方案后，得出了明确的结论：业务型确认卡片应该留在对话流内，而不是做成悬浮在对话框上方的浮层。 原因有两点：

• 原因 1：浮层会遮挡上下文，决策依据断了

浮层弹出时会挡住 AI 之前的回复。用户在做决策时，往往需要看一眼 AI 推进到了哪个步骤、说了什么，浮层把这种视觉连续性切断了。留在对话流内的卡片，上下文始终可见，用户做选择时心里更有底。

• 原因 2：浮层确认后即消失，无法审计追溯

浮层交互一旦确认就消失，聊天记录里没有任何痕迹。但在严肃的 B 端业务中，审计痕迹（Audit Trail）极其重要。

两周后审计团队翻出这份报告，想知道："当时是谁、在什么情况下允许 AI 给出假设的？"如果用的是浮层，这条记录永远找不回来。

对话流内的卡片，既是交互入口，也是审计存证。这是浮层做不到的。

07

七、优化方案：对话流卡片怎么做得更好？

确认了"卡片留在对话流内"的方向后，现有设计还有可以优化的空间：

① 减少分步操作，让"一次点击"完成确认

AI 应尽量在后台对齐前置信息，在聊天流卡片中只暴露核心矛盾，而不是让用户像填多页问卷一样一路"下一步"。

② 确认后让卡片"坍缩"成历史存证（关键改变）

用户点击确定后，复杂的表单卡片不应维持原样停在时间线里，而应立刻收起，变成一段不可编辑的灰色历史记录：

用户决策完成后

这样既留下了审计凭证，又让聊天流保持干净。

写在最后：从"阻断追问"到"默认推进"

通用 AI 的本质是"聊天驱动配置" — 用户不知道自己要什么，通过对话慢慢摸索出规格。

行业 SaaS 的本质是"配置驱动执行" — 规则和 SOP 本就在那里，AI 只是在既定轨道上用自然语言加速推进。

B 端业务的核心，是 SOP 的数字化与合规化。 通用 AI 的聊天，是帮用户寻找 SOP；行业 SaaS 的配置，是让 AI 遵守 SOP。

未来真正成熟的 AI SaaS，不会是把所有东西都塞进一个无所不能的 Chat 框，而一定是"AI 驱动的工作流"。

决定一个产品好坏的应该不是聊天机器人做得有多拟人、有多丝滑，而是系统能不能像一个靠谱的专业员工一样，稳定交付、合规控险~