feat: 同步知识库与工作台相关改动
This commit is contained in:
Jackzhou
@@ -26,6 +26,7 @@
|
||||
| `SY16_Ontology_Generalizes_Data_Actions_And_Workflows.md` | 本体如何让数据、动作、工作流一般化 |
|
||||
| `SY17_Workbench_UI_Wireframes.md` | 数字员工平台 UI 线框图（知识库固定 + 专员动态生长） |
|
||||
| `SY18_DWP_DW_ADW_Formal_Design_Contract.md` | DWP / DW / ADW 正式设计合同（供人和 AI 共用的对象基准） |
|
||||
| `SY19_Universal_Digital_Worker_Product_Planning.md` | 通用数字员工平台 V1.0 产品规划（先通用、后定制的产品打法收口） |
|
||||
|
||||
## 当前主线关系
|
||||
|
||||
@@ -42,3 +43,4 @@
|
||||
11. `SY16`：解释本体为何要把数据、动作、工作流提升为统一业务表达，服务六层架构理解与对象建模
|
||||
12. `SY17`：把六层架构落成数字员工平台工作台线框，明确平台不再是单一导航后台
|
||||
13. `SY18`：正式定义 DWP / DW / ADW 的结构合同、字段规范和 AI 生成规则
|
||||
14. `SY19`：把当前阶段产品路线正式收口为「先通用数字员工、后行业包与企业定制」
|
||||
|
||||
@@ -0,0 +1,519 @@
|
||||
# SY19 — 通用数字员工平台 V1.0 产品规划
|
||||
|
||||
> **版本：V1.0 | 最后更新：2026-08-24**
|
||||
|
||||
---
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文用于把当前项目从「知识库中心化的培训/考试平台」进一步收口为：
|
||||
|
||||
**一套先通用、后定制的数字员工平台产品路线。**
|
||||
|
||||
本文重点回答五个问题：
|
||||
|
||||
- 当前阶段到底做什么，不做什么
|
||||
- 为什么不直接对标 WorkBuddy 的高自由度路线
|
||||
- 第一阶段应该先沉淀哪些通用数字员工
|
||||
- 现有项目哪些能力可以直接复用，哪些能力需要补齐
|
||||
- 后续如何从通用包自然演进到行业包和企业定制
|
||||
|
||||
本文属于 SY03、SY04、SY18 之后的收口文档。它不替代平台战略，而是把当前阶段的产品打法定死。
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前判断
|
||||
|
||||
### 2.1 不直接做「高自由度 WorkBuddy」
|
||||
|
||||
WorkBuddy 的方向是高自由度、强定制、强执行型桌面智能体，这条路线的优势很明显，但对当前项目并不是最合适的第一步。
|
||||
|
||||
如果现在直接走这条路，会同时遇到几个问题：
|
||||
|
||||
- 产品边界太大，容易从培训系统、知识库、工作台、低代码平台一路发散
|
||||
- 不同企业之间复用性弱，难形成标准交付包
|
||||
- 权限、审核、知识边界、结果质量都更难控
|
||||
- 销售和交付阶段难讲清「标准版到底能直接帮客户做什么」
|
||||
|
||||
因此，当前项目不应该先做「无限自由的 AI 办公工作台」，而应该先做：
|
||||
|
||||
**标准化、可复制、可交付、可升级的通用数字员工平台。**
|
||||
|
||||
### 2.2 当前阶段的产品定义
|
||||
|
||||
项目当前阶段统一定义为：
|
||||
|
||||
**一个以知识库为底座、以数字员工为能力单元、面向企业通用办公场景的数字员工平台。**
|
||||
|
||||
关键词有四个：
|
||||
|
||||
- **知识底座**：所有数字员工都必须受知识空间、引用和权限边界约束
|
||||
- **能力单元**：面向用户的不是一个大而全 AI，而是一组职责明确的数字员工
|
||||
- **通用场景**：先覆盖跨行业共性工作，不先做重行业定制
|
||||
- **平台化交付**：可安装、可启停、可配置、可审核、可追溯
|
||||
|
||||
---
|
||||
|
||||
## 3. 当前阶段的产品原则
|
||||
|
||||
### 3.1 总原则
|
||||
|
||||
当前阶段的产品铁律只有一句话：
|
||||
|
||||
**先做通用数字员工产品包，不做无限自由平台。**
|
||||
|
||||
### 3.2 五条强约束
|
||||
|
||||
#### 原则 1：主界面从「问知识库」切到「把任务交给数字员工」
|
||||
|
||||
知识库仍然重要，但它应该退到后台成为数字员工的大脑底座。
|
||||
|
||||
面向用户的主叙事应改为：
|
||||
|
||||
- 我有哪些数字员工
|
||||
- 每个数字员工负责什么
|
||||
- 我应该把任务交给谁
|
||||
- 它现在推进到哪一步
|
||||
- 它交付了什么
|
||||
- 依据来自哪里
|
||||
- 哪一步需要我确认
|
||||
|
||||
#### 原则 2：每个数字员工必须职责清晰、边界明确
|
||||
|
||||
每个数字员工都必须说清楚：
|
||||
|
||||
- 它是谁
|
||||
- 它负责什么
|
||||
- 它不负责什么
|
||||
- 它可以访问哪些知识和资源
|
||||
- 它最后交付什么结果
|
||||
|
||||
不允许继续把多个能力混成一个「什么都能干的大助手」。
|
||||
|
||||
#### 原则 3：所有结果都要可追溯
|
||||
|
||||
这是当前项目相对 WorkBuddy 最值得保留并放大的优势。
|
||||
|
||||
所有数字员工输出都要尽量具备：
|
||||
|
||||
- 命中层级
|
||||
- 原文引用
|
||||
- 来源证据
|
||||
- 任务记录
|
||||
- 审核状态
|
||||
|
||||
这既是企业可信度要求，也是后续做合规、认证、复盘、经营分析的基础。
|
||||
|
||||
#### 原则 4：先做可配置，不做完全开放式编排
|
||||
|
||||
当前阶段只开放以下几类配置：
|
||||
|
||||
- 名称与描述
|
||||
- 适用部门/岗位
|
||||
- 绑定知识空间
|
||||
- 绑定模板
|
||||
- 输出格式
|
||||
- 审核人
|
||||
- 是否启用某连接器/能力
|
||||
|
||||
当前阶段不开放以下能力为一线主路径：
|
||||
|
||||
- 任意工作流编排
|
||||
- 任意动作拼装
|
||||
- 自定义 DSL
|
||||
- 完全开放的 Skill 开发模式
|
||||
- 无限自由的连接器联动
|
||||
|
||||
#### 原则 5：通用包优先，行业包和企业定制后置
|
||||
|
||||
第一阶段先做通用包，是为了先形成：
|
||||
|
||||
- 明确的产品边界
|
||||
- 统一的数据结构
|
||||
- 统一的任务闭环
|
||||
- 统一的交付机制
|
||||
- 可复制的商业版本
|
||||
|
||||
行业包、企业定制都必须建立在这套标准底座之上。
|
||||
|
||||
---
|
||||
|
||||
## 4. 产品心智模型
|
||||
|
||||
### 4.1 平台对用户的呈现方式
|
||||
|
||||
对用户来说，平台不是一个聊天框，而应该是一组可调用的数字员工。
|
||||
|
||||
统一心智如下：
|
||||
|
||||
```
|
||||
企业数字员工平台
|
||||
├─ 专员市场：我有哪些数字员工可安装/可启用
|
||||
├─ 专员工作区：某个数字员工怎么接任务、交付结果
|
||||
├─ 任务中心：事项现在做到哪一步
|
||||
├─ 交付中心：已经产出过什么结果
|
||||
└─ 知识底座：这些数字员工基于哪些可信知识在工作
|
||||
```
|
||||
|
||||
### 4.2 每个数字员工的最小定义
|
||||
|
||||
在 SY18 的「信源 / 动作 / 结果 / 权限」基础上，当前阶段进一步面向产品统一为五件套：
|
||||
|
||||
1. **角色**：它是谁，负责什么
|
||||
2. **知识**：它能访问哪些知识空间、FAQ、模板、案例
|
||||
3. **动作**：它能执行哪些标准动作
|
||||
4. **交付**：它能产出什么
|
||||
5. **审核**：哪些结果需要人确认
|
||||
|
||||
可理解为：
|
||||
|
||||
```
|
||||
数字员工 = 角色 + 知识 + 动作 + 交付 + 审核
|
||||
```
|
||||
|
||||
其中：
|
||||
|
||||
- SY18 更偏业务前台的呈现模型
|
||||
- 本文更偏当前产品阶段的标准化定义模型
|
||||
|
||||
两者不冲突，可共同存在。
|
||||
|
||||
---
|
||||
|
||||
## 5. 第一阶段：先做 4 个通用数字员工
|
||||
|
||||
当前阶段不建议同时铺很多专员。第一批只做 4 个通用数字员工，确保每个都能真正形成闭环。
|
||||
|
||||
### 5.1 知识运营专员
|
||||
|
||||
**定位：** 负责知识资料整理、摘要、FAQ 沉淀、知识空间维护的通用专员。
|
||||
|
||||
**典型任务：**
|
||||
|
||||
- 整理上传资料
|
||||
- 提取重点摘要
|
||||
- 生成 FAQ 初稿
|
||||
- 标记失效知识
|
||||
- 按主题归档
|
||||
|
||||
**交付结果：**
|
||||
|
||||
- FAQ 条目
|
||||
- 知识摘要
|
||||
- 知识卡片
|
||||
- 待审核知识项
|
||||
|
||||
**为什么优先做：**
|
||||
|
||||
- 与当前项目知识入库、审批、FAQ、检索能力直接衔接
|
||||
- 各行业通用
|
||||
- 能快速体现平台的知识底座价值
|
||||
|
||||
### 5.2 培训考试专员
|
||||
|
||||
**定位：** 负责岗位应学范围、题库生成、组卷、学习认证建议的通用专员。
|
||||
|
||||
**典型任务：**
|
||||
|
||||
- 基于知识生成题目初稿
|
||||
- 生成岗位应学清单
|
||||
- 推荐学习路径
|
||||
- 输出岗位考试建议
|
||||
- 生成认证结果说明
|
||||
|
||||
**交付结果：**
|
||||
|
||||
- 岗位学习包
|
||||
- 试卷/题目初稿
|
||||
- 认证建议
|
||||
- 补训建议
|
||||
|
||||
**为什么优先做：**
|
||||
|
||||
- 与当前项目最成熟的培训、考试、岗位映射能力强复用
|
||||
- 是现有底座最快能升级成数字员工形态的一块
|
||||
|
||||
### 5.3 内容生成专员
|
||||
|
||||
**定位：** 负责结构化文档、周报、会议纪要、培训材料、FAQ 卡片生成的通用专员。
|
||||
|
||||
**典型任务：**
|
||||
|
||||
- 生成会议纪要
|
||||
- 生成周报/月报
|
||||
- 输出培训讲义
|
||||
- 输出产品说明/方案初稿
|
||||
- 输出标准 FAQ 卡片
|
||||
|
||||
**交付结果：**
|
||||
|
||||
- Word/Markdown/HTML 文档
|
||||
- 培训材料初稿
|
||||
- 话术/FAQ 卡片
|
||||
- 结构化摘要
|
||||
|
||||
**为什么优先做：**
|
||||
|
||||
- 企业通用需求高频
|
||||
- 最容易让客户快速感知价值
|
||||
- 适合作为“任务 -> 草稿 -> 审核 -> 发布”的标准闭环示范
|
||||
|
||||
### 5.4 任务推进专员
|
||||
|
||||
**定位：** 负责任务拆解、状态推进、待确认项提醒、结果归档的通用专员。
|
||||
|
||||
**典型任务：**
|
||||
|
||||
- 接收任务并拆解步骤
|
||||
- 跟踪事项状态
|
||||
- 提醒待确认项
|
||||
- 汇总风险点
|
||||
- 归档交付结果
|
||||
|
||||
**交付结果：**
|
||||
|
||||
- 任务清单
|
||||
- 推进状态
|
||||
- 风险提醒
|
||||
- 交付归档包
|
||||
|
||||
**为什么优先做：**
|
||||
|
||||
- 这是把聊天式 AI 拉成工作流式 AI 的关键
|
||||
- 与当前 `worker_task`、`worker_artifact` 等结构最接近
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前项目能力复用判断
|
||||
|
||||
### 6.1 已经具备、可直接复用的底座
|
||||
|
||||
结合当前 PRD、PROJECT_STATE 和代码现状，以下能力已经具备较强复用价值：
|
||||
|
||||
#### 1. 知识底座
|
||||
|
||||
- 素材上传、审批、入库
|
||||
- 文档切片与检索
|
||||
- FAQ / 混合检索 / 引用链路
|
||||
- 知识空间与工作台知识问答
|
||||
|
||||
#### 2. 人群与学习底座
|
||||
|
||||
- 岗位映射
|
||||
- 岗位应学清单
|
||||
- 考试蓝图
|
||||
- 错题本、证书、学习档案、能力雷达
|
||||
|
||||
#### 3. 平台雏形
|
||||
|
||||
- 专员市场
|
||||
- 控制台
|
||||
- 工作台概览
|
||||
- Studio / Market / KnowledgeHub 等前台入口
|
||||
|
||||
#### 4. 任务与交付雏形
|
||||
|
||||
- `worker_task`
|
||||
- `worker_artifact`
|
||||
- 工作台待办、风险、最近交付物
|
||||
|
||||
### 6.2 当前仍然偏弱、需要补齐的关键能力
|
||||
|
||||
#### 1. 数字员工统一定义仍不够收口
|
||||
|
||||
虽然已有 specialist 模型，但当前字段仍偏展示/概念堆叠，需要进一步统一成标准产品模型。
|
||||
|
||||
#### 2. 任务闭环还不够完整
|
||||
|
||||
需要把任务、执行、产出、审核、发布五个阶段拉通，而不是停留在卡片展示层。
|
||||
|
||||
#### 3. 模板中心还不够清晰
|
||||
|
||||
通用数字员工一定要有可复用的模板体系，否则很难形成跨企业复用。
|
||||
|
||||
#### 4. 安装与配置机制还要更产品化
|
||||
|
||||
需要更明确地区分：
|
||||
|
||||
- 哪些专员是已安装
|
||||
- 哪些专员是试用
|
||||
- 哪些专员属于通用包
|
||||
- 哪些专员属于行业包
|
||||
- 某个专员绑定了哪些知识空间、模板、部门、岗位
|
||||
|
||||
---
|
||||
|
||||
## 7. 当前阶段必须补齐的产品闭环
|
||||
|
||||
如果要把当前项目真正升级成「通用数字员工平台」，至少要补齐以下闭环。
|
||||
|
||||
### 7.1 数字员工定义闭环
|
||||
|
||||
每个数字员工都必须明确：
|
||||
|
||||
- 基本信息：名称、类型、适用范围、状态
|
||||
- 角色边界：负责什么、不负责什么
|
||||
- 知识边界：绑定哪些知识空间/FAQ/案例
|
||||
- 动作边界：可执行哪些标准动作
|
||||
- 交付边界：输出哪些标准结果
|
||||
- 审核边界：哪些需要人工确认
|
||||
|
||||
### 7.2 任务闭环
|
||||
|
||||
统一任务生命周期建议为：
|
||||
|
||||
```
|
||||
新任务 -> 待执行 -> 执行中 -> 草稿待确认 -> 已确认 -> 已发布/已归档
|
||||
```
|
||||
|
||||
无论是知识整理、内容生成、培训认证还是任务推进，都应落在同一套任务状态机里。
|
||||
|
||||
### 7.3 交付闭环
|
||||
|
||||
每个交付结果都建议带上：
|
||||
|
||||
- 交付类型
|
||||
- 来源任务
|
||||
- 来源数字员工
|
||||
- 版本
|
||||
- 审核状态
|
||||
- 知识依据/引用
|
||||
- 创建时间
|
||||
- 发布/归档状态
|
||||
|
||||
### 7.4 审核闭环
|
||||
|
||||
通用阶段不做复杂审批流，但必须有最小审核链：
|
||||
|
||||
- 哪类产出允许直接查看
|
||||
- 哪类产出必须确认后才能发布
|
||||
- 谁是默认确认人
|
||||
- 哪些风险必须提示
|
||||
|
||||
---
|
||||
|
||||
## 8. 当前阶段明确不做的事
|
||||
|
||||
为了防止产品再次发散，以下能力在当前阶段明确不作为主目标：
|
||||
|
||||
### 8.1 不做完全开放式 WorkBuddy 路线
|
||||
|
||||
不追求：
|
||||
|
||||
- 用户一句话就能自由编排一切
|
||||
- 桌面级全权限执行
|
||||
- 无限开放的工作流拼装
|
||||
- 无限开放的插件/Skill 开发
|
||||
|
||||
### 8.2 不做重行业定制优先
|
||||
|
||||
不先围绕某一个行业重做数据模型、流程和页面。
|
||||
|
||||
当前阶段行业包只作为第二阶段目标，不作为第一阶段主路径。
|
||||
|
||||
### 8.3 不做“什么都能干”的单一大助手
|
||||
|
||||
不再强化一个泛化聊天助手来承接所有任务。
|
||||
|
||||
当前阶段要坚持：
|
||||
|
||||
**多个职责明确的数字员工 > 一个无限泛化的大助手。**
|
||||
|
||||
---
|
||||
|
||||
## 9. 三阶段路线图
|
||||
|
||||
### 9.1 阶段一：通用数字员工 1.0
|
||||
|
||||
**目标：** 做出可卖、可演示、可复制的标准版产品。
|
||||
|
||||
**核心建设项：**
|
||||
|
||||
- 4 个通用数字员工
|
||||
- 专员市场
|
||||
- 专员工作区
|
||||
- 任务/交付/审核闭环
|
||||
- 模板中心
|
||||
- 知识引用与可追溯
|
||||
- 部门/岗位/知识空间绑定
|
||||
|
||||
**阶段结果：**
|
||||
|
||||
平台能够对外统一表达为：
|
||||
|
||||
> 一套可安装、可审核、可追溯的企业通用数字员工平台，先覆盖知识运营、培训考试、内容生成、任务推进四类共性场景。
|
||||
|
||||
### 9.2 阶段二：行业数字员工包 1.0
|
||||
|
||||
**目标：** 在通用底座之上，生长行业包，而不是重做底座。
|
||||
|
||||
优先建议的行业方向：
|
||||
|
||||
- 销售赋能
|
||||
- 合规审查
|
||||
- 培训认证
|
||||
|
||||
这些方向都与当前知识底座和培训底座天然接近，落地成本相对最低。
|
||||
|
||||
### 9.3 阶段三：企业半定制能力
|
||||
|
||||
**目标：** 在不破坏标准产品的前提下，开放企业可配置能力。
|
||||
|
||||
建议逐步开放：
|
||||
|
||||
- 自定义模板
|
||||
- 自定义知识空间绑定
|
||||
- 自定义专员副本
|
||||
- 自定义连接器绑定
|
||||
- 有边界的工作流配置
|
||||
|
||||
不建议一开始就完全开放到底层编排。
|
||||
|
||||
---
|
||||
|
||||
## 10. 对现有前后端的指导意义
|
||||
|
||||
### 10.1 前端
|
||||
|
||||
后续前端主轴应继续从「模块中心」转向「数字员工中心」：
|
||||
|
||||
- 首页/工作台强调任务与数字员工
|
||||
- 市场页强调专员包安装与分类
|
||||
- 工坊页强调装配与配置，不强调无限自由编排
|
||||
- 知识库页退到数字员工底座与证据支撑角色
|
||||
|
||||
### 10.2 后端
|
||||
|
||||
后续后端优先保障以下统一模型：
|
||||
|
||||
- specialist 的标准定义
|
||||
- worker_task 的统一状态机
|
||||
- worker_artifact 的统一交付模型
|
||||
- knowledge_space 的强边界约束
|
||||
- 模板中心与专员配置关系
|
||||
|
||||
### 10.3 商业表达
|
||||
|
||||
后续对外讲述口径建议统一为：
|
||||
|
||||
> 我们不是先做一个无限自由的 AI 工作台，而是先做一组企业拿来就能用、可审核、可追溯、可升级的数字员工产品包。
|
||||
|
||||
这比「什么都能做」更容易被企业理解，也更容易成交。
|
||||
|
||||
---
|
||||
|
||||
## 11. 最终结论
|
||||
|
||||
当前项目的正确路线不是：
|
||||
|
||||
**先追 WorkBuddy 的自由度，再想办法收回来。**
|
||||
|
||||
而应该是：
|
||||
|
||||
**先把数字员工做成标准化产品包，再在这个底座上逐步开放行业包和企业定制。**
|
||||
|
||||
因此，当前阶段的产品主线正式定为：
|
||||
|
||||
> **先通用，后定制；先产品包，后自由平台。**
|
||||
|
||||
这是后续所有页面、模型、任务系统、交付系统、模板系统的上位约束。
|
||||
Reference in New Issue
Block a user