第5章 搭建产品架构 — 1张表、4张图
产品经理最怕的场景是什么？评审会上，开发问"这个功能的状态有哪些？"，你愣住了。改需求时，产品说"这个流程好像不太对"，你发现想不全。这不是能力问题，是架构没搭好。
我是怕浪猫，这一章不讲理论，只讲实操。1张表、4张图，帮你把任何产品的架构搭得清清楚楚。
5.1 产品架构方法论
5.1.1 产品架构的本质与价值
产品架构是什么？简单说就是"把产品的所有要素组织起来的结构"。
为什么要画产品架构？因为人脑处理不了太复杂的信息。产品经理脑子里装着200个功能点、50个流程节点、30个角色——不画出来，根本理不清。
产品架构的三个价值：
第一：系统化思考的工具
画架构的过程就是强迫自己思考的过程。"内容模块和用户模块是什么关系？搜索功能依赖哪些基础能力？"架构图画着画着，这些问题就想清楚了。
第二：团队沟通的媒介
PRD评审时，一图胜千言。你花10分钟讲清楚架构图，比写1000字的设计说明更有用。开发、设计、测试看了架构图，就知道你要做什么。
第三：迭代决策的依据
产品迭代时，架构图告诉你"改A会影响B"。你知道改动的影响范围，才能做决策。没有架构图，改了一个地方可能引发三个地方的问题。
产品架构不是"写完就完了"的文档，而是"一直在用"的工具。好的架构图，每次迭代都应该拿出来对照。
5.1.2 1张表：功能清单/需求矩阵
功能清单表是产品架构的"地基"。没有这张表，所有架构图都是空中楼阁。
功能清单表的结构
| ID | 模块 | 功能名称 | 功能描述 | 用户角色 | 优先级 | 依赖功能 |
|---|---|---|---|---|---|---|
| F001 | 用户 | 注册 | 手机号+验证码注册 | 访客 | P0 | 无 |
| F002 | 用户 | 登录 | 手机号+验证码登录 | 访客 | P0 | F001 |
| F003 | 内容 | 发帖 | 发布图文/视频内容 | 创作者 | P0 | F001,F002 |
| F004 | 内容 | 浏览 | 列表流浏览内容 | 消费者 | P0 | 无 |
| F005 | 内容 | 评论 | 对内容发表评论 | 消费者 | P1 | F001,F004 |
模块划分方法
模块划分有两种思路：
思路一：按业务域划分。适合复杂业务系统。
| 业务域 | 说明 | 模块示例 |
|---|---|---|
| 用户域 | 用户相关的一切 | 注册、登录、资料、会员 |
| 内容域 | 内容生产与消费 | 发帖、浏览、搜索、推荐 |
| 交易域 | 交易与支付 | 购物车、订单、支付、售后 |
| 社交域 | 社交互动 | 点赞、评论、关注、消息 |
思路二：按页面/功能入口划分。适合C端产品。
| 入口 | 包含功能 |
|---|---|
| 首页Tab | 推荐流、分类入口、搜索入口 |
| 搜索Tab | 搜索框、历史记录、搜索结果 |
| 发布Tab | 发布器、内容编辑、话题选择 |
| 消息Tab | 评论、赞、关注、系统通知 |
| 我的Tab | 个人信息、设置、钱包、订单 |
功能清单表的自检标准
画完功能清单表后，问自己三个问题：
- 每一行都有明确的用户角色吗？没有用户角色的功能是"假功能"——你以为自己需要，其实没人用。
- 每一行都有清晰的优先级吗？P0/P1/P2/P3，不是给老板看的，是给自己排版本用的。
- 依赖关系是否完整？任何一个P0功能，如果依赖了P2功能，优先级应该提升。
5.1.3 4张图：信息架构图、功能架构图、业务流程图、状态机图
这四张图是产品架构的核心表达。
图1：信息架构图
信息架构图回答的问题是："产品里有哪些信息，这些信息之间是什么关系？"
以电商App为例：
商品信息
├── 商品基础信息（名称、价格、库存）
├── 商品详情信息（图片、描述、规格）
└── 商品评价信息（评分、评价内容）
用户信息
├── 账户信息（手机、密码、昵称）
├── 收货信息（地址簿）
└── 资产信息（积分、优惠券、余额）
订单信息
├── 订单基础信息（订单号、时间、状态）
├── 订单商品信息（商品快照、数量）
└── 订单支付信息（支付方式、金额）信息架构图的价值：帮助设计师理解"数据模型"，帮助开发理解"数据库设计"。好的信息架构是前后端沟通的基础。
图2：功能架构图
功能架构图回答的问题是："产品的功能是怎么组织的？哪些是底层能力，哪些是上层应用？"
以内容平台为例：
┌─────────────────────────────────────────┐
│ 内容展示层 │
│ [首页推荐] [搜索结果] [个人主页] [详情页] │
└─────────────────────────────────────────┘
↑
┌─────────────────────────────────────────┐
│ 内容运营层 │
│ [话题管理] [内容审核] [推荐算法] [搜索排序] │
└─────────────────────────────────────────┘
↑
┌─────────────────────────────────────────┐
│ 内容供给层 │
│ [发布器] [内容处理] [媒资管理] [创作者工具] │
└─────────────────────────────────────────┘
↑
┌─────────────────────────────────────────┐
│ 基础能力层 │
│ [用户体系] [权限体系] [通知体系] [数据分析] │
└─────────────────────────────────────────┘功能架构图的价值：让你看清楚"复用关系"。如果两个功能都要用"搜索排序"，你应该把搜索排序做成底层能力，而不是重复实现两次。
图3：业务流程图
业务流程图回答的问题是："用户做一件事，要经历哪些步骤，每一步是什么？"
以电商下单流程为例：
开始 → 浏览商品 → 点击详情 → 选择规格 → 加入购物车 →
去购物车结算 → 确认订单 → 选择地址 → 选择支付方式 →
确认支付 → 跳转支付 → 支付成功 → 生成订单 → 结束扩展流程：
加入购物车
├── 库存充足 → 加入成功
├── 库存不足 → 提示"已售罄" / "到货通知"
└── 未登录 → 跳转登录 → 登录后继续
确认支付
├── 余额充足 → 支付成功
├── 余额不足 → 提示"余额不足"
└── 支付超时 → 订单关闭业务流程图的价值：帮你穷举所有可能。用户走的每一条路，你都要提前想清楚。没有业务流程图，上线后就会出现各种"没想到的bug"。
图4：状态机图
状态机图回答的问题是："一个实体（订单、内容、用户）有哪些状态，这些状态之间是怎么转换的？"
以订单状态机为例：
[待付款] --付款成功--> [待发货] --商家发货--> [待收货] --确认收货--> [已完成]
↑ | |
└─────取消/退款───────┴───申请退款─────────┘更复杂的状态机（考虑退货）：
[待付款]
│
↓ 付款成功
[待发货]
│
↓ 商家发货
[待收货]
│
├─→[确认收货]→[已完成]
│
└─→[申请退款/退货]→[退款/退货中]
│
├─→[退款成功]→[已退款]
└─→[退货成功]→[已退货]状态机图的价值：开发看了状态机，就知道"每一种状态变化应该触发什么逻辑"。产品经理看了状态机，就知道"哪些状态转换容易出错"。很多订单bug，根源都是状态机没画清楚。
四张图不是"全部要画"，而是"根据需要选择"。C端产品优先画业务流程图和状态机图。B端产品优先画功能架构图和信息架构图。没有标准答案，只有最适合你的选择。
四张图的适用场景
| 图类型 | 回答的问题 | 最适合的产品 | 优先级 |
|---|---|---|---|
| 信息架构图 | 有哪些数据？ | B端、平台型产品 | 中 |
| 功能架构图 | 功能如何组织？ | 所有产品 | 高 |
| 业务流程图 | 流程是什么？ | C端、交易类产品 | 高 |
| 状态机图 | 状态有哪些？ | 有状态变化的实体 | 高 |
5.2 产品架构实战
5.2.1 思维导图与流程图工具运用
好的工具让架构设计效率提升10倍。我用过的工具里，有三个最推荐。
工具一：XMind（思维导图）
适合画：功能清单表、信息架构图、功能架构图
XMind的优势是结构清晰、层次分明，适合梳理"包含关系"——"A模块包含B和C，B包含D和E"。缺点是对流程图和状态机图支持不好。
使用技巧：用XMind的"大纲模式"直接生成功能清单。每一行包含"模块/功能/描述/优先级"，在XMind里一目了然。
工具二：ProcessOn（在线流程图）
适合画：业务流程图、状态机图
ProcessOn的优势是在线协作，团队可以同时编辑。模板库丰富，直接选用模板改一改就行。缺点是需要联网，离线体验一般。
使用技巧：用ProcessOn的泳道图来画跨角色的流程。每个泳道代表一个角色，横向看就能看到每个角色的工作。
工具三：Figma（设计协作）
适合画：所有类型的图（如果你愿意的话）
Figma的优势是设计工具的精度，适合画需要给设计师参考的架构图。缺点是学习曲线稍高，不如前两者"轻量"。
使用技巧：用Figma的框架工具画信息架构图。框架内可以嵌套框架，层次关系很清楚。
5.2.2 实战案例：资讯App产品架构搭建
用一个完整的案例，把"1张表、4张图"串起来。
背景
做一个面向职场人士的新闻资讯App，核心功能：新闻浏览、话题讨论、个人中心。
步骤一：功能清单表
| ID | 模块 | 功能名称 | 功能描述 | 用户角色 | 优先级 |
|---|---|---|---|---|---|
| F001 | 首页 | 推荐流 | 算法推荐新闻 | 消费者 | P0 |
| F002 | 首页 | 分类浏览 | 按分类查看新闻 | 消费者 | P1 |
| F003 | 首页 | 搜索 | 搜索新闻和话题 | 消费者 | P1 |
| F004 | 详情 | 新闻阅读 | 阅读新闻正文 | 消费者 | P0 |
| F005 | 详情 | 评论 | 对新闻发表评论 | 消费者 | P0 |
| F006 | 详情 | 收藏 | 收藏新闻 | 消费者 | P1 |
| F007 | 话题 | 话题列表 | 浏览热门话题 | 消费者 | P1 |
| F008 | 话题 | 话题讨论 | 在话题下参与讨论 | 消费者 | P1 |
| F009 | 用户 | 登录注册 | 账户体系 | 访客/用户 | P0 |
| F010 | 用户 | 个人信息 | 修改昵称头像等 | 用户 | P1 |
| F011 | 用户 | 收藏管理 | 管理收藏的新闻 | 用户 | P1 |
| F012 | 用户 | 阅读历史 | 查看历史浏览记录 | 用户 | P2 |
步骤二：信息架构图
用户数据
├── 账户（手机号、密码、第三方绑定）
├── 资料（昵称、头像、简介）
├── 行为（收藏记录、阅读历史）
└── 社交（关注、粉丝）
内容数据
├── 新闻（标题、正文、作者、来源、发布时间）
├── 分类（分类ID、名称、图标）
├── 评论（内容、用户、新闻、时间）
└── 话题（标题、描述、参与人数、热度）
系统数据
├── 推送记录
├── 广告配置
└── 内容推荐模型步骤三：功能架构图
┌────────────────────┐
│ 内容展示层 │
│ [首页推荐] [分类] [搜索] [话题] │
└────────────────────┘
↑
┌────────────────────┐
│ 内容运营层 │
│ [内容推荐] [搜索排序] [话题热度] │
└────────────────────┘
↑
┌────────────────────┐
│ 内容供给层 │
│ [新闻采集] [内容处理] [内容审核] │
└────────────────────┘
↑
┌────────────────────┐
│ 基础能力层 │
│ [用户] [权限] [搜索] [推送] [数据] │
└────────────────────┘步骤四：业务流程图
核心流程——阅读新闻：
打开App → 首页推荐流 → 点击新闻卡片 → 进入详情页 → 阅读正文 →
发表评论 → 收藏 → 返回首页 → 浏览其他内容 → 退出App扩展流程——搜索新闻：
点击搜索入口 → 输入关键词 → 展示搜索建议 → 点击搜索 →
加载搜索结果 → 点击结果 → 进入详情页异常流程——新闻加载失败：
点击新闻卡片 → 加载中（3秒）→ 加载失败（超时/网络异常）→
显示错误页 → 重试按钮 → 重试加载 → 加载成功步骤五：状态机图
评论状态机：
[待发布] --点击发送--> [发布中]
↓ 成功
[已发布] --被删除--> [已删除]
↓ 被举报
[审核中] --通过--> [已发布]
--不通过--> [已删除]收藏状态机：
[未收藏] --点击收藏--> [已收藏]
↓
[取消收藏] --> [未收藏]架构设计不是"一次性完成"的工作，而是在产品迭代中持续完善的。新功能上线后要更新架构图，改了架构图要同步更新PRD——保持文档的一致性，比文档本身更重要。
产品架构迭代检查清单
| 检查项 | 频率 | 说明 |
|---|---|---|
| 功能清单更新 | 每次版本规划时 | 新增功能加入清单 |
| 信息架构更新 | 涉及数据结构变更时 | 和开发对齐数据模型 |
| 流程图更新 | 流程发生重大变更时 | 老流程作废，新流程替换 |
| 状态机更新 | 涉及状态变更时 | 和开发对齐状态逻辑 |
本章小结：产品架构是产品经理的"底层能力"。1张表（功能清单表）把你要做的事情列清楚，4张图（信息架构图、功能架构图、业务流程图、状态机图）从四个维度把产品结构表达清楚。架构清晰了，后面的设计、评审、开发才会顺畅。
| 本章核心知识点 | 一句话总结 |
|---|---|
| 功能清单表 | 所有功能的完整列表，含优先级和依赖 |
| 信息架构图 | 产品有哪些数据，数据之间的关系 |
| 功能架构图 | 功能如何分层组织，底层和上层的关系 |
| 业务流程图 | 用户做一件事的完整路径，含分支和异常 |
| 状态机图 | 一个实体的所有状态，以及状态之间的转换关系 |
| 工具选择 | XMind梳理结构，ProcessOn画流程，Figma做精细设计 |
觉得有用？收藏起来，下次画产品架构直接照抄模板。
你画架构图时踩过什么坑？评论区说说。
关注怕浪猫，下期我们讲"交互原型设计"——Axure怎么用、原型怎么画、交互状态怎么设计，怕浪猫带你从零开始搞定原型。
系列进度 5/16
下章预告： 第6章是产品经理的手艺活。原型的画法看似简单，但大多数人画出来的原型——要么太简陋（没有交互），要么太花哨（开发做不出来）。下一章，我教你如何画一个"开发看了就知道怎么做"的原型。