refactor: 专员目录收敛为 6 个，重整 AI 路由与系统管理页
一次性提交当天全部改动（110 个文件）。 **未按 TOP_CODING_RULES.md G14.5「一次提交只装一件事」拆分** —— 用户明确要求 单一提交，此处如实记录，不静默忽略该冲突。 提交前验证：后端 go build / go vet / go test ./... 全绿，前端 npm run build exit 0，/api/health 与管理员 login 均返回 200。 - 专员目录收敛为 6 个：下线 knowledge-operations / process-coordination / presentation-briefing / report-generation 四个专员（前后端 manifest 与 seed 同步删除），新增 general-assistant。专员的归属关系（拥有哪些技能定义、 哪些目录项、提示词与绑定从哪来）改由 specialists/core 的 ownership.go、 prompt_provider.go、binding_provider.go 统一提供，seed 与 admin_handlers 随之内置化，卸载路径统一走 uninstall.go。 - 技能：补齐 text-to-speech 的前端 manifest（后端包在 HEAD 已存在）， skillcore/ownership.go 提供与专员对称的归属查询。 - AI 路由：ai_config.json 由 OpenRouter/Ollama 切到 LMUAI / SiliconFlow / llama.cpp 本地路由，ai_secrets.example.json 与部署 env 样例同步新增 SILICONFLOW_API_KEY。 - 系统管理页重整：新增 AiAdminPage、OrganizationManagementPage，删除 AdminOverviewPage、CompanyConfigPage，SystemConfigPage 精简，nav / router / config/workbench.js 同步调整。依 G05.5，开发阶段直接收口到新结构，不留旧路由。 - 新增 internal/objectrefs：统一统计对象（专员 / 技能 / xapp）的运行时引用 （被多少 xapp、项目、任务引用），供管理页做删除前的影响面判断。 - 公众号创作专员：新增 OfficialAccountSpecialistPanel，workflow 与投递链路调整。 - XApp：考试 / 培训 Shell 扩展，XAppDirectoryPage 与 xappDefinition 同步。 - 文档：新增 GW01–GW05 工作台演进系列与 AR12 对话驱动与结构化交互架构； 同步 AR05 / SY17 / SY23 / SY25 / PL04；TOP_CODING_RULES.md 增补 G05.5。 Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
eaiadmin
@@ -3,7 +3,7 @@
|
||||
> 落盘日期：2026-09-16
|
||||
> 状态：架构合同
|
||||
> 作用：作为后续前端重构的强约束，先定模型，再做代码迁移
|
||||
> 关联文档：`AR08_角色交互设计.md`
|
||||
> 关联文档：`AR08_角色交互设计.md`、`AR12_对话驱动与结构化交互架构.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -275,6 +275,33 @@ type TaskRuntimeContext = {
|
||||
3. 工具焦点时，展示工具级执行流与产物
|
||||
4. 右栏不允许只支持专员、不支持工具
|
||||
|
||||
### 6.6 关键分叉节点交互
|
||||
|
||||
Workbench 采用混合交互架构：
|
||||
|
||||
- 对话负责发起任务与局部修订
|
||||
- 结构化 UI 负责关键分叉节点接管
|
||||
- 右栏负责持续展示阶段、结果与回退点
|
||||
|
||||
因此，以下节点不允许只靠消息流向下滚动：
|
||||
|
||||
1. 选题
|
||||
2. 标题
|
||||
3. 路由
|
||||
4. Provider
|
||||
5. 发布
|
||||
6. 删除
|
||||
7. 覆盖已有结果
|
||||
8. 切换当前主责对象
|
||||
|
||||
这些节点一律视为关键分叉节点，必须满足：
|
||||
|
||||
1. 显式列出候选项
|
||||
2. 提供一键确认入口
|
||||
3. 允许用户手工改写，而不是只能选现有项
|
||||
4. 标明当前结果是“用户确认”还是“系统默认”
|
||||
5. 未确认前，不得静默继续执行下游步骤
|
||||
|
||||
---
|
||||
|
||||
## 7. 对象生命周期
|
||||
|
||||
@@ -0,0 +1,259 @@
|
||||
# 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 承接面的共同交互依据。
|
||||
@@ -9,6 +9,7 @@
|
||||
> 当前产品导航与工作台口径，请以 `docs/01_System_Overall/SY22_角色技能应用统一任务架构.md` 为准：
|
||||
> `新建任务 / 项目 / 专员·技能·APP·连接器 / 长程APP / 知识库 / 后台管理 / 我的`
|
||||
> **`AR09` 是规范性文件（对象命名规范），不是设计稿。** 它约束新增代码的命名，并登记了当前已核实的命名问题与修复流程；与 `TOP_CODING_RULES.md` 的 G03 配套使用。
|
||||
> **`AR12` 是当前交互范式讨论的主文档。** 它定义“对话发起 + 结构化决策接管 + 对话继续推进”的混合交互架构，后续 Workbench 与专员工作流交互以此为依据。
|
||||
> 当前正式对象目录请以 `docs/05_Object_Catalog/` 为准；本目录负责跨层架构契约，不再承担对象清单主仓职责。
|
||||
|
||||
## 文件清单
|
||||
@@ -29,4 +30,5 @@
|
||||
| `AR09_对象命名规范.md` | 对象命名规范（**规范性文件**：原理 / 判据 / 术语表 / 分层规范 / 检查守卫 / 修复流程 / 现状问题登记 / 反例库） |
|
||||
| `AR10_应用可删除封装规范.md` | XApp 可删除封装规范（面向一级业务包，目标是“删目录 + 删注册 + 跑卸载”） |
|
||||
| `AR11_技能专员连接器可删除封装规范.md` | Skill / Specialist / Connector 可删除封装规范（复用 AR10 思想，但区分能力包、策略定义包、连接插件包的边界） |
|
||||
| `AR12_对话驱动与结构化交互架构.md` | Workbench 交互范式主文档（对话发起 + 结构化决策接管 + 对话继续推进） |
|
||||
| `Historical_Records/目录说明.md` | 架构迁移说明、历史清单、旧版 AR01–AR03 与阶段性记录索引 |
|
||||
|
||||
Reference in New Issue
Block a user