企业官网建设流程全解析

需求评审开到第三轮，会议室里翻来覆去还是那几句话：这个功能到底算谁的、改这里会不会连带影响那边、当初说好的到底是什么样。这类会我开过太多次，绝大多数时候问题不出在人身上，而是大家脑子里装的是不同的系统：有人想的是页面菜单，有人想的是接口调用，有人想的是业务动作，三张完全不同的图在同一个房间里打架，讨论当然对不齐。

功能图就是用来终结这种各说各话的工具。它把系统拆成一棵自上而下的功能树，每个节点是一个边界清晰的能力单元，节点之间有层级归属，节点和需求条目之间有映射关系。做需求澄清的时候，它是团队共同语言；做变更评估的时候，它是影响范围的坐标系；做版本规划的时候，它又是一张能看清工作量的地图。这篇内容适合三类人：刚接手需求分析、还分不清几种图区别的新人；被变更追着跑、每次评估都靠拍脑袋的项目负责人；以及想把需求文档从纯文字升级成结构化表达的团队成员。下面我按自己做过的几个项目，把功能图从概念到落地这条链路完整走一遍。

1. 先搞清楚"功能图"到底指什么：四种图的分工与误用

1.1 功能结构图、功能流程图、用例图、业务流程图不是一回事

这四个词在团队里经常被混着用，导致的直接后果是：会上有人说"你画个功能图"，三个人掏出三种东西。我习惯用下面的方式把它们掰开。

功能结构图是静态的，回答"系统能提供哪些能力"，节点是能力单元，连线是归属关系。它像一本书的目录，你看到的是分类和层级，看不到阅读顺序。

功能流程图是动态的，回答"完成一件事要经过哪些环节"，节点是步骤，连线是先后顺序。它像菜谱，重点是顺序和判断分支。

用例图是角色视角的，回答"谁能用系统做什么"，节点是参与者与用例，连线是关联。它擅长暴露角色和权限，但不擅长展示系统内部的功能分解。

业务流程图是跨角色、跨系统的，回答"业务价值怎么从一个人传到另一个人"，节点常常包含系统之外的人工动作。

对比维度如下表，这张表我在好几次内部培训里都用到过：

选错图的代价很实在。用流程图代替结构图去做需求对齐，你会发现每个人只盯着自己负责的那一段，没人看整体完整性；用结构图代替流程图去做流程梳理，又会出现"步骤全在、顺序全错"的尴尬。做需求对齐这件事，主力工具应该是功能结构图，另外三种图作为补充，在特定问题上补位。

1.2 为什么大多数人画的功能图既不能对齐需求也不能分析变更

我接手过不少别人画好的功能图，真正能用的比例不高。问题集中在几个地方，每一个我都见过不止一次。

第一种是把菜单结构当功能结构。打开系统截个图，把左侧导航栏抄下来，横向菜单变成一级节点，页面里的标签页变成二级节点。这种做法最省事，也最没用。页面会因为交互优化合并或拆分，会因为终端差异（桌面端、移动端）呈现不同，但底层功能并没有变。一旦页面改版，这张图就全废了，而它本应该是最稳定的那份资产之一。判断方法很简单：如果你的功能图上有"首页""个人中心""设置"这种纯导航词，基本就可以判定是从菜单抄的。

第二种是层级里混了粒度。我见过一张图，"用户管理"下面挂着"新增用户""编辑用户""删除用户""导入用户"，旁边另一个分支"订单管理"下面挂着"订单创建""订单查询""订单退款""订单结算""订单对账"。表面看都是三层结构，实际上左边的二级节点全是原子操作，右边的二级节点是业务子域，两者根本不在一个粒度上。后果是评审时没法一起讨论，因为讨论左边是在聊按钮，讨论右边是在聊业务规则，话题根本不在一个频道。

第三种是命名不承载语义。节点写成"订单""用户""数据"，这是名词，看不出系统要做什么动作；或者写成"处理""维护""管理"，这是动词，看不出处理的是什么对象。还有一种更麻烦的，叫"综合管理"，一个节点下面塞了七八个不相关的东西，实际上是个垃圾桶，凡是归不进去的都往里扔。这种节点在变更分析时是灾难，因为你永远说不清改它到底会影响什么。

第四种是没有稳定编号。节点不能引用，评审时只能说"就那个、左边第三个框、下面那个分支"，指代一旦多起来就彻底乱套。文档里写"参见功能图"，等于没写。编号看起来是小细节，实际上决定了这张图能不能被当作可引用的基准物来使用。

第五种是画完就锁进抽屉。立项时画一张，之后所有变更都靠口头传递，半年后再打开，图上还是半年前的样子。功能图的价值随时间衰减得极快，一张不维护的图比没有图更危险，因为新人会把它当真。

1.3 一张真正可用的功能图要满足四个硬指标

这四个指标是我自己总结的验收标准，每次画完都会对着过一遍。

全覆盖。所有已知需求都能在图上找到归属节点，不能靠"其他"这种兜底节点收口。如果确实有内容归不进去，说明顶层功能域划分漏了一个维度，要回去补，而不是塞进"其他"里假装解决了。

不重叠。同一层级的节点，职责互斥。检验方法是对任意一条需求问"它落在哪个节点"，如果答案有两个以上，就说明边界不清。这一条本质上是分类学里的互斥穷尽原则，听起来学术，落到实际就是：别让两个节点都能干同一件事。

可引用。每个节点有唯一且稳定的编号，文档、工单、缺陷记录里都能直接用编号指代。编号一旦分配就不应该复用，节点删掉了就留空号，这样历史文档里的引用不会指错地方。

可追溯。每个叶子节点至少关联一条需求，每条需求至少落在一个叶子节点上。这条规则双向生效，图上出现没有需求的叶子节点，说明是想象出来的功能；需求列表里出现没有节点的需求，说明分解漏了东西。

2. 功能分解的正确骨架：从系统目标往下拆到可交付单元

2.1 顶层功能域的划分依据，决定了这张图能不能撑过一年

顶层怎么切，是整张图最关键的决定，因为它决定了后续所有变更分析的路径长短。我见过三种主流切法，各有适用场景。

按业务对象或领域切。比如订单、商品、账户、库存、结算。这是我绝大多数情况下推荐的方式，理由很实际：变更几乎总是沿着对象维度发生的。订单相关的规则调整，影响面基本就在订单这个分支下面，评估时顺着分支往下看一遍就够了。而且业务对象是业务方最熟悉的词汇，评审时不需要额外翻译。

按用户角色切。比如买家端功能、卖家端功能、平台运营功能。适合多个角色使用差异极大的系统，比如一个多边平台。缺点是同一个业务对象会散落在多个分支里，订单创建在买家分支，订单处理在卖家分支，订单审核在运营分支，一旦订单的核心规则变了，三个分支都要改，评估容易漏。

按业务流程阶段切。比如售前、售中、售后，或者申请、审批、执行、归档。适合流程性极强的系统，比如审批类、生产管理类。缺点是流程一旦调整，顶层结构就要动，稳定性差。

还有一种我不推荐的切法：按组织结构切。初期看着很顺，因为每个部门对着一个功能域，职责清晰。但组织一调整，图就废了，而组织调整的频率往往比系统功能变化还高。我见过一个项目半年内组织架构换了两次，功能图跟着改了两版，最后没人愿意再碰它。

实际操作中，顶层功能域控制在五到八个比较合适。少于五个说明拆得不够，高层节点下面会挂太多东西；多于十个说明维度没收敛，读者记不住。

2.2 分解到第几层该停：三条判断线

新人最常问的问题是"到底要拆几层"。这个问题没有固定答案，但有三条判断线可以参考。

第一条：叶子节点能在一次迭代内交付，就停。如果一个节点下面还包含多个迭代才能做完的内容，说明它还不是最小交付单元，要继续拆。反过来，如果拆出来的节点小到一次迭代能做好几个，那说明拆过头了，往上收一层。

第二条：再往下就是实现细节，就停。字段、按钮、接口参数、表结构，这些不属于功能结构图的范畴。我见过把"新增用户"继续拆成"用户名字段校验""手机号格式校验""重复用户检测"的，这不是功能分解，这是详细设计。功能图的读者包括业务方，拆到这个层级他们就看不懂了，图也就失去了对齐需求的作用。

第三条：三到四层是大多数业务系统的舒适区。一层系统、二层功能域、三层功能模块、四层具体功能。超过五层，通常意味着两个问题之一：要么中间某一层漏了归类，硬生生多出一层来；要么一条线上混了两个维度，比如既按业务对象分又按操作类型分，导致层级越堆越多。遇到这种情况，别硬拆，回去检查那一层的分类依据是否统一。

2.3 命名规范：动词加名词，以及为什么"管理"是最糟糕的词

命名这件事看起来琐碎，实际上是功能图质量的分水岭。我的规则很土：用动宾结构，动词要具体，名词要是业务词汇。

"管理"这个词的问题在于它什么都是，什么都不是。写"用户管理"，读者不知道你要做增删改查里的哪几个，不知道有没有审批流，不知道涉不涉及权限分配。评审的时候，业务方理解成完整的用户生命周期管理，开发理解成三个接口，双方点完头各自散去，等到验收时才发现差了十万八千里。

我给几个常见的改写对照，都是从实际项目里抄出来的：

另一个容易忽略的点是同一层级不要混用名词型和动词型节点。要么这一层全是业务对象（订单、商品、账户），要么全是功能动作（创建订单、查询订单、取消订单）。混着放会让人分不清层级关系，也会让变更分析时的判断标准不一致。

2.4 功能结构和代码结构是两个视角，别强行对齐

这一点值得单独说，因为我见过不少团队在这上面纠结。有人主张功能图的每个叶子节点对应一个代码模块，图改了代码就得跟着改。这种绑定关系看起来很整齐，实际上会把架构绑死。

功能图描述的是系统对外呈现的能力，代码结构描述的是内部实现的组织方式。两者有 correspondence，但不是一一对应。一个"订单创建"功能，实现上可能涉及订单服务、库存服务、优惠计算服务、消息服务；反过来，一个公共服务模块可能支撑图上的五个不同节点。强行对齐的结果是：为了保持图和代码一致，你要么把代码拆得支离破碎，要么把图改得面目全非。

我的做法是保持两者独立，但在功能节点上标注"主要实现模块"，作为参考信息而不是强约束。这样既保留了追溯能力，也不至于让架构调整被图的形状限制住。

3. 把功能图和需求条目挂上钩：对齐会议怎么开才不跑偏

3.1 双向映射表是整条链路的枢纽

功能图画得再好，如果和需求列表是两套平行体系，那它就只是个装饰品。真正让它产生价值的是中间那张映射表。

表的结构我一般这么设计：

这张表有三条使用规则，比表本身重要。

第一，一对一不是必须的，但空着一定有问题。一条需求落在多个功能节点上是正常的，比如"下单后要给用户发通知"就同时涉及订单创建和消息通知两个节点。但反过来，如果一个叶子节点在需求列上是空的，那就要问清楚：这个功能是本期的还是规划的？如果是规划的就明确标注出来，不要让它伪装成本期内容。

第二，验收标准必须挂到节点上，而不是挂在需求上。需求是描述性的，验收标准是可判定的。挂到节点上之后，每个功能节点就有了明确的完成定义，测试可以照着写用例，开发可以照着做自测。

第三，责任角色这一列不能省。功能图和需求对齐之后，最大的争议往往不是"要做什么"，而是"谁来做"。把责任角色写进表里，评审时就能当场确认，省掉后面无数扯皮。

3.2 功能、角色、数据三列法：找出漏掉的需求

功能图最大的盲区是它只描述"有什么能力"，不描述"谁来用"和"用什么数据"。补上这两块，遗漏的需求会自己浮出来。

具体做法是对每一个叶子节点问三个问题：谁触发这个功能？它需要什么输入数据？它产出什么输出数据？三个答案填满，节点才算完整。

举个实际例子。某后台系统有个"订单导出"节点，初看很完整。填三列的时候问题就出来了：

• 谁触发？原本只写了财务，追问之下发现运营也要用，而且运营要的字段和财务完全不一样。于是这个节点实际上要拆成两个，或者增加一个字段模板配置的子功能。
• 输入数据是什么？时间范围从哪来，是用户手选还是有默认值？数据量有没有上限？超过十万条怎么办，是同步导出还是异步生成文件？
• 输出数据是什么？文件格式是什么，CSV 还是 Excel？字段顺序谁定？含不含敏感信息，导出要不要留审计记录？

一个看起来一句话就能说清的节点，填完三列之后多出了七八条需求。这些需求不是凭空创造的，是原本就存在但没人提起的。我做过统计，用这个方法过一遍功能图，平均每个叶子节点能挖出两到三条被遗漏的需求，比例相当可观。

这个方法本质上是对每个节点做一次完整的上下文补全。功能图给了纵深的分解，三列法给了横向的约束，两者交叉之后，系统的功能边界就基本封闭了。

3.3 评审现场的典型分歧和处理办法

抱着功能图开评审会，分歧会比纯文字评审少很多，但不会消失。我遇到的分歧基本归为三类，每类都有对应的处理方式。

第一类是职责边界分歧。典型表现是两个功能节点都觉得自己应该包含某项能力。比如"消息通知"节点和"订单状态流转"节点都认为发送状态变更短信是自己的职责。这类分歧不要在会上争，直接按一条规则裁决：如果这个能力被两个以上功能用到，就抽出来做成上一层级的公共功能节点。抽出来之后，两个原节点只负责触发，不负责实现，边界立刻清晰。

第二类是粒度分歧。有人说拆得太细，有人说太粗。这类争论没有标准答案，但有裁判标准：能不能独立验收。如果能独立写出一条验收标准、独立测试通过，那它就应该是一个节点；如果两条功能必须一起验收才能判断对不对，那它们就应该合并。用这个标准裁决，比争论谁的直觉更准有效得多。

第三类是命名分歧。技术上讨论命名很容易演变成个人偏好之争。我的处理方式是把话题从"这个名字好不好"拉回到"业务方平时怎么叫它"。功能图的读者里有一半不是技术角色，用业务方自己的词汇，比用技术精确但陌生的词更有价值。遇到确实需要区分的情况，在节点上加一行说明，别在名字里堆定语。

还有一类会议本身的问题：参与者不对。功能图评审必须有三类人在场——业务方代表、实现方代表、测试方代表。缺了业务方，命名和边界会跑偏；缺了实现方，会画出做不出来的东西；缺了测试方，验收标准会写得没法验证。人不到齐，会开了也白开。

4. 变更分析：一张图看出改动会波及哪些模块

4.1 影响面会往四个方向传播

变更分析最怕的是只看眼前。产品经理说"就在列表页加个批量操作，很快的"，然后开发一评估发现要动一周。原因就是只看了变更点本身，没看它往哪传播。

功能图能帮上忙的地方，是它把四个传播方向都可视化了。

向上传播：父节点的职责描述会变。一个功能节点增加了能力，它父节点的描述如果还是原来那句，就失真了。这种失真会累积，改了几轮之后，上层节点描述和实际能力完全对不上，图就废了。所以每次变更都要检查父节点需不需要同步修订。

向下传播：子功能是否需要同步修改。如果是一个中间节点变更了规则，它下面所有叶子节点都可能受影响。比如"权限校验"节点的规则从"按角色校验"改成"按角色加数据范围校验"，下面挂着的所有功能都要过一遍。

横向传播：兄弟节点共享的数据、规则、权限。这是最容易漏的方向。同一个层级的节点往往共用同一套实体和枚举值，改了一个节点的数据结构，兄弟节点大概率要跟着动。

跨层传播：外部接口、报表、上下游系统。功能图本身不画外部系统，但变更评估时必须把它们补进来。一个内部字段的类型变化，可能直接影响对外的接口契约、下游的数据同步、BI 的报表口径。

4.2 在图上补一层依赖标注，别指望树结构自己说清楚

功能结构图本质是棵树，树只能表达归属关系，表达不了横向依赖。而变更影响恰恰大量发生在横向。所以我会在功能图之外单独维护一张依赖标注表，和图上的编号对应起来。

依赖类型我归为四类：

这张表不需要很细，节点级别就够，但必须保持更新。我一般会在每次版本规划会上花十分钟过一遍，看有没有新产生的依赖。

用颜色或标记把依赖叠在图上也可以，但我不建议在图本身堆太多信息。图保持简洁，依赖放在附表里，查阅的时候对着编号找，比一张密密麻麻的图好用得多。

4.3 变更评估表：把"改一下"翻译成可讨论的量

变更评估最怕的就是"改一下"这三个字。我的做法是强制过一张评估表，把模糊感受变成可以讨论的条目。

这张表的价值不在于估得多准，而在于它强迫评估者把影响面走一遍。我见过太多项目，评估时只写个"1 天"，实际做完 5 天，不是开发不努力，是评估阶段根本没想到那些横向依赖。

4.4 一个具体案例：批量操作这几个字背后的连锁反应

去年参与的一个后台系统项目，需求是在订单列表加一个"批量取消"操作。产品侧的判断是"小改动，两天"。我们用功能图走了一遍评估，结论完全不一样。

变更节点是F-02-03-03 订单取消，影响分析如下：

向上看，父节点F-02-03 订单处理的职责描述从"单个订单的操作"扩展到"支持批量操作"，需要同步修订，否则文档失真。

向下看，订单取消原本只有单个入口，现在要支持批量，意味着要新增批量校验、批量结果反馈、部分成功部分失败的展示逻辑。

横向看，问题开始变多。F-02-04 订单查询的列表接口要支持批量选中，返回结构可能要调整；F-05-01 权限校验要区分"单次取消"和"批量取消"的权限粒度；F-06-02 操作日志从一条记录变成 N 条还是汇总一条，需要明确；F-07-01 消息通知的触发从一条变成批量触发，要考虑频次控制和去重。

跨层看，对外的订单接口契约可能变化；财务报表里取消订单的统计口径要确认；下游的库存回滚逻辑要确认是否支持批量。

最后评估下来是五到六天的工作量，涉及四个功能域、两个外部系统。这个结论不是靠经验拍出来的，是顺着功能图走出来的。走一遍花不了半小时，但省下的是三四天的返工。

5. 工具选型与落地：从白板到文档的实操链路

5.1 三个阶段用三种工具，别一上来就开建模软件

工具这件事上我的观点很明确：工具跟着阶段走，不要一步到位。

共创阶段用白板。需求刚进来、功能域还没定的时候，最好的工具是白板或者纸。这个阶段的目标是快速试错，把三种切法都画一遍，看看哪种更顺。用工具画会不自觉地开始调格式、对齐、配色，注意力从内容跑到排版上去了。我在这个阶段一般会画三版草图，摆在一起对比，选一版继续往下推。

定稿阶段用通用绘图工具。功能域确定之后，开始正式画。这个阶段的诉求是结构清晰、易于共享、方便非技术同事查看。通用绘图工具足够用，重点是模板要统一，图例要固定，编号规则要一致。

持续维护阶段才考虑建模工具。当节点数量超过五六十个、变更频率高、需要和需求库联动的时候，通用绘图工具会开始吃力，因为它只是一张图片，节点不能被查询、不能被引用、不能导出结构化数据。这时候建模类工具的价值才显现出来：节点是数据对象，可以加属性、可以查询、可以导出。

工具选型有几个判断维度，我整理成一张表：

我见过最浪费的情况是有团队一上来就上了建模工具，配了模板、定了规范、培训了两轮，结果节点不到三十个，改一次比画一次还慢，三个月后全体退回通用绘图工具。工具的成本不只是钱，还有学习成本和维护成本。

5.2 图例约定和编号规则，要在第一次画之前定死

这两件事如果在项目中途才想起来定，后面一定要返工。

编号规则我一般用F-一级-二级-三级的格式，比如F-02-03-01。规则里有几条细节值得说：

• 编号一旦分配不复用。节点删掉了，编号留空，后面的节点不往前补。这样历史文档、工单、缺陷记录里的引用永远指得到对的地方。
• 层级编号补零。F-02而不是F-2，保证排序稳定。
• 跨版本新增的节点用后缀标记，比如F-02-03-04-N，一眼能看出是本版本新加的。

图例至少要有四种区分：

图例不要超过六种，超过之后读者记不住，反而不如不标。

5.3 推行时最容易卡住的两个环节

工具和规范都只是表面问题，真正让功能图在团队里落不了地的，是两个更软性的环节。

第一个卡点是没人愿意维护。图这东西，画的时候一群人围观，维护的时候一个人都没有。我的解决办法是把功能图嵌进流程里，让它成为某个环节的必要条件。具体做法是：需求评审的准入门槛里加一条——没有对应功能节点编号的需求不予评审。这条规则一立，产品经理自己就会去维护图，因为不维护他的需求就排不进会。这件事听起来有点强硬，但确实是所有方法里最有效的。

第二个卡点是图太复杂没人看。节点一多，图就变成一团线，读者看一眼就关掉了。解决办法是分层呈现：一张总览图，只到二级节点，让所有人能一眼看清系统全貌；每个功能域再来一张详图，展开到叶子节点，给负责该域的人看。同一套数据，两种视图。总览图永远保持在一页之内，这是硬约束。

还有一个容易被忽略的点：图要有一个明确的唯一存放位置。我见过功能图散落在三个人的本地、两个群聊记录、四个文档平台的角落，最后没人说得清哪一版是对的。定一个位置，别处一律只放链接，链接指向那一份。

6. 我在几个项目里踩过的坑和总结出的检查清单

6.1 图越画越大，最后变成没人看的艺术品

前面说过分层呈现，这个教训是我实打实换来的。有个项目功能图画到第三版的时候，节点超过了一百八十个，一张图铺满四块屏幕还放不下。那段时间每次评审，大家对着图沉默半分钟，然后开始聊别的。图还在，作用已经没有了。

后来的处理是砍成三层视图：一张十二个节点的总览图，六张各二十到三十个节点的分域图，叶子节点的详细信息全部挪到映射表里，不画在图上。改完之后，总览图能打印在一张纸上，贴在会议室里用了一个季度。

这里的经验是：图的信息密度是有上限的，超过之后读者会放弃。与其把所有信息塞进一张图，不如分层，让不同的人在不同的层级找到自己需要的东西。

6.2 图与实现脱节之后，怎么重新建立信任

功能图不是设计文档，不应该跟着代码同步到方法级别，但功能域级别的变化必须回写。这一点我在一个项目里做错过：中期为了赶进度，图停更了两个月，等到想补的时候发现已经改得面目全非，补图的成本比重新画还高。结果是这张图彻底失去信任，后面再提"我们看看功能图"，大家的反应都是"那个不准"。

重建信任的做法很朴素：找一个范围明确的小版本，从头到尾把图和实现对齐一遍，把这个过程公开，让团队看到图是准的。之后每次版本迭代结束，固定花半天回写变更。这个成本是必须付的，不付就要付更大的代价。

还有一个技巧：把功能图放进迭代的完成定义里。一个迭代结束，如果功能有变化而图没更新，这个迭代就不算完成。这条规则比任何口头强调都有效。

6.3 一份可以直接抄走的检查清单

最后把前面所有内容压缩成一份清单，画完图、评审之前对着过一遍。

关于结构：

• 顶层功能域数量在五到八个之间，划分依据统一，没有混用多种维度
• 层级不超过五层，超过的地方检查是否漏了归类或混了维度
• 同层级节点粒度一致，没有出现某层既有业务子域又有原子操作
• 每个节点的编号唯一、稳定，不和历史编号冲突

关于命名：

• 全部采用动宾结构，动词具体，名词是业务词汇
• 没有"管理""处理""维护""综合""其他"这类空词
• 名词型节点和动词型节点不在同一层混放

关于需求对齐：

• 每个叶子节点至少关联一条需求，每条需求至少落在一个节点上
• 每个叶子节点都有可判定的验收标准
• 每个叶子节点都标注了责任角色
• 每个叶子节点都填过"谁触发、输入什么、输出什么"三列

关于变更分析：

• 依赖标注表已更新，四类依赖都有覆盖
• 变更评估表填完整，横向影响和跨层影响都有条目
• 图例和视图分层约定在团队内一致

关于维护：

• 图有唯一存放位置，其他地方只放链接
• 版本回写已经排进流程，有明确的触发时机
• 总览图控制在一页之内，分域图按域拆分

这份清单看着条目不少，实际过一遍二十分钟够了。我自己的习惯是画完之后隔一天再对着清单检查，刚画完的时候脑子是热的，容易觉得哪哪都对。

有个细节值得单独提一句：功能图的验收标准里，我最看重的其实是"不重叠"这一条。因为它最难满足，也最能反映画图的人对业务的理解深度。覆盖不全可以补，命名不好可以改，但边界重叠意味着对业务的理解本身是模糊的，这个只能靠反复跟业务方确认来打磨。我在几个项目里都是靠一遍遍追问"这件事到底归谁管"才把边界磨清楚的，没有捷径。

另外分享一个判断图是否成熟的简单信号：如果团队在讨论一个新需求时，会自然而然地说"这个落在 F-03 下面，可能还要动 F-05"，那就说明功能图真正进入工作语言了。图的价值不在于画得多漂亮，而在于它变成了大家沟通时的坐标系。到了那个状态，后面所有的需求对齐和变更分析都是顺水推舟的事。