# IT智能服务台 - AI回复来源标识 PRD

**版本**：v1.0
**日期**：2026-07-20
**状态**：已评审
**评审日期**：2026-07-20
**作者**：许清楚
**子系统**：03-AI服务
**模块**：来源标识

---

## 一、文档变更记录

| 版本 | 日期 | 变更说明 |
|------|------|----------|
| v1.0 | 2026-07-20 | 初始版本 |

---

## 二、背景与目标

### 2.1 背景

当前系统 AI 回复来源不透明，用户和坐席无法感知回复来自哪个路由（本地快判/图谱/Dify/业务路由等），影响信任度和问题追溯。

### 2.2 目标

| # | 目标 | 衡量指标 |
|---|------|----------|
| G1 | **来源透明** - 用户能感知回复来自哪个路由 | 来源标识显示覆盖率 = 100% |
| G2 | **可追溯** - 坐席能追溯每条回复的来源 | 来源记录可追溯率 = 100% |
| G3 | **统一管理** - 来源标识统一配置，易维护 | 标识变更无需代码修改 |

---

## 三、用户故事

| # | 角色 | 用户故事 |
|---|------|----------|
| US-1 | 员工 | **As a** 员工, **I want** 能看到 AI 回复的来源标识, **so that** 我知道回复的可靠性来源 |
| US-2 | 坐席 | **As a** 坐席, **I want** 能在会话记录中追溯每条 AI 回复的来源, **so that** 在需要人工介入时快速定位问题来源 |
| US-3 | 运维 | **As a** 运维人员, **I want** 统一配置来源标识的图标和映射关系, **so that** 调整标识时无需修改代码 |

---

## 四、来源类型定义

### 4.1 来源类型

| 来源Key | 来源名称 | 图标 | 说明 |
|--------|----------|------|------|
| `byod` | BYOD拦截 | 🔒 | 员工自带设备策略拦截 |
| `rule` | 本地快判 | ⚡️ | 打招呼/呼叫人工等规则匹配 |
| `vision` | 图片增强 | 🖼️ | Vision多模态理解 |
| `graph` | Neo4j图谱 | 🕸️ | 知识图谱匹配命中 |
| `dify` | Dify推理 | 🤖 | Dify主推理链路 |
| `routing` | 业务路由 | 📋 | 非IT问题路由到业务负责人 |
| `assets` | 资产推荐 | 💻 | IT资产管理推荐 |
| `fallback` | 降级回复 | ⚠️ | 所有路由均未命中时的兜底回复 |

### 4.2 来源标识配置

```python
# 来源标识配置
REPLY_SOURCE_MARKERS = {
    "byod": "🔒",       # BYOD拦截
    "rule": "⚡️",      # 本地快判（打招呼/呼叫人工）
    "vision": "🖼️",     # 图片增强
    "graph": "🕸️",      # Neo4j图谱
    "dify": "🤖",       # Dify主推理
    "routing": "📋",     # 业务路由
    "assets": "💻",      # 资产推荐
    "fallback": "⚠️",    # 降级回复
}
```

---

## 五、实现方案

### 5.1 方案对比

| 方案 | 实现方式 | 优点 | 缺点 |
|------|----------|------|------|
| 方案A | 回复内容末尾嵌入标识 | 简单直接，实现成本低 | 可能被用户复制，影响体验 |
| 方案B | persist函数统一追加 | 统一管理，原始内容纯净，便于数据分析 | WS推送和DB存储都会追加，需注意区分 |

**推荐：方案B** - 统一在 persist 函数追加标识，便于集中管理和配置调整。

### 5.2 方案B详细设计

#### 5.2.1 数据结构

```python
# 消息表新增字段
class Message:
    id: str
    conversation_id: str
    content: str              # 原始内容（不含标识）
    reply_source: List[str]   # 来源列表，可叠加
    created_at: datetime
```

#### 5.2.2 处理流程

```
AI回复生成
    ↓
确定来源（rule/graph/dify/routing/...）
    ↓
persist函数统一追加标识
    ↓
  ├── WS推送：content + 标识
  └── DB存储：content + reply_source字段
```

#### 5.2.3 标识追加规则

- **单来源**：直接追加对应图标，如 `⚡️`
- **多来源**：按优先级顺序叠加，如 `📋💻`（业务路由 + 资产推荐）
- **来源优先级**：`rule` > `byod` > `vision` > `graph` > `dify` > `routing` > `assets` > `fallback`

### 5.3 前端展示

#### 5.3.1 H5员工端

```
┌─────────────────────────────────┐
│ 用户消息                         │
└─────────────────────────────────┘

┌─────────────────────────────────┐
│ AI回复内容...                   │
│ 🕸️                              │  ← 来源标识
└─────────────────────────────────┘
```

#### 5.3.2 坐席工作台

```
┌─────────────────────────────────┐
│ 来源：🕸️ Neo4j图谱              │  ← 详细信息
└─────────────────────────────────┘
```

---

## 六、非目标

| # | 明确不做 |
|---|----------|
| N1 | 不修改各路由模块的返回逻辑，仅在 persist 层统一处理 |
| N2 | 不在消息气泡内显示详细来源文字（坐席端可查看详情） |
| N3 | 不支持前端自定义图标（统一配置管理） |

---

## 七、指标与验收

| # | 指标 | 目标值 | 验收方式 |
|---|------|--------|----------|
| AC1 | 来源标识显示覆盖率 | 100% | 每条AI回复均有标识 |
| AC2 | 来源记录可追溯率 | 100% | DB中reply_source字段完整 |
| AC3 | 标识配置可维护性 | 调整无需代码修改 | 配置文件变更即可 |

---

## 八、关联文档

| 文档 | 说明 |
|------|------|
| `PRD-REQ-AI-001-复杂场景与统一路由-v1.1.md` | 路由层设计 |
| `PRD-REQ-AI-002-置信度门控-v1.0.md` | 置信度门控 |
| `PRD-REQ-AI-003-多模态视觉理解-v1.0.md` | Vision设计 |
| `技术方案-REQ-AI-004-AI回复来源标识-v1.0.md` | 技术实现方案 |

---

## 九、风险与依赖

| 风险 | 影响 | 缓解措施 |
|------|------|----------|
| R1：现有路由未返回来源标识 | 功能不完整 | 审查所有路由模块，确保返回reply_source |
| R2：多来源叠加显示混乱 | 用户体验差 | 严格按优先级排序，限制最多3个 |
| R3：WS推送和DB存储不一致 | 数据分析困难 | 统一在persist层处理 |

**依赖**：
- D01：各路由模块需返回reply_source字段
- D02：前端消息组件需支持显示标识

---

## 十、里程碑

| 阶段 | 任务 | 预计时间 |
|------|------|----------|
| M1 | 技术方案评审 | 1天 |
| M2 | 后端实现（persist层改造） | 2天 |
| M3 | 前端展示（H5+坐席端） | 2天 |
| M4 | 联调测试 | 1天 |
| M5 | 上线 | 1天 |

---

## 十一、待确认问题

| # | 问题 | 建议 | 优先级 |
|---|------|------|--------|
| Q1 | 多来源叠加时排序规则 | 按优先级排列 | P1 |
| Q2 | 降级回复是否固定显示fallback标识 | 是 | P2 |
| Q3 | 历史消息是否需要补充标识 | 否，仅新消息 | P2 |