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
@@ -0,0 +1,326 @@
|
||||
# GW01_全球主流软件工作台历史演进
|
||||
|
||||
> 状态：研究主文
|
||||
> 最后更新：2026-09-23
|
||||
> 关联文档：
|
||||
> - `docs/02_Architecture/AR12_对话驱动与结构化交互架构.md`
|
||||
> - `GW02_对话式AI工作台与传统UI分界判断.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景
|
||||
|
||||
“工作台”不是一个固定不变的 UI 样式，而是软件在不同时代对同一个问题的回答：
|
||||
|
||||
**人如何向系统发起任务、查看状态、做关键选择、协调资源，并把结果沉淀为持续可复用的工作资产。**
|
||||
|
||||
如果只把工作台理解成一个页面布局，就会误判今天的 AI 工作台。
|
||||
真正的历史主线不是“按钮变聊天”，而是：
|
||||
|
||||
1. 从命令执行界面，走向图形化操作面
|
||||
2. 从孤立应用，走向集成式工作面
|
||||
3. 从个人文件处理，走向协同式共享空间
|
||||
4. 从信息显示与流程填写，走向角色化任务入口
|
||||
5. 从辅助建议，走向 AI 参与执行
|
||||
6. 从单代理对话，走向多代理编排与人工接管
|
||||
|
||||
---
|
||||
|
||||
## 2. 核心判断
|
||||
|
||||
全球主流软件工作台形态的演进，并不是线性替换，而是不断叠层。
|
||||
|
||||
旧层没有消失，新层只是接管了更高价值的控制面：
|
||||
|
||||
1. CLI 没有死，它变成了专家层和自动化层
|
||||
2. GUI 没有死，它变成了大众软件的主操作面
|
||||
3. 表单和事务界面没有死，它们在 ERP、CRM、后台系统里仍是高密度输入面
|
||||
4. 协同工作台没有死，它变成了组织知识和任务的主枢纽
|
||||
5. 对话式 AI 没有吞掉 UI，它只是新增了一个极低门槛的意图输入层
|
||||
6. Agent Workbench 不是“聊天升级版”，而是新的协调层
|
||||
|
||||
所以今天讨论 AI 工作台时，不能把问题简化成“要不要聊天框”。
|
||||
真正的问题是：
|
||||
|
||||
**哪一层负责发起，哪一层负责决策，哪一层负责执行，哪一层负责审计。**
|
||||
|
||||
---
|
||||
|
||||
## 3. 历史分期
|
||||
|
||||
### 3.1 第一阶段：批处理与命令行工作面
|
||||
|
||||
这一阶段的核心不是“界面美观”，而是“机器终于允许人直接发出可执行指令”。
|
||||
|
||||
早期交互从打孔卡、批处理到终端命令，解决的是“如何让机器接收任务”。
|
||||
CLI 带来的关键变化是：
|
||||
|
||||
1. 首次形成实时往返的人机回路
|
||||
2. 用户开始直接操控系统，而不是通过操作员间接提交任务
|
||||
3. 任务执行以命令为中心，而不是以可见对象为中心
|
||||
|
||||
这一阶段的工作台特点是：
|
||||
|
||||
1. 强表达力
|
||||
2. 强组合性
|
||||
3. 低可见性
|
||||
4. 高学习门槛
|
||||
|
||||
CLI 的历史地位不是“过时的输入法”，而是软件工作台第一次拥有“可编排执行”能力。
|
||||
今天 AI Agent 的工具调用、命令执行和脚本编排，本质上都继承了这条线路。
|
||||
|
||||
### 3.2 第二阶段：GUI 与桌面隐喻
|
||||
|
||||
GUI 的意义不是“更好看”，而是把机器操作从语法记忆，转移到视觉识别与对象操作。
|
||||
|
||||
从 Sketchpad、Engelbart 的演示，到 Xerox PARC、桌面隐喻、窗口和鼠标，软件开始把“命令”翻译成“对象 + 动作”的关系。
|
||||
这一步把软件工作台从专家工具推进到大众工具。
|
||||
|
||||
这一阶段奠定了三个长期结构：
|
||||
|
||||
1. 窗口是工作上下文容器
|
||||
2. 图标 / 文档 / 文件夹是可见对象
|
||||
3. 菜单 / 按钮 / 拖拽是标准动作
|
||||
|
||||
GUI 最大的贡献不是替代 CLI，而是让“状态可见”和“操作可发现”成为主流软件的基本要求。
|
||||
|
||||
### 3.3 第三阶段：集成开发工作台与专业工作面
|
||||
|
||||
IDE 是现代工作台思想第一次被做成高完成度产品。
|
||||
|
||||
IDE 不只是把编辑器、编译器、调试器放在一起，它定义了“一个工作面如何承接完整任务闭环”：
|
||||
|
||||
1. 代码编写
|
||||
2. 运行与调试
|
||||
3. 错误定位
|
||||
4. 项目导航
|
||||
5. 构建与发布
|
||||
|
||||
这一步的关键不是视觉变化，而是：
|
||||
|
||||
**从单功能工具，升级为围绕任务闭环组织的统一工作面。**
|
||||
|
||||
这条线后来影响了许多企业软件和内容生产软件。
|
||||
“左侧导航 + 中央主区 + 底部状态/日志 + 右侧属性/上下文”的经典工作台骨架，很大程度上就是专业工作面的产物。
|
||||
|
||||
### 3.4 第四阶段：企业事务系统与角色化工作面
|
||||
|
||||
当 ERP、CRM、ITSM、BPM 系统进入企业核心流程后，工作台开始从“工具整合”走向“角色整合”。
|
||||
|
||||
这类系统解决的是：
|
||||
|
||||
1. 谁在什么岗位上处理什么事务
|
||||
2. 谁能看到哪些数据和动作
|
||||
3. 哪些流程必须被审批、留痕、追责
|
||||
|
||||
这一阶段的典型变化是：
|
||||
|
||||
1. 从功能菜单走向角色入口
|
||||
2. 从自由探索走向事务驱动
|
||||
3. 从单用户文件处理走向组织流程处理
|
||||
|
||||
CRM 的演进很有代表性：它从纸质联系人和 Rolodex，发展到 ACT!、SFA、Siebel，再到 Salesforce 的云化，再到 AI 和 agentic CRM，整个演进始终围绕“组织如何围绕客户任务协同”展开，而不只是数据录入 ([TechTarget, 2024](https://www.techtarget.com/searchcustomerexperience/infographic/The-history-and-evolution-of-CRM))。
|
||||
|
||||
SAP 的演进也说明了同一件事：传统 SAP GUI 的强项是事务深度和专家效率，但 Fiori 明确把方向改成角色化、移动化和 launchpad 化，也就是从“复杂事务屏”走向“角色工作台” ([SAP PRESS, 2026](https://learning.sap-press.com/sap-fiori-overview))。
|
||||
|
||||
### 3.5 第五阶段：Web / SaaS 工作台
|
||||
|
||||
SaaS 时代最大的变化，不只是部署方式变成浏览器，而是：
|
||||
|
||||
1. 工作台变成持续在线的服务入口
|
||||
2. 组织成员开始共享同一个实时系统
|
||||
3. 集成能力成为产品竞争核心
|
||||
|
||||
这使工作台从本地软件壳，变成组织级云端操作面。
|
||||
这一步之后，“一个页面就是一个应用”的理解开始失效，取而代之的是：
|
||||
|
||||
1. 首页总览
|
||||
2. 模块导航
|
||||
3. 搜索入口
|
||||
4. 角色仪表盘
|
||||
5. 跨应用跳转
|
||||
6. 消息与通知中心
|
||||
|
||||
也就是说，SaaS 重新定义了工作台的边界：
|
||||
工作台不再只是当前功能页，而是整个平台的统一入口层。
|
||||
|
||||
### 3.6 第六阶段：协同工作台与共享上下文
|
||||
|
||||
Lotus Notes、Google Docs、Slack、Teams、Notion、Figma 这一线，给工作台带来的最大变化是：
|
||||
|
||||
**工作对象从“文件副本”变成“共享上下文”。**
|
||||
|
||||
这一步至少有四个决定性变化：
|
||||
|
||||
1. 文档从静态文件变成共享空间
|
||||
2. 消息从即时通知变成可搜索知识
|
||||
3. 任务不再附着于单人界面，而是附着于团队上下文
|
||||
4. 工具集成开始被工作台统一编排
|
||||
|
||||
Google Docs 的历史意义，不是“在线版 Word”，而是把文档从附件制、版本制，改成单一实时源 ([Google, 2021](https://blog.google/products-and-platforms/products/workspace/happy-15-years-google-docs/))。
|
||||
|
||||
Slack 的历史意义，也不是“企业 IM”，而是把人、知识、工具和工作流集中到同一环境里，并明确提出自己是 “operating system for work” ([Slack, 2026](https://slack.com/resources/why-use-slack/what-is-slack-and-how-does-it-work))。
|
||||
|
||||
Teams 则把协同工作台继续往“整套生产力套件前台”推进，把聊天、会议、文件、日程、自动化和权限体系统一挂到 Microsoft 365 上，形成真正的平台级工作枢纽 ([m.io, 2026](https://www.m.io/blog/history-of-microsoft-teams))。
|
||||
|
||||
从这一阶段开始，工作台的核心不再只是“我如何操作软件”，而是：
|
||||
|
||||
**团队如何围绕同一个任务上下文持续协作。**
|
||||
|
||||
### 3.7 第七阶段：Copilot 与对话入口
|
||||
|
||||
ChatGPT 以及随后进入各种软件的 Copilot，把软件工作台再次向前推了一步：
|
||||
|
||||
1. 自然语言成为新的启动入口
|
||||
2. 用户可以先表达目标，再让系统反推动作
|
||||
3. 软件第一次在大众层面拥有“解释、建议、草拟、改写”的统一入口
|
||||
|
||||
这一阶段真正被验证的，不是“聊天界面很新鲜”，而是：
|
||||
|
||||
**自然语言把复杂软件的启动门槛显著降低了。**
|
||||
|
||||
这也是为什么 2023 之后，大量成熟软件不是先重写全部 UI，而是先把 Copilot / Assistant 插到现有工作台里。
|
||||
因为它们看见的是一个新增入口层，而不是一次性替换全部交互层。
|
||||
|
||||
### 3.8 第八阶段：Agent Workbench 与控制面升级
|
||||
|
||||
2025 之后的新变化，不是“聊天更像人”，而是软件开始出现真正的 agent orchestration layer。
|
||||
|
||||
这一阶段的工作台，已经不只是一个对话框，而是一个控制面：
|
||||
|
||||
1. 用户发起任务
|
||||
2. 系统拆解任务
|
||||
3. Agent 调用工具执行
|
||||
4. 人在关键节点审阅、接管、回退
|
||||
5. 平台记录过程、产物与状态
|
||||
|
||||
GitHub Copilot 的 agent mode 已经明确越过“回答问题”阶段，开始自动识别子任务、跨文件修改、建议或调用工具，并进入自修复循环 ([GitHub Blog, 2025](https://github.blog/news-insights/product-news/github-copilot-agent-mode-activated/))。
|
||||
|
||||
开发类产品还进一步出现了 agent command center、parallel sessions、agent fleet management 等结构，说明工作台的重心正在从“单轮交互”转向“多执行体编排与治理”。
|
||||
|
||||
这一步意味着：
|
||||
|
||||
**AI 工作台的主价值，不再只是生成内容，而是协调执行。**
|
||||
|
||||
---
|
||||
|
||||
## 4. 代表性工作台类型
|
||||
|
||||
站在 2026 年看，全球主流软件工作台大致可分为六类：
|
||||
|
||||
1. **命令工作台**
|
||||
- 代表：CLI、终端、脚本环境
|
||||
- 强项：表达力、组合性、自动化
|
||||
|
||||
2. **对象工作台**
|
||||
- 代表：桌面 GUI、文件管理器、传统设计软件
|
||||
- 强项：状态可见、对象直观、通用性高
|
||||
|
||||
3. **专业工作台**
|
||||
- 代表：IDE、分析平台、工程软件
|
||||
- 强项：围绕专业闭环组织能力
|
||||
|
||||
4. **事务工作台**
|
||||
- 代表：ERP、CRM、后台系统、ITSM
|
||||
- 强项：角色化、审批化、留痕化
|
||||
|
||||
5. **协同工作台**
|
||||
- 代表：Docs、Slack、Teams、Notion、Figma
|
||||
- 强项：共享上下文、多人协作、知识沉淀
|
||||
|
||||
6. **Agent 工作台**
|
||||
- 代表：Copilot Workspace、AI-native IDE、Agent Control Plane
|
||||
- 强项：自然语言发起、工具调用、自动推进、人工接管
|
||||
|
||||
注意，这六类不是相互排斥。
|
||||
今天最有竞争力的产品，往往恰恰是多层叠加：
|
||||
|
||||
1. 用对话发起
|
||||
2. 用事务面控制权限与状态
|
||||
3. 用协同面承接共享上下文
|
||||
4. 用 Agent 层接管执行
|
||||
|
||||
---
|
||||
|
||||
## 5. 对当前 AI 工作台讨论的直接启示
|
||||
|
||||
### 5.1 聊天框不是工作台的全部
|
||||
|
||||
聊天框只解决了“怎么开始说”，没有天然解决：
|
||||
|
||||
1. 过程状态可见
|
||||
2. 候选项并列比较
|
||||
3. 默认与确认边界
|
||||
4. 回退与审计
|
||||
5. 多对象、多工具、多步骤协同
|
||||
|
||||
### 5.2 现代工作台的核心价值已经变成“协调”
|
||||
|
||||
从 Slack 到 Teams，再到 Agent Control Plane，最值钱的都不是单一功能，而是协调层：
|
||||
|
||||
1. 协调人和人
|
||||
2. 协调人和文档
|
||||
3. 协调任务和工具
|
||||
4. 协调模型和执行体
|
||||
|
||||
### 5.3 AI 没有取消 UI，AI 把 UI 重新分层了
|
||||
|
||||
现在真正发生的事不是“界面被对话吞掉”，而是界面被重新分成四层：
|
||||
|
||||
1. 意图输入层
|
||||
2. 决策接管层
|
||||
3. 执行编排层
|
||||
4. 状态审计层
|
||||
|
||||
哪怕在最先进的 AI 工作台里，这四层也都存在，只是表达方式不同。
|
||||
|
||||
### 5.4 新一代产品竞争点是“工作台控制权”
|
||||
|
||||
未来产品竞争，不只是谁的模型更强，而是谁控制：
|
||||
|
||||
1. 任务入口
|
||||
2. 上下文组织
|
||||
3. 工具调用
|
||||
4. 审批回路
|
||||
5. 结果回写
|
||||
|
||||
也就是说，真正的战略高地不是单个 Agent，而是 Agent 所附着的工作台控制面。
|
||||
|
||||
---
|
||||
|
||||
## 6. 结论
|
||||
|
||||
全球主流软件工作台的历史演进，说明了一个非常稳定的规律：
|
||||
|
||||
**每一代工作台的胜出，不是因为它删掉了上一代，而是因为它把“发起任务、做决策、调动资源、沉淀结果”的闭环做得更完整。**
|
||||
|
||||
所以，今天讨论对话式 AI 软件时，真正的问题不是：
|
||||
|
||||
- 要不要聊天框
|
||||
- 要不要按钮
|
||||
- 要不要 Tab
|
||||
|
||||
真正的问题是：
|
||||
|
||||
1. 对话负责什么
|
||||
2. 结构化界面负责什么
|
||||
3. Agent 负责什么
|
||||
4. 人工确认点放在哪里
|
||||
5. 过程如何保持可见、可接管、可回退
|
||||
|
||||
这也是为什么下一代 AI 工作台，不会回到传统 GUI，也不会停在纯聊天界面。
|
||||
它会走向一种新的混合形态：
|
||||
|
||||
**对话负责发起，结构化界面负责关键接管，Agent 负责执行推进，工作流面板负责持续可见。**
|
||||
|
||||
---
|
||||
|
||||
## 7. 参考来源
|
||||
|
||||
1. The History of User Interfaces, https://www.historyofui.com/
|
||||
2. TechTarget, The history and evolution of CRM, https://www.techtarget.com/searchcustomerexperience/infographic/The-history-and-evolution-of-CRM
|
||||
3. Slack, What is Slack and how does it work?, https://slack.com/resources/why-use-slack/what-is-slack-and-how-does-it-work
|
||||
4. Google, 15 milestones, moments and more for Google Docs’ 15th birthday, https://blog.google/products-and-platforms/products/workspace/happy-15-years-google-docs/
|
||||
5. SAP PRESS, SAP Fiori Overview: UX, App Types, and Deployment Models, https://learning.sap-press.com/sap-fiori-overview
|
||||
6. m.io, The History of Microsoft Teams, https://www.m.io/blog/history-of-microsoft-teams
|
||||
7. GitHub Blog, Vibe coding with GitHub Copilot: Agent mode and MCP support rolling out to all VS Code users, https://github.blog/news-insights/product-news/github-copilot-agent-mode-activated/
|
||||
@@ -0,0 +1,361 @@
|
||||
# GW02_对话式AI工作台与传统UI分界判断
|
||||
|
||||
> 状态：专题判断
|
||||
> 最后更新：2026-09-23
|
||||
> 关联文档：
|
||||
> - `GW01_全球主流软件工作台历史演进.md`
|
||||
> - `docs/02_Architecture/AR12_对话驱动与结构化交互架构.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题定义
|
||||
|
||||
新一代 AI 驱动软件，最大的误判之一，就是把问题理解成：
|
||||
|
||||
- “聊天框会不会取代传统 UI”
|
||||
- “问答式是不是比按钮式先进”
|
||||
- “有了自然语言之后，页面结构是不是就不重要了”
|
||||
|
||||
这些提法都不够准确。
|
||||
|
||||
真正的问题是：
|
||||
|
||||
**当软件具备自然语言理解、内容生成、工具调用和阶段性自动执行能力之后，传统 UI 的职责如何被重排。**
|
||||
|
||||
也就是说，我们讨论的不是“聊天 vs 页面”，而是：
|
||||
|
||||
1. 哪些环节适合开放表达
|
||||
2. 哪些环节必须显式选择
|
||||
3. 哪些环节可以自动执行
|
||||
4. 哪些环节必须由人工接管
|
||||
|
||||
---
|
||||
|
||||
## 2. 结论先行
|
||||
|
||||
结论非常明确：
|
||||
|
||||
**对话式 AI 工作台不会消灭传统 UI，但会把传统 UI 从“唯一入口层”改造成“结构化接管层和可见性层”。**
|
||||
|
||||
所以，新一代 AI 工作台最合理的主形态不是：
|
||||
|
||||
1. 纯聊天
|
||||
2. 纯表单
|
||||
3. 聊天框旁边随便贴几个按钮
|
||||
|
||||
而是：
|
||||
|
||||
**对话发起 + 结构化决策接管 + 持续可见的工作流状态面。**
|
||||
|
||||
---
|
||||
|
||||
## 3. 为什么纯对话不够
|
||||
|
||||
### 3.1 对话擅长启动，不擅长稳定决策
|
||||
|
||||
用户在任务开始时，经常只能说出目标，说不清完整参数。
|
||||
|
||||
例如：
|
||||
|
||||
- “帮我围绕这个热点写一篇公众号稿”
|
||||
- “给我配一条 AI 路由策略”
|
||||
- “把组织配置整理成更适合后台管理的结构”
|
||||
|
||||
这时候对话很强，因为它允许模糊表达、逐步澄清和低门槛启动。
|
||||
|
||||
但一旦进入关键分叉点，例如：
|
||||
|
||||
1. 选哪个选题
|
||||
2. 选哪个标题
|
||||
3. 走哪个 Provider
|
||||
4. 是否继续发布
|
||||
5. 是否覆盖已有结果
|
||||
|
||||
纯对话就会开始失控。
|
||||
|
||||
原因很简单：
|
||||
|
||||
1. 候选项会被消息流淹没
|
||||
2. 用户不容易对比多个候选
|
||||
3. 用户不清楚系统是“建议”还是“已经默认执行”
|
||||
4. 历史决策边界不清楚
|
||||
|
||||
### 3.2 对话天然是线性的，任务天然是分叉的
|
||||
|
||||
聊天是时间线结构。
|
||||
工作流是状态机结构。
|
||||
|
||||
这两者在关键节点上天然冲突。
|
||||
|
||||
只靠聊天往下滚，会出现三个问题：
|
||||
|
||||
1. 分叉点不可见
|
||||
2. 默认选择不可见
|
||||
3. 回退路径不可见
|
||||
|
||||
所以只要任务不是单轮问答，而是持续推进的工作闭环，对话就必须让位给某种结构化承接。
|
||||
|
||||
### 3.3 对话会放大“黑箱感”
|
||||
|
||||
当系统既能理解自然语言，又能自动往下执行时，如果没有显式状态承接，用户会产生强烈的不确定感：
|
||||
|
||||
1. AI 为什么选了这个方案
|
||||
2. 还有哪些备选没展示
|
||||
3. 这一步是不是已经不可逆
|
||||
4. 是我确认的，还是系统默认的
|
||||
|
||||
这会直接伤害信任。
|
||||
|
||||
所以对话式 AI 产品如果不补足结构化接管层，看起来很智能，实际会越来越难控。
|
||||
|
||||
---
|
||||
|
||||
## 4. 为什么纯传统 UI 也不够
|
||||
|
||||
传统 UI 的强项也很明确：
|
||||
|
||||
1. 候选项并列展示
|
||||
2. 状态稳定
|
||||
3. 可见性强
|
||||
4. 回退路径清楚
|
||||
5. 权限和审计友好
|
||||
|
||||
但传统 UI 有三个天然短板：
|
||||
|
||||
1. 启动成本高
|
||||
2. 表单感强
|
||||
3. 难以承接模糊目标
|
||||
|
||||
用户在任务开始时，往往根本不知道该先填哪一项。
|
||||
如果系统一上来就是大表单和流程页，用户会把认知负担提前承担掉。
|
||||
|
||||
所以传统 UI 很适合“确认和控制”，不适合“生成需求和探索方向”。
|
||||
|
||||
---
|
||||
|
||||
## 5. 正式分界：开放表达与有限决策
|
||||
|
||||
这一代 AI 工作台最关键的交互边界，可以用一句话概括：
|
||||
|
||||
**开放问题用对话，有限决策用结构化 UI。**
|
||||
|
||||
### 5.1 适合对话的环节
|
||||
|
||||
以下环节优先用自然语言：
|
||||
|
||||
1. 用户第一次描述目标
|
||||
2. 用户补充背景和约束
|
||||
3. 用户要求 AI 解释建议
|
||||
4. 用户对结果做局部修改
|
||||
5. 用户重新定义问题
|
||||
|
||||
### 5.2 适合结构化 UI 的环节
|
||||
|
||||
以下环节必须有显式承接：
|
||||
|
||||
1. 系统已经形成有限候选集
|
||||
2. 用户必须在候选中选一个继续
|
||||
3. 不同选项会导致不同下游动作
|
||||
4. 系统需要记录“用户确认”还是“默认沿用”
|
||||
5. 一旦继续执行，会产生不可忽略的时间、资源或结果成本
|
||||
|
||||
### 5.3 两者必须共存的环节
|
||||
|
||||
最理想的形态不是按钮替代对话，而是：
|
||||
|
||||
1. 给出候选项
|
||||
2. 提供一键选择
|
||||
3. 同时允许用户说“都不要，我自己改一个”
|
||||
|
||||
所以最佳交互单元不是单纯按钮，也不是单纯问答。
|
||||
|
||||
最佳交互单元是：
|
||||
|
||||
**候选卡片 + 一键确认 + 手工改写入口。**
|
||||
|
||||
---
|
||||
|
||||
## 6. 对话式 AI 软件和传统软件的根本差异
|
||||
|
||||
传统软件大多要求：
|
||||
|
||||
1. 用户先学会系统结构
|
||||
2. 用户再进入正确页面
|
||||
3. 用户再按流程填写和点击
|
||||
|
||||
对话式 AI 软件把这件事倒过来了：
|
||||
|
||||
1. 用户先说目标
|
||||
2. 系统再帮助补全结构
|
||||
3. 再在关键节点要求用户接管
|
||||
|
||||
这带来两个本质变化：
|
||||
|
||||
### 6.1 入口从“功能入口”变成“意图入口”
|
||||
|
||||
传统软件的入口是模块和菜单。
|
||||
AI 软件的入口可以是目标和需求。
|
||||
|
||||
这让系统第一次可以从“我要做什么”而不是“我要进哪个页面”开始。
|
||||
|
||||
### 6.2 软件开始承担“中间推理”
|
||||
|
||||
传统 UI 默认把中间推理留给用户。
|
||||
AI 工作台开始替用户做一部分：
|
||||
|
||||
1. 补参数
|
||||
2. 提候选
|
||||
3. 生成草稿
|
||||
4. 给建议
|
||||
5. 编排执行路径
|
||||
|
||||
但中间推理越强，越需要“中间可见”。
|
||||
|
||||
这就是为什么 AI 软件不可能只有聊天框。
|
||||
因为它承担了更多中间推理，所以更需要中间状态可视化。
|
||||
|
||||
---
|
||||
|
||||
## 7. 对工作台设计的具体要求
|
||||
|
||||
### 7.1 必须区分三类状态
|
||||
|
||||
所有 AI 工作台都必须明确区分：
|
||||
|
||||
1. `用户输入`
|
||||
2. `系统建议`
|
||||
3. `系统已执行`
|
||||
|
||||
如果这三类状态在界面上混在一起，用户很快就会失去控制感。
|
||||
|
||||
### 7.2 必须标明默认值与确认值
|
||||
|
||||
很多系统喜欢“先帮你默认选一个再继续跑”，短期看流畅，长期看一定出问题。
|
||||
|
||||
因为用户会分不清：
|
||||
|
||||
1. 这是我选的
|
||||
2. 这是系统代我选的
|
||||
3. 这是系统只是先暂存的
|
||||
|
||||
所以默认项必须显式标注。
|
||||
|
||||
### 7.3 必须有待接管状态
|
||||
|
||||
一旦系统来到关键分叉点，不能继续伪装成自然流畅对话。
|
||||
|
||||
它必须明确进入一种待接管状态，例如：
|
||||
|
||||
1. 待选题
|
||||
2. 待选标题
|
||||
3. 待确认发布
|
||||
4. 待选择路由
|
||||
|
||||
这一步是 AI 工作台和“会聊天的功能插件”之间的分水岭。
|
||||
|
||||
### 7.4 必须允许回到对话局部修改
|
||||
|
||||
结构化接管不是把系统重新做回旧表单。
|
||||
|
||||
用户在接管后，仍然应该能立刻回到对话里说：
|
||||
|
||||
- “第三个标题好一点，但再稳一点”
|
||||
- “不要这些候选，我自己写一个”
|
||||
- “就按这个选题，但换个更像行业观察的语气”
|
||||
|
||||
也就是说：
|
||||
|
||||
**结构化接管负责做决定，对话负责做微调。**
|
||||
|
||||
---
|
||||
|
||||
## 8. 对 EAI 这类系统的直接启示
|
||||
|
||||
EAI 这类“任务中心 + 对象中心”的平台，不应该模仿传统后台，也不应该停在单一聊天产品形态。
|
||||
|
||||
它更接近一种“可控的 AI 工作台”。
|
||||
|
||||
所以 EAI 的正确方向应当是：
|
||||
|
||||
1. 一句话发起任务
|
||||
2. 系统自动形成候选与工作流初稿
|
||||
3. 在关键节点由用户显式接管
|
||||
4. 系统继续自动推进
|
||||
5. 全过程在工作流面板中保持可见
|
||||
|
||||
这意味着：
|
||||
|
||||
### 8.1 专员工作流不能只靠消息流表达
|
||||
|
||||
例如公众号创作专员的：
|
||||
|
||||
1. 选题
|
||||
2. 标题
|
||||
3. 提纲
|
||||
4. 配图
|
||||
5. 发布准备
|
||||
|
||||
其中至少前两步就必须有结构化承接。
|
||||
|
||||
### 8.2 技能执行不能只显示“开始执行 / 执行完成”
|
||||
|
||||
技能如果涉及多候选、多配置、多路由选择，也必须有中间状态和待确认点。
|
||||
|
||||
### 8.3 后台治理界面仍然必须保留高度结构化
|
||||
|
||||
AI 调用量、路由策略、Provider 配置、权限与审计，这些都不是适合纯对话承接的主面。
|
||||
这些地方仍然需要明确的表格、Tab、对比视图和可追责记录。
|
||||
|
||||
所以 AI 平台永远不会完全取消“传统后台”，它只会改变前台任务发起和工作流协作方式。
|
||||
|
||||
---
|
||||
|
||||
## 9. 一句话判断
|
||||
|
||||
**对话式 AI 工作台最大的创新，不是让软件变成聊天，而是让用户可以先说目标，再在关键节点低成本接管系统。**
|
||||
|
||||
这也是它与传统 UI 的根本区别：
|
||||
|
||||
1. 传统 UI 要求用户先理解结构再操作
|
||||
2. AI 工作台允许用户先表达目标再逐步接管
|
||||
|
||||
但这条路成立的前提是：
|
||||
|
||||
**系统必须把关键决策点重新显式化。**
|
||||
|
||||
没有这一步，对话式 AI 软件就会沦为：
|
||||
|
||||
1. 启动很惊艳
|
||||
2. 中途很混乱
|
||||
3. 结果很难控
|
||||
|
||||
---
|
||||
|
||||
## 10. 结论
|
||||
|
||||
新一代对话式 AI 软件和传统 UI 之间的重大区别，不在于有没有聊天框，而在于：
|
||||
|
||||
**系统把“需求形成”前移给对话，把“关键决策”交还给结构化界面，把“持续推进”交给 Agent，把“状态与审计”交给工作流控制面。**
|
||||
|
||||
这四层缺一不可。
|
||||
|
||||
因此，真正成熟的 AI 工作台不会长成纯聊天产品，也不会回退成纯表单后台。
|
||||
它会长成一种混合形态：
|
||||
|
||||
1. 对话负责发起
|
||||
2. 卡片 / 按钮 / Tab 负责接管
|
||||
3. Agent 负责执行
|
||||
4. 工作流面板负责可见性和回退
|
||||
|
||||
这不是传统 UI 的终结。
|
||||
这是传统 UI 被重新分工。
|
||||
|
||||
---
|
||||
|
||||
## 11. 参考来源
|
||||
|
||||
1. The History of User Interfaces, https://www.historyofui.com/
|
||||
2. Slack, What is Slack and how does it work?, https://slack.com/resources/why-use-slack/what-is-slack-and-how-does-it-work
|
||||
3. Google, 15 milestones, moments and more for Google Docs’ 15th birthday, https://blog.google/products-and-platforms/products/workspace/happy-15-years-google-docs/
|
||||
4. SAP PRESS, SAP Fiori Overview: UX, App Types, and Deployment Models, https://learning.sap-press.com/sap-fiori-overview
|
||||
5. GitHub Blog, Vibe coding with GitHub Copilot: Agent mode and MCP support rolling out to all VS Code users, https://github.blog/news-insights/product-news/github-copilot-agent-mode-activated/
|
||||
@@ -0,0 +1,554 @@
|
||||
# GW03_专员工作交互形式分析
|
||||
|
||||
> 状态：专题分析
|
||||
> 最后更新：2026-09-23
|
||||
> 关联文档：
|
||||
> - `GW01_全球主流软件工作台历史演进.md`
|
||||
> - `GW02_对话式AI工作台与传统UI分界判断.md`
|
||||
> - `docs/05_Object_Catalog/specialists/`（各专员详细定义）
|
||||
|
||||
---
|
||||
|
||||
## 1. 分析目标
|
||||
|
||||
GW02 给出了"对话 vs 结构化 UI"的分界原则。本文件把它落到具体对象上：
|
||||
|
||||
**平台中每个专员，它的启动、决策、执行、反馈分别应该走对话还是走 UI 选择。**
|
||||
|
||||
分析维度统一为四项：
|
||||
|
||||
| 维度 | 说明 |
|
||||
|---|---|
|
||||
| **启动方式** | 用户如何开始与该专员的交互 |
|
||||
| **决策方式** | 系统给出候选后，用户如何选择 |
|
||||
| **执行方式** | 系统自动推进还是人工辅助 |
|
||||
| **反馈/审计方式** | 结果如何展示、如何回查 |
|
||||
|
||||
所有分析基于以下分界标准（来自 GW02）：
|
||||
|
||||
1. 开放问题用对话
|
||||
2. 有限决策用结构化 UI
|
||||
3. 候选卡片 + 一键确认 + 手工改写入口 = 最佳交互单元
|
||||
|
||||
---
|
||||
|
||||
## 2. 通用级专员分析
|
||||
|
||||
### 2.1 通用助手（general-assistant）
|
||||
|
||||
| 维度 | 分析 |
|
||||
|---|---|
|
||||
| **启动方式** | **对话**。用户直接说目标，不进入任何应用路由。这是系统唯一入口。 |
|
||||
| **决策方式** | **对话为主，路由选择用结构化**。通用助手不自己做领域决策，它的核心职责是"判断意图 → 推荐专员"。当它推荐多个专员时，需要用结构化卡片展示选项，而不是纯对话列表。 |
|
||||
| **执行方式** | **dw（默认工作站）**。它可以自主执行简单任务（闲聊、查资料、任务拆解），但遇到领域任务时必须路由到其他专员。 |
|
||||
| **反馈/审计** | **对话流 + 任务记录**。简单任务直接在对话中反馈；路由决策需要记录"用户选择了哪个专员、从什么入口进入"。 |
|
||||
|
||||
**交互关键判断：**
|
||||
|
||||
通用助手不应该只是一个"会聊天的功能插件"。它是平台的路由中枢。它的关键交互特征是：
|
||||
|
||||
1. 用户说"帮我写一篇公众号稿" → 对话启动
|
||||
2. 通用助手判断意图 → 对话分析
|
||||
3. 系统展示"公众号创作专员 / 汇报专员 / 通用任务"等候选卡片 → **结构化选择**
|
||||
4. 用户选"公众号创作专员" → 进入公众号创作专员的工作流
|
||||
|
||||
所以通用助手的"对话"只是入口层，它的真正价值在"路由决策的透明化"。
|
||||
|
||||
---
|
||||
|
||||
### 2.2 公众号创作专员（wechat-official-account）
|
||||
|
||||
| 维度 | 分析 |
|
||||
|---|---|
|
||||
| **启动方式** | **对话**。用户说"帮我起一个公众号选题"或"围绕这个热点写一篇文章"。 |
|
||||
| **决策方式** | **必须结构化接管**。公众号创作专员有四步工作流：选题 → 标题 → 提纲 → 正文。每一步产出多个候选后，都必须用结构化卡片展示，让用户做选择。不能只在聊天流里说"我生成了3个选题"让用户回复序号。 |
|
||||
| **执行方式** | **dw（默认工作站）**。内容生成可自主执行，但每个候选都需要用户确认后才进入下一步。 |
|
||||
| **反馈/审计** | **对话流 + 工作流面板**。生成过程在对话中展示，但选题、标题等关键决策必须在工作流面板中可见，支持回退和修改。 |
|
||||
|
||||
**交互关键判断：**
|
||||
|
||||
公众号创作专员是平台中工作流最清晰的专员之一。它的工作流四步不是四段对话，而是**四次决策分叉**：
|
||||
|
||||
```
|
||||
启动对话 → 生成3个选题 → [用户选第2个] → 生成3个标题 → [用户选第1个]
|
||||
→ 生成提纲 → [用户修改后确认] → 生成正文 → [用户编辑后发布准备]
|
||||
```
|
||||
|
||||
四次分叉，四次结构化接管。
|
||||
|
||||
如果只做纯对话，会出现以下问题：
|
||||
|
||||
1. 三次选题在聊天流中被淹没，用户找不到"我到底选了哪个"
|
||||
2. 用户无法回退到"换个标题"而不重写整篇文章
|
||||
3. 用户不知道系统已经执行到哪一步，哪些已确认、哪些是默认
|
||||
|
||||
所以公众号创作专员的正确交互形态是：
|
||||
|
||||
**对话启动 → 候选卡片选择 → 候选卡片选择 → 候选卡片选择 → 候选卡片选择 → 最终编辑**
|
||||
|
||||
每一步都是"对话生成 + 卡片选择"的闭环。
|
||||
|
||||
---
|
||||
|
||||
### 2.3 汇报专员（presentation-briefing）
|
||||
|
||||
| 维度 | 分析 |
|
||||
|---|---|
|
||||
| **启动方式** | **对话**。用户说"帮我做一版 8 页管理层汇报 PPT"。 |
|
||||
| **决策方式** | **混合。页数/结构用结构化，内容用对话微调**。汇报专员的输出是 PPT 结构，这是一个强结构化的文档类型。用户应该先选择汇报类型（经营汇报/方案汇报/培训课件/项目复盘），然后系统生成大纲结构，用户确认或修改。 |
|
||||
| **执行方式** | **dw（默认工作站）**。PPT 生成可自主执行，但大纲确认后才能生成具体内容。 |
|
||||
| **反馈/审计** | **结构化预览 + 对话微调**。PPT 大纲需要结构化预览，生成后的内容允许用户在对话中说"第三页太长了，精简一下"。 |
|
||||
|
||||
**交互关键判断：**
|
||||
|
||||
汇报专员和公众号创作专员不同。公众号是"从零创作"，汇报专员是"基于已有材料整理"。所以它的启动阶段可能需要用户上传文件或粘贴文本，这本身就是结构化输入。
|
||||
|
||||
关键决策点：
|
||||
|
||||
1. 选择汇报类型 → **结构化卡片**
|
||||
2. 上传/粘贴材料 → **结构化文件上传**
|
||||
3. 生成大纲 → **结构化预览 + 确认**
|
||||
4. 生成内容 → **对话微调（逐页说）**
|
||||
5. 最终导出 → **结构化确认**
|
||||
|
||||
---
|
||||
|
||||
## 3. 行业级专员分析
|
||||
|
||||
### 3.1 合同审查专员（contract-review）
|
||||
|
||||
| 维度 | 分析 |
|
||||
|---|---|
|
||||
| **启动方式** | **对话 + 文件上传**。用户说"审查这份采购合同"，同时上传合同文件。 |
|
||||
| **决策方式** | **必须结构化接管**。合同审查的输出是风险分级（critical/high/medium/low），这是一个高度结构化的结果。用户必须能看到完整的条款列表、风险等级、红线建议，并逐项确认。纯对话无法承载这种复杂信息。 |
|
||||
| **执行方式** | **adw（辅助默认工作站）**。合同审查涉及法律合规，必须人工确认每个风险点。系统可以自动识别条款和标记风险等级，但用户必须逐项审核。 |
|
||||
| **反馈/审计** | **高度结构化**。审查结果需要以表格形式展示：条款名、风险等级、建议、原始条款位置。这是审计友好的界面。 |
|
||||
|
||||
**交互关键判断：**
|
||||
|
||||
合同审查专员是"adw 模式"的典型代表。它的工作流程是：
|
||||
|
||||
```
|
||||
上传合同 → [系统自动分析] → 结构化展示风险表格 → [用户逐项确认/修改] → 生成审查报告 → [用户确认/导出]
|
||||
```
|
||||
|
||||
每一步都不能用纯对话替代。原因：
|
||||
|
||||
1. 风险分级是四级结构化数据，聊天流无法清晰展示
|
||||
2. 用户需要能"只看 critical 和 high"、"按条款类型筛选"
|
||||
3. 审查结果是法律级文件，必须有完整的审计追踪
|
||||
|
||||
所以合同审查专员的"对话"只发生在启动阶段（说一句话 + 上传文件），后续全部是结构化交互。
|
||||
|
||||
---
|
||||
|
||||
### 3.2 售前方案专员（solution-proposal）
|
||||
|
||||
| 维度 | 分析 |
|
||||
|---|---|
|
||||
| **启动方式** | **对话 + 结构化输入**。用户说"帮我起一版智能培训升级方案"，系统追问客户背景、行业、规模、预算等关键参数。 |
|
||||
| **决策方式** | **必须结构化接管**。售前方案的核心输出是"方案结构 + 需求澄清 + 风险边界"，这些都是高度结构化的内容。 |
|
||||
| **执行方式** | **adw（辅助默认工作站）**。售前方案涉及客户关系，需要人工确认哪些是"已确认需求"、哪些是"我方假设"。 |
|
||||
| **反馈/审计** | **结构化方案预览 + 对话微调**。方案大纲需要结构化展示，内容细节允许对话微调。 |
|
||||
|
||||
**交互关键判断：**
|
||||
|
||||
售前方案专员的交互关键在"需求澄清"环节。系统不能直接生成方案，而是应该：
|
||||
|
||||
```
|
||||
用户说需求 → [系统追问关键参数] → 生成需求清单 → [用户确认需求]
|
||||
→ 生成方案大纲 → [用户确认大纲] → 生成方案内容 → [用户修改后确认]
|
||||
```
|
||||
|
||||
其中"系统追问关键参数"阶段是**对话引导的结构化采集**——系统用对话问用户，但用户回答的内容是结构化的（下拉选择、数字输入、多选）。
|
||||
|
||||
---
|
||||
|
||||
### 3.3 客户跟进专员（customer-followup）
|
||||
|
||||
| 维度 | 分析 |
|
||||
|---|---|
|
||||
| **启动方式** | **对话 + 数据导入**。用户说"帮我跟进这些客户"，系统导入客户数据或用户粘贴客户信息。 |
|
||||
| **决策方式** | **混合。意向分级用结构化，联系策略用对话生成**。客户意向分级（A/B/C/D）是结构化判断，但首轮联系话术可以先生成多条供用户选择。 |
|
||||
| **执行方式** | **adw（辅助默认工作站）**。客户跟进涉及对外沟通，需要人工确认每条联系消息后再发送。 |
|
||||
| **反馈/审计** | **结构化客户列表 + 对话生成的话术**。客户状态需要结构化表格展示，话术可以对话生成。 |
|
||||
|
||||
**交互关键判断：**
|
||||
|
||||
客户跟进专员是"数据驱动型"专员。它的工作流程是：
|
||||
|
||||
```
|
||||
导入客户数据 → [系统自动分级] → 结构化展示客户列表和意向等级 → [用户确认分级]
|
||||
→ 生成首轮联系话术 → [用户选择/修改] → 预约建议 → [用户确认] → 状态回写
|
||||
```
|
||||
|
||||
关键决策点：
|
||||
|
||||
1. 客户分级 → **结构化（系统建议等级 + 用户确认）**
|
||||
2. 联系话术 → **对话生成 + 卡片选择**
|
||||
3. 预约时间 → **结构化日历选择**
|
||||
4. 状态回写 → **结构化确认**
|
||||
|
||||
---
|
||||
|
||||
### 3.4 简历筛选与招聘专员（resume-processor）
|
||||
|
||||
| 维度 | 分析 |
|
||||
|---|---|
|
||||
| **启动方式** | **对话 + 批量导入**。用户说"帮我筛这批简历"，系统导入简历文件或用户粘贴候选人信息。 |
|
||||
| **决策方式** | **必须结构化接管**。招聘筛选的核心输出是"候选人排序 + 匹配度评分 + 推荐理由"，这是一个典型的排序决策问题。聊天流无法清晰展示排名和对比。 |
|
||||
| **执行方式** | **dw（默认工作站）**。简历筛选可自主执行，但用户必须能看到完整的候选人列表、匹配度、筛选理由，并手动调整排序。 |
|
||||
| **反馈/审计** | **高度结构化表格**。候选人列表必须按匹配度排序展示，支持按技能、经验、学历等维度筛选。这是招聘场景的刚需。 |
|
||||
|
||||
**交互关键判断：**
|
||||
|
||||
简历筛选与招聘专员是"数据驱动型"专员中最需要结构化 UI 的一个。它的工作流程：
|
||||
|
||||
```
|
||||
导入简历 → [系统自动解析和评分] → 结构化展示候选人排名表格 → [用户调整排序/标记面试/淘汰]
|
||||
→ 生成面试建议 → [用户确认] → 面试安排 → [用户确认]
|
||||
```
|
||||
|
||||
关键决策点：
|
||||
|
||||
1. 简历解析 → **系统自动执行 + 结构化展示**
|
||||
2. 匹配度评分 → **系统建议 + 用户调整**
|
||||
3. 面试/淘汰标记 → **结构化按钮操作**
|
||||
4. 面试建议 → **对话生成 + 卡片选择**
|
||||
5. 面试安排 → **结构化日历选择**
|
||||
|
||||
这个专员有一个特殊特征：**排序决策**。聊天流完全不适合做排序和对比。用户需要能看到 Top 10 候选人的横向对比。
|
||||
|
||||
#### 3.4.1 功能拆解：它真正要负责什么
|
||||
|
||||
这个专员不能只做“筛简历”这个单点动作，它应该负责一条完整但边界清晰的招聘推进链：
|
||||
|
||||
| 功能层 | 必须覆盖的能力 | 不能缺的输出 |
|
||||
|---|---|---|
|
||||
| **招聘入口归档** | 拉取招聘邮箱、上传附件、识别简历、去重合并、保留来源 | 候选人入口清单、重复投递合并记录 |
|
||||
| **岗位要求建模** | 读取 JD、拆出硬门槛、加分项、淘汰项、面试关注项 | 结构化筛选规则卡、评分维度表 |
|
||||
| **候选人解析** | OCR、字段抽取、技能识别、项目经历拆解、年限估算 | 候选人标准档案 |
|
||||
| **匹配度评分** | 按岗位维度打分、给排序理由、标不确定项 | 排名表、评分证据、待确认问题 |
|
||||
| **推进建议** | 推荐进入面试/淘汰/保留池、给面试重点、生成沟通建议 | 推荐清单、面试建议卡、淘汰原因 |
|
||||
| **招聘协同** | 面试排期、状态回写、和招聘经理确认 | 面试安排单、状态流转记录 |
|
||||
|
||||
这里最关键的一点是：**它的主价值不是“帮你读一份简历”，而是“把一批候选人变成一张可推进的决策清单”。**
|
||||
|
||||
如果只做解析或摘要，它只是技能；如果能把入口、评分、排序、推进连起来，它才配叫专员。
|
||||
|
||||
#### 3.4.2 好用的目标工作流：不是线性表单，而是批处理决策流
|
||||
|
||||
这个专员的理想工作流应该分成 6 段，每一段都有清晰输入、系统动作和人工确认点：
|
||||
|
||||
1. **创建招聘任务**
|
||||
用户输入岗位名称、JD、招聘邮箱或上传简历包，选择本轮筛选目标。
|
||||
|
||||
2. **建立筛选规则**
|
||||
系统把 JD 拆成：
|
||||
- 硬门槛：必须满足
|
||||
- 加分项：满足越多越靠前
|
||||
- 风险项：信息缺失或冲突
|
||||
- 面试关注项：需要面谈验证
|
||||
|
||||
3. **批量解析候选人**
|
||||
系统读取邮件、附件、PDF、图片简历，抽取候选人结构化字段，并做重复投递识别。
|
||||
|
||||
4. **自动评分与排序**
|
||||
系统按统一评分卡打分，输出总分、分项分、排名、理由、不确定项。
|
||||
|
||||
5. **人工校正与分桶**
|
||||
用户直接在表格里做四类动作：
|
||||
- 调整排序
|
||||
- 标记进入面试
|
||||
- 标记淘汰
|
||||
- 标记待确认
|
||||
|
||||
6. **生成推进动作**
|
||||
系统批量生成：
|
||||
- 推荐候选人清单
|
||||
- 面试重点摘要
|
||||
- 邀约邮件/消息草稿
|
||||
- 面试安排建议
|
||||
|
||||
真正影响可用性的，不是第 3 步“AI 能不能抽字段”，而是第 5 步“用户能不能极快地改、看、比、确认”。
|
||||
|
||||
#### 3.4.3 UI 结构：主界面必须围绕“候选人排名表”展开
|
||||
|
||||
这个专员最适合的不是纯聊天页，而是一个 **1 个主表 + 2 个侧栏 + 1 个底部审计区** 的工作台。
|
||||
|
||||
建议布局：
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ 顶部任务条：岗位 / 当前轮次 / 待处理数 / 面试推荐数 / 风险数 │
|
||||
├──────────────┬──────────────────────────────┬───────────────┤
|
||||
│ 左侧规则栏 │ 中央候选人主表 │ 右侧详情栏 │
|
||||
│ │ │ │
|
||||
│ JD 规则卡 │ 排名 / 候选人 / 总分 / 分项分 │ 候选人详情 │
|
||||
│ 硬门槛 │ 来源 / 风险 / 推荐动作 │ 简历原文片段 │
|
||||
│ 加分项 │ [筛选][排序][批量操作] │ 评分证据 │
|
||||
│ 面试关注项 │ │ 待确认点 │
|
||||
│ │ │ 操作记录 │
|
||||
├──────────────┴──────────────────────────────┴───────────────┤
|
||||
│ 底部审计区：时间线 / 回放 / 对话微调 / 导出结果 │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
四个关键区块一个都不能少：
|
||||
|
||||
1. **左侧规则栏**
|
||||
让用户始终看到“系统按什么筛人”。没有这个区块，评分就会变成黑箱。
|
||||
|
||||
2. **中央候选人主表**
|
||||
这是整个页面的核心。列建议固定为：
|
||||
- 排名
|
||||
- 候选人
|
||||
- 当前阶段
|
||||
- 总分
|
||||
- 核心维度分
|
||||
- 来源
|
||||
- 风险
|
||||
- 推荐动作
|
||||
- 人工最终动作
|
||||
|
||||
3. **右侧详情栏**
|
||||
点击任一候选人后展开，展示：
|
||||
- 基本信息
|
||||
- 匹配证据
|
||||
- 简历原文引用
|
||||
- 缺失信息
|
||||
- 推荐理由
|
||||
- 面试重点
|
||||
|
||||
4. **底部审计区**
|
||||
不只是“日志”。它应该包含：
|
||||
- 时间线
|
||||
- 回放节点
|
||||
- 对话微调入口
|
||||
- 导出记录
|
||||
|
||||
#### 3.4.4 什么叫“能用好用”：要把高频动作压缩成一屏完成
|
||||
|
||||
招聘同学的真实高频动作不是聊天，而是以下几类：
|
||||
|
||||
- 先看前 10 名
|
||||
- 看某人为什么排这里
|
||||
- 快速标记进面 / 淘汰 / 待确认
|
||||
- 调整某个维度权重
|
||||
- 找出“学历不满足但经验很强”的例外
|
||||
- 导出一版给招聘经理确认
|
||||
|
||||
所以“好用”的标准不是页面好看，而是下面这些动作能不能极快完成：
|
||||
|
||||
| 目标动作 | 好用的交互方式 | 不好用的交互方式 |
|
||||
|---|---|---|
|
||||
| 看前 10 名 | 默认按总分排序，首屏直出 | 让用户先问一句“谁最合适” |
|
||||
| 看排序理由 | 行内展开 + 右栏证据 | 只给一句文本总结 |
|
||||
| 标记进面/淘汰 | 表格行内按钮 + 批量操作 | 打开详情页再二次确认 |
|
||||
| 改筛选规则 | 左栏直接改权重或门槛 | 回到聊天里重新描述 |
|
||||
| 看信息缺口 | 风险标签 + 缺失字段提示 | 把问题埋在长段解释里 |
|
||||
| 导出决策单 | 一键导出推荐清单 | 手工复制聊天内容 |
|
||||
|
||||
一句话：**这个专员的“好用”来自可批量处理、可横向比较、可快速确认，而不是来自会聊天。**
|
||||
|
||||
#### 3.4.5 对话在这里仍然重要，但只能做三件事
|
||||
|
||||
这个专员不是不要对话，而是要把对话压缩到最有价值的三个位置：
|
||||
|
||||
1. **启动任务**
|
||||
例如：“帮我按这个 JD 先筛今天邮箱里收到的简历。”
|
||||
|
||||
2. **局部调参**
|
||||
例如：“这轮更看重 ToB 销售经验，学历权重降一点。”
|
||||
|
||||
3. **生成解释与沟通文本**
|
||||
例如：“帮我把前 3 名的推荐理由整理给招聘经理。”
|
||||
|
||||
除此之外的核心决策，都应该回到结构化 UI。
|
||||
|
||||
#### 3.4.6 当前实现与目标状态之间的差距
|
||||
|
||||
结合当前仓库状态，这个专员已经有了对象定义、工作台样例数据和基础话术，但距离“能用好用”还有几处硬缺口：
|
||||
|
||||
1. **当前入口仍是通用工作台入口**
|
||||
前端专员 manifest 默认 `objectEntryRoute = '/home'`，说明它目前是“挂载到通用工作台”的对象，不是独立招聘工作区。
|
||||
|
||||
2. **当前工作台主要还是静态场景稿**
|
||||
`workbench.js` 里已经有“候选人列表、时间线、回放”等结构，但本质还是演示态数据，不是招聘域对象驱动的真实 UI。
|
||||
|
||||
3. **缺少岗位规则建模面**
|
||||
现在定义里强调了“按岗位要求评分”，但没有看到专门承载 JD 拆解、权重调节、硬门槛确认的页面结构。
|
||||
|
||||
4. **缺少候选人证据面**
|
||||
真正让招聘经理敢用的不是分数，而是“分数背后的证据引用”。这一层目前还不够具体。
|
||||
|
||||
5. **缺少批量动作面**
|
||||
招聘场景的效率来自批处理：批量标记、批量淘汰、批量发起邀约。没有批量动作，页面再结构化也不够好用。
|
||||
|
||||
#### 3.4.7 产品落地优先级：先把什么做出来
|
||||
|
||||
如果按“最快形成可用闭环”排序，我建议按下面三层推进：
|
||||
|
||||
**P0：先把最小可用闭环做出来**
|
||||
|
||||
- 独立招聘任务页
|
||||
- JD 结构化规则卡
|
||||
- 候选人主表
|
||||
- 候选人详情侧栏
|
||||
- 进面 / 淘汰 / 待确认 三类动作
|
||||
- 推荐清单导出
|
||||
|
||||
**P1：把它做顺手**
|
||||
|
||||
- 权重调节
|
||||
- 缺失信息高亮
|
||||
- 例外候选人提示
|
||||
- 批量操作
|
||||
- 面试重点自动生成
|
||||
- 邀约草稿生成
|
||||
|
||||
**P2：把它做成真正的招聘工作台**
|
||||
|
||||
- 招聘邮箱实时同步
|
||||
- 多岗位并行筛选
|
||||
- 面试反馈回写
|
||||
- 录用结果反哺评分模型
|
||||
- “为什么这次排序和上次不同”的版本对比
|
||||
|
||||
结论很明确：**这个专员不应该继续停留在“聊天入口 + 几段说明文案”的层级，它必须升级成一个围绕候选人排序表运转的招聘工作台。**
|
||||
|
||||
## 4. 综合分析
|
||||
|
||||
### 4.1 按交互模式分类
|
||||
|
||||
将所有专员按"对话 vs 结构化"的比例排序：
|
||||
|
||||
| 专员 | 对话占比 | 结构化占比 | 模式 |
|
||||
|---|---|---|---|
|
||||
| **通用助手** | 70% | 30% | 对话入口 + 结构化路由 |
|
||||
| **公众号创作专员** | 40% | 60% | 对话生成 + 四次结构化选择 |
|
||||
| **汇报专员** | 40% | 60% | 对话生成 + 结构化大纲 |
|
||||
| **简历筛选与招聘专员** | 20% | 80% | 对话启动 + 高度结构化表格 |
|
||||
| **合同审查专员** | 20% | 80% | 对话启动 + 高度结构化表格 |
|
||||
| **售前方案专员** | 30% | 70% | 对话引导 + 结构化方案 |
|
||||
| **客户跟进专员** | 30% | 70% | 对话启动 + 结构化客户列表 |
|
||||
|
||||
### 4.2 关键发现
|
||||
|
||||
**发现 1：对话占比最高的不是"对话式 AI"，而是路由层**
|
||||
|
||||
通用助手对话占比 70%，但它不做领域决策。真正做领域决策的专员，对话占比都在 20%-40%。这说明：
|
||||
|
||||
> 对话的最大价值在"启动和路由"，不在"执行和决策"。
|
||||
|
||||
**发现 2：所有涉及排序、对比、分级的任务必须用结构化 UI**
|
||||
|
||||
招聘筛选（候选人排序）、合同审查（风险分级）、客户跟进（意向分级）——这三个专员的共同特征是"多选项对比决策"。聊天流无法承载这种决策需求。
|
||||
|
||||
**发现 3：adw 模式的专员一定有更强烈的结构化需求**
|
||||
|
||||
合同审查和售前方案都是 adw 模式，它们的共同特征是"涉及合规/风险/客户关系"，所以每一步决策都需要人工确认，这也意味着需要更丰富的结构化界面来支撑确认过程。
|
||||
|
||||
**发现 4：工作流越清晰的专员，越不适合纯对话**
|
||||
|
||||
公众号创作专员有四步明确工作流（选题→标题→提纲→正文），每一步都需要用户确认。这种"多阶段决策"是结构化 UI 的强项，不是聊天流的强项。
|
||||
|
||||
---
|
||||
|
||||
## 5. 对 EAI 平台的交互设计建议
|
||||
|
||||
基于以上分析，对平台交互设计提出以下建议：
|
||||
|
||||
### 5.1 通用助手：对话入口 + 结构化路由卡片
|
||||
|
||||
通用助手的核心价值是路由。当它推荐多个专员时，必须用结构化卡片展示：
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ 你可以根据需要选择： │
|
||||
│ │
|
||||
│ [📝 公众号创作专员] 内容创作 │
|
||||
│ [📊 汇报专员] 演示汇报 │
|
||||
│ [📋 合同审查专员] 法务审查 │
|
||||
│ │
|
||||
│ 或者继续用通用助手聊天 │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 5.2 公众号创作专员：对话生成 + 卡片选择 + 工作流面板
|
||||
|
||||
公众号创作专员的四步工作流应该在工作流面板中持续可见：
|
||||
|
||||
```
|
||||
┌──────────────────┬──────────────────────────┐
|
||||
│ 工作流面板 │ 对话区 │
|
||||
│ │ │
|
||||
│ ① 选题 ● 已选 │ 生成了3个选题： │
|
||||
│ ② 标题 ○ 待选 │ [卡片A] [卡片B] [卡片C] │
|
||||
│ ③ 提纲 ○ 待选 │ 请选择一个 │
|
||||
│ ④ 正文 ○ 待选 │ │
|
||||
│ │ │
|
||||
│ 已选：选题2 │ │
|
||||
│ │ │
|
||||
│ [← 上一步] [下一步 →] │
|
||||
└──────────────────┴──────────────────────────┘
|
||||
```
|
||||
|
||||
### 5.3 合同审查/招聘筛选：高度结构化表格 + 对话辅助
|
||||
|
||||
这些专员的"主界面"应该是表格：
|
||||
|
||||
```
|
||||
┌──────┬──────────────┬────────┬──────────────────┐
|
||||
│ 排名 │ 候选人/条款 │ 等级 │ 建议/理由 │
|
||||
├──────┼──────────────┼────────┼──────────────────┤
|
||||
│ 1 │ 张三 │ CRITICAL│ 赔偿条款无限额 │
|
||||
│ 2 │ 李四 │ HIGH │ 缺少保密条款 │
|
||||
│ 3 │ 王五 │ MEDIUM │ 工作时间不合规 │
|
||||
│ ... │ ... │ ... │ ... │
|
||||
└──────┴──────────────┴────────┴──────────────────┘
|
||||
|
||||
[筛选: 全部 | CRITICAL | HIGH | MEDIUM]
|
||||
[导出审查报告] [确认并继续]
|
||||
```
|
||||
|
||||
在表格下方或侧边保留对话入口，允许用户说"第2条再严格一点"。
|
||||
|
||||
### 5.4 所有专员的共同模式
|
||||
|
||||
无论哪个专员，都应该遵循以下统一模式：
|
||||
|
||||
```
|
||||
对话启动 → 系统分析 → 结构化展示候选 → 用户选择/修改
|
||||
→ 系统执行 → 结构化展示结果 → 用户确认/修改
|
||||
→ 继续或结束
|
||||
```
|
||||
|
||||
关键原则：
|
||||
|
||||
1. **启动用对话**（低门槛进入）
|
||||
2. **候选用卡片**（多选项并列展示）
|
||||
3. **决策用表格**（排序/对比/分级）
|
||||
4. **微调用对话**（局部修改不需要回到表格）
|
||||
5. **确认用按钮**（明确用户确认动作）
|
||||
6. **状态永远可见**（工作流面板/进度条）
|
||||
|
||||
---
|
||||
|
||||
## 6. 一句话总结
|
||||
|
||||
**所有专员的交互形式可以归结为一句话：**
|
||||
|
||||
> 对话负责"说清楚要什么"，结构化 UI 负责"从系统中选出来"，表格和卡片负责"看清楚选对了没有"。
|
||||
|
||||
这三层缺一不可，也不能互相替代。
|
||||
|
||||
---
|
||||
|
||||
## 8. 参考来源
|
||||
|
||||
1. GW01_全球主流软件工作台历史演进.md
|
||||
2. GW02_对话式AI工作台与传统UI分界判断.md
|
||||
3. SAP PRESS, SAP Fiori Overview: UX, App Types, and Deployment Models, https://learning.sap-press.com/sap-fiori-overview（Fiori 的 1-1-3 规则）
|
||||
4. GitHub Blog, Vibe coding with GitHub Copilot: Agent mode and MCP support, https://github.blog/news-insights/product-news/github-copilot-agent-mode-activated/
|
||||
5. 各专员详细定义：`docs/05_Object_Catalog/specialists/`
|
||||
@@ -0,0 +1,519 @@
|
||||
# GW04_公众号创作专员可用性改进分析
|
||||
|
||||
> 状态：专题分析
|
||||
> 最后更新：2026-09-23
|
||||
> 关联文档：
|
||||
> - `GW02_对话式AI工作台与传统UI分界判断.md`
|
||||
> - `GW03_专员工作交互形式分析.md`
|
||||
> - `docs/05_Object_Catalog/specialists/wechat-official-account/`（对象目录）
|
||||
|
||||
---
|
||||
|
||||
## 1. 核心结论
|
||||
|
||||
**公众号创作专员的后端已经 100% 实现，前端只有骨架没有血肉。**
|
||||
|
||||
后端有完整的工作流引擎（9步）、热点抓取（6个业务域、多数据源）、AI集成（选题/标题/提纲/正文生成）、图片生成、预览导出、DB持久化、API路由全部到位。前端只有 manifest 定义和 API 封装函数，没有任何组件、页面、路由或交互。
|
||||
|
||||
要让它"真正可用"，需要补充的是**整个前端工作流 UI 层**——这是唯一缺失的部分。
|
||||
|
||||
---
|
||||
|
||||
## 2. 现状全貌
|
||||
|
||||
### 2.1 已实现（后端 100%）
|
||||
|
||||
| 层级 | 组件 | 文件数 | 行数 |
|
||||
|------|------|--------|------|
|
||||
| Manifest + 岗位说明书 | 专员定义、技能绑定、边界规则 | 1 | 30 |
|
||||
| 工作流引擎 | 9步工作流、步骤执行器、错误处理 | 1 | 1623 |
|
||||
| 文章服务 | 文章状态CRUD、选题候选构建 | 1 | 357 |
|
||||
| 热点服务 | RSS/Web抓取、评分、缓存、降级 | 1 | 507 |
|
||||
| 交付/导出 | 配图、预览、分页、3种导出格式 | 1 | 619 |
|
||||
| 图片服务 | base64持久化、静态服务 | 1 | 176 |
|
||||
| 业务域配置 | 6个业务域、热点源、关键词 | 1 | 239 |
|
||||
| 图片生成 | media 持久化、静态路由 | 1 | 176 |
|
||||
| Runtime 辅助 | 常量、压缩、底部面板 | 1 | 58 |
|
||||
| 数据模型 | 文章表(26字段)、热点表(14字段) | 2 | 61 |
|
||||
| DAO | 文章DAO、热点DAO、包级注册 | 3 | 133 |
|
||||
| Router 注册 | 7个API端点 | 1 | 7 |
|
||||
| DB 迁移 | 两张表 AutoMigrate | 1 | 2 |
|
||||
| Seed 数据 | 专员种子数据 | 1 | 26 |
|
||||
| Task Runtime 集成 | 产物压缩、运行记录压缩 | 1 | 2 |
|
||||
| Core 注册 | builtinRegistry 注册为第一专员 | 1 | 6 |
|
||||
| 测试 | 专员 prompt 测试 | 1 | 6 |
|
||||
|
||||
**后端总计约 4300+ 行有效代码，覆盖完整。**
|
||||
|
||||
### 2.2 已实现（前端骨架）
|
||||
|
||||
| 层级 | 组件 | 说明 |
|
||||
|------|------|------|
|
||||
| Manifest | manifest.js (26行) | 专员定义 + InteractionCard |
|
||||
| API 封装 | officialAccount.js (33行) | 6个API函数 |
|
||||
| 内置注册 | builtin.js 注册 | 作为第4个内置专员注册 |
|
||||
| 项目模板 | content-operations 绑定 | 绑定公众号创作专员 |
|
||||
|
||||
### 2.3 完全缺失（前端）
|
||||
|
||||
| 缺失项 | 级别 | 说明 |
|
||||
|--------|------|------|
|
||||
| **专属路由页面** | 必须 | `/apps/wechat-official-account` 无对应前端页面 |
|
||||
| **工作流配置页** | 必须 | 创建任务时输入业务域、关键词、受众、目标、语气等 |
|
||||
| **工作流步骤面板** | 必须 | 选题候选卡片选择、标题选择、提纲编辑、正文编辑 |
|
||||
| **配图管理 UI** | 必须 | 配图提示词查看、图片预览、图片重生成 |
|
||||
| **预览/导出 UI** | 必须 | Markdown/HTML 预览、导出按钮 |
|
||||
| **底部面板** | 可选 | timeline / replay / trace / logs 展示 |
|
||||
| **状态指示器** | 可选 | 当前步骤进度、完成步骤标记 |
|
||||
| **错误处理 UI** | 可选 | 步骤执行失败的错误展示 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 公众号创作专员完整工作流（后端已有，前端未实现）
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Step 0: 创建任务（前端缺失） │
|
||||
│ 输入：业务域、关键词、受众、目标、语气、正文字数、提纲字数、配图数 │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 1: 推荐热点选题（后端完整，前端缺失） │
|
||||
│ 1) 从热点源抓取（RSS 36kr/IT之家等 + 网页源 国家医保局等） │
|
||||
│ 2) 评分过滤（域名词 + 业务词 + 加分词） │
|
||||
│ 3) AI 增强生成 3-5 个选题候选 │
|
||||
│ 4) 每个选题含：标题、角度、推荐理由、热度等级（爆热/高/中高/中） │
|
||||
│ 前端需做：展示候选卡片 → 用户选一个 │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 2: 标题生成（后端完整，前端缺失） │
|
||||
│ 1) 基于选定选题，AI 生成 3 个标题 │
|
||||
│ 2) 兜底模板生成（无AI也能工作） │
|
||||
│ 前端需做：展示候选卡片 → 用户选一个 │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 3: 提纲生成（后端完整，前端缺失） │
|
||||
│ 1) 基于选定标题，AI 生成结构化学术型/行业观察型提纲 │
|
||||
│ 2) 兜底模板生成 │
|
||||
│ 前端需做：展示提纲 → 用户可编辑/修改 → 确认 │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 4: 正文创作（后端完整，前端缺失） │
|
||||
│ 1) 基于提纲，AI 生成长文（1400字默认） │
|
||||
│ 2) 口语化但不油腻，观点有依据 │
|
||||
│ 3) 兜底模板生成 │
|
||||
│ 前端需做：展示正文 → 用户可编辑/修改 → 确认 │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 5: 配图提示词（后端完整，前端缺失） │
|
||||
│ 1) 从正文自动提取配图位置（封面图 + 每个章节配图） │
|
||||
│ 2) 为每个配图生成 AI 提示词 │
|
||||
│ 前端需做：展示提示词列表 → 用户可编辑/删除 → 确认 │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 6: 图片生成（后端完整，前端缺失） │
|
||||
│ 1) 调用 image_gen 路由的图片生成 API │
|
||||
│ 2) 每个配图生成后持久化 base64 到文件系统 │
|
||||
│ 3) 返回图片 URL │
|
||||
│ 前端需做：展示生成结果 → 用户可预览 → 对某张图点"重生成" │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 7: 预览与导出（后端完整，前端缺失） │
|
||||
│ 1) 生成 Markdown 预览稿（标题 + 正文 + 配图） │
|
||||
│ 2) 生成 HTML 预览稿（简易排版） │
|
||||
│ 3) 生成分页 Markdown（每章节一页，带 `<!-- PAGE N: title -->` 分隔）│
|
||||
│ 前端需做：展示预览 → 提供3种导出格式按钮 │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 8: 分页 MD（后端完整，前端缺失） │
|
||||
│ 1) 解析分页内容，生成结构化分页数据 │
|
||||
│ 2) 每页含：页码、页标题、页面内容 │
|
||||
│ 前端需做：展示分页数据（可选，已完成的元数据步骤） │
|
||||
│ ─────────────────────────────────────────────────────────────── │
|
||||
│ Step 9: 完成 │
|
||||
│ 工作流结束，文章状态标记为完成 │
|
||||
│ 前端需做：展示完成状态、可导出 │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 改进方案：从"可用"到"好用"
|
||||
|
||||
### 4.1 第一层：可用（核心工作流跑通）
|
||||
|
||||
**目标：用户能完整走完一遍工作流，产出可发布的 Markdown 预览稿。**
|
||||
|
||||
需要实现的前端页面结构：
|
||||
|
||||
```
|
||||
/apps/wechat-official-account
|
||||
├── 创建页：输入业务域、关键词、受众、目标、语气、字数要求
|
||||
├── 工作流页（主页面）
|
||||
│ ├── 左侧：步骤导航栏（9步进度条）
|
||||
│ ├── 中间：当前步骤的交互区
|
||||
│ └── 右侧：预览面板（最终稿预览）
|
||||
│
|
||||
│ Step 1 交互：热点选题候选卡片 → 选一个
|
||||
│ Step 2 交互：标题候选卡片 → 选一个
|
||||
│ Step 3 交互：提纲文本编辑 → 确认
|
||||
│ Step 4 交互：正文文本编辑 → 确认
|
||||
│ Step 5 交互：配图提示词列表 → 编辑/删除 → 确认
|
||||
│ Step 6 交互：图片预览网格 → 预览/重生成
|
||||
│ Step 7 交互：Markdown/HTML 预览 + 导出按钮
|
||||
│ Step 8 交互：分页数据展示（只读）
|
||||
│ Step 9 交互：完成状态
|
||||
└── 导出下载功能
|
||||
```
|
||||
|
||||
**关键 UI 组件：**
|
||||
|
||||
1. **创建表单组件** — 输入业务域、关键词、受众、目标、语气、正文字数、提纲风格、最大配图数
|
||||
2. **步骤导航组件** — 9步进度条，显示每步状态（pending/running/completed/error）
|
||||
3. **选题候选卡片组件** — 每个选题一张卡片，含标题、角度、热度标签、推荐理由，支持点击选择
|
||||
4. **标题候选卡片组件** — 3个标题卡片，点击选择
|
||||
5. **文本编辑器组件** — 提纲和正文的编辑区，支持 Markdown 编辑
|
||||
6. **配图管理组件** — 提示词列表 + 图片预览网格 + 重生成按钮
|
||||
7. **预览面板组件** — Markdown/HTML 双栏预览
|
||||
8. **导出按钮组** — 3个导出格式按钮
|
||||
|
||||
### 4.2 第二层：好用（符合 GW02 的交互原则）
|
||||
|
||||
基于 GW02 的分析，公众号创作专员的交互应该遵循：
|
||||
|
||||
> **对话发起 + 结构化决策接管 + 工作流可见性**
|
||||
|
||||
具体改进：
|
||||
|
||||
**a) 创建任务时，对话式启动**
|
||||
|
||||
用户不说"我要创建一个公众号创作专员任务，业务域是AI，关键词是智能体"，而是直接说：
|
||||
|
||||
> "帮我围绕智能体趋势写一篇文章"
|
||||
|
||||
系统自动识别业务域 = AI，关键词 = 智能体，弹出表单确认：
|
||||
|
||||
```
|
||||
确认以下设置：
|
||||
业务域：AI / 智能体（自动识别）
|
||||
关键词：智能体
|
||||
受众：公众号读者（默认，可改）
|
||||
目标：输出一篇可发布的公众号文章（默认，可改）
|
||||
语气：专业但好懂（默认，可改）
|
||||
正文字数：1400字（默认，可改）
|
||||
|
||||
[确认] [修改]
|
||||
```
|
||||
|
||||
**b) 选题决策用卡片，不是列表**
|
||||
|
||||
GW02 的核心判断：候选项在消息流中容易被淹没。
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ 已抓取 42 条热点，AI 帮你选出了 3 个选题 │
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────┐ │
|
||||
│ │ 🔥 爆热 │ AI Agent 正在替代客服：真的还是炒作？ │ │
|
||||
│ │ │ 角度：热点追踪 · 推荐理由：今日有3家大厂│ │
|
||||
│ │ │ 宣布客服转型 Agent │ │
|
||||
│ │ │ 热度：████████░░ 12分 │ │
|
||||
│ └─────────────────────────────────────────────────┘ │
|
||||
│ [ 选择这个 ] [ 再看 ] │
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────┐ │
|
||||
│ │ ⚡ 高 │ 中小企业为什么不敢做 AI Agent 转型？ │ │
|
||||
│ │ │ 角度：产业动向 · 推荐理由：痛点明确， │ │
|
||||
│ │ │ 读者共鸣度高 │ │
|
||||
│ │ │ 热度：███████░░░ 8分 │ │
|
||||
│ └─────────────────────────────────────────────────┘ │
|
||||
│ [ 选择这个 ] [ 再看 ] │
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────┐ │
|
||||
│ │ 🔸 中 │ Agent 开发工具链盘点：谁在跑在前面？ │ │
|
||||
│ │ │ 角度：技术盘点 · 推荐理由：工具盘点类 │ │
|
||||
│ │ │ 内容长期引流效果好 │ │
|
||||
│ │ │ 热度：████░░░░░░ 5分 │ │
|
||||
│ └─────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ [ 都不要，我自己写一个 ] [ 刷新热点 ] │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**c) 正文编辑允许对话微调**
|
||||
|
||||
用户在编辑区改完后，可以在侧边对话中说：
|
||||
|
||||
> "第三段太技术了，换成更通俗的说法"
|
||||
> "加一段关于 Agent 安全风险的讨论"
|
||||
> "结尾要更有力，给一个行动号召"
|
||||
|
||||
**d) 底部面板始终可见工作流状态**
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ 时间线：热点抓取完成(09:20) → 选题确认(09:25) │
|
||||
│ 回放节点：1 2 3 4 5 6 7 8 │
|
||||
│ 追踪：plugin.hotspot.fetch() → plugin.ai.topic() │
|
||||
│ 日志：[INFO] 抓取42条热点 → [INFO] 过滤6条 │
|
||||
└─────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 4.3 第三层：好用（差异化体验）
|
||||
|
||||
**a) 业务域模板**
|
||||
|
||||
每个业务域（AI/医疗/保险/HR/法务/通用）提供预设模板：
|
||||
|
||||
| 业务域 | 推荐受众 | 推荐语气 | 推荐字数 | 推荐提纲风格 |
|
||||
|--------|----------|----------|----------|-------------|
|
||||
| AI/智能体 | 技术从业者 | 专业但好懂 | 1400 | 问题拆解型 |
|
||||
| 医疗/健康 | 普通用户 | 通俗温暖 | 1200 | 场景故事型 |
|
||||
| 保险/金融 | 投资者/消费者 | 客观严谨 | 1600 | 数据对比型 |
|
||||
| HR/招聘 | HR从业者 | 实用专业 | 1300 | 方法流程型 |
|
||||
| 法务/合规 | 法务从业者 | 严谨准确 | 1500 | 条款分析型 |
|
||||
| 通用 | 公众号读者 | 专业但好懂 | 1400 | 问题拆解型 |
|
||||
|
||||
**b) 热点趋势趋势面板**
|
||||
|
||||
展示该业务域最近7天的热点趋势图：
|
||||
|
||||
```
|
||||
热点趋势（近7天）
|
||||
[████████] 周一 32条
|
||||
[███████░] 周二 28条
|
||||
[█████░░░] 周三 21条
|
||||
[████████] 周四 35条 ← 今天
|
||||
[█████░░░] 周五 22条
|
||||
```
|
||||
|
||||
**c) 选题热度预测**
|
||||
|
||||
AI 不仅给热度标签（爆热/高/中高/中），还给出预估阅读量范围：
|
||||
|
||||
```
|
||||
选题1：AI Agent 正在替代客服
|
||||
热度：爆热 · 预估阅读：5000-15000
|
||||
选题2：中小企业 AI 转型
|
||||
热度：高 · 预估阅读：3000-8000
|
||||
```
|
||||
|
||||
**d) 多版本草稿对比**
|
||||
|
||||
支持并行生成多版本：
|
||||
|
||||
```
|
||||
版本 A（选定）：智能体替代客服
|
||||
版本 B（草稿）：中小企业 AI 转型
|
||||
版本 C（草稿）：Agent 工具链盘点
|
||||
|
||||
[ A ] [ B ] [ C ] [+ 新增版本]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 已知 Bug
|
||||
|
||||
### 5.1 `isOfficialAccountStep` 缺少 `page_markdown` case
|
||||
|
||||
后端工作流引擎的 `isOfficialAccountStep` 函数（约第 919-924 行）的 switch 语句中缺少对 `officialAccountStepKeyPageMD` 的检查，而 `officialAccountNextStep` 函数（约第 950-968 行）会将其作为 `preview_export` 的下一步。这意味着执行分页 MD 步骤时会返回 "工作流步骤不存在" 错误。
|
||||
|
||||
**修复方法：** 在 `isOfficialAccountStep` 的 switch 中添加：
|
||||
|
||||
```go
|
||||
case officialAccountStepKeyPageMD:
|
||||
return true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 前端实现方案
|
||||
|
||||
### 6.1 目录结构
|
||||
|
||||
```
|
||||
frontend/src/specialists/packages/wechat-official-account/
|
||||
├── manifest.js ← 已存在，不需改
|
||||
├── views/
|
||||
│ ├── OfficialAccountCreatePage.vue ← 创建任务页
|
||||
│ ├── OfficialAccountWorkbenchPage.vue ← 工作流主页面（核心）
|
||||
│ └── OfficialAccountPreviewPage.vue ← 预览页（可选，可嵌入 Workbench）
|
||||
├── components/
|
||||
│ ├── WorkflowStepNav.vue ← 步骤导航（9步进度条）
|
||||
│ ├── TopicCandidateCard.vue ← 选题候选卡片
|
||||
│ ├── TitleCandidateCard.vue ← 标题候选卡片
|
||||
│ ├── OutlineEditor.vue ← 提纲编辑器
|
||||
│ ├── ContentEditor.vue ← 正文编辑器
|
||||
│ ├── ImagePromptList.vue ← 配图提示词管理
|
||||
│ ├── ImageGallery.vue ← 图片预览网格
|
||||
│ ├── PreviewPanel.vue ← 预览面板
|
||||
│ └── BottomPanel.vue ← 底部面板
|
||||
├── composables/
|
||||
│ ├── useOfficialAccountWorkflow.js ← 工作流状态管理
|
||||
│ └── useOfficialAccountExport.js ← 导出逻辑
|
||||
└── api/
|
||||
└── officialAccount.js ← 已存在，不需改
|
||||
```
|
||||
|
||||
### 6.2 核心交互流程伪代码
|
||||
|
||||
```javascript
|
||||
// OfficialAccountWorkbenchPage.vue
|
||||
<template>
|
||||
<div class="workbench">
|
||||
<!-- 左侧：步骤导航 -->
|
||||
<WorkflowStepNav
|
||||
:steps="workflow.steps"
|
||||
:currentStep="workflow.currentStep"
|
||||
@selectStep="handleSelectStep"
|
||||
/>
|
||||
|
||||
<!-- 中间：当前步骤交互 -->
|
||||
<div class="step-content">
|
||||
<!-- Step 1: 选题 -->
|
||||
<TopicCandidateCard
|
||||
v-if="currentStep === 'topic_recommendation'"
|
||||
:candidates="workflow.shared.topicCandidates"
|
||||
@select="handleSelectTopic"
|
||||
/>
|
||||
|
||||
<!-- Step 2: 标题 -->
|
||||
<TitleCandidateCard
|
||||
v-if="currentStep === 'title_generation'"
|
||||
:candidates="workflow.shared.titleCandidates"
|
||||
@select="handleSelectTitle"
|
||||
/>
|
||||
|
||||
<!-- Step 3: 提纲 -->
|
||||
<OutlineEditor
|
||||
v-if="currentStep === 'outline_generation'"
|
||||
:content="workflow.shared.outline"
|
||||
@confirm="handleConfirmOutline"
|
||||
/>
|
||||
|
||||
<!-- Step 4: 正文 -->
|
||||
<ContentEditor
|
||||
v-if="currentStep === 'content_creation'"
|
||||
:content="workflow.shared.content"
|
||||
@confirm="handleConfirmContent"
|
||||
/>
|
||||
|
||||
<!-- Step 5: 配图提示词 -->
|
||||
<ImagePromptList
|
||||
v-if="currentStep === 'image_prompt_generation'"
|
||||
:prompts="workflow.shared.imagePrompts"
|
||||
@update="handleUpdatePrompts"
|
||||
/>
|
||||
|
||||
<!-- Step 6: 图片生成 -->
|
||||
<ImageGallery
|
||||
v-if="currentStep === 'image_generation'"
|
||||
:images="workflow.shared.imageRefs"
|
||||
@regenerate="handleRegenerateImage"
|
||||
/>
|
||||
|
||||
<!-- Step 7: 预览 -->
|
||||
<PreviewPanel
|
||||
v-if="currentStep === 'preview_export'"
|
||||
:markdown="workflow.shared.previewMarkdown"
|
||||
:html="workflow.shared.previewHTML"
|
||||
/>
|
||||
</div>
|
||||
|
||||
<!-- 底部面板 -->
|
||||
<BottomPanel :data="bottomPanel" />
|
||||
</div>
|
||||
</template>
|
||||
```
|
||||
|
||||
### 6.3 创建任务流程
|
||||
|
||||
```javascript
|
||||
// 1. 用户从专员市场或通用助手点击"公众号创作专员"
|
||||
// 2. 跳转到 /apps/wechat-official-account
|
||||
// 3. 展示创建表单（或对话式启动）
|
||||
// 4. 填写表单 → 创建任务 → 跳转到工作流页
|
||||
|
||||
// 表单提交
|
||||
const task = await createOfficialAccountTask({
|
||||
business_domain: 'ai',
|
||||
keyword: '智能体',
|
||||
audience: '技术从业者',
|
||||
goal: '输出一篇可发布的公众号文章',
|
||||
tone: '专业但好懂',
|
||||
content_target_words: 1400,
|
||||
max_content_images: 3,
|
||||
})
|
||||
|
||||
// 5. 自动执行 Step 1（热点抓取 + 选题生成）
|
||||
await fetchWorkflow(task.id)
|
||||
// 返回的 workflow.steps['topic_recommendation'].status = 'pending'
|
||||
// workflow.shared.topicCandidates = [候选1, 候选2, 候选3]
|
||||
```
|
||||
|
||||
### 6.4 步骤执行流程
|
||||
|
||||
```javascript
|
||||
// 用户选择选题后，自动进入下一步
|
||||
async function handleSelectTopic(topic) {
|
||||
// 保存选题
|
||||
await updateOfficialAccountTask(taskId, { selected_topic: topic })
|
||||
// 执行下一步：标题生成
|
||||
await executeStep(taskId, 'title_generation', { topic })
|
||||
// 刷新工作流
|
||||
await fetchWorkflow(taskId)
|
||||
}
|
||||
|
||||
// 每个步骤的交互模式：
|
||||
// - 有候选项：展示卡片 → 用户选一个 → 自动进入下一步
|
||||
// - 有文本内容：展示编辑器 → 用户编辑 → 点击确认 → 自动进入下一步
|
||||
// - 有图片：展示预览 → 用户查看 → 可重生成 → 自动进入下一步
|
||||
// - 最后一步：展示预览 + 导出按钮 → 完成
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 工作量评估（按优先级）
|
||||
|
||||
### P0 — 核心可用（必须做）
|
||||
|
||||
| 组件 | 预估工作量 | 说明 |
|
||||
|------|-----------|------|
|
||||
| 创建表单 | 1天 | 业务域、关键词、受众、目标、语气、字数 |
|
||||
| 路由配置 | 0.5天 | `/apps/wechat-official-account` 路由 |
|
||||
| 步骤导航 | 1天 | 9步进度条，状态指示 |
|
||||
| 选题卡片 | 1.5天 | 候选展示、选择、刷新热点 |
|
||||
| 标题卡片 | 0.5天 | 3个标题候选、选择 |
|
||||
| 提纲编辑器 | 1天 | Markdown 编辑器、确认 |
|
||||
| 正文编辑器 | 1天 | Markdown 编辑器、确认 |
|
||||
| 配图提示词 | 1天 | 提示词列表、编辑、确认 |
|
||||
| 图片预览 | 1天 | 图片网格、预览、重生成 |
|
||||
| 预览面板 | 1天 | Markdown/HTML 双栏预览 |
|
||||
| 导出功能 | 0.5天 | 3种格式下载 |
|
||||
| **合计** | **~10天** | 一个前端开发可以完成 |
|
||||
|
||||
### P1 — 提升体验（建议做）
|
||||
|
||||
| 组件 | 预估工作量 | 说明 |
|
||||
|------|-----------|------|
|
||||
| 对话式启动 | 1.5天 | 自然语言解析业务域/关键词 |
|
||||
| 底部面板 | 1天 | timeline / replay / trace / logs |
|
||||
| 对话微调 | 1天 | 编辑区侧边对话、局部修改 |
|
||||
| 业务域模板 | 0.5天 | 预设模板选择 |
|
||||
| **合计** | **~4天** | 在 P0 基础上 |
|
||||
|
||||
### P2 — 差异化功能（可选）
|
||||
|
||||
| 组件 | 预估工作量 | 说明 |
|
||||
|------|-----------|------|
|
||||
| 热点趋势图 | 1天 | 折线图展示热点趋势 |
|
||||
| 选题热度预测 | 1天 | 预估阅读量范围 |
|
||||
| 多版本草稿 | 2天 | 并行生成、对比切换 |
|
||||
| **合计** | **~4天** | 在 P1 基础上 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 总结
|
||||
|
||||
公众号创作专员是平台中**后端实现最完整**的专员——从工作流引擎、热点抓取、AI生成、图片生成、预览导出到DB持久化全部到位。唯一缺失的是前端 UI 层。
|
||||
|
||||
要让它"真正可用"，核心工作就是做一个完整的工作流页面。这个页面的设计原则应该遵循 GW02 的结论：
|
||||
|
||||
1. **启动用对话/表单** — 用户输入目标，系统自动补全结构
|
||||
2. **选择用卡片** — 热点选题、标题都是多候选场景，卡片并列展示
|
||||
3. **编辑用文本区** — 提纲、正文允许用户自由修改
|
||||
4. **预览用双栏** — Markdown 编辑 + HTML 实时预览
|
||||
5. **状态永远可见** — 步骤导航 + 底部面板
|
||||
|
||||
预计 **10天核心实现 + 4天体验优化 + 4天差异化功能**，一个有经验的 Vue 前端工程师可以独立完成。
|
||||
@@ -0,0 +1,485 @@
|
||||
# GW05_公众号创作专员与对话框交互兼容分析
|
||||
|
||||
> 状态：专题分析
|
||||
> 最后更新：2026-09-23
|
||||
> 关联文档：
|
||||
> - `GW02_对话式AI工作台与传统UI分界判断.md`
|
||||
> - `GW04_公众号创作专员可用性改进分析.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题定义
|
||||
|
||||
公众号创作专员的工作流 UI（选题卡片、标题选择、正文编辑、配图管理、预览导出）如何与当前的**对话框布局**兼容？
|
||||
|
||||
当前架构的核心矛盾：
|
||||
|
||||
- **对话框是主交互面**：用户通过 SmartAssistantPage 的 ChatLayout 发起一切
|
||||
- **工作流是右栏被动面板**：SpecialistPanel 只展示已完成的步骤，不提供交互式步骤执行
|
||||
- **公众号创作专员需要完整的前端交互**：选题选择、标题选择、文本编辑、配图管理等操作需要主动输入
|
||||
|
||||
所以问题不是"怎么加一个页面"，而是：**这个工作流交互应该长在对话框上，还是长在对话框旁边？**
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前架构分析
|
||||
|
||||
### 2.1 SmartAssistantPage 布局
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────────┐
|
||||
│ ChatLayout（全屏对话布局） │
|
||||
│ ┌──────────┬──────────────────────────────────────────────────────┐│
|
||||
│ │ 左侧 │ 中间区域 ││
|
||||
│ │ 任务列表 │ ┌────────────────────────────────────────────────┐ ││
|
||||
│ │ │ │ 消息流 │ ││
|
||||
│ │ 任务A │ │ 用户：围绕AI趋势写一篇公众号文章 │ ││
|
||||
│ │ 任务B │ │ 助手：好的，我帮你起草 │ ││
|
||||
│ │ 任务C │ │ · 热点抓取 → 选题推荐 → 标题生成 │ ││
|
||||
│ │ │ │ · 3 个选题候选 │ ││
|
||||
│ │ │ │ 🔥 选题1：AI Agent 正在替代客服 · 爆热 │ ││
|
||||
│ │ │ │ ⚡ 选题2：中小企业 AI 转型 · 高 │ ││
|
||||
│ │ │ │ 🔸 选题3：Agent 工具链盘点 · 中 │ ││
|
||||
│ │ │ │ 请选择一个选题 │ ││
|
||||
│ │ │ ├────────────────────────────────────────────────┤ ││
|
||||
│ │ 右侧面板 │ │ 输入框 + 技能芯片 + 发送按钮 │ ││
|
||||
│ │ │ └────────────────────────────────────────────────┘ ││
|
||||
│ │ SpecialistPanel │ ││
|
||||
│ │ ┌──────────────────────────┐ │ ││
|
||||
│ │ │ 工作流 上传物与产物 │ │ ││
|
||||
│ │ ├──────────────────────────┤ │ ││
|
||||
│ │ │ 1. ✓ 更新任务配置 │ │ ││
|
||||
│ │ │ 2. ✓ 推荐热点选题 │ │ ││
|
||||
│ │ │ 3. 4. 标题/提纲生成 │ │ ││
|
||||
│ │ │ 5. 正文创作 │ │ ││
|
||||
│ │ │ 6. 7. 配图生成 │ │ ││
|
||||
│ │ │ 8. 预览导出 │ │ ││
|
||||
│ │ │ 9. 分页 MD │ │ ││
|
||||
│ │ └──────────────────────────┘ │ ││
|
||||
│ └──────────┴──────────────────────────────────────────────────────┘│
|
||||
└────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 SpecialistPanel 的现状
|
||||
|
||||
SpecialistPanel 是一个**只读面板**，它的职责是：
|
||||
|
||||
1. 从 `action_records_json` 解析已执行的步骤（后端工作流引擎每执行一步就写入此字段）
|
||||
2. 从 `task_artifact` 读取步骤产物
|
||||
3. 展示步骤进度（`doneCount / steps.length`）
|
||||
4. 点击产物卡片跳到产物 tab
|
||||
|
||||
**它不做什么：**
|
||||
|
||||
- 不提供步骤执行按钮（执行由后端自动推进）
|
||||
- 不提供交互选择（选题选择、标题选择等）
|
||||
- 不提供文本编辑（提纲编辑、正文编辑）
|
||||
- 不提供配图管理
|
||||
|
||||
### 2.3 当前工作流推进方式
|
||||
|
||||
当前工作流（包括公众号创作专员）的推进方式是：
|
||||
|
||||
1. 用户在对话框输入"帮我写一篇公众号文章"
|
||||
2. 后端解析出要创建公众号创作专员任务
|
||||
3. 后端自动执行所有工作流步骤（自动抓取热点、自动选题、自动标题、自动正文……）
|
||||
4. 每一步完成后在对话消息中展示产出
|
||||
5. 用户被动阅读
|
||||
|
||||
**没有交互选择的余地。** 用户在对话框里只能看、不能选。
|
||||
|
||||
### 2.4 现有交互模式的例外
|
||||
|
||||
目前唯一的"结构化选择"发生在**技能选择**时：
|
||||
|
||||
- 用户在技能面板选择一个技能（如"公文辅助写作"）
|
||||
- 技能面板展示技能的输入表单
|
||||
- 用户填写后点击"执行"
|
||||
|
||||
但这种交互发生在**任务创建之前**（选择要用的技能），而不是任务执行中间。
|
||||
|
||||
---
|
||||
|
||||
## 3. 公众号创作专员需要什么样的交互？
|
||||
|
||||
根据 GW02 的分析，公众号创作专员有多个**多候选决策点**：
|
||||
|
||||
| 步骤 | 决策类型 | 候选数 | 对话适合度 |
|
||||
|------|---------|--------|-----------|
|
||||
| 选题推荐 | 候选选择 | 3-5 个 | 差：消息流中候选容易淹没 |
|
||||
| 标题选择 | 候选选择 | 3 个 | 差：同上 |
|
||||
| 提纲编辑 | 文本修改 | 一个 | 中：对话可以说"改第三段"但不够精确 |
|
||||
| 正文编辑 | 文本修改 | 一个 | 中：同上 |
|
||||
| 配图提示词 | 编辑管理 | 3-5 个 | 差：需要看到所有提示词的完整内容 |
|
||||
| 图片生成 | 预览选择 | 3-5 张 | 中：对话里能看缩略图但不够清晰 |
|
||||
| 预览导出 | 查看导出 | 一个 | 好：直接下载即可 |
|
||||
|
||||
**结论：公众号创作专员的工作流中有 4 个决策点（选题、标题、提纲、配图）不适合纯对话交互，需要结构化 UI 接管。**
|
||||
|
||||
---
|
||||
|
||||
## 4. 兼容方案
|
||||
|
||||
### 方案 A：扩展 SpecialistPanel（推荐）
|
||||
|
||||
**思路：** 不新增页面，在右侧 SpecialistPanel 中嵌入交互式步骤组件。
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────────┐
|
||||
│ 对话区域（不变） │
|
||||
│ ┌──────────┬──────────────────────────────────────────────────────┐│
|
||||
│ │ 左侧 │ 中间区域 ││
|
||||
│ │ 任务列表 │ 消息流（同上） ││
|
||||
│ └──────────┴──────────────────────────────────────────────────────┘│
|
||||
│ ┌─────────────────────────────────────────────────────────────────┐│
|
||||
│ │ 右侧面板（扩展为交互式） ││
|
||||
│ │ ┌──────────────────────────────────────────────────────────┐ ││
|
||||
│ │ │ 工作流 产物 预览 │ 公众号创作专员 ││ ││
|
||||
│ │ ├──────────────────────────────────────────────────────────┤ ││
|
||||
│ │ │ [1] ✓ 热点抓取 │ ││
|
||||
│ │ │ [2] ✓ 选题推荐 │ ││
|
||||
│ │ │ [3] ⚡ 标题生成（进行中） │ ││
|
||||
│ │ │ [4] ○ 提纲生成 │ ││
|
||||
│ │ │ [5] ○ 正文创作 │ ││
|
||||
│ │ │ [6] ○ 配图生成 │ ││
|
||||
│ │ │ [7] ○ 预览导出 │ ││
|
||||
│ │ ├──────────────────────────────────────────────────────────┤ ││
|
||||
│ │ │ │ ││
|
||||
│ │ │ 当前步骤：标题生成 │ ││
|
||||
│ │ │ ┌────────────────────────────────────────────────────┐ │ ││
|
||||
│ │ │ │ 📰 基于选题："AI Agent 正在替代客服" │ │ ││
|
||||
│ │ │ │ │ │ ││
|
||||
│ │ │ │ ① 客服革命还是噱头？ │ │ ││
|
||||
│ │ │ │ 热度：爆热 · 点击选择 │ │ ││
|
||||
│ │ │ │ │ │ ││
|
||||
│ │ │ │ ② 中小企业不敢做 AI 客服的三个原因 │ │ ││
|
||||
│ │ │ │ 热度：高 · 点击选择 │ │ ││
|
||||
│ │ │ │ │ │ ││
|
||||
│ │ │ │ ③ 2026 客服 Agent 行业盘点 │ │ ││
|
||||
│ │ │ │ 热度：中 · 点击选择 │ │ ││
|
||||
│ │ │ │ │ │ ││
|
||||
│ │ │ │ [ 重新生成 ] [ 我不要这些，换个热点 ] │ │ ││
|
||||
│ │ │ └────────────────────────────────────────────────────┘ │ ││
|
||||
│ │ │ │ ││
|
||||
│ │ │ 底部面板： │ ││
|
||||
│ │ │ 时间线 / 回放 / 追踪 / 日志 │ ││
|
||||
│ │ │ │ ││
|
||||
│ │ └──────────────────────────────────────────────────────────┘ ││
|
||||
│ └─────────────────────────────────────────────────────────────────┘│
|
||||
└────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**优点：**
|
||||
- 不破坏现有的对话架构
|
||||
- 与现有 SpecialistPanel 的只读模式自然融合——新增"交互模式"
|
||||
- 用户始终在同一页面内操作，不需要跳转
|
||||
- 对话框和交互面板并行展示，信息不冲突
|
||||
- 最小改动，复用现有的 SpecialistPanel 组件结构
|
||||
- 对话消息和工作流步骤的状态同步已有基础（通过 `taskRuntime.loadTaskDetail`）
|
||||
|
||||
**缺点：**
|
||||
- 面板宽度有限，复杂的编辑区可能放不下
|
||||
- 需要大幅扩展 SpecialistPanel 的渲染逻辑
|
||||
|
||||
**实施建议：**
|
||||
- SpecialistPanel 根据 `currentStep` 动态渲染不同组件
|
||||
- 对话消息中展示工作流摘要
|
||||
- 面板中展示完整交互
|
||||
- 两个区域的同步通过 `fetchOfficialAccountWorkflow` API + 定时刷新
|
||||
|
||||
---
|
||||
|
||||
### 方案 B：独立工作台页面
|
||||
|
||||
**思路：** 用户从对话框点击"用公众号创作专员处理"后，跳转到 `/apps/wechat-official-account` 独立页面。
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────────┐
|
||||
│ 独立工作页面 │
|
||||
│ ┌─────────────────────────────────────────────────────────────────┐│
|
||||
│ │ 公众号创作专员工作台 ││
|
||||
│ │ ┌──────────┬──────────────────────────────────────────────────┐││
|
||||
│ │ │ 步骤导航 │ 主交互区 │││
|
||||
│ │ │ 1. ✓ │ 选题候选卡片（完整版） │││
|
||||
│ │ │ 2. ✓ │ [ 选择这个 ] [ 刷新热点 ] [ 换选题 ] │││
|
||||
│ │ │ 3. ⚡ │ │││
|
||||
│ │ │ 4. ○ │ ┌────────────────────────────────────────────┐ │││
|
||||
│ │ │ 5. ○ │ │ 编辑区：基于选题写提纲 │ │││
|
||||
│ │ │ 6. ○ │ │ · 第一段：AI 客服的现状 │ │││
|
||||
│ │ │ 7. ○ │ │ · 第二段：中小企业的顾虑 │ │││
|
||||
│ │ │ 8. ○ │ │ · 第三段：未来趋势 │ │││
|
||||
│ │ │ │ │ │ │ │ · 第四段：行业预测 │ │││
|
||||
│ │ │ │ │ │ │ └────────────────────────────────────────────┘ │││
|
||||
│ │ │ │ │ │ │ [ 保存草稿 ] [ 确认 ] [ 重新生成 ] │││
|
||||
│ │ │ │ │ │ │ │││
|
||||
│ │ │ └──────────┴──────────────────────────────────────────────────┘││
|
||||
│ │ │ ┌──────────────────────────────────────────────────────────┐ │││
|
||||
│ │ │ │ 底部面板：时间线 / 回放 / 追踪 / 日志 │ │││
|
||||
│ │ │ └──────────────────────────────────────────────────────────┘ │││
|
||||
│ └─────────────────────────────────────────────────────────────────┘│
|
||||
└────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**优点：**
|
||||
- 工作流交互可以完整展示，不受面板宽度限制
|
||||
- 适合复杂编辑场景（正文编辑、配图管理）
|
||||
- 与"工作流页面"的概念更匹配
|
||||
|
||||
**缺点：**
|
||||
- 用户从对话页面跳转到工作台页面，上下文不连续
|
||||
- 对话消息中的上下文（上传的文件、上传的图片、前文）需要重新获取
|
||||
- 用户可能不知道工作台页面的存在（对话框是唯一的入口心智）
|
||||
- 与现有"对话即工作台"的产品定位冲突
|
||||
|
||||
---
|
||||
|
||||
### 方案 C：对话内嵌卡片 + 侧栏扩展（混合模式）
|
||||
|
||||
**思路：** 结合方案 A 和 B 的优点。
|
||||
|
||||
**场景 1：简单决策（选题、标题）**
|
||||
|
||||
在对话消息中直接展示卡片组件，用户直接在对话消息里选择：
|
||||
|
||||
```
|
||||
助手：已生成 3 个选题候选，请选择：
|
||||
|
||||
┌────────────────────────────────────────┐
|
||||
│ 🔥 爆热 │ AI Agent 正在替代客服 │
|
||||
│ │ 角度：热点追踪 │
|
||||
│ │ 热度：████████░░ 12分 │
|
||||
│ │ [ 选择这个 ] [ 不看 ] │
|
||||
└────────────────────────────────────────┘
|
||||
┌────────────────────────────────────────┐
|
||||
│ ⚡ 高 │ 中小企业 AI 转型的三个原因 │
|
||||
│ │ 角度：产业动向 │
|
||||
│ │ 热度：███████░░░ 8分 │
|
||||
│ │ [ 选择这个 ] [ 不看 ] │
|
||||
└────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
选择后自动执行下一步，新的卡片出现在对话流中。
|
||||
|
||||
**场景 2：复杂编辑（正文、配图）**
|
||||
|
||||
当工作流进入正文创作阶段，在 SpecialistPanel 中自动切换到"编辑模式"：
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ 右侧面板自动切换为编辑模式 ││
|
||||
│ ┌──────────────────────────────────────────────────────────┐ ││
|
||||
│ │ 编辑区（正文创作） │ ││
|
||||
│ │ ┌────────────────────────────────────────────────────┐ │ ││
|
||||
│ │ │ # AI 客服的现状 │ │ ││
|
||||
│ │ │ │ │ ││
|
||||
│ │ │ 2026 年，越来越多的企业开始尝试用 AI 替代人工客服 │ │ ││
|
||||
│ │ │ ... │ │ ││
|
||||
│ │ │ │ │ ││
|
||||
│ │ │ [ 粗体 ] [ 斜体 ] [ 链接 ] [ 插入图片 ] [ Markdown ]│ │ ││
|
||||
│ │ └────────────────────────────────────────────────────┘ │ ││
|
||||
│ │ [ 保存草稿 ] [ 确认并继续 ] [ 对话微调 ] │ ││
|
||||
│ │ │ ││
|
||||
│ │ 对话微调面板（可选展开） │ ││
|
||||
│ │ ┌────────────────────────────────────────────────────┐ │ ││
|
||||
│ │ │ 输入修改建议：第三段太技术了，换成更通俗的说法 │ │ ││
|
||||
│ │ │ [ 执行 ] │ │ ││
|
||||
│ │ └────────────────────────────────────────────────────┘ │ ││
|
||||
│ └──────────────────────────────────────────────────────────┘ ││
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**优点：**
|
||||
- 简单决策在对话中直接完成，不打断流程
|
||||
- 复杂编辑在工作台区域完成，有足够空间
|
||||
- 对话和工作台并行，上下文不断开
|
||||
- 符合 GW02 的"对话发起 + 结构化决策接管"原则
|
||||
|
||||
**缺点：**
|
||||
- 实现复杂度最高
|
||||
- 需要设计对话消息中卡片组件与面板编辑组件的切换逻辑
|
||||
- 需要在 SpecialistPanel 中嵌入多种不同的组件
|
||||
|
||||
---
|
||||
|
||||
## 5. 推荐方案与演进路径
|
||||
|
||||
### 阶段 1：方案 A 为基础（快速可用）
|
||||
|
||||
**目标：10 天内让公众号创作专员核心工作流可用。**
|
||||
|
||||
实现方式：
|
||||
1. 在 SpecialistPanel 中新增"交互渲染区"
|
||||
2. 根据 `currentStep` 动态渲染对应组件
|
||||
3. 简单步骤（选题、标题）在小面板内展示卡片
|
||||
4. 复杂步骤（正文编辑）在面板内展示精简编辑器
|
||||
5. 预览导出直接展示结果
|
||||
|
||||
这是最省力的路径，与现有代码改动最小。
|
||||
|
||||
### 阶段 2：对话消息内嵌卡片（提升体验）
|
||||
|
||||
**目标：让用户在对话框中就能看到工作流产出，不切到面板。**
|
||||
|
||||
实现方式：
|
||||
1. 工作流引擎每完成一个步骤，自动在对话消息中展示结果卡片
|
||||
2. 选题卡片直接渲染在对话消息中（`msg.skillResultCard` 机制复用）
|
||||
3. 用户在对话消息中直接点击选择
|
||||
4. 选择后自动触发下一步，新的卡片出现在消息流中
|
||||
|
||||
这需要：
|
||||
- 工作流引擎在完成每一步时自动向对话消息推送结果
|
||||
- 对话消息支持可交互卡片（不只是展示）
|
||||
|
||||
### 阶段 3：完整独立工作台（可选）
|
||||
|
||||
当公众号创作专员的使用量增长后，如果方案 A/B 的空间不够用（比如需要并排查看热点趋势图、选题对比、多版本草稿），再考虑完整独立工作台页面。
|
||||
|
||||
这个页面应该是"对话 + 工作台"的双栏布局：
|
||||
- 左侧：对话流（作为上下文入口和交互补充）
|
||||
- 右侧：工作流面板（完整编辑区）
|
||||
- 底部：状态栏（时间线、回放、追踪）
|
||||
|
||||
---
|
||||
|
||||
## 6. 关键设计原则
|
||||
|
||||
综合 GW02 的结论，公众号创作专员的交互设计必须遵循：
|
||||
|
||||
### 6.1 对话不代替 UI，对话引导 UI
|
||||
|
||||
对话的作用是：
|
||||
- 告诉系统"要做什么"（"围绕 AI 趋势写文章"）
|
||||
- 在编辑阶段进行局部修改（"第三段太技术"）
|
||||
|
||||
对话**不应该**用来：
|
||||
- 展示所有选题候选让用户体验
|
||||
- 逐个询问标题选择
|
||||
- 展示配图效果
|
||||
|
||||
### 6.2 结构化决策必须有 UI 空间
|
||||
|
||||
所有需要**比较、选择、编辑**的操作必须在一个稳定的 UI 区域内完成：
|
||||
- 选题卡片：并排展示，一目了然
|
||||
- 标题选择：三个并排，点击即可
|
||||
- 正文编辑：完整的文本编辑区
|
||||
- 配图管理：网格布局，点击放大
|
||||
|
||||
### 6.3 可见性层始终在线
|
||||
|
||||
用户需要始终知道：
|
||||
- 当前走到哪一步了（步骤导航）
|
||||
- 已完成什么（步骤列表标记）
|
||||
- 下一步是什么（自动高亮当前步骤）
|
||||
- 产出是什么（产物 tab）
|
||||
|
||||
### 6.4 对话与 UI 的同步
|
||||
|
||||
- 对话消息中展示工作流摘要
|
||||
- 工作流 UI 中展示对话上下文
|
||||
- 用户在对话中的选择应该实时反映在工作流 UI 中
|
||||
- 用户在工作流 UI 中的操作应该在对话中留下记录
|
||||
|
||||
---
|
||||
|
||||
## 7. 具体实现建议
|
||||
|
||||
### 7.1 SpecialistPanel 改造
|
||||
|
||||
现有 SpecialistPanel 的 `tab` 结构已经可以扩展为"交互模式"：
|
||||
|
||||
```vue
|
||||
<template>
|
||||
<div class="specialist-panel">
|
||||
<!-- 现有 tab：工作流 / 产物 / 预览 -->
|
||||
<div class="sp-tabs">
|
||||
<button class="sp-tab" :class="{ active: tab === 'flow' }" @click="tab = 'flow'">
|
||||
工作流 <span class="sp-badge">{{ doneCount }}/{{ steps.length }}</span>
|
||||
</button>
|
||||
<button class="sp-tab" :class="{ active: tab === 'arts' }" @click="tab = 'arts'">
|
||||
产物 <span class="sp-badge">{{ artifacts.length }}</span>
|
||||
</button>
|
||||
<button class="sp-tab" v-if="showInteractiveTab" :class="{ active: tab === 'interactive' }" @click="tab = 'interactive'">
|
||||
操作
|
||||
</button>
|
||||
<button class="sp-fold" @click="emit('collapse')">✕</button>
|
||||
</div>
|
||||
|
||||
<div class="sp-body">
|
||||
<!-- 现有：只读工作流 -->
|
||||
<div v-if="tab === 'flow'">...</div>
|
||||
|
||||
<!-- 新增：交互式步骤 -->
|
||||
<div v-if="tab === 'interactive'">
|
||||
<OfficialAccountStepInteractive
|
||||
v-if="currentSpecialistKey === 'wechat-official-account'"
|
||||
:step="currentStep"
|
||||
:workflow-state="workflowState"
|
||||
@select="handleStepSelect"
|
||||
@confirm="handleStepConfirm"
|
||||
/>
|
||||
<div v-else class="sp-empty">选择专员或任务以操作</div>
|
||||
</div>
|
||||
|
||||
<!-- 现有：产物 -->
|
||||
<div v-if="tab === 'arts'">...</div>
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
```
|
||||
|
||||
### 7.2 对话消息中的可交互卡片
|
||||
|
||||
复用现有的 `msg.skillResultCard` 机制：
|
||||
|
||||
```javascript
|
||||
// 工作流引擎完成选题步骤后，在对话消息中自动插入可交互卡片
|
||||
messages.value.push({
|
||||
role: 'assistant',
|
||||
content: '已生成 3 个选题候选，请选择：',
|
||||
skillResult: { topicCandidates: [...] },
|
||||
skillResultCard: markRaw(TopicCandidateCard), // 可交互的 Vue 组件
|
||||
timestamp: new Date().toLocaleTimeString(),
|
||||
})
|
||||
```
|
||||
|
||||
当用户点击卡片中的"选择这个"时：
|
||||
1. 调用 `executeOfficialAccountWorkflowStep(stepKey, { topic: selectedTopic })`
|
||||
2. 工作流自动推进到下一步
|
||||
3. 新的结果卡片出现在消息流中
|
||||
|
||||
### 7.3 数据流
|
||||
|
||||
```
|
||||
用户操作（对话 / 面板）
|
||||
↓
|
||||
调用专用 API（create / update / executeStep）
|
||||
↓
|
||||
后端工作流引擎执行
|
||||
↓
|
||||
更新 action_records_json + task_artifact
|
||||
↓
|
||||
前端轮询 / SSE / WebSocket 刷新
|
||||
↓
|
||||
更新 SpecialistPanel 状态
|
||||
↓
|
||||
如有需要，向对话消息中插入结果卡片
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 总结
|
||||
|
||||
公众号创作专员与对话框的兼容，核心不在于"有没有独立页面"，而在于**如何把结构化决策自然地嵌入对话工作流**。
|
||||
|
||||
**推荐路径：**
|
||||
1. 先实现 SpecialistPanel 扩展（方案 A），让工作流可交互
|
||||
2. 再实现对话消息中嵌入卡片（方案 C 的部分），让用户不切面板也能操作
|
||||
3. 如果确实需要更大编辑空间，再补充完整独立工作台页面
|
||||
|
||||
**关键原则：**
|
||||
- 对话引导，UI 执行
|
||||
- 决策点用卡片，编辑区用面板
|
||||
- 可见性层始终在线
|
||||
- 对话与 UI 双向同步
|
||||
|
||||
这不是"对话还是 UI"的二选一，而是**对话和 UI 各司其职的协作系统**。
|
||||
@@ -0,0 +1,41 @@
|
||||
# 20_Global_Workbench_Evolution 目录说明
|
||||
|
||||
本目录专门讨论全球主流软件工作台形态的历史演进，不承担当前系统架构合同职责，也不直接替代 `02_Architecture` 中的正式架构定义。
|
||||
|
||||
本目录的作用有三项：
|
||||
|
||||
1. 为 EAI 的交互与工作台设计提供跨时代参照系
|
||||
2. 把“对话式 AI 工作台”和传统 GUI、SaaS、协同工作台放在同一条历史线上比较
|
||||
3. 为后续 Workbench、专员工作流、技能运行面、xApp 承接面提供外部样本库
|
||||
|
||||
## 当前文件
|
||||
|
||||
- `GW01_全球主流软件工作台历史演进.md`
|
||||
- 总时间线文档
|
||||
- 讨论从 CLI / GUI 到 SaaS / 协同工作台，再到 Copilot / Agent Workbench 的连续演进
|
||||
|
||||
- `GW02_对话式AI工作台与传统UI分界判断.md`
|
||||
- 专题判断文档
|
||||
- 讨论"对话发起 + 结构化接管 + 工作流可见性"为什么会成为新一代 AI 工作台的主交互模式
|
||||
|
||||
- `GW03_专员工作交互形式分析.md`
|
||||
- 专题分析文档
|
||||
- 对平台中所有专员（通用助手、公众号创作专员、合同审查专员、售前方案专员、客户跟进专员、简历筛选与招聘专员、汇报专员等）逐项分析其启动方式、决策方式、执行方式、反馈方式
|
||||
- 给出每个专员"对话 vs 结构化 UI"的比例判断和交互设计建议
|
||||
|
||||
- `GW04_公众号创作专员可用性改进分析.md`
|
||||
- 专题分析文档
|
||||
- 分析公众号创作专员后端 100% 已实现、前端约 40% 的现状
|
||||
- 给出完整的前端工作流 UI 实现方案、交互设计、组件结构和工作量评估
|
||||
|
||||
- `GW05_公众号创作专员与对话框交互兼容分析.md`
|
||||
- 专题分析文档
|
||||
- 分析公众号创作专员工作流 UI 与当前对话框架构的兼容关系
|
||||
- 对比三种方案：扩展 SpecialistPanel、独立工作台页面、对话内嵌卡片 + 侧栏扩展
|
||||
- 给出分阶段实施路径：先让 SpecialistPanel 可交互 → 再在对话消息中嵌入卡片 → 可选完整独立页
|
||||
|
||||
## 使用原则
|
||||
|
||||
1. 本目录优先记录跨产品、跨代际、跨品类的演进判断
|
||||
2. 当前 EAI 的正式架构结论，仍以 `02_Architecture` 中的正式文档为准
|
||||
3. 当研究判断足够稳定时，可回写到 `02_Architecture` 形成正式合同
|
||||
Reference in New Issue
Block a user