夜雨聆风背景：一个讨论了很久的问题
我们在做 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 是主角，还是配角？
| 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 驱动的工作流"。
决定一个产品好坏的应该不是聊天机器人做得有多拟人、有多丝滑，而是系统能不能像一个靠谱的专业员工一样，稳定交付、合规控险~
