prop-ai-hr/docs/legacy/物业AI陪练系统一期建设实施方案.md

# 物业管家与生活顾问 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成败的真正瓶颈。