产品架构
产品架构是把产品的所有要素组织起来的结构——不仅是文档，更是产品经理的”底层能力”和日常工具。核心方法论：1张功能清单表作为地基，4张图（信息架构图、功能架构图、业务流程图、状态机图）从四个维度把产品结构表达清楚。
简介
产品架构（Product Architecture）是产品经理的核心基本功——把人脑处理不了的复杂性（200个功能点、50个流程节点、30个角色）通过结构化的图表表达清楚。好的架构设计让产品的评审、开发和迭代顺畅进行；没有架构设计，所有功能都像散落一地的小零件，改一个地方可能引发三个地方的问题。
产品架构的价值体现在三个层面：
- 系统化思考的工具：画架构的过程就是强迫自己思考模块关系、依赖关系的过程
- 团队沟通的媒介：一图胜千言，花10分钟讲清楚架构图比写1000字设计说明更有用
- 迭代决策的依据：架构图告诉你”改A会影响B”，让你知道改动的影响范围
产品架构不是”写完就完了”的文档，而是”一直在用”的工具——每次迭代都应该拿出来对照。
关键信息
| 维度 | 说明 |
|---|---|
| 核心方法论 | 1张表（功能清单表）+ 4张图（信息架构图、功能架构图、业务流程图、状态机图） |
| 地基 | 功能清单表，包含ID、模块、功能、描述、角色、优先级、依赖七个字段 |
| 四张图定位 | 信息架构→数据关系、功能架构→分层组织、业务流程→用户路径、状态机→状态转换 |
| 适用场景 | 需求评审、团队沟通、迭代决策、新人入职、架构review |
| 核心原则 | 架构清晰了，后面的设计、评审、开发才会顺畅；持续迭代而非一次性完成 |
| 相关方法 | 业务设计四步法、产品信息架构AI产品四层模型 |
核心特性
1. 1张表：功能清单/需求矩阵
功能清单表是产品架构的”地基”——没有这张表，所有架构图都是空中楼阁。
标准结构（7个字段）：
| ID | 模块 | 功能名称 | 功能描述 | 用户角色 | 优先级 | 依赖功能 |
模块划分的两种思路：
- 按业务域划分（适合复杂B端系统）：用户域、内容域、交易域、社交域等，每个域对应一个业务闭环
- 按页面/功能入口划分（适合C端产品）：首页Tab、搜索Tab、发布Tab、消息Tab、我的Tab等，按用户实际使用的入口组织
自检标准（画完功能清单表后必问的三个问题）：
- 每一行都有明确的用户角色吗？没有用户角色的功能是”假功能”
- 每一行都有清晰的优先级（P0/P1/P2/P3）吗？不是给老板看的，是给自己排版本用的
- 依赖关系是否完整？任何一个P0功能如果依赖了P2功能，优先级应该提升
2. 第1张图：信息架构图
回答的问题：“产品里有哪些信息，这些信息之间是什么关系？”
典型结构（以电商为例）：
- 商品信息：基础信息（名称、价格、库存）→ 详情信息（图片、描述、规格）→ 评价信息（评分、内容）
- 用户信息：账户信息 → 收货信息 → 资产信息
- 订单信息：订单基础信息 → 订单商品信息 → 订单支付信息
价值：帮助设计师理解”数据模型”，帮助开发理解”数据库设计”，是前后端沟通的基础。好的信息架构让数据关系一目了然。
已有 产品信息架构 实体页从AI产品视角建立了四层架构模型（用户层/技术层/模型层/基础层），本篇从传统PM视角补充了信息架构作为”数据模型表达”的维度——两者互补：AI产品四层模型回答”产品怎么运作”，本文信息架构图回答”数据怎么组织”。
3. 第2张图：功能架构图
回答的问题：“产品的功能是怎么组织的？哪些是底层能力，哪些是上层应用？”
典型四层结构（以内容平台为例）：
内容展示层（首页推荐、搜索结果、个人主页、详情页）
↑
内容运营层（话题管理、内容审核、推荐算法、搜索排序）
↑
内容供给层（发布器、内容处理、媒资管理、创作者工具）
↑
基础能力层（用户体系、权限体系、通知体系、数据分析）
核心价值：让你看清楚”复用关系”——如果两个功能都要用”搜索排序”，应该做成底层能力而非重复实现两次。功能架构图揭示了系统设计中的DRY原则（Don’t Repeat Yourself）。
4. 第3张图：业务流程图
回答的问题：“用户做一件事，要经历哪些步骤，每一步是什么？”
构成要素：
- 核心流程（happy path）：从起点到终点的正常用户路径
- 扩展流程（分支）：包括正常分支（库存充足→加入成功）和条件分支（未登录→跳转登录）
- 异常流程（edge cases）：库存不足提示、支付超时关闭、网络异常加载失败等
核心价值：帮你穷举所有可能。用户走的每一条路，都要提前想清楚。没有业务流程图，上线后就会出现各种”没想到的bug”。
与 业务设计 四步法的关系：业务流程图为四步法中”描现状（As-Is）“和”设计未来（To-Be）“提供了标准化的表达工具。
5. 第4张图：状态机图
回答的问题：“一个实体（订单、内容、用户）有哪些状态，这些状态之间是怎么转换的？”
核心要素：
- 状态节点：实体可能处于的所有状态（如订单：待付款→待发货→待收货→已完成）
- 转换条件：触发状态变化的操作或事件（付款成功、商家发货、确认收货）
- 异常路径：取消、退款、退货等非正常路径
核心价值：开发看了就知道每种状态变化应该触发什么逻辑，PM看了就知道哪些状态转换容易出错。很多订单bug的根源都是状态机没画清楚。
与 状态机驱动按钮显隐 实体页的关系：状态机驱动按钮显隐 聚焦”状态枚举驱动前端按钮显隐”这一B端设计模式（后端状态枚举定义可操作动作集合，前端按集合渲染），是状态机图在具体设计场景中的深化应用。
6. 四张图的适用场景选择
| 图类型 | 回答的问题 | 最适合的产品 | 优先级 |
|---|---|---|---|
| 信息架构图 | 有哪些数据？关系是什么？ | B端、平台型产品 | 中 |
| 功能架构图 | 功能如何分层组织？ | 所有产品 | 高 |
| 业务流程图 | 用户做一件事的完整路径？ | C端、交易类产品 | 高 |
| 状态机图 | 一个实体有哪些状态？如何转换？ | 有状态变化的实体 | 高 |
选择原则：不是四张图”全部要画”，而是”根据需要选择”。C端产品优先画业务流程图和状态机图（用户交互密集+状态变更频繁），B端产品优先画功能架构图和信息架构图（系统复杂度高+数据模型关键）。
7. 工具选择
- XMind（思维导图）：适合功能清单表、信息架构图、功能架构图——结构清晰、层次分明，大纲模式可直接生成功能清单
- ProcessOn（在线流程图）：适合业务流程图、状态机图——在线协作、模板库丰富，泳道图可画跨角色流程
- Figma（设计协作）：适合所有类型，尤其是需要给设计师参考的精细架构图——框架内嵌套框架，层次关系很清楚
8. 架构迭代检查清单
| 检查项 | 频率 | 说明 |
|---|---|---|
| 功能清单更新 | 每次版本规划时 | 新增功能加入清单 |
| 信息架构更新 | 涉及数据结构变更时 | 和开发对齐数据模型 |
| 流程图更新 | 流程发生重大变更时 | 老流程作废，新流程替换 |
| 状态机更新 | 涉及状态变更时 | 和开发对齐状态逻辑 |
不同素材中的观点
《第5章 搭建产品架构 — 1张表、4张图》（怕浪猫，2026-08-10）
核心主张： 产品架构是产品经理的”底层能力”，不讲理论只讲实操。1张表（功能清单表）把要做的事情列清楚，4张图（信息架构图、功能架构图、业务流程图、状态机图）从四个维度把产品结构表达清楚。架构清晰了，后面的设计、评审、开发才会顺畅。
方法论要点：
- 功能清单表的自检三问（用户角色/优先级/依赖关系）是防”假功能”的核心机制
- 功能架构图的核心价值是揭示复用关系——底层能力不重复实现
- 业务流程图要穷举所有路径，包括异常流程
- 状态机图要穷举所有状态转换，包括非正常路径
- 架构设计是在产品迭代中持续完善的，不是一次性完成的工作
工具推荐：
- XMind梳理结构、ProcessOn画流程、Figma做精细设计，三者各有定位互不替代
实操内容： 提供了完整的功能清单表模板、信息架构示例、功能架构分层结构、业务流程含异常处理、状态机含退货路径，以及一个资讯App从零搭建的完整实战案例（12个功能、3层数据架构、4层功能架构、含异常的业务流程、评论和收藏两个状态机）。
实用信息
不同类型产品的架构侧重
C端产品（如电商App、社交App、内容App）：
- 优先：业务流程图 + 状态机图（用户交互密集、状态变更频繁）
- 补充：功能架构图（看清底层能力复用关系）
- 信息架构图：中等优先级
B端产品（如SaaS后台、ERP系统、审批系统）：
- 优先：功能架构图 + 信息架构图（系统复杂度高、数据模型关键）
- 补充：状态机图（审批流、工单状态等）
- 业务流程图：中等优先级（但跨角色场景下泳道图很关键）
AI产品：
- 额外需要考虑：模型层（模型能力边界）、技术层（Prompt/RAG/Agent编排）
- 参考 产品信息架构 的四层AI产品架构模型
- 与传统产品架构图叠加使用，不是替代关系
绘制顺序建议
- 先画功能清单表：所有图表的地基，把功能列清楚再画图
- 再画业务流程图：从用户视角出发，理解完整用户旅程
- 然后画状态机图：识别流程中涉及的关键实体及其状态变化
- 再画信息架构图：从数据和信息的角度重新审视产品
- 最后画功能架构图：综合前三张图的发现，进行系统分层设计
常见误区
- 跳过高楼地基直接画图：不画功能清单表就直接画架构图，容易遗漏功能或重复设计
- 只画主流程不画异常流程：上线后80%的bug来自那20%没画出来的异常路径
- 状态机只画正向路径：取消、退款、回退、撤销等反向路径往往比正向更难设计
- 架构图更新滞后于产品迭代：架构图成了”历史遗迹”而非”活文档”