docs: 重构仓库文档目录并迁移训练素材
按当前架构重组 docs 目录，统一中文命名与目录分层，并将训练原材料迁移到独立目录以保持架构文档边界清晰。
This commit is contained in:
eaiadmin
@@ -0,0 +1,267 @@
|
||||
# 六层架构与三对象建设重点阶段性复盘
|
||||
|
||||
> 日期：2026-09-17
|
||||
> 性质：对前序讨论的客观复盘，不替代既有总架构文档
|
||||
> 关联文档：
|
||||
> - `docs/01_System_Overall/SY21_统一角色技能动作架构.md`
|
||||
> - `docs/01_System_Overall/SY22_角色技能应用统一任务架构.md`
|
||||
> - `docs/02_Architecture/对象标准化与解耦总则.md`
|
||||
|
||||
---
|
||||
|
||||
## 一、这份复盘要解决什么
|
||||
|
||||
前序讨论中，围绕以下问题进行了多轮来回：
|
||||
|
||||
- 现有六层架构是否还成立
|
||||
- 专员 / 技能 / 应用三个对象应不应该成为当前建设重点
|
||||
- 当前是否需要优先补绑定关系
|
||||
- AionUi 的经验应该学到什么程度
|
||||
|
||||
这份复盘的目标不是重写总架构，
|
||||
而是把前面讨论中哪些判断成立、哪些判断说过头了，正式收口。
|
||||
|
||||
---
|
||||
|
||||
## 二、已经确认成立的判断
|
||||
|
||||
### 1. 当前系统确实处于“后端有对象表，前端曾长期存在静态目录”的混合态
|
||||
|
||||
这个判断成立。
|
||||
|
||||
虽然近期已经持续推进目录解耦，
|
||||
但从整体历史包袱和代码结构看，
|
||||
系统前期确实存在：
|
||||
|
||||
- 后端有对象模型和接口
|
||||
- 前端以静态配置驱动大量真实目录
|
||||
|
||||
这也是后续做对象标准化与目录统一的现实起点。
|
||||
|
||||
### 2. “先强对象，再补关系”是当前阶段更合理的优先级
|
||||
|
||||
这个判断成立。
|
||||
|
||||
原因不是关系层不重要，
|
||||
而是当前对象成熟度还没有达到“复杂关系优先”的阶段：
|
||||
|
||||
- 专员还没有形成强编排能力
|
||||
- 技能还没有强壮到值得被大量稳定复用
|
||||
- 应用当前更像产品化入口，而不是复杂能力编排器
|
||||
|
||||
因此，当前更合理的顺序是：
|
||||
|
||||
```text
|
||||
先把专员、技能、应用各自做强
|
||||
再在成熟度足够时补关系层
|
||||
```
|
||||
|
||||
### 3. AionUi 最值得学习的是对象资产化，而不是总架构替换
|
||||
|
||||
这个判断成立。
|
||||
|
||||
当前对 AionUi 的借鉴边界应明确为：
|
||||
|
||||
- 学它的助手/员工对象化
|
||||
- 学它的规则资产化
|
||||
- 学它的技能包思维
|
||||
- 学它的运行态工作台思维
|
||||
|
||||
不应盲目学习：
|
||||
|
||||
- Electron 外壳
|
||||
- 个人工具导向产品形态
|
||||
- 创意娱乐类助手堆叠
|
||||
- 过度端侧逻辑
|
||||
|
||||
---
|
||||
|
||||
## 三、前序讨论中说过头的地方
|
||||
|
||||
### 1. 不能因为三个对象重要，就推导出“应该改总架构”
|
||||
|
||||
这个推导证据不足。
|
||||
|
||||
三个对象重要，说明：
|
||||
|
||||
- 第五层对象层需要做强
|
||||
- 第六层运行治理层需要做实
|
||||
|
||||
但这并不自动构成“六层架构应被替代”的理由。
|
||||
|
||||
要否定既有总架构，至少应出现下列情况之一：
|
||||
|
||||
1. 层级职责定义错误
|
||||
2. 多层长期重叠、互相冲突
|
||||
3. 关键对象在原架构中无法安放
|
||||
4. 原架构直接阻碍产品落地
|
||||
|
||||
截至本次复盘，没有充分证据表明六层架构已满足上述否定条件。
|
||||
|
||||
### 2. “当前建设重点”不能被误说成“主架构发生替换”
|
||||
|
||||
更准确的表达应为：
|
||||
|
||||
**六层架构不变，当前建设重点落在第五层对象层与第六层运行治理层。**
|
||||
|
||||
也就是说：
|
||||
|
||||
- 这是架构内聚焦
|
||||
- 不是架构替换
|
||||
|
||||
---
|
||||
|
||||
## 四、关于六层架构的最终判断
|
||||
|
||||
## 4.1 六层架构继续成立
|
||||
|
||||
`SY21` 与 `SY22` 形成的六层总架构继续有效：
|
||||
|
||||
1. 外部连接层
|
||||
2. 本体与语义上下文层
|
||||
3. 总线与编排层
|
||||
4. 能力层
|
||||
5. 对象层
|
||||
6. 工作台与运行治理层
|
||||
|
||||
特别是 `SY22` 已经明确把第五层升级为：
|
||||
|
||||
```text
|
||||
对象层（Expert / Skill / App）
|
||||
```
|
||||
|
||||
这说明六层架构本身已经能够容纳“专员 / 技能 / 应用”三类核心对象，
|
||||
并不存在“对象出现后就装不下”的结构性问题。
|
||||
|
||||
## 4.2 六层架构仍然有意义
|
||||
|
||||
六层架构的意义在于它仍然能解释整个平台为什么成立：
|
||||
|
||||
- 外部系统如何接入
|
||||
- 语义和对象如何统一
|
||||
- 能力如何分层
|
||||
- 任务如何运行
|
||||
- 治理如何落地
|
||||
|
||||
因此它仍应继续作为：
|
||||
|
||||
- 平台总架构
|
||||
- 长期演进底图
|
||||
- 文档与治理总语言
|
||||
|
||||
而不是被轻易推翻。
|
||||
|
||||
## 4.3 当前不需要改架构，当前需要做的是在原架构内把重点层做强
|
||||
|
||||
当前最合理的做法不是改层数，
|
||||
而是继续在既有六层框架内推进：
|
||||
|
||||
- 第五层：对象标准化、对象独立化、对象目录统一
|
||||
- 第六层：任务容器、状态、产物、留痕、项目运行统一
|
||||
|
||||
第一到第四层仍然成立，
|
||||
但当前不应继续投入过多抽象设计精力。
|
||||
|
||||
---
|
||||
|
||||
## 五、关于三个对象的当前建设重点
|
||||
|
||||
### 1. 专员
|
||||
|
||||
当前优先级应放在：
|
||||
|
||||
- 身份稳定
|
||||
- 规则稳定
|
||||
- 开场与引导稳定
|
||||
- 能承接任务
|
||||
|
||||
而不是强求它现在就大量调技能。
|
||||
|
||||
### 2. 技能
|
||||
|
||||
当前优先级应放在：
|
||||
|
||||
- 单独拿出来就有价值
|
||||
- 输入输出稳定
|
||||
- 结果可靠
|
||||
- 产物真实可用
|
||||
|
||||
技能不够强时，专员大量调用技能只会放大不稳定性。
|
||||
|
||||
### 3. 应用
|
||||
|
||||
当前优先级应放在：
|
||||
|
||||
- 成为真正可用的产品化入口
|
||||
- 拥有清晰主界面
|
||||
- 承载状态、结果和留痕
|
||||
- 直接解决某类工作场景
|
||||
|
||||
当前不应为了结构完整性而要求 App 过早承担复杂编排职责。
|
||||
|
||||
---
|
||||
|
||||
## 六、关于绑定关系的阶段性判断
|
||||
|
||||
绑定关系仍然重要，
|
||||
但对当前阶段而言，
|
||||
它不是最高优先级。
|
||||
|
||||
更准确的判断是：
|
||||
|
||||
- 长期看，关系层必须存在
|
||||
- 当前看，优先级低于对象本身做强
|
||||
|
||||
因此当前应坚持：
|
||||
|
||||
```text
|
||||
先强对象，再补关系
|
||||
先做成立，再做复杂协作
|
||||
```
|
||||
|
||||
等到以下信号稳定出现时，再提高关系层优先级：
|
||||
|
||||
- 一个专员稳定复用多种技能
|
||||
- 一个技能被多个专员反复复用
|
||||
- 一个应用需要切换默认专员或能力组合
|
||||
- 后台出现真实的配置、运营和灰度需求
|
||||
|
||||
---
|
||||
|
||||
## 七、与 AionUi 的客观比较
|
||||
|
||||
当前更准确的比较结论是：
|
||||
|
||||
- 我们的六层底座和企业化治理能力，比 AionUi 更完整
|
||||
- AionUi 在上层对象资产化、规则资产化、技能包化方面更成熟
|
||||
|
||||
因此：
|
||||
|
||||
- 不需要因为学习 AionUi 而推翻现有六层总架构
|
||||
- 需要借鉴 AionUi 的，是第五层对象层如何做成真正产品资产
|
||||
|
||||
换句话说：
|
||||
|
||||
**AionUi 更值得学习的是“对象如何做强”，不是“总架构如何重画”。**
|
||||
|
||||
---
|
||||
|
||||
## 八、本次复盘后的正式结论
|
||||
|
||||
本次复盘后，正式收敛为以下判断：
|
||||
|
||||
1. 六层架构继续成立，当前没有充分证据否定它
|
||||
2. 当前不改总架构，而是在原架构内强化重点层
|
||||
3. 当前重点是第五层对象层与第六层运行治理层
|
||||
4. 专员 / 技能 / 应用应先各自独立做强
|
||||
5. 绑定关系重要，但不是当前第一优先级
|
||||
6. 学习 AionUi，应重点学习对象资产化，不应机械替换总架构
|
||||
|
||||
最终可统一表述为：
|
||||
|
||||
```text
|
||||
六层架构不变；
|
||||
当前优化重点放在第五层对象层与第六层运行治理层；
|
||||
先把专员、技能、应用各自做强，
|
||||
再在成熟度足够时补关系层和更复杂的协作编排。
|
||||
```
|
||||
@@ -0,0 +1,14 @@
|
||||
# History_And_Retrospectives
|
||||
|
||||
本目录用于存放系统总体层面的阶段性复盘、历史收口稿与不再作为当前总纲的过程性文档。
|
||||
|
||||
当前包含两类内容：
|
||||
|
||||
1. 阶段复盘文件
|
||||
2. `系统演进旧稿/` 中的旧版总纲、方案稿、推演稿与过渡命名稿
|
||||
|
||||
归档原则：
|
||||
|
||||
1. 仍然作为当前正式总纲的内容，继续留在 `01_System_Overall` 主层
|
||||
2. 带明显日期、阶段性、复盘性质的文档，归入本目录
|
||||
3. 被现行文档替代的旧版 `SYxx` 文档，不再与现行文档并列，统一转入 `系统演进旧稿/`
|
||||
+1
-1
@@ -3,7 +3,7 @@
|
||||
> **版本：V1.0 | 最后更新：2026-08-16**
|
||||
|
||||
> 2026-09-16 架构同步说明：
|
||||
> 本文档保留“知识库中心化平台战略”视角，但当前正式口径已与 `SY21_Unified_Role_Skill_Action_Architecture.md`、`SY22_Role_Skill_App_Unified_Task_Architecture.md` 对齐。
|
||||
> 本文档保留“知识库中心化平台战略”视角，但当前正式口径已与 `SY21_统一角色技能动作架构.md`、`SY22_角色技能应用统一任务架构.md` 对齐。
|
||||
> 后续统一采用：
|
||||
> - 对外：`专家 / 技能 / 长程APP / 知识库 / 连接器目录`
|
||||
> - 对内：`expert / skill / app / action / connector / policy`
|
||||
+3
-3
@@ -19,10 +19,10 @@
|
||||
|
||||
相关参考文档：
|
||||
|
||||
- [SY03_Knowledge_Centric_Agent_Platform_Strategy.md](file:///home/eaiadmin/eaifiles/codebase/pj0231-eai_agentplatforming/docs/01_System_Overall/SY03_Knowledge_Centric_Agent_Platform_Strategy.md)
|
||||
- [SY03_知识中心型智能体平台战略.md](file:///home/eaiadmin/eaifiles/codebase/pj0231-eai_agentplatforming/docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY03_知识中心型智能体平台战略.md)
|
||||
- [09_Research/wechat/叶小钗](file:///home/eaiadmin/eaifiles/codebase/pj0231-eai_agentplatforming/docs/09_Research/wechat/%E5%8F%B6%E5%B0%8F%E9%92%97)（专家/专家团、任务系统、生产级 Agent 工程清单）
|
||||
- [SY15_Terminology_Benchmark_Ontology_Semantic_Layer_Object_Layer.md](file:///home/eaiadmin/eaifiles/codebase/pj0235-eai_agentplatform/docs/01_System_Overall/SY15_Terminology_Benchmark_Ontology_Semantic_Layer_Object_Layer.md)
|
||||
- [SY16_Ontology_Generalizes_Data_Actions_And_Workflows.md](file:///home/eaiadmin/eaifiles/codebase/pj0235-eai_agentplatform/docs/01_System_Overall/SY16_Ontology_Generalizes_Data_Actions_And_Workflows.md)
|
||||
- [SY15_术语基准本体语义层与对象层.md](file:///home/eaiadmin/eaifiles/codebase/pj0235-eai_agentplatform/docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY15_术语基准本体语义层与对象层.md)
|
||||
- [SY16_本体泛化数据动作与工作流.md](file:///home/eaiadmin/eaifiles/codebase/pj0235-eai_agentplatform/docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY16_本体泛化数据动作与工作流.md)
|
||||
|
||||
---
|
||||
|
||||
+8
-9
@@ -4,7 +4,7 @@
|
||||
|
||||
> 2026-09-16 口径同步说明：
|
||||
> 本文档属于早期工作台线框推演稿，保留“知识库固定 + 业务应用动态生长”的核心判断。
|
||||
> 当前正式产品命名与一级导航请以 `SY22_Role_Skill_App_Unified_Task_Architecture.md` 为准：
|
||||
> 当前正式产品命名与一级导航请以 `SY22_角色技能应用统一任务架构.md` 为准：
|
||||
> - `新建任务 / 项目 / 专员·技能·APP·连接器 / 长程APP / 知识库 / 后台管理 / 我的`
|
||||
> - 文中出现的“专员工作区 / 我的应用 / 市场 / 工坊 / 控制台”，应理解为当前 `长程APP / 对象目录 / 后台管理` 的早期表达
|
||||
> - 文中“专员”语义统一按当前 `专家（Expert）` 理解
|
||||
@@ -123,12 +123,11 @@
|
||||
|---------------------| | Artifacts |
|
||||
| 专员工作区 | | Evidence |
|
||||
| - 通用专员 | | Risks |
|
||||
| - 培训交付专员 | | |
|
||||
| - 行业专员 | | |
|
||||
| - 售前方案专员 | | Risks |
|
||||
| - 合同审查专员 | | |
|
||||
| - 履约跟单专员 | | |
|
||||
| - 客户跟进专员 | | |
|
||||
| - 招聘筛选专员 | | |
|
||||
|---------------------|-----------------------------------------------------|---------------------|
|
||||
| 后台 | Optional Bottom Panel: event / replay / logs / trace |
|
||||
| - 市场 | |
|
||||
@@ -165,15 +164,15 @@
|
||||
| [我的待办] [我的业务流] [最近交付物] [高风险事项] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| +-------------------------+ +-------------------------+ +-------------------------+ |
|
||||
| | 培训交付专员 | | 售前方案专员 | | 合同审查专员 | |
|
||||
| | 通用专员 / 训练运营 | | 行业专员 / 售前 | | 行业专员 / 法务 | |
|
||||
| | 3 个待办 / 1 个逾期 | | 2 个待审批 / 1 个高风险 | | 5 个进行中 | |
|
||||
| | 公众号专员 | | 售前方案专员 | | 合同审查专员 | |
|
||||
| | 通用专员 / 内容运营 | | 行业专员 / 售前 | | 行业专员 / 法务 | |
|
||||
| | 3 个待办 / 1 篇待发布 | | 2 个待审批 / 1 个高风险 | | 5 个进行中 | |
|
||||
| | [进入应用] | | [进入应用] | | [进入应用] | |
|
||||
| +-------------------------+ +-------------------------+ +-------------------------+ |
|
||||
| +-------------------------+ +-------------------------+ +-------------------------+ |
|
||||
| | 履约跟单专员 | | 客户跟进专员 | | 新安装专员推荐 | |
|
||||
| | 行业专员 / 货代履约 | | 行业专员 / 客户成功 | | 通用 / 行业双层浏览 | |
|
||||
| | 1 个异常 / 2 个节点延迟 | | 6 个待跟进 | | [查看专员市场] | |
|
||||
| | 招聘筛选专员 | | 客户跟进专员 | | 新安装专员推荐 | |
|
||||
| | 行业专员 / 招聘推进 | | 行业专员 / 客户成功 | | 通用 / 行业双层浏览 | |
|
||||
| | 5 份待筛选 / 3 封待归档 | | 6 个待跟进 | | [查看专员市场] | |
|
||||
| | [进入应用] | | [进入应用] | | | |
|
||||
| +-------------------------+ +-------------------------+ +-------------------------+ |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
+60
@@ -455,6 +455,66 @@ WorkBuddy 的方向是高自由度、强定制、强执行型桌面智能体，
|
||||
|
||||
这些方向都与当前知识底座和培训底座天然接近，落地成本相对最低。
|
||||
|
||||
#### 9.2.1 销售流程数字员工包定义
|
||||
|
||||
销售场景不应按“动作”拆对象，而应按销售流程中的真实岗位拆对象。
|
||||
|
||||
因此，销售方向的行业包建议先收口为 4 个数字员工：
|
||||
|
||||
| 数字员工 | 对应真实岗位 | 所处流程 | 主责 |
|
||||
|---|---|---|---|
|
||||
| 销售专员 | 销售代表 / 客户经理 / 销售顾问 | 获客、筛选、初步沟通、商机推进 | 把客户从线索推进到明确商机 |
|
||||
| 售前解决方案专员 | 售前顾问 / 解决方案顾问 / 售前工程师 | 需求澄清、方案设计、演示、POC | 把客户需求转成可成交的解决方案 |
|
||||
| 商务合同专员 | 商务专员 / 合同专员 / 投标专员 | 报价、商务条款、合同流转、审批协同 | 把成交条件和合同流程跑通 |
|
||||
| 客户成功专员 | 客户成功 / 客户运营 / 客户经理（续约） | 上线后推进、使用经营、续约增购 | 把已签客户经营好、留住并做大 |
|
||||
|
||||
统一边界如下：
|
||||
|
||||
- **签约前**：销售专员、售前解决方案专员、商务合同专员共同负责
|
||||
- **签约后**：客户成功专员主责
|
||||
|
||||
不建议继续使用以下名字作为销售数字员工：
|
||||
|
||||
- `售前方案专员`
|
||||
- `客户跟进专员`
|
||||
- `培训交付专员`
|
||||
|
||||
原因不是“名字不好听”，而是它们描述的分别是：
|
||||
|
||||
- 结果物
|
||||
- 动作
|
||||
- 长流程交付环节
|
||||
|
||||
而不是现实企业里稳定存在、职责边界明确的岗位对象。
|
||||
|
||||
##### 销售专员
|
||||
|
||||
**定位：** 销售前台推进角色，负责把潜在线索转成真实商机。
|
||||
**输入：** 线索名单、客户资料、历史沟通记录、基础产品资料。
|
||||
**输出：** 客户画像、商机判断、跟进记录、下一步动作建议。
|
||||
**不负责：** 深度方案设计、合同审批流转、签约后长期经营。
|
||||
|
||||
##### 售前解决方案专员
|
||||
|
||||
**定位：** 售前技术与方案角色，负责把客户问题转成可理解、可验证、可成交的解决方案。
|
||||
**输入：** 客户背景、需求摘要、行业方案、产品能力、案例与约束。
|
||||
**输出：** 需求澄清纪要、解决方案草案、演示材料、POC 建议、风险边界说明。
|
||||
**不负责：** 线索开发、商务报价、签约后客户经营。
|
||||
|
||||
##### 商务合同专员
|
||||
|
||||
**定位：** 成交条件和合同流程推进角色，负责把客户意向落成可签约、可审批、可执行的正式交易条件。
|
||||
**输入：** 客户成交条件、方案边界、报价规则、合同模板、审批规则。
|
||||
**输出：** 报价单、商务条款摘要、合同版本记录、审批进度、待确认事项。
|
||||
**不负责：** 前台获客、深度需求分析、签约后运营。
|
||||
|
||||
##### 客户成功专员
|
||||
|
||||
**定位：** 签约后客户经营角色，负责让客户真正上线、真正使用，并持续续约和增购。
|
||||
**输入：** 已签约客户资料、上线进度、培训记录、使用数据、客户反馈。
|
||||
**输出：** 客户健康度判断、推进记录、风险客户清单、续约与增购机会清单。
|
||||
**不负责：** 前期获客与商机开发、合同审批流转、替代交付系统本身。
|
||||
|
||||
### 9.3 阶段三：企业半定制能力
|
||||
|
||||
**目标：** 在不破坏标准产品的前提下，开放企业可配置能力。
|
||||
+3
-3
@@ -3,11 +3,11 @@
|
||||
> 状态：架构建议稿
|
||||
> 日期：2026-09-16
|
||||
> 关联文档：
|
||||
> - `SY03_Knowledge_Centric_Agent_Platform_Strategy.md`
|
||||
> - `docs/01_System_Overall/SY24_Platform_Architecture_Rethink.md`
|
||||
> - `SY03_知识中心型智能体平台战略.md`
|
||||
> - `docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY24_平台架构重思考.md`
|
||||
|
||||
> 2026-09-16 术语同步：
|
||||
> 本文档继续成立，但请以 `SY21_Unified_Role_Skill_Action_Architecture.md`、`SY22_Role_Skill_App_Unified_Task_Architecture.md` 为总架构收口版本。
|
||||
> 本文档继续成立，但请以 `SY21_统一角色技能动作架构.md`、`SY22_角色技能应用统一任务架构.md` 为总架构收口版本。
|
||||
> 其中最关键的口径更新是：
|
||||
> - 角色卡属于专家对象属性，不再单列为独立架构层
|
||||
> - 对外当前统一采用 `专家 / 技能 / 长程APP / 知识库`
|
||||
+5
-2
@@ -2,7 +2,7 @@
|
||||
|
||||
> 状态：实施建议稿
|
||||
> 日期：2026-09-17
|
||||
> 关联文档：`SY18_Specialist_Minimal_Definition_Model.md`、`SY20_Role_Card_And_Lightweight_Ontology_Architecture.md`、`SY21_Unified_Role_Skill_Action_Architecture.md`、`SY22_Role_Skill_App_Unified_Task_Architecture.md`
|
||||
> 关联文档：`SY18_专员最小定义模型.md`、`SY20_角色卡与轻量本体架构.md`、`SY21_统一角色技能动作架构.md`、`SY22_角色技能应用统一任务架构.md`
|
||||
> 外部参照：AionUi / AionCore 内置助手与技能（已下载至 `codebase/AionCore-assets/`）
|
||||
|
||||
> **2026-09-18 状态补注**：
|
||||
@@ -15,6 +15,10 @@
|
||||
>
|
||||
> 下面未逐段改写的旧引用，应按这组映射理解；若与当前代码现实冲突，以现代码与 `AR09_Object_Naming_Standard.md` 为准。
|
||||
|
||||
> **2026-09-19 状态补注**：
|
||||
> §2.4「技能 key 校验清单」是当时的提案快照（22 条，抄自 `frontend/src/config/workbench.js`），**不等于现状**。实际实现落在 `internal/skills/core/allowed_skills.go`，白名单由技能注册表 `Manifests()` 构建，而非文中那份常量文件。
|
||||
> 其中 `email-drafting`、`survey-summary`、`proposal-summary`、`project-planning`、`text-toolkit` 5 个 key 已于 2026-09-19 删除，当前有效 key 为 **18 个**。来龙去脉见 `docs/09_Research/RS05_我的通用智能体能力对标与技能清单取舍.md` §9。
|
||||
|
||||
---
|
||||
|
||||
## 0. 一句话诊断
|
||||
@@ -276,7 +280,6 @@ var ValidSkillKeys = map[string]bool{
|
||||
|---|-------------|------|----------------|------------|
|
||||
| 1 | `cowork` + 5 技能 | 6705 | `general-assistant`、`process-coordination` | **21 份里唯一的多技能编排样板**。它的说明书通篇在写「什么场景按哪个技能走」——这正是 SY20「专员 = 可调用工具的角色」要的东西。我们的「通用助手 / 流程协调」现在完全是空壳 |
|
||||
| 2 | `word-creator` + `officecli-docx` | 517 | `report-generation`、`solution-proposal` | 说明书只有 517 字，是**最简模板**，改造成本最低；`officecli-docx` 是文档产出的通用底座，一份技能喂两个专员 |
|
||||
| 3 | `morph-ppt` + `officecli-pptx` | 554 | `training-delivery` | 培训交付要出课件，morph-ppt 专做「文档转 PPT」，另有 3D 变体。我们「培训交付」目前零后端实现，接上就是真能力 |
|
||||
|
||||
### 第二梯队：要改业务语义（本轮之后）
|
||||
|
||||
+4
-4
@@ -3,13 +3,13 @@
|
||||
> 落盘日期：2026-09-16
|
||||
> 状态：架构重思考稿，作为后续产品与数据结构重构的总纲
|
||||
> 关联文档：
|
||||
> - `../02_Architecture/AR05_Workbench_Architecture_Contract.md`
|
||||
> - `../02_Architecture/AR06_Skill_Packaging_Specification.md`
|
||||
> - `../02_Architecture/AR08_Role_Interaction_Design.md`
|
||||
> - `../02_Architecture/AR05_工作台架构约定.md`
|
||||
> - `../02_Architecture/AR06_技能封装规范.md`
|
||||
> - `../02_Architecture/AR08_角色交互设计.md`
|
||||
|
||||
> 2026-09-16 架构同步说明：
|
||||
> 本文档保留 Workbench 收敛和对象化迁移结论，但总命名以
|
||||
> `docs/01_System_Overall/SY21_Unified_Role_Skill_Action_Architecture.md` 为准。
|
||||
> `docs/01_System_Overall/SY21_统一角色技能动作架构.md` 为准。
|
||||
> 当前统一口径为：
|
||||
> - 对外：`角色 / 技能 / 连接器`
|
||||
> - 对内：`role / skill / action / connector / policy`
|
||||
@@ -1,59 +0,0 @@
|
||||
# 01_System_Overall — 系统总览
|
||||
|
||||
> **命名规则：** `SY{NN}_{描述}.md`
|
||||
> **用途：** 系统概述、架构愿景、设计原则
|
||||
>
|
||||
> **当前统一口径：** 术语与一级导航请以 `SY21`、`SY22` 为准。
|
||||
> 当前产品一级导航目标态为：`新建任务 / 项目 / 专员·技能·APP·连接器 / 长程APP / 知识库 / 后台管理 / 我的`
|
||||
|
||||
## 文件清单
|
||||
|
||||
| 文件 | 说明 |
|
||||
|------|------|
|
||||
| `README.md` | 本索引文件 |
|
||||
| `SY01_System_Overview.md` | 系统概述（当前产品闭环与范围） |
|
||||
| `SY02_Design_Principles.md` | 核心设计原则（极简 / 本地化 / 审批前置） |
|
||||
| `SY03_Knowledge_Centric_Agent_Platform_Strategy.md` | 知识库中心化、业务层扩展与智能体平台战略 |
|
||||
| `SY04_Plugin_Workflow_Ontology_Delivery_Platform.md` | 数字员工平台（共享对象层 + 任务系统 + 专员市场 / 工坊 / 工作台） |
|
||||
| `SY05_Connector_Network_Enterprise_Integration_Architecture.md` | 六层架构 + 连接器网络（企业原有业务系统融合总图） |
|
||||
| `SY06_AI_Upgrade_Starting_Point_Decision_Framework.md` | AI 升级起步判断框架（知识库先行 / 工作流先行 / 连接器先行） |
|
||||
| `SY07_Industry_Agent_Pack_Landscape_Overview.md` | 六个行业反推平台需求总览（连接器需求 + 应用方向需求） |
|
||||
| `SY08_Legal_Industry_Agent_Pack.md` | 法律行业需求样本（Matter / Contract 驱动） |
|
||||
| `SY09_Healthcare_Industry_Agent_Pack.md` | 医疗行业需求样本（Patient / Encounter 驱动） |
|
||||
| `SY10_Industrial_Industry_Agent_Pack.md` | 工业行业需求样本（Asset / Order / Alarm 驱动） |
|
||||
| `SY11_Financial_Industry_Agent_Pack.md` | 金融行业需求样本（Customer / Transaction / Alert 驱动） |
|
||||
| `SY12_Logistics_Freight_Forwarding_Industry_Agent_Pack.md` | 物流货代行业需求样本（Shipment / Booking / Milestone 驱动） |
|
||||
| `SY13_Social_Commerce_Microbusiness_Industry_Agent_Pack.md` | 微商行业需求样本（Lead / Conversation / Campaign 驱动） |
|
||||
| `SY14_Industry_Derived_Connector_And_Application_Requirement_Matrix.md` | 从六个行业反推连接器与应用方向矩阵 |
|
||||
| `SY15_Terminology_Benchmark_Ontology_Semantic_Layer_Object_Layer.md` | 本体层 / 语义层 / 对象层命名基准研究（含星邺汇捷 / Palantir / Microsoft / Salesforce 对照） |
|
||||
| `SY16_Ontology_Generalizes_Data_Actions_And_Workflows.md` | 本体如何让数据、动作、工作流一般化 |
|
||||
| `SY17_Workbench_UI_Wireframes.md` | 数字员工平台 UI 线框图（早期线框推演，当前命名与导航以 SY22 为准） |
|
||||
| `SY18_DWP_DW_ADW_Formal_Design_Contract.md` | DWP / DW / ADW 正式设计合同（供人和 AI 共用的对象基准） |
|
||||
| `SY19_Universal_Digital_Worker_Product_Planning.md` | 通用数字员工平台 V1.0 产品规划（先通用、后定制的产品打法收口） |
|
||||
| `SY20_Role_Card_And_Lightweight_Ontology_Architecture.md` | 角色卡与轻量本体对象架构（专家对象交互属性的历史收敛稿） |
|
||||
| `SY21_Unified_Role_Skill_Action_Architecture.md` | 统一 Expert / Skill / Action 总架构确认稿（六层架构与命名收口） |
|
||||
| `SY22_Role_Skill_App_Unified_Task_Architecture.md` | Expert / Skill / App 统一任务架构（把 App 升级为一级对象、补齐完整一级导航、并将知识库确认为默认内建 App，产品名收口为“长程APP”） |
|
||||
| `SY23_Specialist_Rule_File_And_Skill_Binding_Plan.md` | 专员「岗位说明书 + 技能绑定」改造方案（诊断运行时同质化根因 + 三步打通链路 + AionUi 规则文件改写清单） |
|
||||
| `SY24_Platform_Architecture_Rethink.md` | 数字员工平台整体架构重思考（Workbench 收敛与对象化迁移**历史稿**，其结论已并入 SY21 / SY22） |
|
||||
|
||||
## 当前主线关系
|
||||
|
||||
1. `SY01`：定义当前系统范围与业务闭环
|
||||
2. `SY02`：定义强约束设计原则
|
||||
3. `SY03`：把平台主轴从培训系统扩展到知识库中心化智能体平台
|
||||
4. `SY04`：继续升级为数字员工平台
|
||||
5. `SY05`：补齐连接器网络，明确如何与企业原有业务系统融合
|
||||
6. `SY06`：给出 AI 升级的起步判断框架
|
||||
7. `SY07`：把六个行业重新定位为平台需求样本，而不是当前阶段的行业交付目标
|
||||
8. `SY08` - `SY13`：分别沉淀六个行业的需求样本，帮助反推连接器与应用方向
|
||||
9. `SY14`：把六个行业汇总成连接器与应用方向矩阵，直接服务六层架构设计
|
||||
10. `SY15`：澄清本体层、语义层、对象层的理论边界与厂商实践，服务六层架构术语统一
|
||||
11. `SY16`：解释本体为何要把数据、动作、工作流提升为统一业务表达，服务六层架构理解与对象建模
|
||||
12. `SY17`：把六层架构落成数字员工平台工作台线框，明确平台不再是单一导航后台
|
||||
13. `SY18`：正式定义 DWP / DW / ADW 的结构合同、字段规范和 AI 生成规则
|
||||
14. `SY19`：把当前阶段产品路线正式收口为「先通用数字员工、后行业包与企业定制」
|
||||
15. `SY20`：把角色卡从 UI 文案提升为角色对象内建属性，并确认轻量本体的落地边界
|
||||
16. `SY21`：正式收口六层架构与 `expert / skill / action / connector / policy` 总命名
|
||||
17. `SY22`：在 `SY21` 基础上补齐第三类一级对象 `app`，补全完整一级导航视图，并将知识库确认为默认内建 App，把平台升级为 Expert / Skill / App 三对象统一任务系统，产品名收口为“长程APP”
|
||||
18. `SY23`：定位到「专员与技能之间缺绑定边、专员说明未进 prompt」是专员的运行时空洞根因，给出三步打通方案与 AionUi 规则文件改写清单
|
||||
19. `SY24`：Workbench 收敛与对象化迁移的历史重思考稿，结论已并入 `SY21` / `SY22`；本文只作背景追溯，命名一律以 `SY21` 为准
|
||||
@@ -1,81 +0,0 @@
|
||||
# SY01 — 系统概述
|
||||
|
||||
> **版本：V2.0 | 最后更新：2026-09-17**
|
||||
|
||||
---
|
||||
|
||||
## 0. 文档状态与定位演进
|
||||
|
||||
本项目已从「内部培训系统」升级为**以知识库底座为核心、以智能体为能力单元、支持客户半定制的销售训练与认证平台**（知识库中心化智能体平台）。当前产品主轴、分层架构与目标态见 [SY03](SY03_Knowledge_Centric_Agent_Platform_Strategy.md) 及 SY04–SY17；本文档第 1–6 节描述的是已交付的 V1 培训底座（学习/考试/AI 答疑闭环），是平台的起始形态，不再是终点形态。
|
||||
|
||||
---
|
||||
|
||||
## 1. 项目定位
|
||||
|
||||
**eai_agentplatform**（博昇 AI 数字员工平台）是一个纯内网本地化部署的内部专属员工培训系统，技术栈 **Go + Gin + GORM + SQLite**，并以此为基础演进为知识库中心化的智能体平台。
|
||||
|
||||
**核心价值（V1 已交付）：**
|
||||
- 新人快速了解公司文化和业务
|
||||
- 员工系统化学习产品知识和佣金规则
|
||||
- 销售团队通过话术培训提升能力
|
||||
- 统一考试验收学习成果
|
||||
- 全局 AI 助教 PathCoach 提供实时答疑和情景演练
|
||||
|
||||
**演进方向（见 SY03–SY17）：** 知识底座统一主实体化、智能体矩阵（知识顾问/产品顾问/陪练教官/合规审查官/认证考官/出题组卷官/复盘教练/内容工坊助手）、客户半定制智能体工坊、销售赋能/陪练认证/合规经营/内容生产等业务层扩展。
|
||||
|
||||
## 2. 系统边界
|
||||
|
||||
### 包含
|
||||
- 公司介绍培训（认知层）
|
||||
- 产品知识手册（四大分类，含佣金/规则）
|
||||
- 产品销售培训（四大课程，含话术/流程）
|
||||
- 题库 + 组卷 + 自测/正式考试
|
||||
- 素材上传 + 审批流 + 文档转换管线
|
||||
- AI PathCoach 全局聊天框
|
||||
- 管理员后台（用户/素材/考试/系统配置）
|
||||
|
||||
### 不包含 / 已放开（V1.1 约束，随平台升级调整）
|
||||
- ~~学习进度仪表盘、学情分析、能力档案~~ → V1.6 起已实现（积分/排行榜/证书/学习档案/能力雷达）
|
||||
- ~~向量检索（不引入 embedding 依赖）~~ → 已采用 Go 原生 brute-force 向量检索（余弦）+ 关键词兜底
|
||||
- 复杂权限、多级角色、多租户洋葱模型 → 仍保持单租户极简，暂不引入
|
||||
- 视频转码、语音转写（ASR）→ 仍不引入
|
||||
- 外网依赖、云存储（MinIO/OSS）→ 仍保持本地化
|
||||
- 强制学习任务、课程解锁限制 → 仍不引入
|
||||
|
||||
## 3. 用户角色
|
||||
|
||||
| 角色 | 可见模块 | 权限 |
|
||||
|------|---------|------|
|
||||
| **employee**（员工） | 首页、公司介绍、产品知识、销售培训、考试 | 浏览 + 自测 + 正式考试 + 提交素材建议 |
|
||||
| **admin**（管理员） | 员工全部 + 知识管理 + 系统管理 + 内容管理 | 员工权限 + 素材审批 + 用户管理 + 考试配置 + 系统参数 |
|
||||
|
||||
## 4. 核心业务流程
|
||||
|
||||
```
|
||||
学公司认知 → 查产品手册（价格/佣金/规则）→ 学销售谈单能力
|
||||
→ 看课件视频辅助学习 → AI 模拟演练答疑 → 正式考试存档验收
|
||||
→ 管理员统一审核素材、维护产品/课程/题库、管理账号、查看全员成绩
|
||||
```
|
||||
|
||||
## 5. 系统运行闭环
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌──────────────┐
|
||||
│ 员工学习 │ → │ AI 辅助答疑 │ → │ 考试验收 │
|
||||
│ (公司/产品/ │ │ (PathCoach) │ │ (自测/正式) │
|
||||
│ 销售培训) │ │ │ │ │
|
||||
└─────────────┘ └─────────────┘ └──────┬───────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────┐
|
||||
│ 管理员运营 │
|
||||
│ (素材审批/用户/配置/成绩)│
|
||||
└─────────────────────────┘
|
||||
```
|
||||
|
||||
## 6. 全局统一布局
|
||||
|
||||
全站固定三栏结构：
|
||||
1. **顶部导航菜单** — 根据角色动态显示可用菜单
|
||||
2. **中间主内容区** — 各业务模块页面
|
||||
3. **右侧 AI PathCoach 聊天框** — 可收起/展开，全局常驻
|
||||
@@ -0,0 +1,95 @@
|
||||
# SY01 — 系统概述
|
||||
|
||||
> **版本：V3.0 | 最后更新：2026-09-21**
|
||||
|
||||
---
|
||||
|
||||
## 1. 当前定位
|
||||
|
||||
**eai_agentplatform** 当前定位为：
|
||||
|
||||
**一套纯内网、本地化部署、以任务为中心的数字员工平台。**
|
||||
|
||||
它当前按以下口径收口：
|
||||
|
||||
- 以 `专家 / 技能 / App / 连接器` 作为核心对象
|
||||
- 以任务作为统一运行载体
|
||||
- 以知识库、连接器、动作契约作为底座能力
|
||||
- 以对象化扩展和客户半定制作为主要扩展方式
|
||||
|
||||
当前系统总纲以 [SY21_统一角色技能动作架构.md](SY21_统一角色技能动作架构.md)、[SY22_角色技能应用统一任务架构.md](SY22_角色技能应用统一任务架构.md) 为准。
|
||||
|
||||
## 2. 当前系统边界
|
||||
|
||||
### 包含
|
||||
|
||||
- 专家、技能、App 的对象化定义与运行
|
||||
- 统一任务入口与任务会话
|
||||
- 知识库能力与知识导入能力
|
||||
- 连接器接入与对象运行支撑
|
||||
- 后台治理、系统治理与基础配置
|
||||
- 面向销售训练、知识赋能、对象化交付的业务承载
|
||||
|
||||
### 不包含
|
||||
|
||||
- 多租户洋葱模型
|
||||
- 高自由度、无边界的开放式 Agent 平台
|
||||
- 以页面堆叠为核心的传统业务后台扩张方式
|
||||
|
||||
## 3. 当前一级对象模型
|
||||
|
||||
### 对外对象
|
||||
|
||||
- `专家`
|
||||
- `技能`
|
||||
- `App`
|
||||
- `连接器`
|
||||
|
||||
### 对内运行语言
|
||||
|
||||
- `expert`
|
||||
- `skill`
|
||||
- `action`
|
||||
- `connector`
|
||||
- `policy`
|
||||
|
||||
其中：
|
||||
|
||||
- `专家` 承接稳定岗位责任
|
||||
- `技能` 承接单点能力
|
||||
- `App` 承接长流程、结构化业务界面与长期任务
|
||||
- `连接器` 承接外部系统接入
|
||||
|
||||
## 4. 当前一级导航口径
|
||||
|
||||
当前正式一级导航目标态为：
|
||||
|
||||
`新建任务 / 项目 / 专员·技能·APP·连接器 / 长程APP / 知识库 / 后台管理 / 我的`
|
||||
|
||||
这套导航在当前文档体系中视为正式口径，不再作为历史推演稿阅读。
|
||||
|
||||
## 5. 当前技术与部署口径
|
||||
|
||||
- 后端：Go + Gin + GORM
|
||||
- 数据库：SQLite
|
||||
- 检索：Go 原生 brute-force 向量检索（余弦）+ 关键词兜底
|
||||
- 部署：纯内网、本地化、单体部署
|
||||
- 治理：单租户、轻治理、审批前置
|
||||
|
||||
详细技术与部署以：
|
||||
|
||||
- `docs/04_Backend/01_平台治理底座/BG04_数据库总览.md`
|
||||
- `docs/02_Architecture/部署文档.md`
|
||||
- `docs/01_System_Overall/变更日志.md`
|
||||
|
||||
为准。
|
||||
|
||||
## 6. 当前阅读顺序
|
||||
|
||||
建议按以下顺序理解当前系统：
|
||||
|
||||
1. 本文：系统当前定位与边界
|
||||
2. [SY02_设计原则.md](SY02_设计原则.md)：当前设计硬约束
|
||||
3. [SY21_统一角色技能动作架构.md](SY21_统一角色技能动作架构.md)：当前总架构
|
||||
4. [SY22_角色技能应用统一任务架构.md](SY22_角色技能应用统一任务架构.md)：一级对象与导航
|
||||
5. [SY25_业务逻辑拆解与数字员工抽取方法.md](SY25_业务逻辑拆解与数字员工抽取方法.md)：对象抽取方法
|
||||
+4
-4
@@ -1,8 +1,8 @@
|
||||
# SY02 — 核心设计原则
|
||||
|
||||
> **版本：V1.2 | 状态：强制 | 最后更新：2026-08-16**
|
||||
> **版本：V2.0 | 状态：强制 | 最后更新：2026-09-21**
|
||||
>
|
||||
> **文档状态：V1 基线，已升级。** 本项目已于 2026-08 升级为「知识库中心化智能体平台」，产品主轴与目标态见 [SY03](SY03_Knowledge_Centric_Agent_Platform_Strategy.md) 及 SY04–SY17。本文档为 V1 培训平台基线的设计原则，其中「不做向量检索 / 无学情分析 / 无能力档案」等约束已随 V1.6 起逐步放开，当前实现以 `docs/changelog.md` 与 `docs/db_schema.md` 为准。
|
||||
> **文档状态：当前有效。** 本文档只保留当前系统仍然生效的硬约束与设计原则，不再承载历史演进说明。具体实现以 `docs/01_System_Overall/变更日志.md`、`docs/04_Backend/01_平台治理底座/BG04_数据库总览.md` 与 `docs/02_Architecture/部署文档.md` 为准。
|
||||
|
||||
---
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
- 数据库使用 SQLite 单文件（本地实例）+ Go 原生 brute-force 向量检索（余弦相似度）+ 关键词兜底
|
||||
- 文件存储使用本地磁盘（backend/data/media → 现为 `data/kb_data`）
|
||||
|
||||
## 原则 2：极致极简（V1 约束，已随平台升级部分放开）
|
||||
## 原则 2：极致极简
|
||||
|
||||
- 所有功能以"够用"为标准，不做任何冗余
|
||||
- **V1.1 曾明确不做、现已放开的：** 学情分析、能力档案、学习进度仪表盘（V1.6 起已实现积分/排行榜/证书/学习档案/能力雷达）；岗位与部门概念（V1.4 / V1.7 已引入）。复杂权限与多级角色仍保持单租户极简，暂不引入多租户洋葱模型
|
||||
@@ -61,4 +61,4 @@
|
||||
|
||||
- 所有产品数据严格对齐《博昇产品与渠道合作表 V1.0》
|
||||
- 产品编号、名称、分类、佣金比例、分成规则等字段不可随意修改
|
||||
- 支持批量导入（Excel / JSON），导入数据需管理员确认后生效
|
||||
- 支持批量导入（Excel / JSON），导入数据需管理员确认后生效
|
||||
+12
-22
@@ -3,10 +3,10 @@
|
||||
> 状态：总架构确认稿
|
||||
> 日期：2026-09-16
|
||||
> 关联文档：
|
||||
> - `SY03_Knowledge_Centric_Agent_Platform_Strategy.md`
|
||||
> - `SY15_Terminology_Benchmark_Ontology_Semantic_Layer_Object_Layer.md`
|
||||
> - `SY20_Role_Card_And_Lightweight_Ontology_Architecture.md`
|
||||
> - `docs/01_System_Overall/SY24_Platform_Architecture_Rethink.md`
|
||||
> - `History_And_Retrospectives/系统演进旧稿/SY03_知识中心型智能体平台战略.md`
|
||||
> - `History_And_Retrospectives/系统演进旧稿/SY15_术语基准本体语义层与对象层.md`
|
||||
> - `History_And_Retrospectives/系统演进旧稿/SY20_角色卡与轻量本体架构.md`
|
||||
> - `docs/01_System_Overall/History_And_Retrospectives/系统演进旧稿/SY24_平台架构重思考.md`
|
||||
|
||||
> 2026-09-16 术语同步：
|
||||
> 本文原先使用 `Role / role / role_card` 作为主术语。
|
||||
@@ -19,7 +19,7 @@
|
||||
|
||||
## 1. 这份文档要确认什么
|
||||
|
||||
在前面几轮讨论后，当前项目已经不再缺“局部页面方案”，真正缺的是一份统一总架构结论，用来回答以下问题：
|
||||
在前面几轮讨论后，当前项目需要一份统一总架构结论，用来回答以下问题：
|
||||
|
||||
1. 平台到底按几层架构来收敛
|
||||
2. 本体、角色卡、对象、技能、Action、连接器分别处于什么位置
|
||||
@@ -27,7 +27,7 @@
|
||||
4. 是否还要继续使用 `tool` 这个词
|
||||
5. 当前代码和文档后续应该往哪个方向迁移
|
||||
|
||||
这份文档的目标不是给出某个局部功能设计，而是把平台的总语言、总结构、总对象模型先定下来。
|
||||
这份文档用于先定平台的总语言、总结构和总对象模型。
|
||||
|
||||
---
|
||||
|
||||
@@ -65,7 +65,7 @@
|
||||
|
||||
## 2.3 对外默认暴露 `专家 + 技能`
|
||||
|
||||
外部用户看到的应该是：
|
||||
外部用户默认看到的是：
|
||||
|
||||
- 专家
|
||||
- 技能
|
||||
@@ -73,15 +73,7 @@
|
||||
- starter prompts
|
||||
- 可完成的任务
|
||||
|
||||
而不是：
|
||||
|
||||
- tool 列表
|
||||
- 底层调用动作
|
||||
- 技术执行接口
|
||||
|
||||
所以：
|
||||
|
||||
**用户入口层默认暴露 skill，不暴露 action。**
|
||||
因此，**用户入口层默认暴露 skill，不暴露 action。**
|
||||
|
||||
## 2.4 对内统一使用 `action`
|
||||
|
||||
@@ -111,17 +103,15 @@
|
||||
- 告警分析专员
|
||||
- 工单协调专员
|
||||
|
||||
那么本体层不是可选项，而是必要项。
|
||||
那么本体层是必要项。
|
||||
|
||||
原因很简单：
|
||||
|
||||
没有本体层，上层对象和工作台体验很快就会被行业对象、事件、状态、规则的差异撕裂。
|
||||
|
||||
## 2.6 专家卡不是独立层，而是专家对象属性
|
||||
## 2.6 专家卡作为专家对象属性存在
|
||||
|
||||
角色卡仍然要保留，但它不是一层单独架构层。
|
||||
|
||||
更准确的定义是：
|
||||
角色卡仍然要保留，并作为专家对象的交互属性集存在：
|
||||
|
||||
**专家卡 = 专家对象的交互属性集**
|
||||
|
||||
@@ -168,7 +158,7 @@
|
||||
|
||||
这一层负责定义平台语义。
|
||||
|
||||
它不是简单的表结构，而是平台统一语义底座。
|
||||
它承载平台统一语义底座。
|
||||
|
||||
当前阶段建议采用轻量本体，先定义：
|
||||
|
||||
+13
-17
@@ -3,9 +3,9 @@
|
||||
> 状态：总架构扩展确认稿
|
||||
> 日期：2026-09-16
|
||||
> 关联文档：
|
||||
> - `SY17_Workbench_UI_Wireframes.md`
|
||||
> - `SY20_Role_Card_And_Lightweight_Ontology_Architecture.md`
|
||||
> - `SY21_Unified_Role_Skill_Action_Architecture.md`
|
||||
> - `History_And_Retrospectives/系统演进旧稿/SY17_工作台界面线框稿.md`
|
||||
> - `History_And_Retrospectives/系统演进旧稿/SY20_角色卡与轻量本体架构.md`
|
||||
> - `SY21_统一角色技能动作架构.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -17,9 +17,9 @@
|
||||
- 对内运行 `expert / skill / action / connector / policy`
|
||||
- 不再继续扩张 `tool` 概念
|
||||
|
||||
但随着工作台进一步向 WorkBuddy 类产品演进，出现了一个新问题：
|
||||
但随着工作台进一步向 WorkBuddy 类产品演进，系统需要新增一种与专家、技能并列的一级对象。
|
||||
|
||||
**系统里需要一种既不是专家、也不是技能的新一级对象。**
|
||||
**这类对象就是 App。**
|
||||
|
||||
它具备以下特征：
|
||||
|
||||
@@ -29,8 +29,6 @@
|
||||
- 启动后应成为一个长程任务实例
|
||||
- 可挂载右栏 AI、可调用技能、可沉淀业务产物
|
||||
|
||||
这类对象不适合继续塞进 `expert`，也不适合伪装成“大 skill”。
|
||||
|
||||
因此，这份文档正式确认：
|
||||
|
||||
> **平台需要第三类一级对象：App。**
|
||||
@@ -50,11 +48,11 @@
|
||||
5. 对象层
|
||||
6. 工作台与运行治理层
|
||||
|
||||
本次变化不是推翻六层，而是把第五层从偏“专家对象层”正式升级为：
|
||||
本次变化是在保留六层架构的前提下，把第五层正式升级为：
|
||||
|
||||
> **对象层（Expert / Skill / App）**
|
||||
|
||||
## 2.2 App 是一级对象，不是页面，也不是大技能
|
||||
## 2.2 App 是一级对象，承接长程任务运行壳
|
||||
|
||||
App 的准确定义是：
|
||||
|
||||
@@ -86,7 +84,7 @@ App 的准确定义是：
|
||||
因此：
|
||||
|
||||
- 对话是任务中的一种交互轨迹
|
||||
- 不是所有任务都必须以消息流作为主界面
|
||||
- 消息流是部分任务的主界面形态
|
||||
|
||||
## 2.4 长程APP是一级导航，但一级导航必须完整描述
|
||||
|
||||
@@ -132,7 +130,7 @@ App 的准确定义是：
|
||||
|
||||
这里需要明确一个特例：
|
||||
|
||||
> **知识库本身也是 `app`，但它不是普通可选 App，而是组织级默认必须存在的内建 App。**
|
||||
> **知识库本身也是 `app`，并作为组织级默认必须存在的内建 App。**
|
||||
|
||||
原因是：
|
||||
|
||||
@@ -152,13 +150,11 @@ App 的准确定义是：
|
||||
3. 进入该 `app` 的运行界面
|
||||
4. 同时进入统一任务列表
|
||||
|
||||
当前像 `AI考试` 这种已经长出独立业务界面的主导航，在架构上应理解为**过渡态专题入口**。
|
||||
后续应逐步收敛为：
|
||||
当前像 `AI考试` 这种已经长出独立业务界面的主导航，在架构上属于**过渡态专题入口**。
|
||||
后续收敛路径为：
|
||||
|
||||
- `长程APP -> app.training_exam`
|
||||
|
||||
而不是继续长期作为与 `专家 / 技能 / 项目 / 知识库` 并列的专题型一级主栏目。
|
||||
|
||||
---
|
||||
|
||||
## 3. 三类一级对象的边界
|
||||
@@ -631,7 +627,7 @@ App 可以调用 Skill，但不替代 Skill。
|
||||
|
||||
唯一应保留一级直达入口的 App，是像 `知识库` 这种**组织级默认必装底座 App**。
|
||||
|
||||
## 7.2 进入 App 的动作不是“打开页面”，而是“创建任务”
|
||||
## 7.2 进入 App 的标准动作是“创建任务”
|
||||
|
||||
点击 App 卡片后的标准动作应为：
|
||||
|
||||
@@ -750,6 +746,6 @@ AI 对话框在 App 中退居右栏能力区。
|
||||
- `App` 负责长程任务运行壳
|
||||
- `Task` 负责统一承载工作实例
|
||||
|
||||
这意味着平台已经不再是单一对话驱动系统，而是：
|
||||
这意味着平台当前采用以下运行形态：
|
||||
|
||||
> **对话工作台与长程APP并存，但统一运行、统一治理、统一沉淀。**
|
||||
@@ -0,0 +1,375 @@
|
||||
# SY25 — 业务逻辑拆分与数字员工提取方法
|
||||
|
||||
> **版本：V1.0 | 最后更新：2026-09-19**
|
||||
|
||||
---
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文用于回答两个核心问题：
|
||||
|
||||
1. 业务逻辑应该如何拆分
|
||||
2. 数字员工应该如何从业务中被提取出来
|
||||
|
||||
本文提供 **专家 / App / skill 的统一提取方法**。
|
||||
|
||||
其目标是避免继续出现以下问题：
|
||||
|
||||
- 把动作误写成专家
|
||||
- 把结果物误写成专家
|
||||
- 把长流程环节误写成专家
|
||||
- 先造对象名，再反推业务价值
|
||||
|
||||
本文与 `docs/05_Object_Catalog/` 配合使用；如需查看更早期的产品阶段规划，可参考 `History_And_Retrospectives/系统演进旧稿/SY19_通用数字员工产品规划.md`：
|
||||
|
||||
- `SY25` 负责对象提取方法
|
||||
- `docs/05_Object_Catalog` 负责具体对象定义
|
||||
|
||||
---
|
||||
|
||||
## 2. 总原则
|
||||
|
||||
业务与对象设计统一遵守一句话：
|
||||
|
||||
**先拆业务，不先造人；先找真实岗位，再提取数字员工。**
|
||||
|
||||
进一步展开，有 5 条硬规则：
|
||||
|
||||
1. **经营环节构成业务骨架**
|
||||
2. **真实岗位是数字员工的直接来源**
|
||||
3. **xapp 承接长流程，skill 承接单点动作**
|
||||
4. **结果物、动作、流程节点，不直接定义为专员**
|
||||
5. **只有可数字化输入、可在线闭环的岗位部分，才适合提取为数字员工**
|
||||
|
||||
---
|
||||
|
||||
## 3. 业务逻辑拆分的一级骨架
|
||||
|
||||
业务逻辑应先按企业经营主链拆分，再映射到页面菜单、系统模块或功能点。
|
||||
|
||||
当前建议统一采用从需求发现到售后服务的五大经营环节作为一级骨架：
|
||||
|
||||
| 环节 | 定义 | 关键结果 |
|
||||
|---|---|---|
|
||||
| 需求发现 | 找到潜在客户、识别机会、形成有效线索 | 有价值线索 |
|
||||
| 需求确认 | 澄清客户场景、目标、约束和预算 | 清晰需求 |
|
||||
| 方案与交易 | 形成解决方案、完成报价与合同、推动签约 | 可签约方案与交易条件 |
|
||||
| 交付与上线 | 组织实施、培训、上线、验证可用 | 可运行、可使用 |
|
||||
| 售后服务与持续经营 | 保障客户持续使用、续约、增购、反馈闭环 | 留存、续约、增长 |
|
||||
|
||||
这五段用于为业务搭骨架，并为后续岗位识别与对象提取提供顺序。
|
||||
|
||||
---
|
||||
|
||||
## 4. 正确的对象提取顺序
|
||||
|
||||
对象提取必须按以下顺序进行：
|
||||
|
||||
`经营环节 -> 结果 -> 主责岗位 -> 对象类型 -> 具体对象`
|
||||
|
||||
不允许倒过来，从功能点或动作列表直接拼对象名。
|
||||
|
||||
### 4.1 第一步：先画业务主链
|
||||
|
||||
先把业务写成完整经营链，而不是碎片化任务表。
|
||||
|
||||
例如销售型业务，可以先写成：
|
||||
|
||||
`需求发现 -> 需求确认 -> 方案与交易 -> 交付与上线 -> 售后服务与持续经营`
|
||||
|
||||
### 4.2 第二步：明确每段的主结果
|
||||
|
||||
每个经营环节都必须先回答：
|
||||
|
||||
**这一段最后交付什么结果？**
|
||||
|
||||
例如：
|
||||
|
||||
- 需求发现：有效线索
|
||||
- 需求确认：清晰需求
|
||||
- 方案与交易：可签约方案与合同条件
|
||||
- 交付与上线：可运行可使用
|
||||
- 售后服务与持续经营：续约、增购、健康客户
|
||||
|
||||
### 4.3 第三步：寻找真实主责岗位
|
||||
|
||||
每段都继续追问：
|
||||
|
||||
**现实企业里，通常是谁对这个结果负责？**
|
||||
|
||||
这一问的目的，是阻止系统继续从动作中发明假岗位。
|
||||
|
||||
### 4.4 第四步：判断该落成什么对象
|
||||
|
||||
找到主责后，继续判断最合适的对象类型：
|
||||
|
||||
- 稳定岗位责任 -> `专员`
|
||||
- 长流程协作空间 -> `xapp`
|
||||
- 原子动作能力 -> `skill`
|
||||
|
||||
### 4.5 第五步：最后才命名对象
|
||||
|
||||
命名必须服从前面四步，不允许先有名字，再找理由。
|
||||
|
||||
---
|
||||
|
||||
## 4A. 数字员工的物理边界
|
||||
|
||||
上面的“真实岗位”判断，还不够。
|
||||
|
||||
数字员工以现实员工为参考对象，同时遵守明确的物理边界。
|
||||
|
||||
### 4A.1 数字员工只能处理数字化输入
|
||||
|
||||
数字员工原则上只能基于以下输入工作：
|
||||
|
||||
- 已录入系统的数据
|
||||
- 文档、表格、邮件、聊天记录、会议纪要
|
||||
- 表单、工单、知识库、CRM、ERP 等结构化或半结构化信息
|
||||
- 明确授权的线上连接器数据
|
||||
|
||||
数字员工**不能默认具备**以下能力：
|
||||
|
||||
- 实地拜访客户
|
||||
- 线下面谈获取信息
|
||||
- 打电话主动询问信息
|
||||
- 在未接入的现实场景中自行观察和取证
|
||||
- 通过人情关系、现场氛围、口头暗示完成判断
|
||||
|
||||
因此，一个岗位即使在企业中真实存在，如果它的核心价值高度依赖线下触达、电话沟通或现场判断，也不能直接等价提取为完整数字员工。
|
||||
|
||||
### 4A.2 先判断“岗位是否真实”，再判断“岗位是否可数字化”
|
||||
|
||||
专员提取必须通过两层门槛：
|
||||
|
||||
1. **现实世界中是否有这个岗位**
|
||||
2. **这个岗位中是否有足够多的职责，可以只依赖数字化输入在线完成**
|
||||
|
||||
两层都满足，才适合立专员。
|
||||
|
||||
如果第一层满足、第二层不满足，就不应强行做成完整专员，而应降级为：
|
||||
|
||||
- 面向人工岗位的数字副手
|
||||
- 某个流程中的工作台 `xapp`
|
||||
- 若干在线能力 `skill`
|
||||
|
||||
### 4A.3 数字员工擅长持续处理数字信息
|
||||
|
||||
数字员工更适合承接以下类型的工作：
|
||||
|
||||
- 信息整理
|
||||
- 规则判断
|
||||
- 多源信息汇总
|
||||
- 状态跟踪
|
||||
- 文档生成
|
||||
- 风险识别
|
||||
- 节点提醒
|
||||
- 在线协同推进
|
||||
|
||||
以下工作更适合作为人工主责环节：
|
||||
|
||||
- 现场关系建立
|
||||
- 电话破冰
|
||||
- 线下陌生拜访
|
||||
- 当面谈判中的临场博弈
|
||||
- 现场交付中的物理操作
|
||||
|
||||
---
|
||||
|
||||
## 5. 专员、xapp、skill 的底层分工
|
||||
|
||||
### 5.1 专员：承接岗位责任
|
||||
|
||||
专员回答的问题是：
|
||||
|
||||
**谁对这一段业务结果负责？**
|
||||
|
||||
专员的本质是对某段业务结果持续负责。
|
||||
|
||||
因此，专员应当来自现实企业里稳定存在的岗位，例如：
|
||||
|
||||
- 销售专员
|
||||
- 售前解决方案专员
|
||||
- 商务合同专员
|
||||
- 客户成功专员
|
||||
|
||||
### 5.2 xapp：承接长流程工作空间
|
||||
|
||||
xapp 回答的问题是：
|
||||
|
||||
**这段业务如何被组织、推进、留痕、协作和交付？**
|
||||
|
||||
它的重点是流程承载与协作组织。
|
||||
|
||||
因此，凡是“交付系统”“项目空间”“长流程工作台”这一类对象，优先落到 xapp。
|
||||
|
||||
### 5.3 skill：承接单点动作能力
|
||||
|
||||
skill 回答的问题是：
|
||||
|
||||
**具体做什么动作？**
|
||||
|
||||
例如：
|
||||
|
||||
- 纪要整理
|
||||
- 客户画像生成
|
||||
- 方案草稿生成
|
||||
- 合同条款比对
|
||||
- 续约风险识别
|
||||
|
||||
skill 是能力片段，不是岗位。
|
||||
|
||||
---
|
||||
|
||||
## 6. 一个对象能不能成为专员
|
||||
|
||||
一个对象要成为专员，至少要同时满足以下 6 条：
|
||||
|
||||
1. **现实企业里存在对应真实岗位**
|
||||
2. **这个岗位中有足够多的职责，可以只依赖数字化输入在线完成**
|
||||
3. **这个岗位有稳定主责，而不是临时动作集合**
|
||||
4. **它处理的是持续状态，而不是一次性任务**
|
||||
5. **它有清晰输入、输出和判断逻辑**
|
||||
6. **它值得长期作为独立协作对象存在**
|
||||
|
||||
如果不满足，就不要立专员。
|
||||
|
||||
应分流为：
|
||||
|
||||
- 流程承载 -> `xapp`
|
||||
- 单点动作 -> `skill`
|
||||
- 结果物 -> 交付物，而不是对象
|
||||
|
||||
---
|
||||
|
||||
## 7. 三类最常见误判
|
||||
|
||||
### 7.1 把结果物当专员
|
||||
|
||||
错误示例：
|
||||
|
||||
- `售前方案专员`
|
||||
|
||||
问题：
|
||||
|
||||
- “方案”是产物，不是岗位
|
||||
|
||||
正确做法：
|
||||
|
||||
- 回到真实岗位 `售前解决方案专员`
|
||||
|
||||
### 7.2 把动作当专员
|
||||
|
||||
错误示例：
|
||||
|
||||
- `客户跟进专员`
|
||||
- `招聘筛选专员`
|
||||
|
||||
问题：
|
||||
|
||||
- “跟进”“筛选”都是动作，不是稳定岗位
|
||||
|
||||
正确做法：
|
||||
|
||||
- 找到这些动作背后的真实岗位，再决定是否立专员
|
||||
|
||||
### 7.3 把长流程环节当专员
|
||||
|
||||
错误示例：
|
||||
|
||||
- `培训交付专员`
|
||||
|
||||
问题：
|
||||
|
||||
- “交付”是长流程环节
|
||||
- 如果交付已经由 `xapp` 承担，就不应再设同名专员
|
||||
|
||||
正确做法：
|
||||
|
||||
- 交付归 `xapp`
|
||||
- 专员只保留真实岗位责任
|
||||
|
||||
### 7.4 忽略数字员工的物理限制
|
||||
|
||||
错误示例：
|
||||
|
||||
- 让数字员工默认承担实地拜访
|
||||
- 让数字员工通过打电话主动获取一手信息
|
||||
- 把强依赖现场判断的岗位直接照搬成专员
|
||||
|
||||
问题：
|
||||
|
||||
- 这些职责不以数字化输入为前提
|
||||
- 它们高度依赖现实世界接触，而不是在线数据闭环
|
||||
|
||||
正确做法：
|
||||
|
||||
- 只提取该岗位中可数字化、可在线闭环的职责部分
|
||||
- 其余部分保留给真人岗位或线下流程
|
||||
- 必要时把对象降为数字副手、`xapp` 或 `skill`
|
||||
|
||||
---
|
||||
|
||||
## 8. 销售链路示例
|
||||
|
||||
以销售流程为例，按本文方法拆分后，可得到如下结果：
|
||||
|
||||
| 经营环节 | 主责岗位 | 建议对象 |
|
||||
|---|---|---|
|
||||
| 需求发现 | 销售代表 / 客户经理 / 销售顾问 | 销售专员 |
|
||||
| 需求确认 | 销售 + 售前顾问 | 销售专员 + 售前解决方案专员 |
|
||||
| 方案与交易 | 售前顾问 + 商务 / 合同岗位 | 售前解决方案专员 + 商务合同专员 |
|
||||
| 交付与上线 | 项目 / 实施 / 交付体系 | xapp 为主，不急于立专员 |
|
||||
| 售后服务与持续经营 | 客户成功 / 客户运营 | 客户成功专员 |
|
||||
|
||||
因此，销售型业务当前最稳的数字员工骨架是：
|
||||
|
||||
- 销售专员
|
||||
- 售前解决方案专员
|
||||
- 商务合同专员
|
||||
- 客户成功专员
|
||||
|
||||
但需要注意：
|
||||
|
||||
- `销售专员` 并不等于替代真人销售去打陌生电话或跑线下拜访
|
||||
- 它更适合处理 CRM 线索整理、在线跟进记录、客户资料分析、推进提醒、商机判断等数字化环节
|
||||
- 凡是必须依靠电话、现场、当面关系推进才能完成的部分，都不应直接算进数字员工的能力边界
|
||||
|
||||
而以下名字不建议继续使用：
|
||||
|
||||
- `售前方案专员`
|
||||
- `客户跟进专员`
|
||||
- `培训交付专员`
|
||||
|
||||
---
|
||||
|
||||
## 9. 设计检查清单
|
||||
|
||||
后续每次新增专员前，都先过这一张清单：
|
||||
|
||||
1. 这是经营环节、岗位、动作、还是结果物？
|
||||
2. 现实企业里有没有这个岗位？
|
||||
3. 这个岗位中，有多少职责能只依赖数字化输入在线完成？
|
||||
4. 它负责的是一段稳定结果，还是几个零散动作？
|
||||
5. 这件事更应该由专员、xapp 还是 skill 承接？
|
||||
6. 如果删掉这个对象，业务语义会不会更清楚？
|
||||
|
||||
只要前 3 问答不稳，就不要立专员。
|
||||
|
||||
---
|
||||
|
||||
## 10. 最终结论
|
||||
|
||||
业务逻辑拆分与数字员工提取，应统一服从以下底层逻辑：
|
||||
|
||||
- **经营环节是体系骨架**
|
||||
- **真实岗位是数字员工来源**
|
||||
- **数字化输入边界决定哪些岗位职责可以被提取**
|
||||
- **专员管责任**
|
||||
- **xapp 管流程**
|
||||
- **skill 管动作**
|
||||
- **结果物、动作、流程节点，不直接定义为专员**
|
||||
|
||||
一句话收口：
|
||||
|
||||
**拆业务，先看价值链；提专员，先看真实岗位，再看是否可数字化。**
|
||||
@@ -0,0 +1,158 @@
|
||||
# eai_agentplatform — 变更日志
|
||||
|
||||
> **最后更新：2026-08-16**
|
||||
|
||||
---
|
||||
|
||||
## V1.7（2026-08-16）
|
||||
|
||||
**组织架构 + 消息通知落地。** 补齐「部门组织架构管理」与「站内消息通知」两大能力，
|
||||
打通「按部门学情拆分」与「事件推送提醒」；**社交社区/讨论区明确不做（定死）**。
|
||||
|
||||
### 新增
|
||||
- **部门组织架构**：`department` 部门字典表 + `GET/POST/PUT/DELETE /api/departments`（admin）；
|
||||
部门改名时同步 `user.department` 字符串，有员工归属的部门拒绝删除；
|
||||
`GET /api/system/department-stats` 按部门聚合（人数/学习积分/公司介绍已读率/
|
||||
人均产品课程/正式考试通过率/平均分）；前端「系统管理 → 部门管理」页（部门列表 + 部门学情两个 Tab），
|
||||
用户管理「部门」字段改为可搜索下拉（支持自建输入，兼容历史自由文本）
|
||||
- **站内消息通知**：`notification` 表 + 事件钩子（发布正式考试 → 通知全员；
|
||||
正式考试通过 → 通知本人并引导查看证书；用户被设岗 → 通知本人）；
|
||||
`GET /api/notifications`、`GET /api/notifications/unread-count`、
|
||||
`PUT /api/notifications/:id/read`、`PUT /api/notifications/read-all`；
|
||||
前端「消息通知」页 + 侧栏铃铛角标（60s 轮询未读数）
|
||||
|
||||
### 定死（不做）
|
||||
- **社交社区/讨论区**：明确不实现，后续也不纳入路线图
|
||||
|
||||
---
|
||||
|
||||
## V1.6（2026-08-16）
|
||||
|
||||
**学员成长体系落地（游戏化 + 认证 + 学情）。** 对标主流企业培训平台（云学堂/绚星/腾讯乐享/Absorb 等）
|
||||
三大高频能力，突破原「极致极简、杜绝统计/学情分析」设计边界，补齐学员成长激励与学习效果反馈闭环。
|
||||
|
||||
### 新增
|
||||
- **学习积分 + 排行榜**：`point_event` 积分流水表 + `user.learning_points` 冗余总额；
|
||||
首次浏览公司/产品/课程、自测提交、正式考试通过、错题标记已掌握均自动加分（规则集中常量，见下）；
|
||||
`GET /api/points/me`（我的积分+流水）、`GET /api/points/leaderboard`（全员排行榜含名次）；
|
||||
前端 `/exam/leaderboard`「学习排行榜」页
|
||||
- **考试合格证书**：`certificate` 表；正式考试通过自动颁发（按 `exam_record_id` 幂等去重）；
|
||||
`GET /api/exam/certificates` + `GET /api/exam/certificates/:id`（学员）、`GET /api/system/certificates`（管理员）；
|
||||
前端 `/exam/my-certificates`「我的证书」页（含可打印证书弹窗）
|
||||
- **学习档案 / 能力雷达**：`GET /api/my/profile` 返回学习统计（浏览/自测/正式/错题/积分）、
|
||||
按域（公司认知/产品知识/销售能力）能力雷达、薄弱域、正式成绩趋势；
|
||||
前端 `/exam/my-profile`「我的学习档案」页 + 新增 `RadarChart` SVG 雷达图组件
|
||||
|
||||
### 积分规则（集中 `internal/api/points.go` 常量，可一键调整）
|
||||
| 行为 | 积分 |
|
||||
|------|------|
|
||||
| 首次浏览公司介绍 | +10 |
|
||||
| 首次浏览单个产品 | +2 |
|
||||
| 首次浏览单门课程 | +5 |
|
||||
| 自测提交一次 | +5 |
|
||||
| 正式考试通过 | +50 |
|
||||
| 错题标记已掌握 | +3 |
|
||||
|
||||
### 设计说明
|
||||
- 能力雷达按「正式考试答题明细 → 题目 → 知识域」反推各域正确率；自测不落分（P03），故自测次数由积分流水统计
|
||||
- 积分流水逐笔可审计；「错题标记已掌握」仅在未掌握→已掌握时加分，避免反复切换刷分
|
||||
|
||||
---
|
||||
|
||||
## V1.5（2026-08-16）
|
||||
|
||||
**岗位能力闭环补全（P1 + P2）落地。** 在 P0 岗位驱动组卷之上，补齐学员侧「我的岗位应学清单」、
|
||||
「错题本」、成绩按岗位聚合、岗位考试蓝图、简答题 LLM 评分与后端自动化测试。
|
||||
|
||||
### 新增（P1）
|
||||
- 学员「我的岗位应学清单」`GET /api/my/position`：返回本人岗位 + 应学范围（域/课程/产品/级别/权重/必学）
|
||||
- 成绩按岗位聚合 `GET /api/system/exam-stats-by-position`（admin）：按岗位汇总员工数/参考人次/通过人次/通过率/平均分
|
||||
- 岗位考试蓝图：`position_exam_blueprint` 表 + `GET/PUT /api/positions/:id/blueprint`（整表覆盖）；
|
||||
`pickQuestions` 优先按蓝图逐条抽题（域+题型+题量），无蓝图回退 P0 岗位映射抽题；
|
||||
`CreatePaper/UpdatePaper` 校验蓝图总题量 ≥ 试卷题量
|
||||
- 前端：`/exam/my-position`「我的岗位清单」页；岗位管理页「考试蓝图」编辑面板；
|
||||
全部成绩页新增「按岗位统计」Tab
|
||||
|
||||
### 新增（P2）
|
||||
- 错题本：`mistake_record` 表；交卷判分循环中答错自动入本（自测/正式均写，按
|
||||
`(user_id, question_id, source)` 去重，再次答错更新并重置为未掌握）；
|
||||
`GET /api/exam/mistakes` + `PUT /api/exam/mistakes/:id/resolve`；
|
||||
前端 `/exam/my-mistakes`「我的错题本」页（来源/状态筛选 + 标记已掌握）
|
||||
- 简答题 + LLM 评分：`question.type` 增加 `essay`（`answer` 存评分标准，`options` 空）；
|
||||
交卷时对 essay 题调 LLM（复用 `title_gen` 文本生成路由，回退链 + 审计，`essay_grade` 能力不扣点）
|
||||
按评分标准打 0~1 得分率；总分改为 `Σ得分率/题数×总分`，选择题仍确定性判分；
|
||||
`detail_json` 新增 `score_rate` / `comment`；前端答题页 essay 文本域 + 结果页得分率展示
|
||||
- 自动化测试：`internal/api/exam_test.go`（isCorrect/splitDomains/splitIDs/dedupe/
|
||||
normalizeUserAnswer/parseEssayScore/scoreBand/round1）、`internal/ai/retrieve_test.go`
|
||||
（splitTerms/cosine）；`go test ./...` 全绿
|
||||
|
||||
---
|
||||
|
||||
## V1.4（2026-08-16）
|
||||
|
||||
**岗位与知识对应能力（P0）落地。** 补齐「岗位 → 知识映射 → 用户设岗 → 岗位驱动组卷」闭环，
|
||||
对齐 pj006 的岗位驱动思想，但保持极简单租户定位（不引入洋葱模型 / 多租户 / 多岗位）。
|
||||
|
||||
### 新增
|
||||
- 数据表 `position`（岗位）与 `position_knowledge`（岗位知识要求映射：知识域 domain +
|
||||
可选课程 course_id / 产品 product_id + 级别 L1-L4 + 权重 + 必学开关）
|
||||
- `User.PositionID`、`ExamPaper.PositionID` 可空列（AutoMigrate 幂等，对现有数据零破坏）
|
||||
- 岗位 API（admin）：`GET/POST/PUT/DELETE /api/positions`、
|
||||
`GET/PUT /api/positions/:id/knowledge`（整表覆盖保存映射）、`PUT /api/users/:id/position`（设岗/清岗）
|
||||
- 岗位驱动组卷：`pickQuestions` 按岗位知识映射圈定题池（岗位考试优先，否则回退 domain 抽题）；
|
||||
`CreatePaper/UpdatePaper` 校验「岗位必须存在且已配置知识映射」
|
||||
- 前端「岗位管理」页（`/system/positions`）+ 知识映射编辑面板；用户管理页「关联岗位」行内下拉；
|
||||
题库管理试卷表单「关联岗位」下拉
|
||||
|
||||
---
|
||||
|
||||
## V1.3（2026-08-16）
|
||||
|
||||
**目录重构 + 全功能联调测试 + 修复 1 个缺陷。**
|
||||
|
||||
### 变更
|
||||
- 后端 `KNOWLEDGE_SOURCE_DIR` 默认值 `../docs/knowledge_source` → `knowledge_source`；部署路径 `/opt/eai_agentplatform/knowledge_source`
|
||||
- 前后端全功能联调测试通过（认证/权限边界/产品/课程/考试/素材审批/知识入库/AI）
|
||||
- 素材存储目录 `data/media` → `data/kb_data`，子目录三态化：`approved/`（已审批公开）、
|
||||
`pending/`（待审批）、`rejected/`（已驳回）；环境变量 `MEDIA_DIR` → `KB_DATA_DIR`。
|
||||
表名 `media_file`、API 路由 `/api/media/*`、静态 URL 前缀 `/media` 均保持不变。
|
||||
|
||||
### 修复
|
||||
- `GET /api/exam/cover?id={id}` 无法解析 query 参数（`parseID` 误读路径参数 `c.Param`），
|
||||
导致考试封面永远返回「无效的 id」；改用 `c.Query("id")` 修复
|
||||
|
||||
---
|
||||
|
||||
## V1.2（2026-08-15）
|
||||
|
||||
**后端 Python → Go 重写完成，删除旧 Python 后端目录。**
|
||||
|
||||
### 变更
|
||||
- 后端由 FastAPI/Python 整体重写为 **Go + Gin + GORM + SQLite（modernc 纯Go驱动）**，位于 `backend-go/`
|
||||
- 旧 Python 后端目录 `backend/` 已整体删除，Go 后端为唯一后端
|
||||
- 认证：JWT（golang-jwt）+ bcrypt；文档转换：LibreOffice + pdftotext（裸进程）
|
||||
- 部署：裸进程 + systemd + Clonezilla 整盘克隆，Go 单二进制交付（无 Docker、无源码交付）
|
||||
- 文件存储路径：`backend/data/media` → `data/media`（Go 后端工作目录下，部署为 `/opt/eai_agentplatform/data/media`）
|
||||
|
||||
---
|
||||
|
||||
## V1.1（2026-08-15）
|
||||
|
||||
**最终定稿版。** 修复 V1.0 中 9 个内部不自洽问题。
|
||||
|
||||
### 新增
|
||||
- AI LLM 底座明确为「内网可访问地址（OpenAI 兼容接口）」，消除矛盾
|
||||
- MP4 仅预览、不提取文本、不进 AI 知识库，消除矛盾
|
||||
- PDF 文本提取技术选型（PyMuPDF）
|
||||
- 题库管理、组卷规则、合格线配置，补全考试闭环
|
||||
- 产品 / 课程内容的后台维护入口
|
||||
- 认证鉴权方案（JWT + bcrypt + 后端 API 鉴权）
|
||||
- 大文件分片上传、审批后异步转换任务、上传安全
|
||||
- 核心数据表字段设计（8 张核心表 + system_config）
|
||||
- 部署架构补充 LLM 服务与 Nginx 反代
|
||||
|
||||
---
|
||||
|
||||
## V1.0（初始版）
|
||||
|
||||
初始产品需求文档。
|
||||
@@ -0,0 +1,44 @@
|
||||
# 01_System_Overall — 系统总览
|
||||
|
||||
> **命名规则：** `SY{NN}_{描述}.md`
|
||||
> **用途：** 只保留当前系统现状、当前口径与当前方法，不再在主层保留历史推进链。
|
||||
|
||||
## 当前统一口径
|
||||
|
||||
- 当前术语与总架构，以 `SY21` 为准
|
||||
- 当前一级对象与导航，以 `SY22` 为准
|
||||
- 当前对象抽取方法，以 `SY25` 为准
|
||||
- 当前正式对象目录，以 `docs/05_Object_Catalog/` 为准
|
||||
- 当前版本能力变化，以 `变更日志.md` 为准
|
||||
|
||||
当前产品一级导航目标态为：
|
||||
|
||||
`新建任务 / 项目 / 专员·技能·APP·连接器 / 长程APP / 知识库 / 后台管理 / 我的`
|
||||
|
||||
## 当前文件清单
|
||||
|
||||
| 文件 | 说明 |
|
||||
|------|------|
|
||||
| `目录说明.md` | 本索引文件 |
|
||||
| `变更日志.md` | 当前版本演进与能力变更记录 |
|
||||
| `SY01_系统总览.md` | 当前系统定位、边界与阅读顺序 |
|
||||
| `SY02_设计原则.md` | 当前有效的硬约束与设计原则 |
|
||||
| `SY21_统一角色技能动作架构.md` | 当前总架构确认稿 |
|
||||
| `SY22_角色技能应用统一任务架构.md` | 当前一级对象与导航确认稿 |
|
||||
| `SY25_业务逻辑拆解与数字员工抽取方法.md` | 当前对象提取与业务拆解方法 |
|
||||
| `History_And_Retrospectives/目录说明.md` | 已移出主层的阶段复盘与旧稿归档说明 |
|
||||
|
||||
## 当前阅读顺序
|
||||
|
||||
1. `SY01`：先看平台现状、边界和阅读入口
|
||||
2. `SY02`：再看当前硬约束
|
||||
3. `SY21`：理解当前总架构与命名口径
|
||||
4. `SY22`：理解当前一级对象和导航结构
|
||||
5. `SY25`：理解对象应如何从业务中被提取
|
||||
|
||||
## 管理规则
|
||||
|
||||
1. 主层只放“当前仍然有效”的文件
|
||||
2. 方案稿、推演稿、阶段收口稿、旧命名稿，一律移入 `History_And_Retrospectives`
|
||||
3. 新增系统总览类文档前，先判断它是“现状文档”还是“过程文档”
|
||||
4. 现状被新文档替代后，旧文档不再与现行文档并列
|
||||
Reference in New Issue
Block a user