#从需求到原型

你有 100 个想法，但只有被验证过的才能叫产品。这章教你用 Claude Code 把想法变成可以给人看的、可以点的原型——不用打开任何设计工具。

#你需要什么

• Claude Code 已安装并登录
• 一个想做的产品想法（跟着教程用 TaskBoard 也行）
• 浏览器（看原型用）

#本章流程

一句话想法 → 需求澄清对话 → 结构化 PRD → 可交互 HTML 原型 → 确认验收
  5min          10min          5min           8min           2min

总共约 30 分钟，每一步都有具体产出。

#Step 1：从一句话开始

打开终端，进入项目目录，直接告诉 Claude Code 你的想法：

> 我想做一个简易的任务管理看板（TaskBoard），类似于 Trello 的简化版。
> 帮我先做需求分析，搞清楚这个产品到底需要哪些功能。

Claude Code 不会直接给答案——它会反过来问你。这就是产品需求分析的关键：AI 帮你问出你没想清楚的问题。

下面是一次真实的对话示例：

Claude: 好的，让我们先理清楚几个关键问题：

1. 这个看板的用户是谁？单人使用还是团队协作？
2. 卡片需要哪些属性？标题、描述、负责人、截止日期、优先级？
3. 看板的列是固定的（待办→进行中→完成）还是用户可以自定义？
4. 需要用户登录/注册吗？
5. 数据存储方式？本地存储还是需要后端？

先回答这些问题，我就能帮你梳理出完整的需求范围。

这 5 个问题就是价值——它们让你在写一行代码之前想清楚产品边界。

#Step 2：需求澄清对话

回答 Claude 的问题，然后它继续追问细节：

> 1. 先做单人使用，但数据结构上预留团队扩展的可能
> 2. 卡片属性：标题（必填）、描述（可选）、负责人、截止日期、优先级标签（高/中/低）
> 3. 四列固定：待办、进行中、待审核、已完成
> 4. 不需要登录，暂时只用 localStorage
> 5. 本地存储，不需要后端

Claude 会根据你的回答继续深挖：

Claude: 明白了。还有几个交互层面的细节需要确认：

1. 卡片在四列之间是拖拽移动还是点击按钮移动？
2. 待审核列是否需要特殊的交互？比如审核通过/驳回？
3. 优先级标签用什么颜色区分？
4. 是否需要搜索/筛选功能？
5. 截止日期快到了需要提醒吗？

这些细节如果现在不确认，后面改的成本会很高。

这就是 Claude Code 做需求分析的价值——它追问的细节往往是产品设计中容易遗漏的。你回答不上来不重要，重要的是被问到了。

#Step 3：生成结构化 PRD

回答完第二轮问题后，让 Claude 把前面讨论的内容整理成 PRD：

> 把我刚才说的整理成一份结构化的 PRD 文档，包括产品概述、功能范围、用户流程、数据模型、非功能需求。
> 格式用 Markdown。

Claude Code 会生成一份完整的 PRD。好习惯是直接让它写到文件里，方便后续追踪和修改：

> 把 PRD 写到 docs/taskboard/prd.md

生成出来的 PRD 大概长这样：

# TaskBoard 产品需求文档

## 1. 产品概述
TaskBoard 是一个简易的单人任务管理看板，用看板视图帮助用户可视化管理任务流。

## 2. 功能范围

### v1.0（当前版本）
- [x] 四列看板：待办 → 进行中 → 待审核 → 已完成
- [x] 卡片 CRUD：创建、编辑、删除卡片
- [x] 卡片属性：标题、描述、负责人、截止日期、优先级
- [x] 拖拽移动卡片
- [x] 本地存储（localStorage）

### v1.1（预留）
- [ ] 搜索和过滤
- [ ] 截止日期提醒
- [ ] 标签系统

## 3. 用户流程
...

## 4. 数据模型
```typescript
interface Card {
  id: string
  title: string
  description?: string
  assignee?: string
  dueDate?: string
  priority: 'high' | 'medium' | 'low'
  column: 'todo' | 'in-progress' | 'review' | 'done'
  createdAt: string
  updatedAt: string
}

#5. 非功能需求

• 离线可用（localStorage）
• 拖拽操作 60fps
• 移动端适配（至少可查看）

:::tip
**PRD 不是一次写完就完的**。好的做法是：把 `prd.md` 提交到 Git，后续每次需求变更都在上面改。Claude Code 能帮你做变更影响分析——改一个功能点，自动列出受影响的页面和组件。
:::

## Step 4：生成可交互原型

PRD 定稿后，让 Claude Code 生成原型。这里有个技巧：**不要让它生成完整前端项目，先生成一个能交互的 HTML 原型**。HTML 原型成本低、能演示、快。

```text
> 根据 docs/taskboard/prd.md 的要求，先生成一个可交互的 HTML 原型。
> 要求：
> 1. 一个 HTML 文件包含所有功能和样式
> 2. 四列看板，可以拖拽卡片（用原生 HTML Drag and Drop API）
> 3. 可以创建/编辑/删除卡片
> 4. 样式用 Tailwind CSS CDN
> 5. 数据存在 localStorage
> 6. 写到 docs/taskboard/prototype.html

Claude Code 会生成一个完整的单文件原型。在浏览器打开：

# Windows
start docs/taskboard/prototype.html

# macOS
open docs/taskboard/prototype.html

# Linux
xdg-open docs/taskboard/prototype.html

你能看到一个带样式的、可以拖拽卡片的看板——虽然数据只在 localStorage 里，但已经可以拿来演示和验证想法了。

#Step 5：原型确认与迭代

把原型给相关人看，收集反馈。反馈会转化为对话指令：

> 给 prototype.html 加三个改进：
> 1. 卡片标题为空时不允许创建（加个 toast 提示）
> 2. 优先级标签用颜色区分：高=红色，中=黄色，低=灰色
> 3. 加一个顶部统计栏，显示每列卡片数量

改原型阶段，Claude Code 的上下文还保持着整个 PRD 的记忆，所以它能确保改动不破坏已有功能。这也是为什么让同一个 Claude Code 会话搞定 PRD → 原型全流程很重要——上下文完整性。

> 加一个「回收站」列，删除的卡片先到这里而不是直接删掉。
> 回收站卡片 7 天后自动清除（用时间戳判断）。

#常见问题

#原型的功能和真实产品差多远？

原型阶段你只需要验证交互逻辑和用户流程。原型不关心：

• 后端 API 设计
• 数据库选型
• 认证和权限
• 性能优化

这些是 Chapter 4（设计到代码）要解决的问题。原型的目标是"让人看懂这个产品怎么用"。

#拖拽不流畅怎么办？

HTML 原生 Drag and Drop API 的体验确实一般。在原型阶段够用就行——重点是验证"拖拽这个交互对不对"，而不是"拖拽有多丝滑"。正式实现时换 @dnd-kit 或 react-beautiful-dnd。

#PRD 写多详细合适？

够用就好。一个好的 PRD 应该能回答三个问题：

1. 这个功能给谁用？
2. 用户怎么用？（流程）
3. 什么算做完？（验收标准）

如果 PM 拿着你的 PRD 能直接评估工作量和排期——那就是够详细了。

#原型确定后怎么过渡到正式开发？

参考 从设计到代码 章节。一句话流程：HTML 原型 → 提取 Playwright 测试 → 删掉原型 → TDD 写真正的前端代码。

下一章： 设计评审与走查 —— 原型有了，怎么保证质量？教你用 Claude Code 做系统化的设计走查。