docs: 重构仓库文档目录并迁移训练素材
按当前架构重组 docs 目录，统一中文命名与目录分层，并将训练原材料迁移到独立目录以保持架构文档边界清晰。
This commit is contained in:
eaiadmin
@@ -0,0 +1,20 @@
|
||||
# 动作目录
|
||||
|
||||
> 状态：当前有效
|
||||
|
||||
动作是对象层中的执行与治理对象。
|
||||
|
||||
当前动作分两层理解：
|
||||
|
||||
1. 平台层动作定义对象
|
||||
2. 连接器内部的动作目录
|
||||
|
||||
## 当前边界
|
||||
|
||||
- action 不是当前运行主语
|
||||
- action 用于定义、治理和编目可执行动作
|
||||
- task 的真实执行链当前仍由 specialist runtime 驱动
|
||||
|
||||
## 当前说明
|
||||
|
||||
本目录先保留为正式对象位，用于承接后续动作清单与动作详情。
|
||||
@@ -0,0 +1,23 @@
|
||||
# 连接器目录
|
||||
|
||||
> 状态：当前有效
|
||||
|
||||
连接器是对象层中的外部系统访问对象。
|
||||
|
||||
它们负责：
|
||||
|
||||
- 访问外部系统
|
||||
- 提供可查询对象
|
||||
- 暴露动作能力
|
||||
|
||||
## 当前特点
|
||||
|
||||
- 当前连接器更多以代码注册表存在
|
||||
- 它们不像 specialist / skill / xapp 那样主要靠数据库表定义
|
||||
- 对象目录层先保留连接器作为正式对象位
|
||||
|
||||
## 当前边界
|
||||
|
||||
- connector 是对象，不是业务模块
|
||||
- connector 为 specialist、skill、xapp 和 action 提供外部访问能力
|
||||
- 后续如需补完整清单，可在本目录继续展开
|
||||
@@ -0,0 +1,35 @@
|
||||
# 技能目录
|
||||
|
||||
> 状态：当前有效
|
||||
|
||||
当前技能目录以运行中注册表为准。
|
||||
|
||||
技能是能力定义对象，负责承接单点动作、处理模板和执行能力，不承担长期岗位责任。
|
||||
|
||||
当前清单如下：
|
||||
|
||||
| 展示编号 | 逻辑编号 | Key | 名称 | 当前定位 | 状态 |
|
||||
|---|---|---|---|---|---|
|
||||
| `能01` | `EAI-K-01` | `smart-assistant` | 智能助手 | 通用任务拆解与结果收口 | active |
|
||||
| `能02` | `EAI-K-02` | `document-translate` | 文档翻译 | 文档级翻译与术语对齐 | active |
|
||||
| `能03` | `EAI-K-03` | `copy-proofreading` | 文案校对 | 文本问题识别与改写 | active |
|
||||
| `能04` | `EAI-K-04` | `audio-transcribe` | 会议音频分析（转写） | 音频转写与结构化整理 | active |
|
||||
| `能05` | `EAI-K-05` | `batch-extract` | 批量字段提取 → Excel | 多材料字段抽取与汇表 | active |
|
||||
| `能06` | `EAI-K-06` | `contract-review` | 合同批量审查与提取（审查） | 合同风险识别与审查摘要 | active |
|
||||
| `能07` | `EAI-K-07` | `report-generation` | 一键生成报告 | 报告材料收拢与正文生成 | active |
|
||||
| `能08` | `EAI-K-08` | `ppt-generation` | 一键生成 PPT | 汇报页骨架与演示结构生成 | active |
|
||||
| `能09` | `EAI-K-09` | `mind-map` | 会议音频分析（思维导图） | 层级结构压缩与导图输出 | active |
|
||||
| `能10` | `EAI-K-10` | `longform-writing` | 公文辅助写作（长文） | 长文大纲与正文骨架生成 | active |
|
||||
| `能11` | `EAI-K-11` | `ocr-understanding` | 图片/扫描件智能识别 | 图文理解与字段整理 | active |
|
||||
| `能12` | `EAI-K-12` | `meeting-minutes` | 会议音频分析（纪要） | 纪要、结论和待办整理 | active |
|
||||
| `能13` | `EAI-K-13` | `table-cleanup` | 知识库表格视图 | 结构化表格整理与清洗 | active |
|
||||
| `能14` | `EAI-K-14` | `progress-report` | 一键周报 | 进展、风险与下一步计划汇总 | active |
|
||||
| `能15` | `EAI-K-15` | `contract-brief` | 合同批量审查与提取（提取） | 合同核心条款与重点摘要 | active |
|
||||
| `能16` | `EAI-K-16` | `interview-summary` | 招聘简历助手 | 访谈与候选人内容摘要 | active |
|
||||
| `能17` | `EAI-K-17` | `policy-rewrite` | 公文辅助写作（制度） | 制度文稿改写与规范统一 | active |
|
||||
|
||||
## 当前边界
|
||||
|
||||
- 本目录记录运行中的内建技能
|
||||
- skill 是对象层的一等对象，不等同于工具页或独立业务模块
|
||||
- 后续若某个技能进入重点产品化或形成独立对象详情，再补对应详情页
|
||||
@@ -0,0 +1,56 @@
|
||||
# 售前解决方案专员
|
||||
|
||||
## 结论
|
||||
|
||||
`售前解决方案专员` 成立，因为它对应的是现实企业中稳定存在的售前岗位，而不是“售前方案”这种结果物。
|
||||
|
||||
它对应的真实岗位通常包括：
|
||||
|
||||
- 售前顾问
|
||||
- 解决方案顾问
|
||||
- 售前工程师
|
||||
|
||||
## 对象定义
|
||||
|
||||
- 中文名：售前解决方案专员
|
||||
- 建议 Key：`presales-solution-specialist`
|
||||
- 所处流程：需求澄清、方案设计、演示、POC、投标支持
|
||||
- 定位：把客户问题转成可理解、可验证、可成交的解决方案
|
||||
|
||||
## 核心职责
|
||||
|
||||
做：
|
||||
|
||||
- 深入澄清客户需求、场景、约束和目标
|
||||
- 设计解决方案结构与能力边界
|
||||
- 产出演示材料、方案说明、POC 建议
|
||||
- 支持关键客户评审、演示和投标答疑
|
||||
|
||||
不做：
|
||||
|
||||
- 线索开发
|
||||
- 商务报价
|
||||
- 合同流转
|
||||
- 签约后长期经营
|
||||
|
||||
## 关键输入
|
||||
|
||||
- 销售专员沉淀的客户背景与需求摘要
|
||||
- 行业方案
|
||||
- 产品能力说明
|
||||
- 历史案例
|
||||
- 客户现有系统与预算边界
|
||||
|
||||
## 核心输出
|
||||
|
||||
- 需求澄清纪要
|
||||
- 解决方案草案
|
||||
- 演示提纲 / 演示材料
|
||||
- POC 建议
|
||||
- 风险边界说明
|
||||
|
||||
## 为什么它比“售前方案专员”更合理
|
||||
|
||||
“售前方案”只是产物，不是岗位。
|
||||
|
||||
真正稳定存在的岗位价值在“售前解决方案”这一整段职责里，而不是只把方案文档本身包装成一个对象。
|
||||
@@ -0,0 +1,56 @@
|
||||
# 商务合同专员
|
||||
|
||||
## 结论
|
||||
|
||||
`商务合同专员` 成立，因为它对应的是销售主流程里真实存在的商务与合同推进岗位。
|
||||
|
||||
它通常对应：
|
||||
|
||||
- 商务专员
|
||||
- 合同专员
|
||||
- 投标专员
|
||||
|
||||
## 对象定义
|
||||
|
||||
- 中文名：商务合同专员
|
||||
- 建议 Key：`business-contract-specialist`
|
||||
- 所处流程：报价、商务条款、合同流转、审批协同
|
||||
- 定位：把客户意向落成可签约、可审批、可执行的正式交易条件
|
||||
|
||||
## 核心职责
|
||||
|
||||
做：
|
||||
|
||||
- 管理报价、折扣、付款方式等商务条件
|
||||
- 协调合同模板、条款修改与版本流转
|
||||
- 推进内部审批和外部签署流程
|
||||
- 维护投标材料、商务附件和签约台账
|
||||
|
||||
不做：
|
||||
|
||||
- 前台获客
|
||||
- 深度需求分析
|
||||
- 售前方案设计
|
||||
- 签约后客户经营
|
||||
|
||||
## 关键输入
|
||||
|
||||
- 销售确认的客户意向与成交条件
|
||||
- 售前解决方案专员输出的范围边界
|
||||
- 报价规则
|
||||
- 合同模板
|
||||
- 审批规则
|
||||
|
||||
## 核心输出
|
||||
|
||||
- 报价单
|
||||
- 商务条款摘要
|
||||
- 合同版本记录
|
||||
- 审批进度
|
||||
- 待确认事项清单
|
||||
|
||||
## 与合同审查对象的关系
|
||||
|
||||
如果企业法务审查很重，后续可以再细分出法务/合同审核角色。
|
||||
|
||||
但在销售主流程骨架里，先由“商务合同专员”统一承接，更符合成交链路的产品表达。
|
||||
@@ -0,0 +1,56 @@
|
||||
# 客户成功专员
|
||||
|
||||
## 结论
|
||||
|
||||
`客户成功专员` 成立，因为它对应的是签约后客户经营这一段真实存在的岗位价值。
|
||||
|
||||
它通常对应：
|
||||
|
||||
- 客户成功
|
||||
- 客户运营
|
||||
- 续约客户经理
|
||||
|
||||
## 对象定义
|
||||
|
||||
- 中文名：客户成功专员
|
||||
- 建议 Key：`customer-success-specialist`
|
||||
- 所处流程：上线后推进、使用经营、续约增购
|
||||
- 定位：让客户真正上线、真正使用，并持续续约和增购
|
||||
|
||||
## 核心职责
|
||||
|
||||
做：
|
||||
|
||||
- 推进客户上线后的使用落地
|
||||
- 跟踪活跃度、反馈和风险信号
|
||||
- 协调培训、答疑、问题闭环和关键节点沟通
|
||||
- 识别续约、增购、转介绍机会
|
||||
|
||||
不做：
|
||||
|
||||
- 前期获客
|
||||
- 商机开发
|
||||
- 商务审批流转
|
||||
- 替代交付系统本身
|
||||
|
||||
## 关键输入
|
||||
|
||||
- 已签约客户资料
|
||||
- 项目上线进度
|
||||
- 培训记录
|
||||
- 使用数据
|
||||
- 客户反馈与会议纪要
|
||||
|
||||
## 核心输出
|
||||
|
||||
- 客户健康度判断
|
||||
- 上线 / 使用推进记录
|
||||
- 风险客户清单
|
||||
- 续约与增购机会清单
|
||||
- 客户阶段总结
|
||||
|
||||
## 为什么它比“客户跟进专员”更合理
|
||||
|
||||
“客户跟进”只是动作描述，既可能发生在销售前，也可能发生在签约后。
|
||||
|
||||
而“客户成功”是企业里更稳定、更清楚的岗位价值，边界也更明确：它承接的是签约后的客户经营，而不是泛化的“谁都能跟进一点”。
|
||||
@@ -0,0 +1,63 @@
|
||||
# 客户跟进专员
|
||||
|
||||
## 结论
|
||||
|
||||
`customer-followup` 是对旧对象 `logistics-fulfillment` 的彻底重构，不是简单改名。
|
||||
|
||||
旧对象偏物流履约与异常跟踪，不适合作为通用专员产品；新对象改成更通用、更常见的客户推进场景：
|
||||
|
||||
- 整理客户资料
|
||||
- 分析客户意向
|
||||
- 生成联系建议
|
||||
- 推进会议预约
|
||||
- 回写跟进状态
|
||||
|
||||
## 为什么重构
|
||||
|
||||
旧对象“履约跟单专员”存在两个问题：
|
||||
|
||||
1. 职位名不够通用，更多是行业内产品化命名，不是大多数企业一眼就懂的岗位对象。
|
||||
2. 底层业务偏物流履约，不适合作为当前阶段的通用企业产品样本。
|
||||
|
||||
## 新对象定义
|
||||
|
||||
- 中文名：客户跟进专员
|
||||
- Key：`customer-followup`
|
||||
- 路由：`/apps/customer-followup`
|
||||
- 定位：客户资料整理到会议预约这一段的推进对象
|
||||
|
||||
## 目标用户
|
||||
|
||||
- 销售
|
||||
- 售前
|
||||
- 客户成功
|
||||
- 需要推进商机或会议预约的业务团队
|
||||
|
||||
## 当前边界
|
||||
|
||||
做：
|
||||
|
||||
- 客户资料归档
|
||||
- 客户意向分层
|
||||
- 联系建议
|
||||
- 会议预约建议
|
||||
- 跟进状态回写
|
||||
|
||||
不做：
|
||||
|
||||
- 伪造客户承诺
|
||||
- 直接替用户发外部联系
|
||||
- 在缺失客户历史时擅自补全事实
|
||||
|
||||
## 代码落点
|
||||
|
||||
- 前端对象定义：[eai_agentplatform/frontend/src/specialists/packages/customer-followup/manifest.js](../../../eai_agentplatform/frontend/src/specialists/packages/customer-followup/manifest.js)
|
||||
- 后端对象定义：[eai_agentplatform/backend-go/internal/specialists/packages/customer_followup/manifest.go](../../../eai_agentplatform/backend-go/internal/specialists/packages/customer_followup/manifest.go)
|
||||
- 专员种子：[eai_agentplatform/backend-go/internal/specialists/seeding/seed_specialists.go](../../../eai_agentplatform/backend-go/internal/specialists/seeding/seed_specialists.go)
|
||||
- 工作台示例：[eai_agentplatform/frontend/src/config/workbench.js](../../../eai_agentplatform/frontend/src/config/workbench.js)
|
||||
|
||||
## 下一步
|
||||
|
||||
1. 观察是否需要补 CRM 连接器绑定。
|
||||
2. 评估是否要补独立“会议预约 / 联系触达”技能。
|
||||
3. 后面如数据面继续做大，再判断是否升为更完整的商机推进专员族。
|
||||
@@ -0,0 +1,72 @@
|
||||
# 专员目录
|
||||
|
||||
> 状态：当前有效
|
||||
|
||||
当前专员目录以运行中注册表为准。
|
||||
|
||||
专员是当前系统中最重要的协作人格对象，也是 task 运行时的主要责任主体。
|
||||
|
||||
当前清单如下：
|
||||
|
||||
| 展示编号 | 逻辑编号 | Key | 名称 | 当前定位 | 状态 | 下一步 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| `专01` | `EAI-S-01` | `contract-review` | 合同审查专员 | 条款风险、红线建议、审查交付 | active | 保留，后面再看是否补强法务数据面 |
|
||||
| `专02` | `EAI-S-02` | `solution-proposal` | 售前方案专员 | 客户需求澄清、方案草案、评审材料 | active | 保留，后面可补 CRM / 方案模板绑定 |
|
||||
| `专03` | `EAI-S-03` | `training-delivery` | 培训交付专员 | 培训计划、交付节点、归档闭环 | active | 继续观察是否需要拆出交付 xapp |
|
||||
| `专04` | `EAI-S-04` | `wechat-official-account` | 公众号专员 | 选题、提纲、正文、发布准备 | active | 继续包化公众号工作流与模型 |
|
||||
| `专05` | `EAI-S-05` | `customer-followup` | 客户跟进专员 | 客户资料整理、意向分层、联系推进、会议预约 | active | 作为新口径继续打磨；详见 [客户跟进专员.md](./客户跟进专员.md) |
|
||||
| `专06` | `EAI-S-06` | `resume-processor` | 招聘筛选专员 | 招聘入口归档、候选人筛选、面试推进 | active | 继续观察是否需要补独立招聘连接器 |
|
||||
|
||||
## 已退出当前目录但保留历史意义的对象
|
||||
|
||||
- `knowledge-operations`
|
||||
- `process-coordination`
|
||||
- `report-generation`
|
||||
- `presentation-briefing`
|
||||
- `hr-email-sorter`
|
||||
- `logistics-fulfillment`
|
||||
|
||||
---
|
||||
|
||||
## 当前建议中的销售流程专员骨架
|
||||
|
||||
以下是面向后续产品化收口的销售流程专员骨架。
|
||||
|
||||
判断标准：
|
||||
|
||||
1. 现实企业里是否存在这类岗位
|
||||
2. 它在销售流程里是否有稳定主责
|
||||
3. 它是不是岗位，而不是结果物、动作或流程节点
|
||||
|
||||
| 建议对象 | 建议 Key | 对应真实岗位 | 当前判断 |
|
||||
|---|---|---|---|
|
||||
| [销售专员](./销售专员.md) | `sales-specialist` | 销售代表 / 客户经理 / 销售顾问 | 建议新增为正式销售前台对象 |
|
||||
| [售前解决方案专员](./售前解决方案专员.md) | `presales-solution-specialist` | 售前顾问 / 解决方案顾问 / 售前工程师 | 建议作为 `solution-proposal` 的重塑方向 |
|
||||
| [商务合同专员](./商务合同专员.md) | `business-contract-specialist` | 商务专员 / 合同专员 / 投标专员 | 建议作为销售成交条件与合同流转主对象 |
|
||||
| [客户成功专员](./客户成功专员.md) | `customer-success-specialist` | 客户成功 / 客户运营 / 续约客户经理 | 建议作为签约后经营主对象 |
|
||||
|
||||
### 当前对象到建议骨架的映射
|
||||
|
||||
| 当前对象 | 建议去向 |
|
||||
|---|---|
|
||||
| `solution-proposal` / 售前方案专员 | 重塑为 `售前解决方案专员` |
|
||||
| `customer-followup` / 客户跟进专员 | 拆分并回收至 `销售专员` 与 `客户成功专员` |
|
||||
| `contract-review` / 合同审查专员 | 暂保留；后续评估是并入 `商务合同专员`，还是单独作为法务审查对象 |
|
||||
|
||||
### 当前不建议继续使用的名字
|
||||
|
||||
- `售前方案专员`
|
||||
- `客户跟进专员`
|
||||
- `培训交付专员`
|
||||
|
||||
这些名称分别对应以下问题：
|
||||
|
||||
- 结果物
|
||||
- 动作
|
||||
- 长流程交付环节
|
||||
|
||||
## 当前边界
|
||||
|
||||
- specialist 是对象层的一等对象
|
||||
- specialist 对应真实岗位责任，而不是结果物、动作或长流程环节
|
||||
- 当前 task 运行时仍以 specialist 为主要挂载点
|
||||
@@ -0,0 +1,63 @@
|
||||
# 销售专员
|
||||
|
||||
## 结论
|
||||
|
||||
`销售专员` 是销售流程中的前台推进岗位，不是“客户跟进”这类动作型包装对象。
|
||||
|
||||
它对应的是真实企业里稳定存在的一类岗位：
|
||||
|
||||
- 销售代表
|
||||
- 客户经理
|
||||
- 销售顾问
|
||||
- BD
|
||||
|
||||
因此它可以成立为数字员工对象。
|
||||
|
||||
## 对象定义
|
||||
|
||||
- 中文名：销售专员
|
||||
- 建议 Key：`sales-specialist`
|
||||
- 所处流程：获客、线索筛选、初步沟通、商机推进
|
||||
- 定位：把潜在线索推进到明确商机
|
||||
|
||||
## 核心职责
|
||||
|
||||
做：
|
||||
|
||||
- 收集和筛选线索
|
||||
- 整理客户基础资料
|
||||
- 记录初步沟通结果
|
||||
- 判断是否值得继续推进
|
||||
- 维护商机状态
|
||||
- 识别何时需要拉入售前解决方案专员或商务合同专员
|
||||
|
||||
不做：
|
||||
|
||||
- 深度方案设计
|
||||
- 商务报价与合同流转
|
||||
- 签约后的长期经营
|
||||
- 伪造客户需求或预算判断
|
||||
|
||||
## 关键输入
|
||||
|
||||
- 线索名单
|
||||
- 客户资料
|
||||
- CRM 信息
|
||||
- 历史沟通记录
|
||||
- 产品基础资料
|
||||
|
||||
## 核心输出
|
||||
|
||||
- 客户画像
|
||||
- 商机判断结果
|
||||
- 跟进记录
|
||||
- 下一步动作建议
|
||||
- 需售前介入的需求摘要
|
||||
|
||||
## 为什么它比“客户跟进专员”更合理
|
||||
|
||||
“客户跟进”是动作，不是岗位。
|
||||
|
||||
销售流程里真正稳定存在的前台岗位是销售，而不是一个抽象的“跟进角色”。
|
||||
|
||||
因此，如果对象要按真实岗位定义，销售前段应优先落到“销售专员”，而不是继续保留“客户跟进专员”。
|
||||
@@ -0,0 +1,23 @@
|
||||
# XApp 目录
|
||||
|
||||
> 状态：当前有效
|
||||
|
||||
当前 xapp 口径分两层：
|
||||
|
||||
1. 内建成品 xapp
|
||||
2. 用户应用中心中的自定义 xapp
|
||||
|
||||
xapp 是对象层的一等对象，同时也是当前面向用户的成品入口壳。
|
||||
|
||||
当前内建 xapp 清单如下：
|
||||
|
||||
| 展示编号 | 逻辑编号 | Key | 名称 | 当前定位 | 状态 | 下一步 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| `应01` | `EAI-X-01` | `internal-training` | 内部培训APP | 销售培训、产品知识、公司介绍的统一培训空间 | active | 后续补对象级产品页与模块边界 |
|
||||
| `应02` | `EAI-X-02` | `internal-exam` | 内部考试APP | 练习、自测、正式考试、记录、证书的统一考试空间 | active | 后续补对象级产品页与结果资产边界 |
|
||||
|
||||
## 当前边界
|
||||
|
||||
- `xapp center` 允许用户创建自定义 xapp，但这类对象当前不算固定对象目录中的长期条目
|
||||
- xapp 是对象，不等于当前运行主键
|
||||
- 当前前台长程壳主要体现为 `internal-training` 和 `internal-exam`
|
||||
@@ -0,0 +1,42 @@
|
||||
# 05_Object_Catalog — 系统对象目录
|
||||
|
||||
> 状态：当前有效
|
||||
> 最后更新：2026-09-21
|
||||
|
||||
本目录是当前系统的一等对象目录。
|
||||
|
||||
它不再属于 `06_Product_Lines`，而是和 `03_Frontend`、`04_Backend` 并列，承担对象定义、对象清单和对象详情的主入口职责。
|
||||
|
||||
## 当前对象层
|
||||
|
||||
当前系统的一等对象包括：
|
||||
|
||||
- `specialists`：协作人格与岗位责任对象
|
||||
- `skills`：能力定义对象
|
||||
- `xapps`：成品入口与运行壳对象
|
||||
- `connectors`：外部系统访问对象
|
||||
- `actions`：动作目录与治理对象
|
||||
|
||||
## 当前作用
|
||||
|
||||
本目录负责：
|
||||
|
||||
1. 记录对象清单
|
||||
2. 记录对象详情
|
||||
3. 提供对象命名与对象边界的可读入口
|
||||
4. 作为系统对象层与产品对象层之间的桥接目录
|
||||
|
||||
## 阅读顺序
|
||||
|
||||
1. 先读 `specialists/目录.md`
|
||||
2. 再读 `skills/目录.md`
|
||||
3. 需要看成品入口时读 `xapps/目录.md`
|
||||
4. 需要看外部访问对象时读 `connectors/目录.md`
|
||||
5. 需要看动作治理时读 `actions/目录.md`
|
||||
|
||||
## 当前边界
|
||||
|
||||
- 本目录定义“系统里有哪些对象”
|
||||
- `03_Frontend` 负责解释这些对象如何在前端被看见和打开
|
||||
- `04_Backend` 负责解释这些对象如何在后端被定义和运行
|
||||
- `06_Product_Lines` 只负责这些对象如何被产品化和业务化包装
|
||||
Reference in New Issue
Block a user