提示词模板（AI 需求采访 - 启动）：

你是一个拥有 10 年经验的资深产品经理。我要做 [产品描述]。
请像面试一样"采访"我，帮我理清需求。

规则：
- 每次只问 2-3 个问题，等我回答后再问下一轮
- 问题要具体、有针对性，避免泛泛而谈
- 如果我的回答模糊，追问细节
- 主动提出我可能遗漏的场景和边缘情况

需要覆盖的维度（按优先级）：
1. 目标用户是谁？他们的日常工作流是什么？
2. 核心问题是什么？现在他们怎么解决的？痛点有多痛？
3. MVP 必须包含哪些功能？哪些可以后续迭代？
4. 有哪些边缘场景需要处理？
5. 数据模型是什么样的？
6. 有哪些非功能性需求（性能、安全、可用性）？
7. 商业模式是什么？用户愿意为什么付费？
8. 成功指标是什么？如何衡量产品是否成功？

请开始第一轮提问。

提示词模板（边缘场景挖掘）：

基于我们之前的对话，请帮我系统化地思考边缘场景：

1. **用户异常行为**：
   - 用户输入了无效数据怎么办？
   - 用户在操作中途退出怎么办？
   - 多个用户同时操作同一资源怎么办？

2. **系统异常**：
   - 网络断开时怎么处理？
   - 第三方 API 超时或返回错误怎么办？
   - 数据库满了或写入失败怎么办？

3. **业务边界**：
   - 数据量极大时（10x 预期）系统能否承受？
   - 免费用户和付费用户的功能边界在哪里？
   - 国际化/多语言需要考虑吗？

4. **安全场景**：
   - 未授权访问怎么防御？
   - 敏感数据如何存储和传输？
   - 用户数据删除请求如何处理？

对每个场景，请评估：
- 发生概率：高/中/低
- 影响严重度：高/中/低
- 建议处理方式：MVP 必须处理 / 可以后续迭代 / 可以忽略

提示词模板（需求优先级矩阵）：

基于我们的对话，请将所有识别出的需求按以下框架排序：

**P0 - MVP 必须（没有就不能上线）**：
- [列出核心功能]
- 判断标准：用户无法完成核心任务

**P1 - 重要（上线后 1-2 个迭代内完成）**：
- [列出重要功能]
- 判断标准：显著影响用户体验或留存

**P2 - 锦上添花（有时间再做）**：
- [列出增强功能]
- 判断标准：提升体验但不影响核心流程

**P3 - 未来考虑（记录但不承诺）**：
- [列出远期功能]
- 判断标准：需要更多验证或技术成熟度

对每个需求，请标注：
- 预估开发工作量：S（1-2天）/ M（3-5天）/ L（1-2周）/ XL（2周+）
- 依赖关系：是否依赖其他需求先完成

提示词模板（会议记录 → 需求提取）：

以下是一次产品讨论会议的记录/转录：

[粘贴会议记录]

请从中提取结构化的产品需求：

1. **决策事项**（会议中明确达成共识的决定）
   | 决策 | 决策人 | 影响范围 |
   |------|--------|---------|

2. **功能需求**（讨论中提到的功能点）
   | 功能 | 提出者 | 优先级推测 | 是否达成共识 |
   |------|--------|-----------|-------------|

3. **待确认事项**（讨论中未达成共识或需要进一步调研的）
   | 事项 | 相关方 | 建议下一步 |
   |------|--------|-----------|

4. **用户故事草稿**（从讨论中提炼）
   - As a [角色], I want [功能], so that [价值]

5. **风险和顾虑**（会议中提到的担忧）
   | 风险 | 提出者 | 严重度 | 建议缓解措施 |
   |------|--------|--------|-------------|

请标注哪些是"明确提到的"，哪些是"AI 推断的"。

提示词模板（用户故事批量生成）：

产品描述：[一段话描述你的产品]
目标用户：[列出 2-3 个主要用户角色]

请为每个用户角色生成用户故事，遵循以下格式：

### [用户角色名称]

**US-001: [故事标题]**
- As a [角色]
- I want [功能/行为]
- So that [业务价值/用户价值]
- Priority: P0/P1/P2
- Estimated Size: S/M/L/XL

**验收标准：**
- Given [前置条件]
- When [用户操作]
- Then [预期结果]
- And [附加预期]

**边缘场景：**
- [场景 1]：[处理方式]
- [场景 2]：[处理方式]

---

要求：
1. 每个角色至少 5 个用户故事
2. P0 故事必须覆盖核心用户旅程
3. 每个故事的验收标准必须具体到可以写成自动化测试
4. 标注故事之间的依赖关系
5. 用中文编写

提示词模板（用户故事深度展开）：

请将以下用户故事展开为完整的需求规格：

原始故事：As a [角色], I want [功能], so that [价值]

请输出：

## US-XXX: [故事标题]

### 用户故事
As a [角色], I want [功能], so that [价值]

### 背景与动机
[为什么这个功能重要？用户现在怎么解决这个问题？]

### 验收标准（Given/When/Then）

**正常流程：**
1. Given [前置条件]
   When [用户操作]
   Then [预期结果]

2. Given [另一个前置条件]
   When [用户操作]
   Then [预期结果]

**异常流程：**
3. Given [异常前置条件]
   When [用户操作]
   Then [错误处理]

**边界条件：**
4. Given [边界条件]
   When [用户操作]
   Then [边界处理]

### UI/UX 要求
- [界面元素描述]
- [交互行为描述]
- [响应式要求]

### 数据要求
- 输入数据：[字段、类型、验证规则]
- 输出数据：[展示格式、排序规则]
- 存储需求：[持久化、缓存策略]

### 非功能性需求
- 性能：[响应时间要求]
- 安全：[权限、数据保护]
- 可用性：[无障碍要求]

### 依赖关系
- 前置：[需要先完成的故事]
- 后续：[依赖本故事的故事]

### 开放问题
- [需要进一步确认的问题]

提示词模板（用户故事质量审查）：

请审查以下用户故事，按 INVEST 原则评估：

[粘贴用户故事列表]

对每个故事，评估：

| 故事 | I（独立） | N（可协商） | V（有价值） | E（可估算） | S（小） | T（可测试） | 总分 |
|------|----------|-----------|-----------|-----------|--------|-----------|------|

评分标准（每项 1-5 分）：
- **Independent**：是否可以独立开发和交付？
- **Negotiable**：是否留有实现方式的灵活性？
- **Valuable**：是否对用户或业务有明确价值？
- **Estimable**：是否足够清晰可以估算工作量？
- **Small**：是否足够小可以在一个迭代内完成？
- **Testable**：验收标准是否具体到可以写测试？

对于总分 < 20 的故事，请给出具体改进建议。

额外检查：
1. 是否有遗漏的用户角色？
2. 是否有遗漏的核心用户旅程？
3. 故事之间是否有隐含的依赖关系未标注？
4. 验收标准是否有歧义或不可测试的描述？

提示词模板（需求 → 验收标准）：

请将以下需求描述转化为 Given/When/Then 格式的验收标准：

需求描述：[粘贴需求描述]

要求：
1. 每个验收标准必须是独立可测试的
2. 覆盖正常流程、异常流程、边界条件
3. 使用具体的数据示例（不要用"某个值"这样的模糊描述）
4. 标注每个标准的测试类型（单元测试/集成测试/E2E 测试）

输出格式：

**AC-1: [标准标题]**
- Given [具体的前置条件，包含示例数据]
- When [具体的用户操作或系统事件]
- Then [具体的预期结果，包含可验证的断言]
- Test Type: [单元/集成/E2E]

**AC-2: [异常场景标题]**
- Given [异常前置条件]
- When [触发操作]
- Then [错误处理行为，包含错误消息]
- Test Type: [单元/集成/E2E]

**AC-3: [边界条件标题]**
- Given [边界值条件]
- When [操作]
- Then [边界处理行为]
- Test Type: [单元/集成/E2E]

提示词模板（验收标准完整性检查）：

请检查以下验收标准是否覆盖了所有必要场景：

[粘贴已有的验收标准]

请按以下清单检查并补充遗漏：

□ **Happy Path**（正常流程）
  - 标准的成功操作流程是否覆盖？
  - 所有正常输入组合是否考虑？

□ **Validation**（输入验证）
  - 必填字段为空时的行为？
  - 格式错误的输入（邮箱、电话、URL）？
  - 超出长度限制的输入？
  - 特殊字符和 XSS 攻击向量？

□ **Authorization**（权限控制）
  - 未登录用户的行为？
  - 无权限用户的行为？
  - 不同角色的权限差异？

□ **Concurrency**（并发场景）
  - 多用户同时操作同一资源？
  - 乐观锁/悲观锁的行为？

□ **Error Handling**（错误处理）
  - 网络超时的行为？
  - 服务端错误（500）的行为？
  - 第三方服务不可用的行为？

□ **Boundary**（边界条件）
  - 空列表/空数据的展示？
  - 数据量极大时的分页/性能？
  - 首次使用（无历史数据）的体验？

□ **State Transitions**（状态转换）
  - 所有合法的状态转换路径？
  - 非法状态转换的拒绝？

请补充遗漏的验收标准，并标注优先级。

提示词模板（验收标准 → 测试代码框架）：

请将以下验收标准转化为测试代码框架：

[粘贴验收标准]

技术栈：[Jest/Vitest/Pytest/其他]
语言：[TypeScript/Python/Rust/其他]

要求：
1. 每个验收标准对应一个 describe 块
2. 每个 Given/When/Then 对应一个 test case
3. 只生成测试框架（describe/it/test），不写具体实现
4. 添加注释标注对应的验收标准编号
5. 包含 setup/teardown 的占位符

输出示例：
```typescript
describe('AC-1: [标准标题]', () => {
  // Given: [前置条件]
  beforeEach(() => {
    // TODO: 设置前置条件
  });

  it('should [预期行为] when [操作]', () => {
    // When: [操作]
    // Then: [预期结果]
    // TODO: 实现测试
  });
});

---

## 5. AI 辅助 PRD 生成


### 5.1 结构化 PRD 生成

经过需求采访和用户故事梳理后，可以让 AI 生成完整的结构化 PRD。以下模板融合了业界最佳实践：

#### 提示词模板：完整 PRD 生成

### 5.2 PRD 审查与迭代

PRD 初稿生成后，需要经过多轮审查和迭代。AI 可以扮演不同角色来审查 PRD：

#### 提示词模板：多角色 PRD 审查

#### 提示词模板：PRD 差距分析

---

## 6. Spec-Driven 开发工作流


### 6.1 Kiro Spec 工作流详解

Kiro 的 Spec-Driven 开发是 2025 年最具代表性的"需求→代码"工作流。它将传统的 PM/工程流程压缩为三个自动化阶段：

#### 操作步骤

**步骤 1：创建 Spec**

在 Kiro 中描述你的产品想法，Kiro 会自动生成 `requirements.md`：

**步骤 2：生成技术设计**

确认需求后，Kiro 自动生成 `design.md`：

**步骤 3：生成任务列表**

技术设计确认后，Kiro 生成 `tasks.md`：

**步骤 4：AI Agent 执行任务**

Kiro 的 AI Agent 按照任务列表逐个执行，每个任务都有明确的需求和设计作为上下文。

#### Kiro Spec 的 requirements.md 格式示例

```markdown
# Requirements Document

## Introduction
[产品简介和背景]

## Glossary
- **Term1**: 定义
- **Term2**: 定义

## Requirements

### Requirement 1: [需求组标题]

**User Story:** As a [角色], I want [功能], so that [价值]。

#### Acceptance Criteria

1. WHEN [条件], THE [系统] SHALL [行为]
2. WHEN [条件], THE [系统] SHALL [行为]
3. WHEN [条件], THE [系统] SHALL NOT [禁止行为]

# Product Specification
 
## Problem Statement
[要解决的问题]
 
## Goals
- [目标 1]
- [目标 2]
 
## User Stories
- As a [角色], I want [功能], so that [价值]
 
## Acceptance Criteria
- [ ] [标准 1]
- [ ] [标准 2]
 
## Non-Functional Requirements
- Performance: [要求]
- Security: [要求]
 
## Constraints
- [技术约束]
- [业务约束]

# Architecture Decision Record
 
## Context
[决策背景]
 
## Decision
[选择的方案]
 
## Consequences
[方案的影响]
 
## Alternatives Considered
[考虑过的其他方案]

# Task Breakdown
 
## Phase 1: Foundation
- [ ] Task 1.1: [描述]
- [ ] Task 1.2: [描述]
 
## Phase 2: Core Features
- [ ] Task 2.1: [描述]

提示词模板（PRD → Kiro Spec 格式）：

请将以下 PRD 转化为 Kiro Spec 的 requirements.md 格式：

[粘贴 PRD 内容]

转化规则：
1. 每个功能模块对应一个 Requirement 组
2. 每个用户故事使用 "As a... I want... So that..." 格式
3. 验收标准使用 "WHEN [条件], THE [系统] SHALL [行为]" 格式
4. 非功能性需求也要转化为可验证的验收标准
5. 添加 Glossary 定义所有专业术语
6. 验收标准必须具体到可以写成自动化测试

注意：
- 模糊的需求要量化（"快" → "响应时间 < 200ms"）
- 隐含的需求要显式化（如错误处理、权限控制）
- 每个验收标准编号要与需求组对应

提示词模板（需求变更影响分析）：

我需要对以下需求进行变更：

**原始需求**：[粘贴原始需求]
**变更内容**：[描述变更]
**变更原因**：[为什么要变更]

请分析这个变更的影响：

1. **直接影响**
   - 哪些用户故事需要修改？
   - 哪些验收标准需要更新？
   - 预估额外工作量：

2. **间接影响**
   - 哪些已完成的功能可能受影响？
   - 哪些正在开发的任务需要调整？
   - 是否影响数据模型或 API 设计？

3. **风险评估**
   - 变更引入的新风险：
   - 对时间线的影响：
   - 对其他需求的连锁影响：

4. **建议**
   - 是否建议接受这个变更？
   - 如果接受，建议的实施策略：
   - 如果拒绝，替代方案：

提示词模板（需求变更日志生成）：

请对比以下两个版本的需求文档，生成变更日志：

**旧版本**：
[粘贴旧版本]

**新版本**：
[粘贴新版本]

请输出：

## 需求变更日志 - [日期]

### 新增需求
- [新增的用户故事或验收标准]

### 修改需求
- [修改前] → [修改后]（修改原因）

### 删除需求
- [删除的需求]（删除原因）

### 影响评估
- 受影响的模块：
- 预估额外工作量：
- 需要重新测试的范围：

开发者输入：
我想做一个桌面应用，可以把本地文件夹自动同步到百度网盘。
用 Tauri + React 做前端，Rust 做后端。

AI 采访问题（第 1 轮）：
1. 同步是单向（本地→云端）还是双向？
2. 需要实时监控文件变化还是手动触发同步？
3. 大文件（>100MB）如何处理？

开发者回答：
1. 先做单向（本地→云端），后续考虑双向
2. 实时监控，文件变化后自动同步
3. 大文件需要分片上传，支持断点续传

AI 采访问题（第 2 轮）：
1. 需要支持 .gitignore 风格的忽略规则吗？
2. 同步冲突（云端文件被其他设备修改）如何处理？
3. 需要同步日志和历史记录吗？
...

# Requirements Document
 
## Introduction
RustSync 是一个桌面文件同步工具，使用 Tauri + React 前端和 Rust 后端，
将本地文件夹自动同步到百度网盘。
 
## Glossary
- **SyncPair**: 一组本地文件夹和百度网盘路径的映射关系
- **FileWatcher**: 监控本地文件系统变化的组件
- **TransferScheduler**: 管理文件上传队列和优先级的调度器
 
## Requirements
 
### Requirement 1: 文件同步核心功能
 
**User Story:** As a 开发者, I want 将本地文件夹自动同步到百度网盘,
so that 我的代码和文档有云端备份。
 
#### Acceptance Criteria
 
1. WHEN 用户配置了本地文件夹和百度网盘路径,
   THE SyncPair SHALL 建立并持久化保存映射关系
2. WHEN 本地文件发生变更（新增/修改/删除）,
   THE FileWatcher SHALL 在 5 秒内检测到变更
3. WHEN FileWatcher 检测到变更,
   THE TransferScheduler SHALL 将变更加入上传队列
4. WHEN 文件大小超过 4MB,
   THE TransferScheduler SHALL 使用分片上传
5. WHEN 上传过程中网络中断,
   THE TransferScheduler SHALL 支持断点续传
 
### Requirement 2: 忽略规则
 
**User Story:** As a 开发者, I want 配置文件忽略规则,
so that node_modules 等不需要同步的文件不会被上传。
 
#### Acceptance Criteria
 
1. WHEN 用户创建 .syncignore 文件,
   THE IgnoreEngine SHALL 解析 gitignore 风格的规则
2. WHEN 文件匹配忽略规则,
   THE FileWatcher SHALL 跳过该文件的同步