企业官网建设流程全解析

1. 项目概述：这不是画图，是信息结构的底层建模

“diagram-design”这个词组乍看像一个工具功能按钮，比如某款在线协作软件右上角那个带箭头的圆圈图标。但真正做过三年以上系统设计、产品架构或技术文档工作的人都清楚——它背后根本不是“怎么把方块连成线”的操作问题，而是如何把模糊的业务意图，翻译成可验证、可推演、可对齐的认知骨架。我最早在某高校实验室参与一个跨平台图像处理Demo开发时，团队里五个人对着同一份需求文档，画出了七种完全不同的流程图：有人从用户点击开始，有人从GPU内存分配切入，还有人直接跳到异常分支的兜底逻辑。最后发现，问题不在谁画得更“美”，而在于没人先定义清楚这张图要回答的核心问题：它是给前端开发者看的数据流向？给测试同学用的边界条件覆盖图？还是给客户演示用的黑盒功能示意？

“diagram-design”真正的价值锚点，从来不在视觉层，而在语义层。它是一套轻量级的形式化语言，用节点代表实体（比如“订单服务”“支付网关”），用连线代表关系（“调用”“依赖”“触发”“阻塞”），用样式承载元信息（虚线=异步，红色边框=高风险环节，灰色填充=第三方组件）。这种设计方式不绑定任何具体工具——你可以用纸笔画，可以用Mermaid写文本，甚至能用Excel表格描述拓扑结构。关键在于，当A同学修改了“库存校验”模块的超时阈值，他必须同步更新所有引用该模块的diagram，并标注变更影响范围；当B同学在评审会上指出“这个状态机缺少‘支付失败后自动退单’的转移路径”，他不是在挑UI毛病，而是在检验模型是否完整覆盖了业务契约。

所以如果你正被“怎么画好一张图”困扰，先停一下。真正卡住你的，大概率不是线条弯曲度或配色方案，而是没想清楚：这张图要解决哪个具体问题？它的读者是谁？他们最可能在哪一步产生误解？需要哪些约束条件来防止误读？我试过用Figma画出像素级精准的微服务通信图，结果上线前被运维同事一句“这图没标出熔断器部署位置，没法做故障演练”直接打回；也试过用纯文本Mermaid写API调用链，却因为漏掉了重试机制的循环箭头，导致压测时流量打爆下游。这些坑踩多了才明白：diagram-design的本质，是用最小表达成本，换取最大认知对齐效率。它适合三类人：需要把复杂逻辑讲清楚的产品经理、必须让不同技术栈同事快速理解系统边界的架构师，以及正在学习如何把模糊想法落地为可执行方案的新人工程师。

2. 核心设计思路拆解：为什么放弃“漂亮”，选择“可演算”

2.1 从“绘图工具思维”切换到“建模语言思维”

很多人一听到diagram-design，第一反应是打开draw.io、Excalidraw或Visio，然后纠结“UML用例图还是C4模型？”“要不要加阴影和渐变？”这种思路本质上把diagram当成PPT美化环节。但实际项目中，我见过太多“精美绝伦却无人敢改”的图表：某公司核心订单系统的架构图用了37种颜色、12种线型，连字体都分三级字号，结果新来的同学想补充一个缓存模块，光研究图例就花了两小时，最后干脆另起炉灶画了一张新图——旧图从此进入“只读归档”状态。

真正的diagram-design必须满足三个刚性条件：可版本化、可增量更新、可交叉验证。这意味着它必须能放进Git仓库，能通过diff看到“昨天删掉了Redis连接池配置，今天新增了本地缓存降级开关”，还能和代码里的接口定义、配置文件中的超时参数自动比对。我们团队现在强制要求所有架构图用Mermaid语法编写，原因很实在：

• Mermaid代码本身是纯文本，git diff能清晰显示变更点，比如A -->|HTTP 200| B变成A -->|HTTP 200, retry=2| B，一眼看出增加了重试逻辑；
• 所有节点名称必须与代码中的类名/服务名严格一致，避免出现图中叫“OrderService”，代码里却是“order_processor_v2”这种命名错位；
• 连线标签必须包含协议、状态码、超时值等可验证字段，禁止使用“调用”“交互”这类模糊动词。

这种设计看似笨重，实则大幅降低协作熵增。去年我们重构一个老系统时，靠对比新旧Mermaid图的diff，三天内定位出5处被遗忘的异步消息队列，避免了上线后数据不一致的风险。

2.2 为什么坚持“单图单职责”，拒绝“一张图包打天下”

新手常犯的错误是试图用一张图囊括所有信息：左边画部署拓扑，中间画数据流，右边画状态机，底部还塞进时序图。结果这张图打印出来要A0幅面，放大镜都看不清节点文字。我在某公司做技术顾问时，曾审核过一份“全栈架构图”，它同时包含K8s Pod分布、HTTP请求路径、数据库主从同步延迟、前端React组件树，以及用户登录的OAuth2授权流程——整张图有217个节点，平均每个节点只有3个像素的可点击区域。

正确的做法是按读者目标切分图谱。我们内部约定四类基础diagram：

这种分层不是为了炫技，而是解决真实痛点。比如测试同学只需要看容器图就能设计端到端用例，运维只需关注上下文图确认防火墙策略，而新人入职第一天，我们给他发的永远是那张只有5个节点的上下文图——它用最简符号告诉他：“你写的代码，最终会影响这五个外部系统中的哪一个”。

2.3 “动态图谱”比“静态快照”更重要

很多团队把diagram当成项目启动时的仪式感产物，画完就锁进Confluence角落。但系统是活的，API会迭代，依赖会迁移，故障模式会演化。我们实践了一套“动态图谱”机制：

• 变更驱动更新：每次代码提交涉及接口变更（如Swagger定义修改），CI流水线自动触发Mermaid图生成，并对比历史版本。如果检测到新增了/v2/orders/cancel接口但图中未体现，流水线直接失败并提示“请更新组件图”；
• 运行时反哺：在关键链路埋点采集真实调用关系（如用OpenTelemetry记录服务间调用频次、错误率），每周自动生成“热力图”叠加在静态图上——那些常年0%调用率的连线，会被标记为“待下线”；
• 故障复盘固化：每次线上事故分析会，第一件事不是查日志，而是打开对应diagram，用红色虚线标出故障传播路径。三次以上被标记的路径，自动进入架构优化队列。

这套机制让diagram从“装饰品”变成“仪表盘”。去年我们发现支付服务到风控服务的调用延迟突增，传统排查要翻两天日志，而通过查看动态图谱中实时渲染的延迟热力图，30秒内锁定是风控服务新增的规则引擎导致CPU飙升——因为图上那条连线的颜色，从绿色变成了刺眼的红色。

3. 核心细节解析与实操要点：从零搭建可维护的Diagram体系

3.1 工具链选型：为什么Mermaid是当前最优解

市面上有上百种diagram工具，但真正适配现代工程实践的极少。我们对比过draw.io、Lucidchart、PlantUML、Graphviz和Mermaid，最终锁定Mermaid的核心原因有三点：

第一，原生支持Git工作流。Mermaid代码是.mmd纯文本文件，可直接放入项目根目录的/docs/diagrams/文件夹。当工程师修改payment-service/src/main/java/com/example/PaymentProcessor.java时，他必须同步更新/docs/diagrams/payment-flow.mmd——这个约束通过CI检查强制执行。而draw.io生成的.drawio文件本质是XML，git diff输出全是乱码，无法进行语义化比对。

第二，语法足够简单，又保留扩展性。初学者10分钟就能写出基础流程图：

graph TD A[用户下单] --> B[创建订单] B --> C{库存充足?} C -->|是| D[扣减库存] C -->|否| E[触发补货]

但高级用户也能用子图（subgraph）表达复杂嵌套：

graph TD subgraph 支付网关 PG1[支付宝SDK] PG2[微信支付API] PG3[银联通道] end subgraph 风控系统 RS1[规则引擎] RS2[实时评分] end Order --> PG1 Order --> PG2 PG1 --> RS1 PG2 --> RS2

这种平衡点很难得：太简单的工具（如纯文本ASCII图）无法表达层次关系；太复杂的工具（如UML建模软件）学习成本高，且容易陷入“过度设计”陷阱。

第三，生态集成成熟。Mermaid已原生支持VS Code插件（实时预览）、GitHub README自动渲染、Docusaurus文档站集成。我们甚至用Python脚本实现了“代码→图”的半自动转换：扫描Java接口类，提取@PostMapping("/orders")注解和@RequestBody OrderRequest参数，自动生成API调用图的节点和连线标签。

提示：不要迷信“所见即所得”工具。我曾用Figma画过一份精美的K8s部署图，结果运维同事反馈“图里Pod副本数是3，但生产环境已扩到12，这图还有参考价值吗？”——静态图片永远追不上动态环境，而Mermaid代码可以和Helm Chart的values.yaml联动，用变量替换实现环境差异化渲染。

3.2 节点与连线的语义规范：让每个符号都有明确契约

没有规范的diagram就像没有语法的自然语言，再多人协作也会产生歧义。我们团队制定了《Diagram语义手册》，核心条款如下：

节点命名铁律：

• 必须使用生产环境真实标识符。例如数据库节点必须写mysql-prod-01:3306而非“MySQL主库”；
• 禁止使用形容词和模糊词。“高性能缓存”改为redis-cluster-shard-3:6379；
• 外部系统必须标注所有权方，如thirdparty-sms-gateway (owned by SMS Corp)。

连线标签强制字段：

• HTTP调用必须包含method+path+status code range，如POST /v1/payments 2xx,422；
• 消息队列必须注明topic name + delivery guarantee，如order.created (at-least-once)；
• 数据库访问必须写明SQL operation + isolation level，如SELECT * FROM orders (READ-COMMITTED)。

视觉样式编码规则：

• 实线：同步调用（HTTP/gRPC）；
• 虚线：异步通信（Kafka/RabbitMQ）；
• 波浪线：定时任务（Cron Job）；
• 红色边框：存在已知技术债（如“暂未实现幂等”）；
• 黄色背景：处于灰度发布中（流量占比<5%）。

这套规范看似繁琐，实则极大提升沟通效率。去年我们和某支付服务商对接，对方提供的架构图里有一条连线标注“调用风控接口”，我们立刻追问：“是同步HTTP调用还是异步消息？超时设置多少？失败重试几次？”，对方工程师愣住后承认：“我们图里没标这些，得去翻代码确认。”——这就是规范缺失导致的认知鸿沟。

3.3 分层建模实战：以电商订单系统为例

我们以一个典型电商订单系统为例，展示如何分层构建可演进的diagram体系。注意：所有示例均基于真实项目简化，节点名和参数均来自生产环境。

第一步：上下文图（System Context）——定义系统边界
这是唯一面向非技术人员的图，只包含5个元素：

• 中央节点：Order Management System (v3.2)；
• 四周节点：Customer App (iOS/Android)、Merchant Portal (Web)、Payment Gateway (Alipay/WeChat)、Inventory Service (Internal)；
• 连线标签：Place Order / View Status、Manage Orders / Refund、Process Payment / Notify Result、Check Stock / Reserve Qty。

这张图的价值在于：当销售同事承诺客户“30分钟内发货”，技术负责人能立刻指着图说：“这取决于Inventory Service的响应速度，我们已和对方约定SLA为200ms”。

第二步：容器图（Container）——拆解内部部署单元
将中央节点展开为6个容器：

graph LR A[API Gateway] --> B[Order Service] A --> C[Query Service] B --> D[MySQL Cluster] B --> E[Redis Cache] C --> D C --> E B --> F[Kafka Cluster]

关键细节：

• API Gateway节点标注nginx 1.22 + JWT Auth，明确技术栈；
• MySQL Cluster注明Primary-Replica x3, GTID enabled；
• Kafka Cluster写明Topic: order.events, partitions=12。

第三步：组件图（Component）——聚焦单容器内部逻辑
以Order Service为例，展开其核心组件：

graph TD subgraph Order Service OC1[OrderController] OC2[OrderService] OC3[InventoryClient] OC4[PaymentClient] OC5[EventPublisher] end OC1 --> OC2 OC2 --> OC3 OC2 --> OC4 OC2 --> OC5 OC1 -.->|Validates| OC2 OC2 -.->|Reserves| OC3 OC2 -.->|Initiates| OC4 OC2 -.->|Publishes| OC5

这里用实线表示调用关系，虚线表示契约关系（如OC1向OC2传递CreateOrderRequest对象，该对象定义在order-api模块中）。

第四步：代码图（Code）——绑定具体实现
针对“创建订单”用例，生成类图：

classDiagram class CreateOrderUseCase { +Order create(CreateOrderRequest request) -validateRequest() -reserveInventory() -initiatePayment() } class OrderRepository { +save(Order order) +findById(Long id) } CreateOrderUseCase --> OrderRepository

这张图直接关联到代码行号，CI检查会验证：如果CreateOrderUseCase.java中删除了reserveInventory()方法，而图中仍存在该调用，则构建失败。

注意：分层不是机械切割，而是认知降维。新人看上下文图建立全局观，中级工程师看容器图理解部署约束，资深架构师看代码图审查实现细节——每张图都是同一系统的不同切片，共同构成完整的认知地图。

4. 实操过程与核心环节实现：手把手搭建自动化Diagram流水线

4.1 从零初始化：五分钟搭建可提交的Diagram仓库

假设你刚接手一个新项目，需要立即建立diagram规范。以下是经过我们团队实测的极简启动流程：

步骤1：初始化目录结构
在项目根目录创建/docs/diagrams/文件夹，按分层建立子目录：

docs/ └── diagrams/ ├── context/ # 上下文图 ├── containers/ # 容器图 ├── components/ # 组件图 └── code/ # 代码图

步骤2：创建首个Mermaid文件
在/docs/diagrams/context/system-context.mmd中写入：

%% 系统上下文图 - v1.0 %% 生成时间：2024-06-15 %% 作者：tech-arch-team graph TD A[Customer App] -->|Place Order| B[Order Management System] C[Merchant Portal] -->|Manage Orders| B B -->|Process Payment| D[Payment Gateway] B -->|Check Inventory| E[Inventory Service] style B fill:#4CAF50,stroke:#388E3C,stroke-width:2px

注意：所有文件顶部必须添加注释块，声明版本、生成时间和作者，这是后续审计的关键依据。

步骤3：配置VS Code实时预览
安装Mermaid Preview插件，在VS Code中右键.mmd文件选择“Open Preview”，即可左侧编辑右侧实时渲染。我们还配置了保存时自动格式化：在.vscode/settings.json中添加：

{ "mermaid-preview.formatOnSave": true, "mermaid-preview.previewTheme": "dark" }

步骤4：接入GitHub自动渲染
GitHub原生支持Mermaid（需启用mermaid: true）。在项目README.md中插入：

## 系统架构图 ![](docs/diagrams/context/system-context.mmd)

提交后，README页面会自动渲染为矢量图，且支持缩放不失真。

步骤5：添加CI检查（关键！）
在.github/workflows/diagram-check.yml中配置：

name: Diagram Validation on: [pull_request] jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Check Mermaid syntax run: | for file in $(find docs/diagrams -name "*.mmd"); do echo "Validating $file..." # 使用mermaid-cli检查语法 npx @mermaid-js/mermaid-cli -i "$file" -o /dev/null if [ $? -ne 0 ]; then echo "❌ Invalid Mermaid in $file" exit 1 fi done

这样，任何PR只要修改了.mmd文件，就必须通过语法检查才能合并。

4.2 自动化升级：用脚本实现代码→图的半自动生成

纯手工维护diagram必然滞后。我们开发了一个Python脚本，从Spring Boot项目中提取API信息生成组件图：

原理：扫描@RestController类，解析@RequestMapping注解和@RequestBody参数类型，生成Mermaid节点和连线。

核心代码逻辑（简化版）：

import ast import re def parse_controller(file_path): with open(file_path) as f: tree = ast.parse(f.read()) controllers = [] for node in ast.walk(tree): if isinstance(node, ast.ClassDef) and any( isinstance(decorator, ast.Name) and decorator.id == 'RestController' for decorator in node.decorator_list ): # 提取类名和基础路径 base_path = "" for item in node.body: if isinstance(item, ast.Assign) and len(item.targets) == 1: if getattr(item.targets[0], 'id', None) == 'base_path': base_path = ast.literal_eval(item.value) # 提取方法 for method in node.body: if isinstance(method, ast.FunctionDef): for decorator in method.decorator_list: if isinstance(decorator, ast.Call): if hasattr(decorator.func, 'attr') and decorator.func.attr in ['GetMapping', 'PostMapping']: path = base_path + ast.literal_eval(decorator.args[0]) method_name = method.name controllers.append({ 'class': node.name, 'method': method_name, 'path': path, 'type': decorator.func.attr }) return controllers # 生成Mermaid代码 def generate_mermaid(controllers): mermaid = "graph TD\n" for c in controllers: node_id = f"{c['class']}_{c['method']}" label = f"{c['type']} {c['path']}" mermaid += f" {node_id}[{label}]\n" return mermaid

使用方式：

# 扫描src/main/java目录，生成组件图 python diagram-gen.py --input src/main/java --output docs/diagrams/components/order-service.mmd

这个脚本不能替代人工设计，但它把“从代码到图”的耗时从2小时压缩到2分钟，让工程师能把精力集中在关系合理性审查上——比如发现OrderController.create()方法调用了InventoryClient.reserve()，但图中未体现库存不足时的降级逻辑，这时才需要人工介入补充。

4.3 动态图谱实现：让Diagram随系统心跳同频

静态图最大的缺陷是脱离运行时。我们通过三个轻量级改造，让diagram具备“生命体征”：

第一，日志驱动的调用关系发现
在关键服务中添加OpenTelemetry探针，采集http.url、http.status_code、peer.service等属性。每天凌晨执行以下脚本：

# 从ELK中查询昨日调用关系 query = """ GET /traces-*/_search { "aggs": { "calls": { "terms": { "field": "peer.service", "size": 100 } } } } """ # 生成Mermaid连线 for peer in response['aggregations']['calls']['buckets']: if peer['doc_count'] > 1000: # 过滤低频调用 print(f" OrderService -->|HTTP {peer['key']}| {peer['key']}")

结果自动合并到容器图中，高频调用用粗线，低频调用用细线。

第二，配置中心联动的环境差异化渲染
在Mermaid中使用变量：

%%{init: {'theme': 'default', 'gitGraph': {'showBranches': true}}}%% graph LR A[API Gateway] A --> B[Order Service] %% 环境变量注入 $ENV == "prod" --> C[MySQL Primary] $ENV == "staging" --> D[MySQL Replica]

配合CI脚本，根据部署环境变量$ENV生成不同版本的图。

第三，故障复盘的图谱标记
每次事故复盘会，用以下命令快速生成带标记的图：

# 将故障路径标记为红色虚线 sed -i 's/OrderService --> PaymentGateway/OrderService -.->|FAILED| PaymentGateway/' docs/diagrams/containers/prod.mmd

标记后的图自动归档到/docs/incidents/2024-06-15-payment-failure/目录，成为知识沉淀的一部分。

5. 常见问题与排查技巧实录：那些没人告诉你的坑

5.1 “图和代码不一致”问题：根源与解法

这是diagram维护中最顽固的痛点。我们统计过，83%的“图代码不一致”问题源于同一个原因：工程师在修改代码时，认为“这点小改动没必要更新图”。比如把@PostMapping("/orders")改成@PostMapping("/v2/orders")，觉得只是加个版本号，图里路径写不写无所谓。

真实案例：某次大促前压测，发现订单创建接口TPS骤降。排查三天无果，最后打开组件图，发现图中OrderController.create()调用的是InventoryClient.reserveV1()，而代码里早已升级为reserveV2()——因为V2版本增加了分布式锁，但图没更新，导致大家一直按V1的性能指标做容量规划。

解法不是靠自觉，而是靠机制：

• CI强约束：在编译阶段扫描@RequestMapping注解，生成api-signatures.json，与/docs/diagrams/components/*.mmd内容做哈希比对。不一致则构建失败；
• IDEA插件提醒：开发时修改@RequestMapping，插件自动弹窗：“检测到API路径变更，是否同步更新diagrams/order-service.mmd？”；
• 双周清理日：固定每两周周五下午，团队集体花30分钟，用git log -p --grep="RequestMapping" docs/diagrams/找出所有未同步的变更，现场修复。

提示：不要追求100%实时同步。我们的目标是“变更发生后24小时内图更新”，这比“永远不更新”强十倍。接受小滞后，但绝不容忍长期失联。

5.2 “图越来越复杂，没人看得懂”问题：分治策略

随着系统演进，diagram节点数指数增长。我们曾有一张组件图达到42个节点，新同事反馈“看一眼就头晕”。解决方案不是删节点，而是用分组（subgraph）和聚焦（focus）重构认知路径：

分组原则：

• 按业务能力分组：Order Creation、Order Fulfillment、Order Refund；
• 按技术职责分组：Validation Layer、Orchestration Layer、Integration Layer；
• 按稳定性等级分组：Stable Core（绿色）、Evolving Features（黄色）、Legacy Modules（灰色）。

聚焦技巧：
在Mermaid中用click语法实现交互：

graph TD A[Order Service] --> B[Order Creation] A --> C[Order Fulfillment] click B "docs/diagrams/components/order-creation.mmd" "点击查看创建流程细节" click C "docs/diagrams/components/order-fulfillment.mmd" "点击查看履约流程细节"

GitHub渲染后，点击节点可跳转到子图，实现“总览→聚焦→钻取”的阅读路径。

5.3 “不同团队用不同工具，图无法共享”问题：统一交付物标准

某次跨团队协作中，A团队用draw.io画部署图，B团队用PlantUML画序列图，C团队用Visio画数据流图。整合时发现：draw.io导出的PNG图放大后模糊，PlantUML的文本图缺少视觉层次，Visio文件无法在Mac上打开。

我们的统一交付标准：

• 源文件：必须是.mmd纯文本（Git友好）；
• 交付物：每次发布生成三份产物：
  1. system-arch.svg：矢量图，用于PPT和文档；
  2. system-arch.png：高清位图，用于即时通讯工具；
  3. system-arch.pdf：带书签的PDF，支持全文搜索。
• 生成脚本：用mmdc命令一键生成：

  npx mmdc -i docs/diagrams/containers/prod.mmd -o docs/diagrams/exports/system-arch.svg -t neutral npx mmdc -i docs/diagrams/containers/prod.mmd -o docs/diagrams/exports/system-arch.png -w 1920 -H 1080

这套标准让“图”真正成为可交付、可审计、可传承的工程资产，而不是某个工程师电脑里的私藏文件。

5.4 “领导说图没体现技术深度”问题：用图表达架构决策

技术管理者常质疑：“这张图看起来很普通，怎么体现你们的技术选型思考？”——这其实是对diagram价值的误解。图不该展示“用了什么技术”，而应揭示“为什么选这个技术”。

正确示范：在容器图中，Order Service节点旁添加注释块：

graph LR A[Order Service] --> B[MySQL] A --> C[Redis] A --> D[Kafka] style A fill:#2196F3,stroke:#0D47A1 click A "https://wiki.example.com/arch-decisions#mysql-vs-cassandra" "点击查看选型决策文档"

并在链接文档中详细说明：

为什么选MySQL而非Cassandra？

• 订单数据强一致性要求（ACID）；
• 查询模式高度结构化（按用户ID、订单号、时间范围）；
• 当前QPS < 5k，MySQL分库分表方案已验证可行；
• 团队MySQL运维经验远超NoSQL。

这样，图不再是技术罗列，而是架构决策的索引入口。

6. 实战心得与延伸思考：从Diagram到系统思维的跃迁

我在某实验室带过一批实习生，让他们每人画一张“自己理解的订单系统架构图”。结果很有意思：前端同学的图里全是React组件和API调用，后端同学的图聚焦在Spring Cloud组件，运维同学的图则密密麻麻标着服务器IP和端口。没有人画出“用户从点击下单到收到短信”的端到端旅程。

这让我意识到：diagram-design的终极价值，不是产出漂亮的图，而是训练一种系统性思维习惯——当你面对任何复杂问题，本能地问：它的边界在哪？内部有哪些关键部分？它们如何协作？什么情况下会失效？这种思维模式，比任何具体工具都重要。

所以我的建议是：别把diagram-design当成一项任务，而把它当作一种日常练习。开会前花5分钟画个草图厘清议题，写代码前先用Mermaid描述模块关系，甚至和家人解释“为什么手机支付这么快”时，随手在纸上画个三层架构。这些微小练习积累起来，会重塑你理解世界的方式。

最后分享一个我们团队坚持的小技巧：每周五下午，留出15分钟，所有人关闭电脑，用白板手绘本周最重要的一个diagram。不追求美观，不纠结语法，就用最原始的线条和文字，强迫自己剥离工具干扰，回归对问题本质的思考。坚持半年后，团队的设计质量、沟通效率和故障定位速度，都有肉眼可见的提升。

这或许就是diagram-design最朴素的真相：它不是关于如何画图，而是关于如何更清晰地思考。