用大模型将产品需求转换成 PRD 文档：五种方法与实战指南

我正在做一个内部 IT 工单系统，主要需求是：
- 员工可以提交 IT 问题（电脑故障、软件安装、权限申请等）
- 管理员可以查看、分配、处理工单
- 需要有优先级和状态跟踪
 
请帮我写一份 PRD 文档，包含：背景与目标、用户角色、核心功能、非功能需求、数据模型概要。

# 角色
你是一位拥有 10 年经验的高级产品经理，擅长将模糊的业务需求转化为结构清晰、
开发可执行的 PRD 文档。
 
# 任务
根据用户提供的需求描述，生成一份完整的 PRD 文档。
 
# PRD 文档结构（严格按此顺序输出）
 
## 1. 文档信息
- 文档标题、版本号、作者、日期、状态（草稿/评审中/已确认）
 
## 2. 背景与目标
- 业务背景：为什么要做这个功能
- 核心目标：用 1-2 句话描述要解决的问题
- 成功指标：可量化的 KPI（如果需求中未提及，标记 [待确认]）
 
## 3. 用户角色与场景
- 列出所有用户角色
- 每个角色的核心使用场景（User Story 格式：作为___，我想要___，以便___）
 
## 4. 功能需求
- 按模块组织，每个功能点包含：
  - 功能描述
  - 输入/输出
  - 业务规则
  - 边界情况和异常处理
- 优先级标记：P0（必须有）、P1（应该有）、P2（可以有）
 
## 5. 非功能需求
- 性能要求
- 安全要求
- 兼容性要求
- 可用性要求
 
## 6. 数据模型概要
- 核心实体和字段
- 实体关系
 
## 7. 开放问题
- 列出所有标记为 [待确认] 的问题
- 需要干系人确认的决策点
 
# 规则
1. 需求中未明确的信息，用 [待确认] 标记，不要自行假设
2. 每个功能点必须考虑异常情况
3. 优先级必须标注
4. 使用简洁的中文，避免冗余描述
5. 数据模型用表格呈现

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  需求解析    │────▶│  PRD 生成    │────▶│  质量审查    │
│  Agent       │     │  Agent       │     │  Agent       │
│              │     │              │     │              │
│ · 提取关键   │     │ · 按模板生成 │     │ · 检查完整性 │
│   实体       │     │   完整 PRD   │     │ · 标记遗漏   │
│ · 识别用户   │     │ · 补充边界   │     │ · 建议改进   │
│   角色       │     │   情况       │     │              │
│ · 生成澄清   │     │              │     │              │
│   问题       │     │              │     │              │
└─────────────┘     └─────────────┘     └─────────────┘
       │                                        │
       ▼                                        ▼
  如果有澄清问题                          输出最终 PRD
  → 返回给用户确认                        + 开放问题清单

@codebase 基于现有的用户模型和权限系统，帮我写一份工单系统的技术 PRD，
包含：
1. 新增的数据模型（与现有 User 模型的关系）
2. API 端点设计（RESTful）
3. 权限矩阵
4. 与现有通知服务的集成方案

你是一位在 SaaS B2B 领域有 10 年经验的高级产品经理。
你曾主导过 CRM、工单系统、项目管理工具等企业级产品的从 0 到 1。
你特别擅长识别边界情况和异常流程。

功能需求的格式示例：
 
### F-001: 创建工单
- **描述**：员工可以通过表单创建新的 IT 工单
- **输入**：标题（必填，50字内）、描述（必填）、类别（下拉选择）、优先级（下拉选择）
- **输出**：工单创建成功，返回工单编号，发送确认邮件
- **业务规则**：
  1. 同一员工同时最多有 10 个未关闭工单
  2. 优先级为"紧急"时，自动通知值班管理员
- **异常处理**：
  1. 标题超长 → 前端截断 + 提示
  2. 网络中断 → 本地暂存，恢复后自动提交
- **优先级**：P0
 
请按照这个格式输出所有功能需求。

请以资深 QA 工程师的视角审查上面的 PRD，找出：
1. 遗漏的边界情况
2. 不明确的业务规则
3. 可能的并发问题
4. 缺失的错误处理
 
对每个问题，给出具体的补充建议。

请以后端架构师的视角评审这份 PRD，关注：
1. 数据模型是否合理
2. API 设计是否 RESTful
3. 是否有性能瓶颈
4. 安全风险点

规则：
- 需求中未明确提及的信息，必须标记为 [待确认]，不得自行假设
- 每个功能点必须标注优先级：P0（MVP 必须）、P1（第二期）、P2（未来考虑）
- 涉及金额、权限、通知的逻辑，必须列出所有边界情况

请根据以下需求生成 PRD 文档：
 
我们公司现在 IT 问题都是在微信群里喊，经常漏掉。需要做一个内部工单系统，
员工遇到电脑问题、要装软件、申请权限什么的，可以提个工单。IT 那边能看到
所有工单，分配给具体的人处理。最好能看到处理进度，别提了工单就石沉大海了。
急的问题要能优先处理。

## 1. 文档信息
- 文档标题：内部 IT 工单管理系统 PRD
- 版本：v0.1（AI 生成草稿）
- 日期：2026-03-14
- 状态：草稿
 
## 2. 背景与目标
 
### 业务背景
当前公司 IT 支持依赖微信群沟通，存在以下问题：
- 问题容易被消息流淹没，导致遗漏
- 无法跟踪处理进度，员工不知道问题是否在处理
- 缺乏优先级机制，紧急问题无法优先响应
- 没有历史记录，相同问题重复沟通
 
### 核心目标
建立结构化的 IT 工单管理系统，实现问题的提交、分配、跟踪和闭环管理。
 
### 成功指标
- IT 问题响应时间从 [待确认] 降低到 [待确认]
- 工单遗漏率降至 5% 以下
- 员工满意度达到 [待确认]
 
## 3. 用户角色与场景
 
### 普通员工
- 作为普通员工，我想要提交 IT 工单，以便我的问题能被记录和跟踪
- 作为普通员工，我想要查看我的工单处理进度，以便我知道问题何时能解决
 
### IT 管理员
- 作为 IT 管理员，我想要查看所有待处理工单，以便我能合理分配资源
- 作为 IT 管理员，我想要将工单分配给具体的 IT 人员，以便责任明确
 
### IT 处理人员
- 作为 IT 处理人员，我想要查看分配给我的工单，以便我知道需要处理什么
- 作为 IT 处理人员，我想要更新工单状态和处理记录，以便提交人了解进展
 
## 4. 功能需求（摘录）
 
### F-001: 创建工单 [P0]
- **描述**：员工通过表单提交 IT 工单
- **输入**：标题（必填）、问题描述（必填）、类别（下拉）、优先级（下拉）、
  附件（可选）
- **业务规则**：
  1. 类别选项：硬件故障、软件安装、权限申请、网络问题、其他
  2. 优先级：紧急、高、中、低
  3. 创建后状态自动设为"待分配"
- **异常处理**：
  1. 附件大小超限 → 提示并阻止提交 [待确认：附件大小上限]
  2. 必填字段为空 → 前端校验提示
 
### F-002: 工单列表与筛选 [P0]
...
 
### F-005: 工单状态流转 [P0]
- **状态机**：待分配 → 已分配 → 处理中 → 待验证 → 已关闭
- **业务规则**：
  1. 只有 IT 管理员可以执行"分配"操作
  2. 只有被分配的处理人员可以更新为"处理中"
  3. 处理完成后，提交人验证确认后关闭
  4. [待确认] 是否允许重新打开已关闭的工单

请补充以下方面：
 
1. 通知逻辑：什么事件触发通知？通知谁？通过什么渠道？
2. 超时处理：工单超过一定时间未处理怎么办？
3. 并发场景：两个管理员同时分配同一个工单怎么办？
4. 数据权限：普通员工能看到别人的工单吗？
5. 工单关闭后的处理：关闭后能重新打开吗？有评价机制吗？

## 通知逻辑
 
| 触发事件 | 通知对象 | 通知渠道 | 通知内容 |
|----------|----------|----------|----------|
| 新工单创建 | IT 管理员 | 邮件 + 系统内 | 工单标题、优先级、提交人 |
| 工单被分配 | 处理人员 | 邮件 + 系统内 | 工单详情、期望完成时间 |
| 工单被分配 | 提交人 | 系统内 | 处理人员信息 |
| 状态变更 | 提交人 | 系统内 | 新状态、处理备注 |
| 紧急工单创建 | IT 管理员 | 邮件 + 短信 [待确认] | 工单详情 |
| 工单超时 | 处理人员 + 管理员 | 邮件 | 超时提醒 |
 
## 超时机制
- 紧急工单：30 分钟未分配 → 通知管理员；2 小时未开始处理 → 升级
- 高优先级：2 小时未分配 → 通知；8 小时未处理 → 升级
- 中/低优先级：24 小时未分配 → 通知
- [待确认] 升级通知发给谁？IT 主管？
 
## 并发控制
- 工单分配采用乐观锁机制
- 如果管理员 A 正在分配工单 X，管理员 B 尝试分配同一工单时，
  提示"该工单已被 [管理员A] 分配给 [处理人员]，请刷新页面"

请以后端工程师的视角评审这份 PRD，重点关注：
1. 数据模型设计是否合理
2. API 设计建议
3. 潜在的性能问题
4. 安全风险
 
请直接给出具体的技术建议，而不是泛泛的评论。

## 技术评审意见
 
### 数据模型建议
1. 工单表建议增加 `deleted_at` 字段支持软删除
2. 工单操作日志应独立成表（ticket_logs），记录所有状态变更，
   字段：id, ticket_id, operator_id, action, old_value, new_value, 
   created_at
3. 附件表独立（ticket_attachments），支持多附件
4. [建议] 类别和优先级用枚举表而非硬编码，方便后续扩展
 
### API 设计建议
- POST   /api/tickets          — 创建工单
- GET    /api/tickets          — 工单列表（支持分页、筛选）
- GET    /api/tickets/:id      — 工单详情
- PATCH  /api/tickets/:id      — 更新工单（状态、分配等）
- POST   /api/tickets/:id/comments — 添加处理记录
- GET    /api/tickets/stats    — 统计数据（管理员仪表盘）
 
### 性能关注点
1. 工单列表页需要分页，建议默认 20 条/页
2. 筛选查询需要在 status、priority、assignee_id、created_at 
   上建索引
3. 通知发送应异步处理（消息队列），避免阻塞主流程
4. 附件上传建议直传 OSS，不经过应用服务器
 
### 安全风险
1. 权限校验必须在后端实现，不能仅依赖前端控制
2. 工单详情接口需校验当前用户是否有权查看
3. 附件下载需要鉴权，不能用可猜测的 URL
4. 防止 XSS：工单描述支持富文本时需做内容过滤

## 开放问题清单
 
1. [待确认] 成功指标的具体数值（当前响应时间、目标响应时间）
2. [待确认] 附件大小上限（建议 10MB）
3. [待确认] 是否允许重新打开已关闭的工单
4. [待确认] 紧急工单是否需要短信通知
5. [待确认] 超时升级通知发给谁
6. [待确认] 是否需要工单评价机制
7. [待确认] 是否需要移动端支持（第一期）
8. [待确认] 是否需要与现有 OA 系统集成
9. [待确认] 数据保留策略（工单数据保留多久）

你的需求是什么？
│
├─ 快速探索一个想法
│  └─▶ 直接对话（ChatGPT/Claude）
│
├─ 团队已有 Notion/飞书/Jira
│  └─▶ 先试 SaaS 内置 AI
│     └─ 质量不够？ → 模板填充法
│
├─ 需要标准化团队 PRD 流程
│  └─▶ 模板填充法（性价比最高）
│
├─ 复杂产品，需要多轮生成和审查
│  └─▶ Agent 工作流
│
└─ 技术型 PRD（API 设计、数据模型）
   └─▶ IDE 集成