功能架构图的读者是产品经理、业务方和管理层，不是研发。这个前提决定了它的所有画法：不出现技术名词、不体现实现方式、不关心调用关系，只回答一件事——这个产品能帮用户做什么，这些能力怎么归类。
最常见的画错方式是按技术模块分组。把"消息推送服务"和"站内信服务"分成两个模块，是研发视角；用户只知道"我要及时收到通知"，这两个东西在他眼里是一件事。
一、和另外三张图的区别
这四张图经常被混着叫，先分清楚：
| 图 | 回答什么 | 读者 | 节点是什么 |
|---|---|---|---|
| 功能架构图 | 产品有哪些能力 | 产品、业务方 | 功能模块 |
| 系统架构图 | 技术上怎么构成 | 研发、架构师 | 服务、组件 |
| 信息架构图 | 内容怎么组织和导航 | 设计师 | 页面、层级 |
| 产品结构图 | 页面之间怎么跳转 | 设计、前端 | 页面、入口 |
判断口诀：说"能做什么"是功能架构，说"怎么实现"是系统架构，说"在哪里找到"是信息架构，说"从哪跳到哪"是产品结构。
系统架构图的画法可以看架构图怎么画，这篇只讲功能架构。
二、三步：清单 → 分组 → 定层
第一步：列全功能点。
从 PRD、需求池、现有产品菜单里把所有功能列出来。这一步只求全，不管归属和粒度。一个成熟产品通常能列出 80–200 个功能点。
写功能点时统一用"动词 + 宾语"，从用户视角描述：写"导出报表"不写"报表导出模块"，写"批量修改状态"不写"状态管理"。
第二步：按用户目标分组。
把功能点摊开，问自己：用户在什么情况下会用到它？ 用同一个目标驱动的功能归到一组。
举个反例和正例的对比：
❌ 按技术分组：用户服务 / 订单服务 / 消息服务 / 报表服务
✅ 按目标分组：找到合适的商品 / 完成购买 / 跟踪订单 / 处理售后
后者一眼能看出产品覆盖了用户的哪些环节，也能看出哪个环节的能力薄弱。
第三步：定层级。
- 一级模块 4–8 个
- 每个一级下 3–7 个二级模块
- 三级到具体功能点
总层级不超过三层。 需要第四层通常意味着一级分得太粗，或者某个模块本身应该独立成一张图。
三、粒度不齐怎么办
功能架构图最常见的问题是同层粒度不一致——一级模块里既有"用户中心"（包含二十个功能）又有"意见反馈"（就一个页面）。
检查方法：把同一层的名称念一遍，如果某一项明显比其他项小一个量级，就要处理。
三种处理方式：
- 上提——把过小的项并入相关的大模块
- 下沉——把过大的项拆成两个平级模块
- 重新找维度——如果调整之后还是不齐，说明分组维度选错了，回到第二步
四、从 PRD 提取功能点
大多数功能架构图的起点是一份或多份 PRD。手工提取的问题是量大且容易漏。
比较高效的做法是把 PRD 文档拖进画布，让 AI 先提取出功能点清单和初步分组，再由你做三件事：
- 修正分组维度——AI 倾向于按文档章节分组，需要改成按用户目标分组
- 调整粒度——把明显不同量级的项拉齐
- 补充文档没写的——权限、设置、通知这类横向能力，PRD 里常常分散在各处
生成结果是画布上的可编辑元素，模块可以拖动重组、层级可以调整，比在文档里改列表直观得多。英飞·思想家支持 PDF、Word 等 14+ 种格式承载，AI 读取内容后生成的结构可以继续编辑和协作。
五、几种实用的标注
功能架构图除了结构本身，加上几种标注会更有用：
版本标注。 用颜色区分"已上线 / 开发中 / 规划中 / 暂不做"。一张图同时表达现状和规划，评审时省一半解释。
优先级标注。 结合KANO 模型的分类，标出哪些是基本型、期望型、兴奋型能力。
竞品对照。 在模块上标注竞品是否具备，能直观看出能力差距。这需要配合竞品分析的结论。
用户角色标注。 多角色产品里标出每个模块主要服务哪类角色，能看出资源分配是否合理。
标注不要同时加太多，一张图最多两种，否则会盖过结构本身。加了标注就要有图例。
六、什么时候需要更新
功能架构图是产品的地图，过期的地图比没有地图更危险。三个更新时机：
- 每个版本发布后——把"开发中"改成"已上线"，这是最低成本的维护
- 产品方向调整时——分组维度可能需要重新设计
- 新人入职前——功能架构图是最好的产品介绍材料，确保它是最新的
放在能改的地方是前提。 存成 PNG 塞进网盘的图，三个月后没人会更新它。放在可编辑的画布上，改一个模块是十秒钟的事。
七、和其他产品文档放在一起
功能架构图很少单独使用。放在同一块画布上的配套内容：
- 用户旅程图——看每个功能对应用户旅程的哪个环节，能发现哪些环节缺少支撑
- 需求池——新需求进来时直接放到对应模块旁边，看它是补强还是新增
- 竞品的功能架构图——并排放，差距一目了然
- PRD 原文——某个模块的细节定义直接翻到旁边
无限画布支持这几类内容同屏组合，缩小看全局、放大看细节，配合实时协作和节点级批注，评审时的意见直接标在具体模块上。
常见问题
功能架构图和系统架构图有什么区别？
功能架构图描述产品能力和分组，读者是产品和业务方；系统架构图描述技术组件和依赖，读者是研发。同一个产品的两张图差别很大。
一级模块分几个合适？
4–8 个。少于 4 个说明拆得不够，多于 8 个读者记不住，应该考虑上一层的归纳。
该按用户目标还是按业务模块分组？
按用户目标。业务模块是内部视角，按它分组会让业务方也看不懂自己的产品覆盖了用户的哪些环节。
能从 PRD 自动生成吗？
可以把 PRD 拖进画布让 AI 提取功能点和初步分组，再人工把分组维度改成按用户目标，并拉齐粒度。
要不要标注开发状态？
建议标。用颜色区分已上线、开发中、规划中，一张图同时表达现状和规划，评审时更高效。
结语
功能架构图画得好不好，只看两件事：分组是不是按用户目标、同层粒度是不是一致。这两条做到，图就能被业务方看懂；做不到，再规整的排版也是自说自话。
从 PRD 提取清单只是起点，真正花时间的是重新分组。画完记得放在能随时改的地方，让它跟着产品一起长。