关注公众号：weelinking | 访问官网：weelinking.com

「产品经理用 Claude 实现产品」系列 · 第7篇

前六篇打好了基础，从今天开始正式启动项目！第一步不是写代码，而是写需求——给 Claude 的需求。我会教你一套模板,把产品需求翻译成 Claude 能精准执行的格式。用好这套模板，Claude 的代码质量会提升一个档次。

---

一、前言：你跟 Claude 的"需求评审会"

前六篇我们完成了准备工作：

• ✅ 建立了认知
• ✅ 搭好了环境
• ✅ 做出了第一个页面
• ✅ 理解了技术架构

从今天开始，我们要做真正的项目了——需求管理平台。

第一步不是让 Claude 写代码，而是写需求。

你可能会想：“写需求不就是写 PRD 吗？我天天在写啊。”

是，但又不完全是。

跟人沟通，你的 PRD 可以有一些"隐含假设"——开发看不懂会问你，评审会上大家会讨论补充。

但跟 Claude 沟通，它不会主动问你。你说什么，它做什么。所以你需要一种更结构化、更明确的需求描述方式——我把它叫做**“AI 可执行需求文档”**。

今天我会教你一套模板，以及如何用这套模板描述我们的"需求管理平台"项目。

💡 本系列全程使用 weelinking 访问 Claude，国内可稳定使用

---

二、为什么不能直接丢 PRD 给 Claude

先来看一个反面案例。

模糊需求示例

你： 帮我做一个需求管理系统。

Claude 会给你回复，但很可能不是你想要的。因为"需求管理系统"太宽泛了：

• 是 Web 系统还是客户端？
• 有哪些核心功能？
• 数据字段有哪些？
• 用户角色是什么？
• 技术栈用什么？

Claude 不知道，所以它只能猜。 猜的结果可能跟你想的差十万八千里。

PRD vs AI 可执行需求文档

维度	传统 PRD	AI 可执行需求文档
读者	人（开发、设计、测试）	AI（Claude）
风格	叙述性、可以有隐含假设	结构化、明确无歧义
背景说明	详细（商业价值、用户画像…）	简略（一段话说清楚即可）
功能描述	分散在多个章节	集中、列表式
数据字段	可能在附录，可能没有	必须明确列出
业务规则	自然语言描述	if-then 格式
技术要求	通常不写	可选但建议写（指定技术栈）

简单说：PRD 是给人看的，AI 需求文档是给机器执行的。

---

三、给 Claude 的需求描述模板

经过大量实践，我总结了这套模板，适用于大多数 Web 应用项目：

完整模板结构

# 项目名称

## 一、项目背景（1-2段话）
- 这是什么产品
- 解决什么问题
- 目标用户是谁

## 二、核心功能（列表式，具体到操作）
1. 功能模块1
   - 子功能1.1
   - 子功能1.2
2. 功能模块2
   ...

## 三、页面清单（每个页面包含什么）
1. 页面A
   - 页面布局
   - 包含元素
   - 交互行为
2. 页面B
   ...

## 四、数据字段（列出所有字段及类型）
### 实体1（如：需求）
- 字段1（类型，必填/选填，说明）
- 字段2
...

### 实体2（如：用户）
...

## 五、业务规则（if-then 形式）
1. 规则1：当XX时，做XX
2. 规则2：XX只能XX
...

## 六、技术要求（可选）
- 前端：React + Ant Design
- 后端：Node.js + Express
- 数据库：SQLite
- 其他特殊要求

这个模板的好处：

• ✅ 结构清晰，Claude 一看就懂
• ✅ 信息完整，不会遗漏关键内容
• ✅ 可复用，以后做其他项目直接套用

---

四、梳理"需求管理平台"的完整需求

现在我们用这套模板，梳理我们要做的"需求管理平台"。

4.1 项目背景

# 需求管理平台

## 一、项目背景

这是一个轻量级的产品需求管理工具，帮助产品经理和团队收集、整理、跟踪产品需求。

**解决的问题：**
- 需求散落在各种地方（飞书文档、Excel、微信群），难以统一管理
- 需求优先级不清晰，团队不知道先做什么
- 需求状态不透明，不知道哪些在做、哪些做完了

**目标用户：**
- 产品经理：创建需求、设置优先级、跟踪进度
- 团队成员：查看需求列表、了解优先级
- 管理者：查看统计数据、了解整体进度

4.2 核心功能（MVP 版本）

## 二、核心功能

### 1. 用户认证
- 用户注册（用户名+密码+邮箱）
- 用户登录（用户名+密码）
- 退出登录

### 2. 需求管理
- 创建需求（标题、描述、优先级、类型）
- 编辑需求
- 删除需求（仅创建者和管理员）
- 查看需求详情

### 3. 需求列表
- 列表展示（表格形式）
- 搜索（按标题）
- 筛选（按状态、优先级）
- 排序（按创建时间、优先级）
- 分页（每页20条）

### 4. 看板视图
- 三列看板：待评审 | 开发中 | 已完成
- 拖拽改变状态
- 卡片显示关键信息

### 5. 数据统计（简版）
- 需求总数
- 各状态数量（待评审/开发中/已完成）
- 各优先级占比

4.3 页面清单

## 三、页面清单

### 1. 登录页 (/login)
- 中央白色卡片，包含 Logo
- 用户名输入框
- 密码输入框
- 登录按钮
- "还没账号？去注册"链接

### 2. 注册页 (/register)
- 类似登录页布局
- 用户名、邮箱、密码、确认密码输入框
- 注册按钮
- "已有账号？去登录"链接

### 3. 主页 (/home)
- 顶部导航栏（Logo、菜单、用户头像下拉）
- 侧边栏菜单（需求列表、看板视图、数据统计）
- 右侧内容区域（根据菜单切换显示不同页面）

### 4. 需求列表页 (/requirements)
- 顶部：搜索框 + 筛选条件（状态、优先级）+ "创建需求"按钮
- 中间：表格展示需求列表
- 底部：分页组件

### 5. 需求创建/编辑页 (/requirements/new 或 /requirements/:id/edit)
- 表单，包含所有需求字段
- 提交按钮、取消按钮

### 6. 需求详情页 (/requirements/:id)
- 需求完整信息展示
- 编辑按钮（仅创建者和管理员可见）
- 删除按钮（仅创建者和管理员可见）
- 返回按钮

### 7. 看板视图页 (/kanban)
- 三列看板布局
- 每列显示对应状态的需求卡片
- 支持拖拽

### 8. 数据统计页 (/stats)
- 数据概览卡片（总数、各状态数量）
- 优先级分布饼图
- 状态分布柱状图

4.4 数据字段

## 四、数据字段

### 需求表 (requirements)
- id (整数，主键，自动递增)
- title (字符串，必填，最多100字) - 需求标题
- description (文本，必填) - 详细描述
- priority (枚举，必填) - 优先级：P0/P1/P2/P3
- type (枚举，必填) - 类型：feature(新功能)/optimization(优化)/bugfix(Bug修复)/other(其他)
- status (枚举，必填) - 状态：pending(待评审)/in_progress(开发中)/testing(测试中)/done(已完成)/closed(已关闭)
- creator_id (整数，必填，外键关联 users.id) - 创建人
- assignee_id (整数，选填，外键关联 users.id) - 负责人
- tags (JSON数组，选填) - 标签列表
- created_at (日期时间，自动) - 创建时间
- updated_at (日期时间，自动) - 更新时间
- expected_date (日期，选填) - 期望完成日期

### 用户表 (users)
- id (整数，主键，自动递增)
- username (字符串，必填，唯一) - 用户名
- email (字符串，必填，唯一) - 邮箱
- password (字符串，必填) - 密码（加密存储）
- role (枚举) - 角色：admin(管理员)/member(普通成员)
- avatar (字符串，选填) - 头像URL
- created_at (日期时间，自动) - 注册时间

4.5 业务规则

## 五、业务规则

### 权限规则
1. 未登录用户只能访问登录页和注册页
2. 登录用户可以查看所有需求
3. 只有创建者和管理员可以编辑需求
4. 只有创建者和管理员可以删除需求
5. 管理员可以修改任何需求

### 数据验证规则
1. 需求标题：不能为空，长度1-100字符
2. 需求描述：不能为空，最少10字符
3. 优先级：必须选择，只能是 P0/P1/P2/P3
4. 状态：默认为"待评审"
5. 用户名：长度3-20字符，只能包含字母数字下划线
6. 邮箱：必须符合邮箱格式
7. 密码：最少6位

### 业务逻辑规则
1. 创建需求时，自动记录创建人和创建时间
2. 编辑需求时，自动更新 updated_at
3. 看板拖拽改变状态时，同步更新需求的 status 字段
4. 删除需求为软删除（标记为已删除，不真正删除记录）
5. 列表默认按创建时间倒序排列（最新的在前）

4.6 技术要求

## 六、技术要求

### 前端
- 框架：React 18
- UI 组件库：Ant Design 5.x
- 路由：React Router 6
- 状态管理：React Context + Hooks（简单场景，暂不用 Redux）
- HTTP 请求：axios
- 样式：CSS Modules 或 styled-components

### 后端
- 运行环境：Node.js 18+
- 框架：Express 4.x
- 认证：JWT (JSON Web Token)
- 密码加密：bcrypt
- 数据库：SQLite3（简单易用，无需额外安装）
- ORM：暂不使用，直接写 SQL（后期可考虑 Sequelize）

### 其他
- 前后端分离部署
- 后端提供 RESTful API
- 前端调用后端 API 获取数据
- 开发环境前端用 Vite，后端用 nodemon 热更新

---

五、把需求喂给 Claude

现在我们有了完整的需求文档，来看看怎么跟 Claude 对话。

5.1 第一步：让 Claude 生成技术方案

打开 Claude（通过 weelinking），新建对话，输入：

你： 我要做一个需求管理平台的 Web 应用，以下是完整需求。请基于这份需求，给我一个技术方案建议，包括：

1. 技术栈选型是否合理
2. 数据库表设计建议
3. API 接口列表
4. 前端页面组件结构
5. 项目文件目录结构

【然后粘贴完整的需求文档】

Claude 会给你一个详细的技术方案，包括：

• 技术栈评估（是否合理，有无更好的选择）
• 数据库 SQL 建表语句
• 完整的 API 接口列表（路径、方法、参数、返回）
• 前端组件树
• 推荐的项目目录结构

这就相当于"技术评审"——但评审者是 Claude。

5.2 第二步：让 Claude 生成项目需求文档

继续对话：

你： 很好。请基于这个需求和你的技术方案，帮我生成一份"项目技术需求文档"，作为后续开发的参考。文档应该包括：

1. 项目概述
2. 技术架构
3. 数据库设计（含建表 SQL）
4. API 接口文档（完整列表）
5. 前端路由和组件结构
6. 开发计划建议

Claude 会给你一份 Markdown 格式的完整技术文档。

把这份文档保存到项目的 docs 文件夹里——这就是你的"项目合同"，后续所有开发都以此为准。

---

六、实战对比：模糊需求 vs 精准需求

让我们做个对比，看看需求描述的精准程度对结果的影响。

对比实验

模糊需求：

帮我做一个需求管理系统的登录页。

Claude 可能做的：

• 给你一个基础的登录表单
• 样式可能很简陋
• 缺少注册入口
• 缺少忘记密码功能
• 不知道登录后跳转到哪里

---

精准需求：

帮我做登录页，要求：

布局：

• 居中白色卡片，圆角12px，阴影
• 卡片顶部有 Logo 和标题"需求管理平台"

表单字段：

• 用户名输入框（placeholder: 请输入用户名）
• 密码输入框（placeholder: 请输入密码）
• "记住我"复选框

按钮：

• 登录按钮（蓝色渐变，宽度100%）

其他：

• 底部一行小字：“还没账号？去注册”，点击跳转 /register
• 整体风格参考 Ant Design
• 背景用浅灰色

交互：

• 用户名不能为空
• 密码最少6位
• 不满足时显示红色提示
• 登录成功后跳转 /home

Claude 做的：

• 完全符合要求的登录页
• 样式精美
• 所有功能都有
• 验证逻辑完整
• 一次到位，不用改

结论：需求越精准，结果越好。

---

七、总结与下期预告

🎯 本篇核心要点

1. Claude 需要结构化的需求描述。 传统 PRD 是给人看的，可以有隐含假设。给 Claude 的需求要结构化、明确、无歧义。

2. 用模板规范需求描述。 项目背景 + 核心功能 + 页面清单 + 数据字段 + 业务规则 + 技术要求——这套模板能覆盖 80% 的 Web 应用。

3. 先写需求再写代码。 花 30 分钟梳理清楚需求，能节省后续数小时的返工时间。

📌 记住这句话

需求的精准度，决定了代码的质量。花时间写清楚需求，是最划算的投资。

📣 下期预告

第8篇：《从用户故事到技术方案——Claude 帮你做技术评审》

需求梳理好了，下一步就是让 Claude 帮我们做"技术设计"——设计数据库、设计 API、规划前端组件、初始化项目骨架。

你会发现，以前需要开发团队开会讨论一整天的"技术方案"，Claude 10 分钟就能给你一份完整的。

而且你作为产品经理，完全能看懂、能评审、能提意见——因为它用的概念，你全都懂。

💡 本系列全程使用 weelinking 访问 Claude，国内可稳定使用

---

📎 配套资源

📋 Claude 需求描述模板（可直接套用）

# [项目名称]

## 一、项目背景
[这是什么产品 | 解决什么问题 | 目标用户是谁]

## 二、核心功能（MVP）
1. [功能模块1]
   - [子功能1.1]
   - [子功能1.2]
2. [功能模块2]
   ...

## 三、页面清单
1. [页面名] ([路由])
   - 布局：[描述]
   - 元素：[列表]
   - 交互：[描述]

## 四、数据字段
### [实体1名称]
- [字段名] ([类型], [必填/选填]) - [说明]
- ...

## 五、业务规则
1. [规则1]：当 [条件] 时，[动作]
2. [规则2]：[主体] 只能 [操作]
...

## 六、技术要求
- 前端：[技术栈]
- 后端：[技术栈]
- 数据库：[选择]

📋 需求管理平台完整需求文档

（完整文档见正文第四章，可复制保存到 docs/requirements.md）

📋 好需求 vs 差需求对比集

场景	差需求 ❌	好需求 ✅
登录页	“做个登录页”	“登录页要有用户名、密码输入框，登录按钮，底部有注册入口，验证不能为空，风格参考 Ant Design”
表格	“做个需求列表”	“表格包含7列：标题、优先级、状态、创建人、创建时间、操作，支持搜索和筛选，每页20条”
表单	“做个创建需求的表单”	“表单包含：标题（文本，必填，100字以内）、描述（多行，必填，最少10字）、优先级（下拉，P0-P3）、提交按钮”
看板	“做个看板”	“三列看板（待评审/开发中/已完成），卡片显示标题、优先级、创建人，支持拖拽改变状态”

---

🌟 如果这篇文章对你有帮助，请点赞👍 收藏⭐ 关注🔔

你的支持是我持续更新的最大动力！

💬 评论区聊聊：你之前写需求时，有没有遇到"说不清楚"的情况？

---

📌 系列导航： 产品经理用 Claude 实现产品 · 系列目录

⏪ 上一篇： 第6篇：理解前端、后端、数据库——用你熟悉的产品语言

⏩ 下一篇： 第8篇：从用户故事到技术方案——Claude 帮你做技术评审