Files
wecom_it_smart_desk/docs/01-产品文档/07-知识库/PRD-REQ-知识-001-知识库闭环-v1.0.md
T
Simon facc04aa65 chore: docs 结构整改 + compose 双目录对齐(合并重建提交)
本提交为 .git 对象库损坏后的重建提交,内容等价于原先三个本地提交
(5e2fd4c2 / 57a53c98 / 5d7e1873)的累积结果,未做任何额外改动。

一、docs 结构整改(整改 #14)
根因:重构时新结构为 untracked 文件,执行 git stash(未带 -u)未纳入,
随后 git reset 拉回 HEAD 旧 tracked 树,导致旧树复活、新旧两棵目录
树并存于 docs/,共 791 文件、双分类体系冲突。

修复动作:
- b2 同名异主题文件改名迁移保全 9 个
- C 类 39 个孤立文件按主题正确归类
- A/B1 类 222 个重复文件删除(新结构已有内容副本)
- 9 个旧独有空目录删除
- 270 处内部引用按 verified 映射改写
- 整改记录 #14 登记于 04-运维文档/部署运维

结果:docs 791 → 569 文件,顶层仅规范 8 类 + 治理文件,单树恢复。
残留:约 20 处指向从未存在文件的陈旧死链,归入独立文档卫生任务。

二、compose 双目录对齐(消除踩坑 A)
- docker-compose.yml:nginx 前端挂载全部由根目录 frontend-*/dist
  改为 src/frontend-*/dist(h5 / agent / admin / terminal)
- docker-compose.dev.yml:dev 服务 build context 与卷同步改 src/
- 效果:本地 docker compose up 不再把根目录 stale dist 挂回,
  与线上一致,分叉隐患消除(已 docker compose config 校验通过)

防复发铁律:
- 重构须提交;仓库修复须 git stash -u 或先 commit
- 新结构须 git add 并提交,避免再次 untracked 复活
- H5 改动只动 src/frontend-h5/,禁改根目录遗留 frontend-*/
2026-08-07 22:31:32 +08:00

232 lines
6.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# PRD - 知识库闭环
> **REQ编号**: REQ-知识-001
> **版本**: v1.1
> **优先级**: P0
> **阶段**: 近期(1-2个月)
> **作者**: 宋献
> **日期**: 2026-07-19
> **状态**: 待开发
> **原型**: `原型-REQ-知识-001-知识库闭环-v1.0.html`
> **关联**: REQ-知识-002 已合并(训练师审批作为核心环节)
---
## 一、问题陈述
**用户问题**
- 知识库 P2-01 标注"已完成",但实际是桩实现(stub),API 未挂载
- 员工提问时 AI 无法引用真实知识库内容
- 知识建议→训练师审批→入库→AI引用的全流程未打通
**业务目标**
- 实现知识库全闭环:知识建议 → 审批 → 入库 → AI 引用
- 知识库回答准确率提升至 85% 以上
---
## 二、需求范围
### 2.1 核心功能
| 功能 | 描述 |
|------|------|
| 知识建议API挂载 | 将 P2-01 的知识建议接口从桩实现改为真实调用 |
| 知识入库 | 知识通过审批后写入 Neo4j 图数据库 |
| 知识引用 | AI 回答时从知识库检索相关内容并引用 |
| 审批流打通 | 训练师在坐席端可审批知识建议 |
### 2.2 非目标
- 不包含知识库的自动学习/自训练能力
- 不包含知识库的版本管理
- 不包含知识库的分类/标签管理(后续迭代)
---
## 三、用户故事
| 角色 | 用户故事 | 验收标准 |
|------|----------|---------|
| 员工 | 我提问后,AI 能引用知识库中的相关内容 | 知识库有答案的问题,AI 回答时显示引用来源 |
| 坐席 | 我可以提交知识建议供审批 | 提交后进入待审批列表 |
| 训练师 | 我可以审批知识建议 | 通过/拒绝后知识入库或打回 |
| 管理员 | 我可以查看知识库覆盖情况 | 管理后台能看到知识节点数量、更新日志 |
---
## 四、功能详情
### 4.1 知识建议 API 挂载
**现状**`knowledge_iteration_router` 被注释,未挂载真实 API
**改造**
1. 取消注释 `knowledge_iteration_router`
2. 挂载真实知识检索 API
3. 配置 Neo4j 图存储连接
### 4.2 知识入库流程
```
用户提问 → AI分析 → 知识建议 → 训练师审批 → 写入Neo4j → AI可引用
```
| 步骤 | 动作 | 责任人 |
|------|------|--------|
| 1 | 知识建议生成 | AI服务 |
| 2 | 入库申请提交 | 坐席/管理员 |
| 3 | 审批(通过/拒绝) | 训练师 |
| 4 | 写入Neo4j | 后端服务 |
| 5 | 索引更新 | 后端服务 |
### 4.3 审批界面
- 坐席端增加「知识审批」Tab
- 显示待审批列表:知识标题、摘要、申请人、提交时间
- 支持:通过、拒绝、修改后通过
---
## 五、指标设计
| 指标 | 目标 | 测量方式 |
|------|------|---------|
| 知识库引用率 | ≥ 60% | AI回答中引用知识库的比例 |
| 知识库准确率 | ≥ 85% | 知识库答案被标记为正确的比例 |
| 审批平均耗时 | ≤ 24h | 知识从提交到审批完成的平均时间 |
---
## 六、技术依赖
| 依赖项 | 说明 |
|--------|------|
| Neo4j 图数据库 | 知识存储 |
| Dify API | 知识检索 |
| RAGFlow | 知识向量化 |
---
## 七、API 接口设计
| 接口 | 方法 | 说明 |
|------|------|------|
| `/api/knowledge/suggest` | POST | 知识建议(AI分析对话后生成) |
| `/api/knowledge/submit` | POST | 提交知识入库申请 |
| `/api/knowledge/approve` | POST | 审批知识(通过/拒绝) |
| `/api/knowledge/approve/list` | GET | 待审批列表 |
| `/api/knowledge/search` | GET | 知识库检索 |
| `/api/knowledge/graph` | GET | 知识图谱可视化 |
### 7.1 POST /api/knowledge/submit
**请求体**
```json
{
"title": "VPN连接失败排查步骤",
"content": "1. 检查VPN客户端版本...\n2. 检查网络环境...",
"category": "网络问题",
"tags": ["VPN", "网络", "连接"],
"source_conversation_id": "conv_xxx"
}
```
**响应**
```json
{
"success": true,
"knowledge_id": "kn_001",
"status": "pending_approval"
}
```
### 7.2 POST /api/knowledge/approve
**请求体**
```json
{
"knowledge_id": "kn_001",
"action": "approve", // "approve" | "reject" | "modify_approve"
"comment": "内容准确,可以入库",
"modified_content": null // 当 action 为 modify_approve 时使用
}
```
---
## 八、数据模型
### 8.1 Knowledge 表
```sql
CREATE TABLE knowledge_base (
id SERIAL PRIMARY KEY,
knowledge_id VARCHAR(64) UNIQUE NOT NULL,
title VARCHAR(255) NOT NULL,
content TEXT NOT NULL,
category VARCHAR(50),
tags JSONB DEFAULT '[]',
status VARCHAR(20) DEFAULT 'draft', -- draft / pending / approved / rejected
source_conversation_id VARCHAR(64),
created_by VARCHAR(64),
created_at TIMESTAMP DEFAULT NOW(),
approved_by VARCHAR(64),
approved_at TIMESTAMP,
neo4j_node_id VARCHAR(64) -- 写入Neo4j后的节点ID
);
```
### 8.2 Knowledge Approval History 表
```sql
CREATE TABLE knowledge_approval_history (
id SERIAL PRIMARY KEY,
knowledge_id VARCHAR(64) NOT NULL,
action VARCHAR(20) NOT NULL, -- submit / approve / reject / modify
comment TEXT,
operator_id VARCHAR(64) NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);
```
---
## 九、技术架构
### 9.1 知识流动
```
用户提问 → Dify分析 → 知识建议 → 坐席提交 → 训练师审批 → Neo4j入库 → AI检索引用
↓ ↓ ↓ ↓ ↓
AI回复 建议内容 待审批 审批记录 图数据库
```
### 9.2 核心改造点
1. **取消注释** `knowledge_iteration_router`,挂载真实 API
2. **Neo4j 集成**:配置图数据库连接,实现知识写入和检索
3. **审批工作流**:坐席端增加知识审批 Tab,训练师操作
4. **知识检索**AI 回答时调用 RAGFlow/Dify 检索知识库
---
## 十、验收标准
| 场景 | 验收条件 |
|------|----------|
| 知识提交 | 坐席提交知识 → 进入待审批列表 → 训练师可见 |
| 知识审批-通过 | 训练师点击通过 → 状态变为已批准 → 写入Neo4j |
| 知识审批-拒绝 | 训练师点击拒绝 → 状态变为已拒绝 → 申请人收到通知 |
| AI引用 | 员工提问 → AI回答时显示「知识库引用」来源卡片 |
| 知识检索 | 管理后台可搜索知识库内容 |
| 审批历史 | 知识详情页显示完整审批操作历史 |
---
## 十一、关联文档
- 技术方案: `02-技术文档/技术架构/增量设计-知识库迭代与痛点缓解-20260711.md`
- 前置需求: REQ-AI-001 复杂场景与统一路由
- UI设计: `原型-REQ-知识-001-知识库闭环-v1.0.html`