# DCR Triage Agent — 产品需求文档 (PRD)

> **版本**: v0.5  
> **作者**: Yu Rou He  
> **日期**: 2026-04-03  
> **状态**: 设计完善阶段（融合 PM 调研 + 历史 DCR 数据分析）  
> **产品类型**: Internal PM Productivity Agent

---

## 1. 项目整体定位 (What & Why)

### 什么是 DCR

**DCR = Design Change Request（设计变更请求）**。这是 Microsoft Teams 中客户发起功能请求、设计变更或增强提案的正式机制——不是 Bug 或现有功能缺陷。

- **SLA 目标**: 从提交到解决 **< 30 天**
- **IcM 团队**: `MICROSOFTTEAMSSUPPORT\TeamsDCR`（team ID 108657）
- **监控**: DCR 是 Tenant Health 项目中的受监控信号；Red/Deep Red 状态会触发管理层升级
- **上报级别**: DCR SLA 违规已被上报至 **Product Day** 和 **Commercial MBR**，并为受影响的租户创建了 Get-to-Green 计划

### 要解决的核心问题

Teams PM 每周需处理大量来自 IcM、Teams、Support 等碎片化渠道的 DCR，每条 DCR 都要经历信息聚合 → 查重 → 分类 → 路由 → 回复的完整链路，**认知负担极重**。与此同时，DCR 积压严重——大量工单**超出 30 天 SLA**，部分甚至**滞留超过 100 天**，已多次被上报至 Product Day 和 Commercial MBR，触发 Get-to-Green 行动计划。

### 项目目标

> 让 Agent 承担 **"主动提醒 + 信息聚合 + 初步判断 + 建议草稿"** 的角色，PM 只需审阅确认。

**核心设计原则**：
1. **PM 是最终决策者** — Agent 只建议，不裁决
2. **显式确认** — 所有操作建议必须经 PM 明确确认才执行
3. **可解释性** — 每个判断附带推理过程和引用来源
4. **渐进信任** — Shadow Mode 起步，逐步放开自动化程度
5. **安全边界** — S500/ACE/合规/敏感场景自动标记为 PM 必审

---

## 2. 问题陈述 (Problem Statement)

### 2.1 现状痛点

> 来源: PM 调研+ 历史 DCR 数据分析+ Athena DCR Report + Tenant Health E2E Triage Process Wiki

| # | 痛点 | 影响 |
|---|------|------|
| P1 | **30 天 SLA 大面积违规** | 被上报至 Product Day 和 Commercial MBR；需要 Get-to-Green 计划 |
| P2 | 通知被淹没（Notification Blindness） | DCR 通知埋在高频 Teams @mentions 中，PM 有时 100+ 天后才发现 |
| P3 | IcM 自动分配不准确 | PRISM AI 频繁将 DCR 路由到错误的 PM，无便捷的拒绝/转交机制 |
| P4 | 上下文重建负担重 | PM 必须跨 IcM、Teams、邮件、群聊等多个系统读取长历史 |
| P5 | 信息分散在多个系统 | 查找信息耗时，容易遗漏上下文 |
| P6 | 难以判断是否是重复请求 | 缺乏高效的历史 DCR 比对手段 |
| P7 | 写回复需要查阅多份文档 | 首次回复出稿成本高 |
| P8 | 跨团队协作成本高 | 沟通效率低，容易信息断层 |
| P9 | 升级判断依赖个人经验 | 标准不统一，关键 DCR 可能被延误 |
| P10 | DCR Bounce | DCR 在团队间转来转去无人解决（数据显示复杂 DCR 在 3-5 个 PM 间流转） |
| P11 | 缺少优先级框架 | S500 vs 小租户没有标准化的决策规则 |

### 2.2 DCR 流程现状

#### 外部客户 DCR 流程（经 PRISM AI）

```
Support 提交 DCR → IcM 创建（TeamsDCR queue）→ MoreInfo Queue（填 BIS, 3天SLA）
  → PRISM AI 分类 + 分配 PM → PM 分诊 → Accept/Reject/Investigate → 关闭
```

**BIS（Business Impact Statement）** 是关键输入——包含客户名称、受影响用户数、业务影响说明、紧急程度、替代方案。BIS 质量直接影响分诊效率。

#### 内部 Ship Room DCR 流程（FY24+）

创建 Epic/Feature (State=Proposed) → 填写影响评估表 → Ship Room 审批 → 标签更新

#### DCR 结果标签

| 标签 | 含义 |
|-----|------|
| `dcraccepted` | 接受 |
| `dcrrejected` | 拒绝 |
| `DCRNotConsidered` | 不考虑 |
| `dcrinvestigate` | 需进一步调查 |
| `FeatureItemLinked` | 已关联 Feature |
| `PMEngaged` | PM 已介入 |
| `NeedCustomerInput` | 等待客户信息（超时自动关闭） |

### 2.3 典型场景举例

**场景 A — IcM #697474974**：
- [S500] Teams Recap 许可证提示 DCR，从 2025-10 创建至今 ACTIVE，在 Support → PM → Feature Owner 之间流转超过 5 个月

**场景 B — ADO #3974650**（来自历史数据）：
- S500 客户请求转录下载权限控制
- 经过 4 个 PM（Idil Ates → Weizhong Xue/Melissa Ma → Bryan Nyce → Harin Lee），17 条评论，历时数月
- → Agent 可在进入时建议正确 PM 路由，避免 bounce

**场景 C — ADO #3931621**（升级模式）：
- 无障碍问题，iConectados 11 万用户
- 4+ 月无人分诊，外部支持升级："Case is +4 months old… employees with low vision are increasingly unhappy"
- → Agent 应在 30/60/90 天时主动告警

---

## 3. 目标用户 (Target Users)

| 角色 | 使用场景 |
|------|----------|
| **Teams PMs** | 日常 DCR 分诊、回复、升级决策 |
| **GPM (Group PM)** | 跨功能区域的 DCR 路由决策 |

**非目标用户**: Support Engineer（上游来源）、普通开发者、最终业务使用者

---

## 4. 核心能力 (Core Capabilities)

### 输入 (Inputs)

| 输入项 | 说明 | 来源 |
|--------|------|------|
| DCR / IcM 事件详情 | 事件完整原始数据 | IcM MCP |
| BIS (Business Impact Statement) | 客户名称、受影响用户数、业务影响、紧急程度、替代方案 | IcM MoreInfo 表单 |
| 客户分层 | S500 / S400 / OED / Premier / 无 | 标题前缀 + BIS |
| 功能区域 | Messaging / Recording / Forms / Meetings / Copilot 等 | PRISM AI 分类 |
| 标签与关联历史 | IcM 标签、DCR outcome 标签、历史相似事件 | ADO + IcM |
| 云环境 | Commercial / GCC / GCCHigh / DoD | IcM / BIS |

### 输出 (Outputs)

| 输出项 | 说明 |
|--------|------|
| **分诊摘要** | 简洁自然语言总结，含 BIS 要点 |
| **分类标签** | 功能区域 + DCR 类型 + 建议 Outcome + 分诊模式(1-7) + 置信度 + 推理过程 |
| **重复分组** | 与历史 DCR 匹配结果 + 来源引用 |
| **建议回复** | 按分诊模式生成回复草稿 + 引用链接 |
| **升级建议** | auto-close / pm-review / escalate + 判断理由 |
| **PM 路由建议** | 基于功能区域和 GPM 映射建议正确 PM |
| **SLA 状态** | 剩余天数 / 已超期天数 |
| **安全边界标记** | 是否触发 NO-GO 规则 |

### 数据源 (Data Sources)

| 数据源 | 优先级 | 说明 |
|--------|--------|------|
| IcM 记录 + BIS 内容 | P0 | 当前事件详情、客户影响声明 |
| ADO 工作项 + 评论 | P0 | 历史 DCR 记录、PM 分诊理由（**核心训练信号**） |
| ADO / Bluebird Wiki | P1 | 流程文档、DCR 流程定义 |
| 内部产品文档 | P1 | 设计规范、产品路线图、Feature Flag 文档 |
| PM 已审批回复 | P1 | 可复用的标准回复模板 |
| 客户元数据 | P1 | S500 客户列表、租户信息 |

### 4.1 主动 DCR 感知 + SLA 监控

Agent 在新 DCR 进入时：
1. **即时通知** PM（通过 Teams），附带结构化摘要（BIS 要点、客户分层、功能区域）
2. 如果 BIS 未填或信息不足，**自动提示需要补充的字段**
3. **SLA 倒计时** — 跟踪 DCR 年龄，在接近/超过 30 天 SLA 时标记警告

### 4.2 DCR 自动分类 (Classification)

基于 108+ 条历史数据建立的分类体系：

**DCR 类型**: NewFeature / Enhancement / AdminControl / ComplianceGap

**建议 Outcome**: ACCEPTED / REJECTED / NOT_CONSIDERED / INVESTIGATE / REDIRECTED / REVISIT

**额外维度**:
- **功能区域**: Forms/Polls, Recording, Meetings, Devices, Video, Recap 等
- **客户分层**: S500 > S400 > OED > Premier > 无
- **影响范围**: 单功能 / 跨功能 / 跨团队
- **紧急程度**: 低 / 中 / 高
- **云敏感度**: GCC/GCCHigh/DoD 需要不同处理

### 4.3 分诊模式匹配 (Triage Pattern Matching)

从 108+ 条历史 DCR 中提炼的 **7 个 PM 决策模式**，Agent 在分类后识别适用模式并生成对应回复策略：

| # | 模式 | 自动化潜力 | Agent 行为 |
|---|------|-----------|-----------|
| 1 | 以产品愿景拒绝 | 中 | 匹配 DCR 主题 vs 产品路线图，生成拒绝草稿 |
| 2 | 以技术原因拒绝 | 中 | 引用架构文档和历史技术决策 |
| 3 | 接受到 Backlog（无 ETA） | **高** | 标准模板：接受 + 关联 ADO Feature + "no ETA" |
| 4 | 重定向到合作团队 | **高** | 基于 PM-to-Feature 映射建议正确团队 |
| 5 | 用已有功能解决 | **最高** | 搜索 Feature Flag / 已有功能，无需 PM |
| 6 | 升级压力下接受 | 低（需 PM） | 监控 DCR 年龄 + 检测升级语言模式 |
| 7 | 因客户无响应关闭 | **完全自动** | BIS 3 天 SLA 超时后自动标记关闭 |

### 4.4 重复请求检测 (Duplicate Detection)

Agent 将当前 DCR 与历史记录比对：
- `✅ Detected Duplicate` — 关联历史 DCR 编号 + 该 DCR 最终决策
- `🔗 Related Design Decision` — 关联已有设计文档 / 规范
- `🆕 New Request` — 无匹配

### 4.5 基于分诊模式的建议回复 (Suggested Response)

Agent 根据识别到的分诊模式（1-7）生成回复草稿，要求引用具体来源。

PM 操作选项: ✅ 采用 / ✏️ 修改 / ❌ 推翻

### 4.6 升级决策建议 (Escalation Recommendation)

| 因子 | 权重 | 说明 |
|------|------|------|
| 客户分层 | 高 | S500/ACE 客户自动提升优先级 |
| 影响范围 | 高 | 受影响用户/功能数（来自 BIS） |
| 跨团队 | 高 | 是否涉及其他团队 |
| 合规/云敏感 | 高 | SOX/GDPR/GCCHigh/DoD |
| DCR 年龄 | 中 | 接近 30 天 SLA 的自动升级 |
| 竞争差距 | 中 | "[Compete Gap]" 标签 |
| **安全边界** | **最高** | NO-GO 规则 → 强制 PM 审阅 |

**NO-GO 规则**:
- 🔴 S500/ACE/Strategic 客户
- 🔴 合规/法律/隐私（SOX 标签）
- 🔴 产品方向/长期路线图
- 🔴 跨产品/跨组织
- 🔴 历史重大争议 DCR
- 🟡 缺乏文档或决策依据

### 4.7 PM 路由建议 (Ownership Routing)

Agent 维护 **PM-to-Feature-Area 映射表**，在 DCR 进入时建议正确 PM，减少 bounce。映射需支持动态更新。

### 4.8 PM 反馈闭环 (Feedback Loop)

记录 PM 对每步输出的操作（Accept / Modify / Override），用于持续改进。

---

## 5. 系统架构概要

- **接入层 (Intake)** — 多渠道 DCR 归一化
- **感知层 (Notify)** — 主动推送 + BIS 解析 + SLA 监控
- **分诊引擎** — 安全边界检查 → 分类 → 分诊模式匹配 → 去重 → 建议回复 → 升级决策
- **知识层** — 历史 DCR + PM 决策理由 + 产品文档 (RAG)
- **工具层** — IcM / ADO / Teams / SharePoint MCP 集成
- **反馈层** — PM 操作记录

---

## 6. V1 范围 (MVP Scope)

### 运行模式
| 模式 | 说明 | 阶段 |
|------|------|------|
| **Shadow** | Agent 建议但不执行，PM 查看后决定 | V1 初始 |
| **Semi-Auto** | 执行前显式请求 PM 确认 | V1 成熟期 |
| **Auto** | 自动执行低风险，高风险仍需确认 | V2+ |

### ✅ V1 包含
| 能力 | 优先级 |
|------|--------|
| 主动 DCR 通知 + SLA 监控 | P0 |
| DCR 自动分类 + 分诊模式匹配 | P0 |
| 重复检测 | P0 |
| BIS 解析（客户名、用户数、业务影响） | P0 |
| ICM + ADO 集成 | P0 |
| 可解释性输出（每步附推理和引用） | P0 |
| 回复建议（按分诊模式 + 来源引用） | P1 |
| 升级建议（含 NO-GO 安全边界） | P1 |
| PM 路由建议 | P1 |
| PM 反馈收集 | P1 |

### 🚫 V1 不包含
| 能力 | 原因 |
|------|------|
| 自动最终裁决 | Agent 不代替 PM 做决策 |
| IcM 回写 | V1 只读 |
| Teams Bot 集成 | V2 开发 |
| 跨组织路由 | 复杂度过高 |
| 多语言支持 | V1 聚焦英文 |

---

## 7. 上游渠道 (Intake Channels)

| 渠道 | 优先级 | 集成方式 |
|------|--------|----------|
| **IcM** | P0 (V1) | ICM MCP Server API |
| **Teams** | P1 (V1.5) | WorkIQ Teams MCP |
| **Email** | P2 (V2) | WorkIQ Mail MCP |

---

## 8. 交互模式 — Agent 交付方案对比 (Interaction Mode)

> PM 是最终用户。Agent 需要以 PM 最自然的方式融入其日常工作流，而不是要求 PM 学习新工具。

### 8.1 方案总览

| # | 方案 | 简述 | 开发成本 | PM 体验 | V1 可行性 |
|---|------|------|----------|---------|-----------|
| A | **M365 Copilot Declarative Agent** | 作为 M365 Copilot 扩展，PM 在 Copilot 聊天中调用 | 低-中 | ⭐⭐⭐⭐⭐ 最自然 | ✅ 推荐 |
| B | **Teams Bot (Bot Framework)** | 独立 Teams Bot，PM 在 1:1 或群聊中与 Bot 对话 | 高 | ⭐⭐⭐⭐ | ⚠️ 开发周期长 |
| C | **Copilot Studio Agent** | 在 Copilot Studio 低代码平台构建，发布到 Teams | 低 | ⭐⭐⭐⭐ | ✅ 快速原型 |
| D | **Power Automate + Adaptive Card** | 自动化流推送 Adaptive Card 到 Teams，PM 点击操作 | 低 | ⭐⭐⭐ | ✅ 适合通知场景 |
| E | **Teams Tab App (Web)** | Teams 内嵌 Web 仪表盘 | 中-高 | ⭐⭐⭐ 仪表盘体验 | ⚠️ 非对话式 |
| F | **Teams Channel + Webhook** | Agent 向指定频道推送消息，PM 在频道内回复 | 低 | ⭐⭐ | ✅ 最简单 |

### 8.2 方案详细分析

#### 方案 A — M365 Copilot Declarative Agent（推荐）

PM 在 M365 Copilot 聊天窗中 `@DCR-Agent` 调用，Agent 作为 Copilot 扩展运行，可访问 IcM/ADO 等数据源。

- **交互方式**: 自然语言对话 + Adaptive Card 展示结构化结果
- **主动推送**: 通过 Copilot 通知或 Teams Activity Feed 提醒
- **PM 反馈**: 在对话中直接回复（采纳/修改/拒绝）
- **优势**:
  - 融入 PM 已有 Copilot 使用习惯，零学习成本
  - 可直接利用 MCP (Model Context Protocol) 连接 IcM、ADO 等后端服务
  - Declarative Agent 开发复杂度低，专注于 Prompt + 数据编排
  - 支持 SSO，无需额外认证
- **劣势**:
  - 依赖 PM 拥有 M365 Copilot 许可证
  - 主动推送能力受限于 Copilot 平台能力
  - 对复杂 UI（如仪表盘）支持有限
- **适合阶段**: V1 核心交互通道

#### 方案 B — Teams Bot (Bot Framework)

基于 Azure Bot Framework 构建独立 Bot，注册到 Teams，PM 通过 1:1 对话或群组 @mention 交互。

- **交互方式**: 对话式 + Adaptive Card + 按钮操作
- **主动推送**: Proactive Messaging API，可在任何时间向 PM 发消息
- **PM 反馈**: Adaptive Card 按钮（✅ 采纳 / ✏️ 修改 / ❌ 拒绝）
- **优势**:
  - 完全控制交互流程和 UI
  - 强大的 Proactive Messaging 能力，非常适合 SLA 告警
  - 可独立部署，不依赖 Copilot 许可证
  - 支持复杂对话流（多轮确认、分步骤操作）
- **劣势**:
  - 开发周期长（Bot Framework + Azure 部署 + Teams App 注册）
  - 需要自建 AI 推理层
  - 维护成本较高
- **适合阶段**: V2，或作为主动推送的补充通道

#### 方案 C — Copilot Studio Agent

在 Copilot Studio（原 Power Virtual Agents）中低代码构建 Agent，接入 IcM/ADO 数据，发布到 Teams。

- **交互方式**: 对话式，支持 Generative AI 回复
- **主动推送**: 通过 Power Automate 触发器实现
- **PM 反馈**: 对话中直接操作
- **优势**:
  - 低代码/无代码，PM 团队可自行维护
  - 内置 AI 能力（GPT 驱动），支持自然语言理解
  - 快速迭代原型
  - 可通过 Connector 接入 IcM/ADO
- **劣势**:
  - 复杂推理逻辑（如 7 种分诊模式匹配）表达能力有限
  - 对自定义 MCP 工具的支持不如 Declarative Agent 灵活
  - 企业级定制受限于平台能力
- **适合阶段**: V1 快速验证 / 作为 Plan B

#### 方案 D — Power Automate + Adaptive Card

通过 Power Automate 监听 IcM 事件，触发时自动向 PM 的 Teams 发送包含分诊结果的 Adaptive Card。

- **交互方式**: PM 接收卡片 → 查看摘要 → 点击按钮操作
- **主动推送**: ✅ 天然支持，基于事件触发
- **PM 反馈**: Adaptive Card 按钮回调
- **优势**:
  - 开发最快，适合 "通知 + 简单操作" 场景
  - 无需 PM 主动查询，完全推送驱动
  - 与 M365 生态深度集成
- **劣势**:
  - 不支持多轮对话（PM 无法追问或深入探索）
  - AI 推理需要在后端服务中实现，Card 只是展示层
  - 复杂交互（如修改 Agent 建议）体验差
- **适合阶段**: V1 的主动通知补充通道

#### 方案 E — Teams Tab App (Web Dashboard)

在 Teams 中嵌入 Web 应用，提供 DCR 仪表盘视图，PM 可查看所有 DCR 状态、分诊结果、SLA 状态。

- **交互方式**: 仪表盘浏览 + 筛选 + 操作
- **主动推送**: 需配合其他方案（如方案 D）实现通知
- **PM 反馈**: Web UI 表单操作
- **优势**:
  - 全局视图，适合 SLA 监控和批量操作
  - UI 灵活度最高，可展示复杂数据
- **劣势**:
  - 非对话式，PM 需要主动打开
  - 开发工作量大（前端 + 后端）
  - 不适合即时分诊场景
- **适合阶段**: V2+ 作为辅助视图

#### 方案 F — Teams Channel + Webhook

Agent 向指定 Teams 频道发送消息（通过 Incoming Webhook 或 Bot），PM 在频道中回复。

- **交互方式**: 频道消息 + 线程回复
- **主动推送**: ✅ Webhook 直接推送
- **PM 反馈**: 回复消息或 Emoji 反应
- **优势**:
  - 实现最简单，几乎零开发成本
  - 团队可见，适合协作讨论
- **劣势**:
  - 消息容易被淹没（与 P2 痛点相同）
  - 无法精确路由到特定 PM
  - 结构化反馈采集困难
- **适合阶段**: 早期 PoC / 团队内部演示

### 8.3 推荐组合策略

| 阶段 | 主交互通道 | 辅助通道 | 说明 |
|------|-----------|----------|------|
| **PoC** | 方案 F（Channel Webhook） | — | 快速验证 Agent 核心推理能力 |
| **V1** | 方案 A（Copilot Declarative Agent） | 方案 D（Adaptive Card 推送） | Copilot 对话做主动查询 + Adaptive Card 做被动推送通知 |
| **V2** | 方案 A + 方案 B（Bot 补充） | 方案 E（Dashboard） | Bot 增强主动推送 + Dashboard 提供全局视图 |

### 8.4 交互场景映射

| 场景 | 推荐方案 | 交互流程 |
|------|----------|----------|
| 新 DCR 到达通知 | D（Adaptive Card） | Agent 自动推送 Card → PM 查看摘要 → 点击 "查看详情" 跳转 Copilot 对话 |
| SLA 即将超期告警 | D（Adaptive Card） | Agent 推送告警 Card（含剩余天数、客户分层）→ PM 点击操作 |
| PM 主动查询 DCR | A（Copilot Agent） | PM 在 Copilot 中 `@DCR-Agent 查看 IcM #12345 的分诊结果` |
| PM 审阅 Agent 建议 | A（Copilot Agent） | Agent 展示分类 + 建议回复 → PM 回复 "采纳" / "修改为..." |
| PM 批量查看 DCR 状态 | E（Dashboard，V2） | PM 打开 Tab → 筛选 SLA 超期 → 批量操作 |
| NO-GO 强制审阅 | D + A（组合） | Card 推送红色警告 → PM 点击进入 Copilot 详细对话 |

---

## 9. 成功指标 (Success Metrics)

| 指标 | 目标 | 衡量方式 |
|------|------|----------|
| PM 周活跃使用次数 | 稳定增长 | Agent 被调用/查看建议的次数（周维度） |
| 建议回复采纳率 | > 60% | PM 直接采用或微调 vs 完全推翻 |
| 分类准确率 | > 80% | Agent 分类 vs PM 最终决策对比 |
| 重复 DCR 识别率 | > 80% | Agent 识别 vs 人工确认 |

---

## 10. 风险与缓解

| 风险 | 缓解措施 |
|------|----------|
| 知识库覆盖不足 | V1 限定功能区域，逐步扩展 |
| Agent 误判关键 DCR | NO-GO 安全边界 + Shadow Mode |
| 决策黑箱感 | 强制可解释性 + 来源引用 |
| PM 路由映射过时 | 从 ADO PM/GPM 映射自动同步 |
| PM 使用习惯难变 | Shadow Mode 起步，嵌入现有工作流 |
| 多渠道接入复杂度 | V1 仅 IcM，V1.5 加 Teams |

---

## 11. 时间线 (Milestones)

| 阶段 | 内容 |
|------|------|
| **数据管道** | 批量获取 100+ DCR 数据 + BIS 提取 + PM 决策理由解析 |
| **数据集构建** | 基于 `dcr_template.md` 构建标注数据集，编码 7 种分诊模式 |
| **V1 开发** | 分诊引擎 + ICM/ADO 集成 + 分诊模式匹配 |
| **内部试用** | Shadow Mode Dogfood |
| **迭代优化** | 基于 PM 反馈优化分类/路由/回复质量 |

---

## 12. 开放问题 (Open Questions)

1. ~~**历史数据量?**~~ ✅ 已确认：108+ 条标注记录，45+ 条含 PM 评论
2. ~~**分类体系?**~~ ✅ 已确认：`dcr_template.md` 定义了完整 schema
3. **知识库范围**: V1 先接入哪些区域文档？（建议 Forms/Polls + Recording，数据最丰富）
4. **PM-Feature 映射**: 如何获取和维护最新 PM/GPM 归属？
5. **权限模型**: Agent 的 ICM/ADO 操作权限范围？