第5章 搭建产品架构 — 1张表、4张图
产品架构是产品经理的”底层能力”。不讲理论，只讲实操——1张功能清单表 + 4张架构图，帮你把任何产品的架构搭得清清楚楚。
基本信息
| 维度 | 说明 |
|---|---|
| 来源 | 掘金（怕浪猫系列第5章，系列进度5/16） |
| 类型 | 产品经理实操教程 |
| 字数 | ~4,233 字 |
| 核心主题 | 产品架构设计方法论 |
核心观点
-
产品架构的本质是”把所有产品要素组织起来的结构”：产品经理脑子里装着200个功能点、50个流程节点、30个角色——不画出来，根本理不清。产品架构有三个价值：系统化思考的工具、团队沟通的媒介、迭代决策的依据。
-
1张表（功能清单表）是产品架构的”地基”：包含ID、模块、功能名称、功能描述、用户角色、优先级、依赖功能七个字段。模块划分有两种思路——按业务域划分（适合复杂B端系统）或按页面/功能入口划分（适合C端产品）。自检三问：每一行都有明确的用户角色吗？每一行都有清晰的优先级吗？依赖关系是否完整？
-
4张图从四个维度表达产品结构：信息架构图（回答”产品里有哪些数据，关系是什么”）、功能架构图（回答”功能如何分层组织”）、业务流程图（回答”用户做一件事的完整路径”）、状态机图（回答”一个实体有哪些状态，状态之间如何转换”）。C端产品优先画业务流程图和状态机图，B端产品优先画功能架构图和信息架构图——没有标准答案，只有最适合的选择。
-
产品架构不是”写完就完了”的文档，而是”一直在用”的工具：好的架构图每次迭代都应该拿出来对照。四张图对应四种迭代检查频率——功能清单每次版本规划时更新、信息架构涉及数据结构变更时更新、流程图流程发生重大变更时更新、状态机涉及状态变更时更新。
-
三种推荐工具各有定位：XMind（思维导图）梳理结构和包含关系；ProcessOn（在线流程图）画业务流程和状态机图，支持在线协作；Figma（设计协作工具）画需要给设计师参考的精细架构图。XMind的大纲模式可直接生成功能清单。
实操内容保留
功能清单表模板
| ID | 模块 | 功能名称 | 功能描述 | 用户角色 | 优先级 | 依赖功能 |
|---|---|---|---|---|---|---|
| F001 | 用户 | 注册 | 手机号+验证码注册 | 访客 | P0 | 无 |
| F002 | 用户 | 登录 | 手机号+验证码登录 | 访客 | P0 | F001 |
| F003 | 内容 | 发帖 | 发布图文/视频内容 | 创作者 | P0 | F001,F002 |
| F004 | 内容 | 浏览 | 列表流浏览内容 | 消费者 | P0 | 无 |
| F005 | 内容 | 评论 | 对内容发表评论 | 消费者 | P1 | F001,F004 |
模块划分思路一：按业务域划分（适合B端）
| 业务域 | 说明 | 模块示例 |
|---|---|---|
| 用户域 | 用户相关的一切 | 注册、登录、资料、会员 |
| 内容域 | 内容生产与消费 | 发帖、浏览、搜索、推荐 |
| 交易域 | 交易与支付 | 购物车、订单、支付、售后 |
| 社交域 | 社交互动 | 点赞、评论、关注、消息 |
模块划分思路二：按页面/功能入口划分（适合C端）
| 入口 | 包含功能 |
|---|---|
| 首页Tab | 推荐流、分类入口、搜索入口 |
| 搜索Tab | 搜索框、历史记录、搜索结果 |
| 发布Tab | 发布器、内容编辑、话题选择 |
| 消息Tab | 评论、赞、关注、系统通知 |
| 我的Tab | 个人信息、设置、钱包、订单 |
信息架构图示例（电商App）
商品信息
├── 商品基础信息（名称、价格、库存）
├── 商品详情信息（图片、描述、规格）
└── 商品评价信息（评分、评价内容）
用户信息
├── 账户信息（手机、密码、昵称）
├── 收货信息（地址簿）
└── 资产信息（积分、优惠券、余额）
订单信息
├── 订单基础信息（订单号、时间、状态）
├── 订单商品信息（商品快照、数量）
└── 订单支付信息（支付方式、金额）
功能架构图示例（内容平台）
┌─────────────────────────────────────────┐
│ 内容展示层 │
│ [首页推荐] [搜索结果] [个人主页] [详情页] │
└─────────────────────────────────────────┘
↑
┌─────────────────────────────────────────┐
│ 内容运营层 │
│ [话题管理] [内容审核] [推荐算法] [搜索排序] │
└─────────────────────────────────────────┘
↑
┌─────────────────────────────────────────┐
│ 内容供给层 │
│ [发布器] [内容处理] [媒资管理] [创作者工具] │
└─────────────────────────────────────────┘
↑
┌─────────────────────────────────────────┐
│ 基础能力层 │
│ [用户体系] [权限体系] [通知体系] [数据分析] │
└─────────────────────────────────────────┘
业务流程图示例（电商下单，含扩展流程）
开始 → 浏览商品 → 点击详情 → 选择规格 → 加入购物车 →
去购物车结算 → 确认订单 → 选择地址 → 选择支付方式 →
确认支付 → 跳转支付 → 支付成功 → 生成订单 → 结束
扩展流程：
加入购物车
├── 库存充足 → 加入成功
├── 库存不足 → 提示"已售罄" / "到货通知"
└── 未登录 → 跳转登录 → 登录后继续
确认支付
├── 余额充足 → 支付成功
├── 余额不足 → 提示"余额不足"
└── 支付超时 → 订单关闭
状态机图示例（订单状态机）
[待付款] --付款成功--> [待发货] --商家发货--> [待收货] --确认收货--> [已完成]
↑ | |
└─────取消/退款───────┴───申请退款─────────┘
更复杂的状态机（考虑退货）：
[待付款]
│
↓ 付款成功
[待发货]
│
↓ 商家发货
[待收货]
│
├─→[确认收货]→[已完成]
│
└─→[申请退款/退货]→[退款/退货中]
│
├─→[退款成功]→[已退款]
└─→[退货成功]→[已退货]
资讯App完整实战案例
功能清单表（12个功能）：
| 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 |
评论状态机：
[待发布] --点击发送--> [发布中]
↓ 成功
[已发布] --被删除--> [已删除]
↓ 被举报
[审核中] --通过--> [已发布]
--不通过--> [已删除]
产品架构迭代检查清单：
| 检查项 | 频率 | 说明 |
|---|---|---|
| 功能清单更新 | 每次版本规划时 | 新增功能加入清单 |
| 信息架构更新 | 涉及数据结构变更时 | 和开发对齐数据模型 |
| 流程图更新 | 流程发生重大变更时 | 老流程作废，新流程替换 |
| 状态机更新 | 涉及状态变更时 | 和开发对齐状态逻辑 |
四张图的适用场景总览
| 图类型 | 回答的问题 | 最适合的产品 | 优先级 |
|---|---|---|---|
| 信息架构图 | 有哪些数据？ | B端、平台型产品 | 中 |
| 功能架构图 | 功能如何组织？ | 所有产品 | 高 |
| 业务流程图 | 流程是什么？ | C端、交易类产品 | 高 |
| 状态机图 | 状态有哪些？ | 有状态变化的实体 | 高 |
关键概念
- 产品架构 — 把所有产品要素组织起来的结构，产品经理的底层能力
- 产品信息架构 — 信息架构图回答”产品里有哪些数据，数据之间是什么关系”（已有实体页覆盖）
- 功能清单表 — 产品架构的”地基”，所有功能的完整列表含优先级和依赖（见本文实操模板）
- 功能架构图 — 功能如何分层组织，底层能力与上层应用的关系
- 业务流程图 — 用户做一件事的完整路径，含分支和异常流程
- 状态机图 — 一个实体的所有状态及状态之间的转换关系（已有状态机驱动按钮显隐实体页覆盖B端设计模式）
- XMind — 思维导图工具，适合梳理结构和包含关系
- ProcessOn — 在线流程图工具，适合画业务流程和状态机图，支持在线协作
- Figma — 设计协作工具，可用于画精细架构图（已有实体页）
与其他素材的关联
- 与 产品信息架构 互补：已有实体页聚焦AI产品的四层架构模型（用户层/技术层/模型层/基础层），本篇补充了传统PM视角的”1张表+4张图”完整方法论，两者共同构成产品架构的知识全貌。
- 与 状态机驱动按钮显隐 衔接：已有实体页聚焦”状态枚举驱动前端按钮显隐”这一B端设计模式，本篇提供了更通用的状态机图绘制方法和模板。
- 与 业务设计 四步法同构：本文的”4张图”（信息架构、功能架构、业务流程、状态机）与业务设计步骤中”描现状”和”设计未来”所需的工具重合，可作为业务设计过程中的执行工具。
- 与 Figma 实体页补充：已有实体页主要覆盖Figma的设计协作和AI功能，本篇增加了Figma作为产品架构图绘制工具的定位。
原文精彩摘录
产品架构不是”写完就完了”的文档，而是”一直在用”的工具。好的架构图，每次迭代都应该拿出来对照。
业务流程图的价值：帮你穷举所有可能。用户走的每一条路，你都要提前想清楚。没有业务流程图，上线后就会出现各种”没想到的bug”。
状态机图的价值：开发看了状态机，就知道”每一种状态变化应该触发什么逻辑”。产品经理看了状态机，就知道”哪些状态转换容易出错”。很多订单bug，根源都是状态机没画清楚。
架构设计不是”一次性完成”的工作，而是在产品迭代中持续完善的。新功能上线后要更新架构图，改了架构图要同步更新PRD——保持文档的一致性，比文档本身更重要。