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

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

你在 Figma 里画了一个漂亮的页面，跟真正能用的产品之间，到底差了什么？今天用产品经理的语言，把"前端、后端、数据库、API"这些技术概念讲明白。你会发现——原来你一直在做"技术设计"，只是自己不知道而已。

---

一、前言：原型和产品之间隔着什么

上一篇我们聊了产品经理为什么要自己"写"代码。今天来聊一个更根本的问题：

你在 Figma / Axure 里画的原型，跟真正的产品之间，差了什么？

你一定有过这样的体验——原型评审会上，你自信地展示着精心设计的页面：交互清晰、逻辑完整、标注详细。领导和同事纷纷点头：“挺好的，什么时候能上线？”

然后你把原型丢给开发，等了两周。

拿到手一看——页面倒是做出来了，但点"提交"没反应，数据也不知道存到哪里去了，关掉浏览器再打开，刚才填的东西全没了。

因为原型只是一张"效果图"。 它展示了用户能看到什么，但没有告诉电脑应该做什么。

从效果图到真正能用的产品，中间有四个东西需要被"建造"出来：前端、后端、数据库、API。

别慌，这四个词听起来很技术，但今天我保证——用产品经理的语言，让你 10 分钟全部搞懂。

💡 如何可以高效使用Claude weelinking

---

二、用产品经理的语言理解技术

2.1 前端 = 用户看到的界面

一句话理解：前端就是你画的原型，但是"活的"。

你在 Figma 里画了一个登录页面——有 Logo、有输入框、有按钮、有"忘记密码"的链接。这些东西在前端里用三种"材料"来搭建：

你在原型里做的	前端对应的技术	通俗理解
摆放框、文字、按钮	HTML	页面的骨架，决定"有什么"
设置颜色、间距、字号	CSS	页面的装修，决定"好不好看"
标注点击跳转、弹窗	JavaScript	页面的灵魂，决定"能不能动"

用盖房子来类比：

HTML = 砖墙和框架（房子的结构）
CSS  = 装修和粉刷（让房子好看）
JS   = 水电和智能家居（让房子能用）

你现在再看看自己画的原型——你一直在做前端设计，只是用的工具不同。 你在 Figma 里拖拽组件，前端工程师在代码里写标签。做的事情本质上一样：让用户看到一个好用的界面。

2.2 后端 = 业务逻辑的引擎

一句话理解：你在 PRD 里写的"业务规则"，都在后端执行。

前端只负责"展示"和"交互"。但当用户点击"提交"按钮的时候，数据要被处理、要被校验、要被存起来——这些事情是后端干的。

举个你最熟悉的例子。你在 PRD 里写过这种规则吧：

· 用户提交需求时，状态默认为"待评审"
· 需求标题不能为空，不能超过 100 字
· 只有创建者和管理员可以删除需求
· 需求从"开发中"改为"已完成"时，自动记录完成时间

这些就是后端逻辑。 你一直在"设计"后端，只是你管它叫"业务规则"。

用外卖平台来类比就更清楚了：

前端 = 你手机上的外卖 App（看菜单、下单、付款）
后端 = 商家的调度系统（接单、分配骑手、计算配送时间、扣款）

你在 App 上点了"下单"，App 只是把你的请求"发出去"了。真正计算价格、检查库存、安排骑手的，是后面那个你看不见的系统。

后端就是那个看不见的系统。

2.3 数据库 = 你的数据仓库

一句话理解：数据库就是一个超级 Excel。

你在 PRD 里写的"数据字段"——需求标题、描述、优先级、状态、创建人、创建时间——这些数据总得存在某个地方吧？

数据库就是存数据的地方。

而且它的结构你已经非常熟悉了：

产品经理的概念	数据库的概念	通俗理解
一个 Excel 文件	一个数据库	存放所有数据的仓库
一个 Sheet 页签	一张数据表	存放某一类数据
Sheet 里的列名	字段	数据的属性
Sheet 里的一行	一条记录	一个具体的数据

比如你在 PRD 里写的需求字段：

需求标题（文本，必填，100字以内）
需求描述（富文本，选填）
优先级（枚举：P0/P1/P2/P3）
状态（枚举：待评审/开发中/测试中/已完成/已关闭）
创建人（关联用户）
创建时间（自动生成）

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

你一直在写"字段定义"，在数据库的世界里，这就叫"表结构设计"。名字变了，事情没变。

2.4 API = 前后端的"接口文档"

一句话理解：API 就是前端和后端之间的"通话协议"。

前端想要数据，后端有数据。它们之间怎么沟通？靠 API。

产品经理应该对"接口文档"不陌生吧？你可能写过或者看过这样的东西：

接口名称：创建需求
请求方式：POST
请求地址：/api/requirements
请求参数：
  - title（标题，必填）
  - description（描述，选填）
  - priority（优先级，必填）
返回结果：
  - 成功：返回新创建的需求信息
  - 失败：返回错误原因

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

用打电话来类比：

前端 → 拨号（发送请求）
API  → 电话线（通信协议）
后端 → 接电话、处理事情、回话（处理请求、返回结果）

所以当你在 PRD 里写"用户点击提交按钮，系统保存需求并返回成功提示"的时候，你已经在描述一个完整的 API 调用流程了。

---

三、一个需求从 PRD 到上线的技术全流程

理解了四个核心概念，我们来看一个完整的例子——用户注册。

3.1 用"用户注册"举例

你在 PRD 里是这样写的：

用户填写用户名、邮箱、密码，点击注册按钮。系统校验信息格式，检查用户名是否已存在，如果通过则创建账号并跳转到登录页，提示"注册成功"。

来看这个需求在技术上是怎么实现的：

Step 1 👁️ 【前端】
  → 展示注册页面（输入框 + 按钮）
  → 用户填写信息，点击"注册"

Step 2 📡 【API】
  → 前端把用户名、邮箱、密码打包
  → 发送请求给后端：POST /api/register

Step 3 ⚙️ 【后端】
  → 收到请求
  → 校验：用户名是否为空？邮箱格式对吗？密码够长吗？
  → 查询数据库：这个用户名有人用过吗？
  → 如果都没问题：加密密码，存入数据库
  → 返回结果：{success: true, message: "注册成功"}

Step 4 💾 【数据库】
  → users 表新增一条记录：
  → | id | username | email | password(加密) | created_at |

Step 5 👁️ 【前端】
  → 收到后端返回的"成功"
  → 弹出提示："注册成功！"
  → 跳转到登录页

一张图看完全流程：

用户填写表单 → 前端发送请求 → 后端校验处理 → 存入数据库
                                                    ↓
用户看到提示 ← 前端展示结果 ← 后端返回结果 ← 数据库确认保存

现在你再看这个流程，是不是没那么神秘了？

3.2 原来你一直在做"技术设计"

让我做一个惊人的对照——你在日常工作中做的事情，和技术岗位做的事情：

你在产品工作中做的	技术上叫什么	是同一件事吗？
画页面原型	前端页面设计	✅ 是
定义数据字段	数据库表结构设计	✅ 是
写业务规则	后端业务逻辑设计	✅ 是
写接口文档	API 设计	✅ 是
画页面跳转流程图	前端路由设计	✅ 是
定义用户角色权限	权限系统设计	✅ 是

你一直在用"产品语言"做"技术设计"。

唯一的差别是：你画出来的是"设计图纸"，开发写出来的是"砖和水泥"。

现在有了 Claude，你可以把自己的"设计图纸"直接变成"砖和水泥"。

---

四、Claude 在这个流程中扮演什么角色

理解了前端、后端、数据库、API 之后，Claude 的角色就非常清晰了：

传统模式：
你（说需求）→ 开发（翻译成代码）→ 产品（你验收）

Claude 模式：
你（说需求）→ Claude（翻译成代码）→ 产品（你验收）

流程完全一样，只是"翻译者"换了。

而且这个新的翻译者有几个显著优势：

对比维度	真人开发	Claude
响应速度	排期 3-5 天	5 秒
工作时间	朝九晚六	24小时
改需求态度	“又改？”	“好的，马上改”
信息损耗	需要反复沟通	你说什么它做什么
情绪成本	可能有抵触	永远积极

当然 Claude 也有局限——它不会主动问你遗漏的细节、大型项目可能需要更多引导、复杂系统还是需要专业开发。

但对于我们的目标——做一个产品经理日常能用的工具——Claude 绰绰有余。

本质上，你跟 Claude 的协作模式就是：

1. 你说需求（你的老本行）
2. Claude 翻译成代码（它的强项）
3. 你验收成果（还是你的老本行）

不就是你跟开发协作的升级版吗？只不过这个"开发"从不请假、从不抱怨、秒回消息、不用排期。

---

五、总结与下期预告

🎯 本篇核心要点

1. 技术没有你想的那么神秘。 前端、后端、数据库、API——这四个概念翻译成产品语言后，你发现自己早就在跟它们打交道了。

2. 你一直在做"技术设计"。 画原型 = 前端设计，定义字段 = 数据库设计，写业务规则 = 后端设计，写接口文档 = API 设计。你只是不知道它们叫什么而已。

3. Claude 就是你的翻译器。 你负责说需求（设计），Claude 负责翻译成代码（实现），你再负责验收。流程和你跟开发协作完全一样。

📌 记住这句话

你不需要学编程，你只需要学"把你的产品设计翻译给 AI"。而这件事，比写 PRD 还简单。

📣 下期预告

第3篇：《你的新搭档 Claude——比任何开发都听话》

认识了技术的全貌，下一篇我们正式请出你的新搭档——Claude。我们会真刀真枪地跟 Claude 对话，让它帮你做一个页面出来。你会亲眼看到：一句话，5 秒出页面。

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

---

📎 配套资源

📋 "PRD 概念 → 技术概念"对照表

产品经理概念	技术概念	一句话理解
页面原型	前端（HTML/CSS/JS）	用户看到的界面
业务规则	后端逻辑	系统怎么处理数据
数据字段定义	数据库表结构	数据存在哪里、存什么
接口文档	API 定义	前端和后端怎么通信
页面跳转流程	路由（Router）	页面之间怎么切换
组件/母版	组件（Component）	可复用的界面模块
角色权限矩阵	RBAC 权限系统	谁能干什么
状态流转	状态机	数据状态怎么变化
操作日志	审计日志	记录谁在什么时候做了什么

🏗️ 全栈架构图（产品经理友好版）

┌─────────────────────────────────────────────┐
│                  用户 👤                     │
│            （用浏览器访问）                    │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│              前端 Frontend 👁️                │
│    你画的原型变成"活的"：页面、样式、交互       │
│    技术：HTML + CSS + JavaScript（React）     │
└──────────────────┬──────────────────────────┘
                   │ API 请求/响应
┌──────────────────▼──────────────────────────┐
│              后端 Backend ⚙️                 │
│    你写的业务规则在这里执行：校验、计算、权限    │
│    技术：Node.js（Express）                   │
└──────────────────┬──────────────────────────┘
                   │ 读写数据
┌──────────────────▼──────────────────────────┐
│             数据库 Database 💾               │
│    你定义的数据字段存在这里：像超级 Excel       │
│    技术：SQLite                              │
└─────────────────────────────────────────────┘

---

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

⏪ 上一篇： 第1篇：产品经理为什么要自己"写"代码？

⏩ 下一篇： 第3篇：你的新搭档 Claude——比任何开发都听话

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

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

💬 评论区聊聊：看完这篇，你觉得技术还"可怕"吗？