产品经理理解前端后端数据库——用产品语言解析技术架构

你在 PRD 里画过这样的流程图吧：

登录页 → 点击登录 → 主页
主页 → 点击"需求列表" → 列表页
列表页 → 点击某个需求 → 详情页

这就是路由设计。在 React 里：

/login → 登录页组件
/home → 主页组件
/requirements → 列表页组件
/requirements/:id → 详情页组件

你画的页面流程图，开发叫它"路由表"。名字不同，事情一样。

② 状态 (State) = 当前页面的数据

你在标注交互的时候会写：

- 用户输入用户名、密码，点击登录
- 登录成功后，顶部显示"欢迎，{用户名}"
- 用户创建需求后，列表页显示最新的需求

这些"用户名""需求列表"就是状态 (State)——页面当前记住的数据。

③ 事件 (Event) = 用户操作

你在交互说明里写：

- 点击"提交"按钮 → 验证表单 → 提交数据
- 鼠标悬停在按钮上 → 改变背景色
- 输入框失焦 → 触发格式校验

这些就是事件——用户的操作触发的动作。

二、后端深入理解：业务规则的执行者

2.1 后端做了什么——你写的业务规则在这里执行

看一个你写过的业务规则：

需求创建规则：
1. 标题不能为空，不能超过 100 字
2. 优先级必须选择（P0/P1/P2/P3 之一）
3. 创建时，状态默认为"待评审"
4. 自动记录创建时间和创建人
5. 只有登录用户才能创建需求
6. 创建成功后，通知相关人员

这些规则在哪里执行？——后端。

前端可以做一些基础验证（比如不能为空），但真正的业务逻辑必须在后端：

你在 PRD 里写的每一条"业务规则"，都会变成后端的一段代码。

2.2 API 就是你写的"接口文档"

你肯定写过或看过这样的接口文档：

接口名称：创建需求
请求方式：POST
请求地址：/api/requirements
请求参数：
- title (string, 必填): 需求标题
- description (string, 必填): 详细描述
- priority (string, 必填): 优先级 (P0/P1/P2/P3)
- type (string, 选填): 需求类型
返回结果：
成功：{
  "code": 200,
  "message": "创建成功",
  "data": {
    "id": 123,
    "title": "...",
    "status": "待评审",
    "createdAt": "2024-01-01 10:00:00"
  }
}
失败：{
  "code": 400,
  "message": "标题不能为空"
}

这就是一个 API 的完整定义。 你在写接口文档的时候，就是在做 API 设计。

前端根据这个文档发送请求，后端根据这个文档处理请求。

产品经理 → 技术的完美对应：

三、数据库深入理解：你一直在做"数据库设计"

3.1 数据表设计 = 你定义的数据字段

回忆一下你在 PRD 里怎么定义数据的：

需求数据结构：
基本信息：
- 需求 ID (自动生成)
- 需求标题 (文本，必填，最多 100 字)
- 详细描述 (富文本，必填)
- 优先级 (枚举：P0/P1/P2/P3)
- 需求类型 (枚举：新功能/优化/Bug 修复/其他)
- 状态 (枚举：待评审/开发中/测试中/已完成/已关闭)
关联信息：
- 创建人 (关联用户表)
- 负责人 (关联用户表，选填)
- 相关标签 (多个标签)
时间信息：
- 创建时间 (自动记录)
- 更新时间 (自动记录)
- 期望完成时间 (选填)

恭喜，你刚刚完成了一个数据库表的设计。

开发拿到这个，会在数据库里建一张 requirements 表：

你定义字段的时候，就是在做数据库设计。 只是名字不一样罢了。

3.2 表关系 = 你画的 ER 图

你在 PRD 里会写这些关系：

- 一个用户可以创建多个需求
- 一个需求只有一个创建人
- 一个需求可以有多条评论
- 一条评论属于一个需求
- 一个需求可以关联多个标签
- 一个标签可以被多个需求使用

这就是数据库的"表关系"：

如果你画过 ER 图（实体关系图），那你已经是数据库设计师了。

四、把它们串起来：一个完整需求的数据流

现在我们把前端、后端、数据库串起来，看一个完整的流程——用户创建一个需求。

完整数据流

【步骤 1】用户在前端操作 → 打开"创建需求"页面 → 填写标题、描述、优先级等信息 → 点击"提交"按钮
【步骤 2】前端验证 → 检查必填项是否填写 → 检查格式是否正确（标题长度、描述长度等） → 验证通过，准备发送请求
【步骤 3】前端发送 API 请求 → 调用 POST /api/requirements → 把表单数据打包成 JSON 格式 → 发送给后端服务器
【步骤 4】后端接收并处理 → 接收到请求数据 → 验证用户是否登录（检查 Token） → 再次验证数据格式（不信任前端） → 检查标题是否重复（查询数据库） → 填充默认值（状态=待评审，创建时间=现在）
【步骤 5】后端操作数据库 → 执行 SQL：INSERT INTO requirements (...) → 数据库保存这条需求记录 → 数据库返回新记录的 ID
【步骤 6】后端返回结果 → 封装返回数据：{code: 200, message: "创建成功", data: {...}} → 发送回前端
【步骤 7】前端展示结果 → 收到成功响应 → 显示"创建成功"提示 → 跳转到需求列表页 或 详情页 → 列表页重新请求数据，新需求出现在列表里

用图表展示

┌─────────────────────────────────────────────────────┐
│ 用户 (在浏览器里) │
│ 输入数据、点击按钮 │
└───────────────────┬─────────────────────────────────┘
│
┌─────────▼──────────┐
│ 前端 (React) │
│ 表单验证 + UI 展示 │
└─────────┬──────────┘
│ HTTP Request (API 调用)
│ POST /api/requirements
│ Body: { title, description, ... }
│
┌─────────▼──────────┐
│ 后端 (Node.js) │
│ 业务逻辑 + 权限验证 │
└─────────┬──────────┘
│ SQL Query
│ INSERT INTO requirements ...
│
┌─────────▼──────────┐
│ 数据库 (SQLite) │
│ 永久保存数据 │
└─────────┬──────────┘
│ 返回新记录 ID
│
┌─────────▼──────────┐
│ 后端 (Node.js) │
│ 封装返回结果 │
└─────────┬──────────┘
│ HTTP Response
│ { code: 200, data: {...} }
│
┌─────────▼──────────┐
│ 前端 (React) │
│ 更新 UI、显示提示 │
└─────────┬──────────┘
│
┌───────────────────▼─────────────────────────────────┐
│ 用户 (在浏览器里) │
│ 看到"创建成功"，列表更新了 │
└─────────────────────────────────────────────────────┘

看懂了吗？ 前端、后端、数据库各司其职：

• 前端：用户看到什么、怎么交互
• 后端：业务规则、权限控制
• 数据库：数据存储

五、产品经理 ↔ 技术概念完整映射表

让我们做一个终极对照——你在产品工作中做的每一件事，在技术上叫什么：

惊不惊喜？你一直在做"技术设计"，只是用的是产品语言。

六、总结与下期预告

🎯 本篇核心要点

1. React 的组件化 = Figma 的组件。 你在 Figma 里用组件、母版、实例的思维，React 完全一样。你已经是"组件化思维"的高手了。

2. 你一直在做数据库设计。 你定义的数据字段就是数据库表结构，你画的 ER 图就是表关系设计。名字不同，事情一样。

3. API 就是你的接口文档。 你写的接口文档就是 API 定义——请求什么、参数是什么、返回什么。

4. 业务规则 = 后端逻辑。 你写的"业务规则"会变成后端代码——验证、计算、存储、通知……

📌 记住这句话

你不需要学技术概念，你只需要知道：你做的产品设计，在技术世界里叫什么名字。

📣 下期预告

第 7 篇：《像写 PRD 一样写需求——让 AI 精准理解你要什么》

理解了技术全貌，下一篇我们要正式启动"需求管理平台"项目了。

第一步就是写需求——但不是给人看的 PRD，而是给 AI 看的"AI 可执行需求文档"。

我会教你一套模板，把你的产品需求翻译成 AI 能精准执行的格式。用这个模板，AI 给你的代码质量会提升一个档次。