chore: initialize wygj monorepo
This commit is contained in:
@@ -0,0 +1,448 @@
|
||||
# AI 人力资源系统 · 一期 Demo 作战清单
|
||||
|
||||
> 版本:v1.8 ｜ 日期:2026-07-03
|
||||
> 用途:一份纸面作战图,支撑「2026-07-05 周日出可跑 Demo、2026-07-06 周一给大老板演示」,同时说清「做了什么、没做什么、为什么」。
|
||||
> 收敛来源:原《物业管家与生活顾问 AI 陪练系统建设方案》+ 一期实施方案(含 ch.14/15 选型评估)+ 2026-07-01 需求讨论纪要 + 数据资源模型主题域草案。
|
||||
> v1.1 变更:D1–D8 决策已定(见第 8 节),相关章节同步锁定;D9(验收标准)待定。
|
||||
> v1.2 变更:新增第 9 节「周末施工排期(2026-07-03 周五 / 2026-07-04 周六 / 2026-07-05 周日 · 2 人时间盒)」。
|
||||
> v1.3 变更:D9 已定,新增第 10 节「一期最小可验收承诺」。至此 D1–D9 全部闭环。
|
||||
> v1.4 变更:因 Demo 进度提前,新增 D10「资料中台提前加码」和第 11 节;MinIO、OSS-first 文档上传、Excel/PPT 解析进入当前施工线,图片智能分析列入下一阶段。
|
||||
> v1.5 变更:新增 D11「向量库与语义检索路线」和第 12 节;一期选 Qdrant,保留 MySQL Fulltext,制度/SOP 回答采用混合召回 + 重排序 + 引用约束。
|
||||
> v1.6 变更:Qdrant 本地编排和后端最小闭环已落地;上传后尽力 upsert 向量,检索时与 MySQL Fulltext 做 RRF 融合。
|
||||
> v1.7 变更:资料处理服务端目录导入已从同步 Demo 升级为后台任务,页面可轮询进度和按同目录重试。
|
||||
> v1.8 变更:补齐 D12「用户端最小闭环」和第 5.1 节;Demo 必须能从候选人/员工视角发起至少 1 条路径,但仍用 Web/H5,不做独立 APP。
|
||||
|
||||
---
|
||||
|
||||
## 0. 一页速览(TL;DR)
|
||||
|
||||
- **系统定位**:面向物业一线的「**选 · 用 · 育 · 留**」全生命周期 **AI 人力资源系统**(HR 老大提出、给大老板汇报)。原「AI 陪练」只是其中「育/用」一个模块。
|
||||
- **死线**:2026-07-05 周日出可演示 Demo,2026-07-06 周一演示。团队约 2 人,时间极紧。
|
||||
- **六条核心决议**:
|
||||
1. **基座 = 若依(RuoYi)**,非 aifei / PandaWiki / JeecgBoot / Yuxi;集中式前后端分离,非微服务。
|
||||
2. **数据模型 = 复用 Silverston《数据模型资源手册》卷1 HR 主干**(Party-Role 分离 + Product 目录承载 SOP 分层)。
|
||||
3. **组织/人员/登录复用外部系统**,本系统只做「消费 + 扩展」,不当主数据源头。
|
||||
4. **资料中台提前加码**:已知业务资料约 3GB,包含 PPT/图片/Excel/Word/PDF;一期不再只演示 seed SOP,要先把 MinIO + 文档入库 + 解析状态打底。
|
||||
5. **语义检索路线 = MySQL Fulltext + Qdrant + rerank**:MySQL/MinIO 仍是事实源,Qdrant 只做向量索引;制度/SOP 必须混合召回、重排序、带引用回答。
|
||||
6. **用户端必须显式进入 Demo**:管理端负责配置/审核/看结果;用户端负责候选人作答、员工对练、SOP 问答、案例上传。Demo 用 Web/H5 轻入口,不做独立 APP。
|
||||
- **头号风险**:从单纯「范围失控」升级为**用户端缺口、资料规模、解析质量、异步任务稳定性、语义检索准确率和引用一致性**。Demo 仍守住第 5 节切割线,资料中台按第 11/12 节分片推进。
|
||||
|
||||
---
|
||||
|
||||
## 1. 定位与范围决议
|
||||
|
||||
**定位**:物业行业「选用育留」全生命周期 AI 人力资源系统。
|
||||
|
||||
| 生命周期段 | 覆盖能力 | 一期状态 |
|
||||
|---|---|---|
|
||||
| **选**(招聘) | AI 面试出题、候选人现场作答、AI 打分、面试记录 | 一期新增(原方案没有) |
|
||||
| **用**(配置上岗) | 岗位 SOP 匹配、岗前/入职培训、上岗资格 | 一期 |
|
||||
| **育**(训练) | 三角色对练、每日一练、专项训练营、错题本、师徒、案例学习 | 一期核心(原陪练主体) |
|
||||
| **留**(保留发展) | 能力雷达图、认证等级、晋升/绩效关联、荣誉激励 | 一期建规则,挂钩推迟 |
|
||||
| **案例沉淀**(贯穿) | 语音上传 → AI 整理 → 筛选 → AI 对话视频 | 一期(视频用样片) |
|
||||
|
||||
**明确移出一期范围(已定)**:
|
||||
- 内容营销中心(原第七章):属营销/获客,与 HR 无关 → ✅ **一期砍除**(D5)。
|
||||
- 独立语音 APP(豆包式):愿景,非交付物 → ✅ **Demo 用 Web**,APP 进二期(D6)。
|
||||
- 双图谱知识图谱(Neo4j):冷启动成本高 → ✅ **一期先 RAG**,图谱降级二期(D4)。
|
||||
|
||||
---
|
||||
|
||||
## 2. 技术选型决议
|
||||
|
||||
**基座:若依(RuoYi)** — 前后端分离(Vue + Java / Spring Boot 4)、内置 RBAC + RAG 知识库 + 后台、社区成熟、无许可证风险、可与采购系统用户体系对齐。
|
||||
|
||||
**为什么不是其它候选(一句话留档)**:
|
||||
|
||||
| 候选 | 结论 | 一句话理由 |
|
||||
|---|---|---|
|
||||
| **aifei** | ✗ 不采用 | AI Coding 框架,只优化「怎么写代码」,不提供任何现成模块;84 star、文档不全、企业实现走 VIP 付费(与枪毙 PandaWiki 同款风险);违背刚敲定的若依决策与采购系统复用约束。 |
|
||||
| PandaWiki | ✗ | 半开源、后续强制收费风险。 |
|
||||
| JeecgBoot | ✗ | 代码生成集成度过高、二次修改难。 |
|
||||
| Yuxi(玉溪) | 参考 | 仅二期借鉴其 Agent 能力,不做基座。 |
|
||||
|
||||
**架构**:集中式部署 + 前后端分离(非微服务)。理由:2 人小团队、无高并发、微服务开发协作成本高。
|
||||
|
||||
**必须自建(无任何框架可复用)**:三角色状态机(AI 客户/教练/考官)、评分引擎(情感+语义+SOP 关键点+Rubric)、方言 ASR 接入。这是一期真正的工程瓶颈。
|
||||
|
||||
**aifei 的可取之处(留作方法论,非选型)**:它的「数据模型越干净 → AI 生成越稳」这一洞察,反向强化了本项目「先把数据模型做扎实」的优先级。
|
||||
|
||||
---
|
||||
|
||||
## 3. 数据模型方向(选用育留 HR 主干)
|
||||
|
||||
**原则**:不发明表结构,抬 Silverston 通用企业模型的 HR 主干;通用主干优先,行业扩展后挂;主数据/事务/计量/治理分层建模。
|
||||
|
||||
**四段 × 核心实体(来自手册卷1 HR 章 + 通用主干)**:
|
||||
|
||||
| 段 | 核心实体(Silverston) | 落地对象 |
|
||||
|---|---|---|
|
||||
| 选 | `JOB APPLICATION`、`POSITION` | 招聘需求、职位、候选人、面试记录、offer |
|
||||
| 用 | `POSITION`、`EMPLOYMENT`、`PRODUCT CATEGORY` | 岗位-SOP 映射、上岗资格 |
|
||||
| 育 | `WORK EFFORT`、`ACTIVITY` | 训练/考核任务、对练记录、错题、学习路径 |
|
||||
| 留 | `SKILL`、`QUALIFICATION` | 能力评估、认证等级、晋升规则 |
|
||||
| 贯穿 | `PARTY` / `PARTY ROLE` | 主体与角色(见第 4 节同步边界) |
|
||||
|
||||
**两条关键建模决定**:
|
||||
- **Party-Role 分离**:一个人在全生命周期里依次/同时是候选人→新员工→学员→师父→考官,用 Party + Role,不为每种身份建表。
|
||||
- **SOP 用 Product-Category 层级 + Applicability 承载**:大类/中类/小类/行业 × 住宅/公建/景区。Demo 只填住宅类,其余预留结构。
|
||||
- **关系库 vs 向量库切分**:元数据/权限/版本/正文片段事实源落 MySQL,原始文件落 MinIO,Qdrant 只存向量索引与最小 payload;MySQL Fulltext 保留做精确关键词召回。
|
||||
|
||||
---
|
||||
|
||||
## 4. 主数据同步边界(外部同步 vs 本地自有)
|
||||
|
||||
**「复用采购系统用户体系」= 三件独立的事,别混为一谈**:
|
||||
|
||||
| 事项 | 含义 | Demo 处置 |
|
||||
|---|---|---|
|
||||
| ① 认证 / SSO | 用户怎么登录本系统 | ✅ 已定(D2):**本地账号**登录;SSO 留二期对接项 |
|
||||
| ② 权限映射 | 外部岗位/组织 → 本地角色 | 本地建映射表 |
|
||||
| ③ 主数据同步 | 组织架构 + 人员基础信息 | 导静态快照兜底 |
|
||||
|
||||
**同步边界表(只读消费 vs 本地自有)**:
|
||||
|
||||
| 实体 | 归属 | 读写 |
|
||||
|---|---|---|
|
||||
| PARTY / PERSON / ORGANIZATION / 组织树 | 外部同步 | 只读 |
|
||||
| POSITION / EMPLOYMENT / 任职 | 外部同步 | 只读 |
|
||||
| PARTY ROLE(学员/师父/教练/考官/审核员/管理员) | 本地自有 | 读写 |
|
||||
| 权限映射(外部岗位/组织 → 本地角色) | 本地自有 | 读写 |
|
||||
| SKILL / QUALIFICATION(能力/认证) | 本地自有 | 读写 |
|
||||
| JOB APPLICATION / 候选人 | 本地自有 | 读写 |
|
||||
| WORK EFFORT(训练/考核/案例记录) | 本地自有 | 读写 |
|
||||
|
||||
**三条硬约束**:
|
||||
- 本地只存外部 `party_id`,**绝不复制姓名/部门**;所有业务表只引用 ID。
|
||||
- **候选人是例外**:未入职者不在外部系统,先本地建 Party,入职后与同步员工 Party 挂钩。
|
||||
- 调岗/离职用 `FROM DATE / THRU DATE` 有效期承接,不物理删除,保历史可追溯。
|
||||
|
||||
---
|
||||
|
||||
## 5. MVP 三分切割线(核心作战图)⭐
|
||||
|
||||
> 规则:**2026-07-05 Demo 只做「英雄路径 + 壳」,其余明确归入一期或推迟。任何超出「2026-07-05 Demo」列的东西,在 Demo 冲刺期即刻砍掉。**
|
||||
|
||||
### 🔴 2026-07-05 Demo 必做(阻塞项)
|
||||
|
||||
| # | 事项 | 交付标准 |
|
||||
|---|---|---|
|
||||
| 1 | 核心陪练英雄路径 | 砍出 1–2 条**端到端跑通**(建议:语音面试→AI出题→答→打分;案例语音上传→AI整理成稿) |
|
||||
| 2 | 住宅类内容冷启动 | 至少 1 份真实 SOP + 若干样例案例 + 1 套评分 Rubric(2026-07-03 基础日确认谁给料) |
|
||||
| 3 | 组织/人员快照 | 导入静态快照或 mock 同步适配层(不依赖实时 API) |
|
||||
| 4 | 案例→视频 | 用 1 段预渲染样片演示流程,不真跑视频生成 |
|
||||
| 5 | 登录 | 本地账号可登入,SSO 标为「对接项」 |
|
||||
| 6 | 大模型接入 | 公有云 API 先行(合规问题入闸门) |
|
||||
| 7 | 方言语音 | 选 1 家 ASR/TTS 厂商,跑通 1 条语音路径 |
|
||||
| 8 | 演示脚本 | 一页故事线:点开顺序 + 每屏一句价值(服务于 HR 老大邀功叙事) |
|
||||
| 9 | 前端壳 | 全功能点可点开(AI 出图 + 若依脚手架批量生成),英雄路径精做 |
|
||||
| 10 | 用户端轻入口 | Web/H5 同前端提供候选人/员工入口;演示时至少从用户端完成 1 条路径,管理端只负责配置和看结果 |
|
||||
|
||||
### 5.1 用户端最小切割线(新增 D12)
|
||||
|
||||
> 结论:没有用户端,Demo 会变成 HR 后台管理系统,无法证明一线员工/候选人真的能用。用户端要补,但只补 Web/H5 轻入口,不新建独立 APP。
|
||||
|
||||
| 端/角色 | 2026-07-05 Demo 必做 | 一期内补 | 明确推迟 |
|
||||
|---|---|---|---|
|
||||
| 管理端(HR/管理员/教练) | 配置内容、查看记录、查看评分/处理状态 | Rubric 配置、任务分派、审核流 | 多组织复杂工作流 |
|
||||
| 候选人端 | 打开面试入口 → 听/看题 → 作答 → 提交 → 生成面试记录 | 面试邀请、历史记录、人工复核状态 | 外部招聘系统深度集成 |
|
||||
| 员工/学员端 | 打开今日任务 → 三角色对练 / SOP 问答 / 案例上传 至少跑通 1 条 | 学习路径、错题本、能力雷达、认证进度 | 独立 APP、企微/钉钉深度集成、消息推送 |
|
||||
|
||||
**实现边界**:
|
||||
- 复用现有 Vue 前端,用独立路由/菜单/演示入口区分用户端;不新建第二套前端工程。
|
||||
- Demo 可用本地账号或 mock token,但演示脚本必须从「用户端发起 → 管理端看结果」走一遍。
|
||||
- 用户端只做「能完成任务」,不做复杂个人中心、社交、积分商城。
|
||||
|
||||
### 🟡 一期内做(Demo 后)
|
||||
|
||||
数据地基:补全 HR 主干实体(#10)、关系/向量切分(#11)、招聘域(#12)、SOP 多层分类(#13)、Rubric 可配置(#14)、版本管理(#15)、ID 规约(#16)、数据范围字段(#17)、训练事务+学习路径(#18)。
|
||||
能力与运营:LLM/ASR/视频运营成本测算(#23)、内容贡献激励+署名(#25)、Agent 落点标注(#33)、认证/晋升/绩效规则引擎(#34)。
|
||||
|
||||
### ⚪ 明确推迟(现在不做)
|
||||
|
||||
内容营销中心、独立 APP、知识图谱、实时同步、企业微信/钉钉深度集成、脱敏审计、AI 分数挂钩绩效/晋升 —— 均见第 7 节闸门或第 8 节决策。
|
||||
|
||||
---
|
||||
|
||||
## 6. 集成依赖兜底表(6 个,各指定负责人)
|
||||
|
||||
| # | 外部依赖 | 风险 | 兜底方案 | 负责人 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 组织/人员数据同步(采购系统) | 接口疑似与待批预算系统绑定,未就绪 | 静态快照 | ___ |
|
||||
| 2 | 登录 SSO / 身份认证(采购系统) | 同上 | 本地账号 | ___ |
|
||||
| 3 | 权限映射(外部→本地角色) | 依赖①的数据结构 | 本地先建规则 | ___ |
|
||||
| 4 | 方言 ASR / TTS(第三方) | 厂商/延迟/川粤支持/计费未确认 | 选 1 家跑 1 条路径 | ___ |
|
||||
| 5 | 大模型 API | 选型 + 业主 PII 出境合规 | 公有云 API 先行 | ___ |
|
||||
| 6 | 数字人 / 视频生成 | 慢、贵 | 预渲染样片 | ___ |
|
||||
|
||||
---
|
||||
|
||||
## 7. 生产前闸门清单(现在不做,立字据,上线前必过)
|
||||
|
||||
| # | 闸门项 | 说明 |
|
||||
|---|---|---|
|
||||
| G1 | AI 打分定位 | 明确「辅助参考、人可否决」,不由 AI 直接决定绩效/晋升 |
|
||||
| G2 | AI 招聘合规 | 候选人算法筛选保留人工复核,防算法歧视/法律风险 |
|
||||
| G3 | 数据合规 | 业主 PII + 员工数据 脱敏 + 审计 + 数据权限(DR-10 承接) |
|
||||
| G4 | 员工接受度 | 试点期配激励 + 沟通,化解「被 AI 监考」抵触 |
|
||||
| G5 | 情绪树洞隐私 | 兑现「不留痕、不进训练集」,明确隐私边界 |
|
||||
| G6 | 运营成本红线 | LLM/ASR/视频 月度调用成本设预算上限与降级策略 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 决策项(D1–D12 已定)
|
||||
|
||||
| # | 决策项 | 决策结果 | 状态 |
|
||||
|---|---|---|---|
|
||||
| D1 | 系统/数据归属 | **归属项目**(以项目为 owner 与数据范围主体) | ✅ 已定 |
|
||||
| D2 | 登录方式 | **本地账号**(SSO 留二期) | ✅ 已定 |
|
||||
| D3 | 大模型选型 | **公有大模型 API**(出境合规入闸门 G3/G6) | ✅ 已定 |
|
||||
| D4 | 知识图谱一期是否上 | **一期先 RAG**,图谱降二期 | ✅ 已定 |
|
||||
| D5 | 内容营销中心去留 | **一期砍除** | ✅ 已定 |
|
||||
| D6 | 独立 APP | **用 Web**,APP 进二期 | ✅ 已定 |
|
||||
| D7 | 老文档 vs 新 HR 框架口径 | **综合统一成新的一版**(见下方跟进项 F1) | ✅ 已定 |
|
||||
| D8 | 企微/钉钉/工单集成深度 | **只列接口、不实现** | ✅ 已定 |
|
||||
| D9 | 一期验收标准 / 量化承诺 | **最小可验收承诺已定**(见第 10 节;C3 一致率 70%、试点 1–2 项目) | ✅ 已定 |
|
||||
| D10 | 资料中台是否提前建设 | **提前建设 MinIO + OSS-first 文档入库**;PDF/Word/Excel/PPT 先抽文本,图片智能分析进下一阶段 | ✅ 已定 |
|
||||
| D11 | 向量数据库与语义检索路线 | **一期选 Qdrant**;MySQL Fulltext 保留,制度/SOP 采用关键词 + 向量混合召回、rerank、引用约束;Milvus/Weaviate/pgvector 暂缓 | ✅ 已定 |
|
||||
| D12 | 用户端是否进入一期 | **必须进入**;Demo 用 Web/H5 轻入口,候选人/员工至少能发起 1 条英雄路径;独立 APP 和企微/钉钉深度集成推迟 | ✅ 已定 |
|
||||
|
||||
**由决策派生的跟进项**:
|
||||
- **F1(源自 D7)**:综合原《建设方案》+ 一期实施方案 + 本清单,产出**统一新版对外方案**(口径:选用育留 AI 人力资源系统)。
|
||||
- **F2(源自 D1)**:「归属项目」意味着数据权限以**项目为范围主体**——第 4 节同步边界、第二层 #17 数据范围字段,均按「项目级行权限」落地。
|
||||
- **F3(源自 D3)**:公有大模型已定 → 业主 PII 出境是硬约束,闸门 **G3/G6** 升为一期必须评估项,不能纯推迟。
|
||||
- **F4(源自 D12)**:演示脚本必须区分「用户端完成任务」和「管理端查看/审核」,否则系统价值会被误解成后台台账。
|
||||
|
||||
---
|
||||
|
||||
## 9. 周末施工排期(2026-07-03 / 2026-07-04 / 2026-07-05 · 2 人时间盒)
|
||||
|
||||
> 把第 5 节 🔴 2026-07-05 Demo 10 项拆成两人施工单。**铁律:2026-07-05 不加新功能,只联调 + 精修 + 彩排。**
|
||||
|
||||
**分工**:
|
||||
- **A = 技术**(若依骨架 / 后端 / 大模型 & 语音集成 / 评分逻辑)
|
||||
- **B = 业务+前端**(SOP 内容 / Rubric / 案例样片 / UI 出图审校 / 快照造数 / 演示脚本)
|
||||
|
||||
### 2026-07-03 周五 · 基础日(把地基和素材备齐)
|
||||
|
||||
| 负责人 | 任务 | 对应项 |
|
||||
|---|---|---|
|
||||
| A | 若依骨架跑起来 + 本地账号登录 | #9骨架 #5 |
|
||||
| A | 公有大模型 API 接通(一个能调通的对话接口) | #6 |
|
||||
| A | 方言 ASR/TTS 选 1 家、接通、能出字 | #7 |
|
||||
| B | 住宅类 SOP + 样例案例 + 评分 Rubric **定稿** | #2 |
|
||||
| B | 组织/人员静态快照造数(或 mock 适配层) | #3 |
|
||||
| B | 列全功能点清单 + 汇总 UI 出图需求;补齐候选人/员工用户端入口口径 | #9 #10准备 |
|
||||
| **2026-07-03 收工验收** | 能登录 · 能调通大模型 · ASR 能出字 · 内容素材齐 · 功能点清单和用户端入口定稿 | |
|
||||
|
||||
### 2026-07-04 周六 · 主攻日(英雄路径 + 壳)
|
||||
|
||||
| 负责人 | 任务 | 对应项 |
|
||||
|---|---|---|
|
||||
| A | 英雄路径①后端:语音面试→AI 出题→答→打分(评分接 Rubric) | #1 |
|
||||
| A | 英雄路径②后端:案例语音上传→转写→AI 整理成稿 | #1 |
|
||||
| B | AI 出图 → 管理端 + 用户端前端壳批量搭(全功能点可点开) | #9 #10 |
|
||||
| B | 案例→视频 样片预渲染 1 段 | #4 |
|
||||
| B | 演示脚本初稿(点开顺序 + 每屏一句价值) | #8 |
|
||||
| **2026-07-04 收工验收** | 2 条英雄路径后端可跑通(接口级) · 管理端/用户端壳全部可点开 · 样片就绪 · 脚本初稿 | |
|
||||
|
||||
### 2026-07-05 周日 · 联调彩排日(不加新功能)
|
||||
|
||||
| 负责人 | 任务 | 对应项 |
|
||||
|---|---|---|
|
||||
| A+B | 英雄路径前后端联调 + 精修 | #1 #9 |
|
||||
| A+B | 用户端发起 → 管理端看结果 联调 | #10 |
|
||||
| A+B | 兜底预案:每条英雄路径录一段屏,防现场翻车 | 全 |
|
||||
| B | 演示脚本定稿 + 彩排 2 遍 + 卡点预案 | #8 |
|
||||
| **2026-07-05 收工验收** | 端到端走一遍无致命卡点 · 有录屏兜底 · 彩排通过 | |
|
||||
|
||||
### 关键路径与止损
|
||||
|
||||
- **关键路径**:内容(#2)→ 英雄路径(#1)→ 联调。**内容不齐,一切空转**——B 在 2026-07-03 必须锁死 #2。
|
||||
- **外部依赖兜底(呼应第 6 节)**:ASR / 大模型 / 视频 任一没接通,**立即切兜底**(mock / 录屏 / 样片),绝不卡主线。
|
||||
- **如果落后**:保 **1 条**英雄路径 + 壳 + 脚本,**砍掉第 2 条**英雄路径。宁可少演一条、也要演通一条。
|
||||
|
||||
---
|
||||
|
||||
## 10. 一期最小可验收承诺(D9)
|
||||
|
||||
> 原则:验收只写**可判定**的东西——「是/否」或「可测量」。原方案的大 ROI 数字归入**愿景层,不作验收依据**。
|
||||
|
||||
### L0 · Demo 验收(2026-07-06 周一 · 过大老板)—— 全部「是/否」
|
||||
|
||||
| # | 验收项 | 通过标准 |
|
||||
|---|---|---|
|
||||
| L0-1 | 功能完整性 | 全部规划功能点在 Web 端**可点开、有界面**(壳可接受) |
|
||||
| L0-2 | 英雄路径 | **至少 1 条**端到端真跑通(语音面试→AI 出题→作答→AI 出分+建议) |
|
||||
| L0-3 | 知识库 | 住宅类 SOP 可检索,AI 问答能**引用 SOP 内容** |
|
||||
| L0-4 | 案例流程 | 案例语音上传→AI 转写整理 可演示(视频用样片顶) |
|
||||
| L0-5 | 演示鲁棒性 | 脚本走完**无致命卡点**,每条路径**有录屏兜底** |
|
||||
| L0-6 | 用户端闭环 | 候选人/员工 Web 入口可打开,至少 1 条路径从用户端发起并在管理端看到结果/状态 |
|
||||
|
||||
### L1 · 一期验收(阶段交付 · 项目可收尾)
|
||||
|
||||
**A. 功能闭环(是/否)**
|
||||
|
||||
| # | 验收项 | 通过标准 |
|
||||
|---|---|---|
|
||||
| A0 用户端 | 候选人/员工/学员可登录或通过演示入口完成任务、训练、SOP 问答/案例提交;管理端可查看结果 |
|
||||
| A1 选 | AI 面试出题 + 作答 + AI 打分,形成面试记录,闭环可用 |
|
||||
| A2 用 | 住宅类岗位-SOP 匹配 + 岗前/入职培训任务 可分派、可完成 |
|
||||
| A3 育 | 三角色对练**至少 1 类场景**(投诉或催费)端到端;每日一练可推送可评分 |
|
||||
| A4 留 | 能力雷达图基于训练数据生成;认证等级规则可配置 |
|
||||
| A5 案例 | 语音上传→AI 整理→筛选 流程跑通(视频可半自动/样片) |
|
||||
|
||||
**B. 数据与内容(是/否 + 量)**
|
||||
|
||||
| # | 验收项 | 标准 |
|
||||
|---|---|---|
|
||||
| B1 | 住宅类 SOP 入库、可检索、可引用 | ≥ 5 个核心流程(投诉/催费/报修/交付/巡检) |
|
||||
| B2 | 案例库(脱敏) | ≥ 20 条 |
|
||||
| B3 | 评分 Rubric 可配置(维度/权重/指标后台可改) | 是 |
|
||||
| B4 | 组织/人员导入 + **项目级数据范围**权限生效 | 是 |
|
||||
|
||||
**C. 技术与质量(可测量)**
|
||||
|
||||
| # | 验收项 | 标准 |
|
||||
|---|---|---|
|
||||
| C1 | 集中式前后端分离部署,单项目试点稳定运行 | 是 |
|
||||
| C2 | 语音对练单轮响应(ASR+LLM+评分) | ≤ 5 秒 |
|
||||
| C3 | AI 打分与人工打分**分档一致率** | **≥ 70%** |
|
||||
| C4 | RAG 对住宅类 SOP 问题**可用回答率**(人工评审) | ≥ 80% |
|
||||
| — | 明确**不承诺**:高并发、多项目类型 | — |
|
||||
|
||||
**D. 试点效果(pilot 级过程指标,非业务 ROI)**
|
||||
|
||||
| # | 验收项 | 标准 |
|
||||
|---|---|---|
|
||||
| D1 | 试点范围 | **1–2 个住宅项目**,≥ 20 名员工 |
|
||||
| D2 | 人均完成对练/考核 | ≥ 10 次 |
|
||||
| D3 | 完训率 | ≥ 80% |
|
||||
| D4 | 试点满意度 | ≥ 4 / 5 |
|
||||
|
||||
### 明确不纳入一期验收(移交二期 / 生产闸门)
|
||||
|
||||
- **合规上线**(脱敏/审计/业主 PII 出境评估)= 生产前闸门 **G3/G6**
|
||||
- **AI 分数挂钩绩效/晋升/招聘决策** = 推迟(**G1/G2**),一期只做「辅助参考」
|
||||
- 知识图谱、独立 APP、内容营销中心、多项目类型(公建/景区)、企微/钉钉深度集成、实时同步
|
||||
|
||||
### 愿景层(方向性目标,**不作为一期验收依据**)
|
||||
|
||||
> 培训周期↓、成本↓、投诉处理时效↑、增值转化↑、关键岗位流失↓ —— 均为方向性愿景,需更长周期与真实业务数据验证,一期不承诺、不验收。
|
||||
|
||||
---
|
||||
|
||||
## 11. 提前加码:资料中台施工线(v1.5)
|
||||
|
||||
> 背景:Demo 进度快于原计划,且已知业务资料约 3GB,包含 PPT、图片、Excel、Word、PDF。知识库不再只服务 SOP seed,而是要成为后续 RAG、文档解析、案例沉淀和 Chat 的公共入口。
|
||||
|
||||
### 11.1 当前立刻做(L0+)
|
||||
|
||||
| # | 事项 | 交付标准 |
|
||||
|---|---|---|
|
||||
| M1 | MinIO 本地对象存储 | `./scripts/dev.sh` 和 `--reset` 自动启动 MinIO,默认 bucket `ruoyi` 可用 |
|
||||
| M2 | OSS-first 文档上传 | 知识库上传先落 `sys_oss`,再绑定 `aihr_knowledge_attach.oss_id`,同名文档替换旧片段 |
|
||||
| M3 | 文档解析扩展 | 在现有 Tika 解析基础上支持 txt/md/PDF/Word/Excel/PPT 文本抽取 |
|
||||
| M4 | Demo 页面反馈 | 上传后在 SOP 知识库展示 OSS ID、片段数、状态,可立即检索命中 |
|
||||
|
||||
### 11.2 下一阶段(P1)
|
||||
|
||||
| # | 事项 | 处理 |
|
||||
|---|---|---|
|
||||
| M5 | 解析任务状态页 | 已接 `/knowledge/processing` 和 `GET /api/knowledge/processing/overview`;展示等待解析/解析中/已完成/失败、片段数、向量化状态、处理链路和最近事件 |
|
||||
| M6 | 3GB 资料批量导入 | 页面已支持多文件/浏览器目录选择批量导入 Demo 文件;已接 `POST /api/knowledge/doc/import-local-task` 从服务端导入根目录启动后台任务,并用 `GET /api/knowledge/doc/import-tasks` 轮询进度;当前重试粒度是同目录重跑,单失败文件重试/取消暂停仍待做 |
|
||||
| M7 | 图片智能分析 | 图片先落 OSS,再用视觉模型/OCR 生成结构化描述入库;不伪装成普通文本解析 |
|
||||
| M8 | Qdrant 向量召回 | 已接 `qdrant` 本地服务;以 `aihr_knowledge_fragment` 为事实源 upsert 向量,与 MySQL Fulltext 双路召回后做 RRF 融合 |
|
||||
| M9 | 制度/SOP 精确回答 | 检索必须带租户/项目/分类/版本/生效日期过滤,回答必须引用片段;低置信不编造 |
|
||||
|
||||
### 11.3 明确不做
|
||||
|
||||
- 不整包迁移 `ruoyi-chat`;只迁 `ruoyi-aihr` 当前需要的 loader、任务和检索能力。
|
||||
- 不把 3GB 资料通过浏览器单次上传解决;浏览器上传只服务 Demo 和少量验证文件。
|
||||
- 不把图片智能分析做成假 OCR;没有视觉模型/OCR 结果就先标为待处理。
|
||||
|
||||
---
|
||||
|
||||
## 12. 向量库与语义检索路线(v1.5)
|
||||
|
||||
> 结论:一期选 Qdrant。它只做向量索引,不替代 MySQL/MinIO;准确回答靠混合检索、重排序和引用约束,不是靠单一向量相似度。
|
||||
|
||||
### 12.1 选型结论
|
||||
|
||||
| 候选 | 结论 | 用法 |
|
||||
|---|---|---|
|
||||
| Qdrant | ✅ 一期采用 | 本地 Docker + dense vector + payload filter;后续可扩 sparse/hybrid |
|
||||
| Milvus | 暂缓 | 大规模、高并发、集群化后再评估;当前运维成本偏重 |
|
||||
| Weaviate | 暂缓 | 功能完整但平台边界更重;当前不需要整套知识库平台 |
|
||||
| pgvector | 暂缓 | 本项目主库是 MySQL,不为向量单独引入 PostgreSQL |
|
||||
|
||||
### 12.2 存储边界
|
||||
|
||||
| 层 | 存什么 | 不存什么 |
|
||||
|---|---|---|
|
||||
| MySQL | 知识库、附件、片段、权限、分类、版本、生效日期、解析状态 | 大文件二进制 |
|
||||
| MinIO | PDF/Word/Excel/PPT/图片/音频等原始文件 | 业务权限判断 |
|
||||
| Qdrant | 向量、`fragmentId`、最小过滤 payload | 全文正文、权限主数据 |
|
||||
|
||||
**Qdrant payload 最小字段**:`tenantId`、`projectId`、`knowledgeId`、`docId`、`fragmentId`、`category`、`docType`、`version`、`effectiveDate`、`sourcePage/sourceSlide/sourceSheet`、`chunkHash`。
|
||||
|
||||
### 12.3 检索与回答流程
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Q["用户问题"] --> S["意图与范围识别"]
|
||||
S --> K["MySQL Fulltext TopK"]
|
||||
S --> V["Qdrant Vector TopK"]
|
||||
K --> F["RRF 融合"]
|
||||
V --> F
|
||||
F --> R["rerank 重排序"]
|
||||
R --> A["带引用回答"]
|
||||
R --> L["低置信拒答/提示补资料"]
|
||||
```
|
||||
|
||||
**制度/SOP 问答硬规则**:
|
||||
- 先过滤租户、项目、知识库分类、版本、生效日期,再召回。
|
||||
- 关键词召回用于条款编号、岗位名、制度名、流程节点等精确命中;向量召回用于同义表达和场景化问题。
|
||||
- 输出必须带来源引用,至少包含文档名 + 页码/幻灯片/Sheet/片段编号。
|
||||
- 召回片段冲突时,优先新版本和生效日期更近的制度;仍冲突则提示人工确认。
|
||||
- 低置信或无来源时不编造答案,返回“未找到可引用依据”。
|
||||
|
||||
### 12.4 切片规则
|
||||
|
||||
| 资料类型 | 切片原则 | 重点元数据 |
|
||||
|---|---|---|
|
||||
| 制度/规章 | 按章/条/款/项切,保留编号和上下级标题 | 制度名、版本、生效日期、条款号 |
|
||||
| SOP | 按步骤、责任人、时限、输入输出切 | 岗位、项目类型、流程节点 |
|
||||
| Excel | 按 Sheet + 表格区域 + 行摘要切 | Sheet、表头、行号、业务字段 |
|
||||
| PPT | 按页切,标题 + 正文 + 备注合并 | 页码、标题、备注 |
|
||||
| Word/PDF | 优先按标题层级切,否则按段落窗口切 | 页码、标题路径 |
|
||||
| 图片 | 先 OCR/视觉描述,再按图片说明切 | 图片来源、OCR 置信度、视觉模型版本 |
|
||||
| 案例/对练 | 按场景、轮次、评分点切 | 场景、角色、评分维度 |
|
||||
|
||||
### 12.5 一期验收口径
|
||||
|
||||
| 项 | 标准 |
|
||||
|---|---|
|
||||
| 入库 | PDF/Word/Excel/PPT 可入 MinIO,解析后生成片段 |
|
||||
| 检索 | MySQL Fulltext + Qdrant 双路召回可跑通 |
|
||||
| 回答 | SOP/制度类回答必须展示引用来源 |
|
||||
| 准确率 | 住宅类 SOP 问答人工评审可用率 ≥ 80%(承接第 10 节 C4) |
|
||||
| 可追溯 | 每个答案能追到 `fragmentId` 和原始附件 |
|
||||
|
||||
---
|
||||
|
||||
## 附录 A:35 条完整查漏登记(可追溯)
|
||||
|
||||
**第一层(Demo 阻塞)**:1 陪练英雄路径 · 2 内容冷启动 · 3 组织API未就绪 · 4 案例视频过重 · 5 登录/认证未定 · 6 大模型+出境合规 · 7 方言厂商未定 · 8 演示脚本 · 9 UI壳工作量 · 35 用户端入口缺口
|
||||
|
||||
**第二层(数据模型地基)**:10 HR主干抽全 · 11 关系/向量切分 · 12 招聘域空白 · 13 SOP多层分类 · 14 Rubric数据结构 · 15 版本管理 · 16 ID/主键策略 · 17 数据权限字段 · 18 训练事务+学习路径 · 19 知识图谱去留
|
||||
|
||||
**第三层(生产前闸门+组织风险)**:20 AI分挂钩绩效 · 21 AI招聘合规 · 22 业主/员工数据合规 · 23 运营成本模型 · 24 员工接受度/变革管理 · 25 内容贡献激励+署名 · 26 情绪树洞隐私 · 27 系统/数据归属
|
||||
|
||||
**第四层(范围边界+交付一致性)**:28 营销中心去留 · 29 独立APP · 30 老文档一致性债务 · 31 企微/钉钉/工单集成清单 · 32 一期验收标准 · 33 玉溪Agent落点 · 34 认证/晋升/绩效规则引擎
|
||||
|
||||
---
|
||||
|
||||
## 附录 B:一句话结论
|
||||
|
||||
> 现在真正的头号风险不是选型(若依已够),也不是要不要 aifei(不用),而是「用户端缺口」「Demo 范围」和「3GB 业务资料接入」三条线互相拖累。守住第 5 节的三分切割线,按第 5.1 节让用户端只做轻入口,同时按第 11 节把 MinIO、文档解析和批量导入拆开推进,按第 12 节把 Qdrant 作为向量索引而非事实源,才能既演得通、又不把资料中台做成临时脚本。
|
||||
@@ -0,0 +1,104 @@
|
||||
# 后端 API 对接指南
|
||||
|
||||
前端四条演示流和演示预检已经稳定。后端 API 按页面逐刀接入，避免一次性铺满四个页面。
|
||||
|
||||
## 第一阶段范围
|
||||
|
||||
| 页面 | 后端接口 | 处理 |
|
||||
|---|---|---|
|
||||
| AI面试 `/recruit/interview` | `POST /api/recruit/interview/start`、`/answer`、`/finish` | 已接入 seed API |
|
||||
| 三角色对练 `/train/practice` | `POST /api/train/practice/start`、`/turn`、`/finish` | 已接入 seed API |
|
||||
| 案例沉淀 `/knowledge/cases` | `POST /api/knowledge/case/upload`、`/organize`、`/curate` | 已接入 seed API |
|
||||
| SOP知识库 `/knowledge/sop` | `POST /api/knowledge/search`、`POST /api/knowledge/doc/upload` | 已接入 MySQL Fulltext + Qdrant 混合召回、OSS-first 文档上传、txt/md/PDF/Word/Excel/PPT 解析和 embedding 写入，失败回退 seed |
|
||||
| 资料处理 `/knowledge/processing` | `GET /api/knowledge/processing/overview`、`POST /api/knowledge/doc/import-local-task`、`GET /api/knowledge/doc/import-tasks`、复用 `POST /api/knowledge/doc/upload` | 已接入解析任务状态聚合；页面支持多文件/目录选择、服务端后台目录导入和进度轮询，失败回退 seed |
|
||||
|
||||
## 后端落点
|
||||
|
||||
- 业务模块：`backend/ruoyi-modules/ruoyi-aihr`
|
||||
- 注册模块：`backend/ruoyi-modules/pom.xml`
|
||||
- 接入启动包：`backend/ruoyi-admin/pom.xml`
|
||||
- 包名建议：`org.dromara.aihr`
|
||||
- Controller 返回统一用 `org.dromara.common.core.domain.R`
|
||||
|
||||
当前四条页面流仍保留 seed fallback。知识库、模型能力、文档解析、RAG、chat 按 [ruoyi-ai 能力分片迁移计划](RUOYI_AI_INCREMENTAL_MIGRATION.md) 逐片引入；知识库 DDL 与住宅类 SOP seed 在 `backend/script/sql/aihr_knowledge_mysql8.sql`，模型 DDL 在 `backend/script/sql/aihr_model_mysql8.sql`。
|
||||
|
||||
直接打后端 `/api/**` 需要登录后的 `Authorization: Bearer <access_token>`；浏览器内通过已登录前端和 `/dev-api` 代理访问。
|
||||
|
||||
SOP 文档上传第三片已经落最小后端边界：
|
||||
|
||||
| 能力 | 后端接口 | 处理 |
|
||||
|---|---|---|
|
||||
| 文档上传解析 | `POST /api/knowledge/doc/upload` | `multipart/form-data`，字段 `file` 和 `category`；支持 `.txt/.md/.markdown/.pdf/.doc/.docx/.xls/.xlsx/.ppt/.pptx`、100MB 内；先写 `sys_oss`，再绑定 `aihr_knowledge_attach.oss_id` 并切分写入 `aihr_knowledge_fragment` |
|
||||
| 智能归类与标签 | 同一上传/导入链路 | `category=__auto__` 时，解析正文后优先调用已启用的 `aihr_model_config.category='chat'` 模型生成分类、摘要、标签和归类理由，温度固定为 `0`；无模型或调用失败时按文件名/正文关键词兜底。最终分类写入 `aihr_knowledge_info/attach`，摘要和标签写入 `sys_oss.ext1` |
|
||||
| 重复资料处理 | 同一上传/导入链路 | 上传时计算原始文件 `aihrFileSha256`、解析文本 `aihrTextSha256` 和 `md5` 写入 `sys_oss.ext1`；重复判断优先按文件 SHA-256，其次按文本 SHA-256，最后用同名同大小兼容旧数据。命中重复时复用原附件并迁移到最新分类，删除其他重复附件和旧 fragment |
|
||||
| 归类稳定性 | 同一上传/导入链路 | 命中重复资料时优先复用已有 `sys_oss.ext1` 里的分类、摘要和标签；只有旧资料没有存过模型结果时才重新分析，避免同文件因重复上传或更换模型导致标签漂移 |
|
||||
| 文档替换 | 同一 `category + fileName` 再上传 | 复用原 `doc_id`，删除旧 fragment 后重写新 fragment，避免重复文档堆积 |
|
||||
| 片段向量化 | 同一上传接口内机会性执行 | 若 `aihr_model_config.category='vector'` 且启用，会调用配置供应商的 OpenAI-compatible `/embeddings`，把返回向量写入 `aihr_knowledge_fragment.embedding_json` |
|
||||
| Qdrant 向量索引 | 同一上传接口内机会性执行 | embedding 写入 MySQL 后尽力 upsert 到 Qdrant；同名文档替换会尽力删除旧 points；Qdrant 不可用不影响上传和 MySQL 检索 |
|
||||
| 混合检索 | `POST /api/knowledge/search` | 先跑 MySQL Fulltext，同时在 vector 模型和 Qdrant 可用时生成 query embedding 走 Qdrant，再按 RRF 融合并回 MySQL hydrate 片段 |
|
||||
| 解析状态聚合 | `GET /api/knowledge/processing/overview` | 聚合 `aihr_knowledge_attach.status`、fragment 数、embedding 数、`sys_oss.ext1.fileSize`，生成资料处理页指标、分类、任务、链路和最近事件 |
|
||||
| 服务端目录导入 | `POST /api/knowledge/doc/import-local` | JSON `{ directory, category, limit }`；`directory` 只能是 `AIHR_IMPORT_ROOT` / `aihr.import.root` 下的相对目录，默认根目录为 `./.data/import`；逐文件复用上传解析链路，同步执行，保留给小批量/调试 |
|
||||
| 服务端导入任务 | `POST /api/knowledge/doc/import-local-task`、`GET /api/knowledge/doc/import-tasks` | 启动后台目录导入并返回任务；任务写入 `aihr_knowledge_import_task`，页面轮询查看总数、成功数、失败数、当前文件和进度；重试当前按同目录重新启动一轮 |
|
||||
|
||||
模型能力第二片已经落最小后端边界：
|
||||
|
||||
| 能力 | 后端接口 | 处理 |
|
||||
|---|---|---|
|
||||
| 模型供应商 | `GET /api/aihr/model/providers`、`POST /api/aihr/model/providers`、`PUT /api/aihr/model/providers/{providerCode}`、`PATCH /api/aihr/model/providers/{providerCode}/status` | 优先返回 `aihr_model_provider`，支持新增、编辑、启停；缺表或空表时返回 seed 清单 |
|
||||
| 模型配置 | `GET /api/aihr/model/configs`、`POST /api/aihr/model/configs`、`PUT /api/aihr/model/configs/{id}`、`PATCH /api/aihr/model/configs/{id}/enabled` | 优先返回 `aihr_model_config`，支持新增、编辑、启停，并计算是否已具备 URL/Key |
|
||||
| 模型探针 | `POST /api/aihr/model/chat` | 数据库配置后走 OpenAI-compatible `/chat/completions`，否则 seed fallback |
|
||||
|
||||
本阶段不修改 `.env`，也不自动执行模型 SQL。API Key 通过模型配置页面写入数据库：`api_key` 可放在 `aihr_model_provider` 作为供应商默认值，也可放在 `aihr_model_config` 覆盖单个模型；接口响应只返回 `configured/apiKeyConfigured`，不返回密钥明文。
|
||||
|
||||
Qdrant 本地默认值可不配；需要覆盖时用 JVM property 或环境变量：
|
||||
|
||||
| 配置 | 默认值 | 用途 |
|
||||
|---|---|---|
|
||||
| `AIHR_QDRANT_URL` / `-Daihr.qdrant.url` | `http://127.0.0.1:6333` | Qdrant REST 地址 |
|
||||
| `AIHR_QDRANT_COLLECTION` / `-Daihr.qdrant.collection` | `aihr_knowledge` | 知识库向量 collection |
|
||||
| `AIHR_QDRANT_API_KEY` / `-Daihr.qdrant.apiKey` | 空 | 远端 Qdrant API Key，本地不用 |
|
||||
| `AIHR_IMPORT_ROOT` / `-Daihr.import.root` | `./.data/import` | 服务端资料目录导入根目录 |
|
||||
|
||||
## 前端落点
|
||||
|
||||
- AI 面试 API 文件：`frontend/src/api/aihr/interview.ts`
|
||||
- AI 面试页面：`frontend/src/views/recruit/interview.vue`
|
||||
- 三角色对练 API 文件：`frontend/src/api/aihr/practice.ts`
|
||||
- 三角色对练页面：`frontend/src/views/train/practice.vue`
|
||||
- 案例沉淀 API 文件：`frontend/src/api/aihr/case.ts`
|
||||
- 案例沉淀页面：`frontend/src/views/knowledge/cases.vue`
|
||||
- SOP 知识库 API 文件：`frontend/src/api/aihr/sop.ts`
|
||||
- SOP 知识库页面：`frontend/src/views/knowledge/sop.vue`
|
||||
- 资料处理 API 文件：`frontend/src/api/aihr/processing.ts`
|
||||
- 资料处理页面：`frontend/src/views/knowledge/processing.vue`
|
||||
- 模型配置 API 文件：`frontend/src/api/aihr/model.ts`
|
||||
- 模型配置页面：`frontend/src/views/system/model/index.vue`
|
||||
- 保留本地 seed fallback：接口失败时仍能演示，不让现场 Demo 被后端状态拖死。
|
||||
|
||||
## 验收
|
||||
|
||||
```bash
|
||||
./scripts/demo-check.sh
|
||||
npm --prefix frontend run lint:eslint -- src/api/aihr/interview.ts src/views/recruit/interview.vue src/api/aihr/practice.ts src/views/train/practice.vue src/api/aihr/case.ts src/views/knowledge/cases.vue src/api/aihr/sop.ts src/views/knowledge/sop.vue
|
||||
mvn -f backend/pom.xml -pl ruoyi-admin -am -DskipTests package
|
||||
```
|
||||
|
||||
模型能力可单独 smoke：
|
||||
|
||||
```bash
|
||||
TOKEN=<登录后 access_token>
|
||||
curl -fsS http://127.0.0.1:8080/api/aihr/model/providers -H "Authorization: Bearer $TOKEN"
|
||||
curl -fsS http://127.0.0.1:8080/api/aihr/model/configs -H "Authorization: Bearer $TOKEN"
|
||||
curl -fsS -X POST http://127.0.0.1:8080/api/aihr/model/chat \
|
||||
-H "Authorization: Bearer $TOKEN" \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"prompt":"物业管家处理漏水投诉第一步是什么？"}'
|
||||
```
|
||||
|
||||
Qdrant 可单独 smoke：
|
||||
|
||||
```bash
|
||||
curl -fsS http://127.0.0.1:6333/
|
||||
```
|
||||
|
||||
浏览器验收仍按 [DEMO_ACCEPTANCE.md](DEMO_ACCEPTANCE.md) 的四条关键路径执行。
|
||||
@@ -0,0 +1,18 @@
|
||||
# Backlog
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
### Model Classification Version Governance
|
||||
|
||||
Current behavior:
|
||||
|
||||
- Same document fingerprint reuses existing category, summary, and tags.
|
||||
- Model classification uses `temperature=0` to reduce drift.
|
||||
|
||||
Add later when model upgrades need governance:
|
||||
|
||||
- Record provider, model name, prompt version, and analysis time.
|
||||
- Preview batch reclassification after model changes.
|
||||
- Show before/after category and tag diffs.
|
||||
- Require admin confirmation before overwriting historical metadata.
|
||||
- Keep an audit trail of prior classification versions.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Codebase Origins
|
||||
|
||||
This project is now maintained as a local monorepo. `backend/` and `frontend/`
|
||||
were detached from their original upstream repositories on 2026-07-03.
|
||||
|
||||
## Backend
|
||||
|
||||
- Original remote: `https://github.com/dromara/RuoYi-Vue-Plus.git`
|
||||
- Original branch: `5.X`
|
||||
- Original HEAD before detach: `e49f02f89e17ee5a4cc14048af99cc83d72872a7`
|
||||
|
||||
## Frontend
|
||||
|
||||
- Original remote: `https://github.com/CrazyLionCat/plus-ui.git`
|
||||
- Original branch: `5.X`
|
||||
- Original HEAD before detach: `d0d451967676707021b9857df529c395b27e90a7`
|
||||
@@ -0,0 +1,36 @@
|
||||
# 一期 Demo 演示与验收清单
|
||||
|
||||
本文件是现场演示入口：先跑预检，再按四条演示流逐条点击。当前只证明一期 Demo 路径可讲、可点、可截图；SOP 检索已可查本地 MySQL seed 片段，并支持 txt/md/PDF/Word/Excel/PPT 上传解析为本地 fragment，配置 vector 模型后会写入 embedding 并尽力同步 Qdrant，其余记录仍按演示态验收。
|
||||
|
||||
## 演示前预检
|
||||
|
||||
```bash
|
||||
./scripts/demo-check.sh
|
||||
```
|
||||
|
||||
预检通过只代表本地前端、基础接口、路由和 seed 标记在位。真实演示仍以浏览器点击为准。
|
||||
|
||||
## 现场演示脚本
|
||||
|
||||
| 顺序 | 页面 | 点击路径 | 必须看到 |
|
||||
|---|---|---|---|
|
||||
| 1 | 首页 `/index` | 打开首页 | 只展示“首页 / AI面试 / 三角色对练 / 案例沉淀 / SOP知识库 / 资料处理 / 系统设置-模型配置” |
|
||||
| 2 | AI面试 `/recruit/interview` | 生成题目 → 填满 seed 回答 → 完成评分 | 已完成闭环、建议复试、新增面试记录 |
|
||||
| 3 | 三角色对练 `/train/practice` | 开始对练 → 填入 seed 回复 → 继续一轮 → 填入 seed 回复 → 结束并评分 | 已完成闭环、导师改写、新增对练记录 |
|
||||
| 4 | 案例沉淀 `/knowledge/cases` | 选择样例录音 → AI 整理 → 送审 → 入库 → 查看样片 | 已完成闭环、`seed入库`、样片兜底文案 |
|
||||
| 5 | SOP知识库 `/knowledge/sop` | 上传 txt/md/PDF/Word/Excel/PPT 文档或使用 seed 文档 → 检索 → 生成训练题 | 已完成闭环、引用 SOP 原文片段、训练题已生成 |
|
||||
| 6 | 资料处理 `/knowledge/processing` | 打开页面 → 查看解析任务 → 查看处理链路 → 可选点“服务端导入”导入 `.data/import` 下少量样例 | 可看到资料总量、等待/解析中/完成/失败、片段数、向量化状态和最近事件 |
|
||||
|
||||
## 录屏兜底
|
||||
|
||||
录屏只保留一条完整路径，不录框架后台配置。
|
||||
|
||||
1. 从首页开始，左侧菜单依次进入四个页面。
|
||||
2. 每页只点上表的路径，停留 2 秒展示“必须看到”的验收文本。
|
||||
3. 若现场网络或浏览器状态异常，用本阶段通过验收的四张截图兜底：`/tmp/wygj-ai-interview-flow.png`、`/tmp/wygj-practice-flow.png`、`/tmp/wygj-cases-flow.png`、`/tmp/wygj-sop-flow.png`。
|
||||
|
||||
## 不演示
|
||||
|
||||
- 不演示 SSO、权限配置、知识图谱、数字人视频生成、绩效挂钩。
|
||||
- 不承诺面试、对练、案例的 seed 记录已写入后端数据库；SOP 检索与文档上传使用 `aihr_knowledge_*` 本地表，失败时回退 seed。
|
||||
- 不现场接大模型，AI 效果以本地 seed 数据兜底。
|
||||
@@ -0,0 +1,97 @@
|
||||
# 物业AI人力资源系统 Demo 本地启动
|
||||
|
||||
## 当前仓库
|
||||
|
||||
- 后端：`backend`，来自 `dromara/RuoYi-Vue-Plus` 的 `5.X` 分支
|
||||
- 前端：`frontend`，来自 `CrazyLionCat/plus-ui` 的 `5.X` 分支
|
||||
|
||||
## 本地端口
|
||||
|
||||
- 前端：`http://127.0.0.1:5173/`
|
||||
- 后端：`http://127.0.0.1:8080/`
|
||||
- MySQL：`127.0.0.1:13306`，数据库 `ry-vue`，账号 `root/root`
|
||||
- Redis：`127.0.0.1:16379`，密码 `ruoyi123`
|
||||
- MinIO API：`http://127.0.0.1:9000`，Console：`http://127.0.0.1:9001`，账号 `ruoyi / ruoyi123`，默认 bucket `ruoyi`
|
||||
- Qdrant REST：`http://127.0.0.1:6333`，默认 collection `aihr_knowledge`
|
||||
- 服务端资料导入根目录：`./.data/import`
|
||||
|
||||
Qdrant 默认本地无需配置；远端或自定义 collection 可用 `AIHR_QDRANT_URL`、`AIHR_QDRANT_COLLECTION`、`AIHR_QDRANT_API_KEY` 覆盖。服务端资料导入根目录可用 `AIHR_IMPORT_ROOT` 或 `-Daihr.import.root` 覆盖。
|
||||
|
||||
## 启动步骤
|
||||
|
||||
在项目根目录执行：
|
||||
|
||||
```bash
|
||||
./scripts/dev.sh
|
||||
```
|
||||
|
||||
首次启动或需要重建本地 `ry-vue` Demo 数据库时执行：
|
||||
|
||||
```bash
|
||||
./scripts/dev.sh --reset
|
||||
```
|
||||
|
||||
`--reset` 会删除并重建本地 Demo 数据库，只用于本地开发环境。
|
||||
|
||||
## 默认登录
|
||||
|
||||
- 租户：`000000`
|
||||
- 管理员：`admin / admin123`
|
||||
- 测试账号：`test / 666666`、`test1 / 666666`
|
||||
|
||||
## 品牌资源
|
||||
|
||||
- 页面标题：`物业AI人力资源系统`
|
||||
- 侧栏 Logo：`frontend/src/assets/logo/logo.png`
|
||||
|
||||
## 已验证的基础链路
|
||||
|
||||
- MySQL、Redis 与 MinIO 容器健康检查通过
|
||||
- Qdrant 容器随本地开发编排启动，供 SOP 知识库向量召回使用
|
||||
- `ry_vue_5.X.sql`、`ry_job.sql`、`ry_workflow.sql` 已导入
|
||||
- `aihr_knowledge_mysql8.sql`、`aihr_model_mysql8.sql` 已导入；本地库含住宅 SOP seed 片段与模型配置表
|
||||
- SOP 知识库支持 `.txt/.md/.markdown/.pdf/.doc/.docx/.xls/.xlsx/.ppt/.pptx` 上传到 MinIO 后解析入库，接口为 `POST /api/knowledge/doc/upload`，单文件上限 100MB
|
||||
- 服务端目录导入接口为 `POST /api/knowledge/doc/import-local-task`，只读取导入根目录下的相对目录，后台逐文件复用同一上传解析链路；`POST /api/knowledge/doc/import-local` 保留为同步调试接口。
|
||||
- 启用 `aihr_model_config.category='vector'` 的模型配置后，上传会同步写入片段 embedding，并尽力 upsert 到 Qdrant；未配置或 Qdrant 不可用时只走 MySQL Fulltext/seed fallback，不影响检索。
|
||||
- 后端 `ruoyi-admin` 已完成 Maven 打包并启动在 `8080`
|
||||
- 前端依赖已安装，Vite 已启动在 `5173`
|
||||
- `/dev-api/auth/tenant/list` 与 `/dev-api/auth/code` 已通过前端代理返回 `200`
|
||||
- `000000 / admin / admin123` 已通过真实加密登录接口返回 `access_token`
|
||||
|
||||
Qdrant 单独检查：
|
||||
|
||||
```bash
|
||||
curl -fsS http://127.0.0.1:6333/
|
||||
```
|
||||
|
||||
## Demo 页面验证
|
||||
|
||||
登录后侧栏应只展示以下入口：
|
||||
|
||||
- 首页：`/index`
|
||||
- AI面试：`/recruit/interview`
|
||||
- 三角色对练：`/train/practice`
|
||||
- 案例沉淀：`/knowledge/cases`
|
||||
- SOP知识库：`/knowledge/sop`
|
||||
- 资料处理：`/knowledge/processing`
|
||||
- 系统设置-模型配置：`/system/model`
|
||||
|
||||
若依默认菜单如“系统管理 / 租户管理 / 系统监控 / 系统工具 / 测试菜单”在当前 Demo 阶段应保持隐藏。
|
||||
|
||||
## Demo 演示流验证
|
||||
|
||||
当前已跑通四个本地演示流：
|
||||
|
||||
- AI面试：进入 `/recruit/interview`，点击“生成题目” → “填满 seed 回答” → “完成评分”，应看到“已完成闭环”“建议复试”和新增面试记录。
|
||||
- 三角色对练：进入 `/train/practice`，点击“开始对练” → 两次“填入 seed 回复 / 继续一轮” → “结束并评分”，应看到“已完成闭环”“导师改写”和新增对练记录。
|
||||
- 案例沉淀：进入 `/knowledge/cases`，点击“选择样例录音” → “AI 整理” → “送审” → “入库”，应看到“已完成闭环”和新增 `seed入库` 记录。
|
||||
- SOP知识库：进入 `/knowledge/sop`，可上传 txt/md/PDF/Word/Excel/PPT 文档入库；点击“检索” → “生成训练题”，应看到“已完成闭环”、命中数据库 SOP 原文片段和训练题；数据库不可用时页面回退 seed。
|
||||
- 资料处理：进入 `/knowledge/processing`，应看到资料总量、解析任务表、处理链路、规则与风险；可用少量文件验证“批量导入/选择目录/服务端导入”。服务端导入读取 `./.data/import` 下的相对目录，启动后台任务并在页面显示进度；当前重试粒度是同目录重新导入，不是单失败文件重试。
|
||||
|
||||
演示前可先跑最小预检：
|
||||
|
||||
```bash
|
||||
./scripts/demo-check.sh
|
||||
```
|
||||
|
||||
完整演示脚本与录屏兜底见 [DEMO_ACCEPTANCE.md](DEMO_ACCEPTANCE.md)。
|
||||
@@ -0,0 +1,36 @@
|
||||
# 文档索引
|
||||
|
||||
根目录 [README.md](../README.md) 是项目总入口。本文件只维护 `docs/` 区的文档索引。
|
||||
|
||||
## 当前项目文档
|
||||
|
||||
| 文档 | 用途 |
|
||||
|---|---|
|
||||
| [DEV_SETUP.md](DEV_SETUP.md) | 本地端口、账号、启动步骤、基础链路验证 |
|
||||
| [DEMO_ACCEPTANCE.md](DEMO_ACCEPTANCE.md) | 一期 Demo 演示脚本、录屏兜底、四条 seed 流验收清单 |
|
||||
| [API_INTEGRATION.md](API_INTEGRATION.md) | 后端 API 对接顺序、业务模块落点、四条 seed API 切片与 SOP 上传解析接口 |
|
||||
| [RUOYI_AI_INCREMENTAL_MIGRATION.md](RUOYI_AI_INCREMENTAL_MIGRATION.md) | 从 `ageerle/ruoyi-ai` 分片迁移知识库、模型能力、文档解析、Qdrant/RAG 和 chat 的执行边界 |
|
||||
| [AI人力资源系统一期Demo作战清单.md](AI人力资源系统一期Demo作战清单.md) | Demo 作战图、MVP 切割线、排期、验收承诺 |
|
||||
| [物业AI人力资源系统业务需求文档BRD.md](物业AI人力资源系统业务需求文档BRD.md) | 业务需求、范围边界、角色、风险与验收 |
|
||||
| [物业AI人力资源系统开发规格TechSpec.md](物业AI人力资源系统开发规格TechSpec.md) | 工程结构、数据模型、页面路由、API 和核心实现规格 |
|
||||
| [prototypes/ai-hr-dashboard.png](prototypes/ai-hr-dashboard.png) | 后台首页高保真目标图 |
|
||||
| [prototypes/ai-hr-p0-pages-composite.png](prototypes/ai-hr-p0-pages-composite.png) | P0 四个页面组合高保真原型图 |
|
||||
|
||||
## 参考材料
|
||||
|
||||
| 路径 | 用途 |
|
||||
|---|---|
|
||||
| [legacy/物业AI陪练系统一期建设实施方案.md](legacy/物业AI陪练系统一期建设实施方案.md) | 旧陪练系统一期方案，作为 HR 系统范围收敛的参考 |
|
||||
| [legacy/物业AI陪练系统建设方案研判报告.md](legacy/物业AI陪练系统建设方案研判报告.md) | 旧陪练系统方案研判 |
|
||||
|
||||
## Word 原件
|
||||
|
||||
这些文件只作归档，不作为开发入口。
|
||||
|
||||
| 文档 | 对应 Markdown |
|
||||
|---|---|
|
||||
| [originals/AI人力资源系统一期Demo作战清单.docx](originals/AI人力资源系统一期Demo作战清单.docx) | [AI人力资源系统一期Demo作战清单.md](AI人力资源系统一期Demo作战清单.md) |
|
||||
| [originals/物业AI人力资源系统业务需求文档BRD.docx](originals/物业AI人力资源系统业务需求文档BRD.docx) | [物业AI人力资源系统业务需求文档BRD.md](物业AI人力资源系统业务需求文档BRD.md) |
|
||||
| [originals/物业AI人力资源系统开发规格TechSpec.docx](originals/物业AI人力资源系统开发规格TechSpec.docx) | [物业AI人力资源系统开发规格TechSpec.md](物业AI人力资源系统开发规格TechSpec.md) |
|
||||
| [originals/物业AI陪练系统一期建设实施方案.docx](originals/物业AI陪练系统一期建设实施方案.docx) | [legacy/物业AI陪练系统一期建设实施方案.md](legacy/物业AI陪练系统一期建设实施方案.md) |
|
||||
| [originals/物业管家与生活顾问AI陪练系统建设方案.docx](originals/物业管家与生活顾问AI陪练系统建设方案.docx) | 旧原始方案，仅归档 |
|
||||
@@ -0,0 +1,86 @@
|
||||
# ruoyi-ai 能力分片迁移计划
|
||||
|
||||
目标：逐步吸收 `ageerle/ruoyi-ai` 的知识库、模型配置、文档解析、RAG 和 chat 能力，但保留本项目 `ruoyi-aihr` 的业务边界，不整包搬入 `ruoyi-chat`。
|
||||
|
||||
## 迁移原则
|
||||
|
||||
- 业务落点仍是 `backend/ruoyi-modules/ruoyi-aihr`，包名使用 `org.dromara.aihr`。
|
||||
- 数据表使用 `aihr_knowledge_*`、`aihr_model_*` 前缀，避免和未来上游模块或系统表撞名。
|
||||
- `/api/knowledge/search` 保持当前契约：真实 RAG 优先，失败回退 seed。
|
||||
- 先只接一条 SOP 知识库链路；模型能力先走 OpenAI-compatible 边界，再扩展到案例、陪练和 chat。
|
||||
|
||||
## 分片顺序
|
||||
|
||||
| 阶段 | 搬什么 | 不搬什么 | 验收 |
|
||||
|---|---|---|---|
|
||||
| 1. 知识库 schema | `knowledge_info / attach / fragment` 改造为 `aihr_knowledge_*` | 向量库、LLM、上传 UI | SQL 可导入，seed API 不受影响 |
|
||||
| 2. 模型能力 | `chat_provider / chat_model` 改造为 `aihr_model_*`，最小 OpenAI-compatible 调用边界 | 多模型市场、图像、SSE、成本看板 | 模型列表可查；数据库配置后可调用 `/chat/completions` |
|
||||
| 3. 文档解析 | 文本/Markdown/PDF/Word/Excel/PPT loader、OSS-first 上传与分片 | 异步重试队列、图片智能分析 | txt/md/PDF/Word/Excel/PPT 文件可落 OSS 并解析为 fragment |
|
||||
| 4. 检索与 embedding | MySQL Fulltext + OpenAI-compatible embedding + Qdrant 最小向量召回 | Milvus/Weaviate 全量适配、独立向量库后台 | 同一问题返回带分数片段，配置 vector 模型后片段有 embedding，Qdrant 可用时参与 RRF 融合 |
|
||||
| 5. 资料处理状态 | 解析任务状态页、资料分类、处理链路、多文件/目录选择上传、服务端后台目录导入任务 | 单失败文件重试、分布式队列 | 能查看等待解析/解析中/已完成/失败、片段数、向量化状态并导入 Demo 文件 |
|
||||
| 6. RAG 回答 | 带引用回答、训练题生成 | 多模型市场、成本看板 | SOP 页面展示真实引用 |
|
||||
| 7. Chat | 最小会话、消息、引用来源 | 多智能体、工作流、MCP、Skills | 可围绕 SOP 连续追问 |
|
||||
|
||||
## 来源映射
|
||||
|
||||
| ruoyi-ai 来源 | 本项目落点 |
|
||||
|---|---|
|
||||
| `ruoyi-modules/ruoyi-chat/controller/knowledge` | `ruoyi-aihr/controller` 下只保留业务 API |
|
||||
| `KnowledgeAttachServiceImpl` | 文档上传、解析、分片、入库服务 |
|
||||
| `KnowledgeRetrievalServiceImpl` | 检索服务，先保留 fulltext，再接向量 |
|
||||
| `VectorStoreService` | 暂不抽独立 service，先在 `AihrSopSeedService` 用 Qdrant REST 做最小闭环 |
|
||||
| `chat_model / chat_provider` | `aihr_model_config / aihr_model_provider` |
|
||||
| `CustomApiServiceImpl / OpenAIServiceImpl` | 先落 `AihrModelSeedService` 的 OpenAI-compatible HTTP 边界 |
|
||||
| `EmbeddingModelFactory / RerankModelFactory` | 后续接向量化与重排序时再搬 provider adapter |
|
||||
|
||||
## 当前第一片
|
||||
|
||||
- 新增 MySQL 8 DDL：`backend/script/sql/aihr_knowledge_mysql8.sql`
|
||||
- 先定义 `aihr_knowledge_info`、`aihr_knowledge_attach`、`aihr_knowledge_fragment`
|
||||
- DDL 已包含住宅类 SOP seed 数据；`scripts/reset-dev-db.sh` 会导入。
|
||||
|
||||
## 当前第二片
|
||||
|
||||
- 新增 MySQL 8 DDL：`backend/script/sql/aihr_model_mysql8.sql`
|
||||
- 先定义 `aihr_model_provider`、`aihr_model_config`
|
||||
- 新增后端 API：`GET /api/aihr/model/providers`、`GET /api/aihr/model/configs`、`POST /api/aihr/model/chat`
|
||||
- `POST /api/aihr/model/chat` 优先读取 `aihr_model_config`，并从 `aihr_model_provider` 继承 `api_host/api_key`；未配置时返回 seed fallback，不向接口响应暴露密钥。
|
||||
|
||||
## 当前第三片
|
||||
|
||||
- 新增后端 API：`POST /api/knowledge/doc/upload`
|
||||
- SOP 页面已提供“上传文档”入口，支持 `.txt/.md/.markdown/.pdf/.doc/.docx/.xls/.xlsx/.ppt/.pptx`。
|
||||
- 上传时先复用若依 `sys_oss` 写入 MinIO，再按 `category` 找到或创建 `aihr_knowledge_info`，在 `aihr_knowledge_attach` 绑定 `oss_id/doc_id`，最后写入 `aihr_knowledge_fragment`。
|
||||
- 当前限制 100MB 内；同一知识库同名文件会复用 `doc_id` 并替换旧片段。
|
||||
- PDF/Word 解析走 Tika core + PDF/Microsoft 模块，不整包引入标准解析器集合。
|
||||
- 暂不引入图片智能分析和异步解析任务；这些进入后续片。
|
||||
|
||||
## 当前第四片
|
||||
|
||||
- `/api/knowledge/search` 已优先查询 `aihr_knowledge_fragment`。
|
||||
- 检索方式先迁移 `ruoyi-ai` 的 MySQL Fulltext 关键词召回：`MATCH(content) AGAINST(...)`。
|
||||
- MySQL 未命中或表未导入时仍回退当前 seed，保证 Demo 页面不断。
|
||||
- `aihr_knowledge_fragment` 已增加 `embedding_json/embedding_model/embedding_time`。
|
||||
- 若数据库启用 `category=vector` 的模型配置，上传后会同步调用 OpenAI-compatible `/embeddings` 并写入片段向量。
|
||||
- Qdrant 已接入本地开发编排；embedding 写入 MySQL 后尽力 upsert 到默认 collection `aihr_knowledge`。
|
||||
- `/api/knowledge/search` 在 vector 模型和 Qdrant 可用时会生成 query embedding，走 Qdrant 召回后回 MySQL hydrate 片段，并与 MySQL Fulltext 用 RRF 融合。
|
||||
- Qdrant 不可用或 vector 模型未配置时，仍走 MySQL Fulltext / LIKE / seed fallback。
|
||||
|
||||
## 当前第五片
|
||||
|
||||
- 新增后端 API：`GET /api/knowledge/processing/overview`。
|
||||
- 新增前端页面：`/knowledge/processing`，菜单名“资料处理”；`SOP知识库` 菜单保持独立不改名。
|
||||
- 页面聚合展示资料总量、已完成、处理中、失败、资料分类、解析任务表、处理链路、规则风险和最近事件。
|
||||
- 批量导入先复用 `POST /api/knowledge/doc/upload`，支持多文件和浏览器目录选择。
|
||||
- 新增 `POST /api/knowledge/doc/import-local-task` 和 `GET /api/knowledge/doc/import-tasks`，只读取 `AIHR_IMPORT_ROOT` / `aihr.import.root` 下的相对目录，写入 `aihr_knowledge_import_task` 后后台逐文件复用上传解析链路，页面轮询进度；`POST /api/knowledge/doc/import-local` 保留同步调试。
|
||||
|
||||
## 暂缓项
|
||||
|
||||
- 完整 `ruoyi-chat` 模块
|
||||
- Vben Admin 前端
|
||||
- Milvus/Weaviate/pgvector 等多向量库同时支持
|
||||
- 工作流、多智能体、MCP、Skills
|
||||
- 全量模型管理后台
|
||||
- 完整流式 chat 与消息持久化
|
||||
- 图片 OCR/视觉模型解析
|
||||
- 单失败文件重试、导入任务取消/暂停、分布式队列
|
||||
@@ -0,0 +1,552 @@
|
||||
# 物业管家与生活顾问 AI 陪练系统 —— 一期建设实施方案（合并终稿）
|
||||
|
||||
> 依据文件：[`物业管家与生活顾问AI陪练系统建设方案.docx`](../originals/物业管家与生活顾问AI陪练系统建设方案.docx)（原方案）
|
||||
> 参考评审：[`物业AI陪练系统建设方案研判报告.md`](物业AI陪练系统建设方案研判报告.md)（研判一）+ 五角色协同审计（研判二）
|
||||
> 文档性质：本方案是对原《建设方案》的**工程化改写**，目标是把一份战略愿景稿，升级为可以直接用于**需求评审、研发排期、招采比价、验收交付**的实施文档。
|
||||
> 使用方式：产品经理据此拆需求单；研发据此排期与设计接口；法务/合规据此出具意见；业务方据此提供基线数据（文中标注 `[待业务方补充]` 的项）。
|
||||
|
||||
---
|
||||
|
||||
## 0. 与原方案的关系
|
||||
|
||||
原方案的**战略定位、模块划分（学练考辅推）、三角色对练理念（AI客户/教练/考官）是成立的，予以保留**。本文档做的事情是：
|
||||
|
||||
1. 把"模块级"需求拆到"任务级"，补上原方案缺失的流程图、评分规则、数据字段
|
||||
2. 把"六个月全量交付"改写为"一期MVP优先"，明确P0/P1/P2边界
|
||||
3. 把"合规风险意识"升级为"具体法律义务清单"
|
||||
4. 把"预期成效百分比"改写为"基线—假设—测算—验证"的ROI框架
|
||||
|
||||
原方案中**不再赘述**的内容（如项目背景、行业对标案例、方案特色总结）本文档不重复，仅在必要处引用。
|
||||
|
||||
---
|
||||
|
||||
## 1. 一期建设范围与优先级
|
||||
|
||||
### 1.1 一期核心闭环（唯一目标）
|
||||
|
||||
```
|
||||
知识库管理 → 场景配置 → AI对练（单场景起步：物业费催缴） → AI评分反馈 → 主管指派/查看 → 基础数据看板
|
||||
```
|
||||
|
||||
一期**不追求场景数量和模块数量**，只追求把"学-练-考-评"这一条链路，在**一个高频、可验证ROI的场景**上完整跑通，并且验证"训练分数是否与真实业务绩效相关"这一原方案中最薄弱的环节。
|
||||
|
||||
### 1.2 P0 / P1 / P2 功能清单
|
||||
|
||||
| 优先级 | 功能 | 说明 |
|
||||
|---|---|---|
|
||||
| **P0** | 知识库管理（结构化FAQ + 标签 + 版本管理） | 不做图数据库，见第4章 |
|
||||
| **P0** | 催费场景 AI 对练（AI客户 + AI考官） | 单场景验证闭环，见第3章 |
|
||||
| **P0** | 规则引擎 + LLM 兜底评分 | 不做情感计算模型，见第5章 |
|
||||
| **P0** | 文本 + 语音（普通话）双模态 | 不做方言ASR、图片/视频 |
|
||||
| **P0** | 主管指派 / 完成率查看 | 基础管理功能 |
|
||||
| **P0** | 基础数据看板（训练次数/通过率/薄弱项） | 不做管理驾驶舱 |
|
||||
| **P0** | 数据合规基础设施（脱敏、权限分级、留存策略） | 法律义务，不可延后 |
|
||||
| **P1** | 扩展至10-20个高频场景（投诉、报修、增值推介等） | 二期启动，场景清单见3.4 |
|
||||
| **P1** | AI教练轻量提示（规则触发） | 二期，非实时LLM旁听 |
|
||||
| **P1** | 企业微信/钉钉基础集成 | 二期，先跑通催费场景闭环再联调 |
|
||||
| **P1** | AI评分与绩效关联分析（相关性验证） | 二期，需1-2个考核周期数据积累 |
|
||||
| **P1**（客户新增，见13章） | AI辅助起草SOP初稿（人工终审后生效） | 二期，效率工具，不改变"人工审核入库"原则 |
|
||||
| **P1**（客户新增，见13章） | AI辅助生成场景题库/案例变体（人工抽检后入库） | 二期，支撑10-20场景扩展提速，不能替代专家复核 |
|
||||
| **P1**（客户新增，见13章） | AI客户语音音色差异化（男/女声、语气强弱，采购商用TTS音色库） | 二期，仅换音色，不做数字人视频 |
|
||||
| **P1**（客户新增，见13章） | 每日个性化陪练任务推送（规则匹配版：按薄弱知识点/岗位匹配） | 二期，"智能"路径规划留三期，见13.5 |
|
||||
| **P2** | 知识图谱（Neo4j双图谱） | 三期，先有数据积累和真实关系复杂度需求再上 |
|
||||
| **P2** | 内容营销中心（AI生成朋友圈素材） | 三期，涉及广告法合规、独立审核链路 |
|
||||
| **P2** | 管理驾驶舱、能力雷达图、荣誉勋章体系 | 三期，需先有稳定评分数据 |
|
||||
| **P2** | 方言ASR、图像/视频上传、服务录像回放 | 三期或按需评估 |
|
||||
| **P2**（客户新增，见13章） | AI生成静态场景配图（文生图，用于训练场景引导页） | 三期或按需，纯展示辅助，不影响评分逻辑 |
|
||||
| **明确不做（一期）** | AI评分与绩效奖金/晋升直接挂钩 | 见第5.5节灰度期要求，未经一致性校准前禁止 |
|
||||
| **明确不做（一期）** | AI模拟业主群、情绪疏导树洞、话术共创坊 | 扩展创新模块，复杂度与一期目标不匹配 |
|
||||
| **明确不做（一期/二期）**（客户新增，见13章） | AI生成"视频模拟对话"（数字人形象+唇形同步的现场/电话视频对练） | 复杂度与图像/视频/数字人同级，需三期专项技术选型与成本评估，不建议提前 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 用户角色与权限矩阵
|
||||
|
||||
原方案三类角色（一线管家/生活顾问、项目主管/经理、集团培训/品质部）保留，补充权限颗粒度：
|
||||
|
||||
| 角色 | 可见数据 | 可执行操作 | 不可见/不可执行 |
|
||||
|---|---|---|---|
|
||||
| 管家/生活顾问 | 本人训练记录、本人评分、本人错题本 | 发起对练、查看自己的评分反馈与改写建议 | 不可见他人训练记录、不可见业主原始画像明细 |
|
||||
| 项目主管/经理 | 本项目下属训练记录、通过率、薄弱项排名 | 指派训练包、查看团队报告、发起复核申请 | 不可跨项目查看、不可修改评分规则、不可导出业主敏感数据 |
|
||||
| 集团培训/品质部 | 全量训练数据（脱敏后）、案例库、模型评测报告 | 审核知识库变更、终审案例入库、配置评分Rubric、处理评分申诉 | — |
|
||||
| 合规/法务（新增角色，原方案缺失） | 数据访问审计日志、脱敏效果抽检报告、评分申诉记录 | 审核数据授权条款、审批评分-绩效挂钩转正 | 不参与日常训练业务操作 |
|
||||
|
||||
> 原方案未定义合规角色的系统权限，此为本文档新增，用于承接第6章的合规治理要求。
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心场景需求矩阵（业务→开发的桥梁）
|
||||
|
||||
### 3.1 需求矩阵通用模板
|
||||
|
||||
| 用户角色 | 业务场景 | 触发条件 | 用户动作 | 系统动作 | AI能力 | 输出结果 | 数据记录 | 验收标准 |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| 管家 | 物业费催缴 | 员工发起训练 / 主管指派 | 语音或文字回复AI业主 | 生成/维持AI业主人设与情绪状态，判断是否命中SOP关键点 | 角色扮演对话生成、规则引擎SOP匹配、LLM兜底打分 | 总分、分项得分、关键失误、改写建议 | 对话文本/录音、评分明细、SOP命中标签 | 关键SOP命中率≥[待定]、无一票否决项触发 |
|
||||
| 主管 | 团队催费能力提升 | 月度收缴率低于目标 `[待业务方补充基线]` | 指派训练包 | 生成训练任务、推送提醒 | 学习路径推荐（一期用规则匹配，非AI个性化） | 团队短板报告 | 训练次数、通过率、薄弱知识点分布 | 完成率≥[待定]、团队平均分提升幅度 |
|
||||
| 培训部 | 一期效果验证 | 试点期结束（6-8周） | 拉取训练数据 | 计算训练分与真实收缴率相关性 | 统计分析（非AI能力） | 相关性验证报告 | 相关系数、样本量、置信区间 | 相关系数>0.4 视为训练分具备绩效预测力 |
|
||||
|
||||
### 3.2 场景任务级拆解示例①：物业费催缴（一期唯一场景，需完整定义）
|
||||
|
||||
| 任务节点 | 触发条件 | 学员输入 | AI客户（业主）动作 | 系统判定/评分点 | 一票否决项 | 异常分支 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| 1. 开场触达 | 训练开始 | 语音/文字开场白 | 根据人设初始情绪应答（如"又催费，烦不烦"） | 是否礼貌、是否说明来意 | 未表明身份直接催缴 | 业主拒接/拒绝对话 → 训练如何二次触达 |
|
||||
| 2. 了解拒缴原因 | 业主表达抵触 | 提问引导 | 表达具体拒缴理由（对服务不满/资金紧张/出差未归，人设预设） | 是否问清具体原因而非直接施压 | 未询问原因即威胁停水停电类话术 | 业主情绪升级为投诉 → 分支进入投诉处理逻辑 |
|
||||
| 3. 针对性应对 | 拒缴原因已明确 | 分场景话术（如先解释服务改进措施/提供分期方案） | 根据信任度状态调整配合度 | 是否针对具体原因给出对应方案，而非模板化催缴 | 承诺制度外的减免/优惠 | 业主要求升级找主管 → 训练如何得体转介 |
|
||||
| 4. 确认与记录 | 达成缴费共识或明确后续计划 | 确认时间/方式 | 确认或再次拖延 | 是否明确下一步时间节点和跟进方式 | 未获得任何后续承诺即结束对话 | — |
|
||||
| 5. 结束与评分 | 对话结束 | — | — | AI考官汇总评分：SOP完整度、情绪应变、沟通有效性、营销敏感性（是否提及增值服务但不生硬） | — | — |
|
||||
|
||||
> 此表用于研发直接产出对话状态机设计和AI考官评分规则，是原方案中完全缺失的颗粒度。
|
||||
|
||||
### 3.3 场景任务级拆解示例②：投诉处理（二期首个扩展场景，先行定义供预研）
|
||||
|
||||
| 任务节点 | 输入 | 系统/AI动作 | 数据记录 | 验收标准 |
|
||||
|---|---|---|---|---|
|
||||
| 接收 | 业主投诉（语音/文字/图片） | 识别投诉类型与紧急程度 | 投诉类型标签、紧急程度标签 | 分类准确率≥[待定] |
|
||||
| 安抚 | 学员应答 | AI业主情绪状态机响应 | 情绪曲线记录 | 是否先共情后解释（一票否决：反驳/激化矛盾） |
|
||||
| 记录 | 学员填写工单要素 | 校验必填字段完整性 | 工单字段完整度 | 关键字段（时间/地点/影响范围）缺失率 |
|
||||
| 派单 | 学员选择责任部门 | 校验派单是否符合SOP权责表 | 派单正确率 | 派单错误率≤[待定] |
|
||||
| 跟进 | 学员模拟跟进沟通 | AI业主追问处理进度 | 跟进及时性 | 是否承诺具体反馈时限 |
|
||||
| 回访 | 学员模拟回访 | AI业主给出满意度反馈 | 回访完成标记 | 回访动作是否执行 |
|
||||
| 关闭 | 学员结束工单 | 校验闭环完整性 | 工单关闭标签 | 全流程SOP关键点命中率 |
|
||||
|
||||
### 3.4 一期预留 / 二期启动场景清单（15项，供研发提前预估工作量）
|
||||
|
||||
漏水投诉、噪音投诉、宠物扰民、公共设施损坏、物业费催缴（一期已做）、拒缴沟通、报修跟进、电梯困人初期安抚、火警误报安抚、家政保洁增值服务推介、美居产品推荐、新业主交付接待、空置房巡查沟通、老年业主关怀、微信文字沟通规范。
|
||||
|
||||
> 每个场景上线前需产出与3.2/3.3同等颗粒度的任务拆解表，禁止仅凭"场景名称"进入开发排期。
|
||||
|
||||
---
|
||||
|
||||
## 4. 系统架构设计
|
||||
|
||||
### 4.1 六层架构（替代原方案"五大中心+管理后台"的平面模块划分）
|
||||
|
||||
| 层级 | 建设内容 | 一期范围 |
|
||||
|---|---|---|
|
||||
| 用户入口层 | 管家端、主管端、培训运营端、合规审核端 | 全部需要，合规审核端为一期新增 |
|
||||
| 业务应用层 | AI对练、评分反馈、主管指派、数据看板 | 一期仅此四项，其余（每日一练/专项训练/内容工坊/驾驶舱）延后 |
|
||||
| AI能力层 | AI客户、AI考官（规则引擎+LLM兜底）、RAG问答、ASR/TTS（普通话） | AI教练/情感计算模型/多方言延后 |
|
||||
| 知识与规则层 | FAQ库、SOP库、评分Rubric、一票否决规则 | 不建图数据库 |
|
||||
| 数据治理层 | 训练数据、评分数据、脱敏后业主信息、审计日志 | 一期必须建立，是合规底线 |
|
||||
| 集成与安全层 | 身份认证、权限控制、加密、日志审计 | 一期必须建立；企业微信/钉钉/工单系统集成延后到二期 |
|
||||
|
||||
### 4.2 AI角色实现方案（关键降维决策）
|
||||
|
||||
原方案暗示AI客户/教练/考官是三套独立系统，工程上不可行。一期采用：
|
||||
|
||||
- **技术方案**：单一大模型 + 角色化System Prompt + 显式对话状态机，而非三套独立模型/服务
|
||||
- **AI客户**：一期人物模型仅保留"基础属性 + 性格与风格"两维（结构化字段，非自由生成），"动机与目标""认知边界"作为静态prompt片段一次性注入；"动态信任度曲线"用**三档情绪状态机**（平静/不满/生气，规则触发切换）替代连续LLM自主判断，避免长对话漂移
|
||||
- **AI教练**：一期不做实时LLM旁听判断，改为**规则引擎触发**（静音超过N秒 / 连续2轮未命中SOP关键词 / 回复字数低于阈值）+ 固定话术库提示，LLM仅负责生成提示文案
|
||||
- **AI考官**：规则引擎（SOP关键词/checklist匹配，可解释性强）+ LLM兜底打分，输出结构化评分理由（"第X轮，扣Y分，理由：未执行SOP第Z条"），禁止只给笼统总分
|
||||
- **语音音色**（二期，客户新增诉求，见13.3）：AI客户的TTS音色可按人物人设选用不同音色库（如"急躁男性""温和女性"），仅替换音色参数，**不做数字人视频/唇形同步**；"现场"与"电话"场景通过对话渠道标签区分（沿用原方案案例库的沟通渠道维度），不改变底层技术方案
|
||||
|
||||
### 4.3 知识库技术选型
|
||||
|
||||
不采用Neo4j双图谱作为一期方案。一期：结构化FAQ + 标签体系 + 向量检索（pgvector/Milvus等）+ 规则化SOP节点。二期建立业务实体关系（如"报修—设备—责任部门—时限—话术—法规"）。三期视数据规模与真实推理需求再评估是否上图数据库，**不为"图谱"而图谱**。
|
||||
|
||||
### 4.4 内容生产提效工具（二期，客户新增诉求，见13.1/13.2）
|
||||
|
||||
- **AI辅助起草SOP初稿**：基于已有制度文档/工单记录生成SOP草稿，**必须**经集团培训/品质部专家终审后才能进入生效知识库，不改变第4.3节"人工审核入库"的既定原则，仅把"从0写"变成"改初稿"
|
||||
- **AI辅助生成场景题库/案例变体**：基于已定型的场景任务拆解模板（第3.2/3.3节），批量生成同一场景下的变体（不同欠费金额、不同拒缴理由、不同人设），**必须**经业务专家抽检合格后才能计入正式题库，用于支撑二期从1个场景扩展到10-20个场景时的内容产能瓶颈
|
||||
- 两者均为"内容生产提效工具"，服务于知识/内容运营团队，**不是**员工训练时的实时功能，因此不改变第4.2节AI客户/教练/考官的实时架构
|
||||
|
||||
---
|
||||
|
||||
## 5. AI能力与评分体系设计
|
||||
|
||||
### 5.1 一期评分 Rubric（可直接用于开发，替代原方案的定性描述）
|
||||
|
||||
| 评分维度 | 权重 | 评分要点 | 一票否决项 |
|
||||
|---|---:|---|---|
|
||||
| SOP完整度 | 30% | 是否完成安抚、确认、记录、派单、反馈、回访等关键动作 | 擅自承诺不符合制度的赔偿/减免 |
|
||||
| 情绪安抚 | 25% | 是否识别业主情绪，是否先共情再解释 | 反驳、指责、激化矛盾 |
|
||||
| 问题定位 | 20% | 是否问清关键信息（原因、时间、紧急程度） | 未获取关键信息即关闭对话 |
|
||||
| 表达规范 | 15% | 是否使用规范话术，语气是否专业 | 出现侮辱性、歧视性表述 |
|
||||
| 闭环意识 | 10% | 是否明确下一步动作、时限、责任人 | 未承诺后续反馈路径 |
|
||||
|
||||
> 该表为催缴/投诉类场景通用模板，每新增场景需由业务专家复核微调权重与一票否决项，评分标准变更须版本留痕。
|
||||
|
||||
### 5.2 模型治理清单（原方案完全缺失，一期必须建立）
|
||||
|
||||
- Prompt模板版本管理（每次变更留痕，可回滚）
|
||||
- 专家标注样本库（黄金评测集，覆盖各场景×多档情绪状态，建议≥200组起步）
|
||||
- AI评分与专家评分一致性评测（Kappa系数或平均绝对误差），低于阈值（建议Kappa<0.6）则暂停该场景评分用于绩效参考
|
||||
- 幻觉/引用溯源校验：AI考官给出的SOP扣分依据必须可追溯到知识库原文，禁止无来源的"编造式"扣分理由
|
||||
- 敏感内容拦截、越权回答拦截
|
||||
- 人工复核入口与重大错误回滚机制
|
||||
|
||||
### 5.3 评分-绩效解耦的灰度期方案（关键治理要求）
|
||||
|
||||
一期AI评分**仅用于培训反馈与积分排行**，**不接入绩效奖金、晋升、认证**。转正条件：
|
||||
|
||||
1. 运行至少1-2个完整考核周期
|
||||
2. 人工评分与AI评分一致性达标（Kappa>0.6 或同等标准）
|
||||
3. 建立员工评分申诉通道，复核结果可覆盖AI分数，且复核记录留痕
|
||||
4. 业务负责人 + 合规角色（见2.2权限矩阵）联合签字确认后，方可将该场景评分正式接入绩效系统
|
||||
|
||||
---
|
||||
|
||||
## 6. 数据架构与合规治理
|
||||
|
||||
### 6.1 数据对象清单
|
||||
|
||||
| 数据类型 | 存储内容 | 风险等级 | 处理原则 |
|
||||
|---|---|---|---|
|
||||
| 员工训练数据 | 对话录音/文本、评分记录 | 中 | 授权采集、留存期限明确、可申诉 |
|
||||
| 员工能力画像 | 雷达图、能力分布 | 中 | 仅本人+直属主管可见 |
|
||||
| 业主画像数据 | 偏好、家庭结构、服务历史 | 高 | **最小化采集，禁止主观标签，仅用行为事实标签**（见6.3），须单独同意 |
|
||||
| 案例库素材 | 脱敏后的真实对话案例 | 高 | k-匿名化处理，禁止可反推识别的字段组合同时出现 |
|
||||
| 评分与绩效关联数据 | 训练分与真实业绩的关联分析结果 | 高 | 仅在5.3灰度期通过后使用，需透明规则+申诉机制 |
|
||||
|
||||
### 6.2 法律义务清单（对应《个人信息保护法》，一期上线前必须满足）
|
||||
|
||||
| 法条 | 义务 | 本方案对应动作项 |
|
||||
|---|---|---|
|
||||
| 第13/14条（处理个人信息的合法性基础） | 使用业主数据超出物业服务原始目的时需单独同意 | 在服务合同/APP协议中新增专项条款，明确"业主服务数据可能用于内部AI训练模拟"，提供拒绝选项且不影响正常物业服务 |
|
||||
| 第24条（自动化决策） | 对个人权益有重大影响的自动化决策，需告知逻辑、允许说明与人工复核 | 见5.3灰度期方案：评分转正前必须建立申诉与人工复核通道，并书面告知全员评分规则 |
|
||||
| 数据出境相关条款 | 若使用境外大模型API处理境内业主/员工数据，需安全评估 | 一期优先选用境内合规部署的大模型服务；如必须使用境外API，先做出境安全评估 |
|
||||
|
||||
### 6.3 业主标签设计原则（避免伦理风险）
|
||||
|
||||
**禁止**使用主观评价类标签（如"难缠""脾气差""爱投诉"），**必须**改用行为事实标签，例如：
|
||||
|
||||
- 近90天内2次噪音投诉记录
|
||||
- 偏好微信文字沟通
|
||||
- 要求提前电话确认上门时间
|
||||
- 家中有老人，偏好上午时段服务
|
||||
|
||||
### 6.4 数据生命周期规则
|
||||
|
||||
- 最小必要原则：只采集训练/评分/合规审计所需字段
|
||||
- 分级分类：按6.1表格分级管理访问权限
|
||||
- 脱敏入库：案例库素材强制k-匿名化，脱敏后需做重识别风险抽测
|
||||
- 留存期限：训练类录音默认留存不超过`[待业务方与法务确认年限]`，超期自动清除或匿名化归档
|
||||
- 删除机制：业主可申请删除其画像数据，需在合理期限内响应
|
||||
- 访问审计：全量访问行为留痕，供合规角色定期抽查
|
||||
|
||||
---
|
||||
|
||||
## 7. 系统集成与技术选型（一期范围内）
|
||||
|
||||
一期**不做**与企业微信/钉钉/工单/收费系统的深度集成，仅做基础身份认证联通（用于登录与角色识别），避免第一阶段被外部接口联调拖慢核心闭环验证。二期启动集成接口清单设计，需明确：
|
||||
|
||||
- 对接系统：企业微信、钉钉、工单系统、收费系统、CRM
|
||||
- 每个接口需明确：字段清单、调用频率、失败重试策略、权限边界
|
||||
|
||||
一期技术选型建议：
|
||||
|
||||
| 能力 | 建议 | 理由 |
|
||||
|---|---|---|
|
||||
| 知识检索 | FAQ + 标签 + 向量检索 | 替代Neo4j图谱，降低一期复杂度 |
|
||||
| ASR/TTS | 第三方商用API（普通话） | 不自研，方言识别延后并优先外采成熟方言API |
|
||||
| 对话引擎 | 单一大模型 + 角色化Prompt + RAG | 避免维护多套独立模型 |
|
||||
| 内容安全 | 优先接入第三方内容审核API | 降低自建敏感词引擎的交付风险，二期内容营销中心启用时复用 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 实施路线图（现实排期，替代原方案6个月三阶段全量承诺）
|
||||
|
||||
### 一期：MVP验证（6-8周）
|
||||
|
||||
- 第1-2周：知识库（FAQ+标签）搭建、催费场景SOP梳理与Rubric制定
|
||||
- 第3-4周：AI客户人物模型（两维简化版）+ 规则引擎评分开发、对话状态机开发
|
||||
- 第5-6周：主管指派/看板功能开发、数据合规基础设施（脱敏、权限、审计日志）搭建
|
||||
- 第7-8周：10个试点项目灰度测试，采集真实催费工单做训练分-收缴率相关性验证
|
||||
|
||||
**一期验收标准**：核心闭环功能可用 + 相关性验证报告产出（无论结果是否达标，都作为二期决策依据）
|
||||
|
||||
### 二期：场景扩展与集成（视一期验证结果启动，预估3-4个月）
|
||||
|
||||
扩展至10-20个场景（见3.4清单）、AI教练轻量提示上线、企业微信/钉钉基础集成、方言ASR评估接入、评分-绩效关联分析启动（不代表转正）。
|
||||
|
||||
### 三期：规模化与治理成熟（视二期成效评估后启动）
|
||||
|
||||
知识图谱二阶段（业务实体关系）、内容营销中心1.0（含独立合规审核链路）、管理驾驶舱、评分正式转正接入绩效（需满足5.3全部条件）、全公司推广。
|
||||
|
||||
> 三阶段推广均需设置**预算节点与ROI验证阈值**，未达标不进入下一阶段，避免沉没成本持续扩大。
|
||||
|
||||
---
|
||||
|
||||
## 9. ROI 测算框架（替代原方案的裸百分比预期）
|
||||
|
||||
### 9.1 测算公式
|
||||
|
||||
```
|
||||
ROI = （培训成本节约 + 管理效率提升 + 投诉成本降低 + 收缴提升收益 + 增值业务毛利提升 - 系统总成本） / 系统总成本
|
||||
```
|
||||
|
||||
### 9.2 需业务方补齐的基线数据（立项前置条件）
|
||||
|
||||
| 指标类别 | 需补充的基线数据 |
|
||||
|---|---|
|
||||
| 培训效率 | 当前新员工培训天数、人均培训成本、讲师投入工时 |
|
||||
| 投诉改善 | 当前投诉量、平均处理时长、升级投诉比例、赔付成本 |
|
||||
| 收缴改善 | 当前收缴率、逾期金额、催缴人力成本 |
|
||||
| 增值转化 | 当前转化率、客单价、复购率 |
|
||||
| 员工留存 | 当前流失率、招聘成本、替换成本、上岗周期 |
|
||||
| 系统投入 | 一次性研发成本、大模型API调用成本、ASR/TTS采购成本、年度运维成本、内容运营人力成本 |
|
||||
|
||||
### 9.3 外部案例引用处理
|
||||
|
||||
原方案引用的"碧桂园服务""授客AI提效60%""永升物业7次对话掌握技能"三个案例**均无可核实来源、样本量与统计口径**，建议：要求提供公开可查证来源，否则从方案中删除，避免以不可验证数据为自身ROI预期背书。ROI预期数字在9.2基线数据补齐前，一律标注为"待验证假设"而非"预期成效"。
|
||||
|
||||
---
|
||||
|
||||
## 10. 验收标准体系
|
||||
|
||||
| 类型 | 验收指标 |
|
||||
|---|---|
|
||||
| 功能验收 | 场景配置、训练发起、对话记录、评分反馈、主管指派、看板展示是否完整 |
|
||||
| AI准确性验收 | 知识库问答是否引用来源可追溯、SOP命中率是否达标 |
|
||||
| 评分一致性验收 | AI评分与专家评分一致性达到设定阈值（Kappa>0.6） |
|
||||
| 语音能力验收 | 普通话识别准确率、响应延迟 |
|
||||
| 性能验收 | 并发用户数、平均响应时间、峰值稳定性（一期试点规模即可，非万人级） |
|
||||
| 安全验收 | 权限控制、日志审计、数据脱敏效果抽测、敏感内容过滤 |
|
||||
| 合规验收 | 业主授权条款是否落地、评分申诉通道是否可用、数据留存删除机制是否生效 |
|
||||
| 运营验收 | 训练任务完成率、场景新增效率（为二期扩展做准备） |
|
||||
|
||||
---
|
||||
|
||||
## 11. 需要补充的关键配套文档
|
||||
|
||||
| 文件 | 作用 | 责任方 |
|
||||
|---|---|---|
|
||||
| 《场景训练设计手册》 | 定义每个场景的人设、目标、情绪曲线、评分点（模板见3.2/3.3） | 产品+业务专家 |
|
||||
| 《AI评分Rubric全集》 | 每个场景的具体评分权重与一票否决项 | 业务专家+算法 |
|
||||
| 《数据安全与隐私合规方案》 | 落实第6章要求，需法务出具正式意见 | 法务+合规 |
|
||||
| 《系统集成接口清单》 | 二期启动集成时使用 | 研发 |
|
||||
| 《模型评测与验收方案》 | 黄金评测集、一致性评测方法 | 算法 |
|
||||
| 《ROI测算模型（含基线数据）》 | 落实第9章基线补齐 | 业务方+财务 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 立项与推进建议
|
||||
|
||||
**⚠️ 有条件建议立项**，条件：
|
||||
|
||||
1. 完成第6.2章法律义务对应动作项（业主单独同意条款、评分申诉与人工复核机制）
|
||||
2. 完成第9.2章基线数据补齐，删除或核实原方案三个外部引用案例
|
||||
3. 严格按第1章一期范围执行，不在一期同时启动P1/P2功能
|
||||
4. AI评分与绩效奖金/晋升解耦，满足5.3全部转正条件后再挂钩
|
||||
|
||||
满足以上条件后，按第8章路线图启动6-8周一期MVP，以第9章相关性验证结果作为是否扩大投入的决策依据。
|
||||
|
||||
---
|
||||
|
||||
## 13. 客户新增诉求评估（本次追加）
|
||||
|
||||
> 客户原话（逐字保留）：*"Ai自动编写sop，自动生成训练题库，自动陪练打分，自动生成场景模拟图和视频模拟对话，比如很凶的男人，和女人的声音，有现场的，有电话的，还有ai自动题库，每个人每天可以有自己的ai陪练进度。"*
|
||||
|
||||
处理原则：客户新增诉求**不整体照单全收**，按第1章同一套P0/P1/P2标准逐条拆解、定级、纳入，避免重蹈原方案"一次性全量承诺"的覆辙。拆解结果如下（已同步更新至第1.2/4.2/4.4节）：
|
||||
|
||||
### 13.1 AI自动编写SOP
|
||||
|
||||
- **拆解**：是"从0人工撰写"变成"AI起草初稿+专家终审"，属于知识运营提效工具，不是员工训练时的实时功能
|
||||
- **定级**：**P1，二期**
|
||||
- **风险**：AI起草的SOP若未经审核直接生效，会把幻觉内容变成"评分依据"，等于把第5.2节要防范的"AI幻觉污染评分"风险前移到源头，风险更高
|
||||
- **纳入方式**：不改变第4.3节"人工审核入库"原则，AI只产出草稿，终审人（集团培训/品质部）签字后才计入生效知识库，见第4.4节
|
||||
|
||||
### 13.2 自动生成训练题库 / AI自动题库
|
||||
|
||||
- **拆解**：基于已定型的场景任务模板（第3.2/3.3节），批量生成同一场景的变体（不同金额、不同拒缴理由、不同人设组合），用于解决"人工一个个写场景"在二期扩展到10-20个场景时的产能瓶颈
|
||||
- **定级**：**P1，二期**（一期只有催费单场景，人工写1个场景不构成瓶颈，不需要自动化）
|
||||
- **风险**：批量生成的题库若未经抽检直接上线，可能出现不合理、不合规、甚至带偏见的题目
|
||||
- **纳入方式**：AI生成变体 + 业务专家抽检合格后入库，抽检比例与标准需在《场景训练设计手册》（第11章文档清单）中明确，见第4.4节
|
||||
|
||||
### 13.3 自动陪练打分
|
||||
|
||||
- **拆解**：这一条**已经是本方案的核心设计**，即第5章"AI考官：规则引擎+LLM兜底评分"，客户诉求与既有方案完全一致，无需新增
|
||||
- **定级**：**P0，一期已覆盖**
|
||||
- **纳入方式**：不需改动，仅在此确认口径一致
|
||||
|
||||
### 13.4 自动生成场景模拟图和视频模拟对话（含差异化人声、现场/电话场景）—— 本次新增中风险最高的一项
|
||||
|
||||
- **拆解为三个独立子能力，复杂度差异巨大，不能打包处理**：
|
||||
|
||||
| 子能力 | 说明 | 技术复杂度 | 定级 |
|
||||
|---|---|---|---|
|
||||
| 差异化人声（"很凶的男人""女人的声音"） | AI客户TTS音色按人设选用不同音色库 | 低——采购商用TTS音色库即可，不涉及自研模型 | **P1，二期** |
|
||||
| 现场 / 电话场景区分 | 沿用原方案案例库"沟通渠道"标签维度（电话/微信/面访），配置AI客户对话渠道属性 | 低——已有设计基础，仅需在场景配置中挂钩 | **P1，二期** |
|
||||
| AI生成"视频模拟对话"（数字人形象出镜、按台词做唇形同步、支持现场/电话两种镜头语言） | 需要数字人视频生成/合成技术栈（形象建模或购买数字人SDK、TTS+唇形同步引擎、渲染或实时合成算力） | **高**——与我们此前审计中明确建议从一期砍掉的"图像/视频/数字人"是同一类能力，且比静态图片/视频上传的复杂度更高（涉及生成式视频合成，不是简单的上传播放） | **三期，需专项技术选型与成本评估，不建议提前，一/二期明确不做** |
|
||||
|
||||
- **风险提示（需向客户明确说明，避免预期错位）**：
|
||||
1. "差异化人声"和"现场/电话场景区分"**二期即可实现**，成本和周期都可控，可以较早满足客户"有凶的男人、有女人的声音、有电话的、有现场的"这类体验诉求的大部分
|
||||
2. "视频模拟对话"（即数字人形象出镜、有画面的对练）**技术复杂度和一期审计中建议砍掉的"图像/视频上传"不是一回事，而是更重的一层**——不是"支持上传视频"，而是"AI生成视频"，涉及数字人合成的独立技术栈选型（自建 vs 采购数字人SDK）、渲染成本（GPU/云服务费用随训练量线性增长）、以及唇形同步的真实感是否达到"可用于严肃培训考核"的门槛，这些都需要独立的技术预研和成本测算，不能在二期顺带做，也不适合作为MVP验证目标
|
||||
3. 建议向客户提出的替代方案：二期先用**"差异化人声 + 静态场景配图"**（第1.2节P2行"AI生成静态场景配图"）营造沉浸感（业主头像/场景插画配合语音对话），把"是否需要真正的数字人视频对练"作为三期的一个独立评估课题，视二期的训练效果和预算情况再决定是否投入
|
||||
|
||||
### 13.5 每个人每天可以有自己的AI陪练进度
|
||||
|
||||
- **拆解**：这是原方案"个性化学习路径"（原方案第八章2）+"每日一练"（原方案第六章）的再次确认，客户希望的是"干预到人"的每日训练节奏，而非全公司统一进度
|
||||
- **定级**：**P1，二期（规则匹配版）**；"真正智能"的个性化路径规划（如原方案"能力九宫格矩阵""动态难度调整"）**留三期**
|
||||
- **纳入方式**：
|
||||
- 二期：按员工"薄弱知识点标签 + 岗位 + 近 N 次训练分数"做**规则匹配**，每日自动推送1个训练任务（3分钟微场景），逻辑简单、可解释、可快速上线
|
||||
- 三期：待二期积累至少1-2个考核周期的训练数据后，再评估是否引入更复杂的个性化推荐算法（如原方案"三阶段模型+能力九宫格"），避免二期就上不成熟的"智能路径规划"却无法验证效果
|
||||
|
||||
### 13.6 本次追加对总体方案的影响
|
||||
|
||||
- **一期MVP范围（第1.2/8章）不变**：以上五条中只有13.3已在一期覆盖，其余四条均定级为二期或三期，不影响6-8周MVP的范围和排期
|
||||
- **二期范围新增4项**：AI辅助SOP起草、AI辅助题库生成、AI客户音色差异化、每日个性化任务推送（规则匹配版），已并入第1.2节P1清单
|
||||
- **三期新增1项待评估课题**：数字人视频模拟对练，需在二期结束后单独立项预研，不纳入本次实施方案的常规路线图
|
||||
- **建议向客户的沟通口径**：五条诉求中四条可以在二期（3-4个月内）如期兑现，唯独"视频模拟对话/数字人"需要额外的技术选型和成本评估，建议单独讨论预算和时间线，避免被笼统理解为"和其他功能一样二期就能上线"
|
||||
|
||||
---
|
||||
|
||||
## 14. 技术选型评估：是否以 PandaWiki 作为开发基底
|
||||
|
||||
> 评估对象：开源项目 `chaitin/PandaWiki`（AI驱动的知识库/Wiki系统）
|
||||
> 评估方式：直接审查其代码仓库（`backend/domain`、`usecase`、`handler`、许可证文件），基于代码证据而非项目介绍做判断
|
||||
> 结论先行：**不建议以 PandaWiki 作为整个系统的开发基底**。它能覆盖的只是第4章"知识与规则层"里很窄的一块，覆盖不了一期MVP真正的技术难点（三角色状态机、评分引擎），且存在一个容易被忽略的许可证/商业版限制陷阱。
|
||||
|
||||
### 14.1 PandaWiki 实际是什么（基于代码证据）
|
||||
|
||||
| 维度 | 实际情况 | 代码证据 |
|
||||
|---|---|---|
|
||||
| 产品定位 | AI驱动的知识库/Wiki系统（对标GitBook/Confluence+AI问答），不是培训/对练系统 | README定位"产品文档、技术文档、FAQ、博客系统" |
|
||||
| 对话模型 | **单一线性问答记录**：一个conversation下按时间顺序排列user/assistant两种角色的消息，无状态机字段、无角色扮演字段 | `backend/domain/conversation.go`：`ConversationMessage`只有`Role`（schema.RoleType，来自字节跳动eino框架）、`Content`，没有情绪状态、信任度、SOP命中标签等任何字段 |
|
||||
| AI能力 | RAG检索问答、AI辅助写作、AI搜索 | `backend/usecase/chat.go`、`knowledge_base.go` |
|
||||
| 权限模型 | 全局`User.Role` + 按知识库的`KBUsers.Perm`（查看/编辑/管理），无项目层级 | `backend/domain/user.go` |
|
||||
| 内容能力 | 富文本编辑、URL/Sitemap/RSS/Notion/思源笔记/离线文件导入 | `backend/usecase/crawler.go`、`sitemap.go`、`notion.go`、`siyuan.go` |
|
||||
| 集成能力 | 企业微信、钉钉机器人、微信公众号 | `backend/usecase/wecom.go`、`dingtalk_bot.go`、`wechat_*.go` |
|
||||
| 后端质量 | Go，domain/usecase/repo/handler清晰分层，工程质量不错 | `PROJECT_STRUCTURE.md`、`AGENTS.md` |
|
||||
| 语音/视频 | **完全没有**，纯文本系统 | 全仓库搜索无ASR/TTS/audio相关代码 |
|
||||
|
||||
### 14.2 关键陷阱：许可证与商业版限制
|
||||
|
||||
```go
|
||||
// backend/domain/license.go
|
||||
var baseEditionLimitationDefault = BaseEditionLimitation{
|
||||
MaxKb: 1, // 免费版只能建1个知识库站点
|
||||
MaxAdmin: 1, // 免费版只能有1个管理员账号
|
||||
MaxNode: 300, // 单个知识库下最多300篇文档
|
||||
}
|
||||
```
|
||||
|
||||
`.gitmodules`显示`backend/pro`是一个**独立的私有闭源仓库**（`chaitin/PandaWikiPro`），社区版通过这套`EditionLimitation`机制把"多知识库站点、多管理员、评论审核、高级机器人配置、水印、复制保护"等能力锁进付费专业版。
|
||||
|
||||
这意味着：如果直接用社区版承载本方案，**第2章权限矩阵里的"管家/主管/集团品质部/合规法务"四类角色几乎无法落地**——免费版只有1个管理员名额；如果公司有多个项目/多条业务线各建一个知识库，也会立刻撞到"1个知识库站点"的天花板。要突破就只能：
|
||||
|
||||
1. 付费购买闭源Pro版，引入一个新的供应商依赖和未知授权成本；
|
||||
2. 自己改代码绕开限制——AGPL协议下技术上允许，但这是在原厂商的商业模式上"打补丁"，且如果未来这套AI陪练系统对外输出给同行物业公司（原方案本身就提到对标碧桂园、永升物业，存在对外产品化的可能性），AGPL-3.0的"网络使用需开源"条款会要求我们的修改也必须开源，这一点**需要法务在立项前给出书面意见，不能等上线后才发现**。
|
||||
|
||||
### 14.3 能复用的部分 vs 必须新建的部分
|
||||
|
||||
| 一期方案章节 | 能否用PandaWiki | 判断依据 |
|
||||
|---|---|---|
|
||||
| 4.3 知识库技术选型（FAQ+标签+向量检索RAG） | ✅ **可以复用/参考** | PandaWiki的知识库+RAG问答正是它的核心强项，技术路线高度吻合 |
|
||||
| 4.4 AI辅助起草SOP初稿 | ✅ **可以复用** | 这正是PandaWiki"AI辅助创作"功能的标准场景，甚至可以直接拿PandaWiki当"知识运营工具"给集团培训/品质部用 |
|
||||
| 内容冷启动（导入现有制度文档） | ✅ **可以复用** | crawler/sitemap/文件导入功能可直接节省第4.4节的知识库搭建工作量 |
|
||||
| 二期 企业微信/钉钉基础集成 | ⚠️ **可参考代码，不建议直接依赖** | wecom.go/dingtalk_bot.go提供了对接思路，但这是"知识库对外提供问答"的集成，不是"员工训练系统"的集成，字段和鉴权模型都要重做 |
|
||||
| 4.2 AI客户/教练/考官三角色状态机 | ❌ **完全没有，必须新建** | conversation.go是单一线性问答记录，没有角色扮演、情绪状态、信任度曲线的任何数据结构 |
|
||||
| 5.1/5.2 评分Rubric引擎+一票否决 | ❌ **完全没有，必须新建** | 全仓库没有scoring/rubric/评分相关代码，这是本方案工程难度最高的部分，PandaWiki帮不上忙 |
|
||||
| 4章 ASR/TTS语音双模态 | ❌ **完全没有，必须新建/外采** | 纯文本系统，零语音基建 |
|
||||
| 2章 项目-主管-集团三级权限 | ❌ **模型不匹配，需重建** | PandaWiki只有"全局角色+按知识库权限"，没有物业行业的项目层级概念 |
|
||||
| 6章 数据合规（业主画像脱敏、留存删除） | ❌ **完全没有，必须新建** | PandaWiki面向文档知识库，没有业主/员工隐私数据的合规框架 |
|
||||
|
||||
### 14.4 三个反效果（如果整体基于 PandaWiki 开发）
|
||||
|
||||
1. **数据模型要大改**：`ConversationMessage`没有评分字段、状态机字段，硬塞进去比在空白项目里新建一个训练会话模型更贵，相当于在别人的地基上凿承重墙
|
||||
2. **商业版限制变成产品天花板**：免费版1个知识库站点、1个管理员，撞上第2章的四类角色和多项目场景，几乎立刻需要花钱买Pro或者自己改代码绕过授权检查
|
||||
3. **许可证义务是隐性成本**：AGPL-3.0如果未来对外提供服务（哪怕只是集团内跨法人实体共享），存在开源回馈义务，需要法务先给结论，不能事后补救
|
||||
|
||||
### 14.5 结论与推荐做法
|
||||
|
||||
**不把 PandaWiki 当系统底座**，而是把它当成一个**独立的、现成的知识库工具**，仅用于第4.4节"AI辅助起草SOP初稿"和知识冷启动导入这两个场景，供集团培训/品质部内部使用；核心的训练/评分/权限/合规系统仍按本方案第3-6章独立新建。
|
||||
|
||||
若业务方仍坚持要复用PandaWiki代码，建议在立项前先完成两项前置工作，作为第12章立项条件的补充：
|
||||
|
||||
5. 法务对AGPL许可证在"内部使用"和"未来可能对外产品化"两种场景下的义务出具书面意见
|
||||
6. 评估付费Pro版的真实授权成本，再决定是买Pro、是自行fork改限制、还是彻底放弃复用
|
||||
|
||||
---
|
||||
|
||||
## 15. 技术选型评估：JeecgBoot / ruoyi-ai / Yuxi 三个候选基底的实际情况
|
||||
|
||||
> 评估对象：`jeecgboot/JeecgBoot`（低代码平台+AIGC应用）、`ageerle/ruoyi-ai`（RuoYi底座AI聊天平台）、`xerrors/Yuxi`（RAG知识库+知识图谱平台）
|
||||
> 评估方式：与第14章同一套方法——直接审查代码仓库（领域模型、权限模型、许可证文件、AI相关模块），基于代码证据而非README宣传语做判断
|
||||
> 结论先行：**三个项目均不建议作为整体开发基底**。三者与PandaWiki的共性结论是——都覆盖不了一期MVP真正的技术难点（三角色对抗式状态机、可解释评分引擎），区别在于：三者均为**MIT/Apache 2.0标准开源许可证，不存在PandaWiki那种商业版功能阉割陷阱**，但每个项目在"能复用的基础设施"上各有取舍。
|
||||
|
||||
### 15.1 JeecgBoot 实际是什么（基于代码证据）
|
||||
|
||||
| 维度 | 实际情况 | 代码证据 |
|
||||
|---|---|---|
|
||||
| 产品定位 | 低代码开发平台，AIGC是其上附加的应用层能力，不是训练/对练系统 | `README.md`定位"AI低代码平台"；`README-AI.md`定位"类Dify的AIGC知识库问答" |
|
||||
| 对话模型 | 无角色扮演/状态机数据结构 | 未发现`ConversationMessage`之外的对练相关字段 |
|
||||
| AI能力 | RAG知识库问答（Tika解析→分块→pgvector→检索） | `jeecg-boot-module-airag`模块，核心类`EmbeddingHandler.java`（988行） |
|
||||
| 语音能力 | 仅TTS（接入智谱AI），**无ASR** | `VoiceController` |
|
||||
| 权限模型 | 部门树+角色+数据权限注解，相对成熟 | `SysDepart`（树形部门）、`SysRole`、`@PermissionData` |
|
||||
| 合规基建 | 有字段脱敏与操作审计注解，可直接复用 | `common/desensitization/`（`@Sensitive`）、`@AutoLog` |
|
||||
| 代码生成 | 核心卖点是低代码CRUD生成，部分生成器为闭源外部jar | `codegenerate/JeecgOneGUI.java` |
|
||||
| 技术栈 | Spring Boot 3.5.5 / Java 17（后端），Vue 3.5.22 / Vite 7 / TS 5.9 / Ant Design Vue 4.2（前端） | 根`pom.xml`、`jeecgboot-vue3/package.json` |
|
||||
| 许可证 | **Apache 2.0，代码级未发现商业版功能阉割**（仅2处"企业版/商业版"字样出现在注释与种子数据，非功能性gating） | 全仓库License扫描+关键字检索 |
|
||||
|
||||
### 15.2 ruoyi-ai 实际是什么（基于代码证据）
|
||||
|
||||
| 维度 | 实际情况 | 代码证据 |
|
||||
|---|---|---|
|
||||
| 产品定位 | 基于RuoYi管理系统底座的AI聊天平台（ChatGPT式单助手应用），不是培训/对练系统 | 模块结构：`ruoyi-admin`/`ruoyi-common`/`ruoyi-extend`/`ruoyi-modules`（含`ruoyi-chat`/`ruoyi-aiflow`） |
|
||||
| 对话模型 | **单一线性会话记录**：`ChatSession`仅有`id/userId/sessionTitle/sessionContent/conversationId`，无状态机、无人设、无情绪字段；`RoleType`枚举（SYSTEM/USER/ASSISTANT/FUNCTION/TOOL/WORKFLOW）是LLM协议角色，不是业务人设角色 | `ChatSession`实体、`RoleType`枚举 |
|
||||
| AI能力 | 混合检索RAG（向量+全文+RRF融合）+ 多路rerank + Neo4j知识图谱，技术成熟度四个候选项目中最高 | `KnowledgeRetrievalServiceImpl` |
|
||||
| "多智能体" | `AgenticServices`（LangChain4j）是工具调用式任务委派，非持久多人设对话 | `ruoyi-modules/ruoyi-aiflow` |
|
||||
| 语音能力 | **仅占位常量，未接线实现** | `AdiConstant.java`中`ASR`/`TTS`字符串常量无对应服务实现 |
|
||||
| 即时通讯集成 | 仅OAuth2第三方登录，**非消息推送/机器人对接** | `ruoyi-common-social`（基于JustAuth） |
|
||||
| 权限模型 | 部门树（`parentId`+`ancestors`）+ 标准RBAC，与JeecgBoot同级成熟度 | `SysDept`、`SysRole`/`SysRoleMenu`/`SysRoleDept` |
|
||||
| 合规基建 | 有脱敏注解与操作日志切面，可复用 | `@Sensitive`、`OperLogEvent`/`LogAspect` |
|
||||
| 工程质量 | 存在demo级代码（硬编码Windows绝对路径），全仓库仅6个测试文件 | `ChatServiceFacade.handleThinkingMode()`中硬编码`"C:\\Program Files\\nodejs\\npx.cmd"` |
|
||||
| 技术栈 | Spring Boot 3.5.8 / Java 17，LangChain4j 1.13.0，MyBatis-Plus，Sa-Token，Redisson | 根`pom.xml` |
|
||||
| 许可证 | **标准MIT，无任何商业版限制** | LICENSE文件 |
|
||||
|
||||
### 15.3 Yuxi 实际是什么（基于代码证据）
|
||||
|
||||
| 维度 | 实际情况 | 代码证据 |
|
||||
|---|---|---|
|
||||
| 产品定位 | 企业级RAG知识库+知识图谱智能体开发平台，不是培训/对练系统 | `README.md`（"基于大模型的智能知识库与知识图谱智能体开发平台"）、`ARCHITECTURE.md` |
|
||||
| "多智能体" | `subagent_task.py`是**工具调用式任务外包**（主Agent派发子任务给专用Agent执行后收回结果），**不是持久化的对抗式多人设对话**，与本方案"AI客户/教练/考官"三角色语义完全不同 | `backend/package/yuxi/agents/middlewares/subagent_task.py` |
|
||||
| "评估"能力 | `evaluator.py`是RAG检索质量指标（`calculate_retrieval_metrics`/`calculate_answer_metrics`），与"行为化评分/一票否决"无关，属于同名不同义 | `backend/package/yuxi/knowledge/eval/evaluator.py` |
|
||||
| 知识库能力 | Milvus向量库实现成熟（1333行），embedding/rerank抽象层完整，四个候选项目中RAG工程质量最高 | `knowledge/implementations/milvus.py`、`models/embed.py`/`models/rerank.py` |
|
||||
| 语音/视频能力 | **完全没有**，全仓库检索asr/tts/speech/voice/audio均无匹配（仅文件图标组件误命中） | 全仓库grep确认 |
|
||||
| "avatar"字样 | 均为用户头像UI组件（`pixelAvatar.js`/`FallbackAvatar.vue`），与数字人无关 | grep确认 |
|
||||
| 权限模型 | **扁平化，无部门层级**：`Department`+`User.role`仅3档（superadmin/admin/user），无合规角色、无项目层级 | `models_business.py` L28-94 |
|
||||
| 合规基建 | `OperationLog`仅记录动作+IP+时间戳，**无PII脱敏、无留存策略** | `models_business.py` |
|
||||
| 工程质量 | 四个候选项目中最高：120+测试文件、生产级`docker-compose.prod.yml`、CI/CD、独立文档站 | 仓库结构 |
|
||||
| 技术栈 | Vue3+Vite（前端），FastAPI+LangGraph+ARQ（后端），Postgres/Redis/MinIO/Milvus/Neo4j | 仓库结构、`ARCHITECTURE.md` |
|
||||
| 许可证 | **标准MIT，无任何商业版限制** | LICENSE文件 |
|
||||
|
||||
### 15.4 三个反效果（如果整体基于任一项目开发）——与第14.4节PandaWiki同源问题，程度更甚
|
||||
|
||||
1. **数据模型仍要大改**：三者的对话/会话实体（`ChatSession`、Yuxi无对练模型、JeecgBoot无对练模型）都是"单助手问答"或"零对练"设计，硬塞入状态机字段/情绪曲线/信任度字段，等同于在别人的地基上凿承重墙，与PandaWiki第14.4.1条问题同质
|
||||
2. **"多智能体"命名陷阱比PandaWiki更隐蔽**：ruoyi-ai的`AgenticServices`和Yuxi的`subagent_task`都容易被误读为"已有多角色对练能力"，实际是任务委派模式，**引入这两个项目反而会增加团队"名不副实"的认知成本和后续返工风险**，需要在立项评审时向决策层明确澄清这一点，避免采购/立项决策基于错误的能力预期
|
||||
3. **评分引擎仍是全空白**：四个候选项目（含PandaWiki）在"规则引擎+一票否决+可解释扣分理由"这一核心难点上零覆盖，Yuxi的`evaluator.py`和ruoyi-ai的rerank分数都只是检索相关性分数，不能作为评分引擎的种子代码
|
||||
|
||||
### 15.5 能复用的部分 vs 必须新建的部分（跨三项目汇总）
|
||||
|
||||
| 一期方案章节 | JeecgBoot | ruoyi-ai | Yuxi | 判断依据 |
|
||||
|---|---|---|---|---|
|
||||
| 4.3 知识库/RAG技术选型 | ✅ 可参考 | ✅ **可重点参考**（混合检索+RRF+多路rerank，三者中最完整） | ✅ **可重点参考**（Milvus实现+embed/rerank抽象，工程质量最高） | 三者RAG管道均比自建更省时间，选型时可对比后择一复用思路 |
|
||||
| 2章 权限/部门/角色模型 | ✅ **可重点参考**（`SysDepart`树+`@PermissionData`数据权限） | ✅ **可重点参考**（`SysDept`树+标准RBAC，与JeecgBoot同级） | ❌ 不建议参考（仅扁平3档role，无部门层级，与本方案四级权限矩阵不匹配） | JeecgBoot/ruoyi-ai的部门树设计可直接映射"项目-主管-集团"层级 |
|
||||
| 6章 数据合规（脱敏/审计） | ✅ 可复用（`@Sensitive`+`@AutoLog`） | ✅ 可复用（`@Sensitive`+`OperLogEvent`） | ❌ 不建议参考（`OperationLog`仅动作+IP+时间戳，无脱敏机制） | JeecgBoot/ruoyi-ai的注解式脱敏审计可直接搬入新系统 |
|
||||
| 4章 ASR/TTS语音双模态 | ⚠️ 仅TTS可参考，ASR仍需外采 | ❌ 完全没有，需从0外采 | ❌ 完全没有，需从0外采 | 三者均不能解决语音双模态需求，一期仍按第7章"第三方商用API"方案执行 |
|
||||
| 4.2 AI客户/教练/考官三角色状态机 | ❌ 完全没有，必须新建 | ❌ 完全没有，必须新建（`ChatSession`是单助手模型） | ❌ 完全没有，必须新建（`subagent_task`是任务委派非人设对话） | 四个候选项目（含PandaWiki）在此维度**全部空白**，是本方案唯一不可外部复用的核心模块 |
|
||||
| 5.1/5.2 评分Rubric引擎+一票否决 | ❌ 完全没有，必须新建 | ❌ 完全没有，必须新建（仅检索rerank分） | ❌ 完全没有，必须新建（仅RAG质量指标） | 同上，四个候选项目全部空白 |
|
||||
| 二期 企业微信/钉钉集成 | 未深入核实 | ⚠️ 仅OAuth2登录，非消息推送，参考价值有限 | 未深入核实 | 需按第7章独立设计接口清单，不建议依赖任一项目 |
|
||||
|
||||
### 15.6 与第14章PandaWiki评估的横向对比结论表
|
||||
|
||||
| 候选项目 | 许可证风险 | 核心定位 | 权限模型可复用性 | RAG可复用性 | 语音能力 | 整体基底建议 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| PandaWiki | 有（AGPL-3.0+闭源Pro版功能阉割） | AI知识库/Wiki | 较弱（无项目层级） | 较高 | 无 | ❌ 不采用为基底，仅取知识库子模块 |
|
||||
| JeecgBoot | 无 | 低代码平台+AIGC应用层 | ✅ 较优（部门树+数据权限） | 中 | 仅TTS | ❌ 不采用为基底，取权限模型+脱敏审计+RAG片段 |
|
||||
| ruoyi-ai | 无 | 单助手AI聊天平台 | ✅ 较优（部门树+RBAC） | ✅ 最优（混合检索+图谱） | 占位未实现 | ❌ 不采用为基底，取权限模型+脱敏审计+RAG管道设计思路 |
|
||||
| Yuxi | 无 | RAG知识库+知识图谱平台 | 弱（扁平3档role） | ✅ 最优（Milvus工程质量最高） | 无 | ❌ 不采用为基底，仅取RAG/知识库子模块设计思路 |
|
||||
|
||||
**四选一的结论是：不存在"哪个更接近"的说法**——核心的三角色状态机、评分引擎、ASR全链路，在全部四个候选项目中都是空白，必须独立新建，这是本一期方案工程复杂度的真正来源，不会因为选择任何一个开源项目作为基底而减少。
|
||||
|
||||
### 15.7 结论与推荐做法
|
||||
|
||||
**不把 JeecgBoot / ruoyi-ai / Yuxi 中的任何一个当作系统整体基底**。若业务方或研发团队希望降低基础设施搭建成本，建议按以下方式**拆解式**取用，且均为"参考设计思路/直接复用可复制的独立模块"，不做整仓fork：
|
||||
|
||||
1. **权限与组织架构**：优先参考 ruoyi-ai 或 JeecgBoot 的部门树（`SysDept`/`SysDepart`）+ RBAC 设计，映射到第2章"项目-主管-集团+合规"四级权限矩阵
|
||||
2. **数据脱敏与审计日志**：直接参考 JeecgBoot 的`@Sensitive`/`@AutoLog`或 ruoyi-ai 的`@Sensitive`/`OperLogEvent`注解式实现，落实第6章合规治理要求
|
||||
3. **RAG知识库管道**：三者均可参考，若追求检索精度优先看 ruoyi-ai（混合检索+RRF+多路rerank+知识图谱融合），若追求工程可维护性优先看 Yuxi（Milvus实现+embed/rerank抽象层）
|
||||
4. **核心的三角色状态机、评分引擎、ASR全链路**：不依赖任何候选项目，严格按本方案第3-5章从零设计与开发
|
||||
|
||||
综合第14章（PandaWiki）与本章（JeecgBoot/ruoyi-ai/Yuxi）的评估结论，**建议立项决策不再评估更多"现成开源项目做基底"的方向**，而是把有限的技术选型评审时间，集中到"三角色状态机+评分引擎"这一唯一无法外部复用的核心模块的架构设计上，这是决定一期MVP成败的真正瓶颈。
|
||||
@@ -0,0 +1,483 @@
|
||||
# 物业管家与生活顾问 AI 陪练系统建设方案研判报告
|
||||
|
||||
> 依据文件：[`物业管家与生活顾问AI陪练系统建设方案.docx`](../originals/物业管家与生活顾问AI陪练系统建设方案.docx)
|
||||
> 研判主题：需求分解是否到位、系统建设设计方案是否完善、主要风险与优化建议
|
||||
> 适用场景：立项评审、方案优化、招采前评审、产品需求深化、实施路线设计
|
||||
|
||||
---
|
||||
|
||||
## 一、总体判断
|
||||
|
||||
这份《物业管家与生活顾问 AI 陪练系统建设方案》方向是正确的，业务想象力较完整，模块覆盖也比较全面。方案已经把系统定位为“学、练、考、辅、推”一体化平台，并设计了智慧知识中心、场景实战中心、日常训练中心、内容营销中心、个人成长与数据中心、管理后台等核心模块，整体框架具备“平台型产品”的雏形。
|
||||
|
||||
但如果从**立项评审、产品需求规格、供应商招采、研发排期、验收交付**的角度看，当前方案还不够完善。它更像一份**战略型/愿景型建设方案**，还没有完全沉到“功能边界、数据口径、业务流程、接口清单、模型评测、合规治理、验收标准、MVP 优先级”的工程颗粒度。
|
||||
|
||||
核心结论可以概括为：
|
||||
|
||||
> **需求方向分解较到位，需求颗粒度不够；系统蓝图较完整，工程落地方案不足；业务闭环有设计，数据闭环和治理闭环还需补强。**
|
||||
|
||||
### 综合成熟度评估
|
||||
|
||||
| 评估项 | 当前成熟度 | 判断 |
|
||||
|---|---:|---|
|
||||
| 战略价值定位 | 8.5/10 | 价值叙事清晰，抓住了物业服务标准化、培训转化、经验沉淀的痛点 |
|
||||
| 业务模块完整性 | 8/10 | “学练考评推”覆盖较全，但略偏大而全 |
|
||||
| 用户角色与痛点拆解 | 7/10 | 三类核心用户明确，但缺少更细的岗位、权限、任务流 |
|
||||
| 产品需求颗粒度 | 5.5/10 | 还缺用户故事、功能边界、异常流程、验收标准 |
|
||||
| 技术架构可落地性 | 5.5/10 | 有技术关键词，但缺架构分层、数据流、模型治理、接口设计 |
|
||||
| 合规与安全设计 | 4.5/10 | 有意识，但不足以支撑真实上线，尤其是业主画像、语音、朋友圈内容 |
|
||||
| ROI 与成效测算 | 5/10 | 指标很有吸引力，但缺基线、假设、测算模型和验证路径 |
|
||||
| 推广运营机制 | 7/10 | 分阶段推广和运营角色有设计，但缺内容生产 SOP 和运营指标 |
|
||||
|
||||
---
|
||||
|
||||
## 二、需求分解是否到位？
|
||||
|
||||
### 2.1 已经分解到位的部分
|
||||
|
||||
方案把核心服务对象拆成了三类：
|
||||
|
||||
1. 一线管家 / 生活顾问；
|
||||
2. 项目主管 / 经理；
|
||||
3. 集团培训 / 品质部。
|
||||
|
||||
并分别提出了“试错场、内容库、透视镜、工具箱、中央厨房、高速公路”等需求表达，这一点是比较准确的。
|
||||
|
||||
方案也把业务场景覆盖到了投诉处理、费用催缴、增值服务推介、日常服务、突发应急等物业高频场景，说明对一线工作场景有较强理解。
|
||||
|
||||
尤其值得肯定的是，方案没有把 AI 陪练简单理解成“聊天机器人”，而是设计成了“AI 客户、AI 教练、AI 考官”三角色协同。这比单纯问答式训练更接近真实培训闭环。
|
||||
|
||||
### 2.2 没有完全分解到位的部分
|
||||
|
||||
当前需求分解主要停留在**模块级**和**场景级**，还没有进入**任务级、流程级、数据级、验收级**。
|
||||
|
||||
例如，“投诉处理”是一个场景，但还需要继续拆成：
|
||||
|
||||
| 层级 | 应继续拆解的问题 |
|
||||
|---|---|
|
||||
| 业务流程 | 投诉从接收、安抚、记录、派单、跟进、回访、关闭分别如何训练？ |
|
||||
| 训练目标 | 是训练情绪安抚、SOP 记忆、问题定位、跨部门协调，还是投诉升级预防？ |
|
||||
| 输入输出 | 学员说什么、上传什么、系统记录什么、AI 返回什么？ |
|
||||
| 评分规则 | 哪些话必须说？哪些话不能说？哪些动作遗漏直接判为不合格？ |
|
||||
| 数据沉淀 | 哪些训练数据进入能力画像？哪些进入案例库？哪些不能保留？ |
|
||||
| 验收标准 | 一个员工通过该场景的判定标准是什么？主管如何复核？ |
|
||||
|
||||
因此，建议后续补一份**《需求分解矩阵》**，不要只按模块写，而要按“角色—场景—任务—功能—数据—验收”展开。
|
||||
|
||||
### 2.3 建议采用的需求矩阵模板
|
||||
|
||||
| 用户角色 | 业务场景 | 触发条件 | 用户动作 | 系统动作 | AI 能力 | 输出结果 | 数据记录 | 验收标准 |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| 管家 | 漏水投诉 | 业主情绪激动，微信投诉 | 语音 / 文字回复业主 | AI 模拟业主追问、升级情绪 | 情绪模拟、SOP 检索、评分 | 评分、改进话术、错题点 | 录音、文本、评分、标签 | 关键 SOP 命中率、安抚话术合规率 |
|
||||
| 主管 | 团队催费能力提升 | 月度收缴率低于目标 | 指派训练包 | 系统生成训练任务 | 学习路径推荐 | 团队短板报告 | 训练次数、通过率、薄弱项 | 完成率、能力提升幅度 |
|
||||
| 培训部 | 新员工认证 | 新员工入职 | 配置考试场景 | 系统安排模拟考 | AI 考官评分 | 认证结果 | 考试记录、证书等级 | 专家复核一致性 |
|
||||
|
||||
---
|
||||
|
||||
## 三、系统建设方案是否完善？
|
||||
|
||||
### 3.1 框架完整，但偏“全景蓝图”，还不是“建设蓝图”
|
||||
|
||||
方案中“五大智能中心 + 管理后台”的结构是成立的。
|
||||
|
||||
- 智慧知识中心作为底座；
|
||||
- 场景实战中心作为核心训练入口；
|
||||
- 日常训练中心做习惯养成；
|
||||
- 内容营销中心支持顾问转发；
|
||||
- 个人成长与数据中心做画像和激励；
|
||||
- 管理后台支撑配置、权限、运营和监控。
|
||||
|
||||
逻辑上看，这个闭环是完整的。
|
||||
|
||||
但工程上还缺四类关键内容。
|
||||
|
||||
### 3.2 缺少系统边界
|
||||
|
||||
当前方案把知识图谱、语音对话、多模态上传、服务录像回放、AI 朋友圈、动态学习路径、管理驾驶舱、即时锦囊、社群模拟、情绪树洞等都纳入建设范围。
|
||||
|
||||
这些功能方向都可以成立，但如果一期全部做，会造成：
|
||||
|
||||
- 范围过大；
|
||||
- 周期失控；
|
||||
- 预算失真；
|
||||
- 验收困难；
|
||||
- 产品上线后运营压力过大。
|
||||
|
||||
建议明确一期、二期、三期边界，并标注 P0 / P1 / P2 优先级。
|
||||
|
||||
### 3.3 缺少数据架构
|
||||
|
||||
方案提到了静态知识库、动态知识库、案例库、能力画像、训练数据、真实绩效关联，但没有明确：
|
||||
|
||||
- 数据对象；
|
||||
- 字段结构；
|
||||
- 数据来源；
|
||||
- 数据权限；
|
||||
- 数据留存周期；
|
||||
- 脱敏规则；
|
||||
- 质量责任人；
|
||||
- 数据更新机制。
|
||||
|
||||
AI 陪练系统不是单纯的训练工具，而是一个持续积累业务数据和员工能力数据的平台。如果数据架构不清晰，后续会影响知识库质量、模型训练、能力画像、管理看板和合规审计。
|
||||
|
||||
### 3.4 缺少模型治理架构
|
||||
|
||||
AI 评分、AI 客户模拟、AI 教练提示、AI 内容生成都需要治理机制。当前方案提到了 RAG、安全网关、评分模型，但还没有形成完整的模型生命周期管理。
|
||||
|
||||
建议补充：
|
||||
|
||||
- 评测集；
|
||||
- 规则库；
|
||||
- Prompt 版本管理；
|
||||
- 人工复核；
|
||||
- 异常回退；
|
||||
- 幻觉监控；
|
||||
- 敏感内容拦截；
|
||||
- 模型版本留痕；
|
||||
- 评分漂移监控。
|
||||
|
||||
### 3.5 缺少验收体系
|
||||
|
||||
当前方案没有把“做到什么程度算完成”说清楚。
|
||||
|
||||
建议至少补充以下验收指标：
|
||||
|
||||
| 类型 | 示例指标 |
|
||||
|---|---|
|
||||
| 功能验收 | 场景配置、训练发起、对话记录、评分反馈、主管指派、看板展示是否完整 |
|
||||
| AI 准确性验收 | 知识库问答是否引用来源，SOP 命中率是否达标 |
|
||||
| 评分一致性验收 | AI 评分与专家评分一致性达到设定阈值 |
|
||||
| 语音能力验收 | 普通话识别准确率、常用方言识别准确率、响应延迟 |
|
||||
| 性能验收 | 并发用户数、平均响应时间、峰值稳定性 |
|
||||
| 安全验收 | 权限控制、日志审计、数据脱敏、敏感内容过滤 |
|
||||
| 运营验收 | 内容更新周期、场景新增效率、训练任务完成率 |
|
||||
|
||||
---
|
||||
|
||||
## 四、最主要的短板与风险
|
||||
|
||||
### 4.1 MVP 没有收敛，容易“大而全、慢落地”
|
||||
|
||||
当前方案想同时建设：
|
||||
|
||||
- 培训系统；
|
||||
- AI 对练系统；
|
||||
- 知识库系统；
|
||||
- 营销内容系统；
|
||||
- 数据驾驶舱；
|
||||
- 员工激励系统；
|
||||
- 情绪支持系统。
|
||||
|
||||
方向没错，但如果一期全部做，失败风险较高。
|
||||
|
||||
建议一期聚焦一个核心闭环：
|
||||
|
||||
> **知识库 + 高频场景 AI 对练 + AI 评分反馈 + 主管指派 + 数据看板**
|
||||
|
||||
也就是先把“学、练、考、评”打通。
|
||||
|
||||
“推”即内容营销中心，可以作为一期弱功能或二期独立模块，因为它涉及品牌审核、外部传播、AI 生成内容合规、企业微信接口等额外复杂度。
|
||||
|
||||
### 4.2 知识图谱设计偏重，建议分阶段实现
|
||||
|
||||
方案提出“双图谱驱动”，包括技能图谱和知识图谱，并提到图数据库。这一方向先进，但对一期来说可能偏重。
|
||||
|
||||
物业知识的第一阶段核心需求不是复杂推理，而是：
|
||||
|
||||
1. 能准确检索 SOP、法规、收费标准、项目制度；
|
||||
2. 能把知识转化为训练场景；
|
||||
3. 能保证 AI 回答有出处、可追溯、可纠错；
|
||||
4. 能让知识更新后快速生效。
|
||||
|
||||
建议分三步走：
|
||||
|
||||
| 阶段 | 建议做法 |
|
||||
|---|---|
|
||||
| 一期 | 文档知识库 + 标签体系 + 向量检索 + 规则化 SOP 节点 |
|
||||
| 二期 | 建立业务实体关系，如“报修—设备—责任部门—时限—话术—法规” |
|
||||
| 三期 | 上图数据库和推理能力，用于复杂跨场景推荐、能力路径规划、知识缺口分析 |
|
||||
|
||||
不要为了“图谱”而图谱。先解决知识准确、可用、可运营，再上复杂关系网络。
|
||||
|
||||
### 4.3 AI 评分体系需要严肃校准
|
||||
|
||||
方案提出从合规完整度、情感应变力、沟通有效性、营销敏感性等维度评分，并生成雷达图。这是必要的，但也是高风险点。
|
||||
|
||||
AI 评分最怕三件事：
|
||||
|
||||
1. 看起来很专业，但实际不稳定；
|
||||
2. 不同模型版本评分漂移；
|
||||
3. 员工质疑评分不公平。
|
||||
|
||||
建议增加：
|
||||
|
||||
| 评分治理项 | 建议 |
|
||||
|---|---|
|
||||
| 专家标准答案库 | 每个场景先由业务专家制定评分 Rubric |
|
||||
| 黄金评测集 | 建立一批专家已评分的对话样本，用于校准 AI |
|
||||
| 分项评分 | 不只给总分，要给“关键动作是否完成” |
|
||||
| 一票否决项 | 如承诺赔偿、辱骂业主、泄露隐私、违反收费政策 |
|
||||
| 人工复核 | 涉及认证、绩效、晋升时必须允许主管复核 |
|
||||
| 版本留痕 | 每次评分模型、提示词、规则变更都要留档 |
|
||||
|
||||
建议上线早期，AI 评分只作为训练反馈，不直接作为绩效依据。等评分稳定性通过专家一致性验证后，再逐步进入认证和绩效参考。
|
||||
|
||||
### 4.4 数据合规风险被低估
|
||||
|
||||
方案中提到动态知识库会记录业主画像、偏好、性格、服务历史、个性化需求等。这部分价值很高，但也是合规风险最高的地方。
|
||||
|
||||
建议补充一整章**数据安全与隐私保护方案**，至少包括：
|
||||
|
||||
| 数据类型 | 风险点 | 建议 |
|
||||
|---|---|---|
|
||||
| 员工语音 | 声纹、身份识别、绩效争议 | 明确授权、训练用途、保存期限、访问权限 |
|
||||
| 业主画像 | 个人偏好、家庭结构、服务历史 | 最小化采集，禁止无关标签，敏感信息脱敏 |
|
||||
| 对话记录 | 可能包含投诉、财务、家庭信息 | 自动脱敏、分级访问、审计留痕 |
|
||||
| 朋友圈素材 | 对外传播、品牌风险、AI 生成内容 | 人工审核、发布留痕、AI 内容标识评估 |
|
||||
| 绩效关联数据 | 员工权益影响 | 透明规则、申诉机制、人工复核 |
|
||||
|
||||
尤其要避免把“业主画像”做成无限制的标签系统。例如“脾气差、难缠、爱投诉”这类标签虽然业务上常见，但合规和伦理风险很高，建议改为**行为事实标签**，如：
|
||||
|
||||
- 近 90 天有 2 次噪音投诉；
|
||||
- 偏好微信沟通；
|
||||
- 希望提前电话确认上门时间；
|
||||
- 家中有老人，偏好上午上门服务。
|
||||
|
||||
### 4.5 内容营销模块需要更强的合规围栏
|
||||
|
||||
方案提出 AI 每日生成朋友圈素材包，包括文案、海报、小贴士，并支持管家保存、复制、跳转微信或企业微信发布。这个功能有业务价值，但不能只做敏感词过滤。
|
||||
|
||||
朋友圈工坊建议增加：
|
||||
|
||||
1. AI 生成内容标识策略；
|
||||
2. 品牌审核流；
|
||||
3. 禁用主题库，例如医疗功效、投资收益、虚假承诺、夸大宣传；
|
||||
4. 项目本地化审核；
|
||||
5. 发布记录留痕；
|
||||
6. 侵权图片检测；
|
||||
7. 业主可见范围控制；
|
||||
8. 一键撤回或风险通知机制。
|
||||
|
||||
### 4.6 ROI 预测缺少测算依据
|
||||
|
||||
方案提出培训周期缩短、培训成本降低、服务标准执行率提高、投诉处理时效提升、关键岗位流失率降低、增值服务转化率提高等目标。这些指标适合作为目标，但不能直接作为投资测算结论。
|
||||
|
||||
建议改成“基线—假设—测算—验证”的 ROI 模型。
|
||||
|
||||
| 指标 | 需要先补的数据 |
|
||||
|---|---|
|
||||
| 培训效率 | 当前新员工培训天数、人均培训成本、讲师投入工时 |
|
||||
| 投诉改善 | 当前投诉量、平均处理时长、升级投诉比例、赔付成本 |
|
||||
| 收缴改善 | 当前收缴率、逾期金额、催缴人力成本 |
|
||||
| 增值转化 | 当前转化率、客单价、复购率、顾问参与率 |
|
||||
| 员工留存 | 当前流失率、招聘成本、替换成本、上岗周期 |
|
||||
| 系统成本 | 软件开发 / 采购、模型调用、语音服务、运维、内容运营人力 |
|
||||
|
||||
ROI 公式建议写清楚：
|
||||
|
||||
```text
|
||||
ROI = （培训成本节约 + 管理效率提升 + 投诉成本降低 + 收缴提升收益 + 增值业务毛利提升 - 系统总成本） / 系统总成本
|
||||
```
|
||||
|
||||
这样管理层才容易判断项目是否值得投，财务也能复核。
|
||||
|
||||
---
|
||||
|
||||
## 五、建议重构后的系统建设思路
|
||||
|
||||
建议把系统架构从“五大中心”进一步补成“六层架构”。
|
||||
|
||||
| 层级 | 建设内容 |
|
||||
|---|---|
|
||||
| 用户入口层 | 管家端、生活顾问端、主管端、培训运营端、知识管理员端、合规审核端 |
|
||||
| 业务应用层 | AI 对练、每日一练、专项训练、考试认证、内容工坊、错题本、师徒带教、驾驶舱 |
|
||||
| AI 能力层 | AI 客户、AI 教练、AI 考官、RAG 问答、ASR / TTS、内容生成、话术润色、情绪识别 |
|
||||
| 知识与规则层 | SOP 库、法规库、项目制度库、案例库、评分 Rubric、禁用话术库、营销审核规则 |
|
||||
| 数据治理层 | 员工训练数据、能力画像、业主信息脱敏、模型评测数据、发布记录、审计日志 |
|
||||
| 集成与安全层 | 企业微信 / 钉钉、工单系统、收费系统、CRM、统一身份认证、权限控制、加密、日志审计 |
|
||||
|
||||
这样更适合转化为研发架构、采购标书和实施计划。
|
||||
|
||||
---
|
||||
|
||||
## 六、建议一期 MVP 范围
|
||||
|
||||
不建议一开始就做完整版。建议一期只做最能验证价值的闭环。
|
||||
|
||||
### 6.1 一期必须做
|
||||
|
||||
1. **知识库管理**
|
||||
支持 SOP、收费标准、投诉处理规范、常见问答、项目制度上传、标签化、版本管理。
|
||||
|
||||
2. **10—20 个高频 AI 对练场景**
|
||||
优先覆盖投诉、催费、报修、增值服务推介、突发应急。
|
||||
|
||||
3. **AI 客户 + AI 考官**
|
||||
AI 教练可以先做轻量版，例如在学员卡壳时给提示，不必一开始做到复杂实时干预。
|
||||
|
||||
4. **语音输入转文字**
|
||||
语音训练是物业场景的关键，但一期可以先保证普通话和常用口音，方言识别作为增强项。
|
||||
|
||||
5. **评分与反馈**
|
||||
每个场景输出总分、分项得分、关键失误、优秀话术、改写建议。
|
||||
|
||||
6. **主管指派与查看**
|
||||
主管可以给员工派训练包，查看完成率、通过率、高频错误。
|
||||
|
||||
7. **基础数据看板**
|
||||
包括训练次数、完成率、通过率、场景薄弱项、人员排名、团队短板。
|
||||
|
||||
8. **后台配置能力**
|
||||
支持场景配置、评分规则配置、知识上传、人员权限配置。
|
||||
|
||||
### 6.2 一期暂缓做
|
||||
|
||||
| 功能 | 建议 |
|
||||
|---|---|
|
||||
| 完整知识图谱 | 先做标签体系和 RAG，后续再图谱化 |
|
||||
| 多模态视频上传 | 可作为二期，先支持图片 / 文本 / 语音 |
|
||||
| AI 模拟业主群 | 复杂度高，适合成熟后做压力训练 |
|
||||
| 情绪疏导树洞 | 涉及心理健康与隐私，不宜一期上线 |
|
||||
| 朋友圈自动生成与分发 | 可先做模板库，AI 生成和外发审核放二期 |
|
||||
| 绩效强绑定 | 上线早期不建议直接影响奖金和晋升 |
|
||||
|
||||
---
|
||||
|
||||
## 七、需要补充的关键文档
|
||||
|
||||
如果这套方案准备进入立项、招采或研发，建议补齐以下文件：
|
||||
|
||||
| 文件 | 作用 |
|
||||
|---|---|
|
||||
| 《业务需求说明书 BRD》 | 明确建设目标、业务范围、用户角色、核心价值 |
|
||||
| 《产品需求文档 PRD》 | 拆解功能、页面、流程、字段、异常场景 |
|
||||
| 《场景训练设计手册》 | 定义每个 AI 对练场景的人设、目标、情绪曲线、评分点 |
|
||||
| 《知识库建设规范》 | 规定知识来源、标签、版本、审核、更新、废止机制 |
|
||||
| 《AI 评分 Rubric》 | 明确每个维度如何评分，哪些行为扣分或一票否决 |
|
||||
| 《数据安全与隐私合规方案》 | 处理员工、业主、语音、画像、绩效数据的规则 |
|
||||
| 《系统集成接口清单》 | 明确对接企业微信、钉钉、工单、收费、CRM 的字段和频率 |
|
||||
| 《模型评测与验收方案》 | 评估 AI 回答准确性、评分一致性、安全性、延迟、稳定性 |
|
||||
| 《运营机制手册》 | 明确总部、区域、项目、专家、内容审核员的职责 |
|
||||
| 《ROI 测算模型》 | 用真实基线数据支撑投入产出判断 |
|
||||
|
||||
---
|
||||
|
||||
## 八、重点修改建议
|
||||
|
||||
建议优先做以下 12 项修改：
|
||||
|
||||
1. **把方案从“完整版”拆成一期、二期、三期**，避免一次性建设过重。
|
||||
2. **补充 P0 / P1 / P2 功能优先级**，明确哪些功能是上线必备，哪些只是增强功能。
|
||||
3. **增加需求矩阵**，按角色、场景、任务、功能、数据、验收标准拆解。
|
||||
4. **增加真实业务流程图**，尤其是投诉、催费、报修、增值服务推介、新员工认证五大流程。
|
||||
5. **补充 AI 对练场景模板**，每个场景要有业主背景、显性诉求、隐性诉求、情绪曲线、雷点、标准 SOP、评分规则。
|
||||
6. **重写 AI 评分体系**，从“维度描述”升级为“评分 Rubric + 一票否决 + 专家复核 + 模型校准”。
|
||||
7. **弱化一期知识图谱表述**，先落地知识库、标签体系、RAG 和版本管理，图谱作为二期增强。
|
||||
8. **补充数据治理章节**，明确业主画像、语音、对话、绩效数据的采集、脱敏、授权、访问、保留和删除规则。
|
||||
9. **补充模型安全章节**，包括幻觉控制、敏感词、越权回答、提示词注入、内容审核、人工兜底。
|
||||
10. **补充系统集成清单**，不要只写“对接企业微信 / 钉钉”，要明确对接哪些数据、接口频率、失败重试和权限边界。
|
||||
11. **重构 ROI 章节**，用真实基线数据和公式支撑，不要只写预期百分比。
|
||||
12. **增加验收指标**，包括功能验收、性能验收、AI 准确性验收、评分一致性验收、合规验收、运营验收。
|
||||
|
||||
---
|
||||
|
||||
## 九、可直接追加到原方案的章节建议
|
||||
|
||||
如果要把现有方案升级为更适合立项或招采的版本，建议直接新增以下章节：
|
||||
|
||||
### 9.1 一期 MVP 建设范围
|
||||
|
||||
明确一期只建设以下核心闭环：
|
||||
|
||||
```text
|
||||
知识库管理 → 场景配置 → AI 对练 → AI 评分 → 错题反馈 → 主管指派 → 数据看板
|
||||
```
|
||||
|
||||
### 9.2 核心场景清单
|
||||
|
||||
建议一期优先建设 10—20 个场景，覆盖：
|
||||
|
||||
- 漏水投诉；
|
||||
- 噪音投诉；
|
||||
- 宠物扰民；
|
||||
- 公共设施损坏；
|
||||
- 物业费催缴；
|
||||
- 拒缴沟通；
|
||||
- 报修跟进；
|
||||
- 电梯困人初期安抚；
|
||||
- 火警误报安抚；
|
||||
- 家政保洁增值服务推介；
|
||||
- 美居产品推荐；
|
||||
- 新业主交付接待；
|
||||
- 空置房巡查沟通；
|
||||
- 老年业主关怀；
|
||||
- 微信文字沟通规范。
|
||||
|
||||
### 9.3 AI 评分 Rubric 示例
|
||||
|
||||
| 评分维度 | 权重 | 评分要点 | 一票否决项 |
|
||||
|---|---:|---|---|
|
||||
| SOP 完整度 | 30% | 是否完成安抚、确认、记录、派单、反馈、回访等关键动作 | 擅自承诺不符合制度的赔偿 |
|
||||
| 情绪安抚 | 25% | 是否识别业主情绪，是否先共情再解释 | 反驳、指责、激化矛盾 |
|
||||
| 问题定位 | 20% | 是否问清时间、地点、影响范围、紧急程度 | 未获取关键信息即关闭问题 |
|
||||
| 表达规范 | 15% | 是否使用规范话术，语气是否专业 | 出现侮辱性、歧视性、不当承诺 |
|
||||
| 闭环意识 | 10% | 是否明确下一步动作、时限、责任人 | 未承诺后续反馈路径 |
|
||||
|
||||
### 9.4 数据治理原则
|
||||
|
||||
建议在方案中明确：
|
||||
|
||||
- 最小必要原则；
|
||||
- 分级分类管理；
|
||||
- 脱敏入库；
|
||||
- 权限隔离；
|
||||
- 访问审计；
|
||||
- 保留期限；
|
||||
- 删除机制；
|
||||
- 员工申诉与复核机制。
|
||||
|
||||
### 9.5 模型治理机制
|
||||
|
||||
建议在方案中明确：
|
||||
|
||||
- Prompt 模板版本管理；
|
||||
- AI 评分版本管理；
|
||||
- 专家标注样本库；
|
||||
- 模型评测基准；
|
||||
- 幻觉率监控；
|
||||
- 敏感内容拦截；
|
||||
- 人工复核机制；
|
||||
- 重大错误回滚机制。
|
||||
|
||||
---
|
||||
|
||||
## 十、最终研判
|
||||
|
||||
这份方案的优点很明显：**业务洞察不错，场景意识强，平台框架完整，能打动管理层，也能体现 AI 赋能物业服务的方向感。**
|
||||
|
||||
但它现在最大的问题是：**“想做什么”讲得比较充分，“先做什么、怎么做、做到什么标准算成功”还不够清楚。**
|
||||
|
||||
建议不要直接拿当前版本进入开发或采购，而是将它定位为**立项初稿 / 概念方案**。
|
||||
|
||||
下一步应重点产出一版更硬的《系统建设实施方案》，把以下内容补实：
|
||||
|
||||
> **一期 MVP 范围、核心场景清单、需求矩阵、数据架构、AI 评分规则、合规治理、接口清单、验收标准、ROI 测算。**
|
||||
|
||||
只要这些补齐，这个项目就不只是一个“AI 陪练概念”，而可以真正变成一个可建设、可运营、可衡量、可持续迭代的物业服务能力平台。
|
||||
|
||||
---
|
||||
|
||||
## 十一、建议下一步工作清单
|
||||
|
||||
| 优先级 | 工作项 | 输出物 |
|
||||
|---|---|---|
|
||||
| P0 | 收敛一期范围 | 一期 MVP 功能清单 |
|
||||
| P0 | 拆解高频业务场景 | 10—20 个核心训练场景表 |
|
||||
| P0 | 建立评分规则 | AI 评分 Rubric 与一票否决规则 |
|
||||
| P0 | 明确数据合规边界 | 数据安全与隐私保护方案 |
|
||||
| P1 | 梳理系统接口 | 企业微信、钉钉、工单、收费、CRM 接口清单 |
|
||||
| P1 | 设计知识库运营机制 | 知识上传、审核、更新、废止流程 |
|
||||
| P1 | 建立模型评测机制 | 黄金样本集、专家评分一致性评测 |
|
||||
| P2 | 扩展内容营销中心 | AI 朋友圈素材审核与发布闭环 |
|
||||
| P2 | 建设高级知识图谱 | 业务实体关系、技能路径、能力推荐 |
|
||||
| P2 | 绩效关联分析 | 训练数据与投诉率、收缴率、转化率关联模型 |
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
@@ -0,0 +1,640 @@
|
||||
<!doctype html>
|
||||
<html lang="zh-CN">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>AI HR P0 页面组合原型</title>
|
||||
<style>
|
||||
* {
|
||||
box-sizing: border-box;
|
||||
}
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
background: #eef2f7;
|
||||
color: #172033;
|
||||
font-family:
|
||||
-apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif;
|
||||
}
|
||||
|
||||
.app {
|
||||
display: grid;
|
||||
grid-template-columns: 224px 1fr;
|
||||
min-height: 1150px;
|
||||
background: #f4f7fb;
|
||||
}
|
||||
|
||||
.sidebar {
|
||||
background: #1d2d3f;
|
||||
color: #cbd6e3;
|
||||
padding: 18px 14px;
|
||||
}
|
||||
|
||||
.brand {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 10px;
|
||||
margin-bottom: 24px;
|
||||
color: #fff;
|
||||
font-size: 17px;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.brand img {
|
||||
width: 24px;
|
||||
height: 24px;
|
||||
}
|
||||
|
||||
.nav-item {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 12px;
|
||||
height: 44px;
|
||||
padding: 0 12px;
|
||||
border-radius: 8px;
|
||||
margin-bottom: 8px;
|
||||
font-size: 15px;
|
||||
}
|
||||
|
||||
.nav-item.active {
|
||||
background: #3b9bff;
|
||||
color: #fff;
|
||||
}
|
||||
|
||||
.nav-icon {
|
||||
width: 18px;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.main {
|
||||
display: grid;
|
||||
grid-template-rows: 56px 1fr;
|
||||
min-width: 0;
|
||||
}
|
||||
|
||||
.topbar {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: space-between;
|
||||
padding: 0 24px;
|
||||
border-bottom: 1px solid #e3e8f0;
|
||||
background: #fff;
|
||||
color: #7c8798;
|
||||
}
|
||||
|
||||
.tenant {
|
||||
width: 240px;
|
||||
height: 34px;
|
||||
border: 1px solid #dfe5ee;
|
||||
border-radius: 8px;
|
||||
color: #98a2b3;
|
||||
display: grid;
|
||||
place-items: center;
|
||||
}
|
||||
|
||||
.content {
|
||||
padding: 22px;
|
||||
}
|
||||
|
||||
.meta-line {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: flex-end;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
|
||||
.meta-title {
|
||||
margin: 0 0 5px;
|
||||
font-size: 24px;
|
||||
line-height: 1.2;
|
||||
}
|
||||
|
||||
.meta-sub {
|
||||
margin: 0;
|
||||
color: #657184;
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
.meta-date {
|
||||
color: #657184;
|
||||
font-size: 13px;
|
||||
}
|
||||
|
||||
.grid {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.screen {
|
||||
min-height: 500px;
|
||||
border: 1px solid #dfe6f0;
|
||||
border-radius: 8px;
|
||||
background: #fff;
|
||||
box-shadow: 0 12px 28px rgba(17, 29, 48, 0.05);
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
.screen-head {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
padding: 16px 18px;
|
||||
border-bottom: 1px solid #edf1f6;
|
||||
}
|
||||
|
||||
.screen-title {
|
||||
margin: 0;
|
||||
color: #4971b6;
|
||||
font-size: 18px;
|
||||
}
|
||||
|
||||
.tag {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
height: 24px;
|
||||
padding: 0 10px;
|
||||
border-radius: 6px;
|
||||
background: #e9f3ff;
|
||||
color: #2374c9;
|
||||
font-size: 12px;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.tag.red {
|
||||
background: #ffe8e9;
|
||||
color: #c80f1f;
|
||||
}
|
||||
|
||||
.tag.green {
|
||||
background: #e5f8ee;
|
||||
color: #16834c;
|
||||
}
|
||||
|
||||
.tag.orange {
|
||||
background: #fff1dc;
|
||||
color: #bf6900;
|
||||
}
|
||||
|
||||
.screen-body {
|
||||
padding: 16px 18px 18px;
|
||||
}
|
||||
|
||||
.two-col {
|
||||
display: grid;
|
||||
grid-template-columns: 260px 1fr;
|
||||
gap: 14px;
|
||||
}
|
||||
|
||||
.card {
|
||||
border: 1px solid #e5eaf3;
|
||||
border-radius: 8px;
|
||||
background: #fff;
|
||||
}
|
||||
|
||||
.card.pad {
|
||||
padding: 14px;
|
||||
}
|
||||
|
||||
.card-title {
|
||||
margin: 0 0 12px;
|
||||
font-size: 15px;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.field {
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
|
||||
.label {
|
||||
display: block;
|
||||
margin-bottom: 5px;
|
||||
color: #7a8597;
|
||||
font-size: 12px;
|
||||
}
|
||||
|
||||
.input {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
min-height: 36px;
|
||||
padding: 0 10px;
|
||||
border: 1px solid #dfe5ee;
|
||||
border-radius: 7px;
|
||||
color: #253348;
|
||||
font-size: 13px;
|
||||
}
|
||||
|
||||
.button {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
min-width: 96px;
|
||||
height: 36px;
|
||||
padding: 0 14px;
|
||||
border: 0;
|
||||
border-radius: 7px;
|
||||
background: #f65f61;
|
||||
color: #fff;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.button.ghost {
|
||||
border: 1px solid #dfe5ee;
|
||||
background: #fff;
|
||||
color: #3f4c60;
|
||||
}
|
||||
|
||||
.question {
|
||||
display: grid;
|
||||
grid-template-columns: 28px 1fr auto;
|
||||
gap: 10px;
|
||||
align-items: start;
|
||||
padding: 10px 0;
|
||||
border-bottom: 1px solid #eef2f7;
|
||||
}
|
||||
|
||||
.num {
|
||||
display: grid;
|
||||
width: 28px;
|
||||
height: 28px;
|
||||
place-items: center;
|
||||
border-radius: 50%;
|
||||
background: #eef4ff;
|
||||
color: #356bb4;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.answer-box {
|
||||
min-height: 78px;
|
||||
margin-top: 12px;
|
||||
padding: 12px;
|
||||
border: 1px solid #e1e7f0;
|
||||
border-radius: 8px;
|
||||
background: #f9fbfe;
|
||||
color: #49576b;
|
||||
font-size: 13px;
|
||||
line-height: 1.6;
|
||||
}
|
||||
|
||||
.score-row {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(4, 1fr);
|
||||
gap: 8px;
|
||||
margin-top: 12px;
|
||||
}
|
||||
|
||||
.score {
|
||||
padding: 10px;
|
||||
border-radius: 8px;
|
||||
background: #f7f9fc;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.score strong {
|
||||
display: block;
|
||||
color: #d70f20;
|
||||
font-size: 21px;
|
||||
}
|
||||
|
||||
.chat {
|
||||
display: grid;
|
||||
gap: 10px;
|
||||
}
|
||||
|
||||
.bubble {
|
||||
max-width: 88%;
|
||||
padding: 10px 12px;
|
||||
border-radius: 8px;
|
||||
color: #253348;
|
||||
font-size: 13px;
|
||||
line-height: 1.55;
|
||||
}
|
||||
|
||||
.bubble.customer {
|
||||
background: #f1f5fb;
|
||||
}
|
||||
|
||||
.bubble.trainee {
|
||||
justify-self: end;
|
||||
background: #ffe9ea;
|
||||
}
|
||||
|
||||
.bubble.coach {
|
||||
border: 1px dashed #ffbe73;
|
||||
background: #fff8ed;
|
||||
}
|
||||
|
||||
.meter {
|
||||
height: 8px;
|
||||
border-radius: 999px;
|
||||
background: #ecf1f7;
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
.meter span {
|
||||
display: block;
|
||||
height: 100%;
|
||||
border-radius: inherit;
|
||||
background: linear-gradient(90deg, #f65f61, #31b367);
|
||||
}
|
||||
|
||||
.upload {
|
||||
display: grid;
|
||||
min-height: 112px;
|
||||
place-items: center;
|
||||
border: 1px dashed #cbd5e1;
|
||||
border-radius: 8px;
|
||||
background: #f8fafc;
|
||||
color: #637085;
|
||||
}
|
||||
|
||||
.transcript {
|
||||
max-height: 190px;
|
||||
overflow: hidden;
|
||||
color: #344255;
|
||||
font-size: 13px;
|
||||
line-height: 1.65;
|
||||
}
|
||||
|
||||
.summary-grid {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 10px;
|
||||
}
|
||||
|
||||
.summary-item {
|
||||
min-height: 88px;
|
||||
padding: 10px;
|
||||
border-radius: 8px;
|
||||
background: #f8fafc;
|
||||
color: #435269;
|
||||
font-size: 13px;
|
||||
line-height: 1.5;
|
||||
}
|
||||
|
||||
.search {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 92px;
|
||||
gap: 8px;
|
||||
margin-bottom: 12px;
|
||||
}
|
||||
|
||||
.sop-layout {
|
||||
display: grid;
|
||||
grid-template-columns: 190px 1fr;
|
||||
gap: 14px;
|
||||
}
|
||||
|
||||
.category {
|
||||
padding: 10px;
|
||||
border-bottom: 1px solid #edf1f6;
|
||||
color: #4b5b72;
|
||||
font-size: 13px;
|
||||
}
|
||||
|
||||
.category.active {
|
||||
color: #c80f1f;
|
||||
background: #fff0f1;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.quote {
|
||||
padding: 12px;
|
||||
border-left: 4px solid #d70f20;
|
||||
border-radius: 6px;
|
||||
background: #fff6f6;
|
||||
color: #374256;
|
||||
font-size: 13px;
|
||||
line-height: 1.6;
|
||||
}
|
||||
|
||||
.doc {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
gap: 12px;
|
||||
padding: 10px 0;
|
||||
border-bottom: 1px solid #edf1f6;
|
||||
font-size: 13px;
|
||||
}
|
||||
|
||||
.muted {
|
||||
color: #7a8597;
|
||||
}
|
||||
|
||||
.footer-actions {
|
||||
display: flex;
|
||||
justify-content: flex-end;
|
||||
gap: 10px;
|
||||
margin-top: 14px;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="app">
|
||||
<aside class="sidebar">
|
||||
<div class="brand">
|
||||
<img src="../../frontend/src/assets/logo/logo.png" alt="" />
|
||||
<span>物业AI人力资源系统</span>
|
||||
</div>
|
||||
<div class="nav-item active"><span class="nav-icon">●</span> 首页</div>
|
||||
<div class="nav-item"><span class="nav-icon">▣</span> AI 面试</div>
|
||||
<div class="nav-item"><span class="nav-icon">◈</span> 三角色对练</div>
|
||||
<div class="nav-item"><span class="nav-icon">▤</span> 案例沉淀</div>
|
||||
<div class="nav-item"><span class="nav-icon">☰</span> SOP 知识库</div>
|
||||
<div class="nav-item"><span class="nav-icon">⚙</span> 系统管理</div>
|
||||
</aside>
|
||||
|
||||
<main class="main">
|
||||
<header class="topbar">
|
||||
<div>首页 / P0 页面原型总览</div>
|
||||
<div class="tenant">选择租户</div>
|
||||
</header>
|
||||
|
||||
<section class="content">
|
||||
<div class="meta-line">
|
||||
<div>
|
||||
<h1 class="meta-title">P0 四个页面关键状态</h1>
|
||||
<p class="meta-sub">先确认页面信息架构，再逐个落 plus-ui；英雄路径优先保证 AI 面试可端到端演示。</p>
|
||||
</div>
|
||||
<div class="meta-date">数据截至：2026-07-02 10:00:00</div>
|
||||
</div>
|
||||
|
||||
<div class="grid">
|
||||
<article class="screen">
|
||||
<div class="screen-head">
|
||||
<h2 class="screen-title">AI 面试出题</h2>
|
||||
<span class="tag red">英雄路径 A</span>
|
||||
</div>
|
||||
<div class="screen-body two-col">
|
||||
<aside class="card pad">
|
||||
<h3 class="card-title">面试对象</h3>
|
||||
<div class="field">
|
||||
<span class="label">候选人</span>
|
||||
<div class="input">张明 · 生活顾问</div>
|
||||
</div>
|
||||
<div class="field">
|
||||
<span class="label">项目</span>
|
||||
<div class="input">银城花园 / 住宅</div>
|
||||
</div>
|
||||
<div class="field">
|
||||
<span class="label">岗位画像</span>
|
||||
<div class="input">投诉处理、催缴沟通、SOP 执行</div>
|
||||
</div>
|
||||
<div class="footer-actions">
|
||||
<button class="button">生成题目</button>
|
||||
</div>
|
||||
</aside>
|
||||
<section>
|
||||
<div class="card pad">
|
||||
<h3 class="card-title">AI 生成面试题</h3>
|
||||
<div class="question">
|
||||
<span class="num">1</span>
|
||||
<div>业主因漏水情绪激动到前台投诉，你第一句话怎么说？</div>
|
||||
<span class="tag green">已答</span>
|
||||
</div>
|
||||
<div class="question">
|
||||
<span class="num">2</span>
|
||||
<div>催缴物业费时，业主质疑服务不到位，你如何回应？</div>
|
||||
<span class="tag orange">作答中</span>
|
||||
</div>
|
||||
<div class="answer-box">候选人回答：先表示理解和歉意，确认业主具体不满意的服务点，再说明缴费与服务改进可以并行处理。</div>
|
||||
<div class="score-row">
|
||||
<div class="score"><span>表达</span><strong>86</strong></div>
|
||||
<div class="score"><span>SOP</span><strong>82</strong></div>
|
||||
<div class="score"><span>情绪</span><strong>90</strong></div>
|
||||
<div class="score"><span>总分</span><strong>86</strong></div>
|
||||
</div>
|
||||
<div class="footer-actions">
|
||||
<button class="button ghost">保存草稿</button>
|
||||
<button class="button">完成评分</button>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="screen">
|
||||
<div class="screen-head">
|
||||
<h2 class="screen-title">三角色对练</h2>
|
||||
<span class="tag red">育 / 用核心</span>
|
||||
</div>
|
||||
<div class="screen-body two-col">
|
||||
<aside class="card pad">
|
||||
<h3 class="card-title">场景配置</h3>
|
||||
<div class="field">
|
||||
<span class="label">场景</span>
|
||||
<div class="input">客服应对投诉</div>
|
||||
</div>
|
||||
<div class="field">
|
||||
<span class="label">AI 业主</span>
|
||||
<div class="input">高情绪、追问进度、质疑服务</div>
|
||||
</div>
|
||||
<div class="field">
|
||||
<span class="label">教练提示</span>
|
||||
<div class="input">仅在漏关键步骤时提示</div>
|
||||
</div>
|
||||
<p class="muted">信任度</p>
|
||||
<div class="meter"><span style="width: 68%"></span></div>
|
||||
</aside>
|
||||
<section class="card pad">
|
||||
<h3 class="card-title">对练实时过程</h3>
|
||||
<div class="chat">
|
||||
<div class="bubble customer">AI业主：你们说今天处理，到现在都没人联系我，这个房子还怎么住？</div>
|
||||
<div class="bubble trainee">学员：我先帮您确认报修单和现场照片，今天 30 分钟内给您明确回复。</div>
|
||||
<div class="bubble coach">AI教练：先安抚，再确认诉求。</div>
|
||||
<div class="bubble customer">AI业主：我不要流程，我要知道谁负责、什么时候来。</div>
|
||||
</div>
|
||||
<div class="score-row">
|
||||
<div class="score"><span>合规</span><strong>78</strong></div>
|
||||
<div class="score"><span>沟通</span><strong>84</strong></div>
|
||||
<div class="score"><span>情绪</span><strong>72</strong></div>
|
||||
<div class="score"><span>建议</span><strong>2条</strong></div>
|
||||
</div>
|
||||
<div class="footer-actions">
|
||||
<button class="button ghost">继续一轮</button>
|
||||
<button class="button">结束并评分</button>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="screen">
|
||||
<div class="screen-head">
|
||||
<h2 class="screen-title">案例语音整理</h2>
|
||||
<span class="tag orange">样片兜底</span>
|
||||
</div>
|
||||
<div class="screen-body two-col">
|
||||
<aside class="card pad">
|
||||
<h3 class="card-title">上传与转写</h3>
|
||||
<div class="upload">拖入语音 / 选择样例录音</div>
|
||||
<p class="muted">ASR 转写结果</p>
|
||||
<div class="transcript">
|
||||
业主反映地下车库长期积水，担心车辆受损。管家先确认车位号与积水时间，安排工程人员排查排水沟，并在业主群同步处理进度。
|
||||
</div>
|
||||
<div class="footer-actions">
|
||||
<button class="button">AI 整理</button>
|
||||
</div>
|
||||
</aside>
|
||||
<section class="card pad">
|
||||
<h3 class="card-title">结构化案例稿</h3>
|
||||
<div class="summary-grid">
|
||||
<div class="summary-item"><strong>背景</strong><br />雨后车库积水，业主担心车辆与安全问题。</div>
|
||||
<div class="summary-item"><strong>处理</strong><br />确认位置、派工排查、群内同步、次日复盘。</div>
|
||||
<div class="summary-item"><strong>结果</strong><br />排水沟堵塞已清理，业主确认问题解决。</div>
|
||||
<div class="summary-item"><strong>亮点</strong><br />响应快、过程透明、主动同步进度。</div>
|
||||
</div>
|
||||
<p>
|
||||
<span class="tag green">投诉处理</span>
|
||||
<span class="tag">车库</span>
|
||||
<span class="tag orange">高情绪</span>
|
||||
</p>
|
||||
<div class="footer-actions">
|
||||
<button class="button ghost">送审</button>
|
||||
<button class="button">入库</button>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="screen">
|
||||
<div class="screen-head">
|
||||
<h2 class="screen-title">SOP 知识库</h2>
|
||||
<span class="tag green">可引用 SOP 内容</span>
|
||||
</div>
|
||||
<div class="screen-body">
|
||||
<div class="search">
|
||||
<div class="input">业主投诉漏水，管家第一步怎么处理？</div>
|
||||
<button class="button">检索</button>
|
||||
</div>
|
||||
<div class="sop-layout">
|
||||
<aside class="card">
|
||||
<div class="category active">投诉处理 SOP</div>
|
||||
<div class="category">催缴沟通 SOP</div>
|
||||
<div class="category">报修跟进 SOP</div>
|
||||
<div class="category">交付接待 SOP</div>
|
||||
<div class="category">巡检记录 SOP</div>
|
||||
</aside>
|
||||
<section>
|
||||
<div class="quote">
|
||||
AI 回答：先安抚业主情绪并确认具体影响范围；同步记录房号、报修时间、现场照片；再创建工单并明确首次反馈时限。引用：投诉处理 SOP v1.0 第 2、3、5 条。
|
||||
</div>
|
||||
<div class="card pad" style="margin-top: 12px">
|
||||
<h3 class="card-title">命中文档</h3>
|
||||
<div class="doc"><strong>投诉处理 SOP v1.0</strong><span class="tag green">引用 3 段</span></div>
|
||||
<div class="doc"><strong>报修跟进 SOP v1.0</strong><span class="tag">引用 2 段</span></div>
|
||||
<div class="doc"><strong>高情绪沟通话术</strong><span class="tag orange">建议补充</span></div>
|
||||
</div>
|
||||
<div class="footer-actions">
|
||||
<button class="button ghost">查看原文</button>
|
||||
<button class="button">生成训练题</button>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
</div>
|
||||
</section>
|
||||
</main>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 313 KiB |
@@ -0,0 +1,342 @@
|
||||
# 物业行业 AI 人力资源系统 · 业务需求文档(BRD)
|
||||
|
||||
> 版本:v1.1(统一版)｜ 日期:2026-07-02
|
||||
> 定位:本文是本项目的**唯一事实源(Single Source of Truth)**,收敛此前所有讨论与文档,取代分散的局部材料作为业务需求基准。
|
||||
> v1.1 变更:第 5 章数据模型方向补充"HR 主干已对齐《手册》卷1 第9章"结论(见 5.2)。
|
||||
>
|
||||
> **收敛来源**:
|
||||
> - 《物业管家与生活顾问 AI 陪练系统建设方案》(原始业务方案,陪练视角)
|
||||
> - 《物业 AI 陪练系统一期建设实施方案》(含 ch.14/15 技术选型评估)
|
||||
> - 《物业 AI 陪练系统建设方案研判报告》
|
||||
> - 《AI 人力资源系统一期 Demo 作战清单》v1.6(决策 / MVP / 验收 / 排期 / 闸门 / Qdrant 语义检索路线)
|
||||
> - 2026-07-01 需求讨论纪要(HR 负责人提出,确立"选用育留"定位)
|
||||
> - 《数据资源模型主题域草案》(Silverston 通用数据模型)
|
||||
>
|
||||
> **关键重定位(本项目最重要的一条)**:系统已从"AI 陪练系统"(培训/品质视角)**重定位为"选用育留全生命周期 AI 人力资源系统"**(HR 负责人主导)。原"陪练"是其中「育/用」一个模块。
|
||||
|
||||
---
|
||||
|
||||
## 1. 项目背景与定位
|
||||
|
||||
### 1.1 背景
|
||||
|
||||
物业管理行业从"规模扩张"转向"品质驱动",一线管家与生活顾问的服务力(沟通、业务熟练度、营销、应变)直接决定业主满意度与品牌口碑。传统"老带新"式培训成本高、场景少、反馈慢、难规模化复制。企业最宝贵的经验分散在个人大脑里,"愿意讲才成为资产"。
|
||||
|
||||
### 1.2 定位
|
||||
|
||||
**面向物业一线的「选 · 用 · 育 · 留」全生命周期 AI 人力资源系统。**
|
||||
|
||||
- 需求由**公司人力资源负责人**提出,面向大老板汇报立项。
|
||||
- 本质是一套完整 ERP 中**以人力资源为核心**的部分,横跨 HCM(培训/绩效/发展)与招聘。
|
||||
- 原"AI 陪练"是其中「育/用」一个模块,不是系统全部。
|
||||
|
||||
### 1.3 核心价值
|
||||
|
||||
1. **隐性经验显性化**:将金牌管家/顾问的实战智慧,经大模型萃取为可传承、可复制的企业数字资产。
|
||||
2. **选用育留全链闭环**:从面试选人 → 上岗培训 → 日常训练 → 能力评估认证,打通"学-练-考-评"闭环。
|
||||
3. **个性化能力画像**:基于多维表现数据生成能力雷达图,精准识别短板、靶向推送训练。
|
||||
|
||||
---
|
||||
|
||||
## 2. 用户角色与痛点
|
||||
|
||||
| 角色 | 痛点 | 诉求 |
|
||||
|---|---|---|
|
||||
| 一线管家/生活顾问(学员) | 怕说错话激化矛盾;催费难开口;突发状况手足无措;缺可用内容素材 | 零压力"试错场" + 随时可用"内容库" |
|
||||
| 项目主管/经理(管理者) | 无法透视团队真实能力;培训效果难量化;缺针对性辅导工具 | 洞察团队的"透视镜" + 靶向辅导"工具箱" |
|
||||
| 集团 HR / 培训 / 品质部(运营者) | 优秀案例散落难沉淀;SOP 难统一贯彻;知识更新滞后 | 经验资产化"中央厨房" + 标准落地"高速公路" |
|
||||
| HR 负责人(需求方/买单人) | 选用育留全流程割裂、无数字化抓手 | 一体化人才全生命周期赋能平台 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 业务范围与边界
|
||||
|
||||
### 3.1 选用育留全生命周期(一期覆盖)
|
||||
|
||||
| 段 | 覆盖能力 | 一期状态 |
|
||||
|---|---|---|
|
||||
| **选**(招聘) | AI 面试出题、候选人现场作答、AI 打分、面试记录 | 一期新增(原方案没有) |
|
||||
| **用**(配置上岗) | 岗位 SOP 匹配、岗前/入职培训、上岗资格 | 一期 |
|
||||
| **育**(训练) | 三角色对练、每日一练、专项训练营、错题本、师徒、案例学习 | 一期核心(原陪练主体) |
|
||||
| **留**(保留发展) | 能力雷达图、认证等级、晋升/绩效关联、荣誉激励 | 一期建规则,挂钩推迟 |
|
||||
| **案例沉淀**(贯穿) | 语音上传 → AI 整理 → 筛选 → AI 对话视频 | 一期(视频用样片) |
|
||||
|
||||
### 3.2 明确移出一期范围(已决策)
|
||||
|
||||
- **内容营销中心**(原第七章朋友圈工坊):属营销/获客,与 HR 无关 → 一期砍除(D5)。
|
||||
- **独立语音 APP**(豆包式):愿景非交付物 → Demo 用 Web,APP 进二期(D6)。
|
||||
- **双图谱知识图谱**(Neo4j):冷启动成本高 → 一期先 RAG,图谱降二期(D4)。
|
||||
- **多项目类型**:一期只跑**住宅类** SOP;公建类、景区类只预留结构。
|
||||
|
||||
---
|
||||
|
||||
## 4. 业务需求详述
|
||||
|
||||
### 4.1 选 · 招聘与面试(一期新增)
|
||||
|
||||
- AI 依据应聘岗位自动出题,候选人现场(语音/文本)作答,AI 打分并生成面试记录。
|
||||
- 候选人为**未入职者**,在本系统本地建档(不在外部 HR/组织系统内),入职后与同步进来的员工主体挂钩。
|
||||
- **合规约束**:AI 招聘打分**保留人工复核**,只作辅助参考,防算法歧视(闸门 G2)。
|
||||
|
||||
### 4.2 用 · 上岗与培训
|
||||
|
||||
- 岗位与 SOP 匹配;岗前培训、入职培训任务可分派、可完成;上岗资格 gating。
|
||||
- SOP 按**大类/中类/小类/行业**多层分类,叠加**住宅/公建/景区**项目类型(详见第 5 章建模)。
|
||||
|
||||
### 4.3 育 · 场景实战对练(系统核心)
|
||||
|
||||
**4.3.1 三角色协同 AI 教练架构**
|
||||
- **AI 客户**:模拟有复杂背景、特定性格、实时情绪的真实业主,是对话对象。
|
||||
- **AI 教练**:全程观察,学员卡壳或重大流程偏差时**微提示引导**(非直接给答案)。
|
||||
- **AI 考官**:对话结束即基于全量数据,多维打分 + 建设性改进建议。
|
||||
|
||||
**4.3.2 AI 客户五维度人物模型**
|
||||
1. 基础属性(社会身份、人际关系、所处环境)
|
||||
2. 性格与风格(性格特征、语言指纹)
|
||||
3. 动机与目标(显性诉求 vs 隐性痛点、决策逻辑)
|
||||
4. 认知边界(懂什么/不懂什么、对物业的偏见)
|
||||
5. 动态状态(初始情绪、雷点/爽点、信任度动态曲线)
|
||||
|
||||
**4.3.3 多模态交互**
|
||||
- 语音对话(高准确率 ASR,**支持四川话/粤语等方言**)、文本对话、图像/视频上传(拍照报修等)、服务录像回放。
|
||||
|
||||
**4.3.4 全覆盖训练场景**
|
||||
- 投诉处理(漏水/噪音/宠物/邻里/公共设施)、费用催缴、服务推介(增值)、日常服务与突发应急(电梯困人/火警误报等)。
|
||||
|
||||
**4.3.5 即时多维反馈评分(五维)**
|
||||
- 合规与完整度、情感应变力、沟通有效性、营销敏感性、**导师润色版**(把不妥表述重写成更优话术做对比教学)。
|
||||
|
||||
### 4.4 育 · 日常训练中心
|
||||
|
||||
- **每日一练**:每天推 3 分钟微场景,语音作答,AI 秒评。
|
||||
- **专项突破包**:7–14 天专项训练营(如"催费攻心 7 天""投诉终结者 14 天")。
|
||||
- **智能错题本**:自动归集高频失误,归因"知识盲区"或"话术不当",推送修复练习。
|
||||
- **师徒演练**:师父指派案例,查阅徒弟与 AI 完整对话记录做靶向辅导。
|
||||
|
||||
### 4.5 留 · 能力画像与激励
|
||||
|
||||
**4.5.1 五维能力评估模型(权重)**
|
||||
|
||||
| 评估维度 | 权重 | 关键指标 |
|
||||
|---|---|---|
|
||||
| 任务完成度 | 40% | 问题解决有效性、工单闭环率、首解率、SOP 关键点执行率 |
|
||||
| 话术规范性 | 25% | 流程完整性、法规引用准确性、沟通合规、用语专业度 |
|
||||
| 情绪管理能力 | 20% | 共情、语速语气控制、业主情绪引导安抚有效性 |
|
||||
| 响应时效 | 10% | 首响时长、处理周期、跟进频率 |
|
||||
| 增值转化潜力 | 5% | 活动引导、产品推介时机与成功率 |
|
||||
|
||||
- 个性化学习路径("基础→进阶→高阶" + 能力九宫格),**动态难度调级**(连续高分自动升级复合高压场景)。
|
||||
- 管家端成就激励(积分/排行榜/荣誉勋章);管理驾驶舱(投入度、高频错误场景、一键指派强化包、线上数据与真实绩效关联)。
|
||||
- **合规约束**:AI 分数定位"辅助参考、人可否决",**不直接决定绩效/晋升**(闸门 G1)。
|
||||
|
||||
### 4.6 案例沉淀 pipeline(贯穿)
|
||||
|
||||
- 流程:项目负责人**语音上传**案例 → AI 转写 → 从大量案例(目标千级)**AI 筛选出有特色的少数** → 制作成 **AI 对话讲解视频** → 供全员学习(如早八点课堂)。
|
||||
- 节奏:每周每项目提交一个案例。
|
||||
- **一期**:流程跑通,视频用**预渲染样片**顶(数字人/视频生成慢且贵,不真跑)。
|
||||
|
||||
### 4.7 智慧知识中心
|
||||
|
||||
- **一期用 RAG**(若依内置),双图谱(技能图谱 + 知识图谱/Neo4j)降二期。
|
||||
- 静态知识库(收费标准/法规/应知应会/设备手册)+ 动态知识库(业主画像/服务历史)。
|
||||
- **情景案例库多维标签**:业务类型、紧急程度、业主画像、情绪状态、沟通渠道;所有案例**脱敏**后打标签。
|
||||
- **更新机制**:工单/会议记录自动回流(AI 听记转写提炼)、人工审核与共创(一线提交话术、专家终审、**署名入库**)、版本与质量管理(变更留痕、可回溯、防知识腐烂)。
|
||||
|
||||
---
|
||||
|
||||
## 5. 数据模型方向
|
||||
|
||||
### 5.1 原则
|
||||
|
||||
复用 Silverston《数据模型资源手册》卷 1 **HR 主干**,不发明表结构;通用主干优先、行业扩展后挂;主数据/事务/计量/治理分层建模。
|
||||
|
||||
### 5.2 选用育留 × 核心实体
|
||||
|
||||
| 段 | 核心实体(Silverston) | 落地对象 |
|
||||
|---|---|---|
|
||||
| 选 | `JOB APPLICATION`、`POSITION` | 招聘需求、职位、候选人、面试记录、offer |
|
||||
| 用 | `POSITION`、`EMPLOYMENT`、`PRODUCT CATEGORY` | 岗位-SOP 映射、上岗资格 |
|
||||
| 育 | `WORK EFFORT`、`ACTIVITY` | 训练/考核任务、对练记录、错题、学习路径 |
|
||||
| 留 | `SKILL`、`QUALIFICATION` | 能力评估、认证等级、晋升规则 |
|
||||
| 贯穿 | `PARTY` / `PARTY ROLE` | 主体与角色 |
|
||||
|
||||
**HR 主干已对齐《手册》卷1 第9章「人力资源模型」(v1.1 补充)**:经回溯卷1 权威实体(16 个:雇用/职位/职位职责/职位履行/报告关系/工资级别/支付历史/福利/工资册/求职申请/技能/资格/**雇员表现(绩效)**/雇用终止等),数据模型已在开发规格中补齐三张原缺 backbone 表——`performance_review`(雇员绩效,即"绩效关联"锚点)、`position_responsibility`(职位职责)、`employment_termination`(雇用终止)。并明确:
|
||||
- **薪酬/福利/工资册** 属手册 HR 章原生但**本系统一期不做**(非 HR 薪酬系统)。
|
||||
- **面试 AI 打分 / 三角色对练 / 课程学习 / 能力雷达图 / 认证规则** 为**本系统领域扩展**(手册无现成实体,合法自建)。
|
||||
- 详见《开发规格 TechSpec》附录 D。
|
||||
|
||||
### 5.3 三条关键建模决定
|
||||
|
||||
- **Party-Role 分离**:一个人依次/同时是候选人→新员工→学员→师父→考官,用 Party + Role,不为每种身份建表。
|
||||
- **SOP 用 Product-Category 层级 + Applicability 承载**:大类/中类/小类/行业 × 住宅/公建/景区。一期只填住宅类,其余预留。
|
||||
- **关系库 vs 向量库切分**:元数据(目录/分类/权限)落关系表,正文落向量索引(RAG)。
|
||||
|
||||
### 5.4 主数据同步边界(外部同步 vs 本地自有)
|
||||
|
||||
「复用采购系统用户体系」= 三件独立的事:① 认证/SSO ② 权限映射 ③ 组织人员数据同步。
|
||||
|
||||
| 实体 | 归属 | 读写 |
|
||||
|---|---|---|
|
||||
| PARTY / PERSON / ORGANIZATION / 组织树 | 外部同步 | 只读 |
|
||||
| POSITION / EMPLOYMENT / 任职 | 外部同步 | 只读 |
|
||||
| PARTY ROLE(学员/师父/教练/考官/审核员/管理员) | 本地自有 | 读写 |
|
||||
| 权限映射(外部岗位/组织 → 本地角色) | 本地自有 | 读写 |
|
||||
| SKILL / QUALIFICATION(能力/认证) | 本地自有 | 读写 |
|
||||
| JOB APPLICATION / 候选人 | 本地自有 | 读写 |
|
||||
| WORK EFFORT(训练/考核/案例记录) | 本地自有 | 读写 |
|
||||
|
||||
**硬约束**:本地只存外部 `party_id`,绝不复制姓名/部门;候选人未入职先本地建、入职后挂钩;调岗/离职用 `FROM DATE / THRU DATE` 有效期承接,不物理删除。**数据权限以「项目」为范围主体(D1)。**
|
||||
|
||||
---
|
||||
|
||||
## 6. 技术选型与架构
|
||||
|
||||
### 6.1 基座:若依(RuoYi)
|
||||
|
||||
前后端分离(Vue + Java / Spring Boot 4)、内置 RBAC + RAG 知识库 + 后台、社区成熟、无许可证风险、可与采购系统用户体系对齐。
|
||||
|
||||
### 6.2 为什么不是其它候选(留档)
|
||||
|
||||
| 候选 | 结论 | 一句话理由 |
|
||||
|---|---|---|
|
||||
| aifei | ✗ 不采用 | AI Coding 框架只优化"怎么写代码",不提供现成模块;84 star、文档不全、企业实现走 VIP 付费(与枪毙 PandaWiki 同款风险);违背若依决策与采购系统复用约束 |
|
||||
| PandaWiki | ✗ | 半开源、后续强制收费风险 |
|
||||
| JeecgBoot | ✗ | 代码生成集成度过高、二次修改难 |
|
||||
| Yuxi(玉溪) | 参考 | 仅二期借鉴其 Agent 能力,不做基座 |
|
||||
|
||||
### 6.3 架构
|
||||
|
||||
集中式部署 + 前后端分离(**非微服务**)。理由:2 人小团队、无高并发、微服务协作成本高。
|
||||
|
||||
### 6.4 必须自建(无任何框架可复用)
|
||||
|
||||
三角色状态机(AI 客户/教练/考官)、评分引擎(情感 + 语义 + SOP 关键点 + Rubric)、方言 ASR 接入 —— 这是一期真正的工程瓶颈。
|
||||
|
||||
### 6.5 AI 技术关键点
|
||||
|
||||
- 对话引擎:大模型 + 物业专属 Prompt + RAG,控幻觉、保合规。
|
||||
- 语音:高准确率低延迟 ASR(方言)+ 表现力 TTS;**方言走第三方现成接口**,只是费用问题。
|
||||
- 评分模型:情感计算 + 语义相似 + SOP 关键点识别多模型融合,可解释,非关键字匹配。
|
||||
- 大模型:**一期用公有大模型 API(D3)**,业主 PII 出境为硬约束(闸门 G3/G6)。
|
||||
|
||||
---
|
||||
|
||||
## 7. 集成与外部依赖
|
||||
|
||||
| # | 外部依赖 | 一期做法 |
|
||||
|---|---|---|
|
||||
| 1 | 组织/人员数据同步(采购系统) | 接口疑似与待批预算系统绑定;Demo 用静态快照兜底 |
|
||||
| 2 | 登录 / 身份认证(采购系统) | **一期本地账号(D2)**,SSO 留二期 |
|
||||
| 3 | 权限映射(外部岗位/组织→本地角色) | 本地建 |
|
||||
| 4 | 方言 ASR / TTS(第三方) | 选 1 家跑通 |
|
||||
| 5 | 大模型 API | 公有云 API 先行 |
|
||||
| 6 | 数字人/视频生成 | 预渲染样片 |
|
||||
| 7 | 企业微信/钉钉/工单系统 | **一期只列接口、不实现(D8)** |
|
||||
|
||||
---
|
||||
|
||||
## 8. 关键决策记录(D1–D9,全部已定)
|
||||
|
||||
| # | 决策 | 结果 |
|
||||
|---|---|---|
|
||||
| D1 | 系统/数据归属 | 归属项目(以项目为 owner 与数据范围主体) |
|
||||
| D2 | 登录方式 | 本地账号(SSO 留二期) |
|
||||
| D3 | 大模型 | 公有大模型 API(出境合规入闸门) |
|
||||
| D4 | 知识图谱 | 一期先 RAG,图谱降二期 |
|
||||
| D5 | 内容营销中心 | 一期砍除 |
|
||||
| D6 | 独立 APP | 用 Web,APP 进二期 |
|
||||
| D7 | 文档口径 | 综合统一成新的一版(即本 BRD) |
|
||||
| D8 | 企微/钉钉/工单集成 | 只列接口、不实现 |
|
||||
| D9 | 一期验收标准 | 最小可验收承诺(见第 10 章;一致率 70%、试点 1–2 项目) |
|
||||
|
||||
---
|
||||
|
||||
## 9. 一期范围与 MVP 切割线
|
||||
|
||||
### 9.1 🔴 Demo 必做(阻塞项)
|
||||
|
||||
英雄路径(1–2 条端到端跑通)、住宅类内容冷启动(SOP+案例+Rubric)、组织人员快照、案例视频样片、本地登录、大模型接入、方言语音 1 条路径、演示脚本、前端壳全可点开。
|
||||
|
||||
### 9.2 关键路径与止损
|
||||
|
||||
- 关键路径:**内容 → 英雄路径 → 联调**;内容不齐一切空转。
|
||||
- 外部依赖任一没接通,立即切兜底(mock/录屏/样片),不卡主线。
|
||||
- 落后就**保 1 条**英雄路径 + 壳 + 脚本,砍第 2 条。
|
||||
|
||||
---
|
||||
|
||||
## 10. 一期验收承诺(最小可判定)
|
||||
|
||||
> 原则:验收只写"是/否"或"可测量";大 ROI 数字归入愿景层,不作验收依据。
|
||||
|
||||
### 10.1 L0 · Demo 验收(过大老板)
|
||||
|
||||
L0-1 全功能点 Web 可点开 · L0-2 至少 1 条英雄路径端到端跑通 · L0-3 住宅类 SOP 可检索且 AI 问答能引用 · L0-4 案例语音上传→AI 整理可演示 · L0-5 脚本无致命卡点且有录屏兜底。
|
||||
|
||||
### 10.2 L1 · 一期验收
|
||||
|
||||
- **A 功能闭环(是/否)**:选(面试打分闭环)/ 用(SOP 匹配+培训任务)/ 育(≥1 类对练场景端到端 + 每日一练)/ 留(雷达图 + 认证规则可配)/ 案例(整理筛选跑通)。
|
||||
- **B 数据内容**:住宅类 SOP ≥ 5 个核心流程;案例库 ≥ 20 条(脱敏);Rubric 可配置;组织人员导入 + 项目级数据范围权限。
|
||||
- **C 技术质量**:集中式部署稳定;语音单轮响应 ≤ 5 秒;**AI 与人工打分分档一致率 ≥ 70%**;RAG 可用回答率 ≥ 80%;不承诺高并发与多项目类型。
|
||||
- **D 试点效果(过程指标)**:**试点 1–2 个住宅项目**、≥ 20 名员工;人均 ≥ 10 次对练;完训率 ≥ 80%;满意度 ≥ 4/5。
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施路线图与排期
|
||||
|
||||
### 11.1 阶段路线(原方案)
|
||||
|
||||
- 一阶段(1–2 月):知识库/案例库架构 + 核心高频场景对练模型 + 基础评估算法 + 基础 API 集成。
|
||||
- 二阶段(3–4 月):扩场景 + 个性化路径 + 小范围试点。
|
||||
- 三阶段(5–6 月+):全面推广 + 长效运营共创 + 管理驾驶舱 + 阶段性 ROI 评估。
|
||||
|
||||
### 11.2 周末施工排期(2 人时间盒)
|
||||
|
||||
- **2026-07-03 周五 基础日**:若依骨架 + 本地登录 + 大模型接通 + ASR 接通(A);SOP/案例/Rubric 定稿 + 快照造数 + 功能点清单(B)。收工验收:能登录、能调大模型、ASR 出字、素材齐。
|
||||
- **2026-07-04 周六 主攻日**:2 条英雄路径后端(A);前端壳批量搭 + 视频样片 + 脚本初稿(B)。收工验收:路径接口跑通、壳可点开、样片就绪。
|
||||
- **2026-07-05 周日 联调彩排**:前后端联调精修 + 录屏兜底 + 彩排 2 遍。收工验收:端到端无致命卡点、有兜底、彩排通过。**2026-07-05 不加新功能。**
|
||||
|
||||
---
|
||||
|
||||
## 12. 风险 · 生产前闸门 · 组织风险
|
||||
|
||||
### 12.1 生产前闸门(现在不做,上线前必过)
|
||||
|
||||
| # | 闸门项 |
|
||||
|---|---|
|
||||
| G1 | AI 打分定位"辅助参考、人可否决",不由 AI 决定绩效/晋升 |
|
||||
| G2 | AI 招聘打分保留人工复核,防算法歧视 |
|
||||
| G3 | 数据合规:业主 PII + 员工数据 脱敏 + 审计 + 数据权限 |
|
||||
| G4 | 员工接受度:试点期配激励 + 沟通,化解"被 AI 监考"抵触 |
|
||||
| G5 | 情绪疏导树洞:兑现"不留痕、不进训练集"隐私边界 |
|
||||
| G6 | 运营成本:LLM/ASR/视频 月度调用成本设上限与降级策略 |
|
||||
|
||||
### 12.2 组织与变革风险
|
||||
|
||||
AI 分挂钩个人利益的公平性/申诉、员工对被 AI 监考的抵触(尤其资深/年长者)、内容贡献激励与知识产权署名、系统/数据归属(已定:归属项目)。
|
||||
|
||||
---
|
||||
|
||||
## 13. 后续待办与未决项
|
||||
|
||||
- **集成负责人指派**:第 7 章 6 个外部依赖需落实到人。
|
||||
- **F2 派生**:数据权限以项目为范围主体落地(源自 D1)。
|
||||
- **F3 派生**:公有大模型已定,业主 PII 出境评估升为一期必须评估项(源自 D3)。
|
||||
- 二期:知识图谱、独立 APP、玉溪 Agent 化(即时锦囊/语音咨询)、多项目类型、企微/钉钉深度集成、实时同步。
|
||||
|
||||
---
|
||||
|
||||
## 附录 A:34 条完整查漏登记(可追溯)
|
||||
|
||||
- **第一层(Demo 阻塞)**:陪练英雄路径 · 内容冷启动 · 组织 API 未就绪 · 案例视频过重 · 登录/认证 · 大模型+出境合规 · 方言厂商 · 演示脚本 · UI 壳工作量
|
||||
- **第二层(数据模型地基)**:HR 主干抽全 · 关系/向量切分 · 招聘域空白 · SOP 多层分类 · Rubric 数据结构 · 版本管理 · ID/主键策略 · 数据权限字段 · 训练事务+学习路径 · 知识图谱去留
|
||||
- **第三层(生产前闸门+组织风险)**:AI 分挂钩绩效 · AI 招聘合规 · 业主/员工数据合规 · 运营成本模型 · 员工接受度 · 内容贡献激励+署名 · 情绪树洞隐私 · 系统/数据归属
|
||||
- **第四层(范围边界+交付一致性)**:营销中心去留 · 独立 APP · 老文档一致性 · 企微/钉钉/工单集成 · 一期验收标准 · 玉溪 Agent 落点 · 认证/晋升/绩效规则引擎
|
||||
|
||||
## 附录 B:配套文档
|
||||
|
||||
- 《AI 人力资源系统一期 Demo 作战清单》:执行层作战图(决策/MVP/排期/闸门/验收),与本 BRD 配套,本 BRD 为需求基准、作战清单为执行细则。
|
||||
|
||||
## 附录 C:一句话结论
|
||||
|
||||
> 本项目是以"选用育留"为主线的物业行业 AI 人力资源系统;若依做基座、核心三角色对练与评分自建、数据模型抬 Silverston HR 主干、组织人员从外部同步;一期以住宅类 + 单条英雄路径 Demo 起步,合规与挂钩留生产前闸门。当前头号风险是"2 人 + 死线"下的范围失控,守住 MVP 切割线即可闭环。
|
||||
@@ -0,0 +1,441 @@
|
||||
# 物业行业 AI 人力资源系统 · 开发规格(Tech Spec)
|
||||
|
||||
> 版本:v1.3 ｜ 日期:2026-07-02
|
||||
> 定位:**开发层唯一依据**。回答"怎么建"——工程结构、数据表、API 契约、Prompt 规格、集成适配。
|
||||
> v1.1 变更:数据模型对齐《手册》卷1 第9章 HR 主干,补 3 张 backbone 表(职位职责/雇员绩效/雇用终止),新增附录 D 对照表。
|
||||
> v1.2 变更:第 6 章按 Codex 设计评审重写——状态机补异常/终止态、COACH_CHECK 工程化、评分引擎分层(P0 单 LLM / P1 融合)、澄清"单场对练评分 vs 跨期能力画像"两套评分、Prompt 加固 + RAG 硬约束、新增 6.5 P0/P1 切分。
|
||||
> v1.3 变更:Qdrant 作为一期向量索引层落地;SOP 知识库检索升级为 MySQL Fulltext + Qdrant RRF 融合,MySQL/MinIO 仍是事实源。
|
||||
> 配套:需求见[《物业AI人力资源系统业务需求文档BRD》](物业AI人力资源系统业务需求文档BRD.md);执行计划见[《AI人力资源系统一期Demo作战清单》](AI人力资源系统一期Demo作战清单.md)。
|
||||
> **优先级图例**:`P0`=2026-07-05 Demo 必需 · `P1`=一期必需 · `P2`=二期/推迟。
|
||||
> 决策基线:若依基座 / 集中式前后端分离 / 本地登录 / 公有大模型API / 一期RAG / 组织人员外部同步(Demo用快照) / 数据范围以项目为主体。
|
||||
|
||||
---
|
||||
|
||||
## 1. 技术栈与工程结构
|
||||
|
||||
### 1.1 技术栈
|
||||
|
||||
| 层 | 选型 |
|
||||
|---|---|
|
||||
| 后端 | Java + Spring Boot 4(若依 RuoYi 后端) |
|
||||
| 前端 | Vue(若依前端,前后端分离) |
|
||||
| 数据库 | MySQL(主数据/事务)+ MinIO(原始文件)+ Qdrant(向量索引) |
|
||||
| 检索 | MySQL Fulltext + Qdrant 混合 RAG(一期);知识图谱 Neo4j(P2) |
|
||||
| 大模型 | 公有大模型 API(对话/出题/评分/案例整理) |
|
||||
| 语音 | 第三方 ASR(方言:川/粤)+ TTS |
|
||||
| 部署 | 集中式,前后端分离,单实例起步(无微服务、无高并发承诺) |
|
||||
|
||||
### 1.2 工程结构(若依约定)
|
||||
|
||||
```
|
||||
backend/
|
||||
ruoyi-admin/ # 启动入口
|
||||
ruoyi-system/ # 复用:用户/角色/菜单/数据权限
|
||||
hr-recruit/ # 选:招聘面试
|
||||
hr-onboard/ # 用:上岗/SOP/培训
|
||||
hr-train/ # 育:对练/每日一练/训练营/错题/师徒
|
||||
hr-competency/ # 留:能力评估/认证/Rubric/激励
|
||||
hr-knowledge/ # 知识库/案例库/RAG
|
||||
hr-ai/ # AI 适配层:大模型/ASR/TTS/Prompt 模板/评分引擎
|
||||
hr-sync/ # 组织人员同步适配层
|
||||
frontend/
|
||||
src/views/{recruit,onboard,train,competency,knowledge,ai-practice,dashboard,admin}
|
||||
```
|
||||
|
||||
- 复用若依 `ruoyi-system` 的用户/角色/菜单/数据权限;业务模块按选用育留 + 支撑拆分。
|
||||
- AI 能力集中在 `hr-ai`,对上层暴露统一接口(对话/评分/转写/生成),便于切换厂商与兜底。
|
||||
- 可借助已有的 "codex 若依组件生成 skill" 批量生成 CRUD 骨架。
|
||||
|
||||
---
|
||||
|
||||
## 2. 系统模块总览
|
||||
|
||||
| 模块 | 归属 | 一期优先级 |
|
||||
|---|---|---|
|
||||
| M1 主数据与同步 | 支撑 | P0 |
|
||||
| M2 权限与数据范围 | 支撑 | P0 |
|
||||
| M3 招聘面试(选) | 业务 | P0(英雄路径A) |
|
||||
| M4 上岗/SOP/培训(用) | 业务 | P1 |
|
||||
| M5 对练/训练(育) | 业务 | P0(英雄路径核心) |
|
||||
| M6 能力/认证/激励(留) | 业务 | P1 |
|
||||
| M7 知识库/案例库(贯穿) | 业务 | P0(RAG+案例A) |
|
||||
| M8 治理/版本/审核 | 支撑 | P1 |
|
||||
| M9 AI 适配层 | 支撑 | P0 |
|
||||
| M10 管理驾驶舱/报表 | 分析 | P1 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 数据模型
|
||||
|
||||
> 命名:表 snake_case;主键 `id` bigint;外部主体统一引用 `ext_party_id`;审计字段 `create_by/create_time/update_by/update_time/del_flag`(若依标准)省略未列。有效期用 `from_date/thru_date`。
|
||||
|
||||
### 3.1 M1 主数据与同步(P0)
|
||||
|
||||
| 表 | 关键字段 | 归属 | 优先级 |
|
||||
|---|---|---|---|
|
||||
| `sync_person`(人员快照) | id, ext_party_id(唯一), name, phone, org_unit_id, position_code, status, sync_batch_id | 外部同步只读 | P0 |
|
||||
| `sync_org_unit`(组织树) | id, ext_org_id(唯一), parent_ext_org_id, org_name, org_type(集团/公司/项目), project_type(住宅/公建/景区) | 外部同步只读 | P0 |
|
||||
| `sync_batch`(同步批次) | id, source, mode(full/incr), started_at, finished_at, row_count, status | 本地 | P0 |
|
||||
| `employment_termination`(雇用终止,对齐卷1「雇用终止」;留存/流失分析) | id, ext_party_id, term_date, term_reason, from_sync | 外部同步/本地 | P1 |
|
||||
|
||||
- **候选人不进 sync_person**,见 3.3 `candidate`。
|
||||
- 离职/调岗优先用 `sync_person.status` + 有效期承接;`employment_termination` 承载显式离职历史。
|
||||
|
||||
### 3.2 M2 权限与数据范围(P0)
|
||||
|
||||
| 表 | 关键字段 | 优先级 |
|
||||
|---|---|---|
|
||||
| `party_role`(本地角色) | id, ext_party_id, role_code(学员/师父/教练/考官/审核员/管理员/HR/面试官), scope_project_ext_org_id, from_date, thru_date | P0 |
|
||||
| `role_perm_mapping`(岗位/组织→角色映射) | id, match_type(position/org), match_value, role_code, project_scope | P0 |
|
||||
| `sys_role/sys_menu`(若依内置) | 复用 | P0 |
|
||||
|
||||
- **数据范围以项目为主体**:业务表统一带 `project_ext_org_id`,数据权限按 `party_role.scope_project_ext_org_id` 过滤(套若依数据权限)。
|
||||
|
||||
### 3.3 M3 招聘面试(选)—— 英雄路径 A
|
||||
|
||||
| 表 | 关键字段 | 优先级 |
|
||||
|---|---|---|
|
||||
| `candidate`(候选人) | id, name, phone, apply_position_code, project_ext_org_id, source, status, hired_ext_party_id(入职后挂钩) | P0 |
|
||||
| `job_requisition`(招聘需求) | id, position_code, project_ext_org_id, headcount, jd_text, status | P1 |
|
||||
| `interview_session`(面试记录) | id, candidate_id, position_code, mode(voice/text), total_score, ai_summary, status, started_at | P0 |
|
||||
| `interview_question`(面试题) | id, session_id, seq, question_text, gen_source(ai/manual), reference_point | P0 |
|
||||
| `interview_answer`(作答+打分) | id, question_id, answer_text, answer_audio_url, score, dimension_json, ai_comment | P0 |
|
||||
|
||||
### 3.4 M4 上岗 / SOP / 培训(用)
|
||||
|
||||
| 表 | 关键字段 | 优先级 |
|
||||
|---|---|---|
|
||||
| `position_responsibility`(职位职责,对齐卷1「职位职责」;SOP 挂载点) | id, position_code, responsibility_text, sop_id | P1 |
|
||||
| `sop_category`(SOP 多层分类) | id, parent_id, level(大类/中类/小类/行业), name, code | P1(结构 P0 预留) |
|
||||
| `sop`(SOP 主表) | id, category_id, title, content, version, status, project_type | P1 |
|
||||
| `sop_applicability`(适用范围) | id, sop_id, project_type, industry, org_scope | P1 |
|
||||
| `onboard_task`(培训任务) | id, ext_party_id, sop_id/course_id, type(岗前/入职), status, assign_by | P1 |
|
||||
| `course` / `course_enrollment` | id, title, type, ...; id, course_id, ext_party_id, progress, status | P1 |
|
||||
| `qualification_gate`(上岗资格) | id, ext_party_id, position_code, cert_id, passed, valid_thru | P1 |
|
||||
|
||||
### 3.5 M5 对练 / 训练(育)—— 核心
|
||||
|
||||
| 表 | 关键字段 | 优先级 |
|
||||
|---|---|---|
|
||||
| `practice_scenario`(对练场景/AI客户人设) | id, scenario_type(投诉/催费/推介/应急), title, persona_json(五维人设), difficulty, sop_ref, rubric_id, project_type | P0 |
|
||||
| `practice_session`(对练记录) | id, ext_party_id, scenario_id, mode(voice/text), total_score, trust_curve_json, status, started_at | P0 |
|
||||
| `practice_turn`(逐轮对话) | id, session_id, seq, role(customer/trainee/coach), text, audio_url, emotion, coach_hint | P0 |
|
||||
| `practice_score`(五维评分) | id, session_id, dim_compliance, dim_emotion, dim_communication, dim_marketing, mentor_rewrite, ai_comment | P0 |
|
||||
| `daily_drill`(每日一练) | id, ext_party_id, scenario_id, date, score, status | P1 |
|
||||
| `training_camp`(专项训练营) | id, title, theme, days, scenario_ids | P1 |
|
||||
| `mistake_book`(错题本) | id, ext_party_id, session_id, cause(知识盲区/话术不当), fix_scenario_id | P1 |
|
||||
| `mentor_assignment`(师徒指派) | id, mentor_ext_party_id, apprentice_ext_party_id, scenario_id, status | P1 |
|
||||
|
||||
### 3.6 M6 能力 / 认证 / Rubric / 激励(留)
|
||||
|
||||
| 表 | 关键字段 | 优先级 |
|
||||
|---|---|---|
|
||||
| `rubric`(评分标准) | id, name, scenario_type, status, version | P0(单条内置) |
|
||||
| `rubric_dimension`(维度+权重) | id, rubric_id, dim_code, dim_name, weight, key_indicators | P0 |
|
||||
| `performance_review`(雇员绩效,对齐卷1「雇员表现」;绩效关联锚点) | id, ext_party_id, period, review_type(月度/季度考核), source(training/manual), overall_score, dimension_json, reviewer | P1 |
|
||||
| `competency_assessment`(能力评估/雷达图,绩效的可视化扩展) | id, ext_party_id, period, dim_scores_json, radar_snapshot | P1 |
|
||||
| `competency_dim_config`(五维权重配置) | id, dim_code(任务完成/话术规范/情绪管理/响应时效/增值转化), weight | P1 |
|
||||
| `certification` / `cert_rule`(认证/规则) | id, ext_party_id, level(初/中/高), ...; id, level, condition_json | P1 |
|
||||
| `incentive_point` / `badge`(积分/勋章) | id, ext_party_id, points, source; id, code, name | P1 |
|
||||
|
||||
### 3.7 M7 知识库 / 案例库(贯穿)—— 含英雄路径 B
|
||||
|
||||
| 表 | 关键字段 | 优先级 |
|
||||
|---|---|---|
|
||||
| `aihr_knowledge_info`(知识库元数据) | id, tenant_id, name, description, retrieve_limit, enable_hybrid, system_prompt | P0 已落 |
|
||||
| `aihr_knowledge_attach`(知识库附件/文档) | id, knowledge_id, doc_id, name, type, status | P0 已落，支持同名上传替换 |
|
||||
| `aihr_knowledge_fragment`(知识片段) | id, knowledge_id, doc_id, idx, content, embedding_json, embedding_model, embedding_time, FULLTEXT(content) | P0 已落，txt/md/PDF/Word/Excel/PPT 可解析入库，可写 embedding；Qdrant 只存向量索引和最小 payload |
|
||||
| `case`(案例主表,脱敏) | id, title, raw_audio_url, transcript, ai_summary, curated(是否入选), project_ext_org_id, status | P0 |
|
||||
| `case_tag`(多维标签) | id, case_id, dim(业务类型/紧急/业主画像/情绪/渠道), value | P1 |
|
||||
| `case_video`(案例视频/样片) | id, case_id, video_url, is_sample | P1(Demo样片) |
|
||||
|
||||
### 3.8 M8/M9 治理 · 版本 · 集成日志
|
||||
|
||||
| 表 | 关键字段 | 优先级 |
|
||||
|---|---|---|
|
||||
| `review_task`(审核任务) | id, target_type(case/knowledge/话术), target_id, reviewer, status, decision | P1 |
|
||||
| `content_version`(版本留痕) | id, target_type, target_id, version, diff, change_by | P1 |
|
||||
| `llm_call_log`(大模型调用/成本) | id, module, model, tokens_in, tokens_out, cost, latency_ms, created_at | P1(成本闸门G6) |
|
||||
| `asr_config`(语音配置) | id, vendor, dialect, endpoint, enabled | P0 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 页面与路由清单(前端)
|
||||
|
||||
> `P0` 页面需真跑通或壳可点开;英雄路径页面必须真跑通。
|
||||
|
||||
| 路由 | 页面 | 优先级 |
|
||||
|---|---|---|
|
||||
| `/login` | 本地登录 | P0 |
|
||||
| `/index` | 首页/管理驾驶舱(壳) | P0壳 |
|
||||
| `/recruit/interview` | **AI 面试(英雄路径A:出题→作答→打分)** | P0跑通 |
|
||||
| `/recruit/candidates` | 候选人列表 | P1 |
|
||||
| `/train/practice` | **三角色对练(英雄路径核心)** | P0跑通 |
|
||||
| `/train/daily` | 每日一练 | P1 |
|
||||
| `/train/camp` | 专项训练营 | P1 |
|
||||
| `/train/mistakes` | 错题本 | P1 |
|
||||
| `/knowledge/sop` | SOP 库(住宅类检索→引用→训练题) | P0跑通 |
|
||||
| `/knowledge/cases` | **案例库(英雄路径B:语音上传→整理)** | P0跑通 |
|
||||
| `/knowledge/processing` | 资料处理(解析状态、处理链路、浏览器/服务端导入) | P1已提前落地 |
|
||||
| `/system/model` | 模型配置(供应商 Key/Base URL/模型启停/测试) | P1已提前落地 |
|
||||
| `/competency/radar` | 能力雷达图 | P1 |
|
||||
| `/competency/cert` | 认证/激励 | P1 |
|
||||
| `/onboard/tasks` | 上岗培训任务 | P1 |
|
||||
| `/admin/*` | 权限/角色/同步/Rubric 配置 | P0壳 |
|
||||
|
||||
---
|
||||
|
||||
## 5. API 契约
|
||||
|
||||
> 统一响应信封:`{ code, msg, data }`(若依风格)。以下英雄路径详写,其余按 CRUD 惯例。
|
||||
> 当前本地 Demo 先用 API + fallback 跑通 `/recruit/interview`、`/train/practice`、`/knowledge/cases`、`/knowledge/sop` 页面流;SOP 知识库已接 `aihr_knowledge_fragment` MySQL Fulltext 检索、Qdrant 向量召回、txt/md/PDF/Word/Excel/PPT 上传解析和 embedding 写入。
|
||||
> API 对接顺序见 `docs/API_INTEGRATION.md`;面试、对练、案例仍以 seed service 为主，SOP/模型配置已建最小表。
|
||||
|
||||
### 5.1 英雄路径 A:AI 面试(P0)
|
||||
|
||||
```
|
||||
POST /api/recruit/interview/start
|
||||
req: { candidateId, positionCode, mode }
|
||||
resp: { sessionId, questions:[{questionId, seq, questionText}] } // AI 依岗位出题
|
||||
|
||||
POST /api/recruit/interview/answer
|
||||
req: { questionId, answerText? , answerAudioUrl? } // 语音先经 5.4 转写
|
||||
resp: { score, dimensions:{...}, aiComment }
|
||||
|
||||
POST /api/recruit/interview/finish
|
||||
req: { sessionId }
|
||||
resp: { totalScore, aiSummary, records:[...] }
|
||||
```
|
||||
|
||||
### 5.2 英雄路径核心:三角色对练(P0)
|
||||
|
||||
```
|
||||
POST /api/train/practice/start
|
||||
req: { extPartyId, scenarioId, mode }
|
||||
resp: { sessionId, opening:{ customerText, customerAudioUrl }, persona } // AI客户开场
|
||||
|
||||
POST /api/train/practice/turn
|
||||
req: { sessionId, traineeText? , traineeAudioUrl? }
|
||||
resp: { customerText, customerAudioUrl, emotion, trust, coachHint? } // 客户回应+教练微提示
|
||||
|
||||
POST /api/train/practice/finish
|
||||
req: { sessionId }
|
||||
resp: { score:{ compliance, emotion, communication, marketing }, mentorRewrite, aiComment, trustCurve } // 考官评分
|
||||
```
|
||||
|
||||
### 5.3 英雄路径 B:案例语音上传→整理(P0)
|
||||
|
||||
```
|
||||
POST /api/knowledge/case/upload req: { audioFile, projectExtOrgId } resp: { caseId, transcript }
|
||||
POST /api/knowledge/case/organize req: { caseId } resp: { aiSummary, tags[] }
|
||||
POST /api/knowledge/case/curate req: { criteria, limit } resp: { selectedCaseIds[] } // 从多案例筛选
|
||||
```
|
||||
|
||||
### 5.4 AI 适配层(P0)
|
||||
|
||||
```
|
||||
POST /api/ai/chat req:{ system, messages, model? } resp:{ text, usage }
|
||||
POST /api/ai/asr req:{ audioUrl, dialect } resp:{ text }
|
||||
POST /api/ai/tts req:{ text, voice } resp:{ audioUrl }
|
||||
POST /api/ai/score req:{ rubricId, dialogue } resp:{ dimensions, comment }
|
||||
```
|
||||
|
||||
### 5.5 支撑接口
|
||||
|
||||
- 同步:`POST /api/sync/pull`(拉取组织人员,Demo 可读快照文件)
|
||||
- 知识检索(RAG):`POST /api/knowledge/search` → `{ queryText, category, answer, reference, docs[], snippets[], training[], records[] }`
|
||||
- 知识上传解析:`POST /api/knowledge/doc/upload` → `multipart/form-data { file, category }`，支持 `.txt/.md/.markdown/.pdf/.doc/.docx/.xls/.xlsx/.ppt/.pptx`、100MB 内；先落 `sys_oss` 并绑定 `aihr_knowledge_attach.oss_id`，返回 `{ docId, ossId, fileName, category, fragments, snippets[] }`
|
||||
- 服务端目录导入:`POST /api/knowledge/doc/import-local-task` → `{ directory, category, limit }`，只允许读取 `AIHR_IMPORT_ROOT` / `aihr.import.root` 下的相对目录，写入后台导入任务并逐文件复用上传解析链路；`GET /api/knowledge/doc/import-tasks` 返回最近任务进度；`POST /api/knowledge/doc/import-local` 保留同步调试。
|
||||
- 资料处理状态:`GET /api/knowledge/processing/overview` → 聚合附件状态、片段数、向量化状态、分类、处理链路和最近事件。
|
||||
- 片段向量化:同一上传接口在 `category=vector` 模型配置可用时调用 OpenAI-compatible `/embeddings`，写入 `embedding_json/embedding_model/embedding_time`，并尽力 upsert 到 Qdrant；未配置或 Qdrant 不可用不阻塞上传。
|
||||
- 混合检索:`POST /api/knowledge/search` 先查 MySQL Fulltext，同时在 vector 模型和 Qdrant 可用时生成 query embedding 走 Qdrant，最后按 RRF 融合并回 MySQL hydrate 片段；Qdrant 不存正文事实源。
|
||||
- Rubric 配置:`/api/competency/rubric/**` CRUD
|
||||
|
||||
---
|
||||
|
||||
## 6. 核心自建组件规格(无框架可复用,最关键)
|
||||
|
||||
> **本章 v1.2 已按 Codex 设计评审重写**:核心原则——P0 做「确定性会话编排 + 单 LLM 结构化评估」,P1 再上多模型融合与后台配置。三角色对外表现为 AI客户/AI教练/AI考官,内部先做成**一个后端编排器**,少写代码跑通演示闭环。
|
||||
|
||||
### 6.1 三角色对练状态机
|
||||
|
||||
**状态(含异常/终止,不只 happy path)**:
|
||||
```
|
||||
INIT → WAITING_INPUT → PROCESSING → WAITING_INPUT(loop) → FINISHED
|
||||
↘ CANCELED / EXPIRED / FAILED
|
||||
```
|
||||
- `finish_reason ∈ {completed, user_exit, max_turns, timeout, error}`(结束原因用枚举,不为每种情况新增状态类)。
|
||||
- **固定 `max_turns = 4~6`**;满足任一即结束:用户点"结束并评分"、达最大轮次、客户诉求解决、超时。前端必须有"结束并评分"按钮。
|
||||
|
||||
**每轮 turn 生成顺序(固定,不可乱)**:
|
||||
```
|
||||
收学员输入 → COACH_CHECK(卡壳/偏差判定) → 更新 trust/emotion → 生成客户下一句 + coachHint → 写 practice_turn
|
||||
```
|
||||
> ⚠️ **每轮只做轻量 checker + 客户回应,不跑完整评分**;评分只在 `/finish` 一次性做(见 6.3)。
|
||||
|
||||
**COACH_CHECK 工程化判定**:
|
||||
- **卡壳 = 规则判定**(P0,不上模型):空输入 / 超时 / 过短句 / 重复"不知道·嗯" / ASR 失败。
|
||||
- **流程偏差 = LLM checker**:输出 `{ needHint, reasonCode, missingSopIds, hint }`。P0 不上语义相似模型。
|
||||
|
||||
**信任度闭环**:每轮只更新一次 `trust = clamp(trust + delta, 0, 1)`,`delta ∈ [-0.15, 0.15]` 来自 checker JSON。**传给客户 prompt 的是"低/中/高信任"档位,不传裸浮点**(更稳)。
|
||||
|
||||
### 6.2 AI 客户人设(persona_json)
|
||||
|
||||
> 在五维基础上,**补场景收口与信息边界字段**,否则 AI 客户会自曝隐性动机或替管家解决问题。
|
||||
|
||||
```json
|
||||
{
|
||||
"basic": { "identity":"独居退休教师", "relation":"子女在国外", "environment":"楼上噪音困扰" },
|
||||
"style": { "trait":"急躁/温和", "language_fingerprint":"说话慢、爱重复、爱反问" },
|
||||
"motive": { "explicit":"咨询停车费", "hidden":"投诉邻居乱停、试探物业态度", "logic":"" },
|
||||
"cognition":{ "knows":[], "unknowns":[], "bias":"认为物业只收钱不办事" },
|
||||
"dynamic": { "init_emotion":"烦躁", "triggers":{"anger":"被敷衍","pleased":"被重视"}, "trust_init":0.3 },
|
||||
|
||||
"opening": "开场第一句业主话",
|
||||
"success_condition": "本场诉求被满足的判定",
|
||||
"forbidden_reveal": ["隐性动机不得主动自曝", "信任<中 不透露真实诉求"],
|
||||
"escalation_triggers":["被敷衍→升级愤怒"],
|
||||
"allowed_facts": ["仅可引用的事实/SOP要点ID"],
|
||||
"max_turns": 6
|
||||
}
|
||||
```
|
||||
|
||||
### 6.3 评分引擎(分层:P0 单 LLM / P1 融合)
|
||||
|
||||
**⚠️ 澄清两套评分(此前易被当成矛盾)**:
|
||||
- **单场对练评分(每场一次)**:4 维 —— 合规与完整度、情感应变力、沟通有效性、营销敏感性;外加**导师润色版**(不是评分维度,是话术重写对比)。
|
||||
- **能力画像(跨期加权,BRD 4.5)**:5 维加权 —— 任务完成度40% / 话术规范性25% / 情绪管理20% / 响应时效10% / 增值转化5%。**由多场对练评分聚合而来,不是同一层。**
|
||||
|
||||
**P0(2026-07-05 Demo):单 LLM 考官一次性出结构化分**
|
||||
- 输入 `dialogue + rubric + sop_points + persona`,输出固定 JSON;**不做多模型融合**。
|
||||
- **防漂移**:固定模型 + `temperature=0` + 固定 `prompt_version`;首次评分后**缓存 `practice_score`,刷新不重算**;分数用**档位锚点 60/75/90** 减少小数漂移。
|
||||
- **可验收的可解释**:JSON 必带证据 —— `evidence_turn_ids`、`hit_sop_point_ids`、`missed_sop_point_ids`、`rewrite_before/after`;无证据的理由不展示。
|
||||
- Rubric:P0 用**一条内置 seed JSON**;后台 CRUD 只做壳。
|
||||
|
||||
**P1(一期):再拆多模型融合**
|
||||
- SOP 关键点覆盖检测 + 语义相似 + 情感/语音特征融合;Rubric 后台可配置 + 版本 + 启停;一致率校准集 + 人工评审流程。
|
||||
|
||||
**一致率验收口径**:`≥70%` 指**分档一致**(非原始分一致),档位建议 `<60 / 60–74 / 75–89 / ≥90`,用 ≥20 段样本对人工基准评估——**是一期目标,不是 2026-07-05 Demo 目标**;2026-07-05 只验端到端 + 结构化输出。
|
||||
|
||||
### 6.4 Prompt 规格(实际入 `hr-ai` 模板库,均需后端兜底)
|
||||
|
||||
- **AI 客户**(system prompt 强约束 + 2 个 few-shot):`你只扮演业主本人,只输出一句业主的话。禁止:提及系统/人设/评分/SOP;替管家给解决方案;主动自曝隐性诉求(仅当信任度达"高"或被直接问到才可透露)。保持 language_fingerprint。当前情绪={emotion},信任={低/中/高}。`
|
||||
- **AI 教练**(后端强制):`对照 SOP 关键步骤 {sop_points} 与学员本轮 {trainee_text}。仅当卡壳或漏关键步骤时,返回一句 ≤20 字的方向性提示(如"先安抚,再确认诉求"),不得给具体答案;否则返回空。` → **后端 schema 校验:超 20 字重试一次,再失败用固定兜底提示。**
|
||||
- **AI 考官**(模型原生 structured output):字段固定 `{ dimensions[], total, mentorRewrite, summary, risks, evidence_turn_ids, hit_sop_point_ids, missed_sop_point_ids, unsupported_claims }`;**禁 markdown 代码块**;解析失败只重试一次,再返回兜底分。
|
||||
- **面试出题**:`应聘岗位 {position},生成 {n} 道结构化面试题,含考察点 reference_point。`
|
||||
- **案例整理**:`将转写 {transcript} 整理为 背景/处理/结果/亮点;脱敏业主个人信息;打多维标签(业务类型/紧急/业主画像/情绪/渠道)。`
|
||||
- **RAG 硬约束(控幻觉)**:prompt 传 `sop_context`(带 ID);**未命中的政策/金额/时限不得编造,只能说"需核实"**;考官只按给定 `sop_points` 判分,并输出 `unsupported_claims`。
|
||||
|
||||
### 6.5 三角色 P0 / P1 最小切分
|
||||
|
||||
- **P0(2026-07-05 Demo 必须)**:1 场景 × 1 人设 × 1 套 SOP × 1 套 rubric;**文本端到端先跑通**,语音作为外层 ASR/TTS,失败降级文本;`/start /turn /finish` 三接口闭环;每轮轻量 checker + 客户回应;`/finish` 单 LLM 出结构化分;固定 max_turns + 手动结束 + 评分缓存展示。
|
||||
- **P1(一期)**:Rubric 后台配置与版本;SOP 覆盖/语义/情绪融合;一致率校准集 + 人工评审;多场景/多 persona/动态难度/错题本/能力画像沉淀;LLM 调用日志/成本/prompt 版本/失败重试。
|
||||
|
||||
---
|
||||
|
||||
## 7. 集成适配层
|
||||
|
||||
| 集成 | 接口/做法 | Demo 兜底 | 优先级 |
|
||||
|---|---|---|---|
|
||||
| 组织人员同步 | `hr-sync` 拉取采购系统 API → 写 `sync_*` | 读静态快照文件 | P0 |
|
||||
| 登录/SSO | 一期本地账号(若依) | — | P0(SSO=P2) |
|
||||
| 权限映射 | `role_perm_mapping` 规则引擎 | 手工配置 | P0 |
|
||||
| 大模型 | `hr-ai/chat` 封装公有 API | — | P0 |
|
||||
| ASR/TTS | `hr-ai/asr,tts` 封装第三方(方言) | 1 家 1 条路径 | P0 |
|
||||
| 视频生成 | 案例视频 | 预渲染样片 | P1(样片P0) |
|
||||
| 企微/钉钉/工单 | 只留接口占位 | 不实现 | P2 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 权限与数据范围
|
||||
|
||||
- 认证:若依本地账号(一期);SSO 预留 `hr-sync` 对接点(P2)。
|
||||
- 授权:`role_perm_mapping` 把外部岗位/组织映射到本地 `role_code`。
|
||||
- **数据范围以项目为主体**:所有业务查询套若依数据权限,按 `party_role.scope_project_ext_org_id` 过滤;主管只见本项目数据。
|
||||
|
||||
---
|
||||
|
||||
## 9. 非功能与部署
|
||||
|
||||
- 部署:集中式,前后端分离,单实例起步;**不承诺高并发**(明确)。
|
||||
- 性能目标:语音对练单轮响应 ≤ 5 秒(ASR+LLM+评分)。
|
||||
- 合规(生产前闸门,非一期功能):业主 PII + 员工数据 脱敏/审计;大模型出境评估(G3/G6);AI 分辅助参考不决定绩效/招聘(G1/G2)。
|
||||
- 成本:`llm_call_log` 记录用量,设月度上限与降级策略(G6)。
|
||||
|
||||
---
|
||||
|
||||
## 10. 实现优先级与里程碑(对齐 MVP 切割线 / 施工单)
|
||||
|
||||
### 10.1 P0(2026-07-05 Demo 必需)
|
||||
|
||||
- 工程骨架 + 本地登录 + 数据权限(M1/M2)
|
||||
- AI 适配层:chat / asr / tts / score(M9)
|
||||
- 英雄路径至少 1 条真跑通:**A 面试打分** 或 **对练** 或 **B 案例整理**(建议至少含对练或面试)
|
||||
- 住宅类 SOP 入库 + RAG 检索(M7 P0 表)
|
||||
- 案例语音上传→整理(可与对练二选一精做)
|
||||
- 全功能点前端壳可点开
|
||||
- 组织人员快照 + Rubric 单条内置
|
||||
|
||||
### 10.2 P1(一期)
|
||||
|
||||
- M4 上岗/SOP 多层分类完整、M6 能力雷达+认证+激励、M5 每日一练/训练营/错题/师徒、M7 标签/视频、M8 审核/版本、M10 驾驶舱、`llm_call_log` 成本。
|
||||
|
||||
### 10.3 P2(二期)
|
||||
|
||||
- 知识图谱(Neo4j)、独立 APP、玉溪 Agent 化、企微/钉钉深度集成、SSO、实时同步、多项目类型(公建/景区)。
|
||||
|
||||
---
|
||||
|
||||
## 附录:表 → 模块 → 优先级速查
|
||||
|
||||
| 优先级 | 表 |
|
||||
|---|---|
|
||||
| P0 | sync_person, sync_org_unit, sync_batch, party_role, role_perm_mapping, candidate, interview_session, interview_question, interview_answer, practice_scenario, practice_session, practice_turn, practice_score, rubric, rubric_dimension, knowledge_doc, knowledge_chunk, case, asr_config |
|
||||
| P1 | job_requisition, sop_category, sop, sop_applicability, onboard_task, course, course_enrollment, qualification_gate, daily_drill, training_camp, mistake_book, mentor_assignment, competency_assessment, competency_dim_config, certification, cert_rule, incentive_point, badge, case_tag, case_video, review_task, content_version, llm_call_log |
|
||||
| P2 | 知识图谱相关、SSO、企微/钉钉集成表 |
|
||||
|
||||
> 说明:字段清单为落地起点,DDL(主外键、唯一约束、索引、导入顺序)可据此一键生成;三角色/评分/Prompt 为核心自建,严格按第 6 章实现。
|
||||
|
||||
---
|
||||
|
||||
## 附录 D:卷1 第9章 HR 主干实体对照与补全
|
||||
|
||||
> 目的:把本 TechSpec 数据模型对齐《数据模型资源手册》卷1 第9章「人力资源模型」权威实体,诚实标注哪些是手册原生 backbone、哪些是本系统领域扩展、哪些手册有但一期不做。**依据:卷1笔记 §4.8 + 附录权威字典 v7 实测。**
|
||||
|
||||
### D.1 卷1 第9章 HR 权威实体全谱系(16 个 · 手册原文)
|
||||
|
||||
雇用 EMPLOYMENT · 职位 POSITION · 职位类型 POSITION TYPE · 职位职责 POSITION RESPONSIBILITY · 职位履行情况 POSITION FULFILLMENT · 职位状态 · 招聘组织 · 报告关系 · 工资级别 PAY GRADE · 支付历史 PAY HISTORY · 福利 BENEFIT · 工资册信息 PAYROLL · 求职申请 JOB APPLICATION · 雇员技能与资格 SKILL/QUALIFICATION · **雇员表现(绩效)PERFORMANCE REVIEW** · 雇用终止 TERMINATION
|
||||
|
||||
> 附录 v7 字典佐证(属性条数):EMPLOYMENT 102、POSITION 60、EMPLOYEE 60、BENEFIT 49、SKILL 28、TERMINATION 20、SALARY 8、PAY GRADE 6、QUALIFICATION 5、TRAINING 4、PAY HISTORY 4、PAYROLL 2。
|
||||
|
||||
### D.2 对照:手册实体 → TechSpec 表
|
||||
|
||||
| 卷1 HR 实体 | TechSpec 表 | 状态 |
|
||||
|---|---|---|
|
||||
| 雇用 / 职位履行 | `sync_person`(任职,外部同步) | ✅ 已覆盖 |
|
||||
| 职位 / 职位类型 | `sync_person.position_code` + `sop_category` | ✅ |
|
||||
| 职位职责 | `position_responsibility` | ➕ **本次补** |
|
||||
| 报告关系 | `sync_org_unit`(组织树) | ✅ 同步 |
|
||||
| 求职申请 JOB APPLICATION | `candidate` / `job_requisition` | ✅(命名已对齐) |
|
||||
| 雇员技能 SKILL | `rubric`/`skill`/`competency_*` | ✅ |
|
||||
| 资格 QUALIFICATION | `certification` / `cert_rule` | ✅ |
|
||||
| **雇员表现(绩效)** | `performance_review` | ➕ **本次补(原缺!)** |
|
||||
| 雇用终止 TERMINATION | `employment_termination` | ➕ **本次补** |
|
||||
| 工资级别/支付历史/福利/工资册 | — | ⛔ **一期不做**(薪酬非本系统职责) |
|
||||
|
||||
### D.3 本系统的领域扩展(手册无,属 AI 陪练特有)
|
||||
|
||||
> **诚实更正**:此前口头曾说"面试记录/offer/课程/学习记录/考核/测评雷达图/认证 卷1 本来就有"——**部分说过头了**。手册 HR 章真正有的是:求职申请、技能、资格、**雇员表现(绩效)**、雇用终止。以下属**本系统领域扩展**,手册并无现成实体、也不应有,需自建:
|
||||
|
||||
- 面试 AI 出题/作答/打分(`interview_question`/`interview_answer`)——JOB APPLICATION 只到"申请",无 AI 面试评分
|
||||
- 三角色对练 / 五维评分(`practice_*`)
|
||||
- 课程 / 学习记录 / 每日一练 / 训练营 / 错题(`course`/`daily_drill`/…)——手册无 e-learning 模型
|
||||
- 能力雷达图(`competency_assessment`)——「雇员表现」的可视化扩展
|
||||
- 认证等级规则(`cert_rule`)——QUALIFICATION 的规则化扩展
|
||||
|
||||
### D.4 结论
|
||||
|
||||
- **补齐动作(v1.1 已落):** 新增 `performance_review`(绩效)、`position_responsibility`(职位职责)、`employment_termination`(雇用终止)三张 backbone 表;`candidate`/`skill`/`certification` 明确对齐手册 JOB APPLICATION / SKILL / QUALIFICATION。
|
||||
- **绩效关联**(BRD 4.5 / 闸门 G1)由此有了正式锚点:训练/考核结果写入 `performance_review`,再挂钩(辅助参考,人可否决)。
|
||||
- 薪酬/福利/工资册明确划出一期(本系统不承担 HR 薪酬)。
|
||||
- 领域扩展表(对练/评分/课程/AI 面试)为**合法自建**,不因手册未收录而缺失。
|
||||
Reference in New Issue
Block a user