最近一次方案評(píng)審評(píng)審人指著我投出來的服務(wù)調(diào)用圖說“你這張圖根本看不出重點(diǎn)而且這些箭頭到底是從哪發(fā)出來的”我下意識(shí)想反駁但低頭看了一眼自己那三十二個(gè)節(jié)點(diǎn)、大小不一的方框、七種顏色的連線話咽了回去。信息全對(duì)畫法不對(duì)。從那之后我把“畫圖”這件事正式改名為“圖表設(shè)計(jì)”diagram-design并且意識(shí)到它根本不是繪圖技能而是溝通技能。這篇內(nèi)容想分享的是我在多輪架構(gòu)評(píng)審、方案輸出和團(tuán)隊(duì)文檔共建過程中沉淀下來的圖表設(shè)計(jì)經(jīng)驗(yàn)。從信息分層、工具選型、繪制規(guī)范到真實(shí)項(xiàng)目里的翻車記錄和模板化維護(hù)適合正在做系統(tǒng)設(shè)計(jì)、技術(shù)方案或產(chǎn)品流程圖的讀者。如果你也畫過“信息齊但沒人愛看”的圖這篇文章應(yīng)該能幫上忙。1. 圖表設(shè)計(jì)這個(gè)項(xiàng)目到底在解決什么問題1.1 為什么大部分技術(shù)方案圖一眼看去像草稿早幾年我做平臺(tái)架構(gòu)梳理時(shí)最大的困惑不是畫不出圖而是畫出來的圖沒人愿意細(xì)看。節(jié)點(diǎn)大小全靠手感服務(wù)方框有的胖有的瘦連線從節(jié)點(diǎn)正下方拉出來繞了半圈才找到目標(biāo)顏色隨心挑紅色代表服務(wù)紅色又代表告警。每張圖都是獨(dú)立風(fēng)格放在一起沒有任何統(tǒng)一的視覺語言。我把這類問題歸為“草稿感”圖上信息其實(shí)都在但閱讀者需要在腦內(nèi)重新做一次分類和路徑解析才能看懂。這中間消耗的認(rèn)知成本就是實(shí)打?qū)嵉臏贤ǔ杀?。出現(xiàn)草稿感的根源是大多數(shù)人動(dòng)手前跳過了信息設(shè)計(jì)這一步。打開畫布就直接從第一個(gè)組件開始拖拽畫到一半發(fā)現(xiàn)右側(cè)空間不夠于是整體縮小某條線跨了三層節(jié)點(diǎn)為了不讓它穿過文字又繞了個(gè)大彎。所有調(diào)整都是局部反應(yīng)式的結(jié)果自然是一張結(jié)構(gòu)松散、層級(jí)混亂的圖。后來我把繪圖流程拆成“信息架構(gòu) → 布局規(guī)劃 → 視覺設(shè)計(jì) → 細(xì)節(jié)標(biāo)注”四步每步都有明確產(chǎn)出這種草稿感才基本消失。這也是這篇文章想傳遞的核心方法。1.2 設(shè)計(jì)圖表的三個(gè)核心目標(biāo)可讀、可溯、可維護(hù)整理這套方法的時(shí)候我逐漸把一張圖的評(píng)價(jià)標(biāo)準(zhǔn)收斂成三個(gè)詞可讀、可溯、可維護(hù)。可讀性就是“三秒定律”讀者掃一眼圖能不能在幾秒內(nèi)判斷出主干結(jié)構(gòu)。比如一張支付鏈路圖第一反應(yīng)應(yīng)該是“發(fā)起方 → 網(wǎng)關(guān) → 外部渠道”這條主線而不是先被左下角某個(gè)節(jié)點(diǎn)的顏色吸引。達(dá)成可讀性靠的是視覺層級(jí)粗細(xì)、深淺、留白、對(duì)齊全部在服務(wù)主干信息。可追溯性是指圖中每個(gè)元素都有明確歸屬和含義。節(jié)點(diǎn)顏色代表什么、實(shí)線和虛線代表什么、帶箭頭與不帶箭頭的線有什么區(qū)別圖例必須說明而且要全局一致?？勺匪菪圆畹膱D讀者經(jīng)常需要停下來問“這條虛線是什么意思”閱讀節(jié)奏就被打斷了?？删S護(hù)性則是給三個(gè)月后的自己留后路。架構(gòu)圖總要修改如果節(jié)點(diǎn)坐標(biāo)、樣式完全散落在畫布上每次修改都是一次推倒重來。把組件模板化、圖層命名規(guī)范化、源文件歸檔好后續(xù)維護(hù)成本能下降一個(gè)量級(jí)。這三個(gè)目標(biāo)聽著抽象落地時(shí)每一環(huán)都有細(xì)節(jié)接下來我按完整的實(shí)戰(zhàn)順序展開。2. 圖前準(zhǔn)備先設(shè)計(jì)信息層級(jí)再動(dòng)手畫2.1 動(dòng)筆前先寫一句話回答三個(gè)問題現(xiàn)在我的習(xí)慣是畫圖前先寫一句話回答三個(gè)問題。首先是給誰看。是給做技術(shù)評(píng)審的同事看還是給剛加入團(tuán)隊(duì)的新成員做培訓(xùn)還是給外部協(xié)作方做對(duì)接說明不同讀者決定了圖的抽象層級(jí)。給評(píng)審專家看的圖可以畫到服務(wù)內(nèi)部細(xì)節(jié)給外部對(duì)接方看的圖只需要畫清邊界和接口。其次是表達(dá)什么。是“系統(tǒng)如何處理一次請(qǐng)求”還是“服務(wù)之間的依賴關(guān)系”還是“某段流程在什么條件下走到異常分支”這三者對(duì)應(yīng)完全不同的圖畫法混在一起畫必亂。最后是希望讀者看完后做什么。是確認(rèn)方案可行理解接入步驟還是純介紹、沒有目的做決策的圖要突出備選項(xiàng)和結(jié)論做培訓(xùn)的圖要照顧閱讀順序做介紹的圖則可以適當(dāng)放寬細(xì)節(jié)。想清楚這三件事圖的主干信息就浮出來了。例如“給新成員介紹賬號(hào)服務(wù)的整體結(jié)構(gòu)”主干就是“接入層 → 業(yè)務(wù)服務(wù) → 存儲(chǔ)層”依賴的緩存和消息隊(duì)列放到第二層視覺重點(diǎn)即可。2.2 把信息拆成四類元素容器、節(jié)點(diǎn)、連線、標(biāo)注動(dòng)手之前我把所有要呈現(xiàn)的信息拆成四類節(jié)點(diǎn)服務(wù)、模塊、實(shí)體、決策點(diǎn)這類最小信息單元容器系統(tǒng)邊界、組織邊界、環(huán)境邊界表達(dá)歸屬關(guān)系連線節(jié)點(diǎn)之間的關(guān)系方向表達(dá)數(shù)據(jù)流、調(diào)用流或依賴標(biāo)注對(duì)前三者的補(bǔ)充包括圖例、注釋、關(guān)鍵路徑說明。這個(gè)拆分看似基礎(chǔ)實(shí)則是防止畫圖途中“混型”的關(guān)鍵。我見過最常見的混型是把環(huán)境邊界畫成一個(gè)大色塊色塊里放一個(gè)服務(wù)節(jié)點(diǎn)顏色和色塊一樣讀者根本分不清哪個(gè)是邊界、哪個(gè)是組件。我自己通常先用文字清單列出每類元素每類一行。信息拆完這張圖的內(nèi)容就定稿了后面在畫布上做的是排版而不是臨時(shí)增減內(nèi)容。臨時(shí)增減是“草稿感”的重要來源。2.3 布局方向與視覺錨點(diǎn)先排閱讀順序信息拆完之后要做的不是馬上拖節(jié)點(diǎn)而是先排閱讀順序。絕大多數(shù)人的閱讀習(xí)慣是“從上到下、從左到右”技術(shù)圖最常用的三種布局方向自頂向下適合請(qǐng)求處理流程、分層架構(gòu)主線從頂部入口流到底部出口自左向右適合時(shí)間序列、數(shù)據(jù)流管線、發(fā)布流程核心放射圍繞中心服務(wù)的依賴圖適合表達(dá)“誰依賴誰”的結(jié)構(gòu)關(guān)系。定了方向之后還要確定視覺錨點(diǎn)第一眼該落在哪里。通常我會(huì)把最重要的節(jié)點(diǎn)放在畫布中上部偏左的位置也就是接近黃金分割的地方讓它在第一時(shí)間被看到。錨點(diǎn)確定后其他元素圍繞錨點(diǎn)展開而不是平均鋪滿畫布。我早期畫圖總喜歡把內(nèi)容“鋪滿畫布”結(jié)果讀者視線被四個(gè)角拉著跑最后靠圖例下面的注釋才能拼出主線。后來改掉這個(gè)習(xí)慣先想主線放哪里、什么是背景再想細(xì)節(jié)放哪里圖的骨架立刻清晰了。3. 工具選型與工程化配置別貪多夠用且可維護(hù)3.1 主流繪圖工具的真實(shí)體驗(yàn)對(duì)比工具不是核心但選錯(cuò)工具會(huì)讓人陷入“畫得很爽、維護(hù)很痛”的處境。我實(shí)際用下來把幾種常用工具的感受整理成了表格工具定位優(yōu)點(diǎn)不足適合場(chǎng)景draw.io通用繪圖上手快、免費(fèi)、快捷鍵批量排版方便樣式能力有限模板需要自建架構(gòu)圖、部署圖的精細(xì)整理Excalidraw手繪風(fēng)草稿畫得爽、協(xié)作體驗(yàn)好手繪風(fēng)不夠正式元素規(guī)范弱頭腦風(fēng)暴、早期草圖Mermaid代碼生成圖文本即圖、可進(jìn)版本庫、易diff復(fù)雜布局控制弱、中文排版一般時(shí)序圖、狀態(tài)圖、簡(jiǎn)單流程圖PlantUML代碼生成圖時(shí)序和用例圖自動(dòng)化強(qiáng)語法學(xué)習(xí)成本生成圖風(fēng)格偏“程序員味”時(shí)序圖、用例圖Graphviz點(diǎn)線圖引擎自動(dòng)排布節(jié)點(diǎn)、減少交叉效果好樣式定制曲線陡峭依賴關(guān)系、結(jié)構(gòu)類大圖這張表不追求全面只記錄我自己的判斷邏輯開會(huì)隨手畫用Excalidraw作為文檔交付的技術(shù)圖用draw.io精細(xì)排版內(nèi)容以流程和時(shí)序?yàn)橹?、又希望圖能進(jìn)代碼庫走評(píng)審用Mermaid。3.2 為什么我們最終走雙軌方案團(tuán)隊(duì)最終確定的是“手動(dòng)精修 代碼生成”雙軌方案。架構(gòu)圖、部署圖、全景圖這類“版式即信息”的圖用draw.io。這類圖里的分層、邊界、間距本身就在表達(dá)結(jié)構(gòu)手動(dòng)排布才能完全掌控排版質(zhì)量。為了保證多人協(xié)作時(shí)風(fēng)格統(tǒng)一我建設(shè)了一套團(tuán)隊(duì)模板預(yù)置好畫布大小、字體、配色、節(jié)點(diǎn)樣式、圖層命名規(guī)則所有人畫圖都從模板開始而不是從空白畫布開始。時(shí)序圖、狀態(tài)圖、數(shù)據(jù)流這類“順序即信息”的圖用Mermaid寫在Markdown文檔里。這類圖改一個(gè)分支就要重排一張甚至多張圖代碼方式只要改幾行文本再生成就行非常適合頻繁變更的內(nèi)容。雙軌方案的代價(jià)是兩套語法都要熟收益是靜態(tài)圖的質(zhì)量上限和動(dòng)態(tài)圖的維護(hù)成本都被控制住了。這種選擇邏輯也可以遷移到其他領(lǐng)域選工具不是選最好看的而是選“交付質(zhì)量”和“維護(hù)成本”兩頭都能接受的。4. 實(shí)操全流程從一張空白畫布到一張能交付的架構(gòu)圖4.1 畫布、柵格與字體基線先說畫布。我默認(rèn)用16:9分辨率按1920×1080或1280×720來定因?yàn)榇蠖鄶?shù)評(píng)審場(chǎng)景是投影或共享屏幕這個(gè)比例最舒服。畫布統(tǒng)一之后多張圖放在同一篇文檔里并排看視覺上才能連貫。第二步是柵格。以draw.io為例把網(wǎng)格尺寸設(shè)為24像素并開啟“對(duì)齊到網(wǎng)格”。不要小看這個(gè)設(shè)置均勻的節(jié)點(diǎn)間距、對(duì)齊的邊界線都是從柵格來的。沒有柵格約束的手工排版畫到一半再看就是歪的。第三步是字體。技術(shù)方案圖里的中文我優(yōu)先用思源黑體或微軟雅黑這類現(xiàn)代無襯線字體正文用12到14像素標(biāo)題用16到18像素端口號(hào)、命令、類名這類固定寬度信息用等寬字體。整套字體在一個(gè)項(xiàng)目里保持固定不要一張圖換一個(gè)。4.2 配色基線主色、輔助色與語義色配色這塊我踩過大坑早期一張圖用六種顏色每種都像主色結(jié)果整張圖沒有主次?，F(xiàn)在的規(guī)范是把顏色分成三層主色只選1種表達(dá)核心鏈路或核心組件讓讀者一眼鎖定重點(diǎn)輔助色2到3種表達(dá)不同類別的系統(tǒng)或模塊比如應(yīng)用服務(wù)、數(shù)據(jù)存儲(chǔ)、中間件各一個(gè)語義色紅黃綠只能用于狀態(tài)和風(fēng)險(xiǎn)比如異常、進(jìn)行中、正常。這套體系的好處是讀者只要看過一次圖例再看團(tuán)隊(duì)任何一張圖都能立刻理解顏色含義。顏色一旦承擔(dān)統(tǒng)一語義就不再是裝飾而是信息通道。另一個(gè)容易被忽略的細(xì)節(jié)是文字對(duì)比度。淺色背景上不要使用低飽和度的淺灰文字投影環(huán)境下幾乎看不清。我自己在淺灰底上寫字會(huì)強(qiáng)制用深灰或黑色文本閱讀體驗(yàn)差別非常大。4.3 節(jié)點(diǎn)、容器與連線的繪制規(guī)范節(jié)點(diǎn)的尺寸盡量統(tǒng)一最多根據(jù)內(nèi)容多少做1.25倍以內(nèi)的浮動(dòng)不要忽大忽小。圓角矩形取中等圓角別過度圓潤(rùn)邊框線寬統(tǒng)一2像素重點(diǎn)節(jié)點(diǎn)可以用3像素加粗并疊加主色。容器的畫法是淺底色加標(biāo)題條用來表示系統(tǒng)邊界。容器內(nèi)節(jié)點(diǎn)不要貼著容器邊線至少留出一個(gè)柵格單位的呼吸空間。容器標(biāo)題用16像素內(nèi)嵌節(jié)點(diǎn)正文用14像素層級(jí)落差要明顯才不會(huì)讓人分不清邊界和組件。連線的優(yōu)先級(jí)最高。連線盡量使用正交連線也就是直線加直角折線這是技術(shù)圖最穩(wěn)的選擇視覺上干凈曲線只用于數(shù)據(jù)流、事件流這類需要“流動(dòng)感”的場(chǎng)景。連線方向要明確帶箭頭表示調(diào)用或數(shù)據(jù)流向指針一定指向被依賴方。線寬上普通連線用1.5像素重點(diǎn)鏈路用2像素這樣才能拉開層次。4.4 標(biāo)注與注釋的放置策略最后是標(biāo)注。圖例固定放在右下角注釋塊放在左下角關(guān)鍵路徑可以用淺色覆蓋框標(biāo)出但覆蓋框絕不能擋住任何連線和節(jié)點(diǎn)。一個(gè)很實(shí)際的經(jīng)驗(yàn)是注釋永遠(yuǎn)不要離它解釋的對(duì)象太遠(yuǎn)最好用一條短虛線直接引出。否則讀者看完注釋還要回到圖上找位置閱讀成本立刻翻倍。我自己還習(xí)慣給圖編一個(gè)標(biāo)題欄寫在左上角包含圖名、日期和版本號(hào)方便評(píng)審時(shí)對(duì)圖說話。5. 真實(shí)項(xiàng)目里的三個(gè)翻車現(xiàn)場(chǎng)與排查鏈路5.1 翻車一一張網(wǎng)關(guān)架構(gòu)圖變成“毛線團(tuán)”某次我提交了一張網(wǎng)關(guān)改造方案圖圖上三十個(gè)服務(wù)節(jié)點(diǎn)彼此依賴關(guān)系交錯(cuò)。評(píng)審人盯著圖看了半天最后說了一句“這圖我沒法看。”我的排查思路分三步走。第一步把圖縮小到三分之一用人眼整體掃一遍看主干是否清晰。結(jié)果發(fā)現(xiàn)主線被支線打斷根本找不到入口在哪。第二步把所有節(jié)點(diǎn)按“接入層、核心層、外部依賴”三層歸類發(fā)現(xiàn)問題出在初始布局不同層級(jí)的服務(wù)全部平鋪在一條泳道上橫向距離很遠(yuǎn)連線自然又長(zhǎng)又交叉。第三步重新排布為三個(gè)池子接入層在最上核心層在中間外部依賴在最下。同層內(nèi)部再按調(diào)用頻率從左到右排序。修復(fù)之后連線交叉數(shù)從17處降到3處主干一眼可見。這次翻車的教訓(xùn)是連線亂不要急著做局部挪動(dòng)先回到信息分層層面去重新組織節(jié)點(diǎn)位置。局部微調(diào)治標(biāo)不治本重新分層才是治本。5.2 翻車二一張全景圖變成“千層餅”還有一次我想把一套完整平臺(tái)的架構(gòu)畫成一張全景圖用戶層、接入層、應(yīng)用層、領(lǐng)域?qū)?、基礎(chǔ)層、網(wǎng)絡(luò)層全部塞進(jìn)去每層還有二級(jí)組件。結(jié)果縮小時(shí)看不清名稱放大時(shí)找不到所屬層級(jí)評(píng)審時(shí)完全沒法用。排查之后我發(fā)現(xiàn)病根不在排版而在抽象層級(jí)一張圖承載了三層甚至四層抽象這是設(shè)計(jì)目標(biāo)本身出了問題。解決方案是拆分視角給不同讀者做不同的圖面向評(píng)審的圖只畫四個(gè)抽象層每層一個(gè)容器內(nèi)部不展開細(xì)節(jié)面向開發(fā)的圖單獨(dú)畫每個(gè)容器內(nèi)部的服務(wù)與依賴一張圖只覆蓋一個(gè)容器面向運(yùn)維的圖單獨(dú)畫部署環(huán)境與網(wǎng)絡(luò)邊界。三張圖合起來才是完整架構(gòu)但任意一張圖都只聚焦在一個(gè)抽象層級(jí)上。后來我給自己立了規(guī)矩同一張圖里抽象層級(jí)盡量不超過兩層容器算一層容器內(nèi)的節(jié)點(diǎn)算第二層。5.3 翻車三PNG導(dǎo)出后在大屏上糊成一片某次評(píng)審前我把架構(gòu)圖導(dǎo)出成PNG發(fā)給對(duì)方。會(huì)議室大屏一放文字邊緣發(fā)虛細(xì)線全部消失。那次的排查鏈路比較典型。第一步確認(rèn)不是屏幕問題。筆記本上放大到200%看還是虛的說明是位圖本身分辨率不足。第二步檢查導(dǎo)出設(shè)置。發(fā)現(xiàn)當(dāng)時(shí)導(dǎo)出PNG的縮放比例只有1倍1920×1080的畫布導(dǎo)出后就是1920像素寬放到大屏上細(xì)節(jié)全部丟失。第三步改成導(dǎo)出SVG。SVG是矢量格式文字是真正的文本和曲線無論放大多少倍都不會(huì)虛化。那次之后團(tuán)隊(duì)約定改成兩條評(píng)審交付優(yōu)先用PDF或SVG禁止直接發(fā)PNG如果平臺(tái)只收位圖PNG的最小寬度像素要按目標(biāo)屏幕做倍率換算不能隨手導(dǎo)出一張。這個(gè)翻車也解決了字體問題SVG里沒嵌入字體時(shí)換一臺(tái)機(jī)器就可能替換字體、導(dǎo)致排版變化。所以涉及特殊字體的圖導(dǎo)出前要做字形轉(zhuǎn)曲或者嵌入字體子集。6. 讓圖表資產(chǎn)像代碼一樣被維護(hù)6.1 模板化、組件化與圖層命名規(guī)范團(tuán)隊(duì)圖表數(shù)量多了以后最痛苦的事是“一個(gè)通用需求改動(dòng)導(dǎo)致所有圖都要跟著動(dòng)”。這個(gè)問題的解法是把圖表的元素當(dāng)成代碼里的組件來維護(hù)。我在draw.io里建了組件庫服務(wù)節(jié)點(diǎn)、數(shù)據(jù)庫節(jié)點(diǎn)、消息隊(duì)列節(jié)點(diǎn)、容器框、各種箭頭、異常標(biāo)記等全部做成可拖拽的模板。模板的默認(rèn)樣式統(tǒng)一維護(hù)。畫新圖時(shí)從組件庫里拖組件而不是復(fù)制一張舊圖再刪改內(nèi)容。復(fù)制舊圖的方式很容易留下歷史元素圖層會(huì)越來越臟。圖層命名規(guī)范則參考了CSS的命名思路拆成三段層級(jí)、模塊名、元素描述。例如一條網(wǎng)關(guān)節(jié)點(diǎn)的圖層名可以寫成“L1_PAYMENT_GATEWAY_NODE”。命名越清晰后續(xù)協(xié)作時(shí)別人越容易查找和修改。模板化帶來的額外紅利是需要調(diào)整組件樣式時(shí)可以通過批量樣式替換一次生效不需要逐張圖手動(dòng)改。這也是圖表資產(chǎn)不會(huì)像散裝圖片那樣快速腐爛的關(guān)鍵。6.2 讓圖表進(jìn)版本庫像代碼一樣被審查最后一步我把圖表源文件放進(jìn)了項(xiàng)目的版本庫而不是存在個(gè)人電腦或聊天軟件的傳輸記錄里。流程是draw.io的源文件以XMI格式存入Git倉庫Mermaid的圖直接用Markdown源碼存儲(chǔ)每次架構(gòu)變更都伴隨圖表的變更評(píng)審時(shí)圖和代碼一起看凡是圖上與代碼不一致的地方評(píng)審中直接標(biāo)出來絕不接受“圖先大略畫著代碼以后再對(duì)”的說法。有人覺得這套流程麻煩我的經(jīng)驗(yàn)是圖表一旦不納入版本管理三個(gè)月后就會(huì)變成一張“沒人敢信的歷史截圖”。把圖當(dāng)代碼審查、當(dāng)代碼演進(jìn)圖表資產(chǎn)才能真正變成團(tuán)隊(duì)的知識(shí)資產(chǎn)而不是一次性的溝通草稿。走到這一步再回頭看“diagram-design”這個(gè)項(xiàng)目名它對(duì)我來說已經(jīng)不只是一種技巧或工具而是一套工程習(xí)慣先想清楚信息層級(jí)再選擇工具和布局用統(tǒng)一規(guī)范約束視覺表達(dá)最后把圖表納入版本體系持續(xù)演進(jìn)。最后再分享一個(gè)小習(xí)慣每張圖交付之前我都會(huì)做一次“三個(gè)月后測(cè)試”想象三個(gè)月后的自己或者一個(gè)完全沒參與項(xiàng)目的新同事只看這張圖、不看任何解釋能不能說出這張圖想表達(dá)什么。如果答案是否定的那問題多半不在繪圖技巧而在信息架構(gòu)沒理清。這個(gè)自測(cè)非常簡(jiǎn)單但它幫我攔下了很多無效圖表。圖表設(shè)計(jì)這件事做到最后拼的不是軟件熟練度而是對(duì)信息層級(jí)的敏感度和對(duì)讀者的體諒。希望這套從規(guī)劃、繪制到維護(hù)的經(jīng)驗(yàn)?zāi)茏屇愕膱D紙少一點(diǎn)“草稿感”多一點(diǎn)“一次就能讀懂”的確定性。