# AR12 — 对话驱动与结构化交互架构

> 状态：架构讨论点 + 后续 Workbench 交互约束来源
> 最后更新：2026-09-23
>
> 关联文档：
> - `AR02_前端架构.md`
> - `AR05_工作台架构约定.md`
> - `docs/01_System_Overall/SY22_角色技能应用统一任务架构.md`

---

## 1. 背景

EAI 平台当前正在从传统页面式软件，转向“主对话入口 + 任务上下文 + 对象挂载”的新工作台形态。

这个转向带来一个新的核心问题：

**用户应该通过自然语言持续推进任务，还是在关键节点切换到结构化 UI 做选择。**

这个问题不是前端组件样式问题，而是下一代 AI 驱动软件的主交互范式问题。

如果这条架构判断不明确，后续专员、技能、xApp、右栏工作流、操作按钮都会出现各自实现、口径分裂的问题。

---

## 2. 问题定义

对话驱动式工作方式有明确优势：

1. 用户可以一句话启动任务
2. 用户不必先理解系统表单结构
3. 用户可以用自然语言表达模糊目标
4. AI 可以在早期帮助补全需求

对话驱动式工作方式也有明确缺点：

1. 信息天然按时间线滚动，分叉选择容易被淹没
2. 用户很难判断系统是在“建议”，还是已经“替用户决定”
3. 关键状态与可选项不够显式，可控性下降
4. 过程虽然看起来流畅，但审计性、回退性、对比性不足

传统 UI 的优劣恰好相反：

1. 它强在并列展示、状态显式、可比较、可回退
2. 它弱在启动成本高、表单感强、难以承接模糊需求

因此，EAI 不应在“纯对话”与“纯页面表单”之间二选一。

---

## 3. 架构结论

EAI 的正式交互结论是：

**系统采用“对话发起 + 结构化决策接管 + 对话继续推进”的混合交互架构。**

换句话说：

1. **对话**负责表达目标、补充上下文、提出修改意见
2. **结构化 UI**负责承接关键分叉、显式展示备选项、确认后果
3. **工作流状态面板**负责持续展示当前阶段、可回退点、执行结果

这不是“聊天框旁边加几个按钮”。

这是把 AI 软件拆成三层协作：

1. **对话层**：负责意图生成
2. **决策层**：负责关键节点接管
3. **执行层**：负责自动推进与结果回写

---

## 4. 交互分层原则

### 4.1 对话适用的阶段

以下阶段优先使用对话：

1. 用户第一次描述任务目标
2. 用户补充背景、约束、材料
3. 用户对已生成结果提出局部修改意见
4. 用户要求 AI 解释建议原因
5. 用户在开放空间中重新定义问题

典型例子：

- “围绕这个热点写一篇面向医院管理层的文章”
- “第三段太硬了，改得更像公众号”
- “把语气改得更专业，但不要太官腔”

### 4.2 结构化 UI 适用的阶段

以下阶段必须由结构化 UI 接管：

1. 存在有限个备选项，且用户必须做一次显式决定
2. 每个选项存在不同后果、成本或执行路径
3. 系统需要记录这次选择是“用户确认”还是“系统默认”
4. 后续步骤会基于该选择继续自动推进

典型例子：

- 选题候选
- 标题候选
- 路由选择
- Provider 选择
- 执行方式选择
- 是否覆盖已有结果
- 是否发布 / 删除 / 切换对象

---

## 5. 关键分叉点规则

Workbench 中凡是满足“改变后续执行路径”的节点，都属于关键分叉点。

关键分叉点必须满足以下规则：

1. 系统必须显式列出候选项
2. 每个候选项必须展示最小必要解释
3. 用户必须能一键确认，而不是被迫输入“选第二个”
4. 系统必须记录当前结果是：
   - 用户显式选择
   - 系统自动默认
   - 用户手工输入新方案
5. 用户必须能看到“继续生成”和“返回修改”的边界

这条规则直接适用于专员工作流。

例如公众号创作专员在“选题”和“标题”阶段，不能只在消息流里丢出一大段文本然后自动往下跑。

它必须提供：

1. 候选卡片
2. 选择按钮
3. 重生成动作
4. 手工改写入口
5. 当前默认项标识

---

## 6. 问答式与按钮式的正式判断

正式判断不是“问答式更先进”或“按钮式更稳定”。

正式判断是：

**开放问题用问答式，有限决策用按钮式或卡片式。**

进一步细化如下：

### 6.1 优先使用问答式的情况

1. 目标尚未清晰
2. 用户需要补充背景
3. 用户想用自然语言直接改结果
4. 系统无法预先枚举所有合理选项

### 6.2 优先使用按钮 / 卡片式的情况

1. 系统已经生成有限候选集
2. 用户需要从候选集中选一个继续
3. 系统需要明确记录选中的那一项
4. 不同选项会触发不同下游动作

### 6.3 必须同时提供两者的情况

当系统给出候选项时，必须同时允许：

1. 直接点选现有候选
2. 手工输入“都不要，我自己改一个”

因此，最佳形态不是单选按钮，也不是纯聊天。

最佳形态是：

**候选卡片 + 一键选择 + 手工改写入口。**

---

## 7. 对 Workbench 的直接影响

这条架构结论会直接改写 Workbench 的交互职责。

### 7.1 主对话区

主对话区不再只负责消息流。

它还必须承担：

1. 意图发起
2. 阶段性建议解释
3. 结构化候选项承接
4. 人工修改后的继续推进

### 7.2 右栏工作流

右栏工作流不只是“执行日志”。

它还必须承担：

1. 当前阶段展示
2. 待用户选择节点提示
3. 当前默认项显示
4. 历史选择与回退入口

### 7.3 对象工作流定义

后续每个专员 / 技能 / xApp 的工作流定义，不仅要写“执行步骤”，还要写清楚：

1. 哪些步骤是开放输入
2. 哪些步骤是候选选择
3. 哪些步骤允许自动默认
4. 哪些步骤禁止 AI 静默跨过

---

## 8. 系统禁止事项

以下做法禁止作为正式交互方案：

1. 系统给出多个候选项，但没有显式选择入口
2. 系统明明处在关键分叉点，却继续自动执行下游步骤
3. 用户只能靠回复“第 2 个”“用第三个”完成选择
4. 工作流已经进入“待确认”状态，但界面没有任何结构化承接
5. 系统默认选择了某项，但没有标注“这是默认，不是用户确认”

这些行为会让系统看起来更像一个会说话的黑箱，而不是可控的智能工作台。

---

## 9. 当前产品阶段的指导结论

EAI 当前阶段的正式判断如下：

1. 一句话启动任务，继续保留
2. 关键分叉显式选择，必须补齐
3. 执行过程持续可见，必须通过工作流面板承接
4. 局部修改回到对话，继续保留
5. AI 不得静默跨过高价值决策点

其中“高价值决策点”至少包括：

1. 选题
2. 标题
3. 路由
4. Provider
5. 发布
6. 删除
7. 覆盖已有结果
8. 切换当前主责对象

---

## 10. 一句话结论

**EAI 不是用聊天框取代 UI。EAI 是用对话降低启动门槛，用结构化交互接管关键决策，用工作流面板维持持续可控。**

这条结论从现在开始，作为后续 Workbench、专员工作流、技能运行面、xApp 承接面的共同交互依据。