PRD → 任务拆解：技术评审流程

目标： 避免 PRD 生成后仍有大量技术细节未明确，导致开发中途反复停顿。

---

问题场景

典型对话流程：

用户：我想做一个旅行记录的 web 应用
AI：生成 PRD（功能列表、用户故事...）
用户：开始做吧
AI：开始写代码...
   ↓
中途卡住：登录用什么方案？前端 SSR 还是 CSR？API 要不要公开？

根因： PRD 阶段缺少强制技术决策检查点。

---

完整流程（5 阶段）

┌─────────────────────────────────────────────────────────────┐
│  阶段 1: 需求澄清  →  阶段 2: PRD 生成  →  阶段 3: 技术评审  │
│                                                              │
│  阶段 4: 任务拆解  →  阶段 5: 开发执行                       │
└─────────────────────────────────────────────────────────────┘

关键： 阶段 3（技术评审）是强制 checkpoint，不通过不能进入阶段 4。

---

阶段 1：需求澄清

目标： 明确核心价值、目标用户、关键功能边界。

Prompt 模板：

我想做一个 [产品描述]。

在生成 PRD 之前，请先问我 5-8 个关键问题，帮助明确：
1. 目标用户是谁
2. 核心使用场景
3. 必须有的功能 vs 可以后续添加的功能
4. 预期规模（用户量、数据量）
5. 是否有特殊约束（预算、时间、技术偏好）

等我回答完这些问题后，再生成 PRD。

输出： 问答记录 + 需求摘要

---

阶段 2：PRD 生成（结构化模板）

目标： 生成包含技术决策必填项的 PRD。

Prompt 模板：

基于以上需求，生成 PRD。必须包含以下章节：

## 1. 产品概述
- 产品定位
- 目标用户
- 核心价值

## 2. 功能列表
- P0（必须）
- P1（重要）
- P2（可选）

## 3. 技术决策清单（必填，不能留空）

| 决策项 | 选项 | 已选 | 理由 |
|--------|------|------|------|
| 认证方案 | OAuth / JWT / Session / 无登录 | | |
| 前端架构 | SSR / CSR / 混合 / 静态 | | |
| 数据库 | D1 / PostgreSQL / SQLite / 其他 | | |
| 部署平台 | Cloudflare / VPS / Serverless / 其他 | | |
| 公开 API | 是 / 否 | | |
| 文件存储 | 本地 / R2 / S3 / 其他 | | |
| 支付需求 | 是 / 否 | | |

## 4. 用户故事
（按功能列出）

## 5. 非功能需求
- 性能要求
- 安全要求
- 可扩展性考虑

关键规则： 技术决策清单必须填满，AI 不能写"待定"。

---

阶段 3：技术评审（强制 Checkpoint）

目标： 找出 PRD 中所有模糊、矛盾、遗漏的技术点。

Prompt 模板：

现在进入技术评审阶段。请扮演资深技术架构师，审查上面的 PRD。

任务：
1. 逐条检查技术决策清单，评估每个选择的合理性
2. 找出 PRD 中未明确但会影响开发的技术细节
3. 列出所有需要进一步确认的问题

输出格式：

### 技术评审报告

#### ✅ 已明确的决策
（列出没有问题的技术决策）

#### ⚠️ 需要进一步确认
（列出模糊点，每个点说明为什么重要）

#### ❌ 潜在风险/矛盾
（列出可能的技术冲突或风险）

#### 📋 待决策问题清单
1. [问题描述] - 影响范围：[前端/后端/数据库/部署]
2. ...

评审通过标准：待决策问题清单为空，或所有问题已回答。

流程：

• 如果评审通过 → 进入阶段 4
• 如果有待决策问题 → 用户回答 → 重新评审

---

阶段 4：任务拆解

目标： 将 PRD 转化为可执行的任务列表，每个任务有明确的完成标准。

Prompt 模板：

基于已通过的 PRD 和技术评审报告，生成任务列表。

要求：
1. 按依赖关系排序（前置任务 → 后续任务）
2. 每个任务包含：
   - 任务名称
   - 技术栈/工具
   - 完成标准（Definition of Done）
   - 预估工时
3. 标注关键路径任务

输出格式：

## 任务列表

### 阶段 1：基础架构
| ID | 任务 | 技术栈 | 完成标准 | 工时 | 关键路径 |
|----|------|--------|----------|------|----------|
| T1 | 项目初始化 | Next.js, TypeScript | 能运行 hello world | 1h | ✅ |
| T2 | 数据库设计 | D1, Drizzle ORM | 完成 schema 并迁移 | 2h | ✅ |
| T3 | 认证模块 | NextAuth, JWT | 能登录/注册 | 4h | ✅ |

### 阶段 2：核心功能
...

## 依赖关系图
T1 → T2 → T3 → T4...

验证步骤： 生成后追加一个 Prompt：

对每个任务，问自己：执行这个任务的人是否清楚所有技术细节？
如果有模糊点，列出来并补充到任务描述中。

---

阶段 5：开发执行

目标： 按任务列表执行，遇到新问题时记录并更新 PRD。

规则：

1. 严格按任务顺序执行
2. 遇到 PRD 未覆盖的技术问题 → 暂停 → 记录 → 更新 PRD → 继续
3. 每个任务完成后标记状态

问题记录模板：

## 开发中发现的问题

| 日期 | 任务 ID | 问题描述 | 解决方案 | PRD 是否更新 |
|------|---------|----------|----------|-------------|
| 2026-03-24 | T3 | NextAuth 配置与 D1 不兼容 | 改用 Drizzle + 手动 JWT | ✅ |

---

完整示例：旅行记录应用

阶段 1：需求澄清（摘要）

用户：我想做一个旅行记录的 web 应用

AI 问：
1. 目标用户是谁？
   → 个人使用为主，可能分享给朋友

2. 核心功能是什么？
   → 上传照片、写游记、地图标记去过的地方

3. 需要登录吗？
   → 需要，但要简单，不想搞复杂的 OAuth

4. 数据量预期？
   → 个人使用，大概几百张照片，几十篇游记

5. 技术偏好吗？
   → 想用 Cloudflare 栈，成本低

阶段 2：PRD 技术决策清单（填写后）

决策项	选项	已选	理由
认证方案	OAuth / JWT / Session	JWT	简单，无需第三方依赖
前端架构	SSR / CSR / 混合	Next.js SSR	SEO 友好，首屏快
数据库	D1 / PostgreSQL	D1	Cloudflare 原生，成本低
部署平台	Cloudflare / VPS	Cloudflare Pages	免费额度够用
公开 API	是 / 否	否	个人使用，不需要
文件存储	R2 / S3 / 本地	R2	Cloudflare 生态，便宜

阶段 3：技术评审报告（示例）

### 技术评审报告

#### ✅ 已明确的决策
- 认证方案：JWT（符合简单需求）
- 部署平台：Cloudflare Pages（成本最优）
- 文件存储：R2（与 D1 同生态）

#### ⚠️ 需要进一步确认
1. JWT 密钥如何存储？Cloudflare Pages 有环境变量，但需要确认轮换策略
2. 图片上传是否需要压缩？影响 R2 存储成本和加载速度
3. 地图标记用哪个服务？Google Maps / Mapbox / 开源方案？

#### 📋 待决策问题清单
1. JWT 密钥存储和轮换方案 - 影响范围：认证安全
2. 图片处理策略（压缩尺寸、格式） - 影响范围：前端 + R2
3. 地图服务选型 - 影响范围：前端 + 成本

用户回答后，重新评审通过。

阶段 4：任务列表（节选）

## 任务列表

### 阶段 1：基础架构
| ID | 任务 | 技术栈 | 完成标准 | 工时 | 关键路径 |
|----|------|--------|----------|------|----------|
| T1 | 项目初始化 | Next.js 14, TypeScript | 能运行 hello world | 1h | ✅ |
| T2 | D1 数据库设计 | Drizzle ORM | 完成 users, trips, photos 表 | 2h | ✅ |
| T3 | JWT 认证模块 | @hono/jsonwebtoken | 登录/注册/验证中间件 | 4h | ✅ |
| T4 | R2 存储配置 | Cloudflare R2 | 能上传/下载文件 | 2h | ✅ |

### 阶段 2：核心功能
| T5 | 游记 CRUD | Hono API | 增删改查接口完成 | 6h | ✅ |
| T6 | 图片上传组件 | React Dropzone | 支持拖拽、进度条 | 3h | |
| T7 | 地图标记 | Mapbox GL | 能在地图上标记位置 | 4h | |

---

关键成功因素

1. 强制检查点 —— 技术评审不通过，不能进入任务拆解
2. 结构化模板 —— 用表格和清单约束 AI，不让它"糊弄过去"
3. 问题追踪 —— 开发中发现的问题要反向更新 PRD，形成闭环
4. 依赖关系 —— 任务列表必须标注前置依赖，避免并行冲突

---

常见陷阱

陷阱	表现	避免方法
AI 写"待定"	技术决策清单留空	明确规则：不填完 PRD 不算完成
任务粒度过大	"完成后端 API"这种任务	要求每个任务 ≤ 1 天工时
忽略非功能需求	没考虑安全、性能、监控	PRD 模板强制包含非功能章节
开发中不更新 PRD	PRD 和实际代码脱节	遇到问题必须记录并更新 PRD

---

工具建议

• 文档存储： 工作区 docs/ 目录，每个项目一个 PRD 文件夹
• 版本控制： PRD 用 Git 管理，每次评审通过提交一个版本
• 任务追踪： 简单的 Markdown checklist 或 GitHub Issues

---

总结

这个流程的核心思想是：用结构化约束 AI 的发散性，用强制检查点避免细节遗漏。

多花 30 分钟做技术评审，能避免开发中途 3 小时的返工。

---

文档版本：v1.0 | 创建时间：2026-03-24 | 作者：v0