要用 AI 建立架構圖，先各選定一個受眾、問題、範圍和視圖層級，再根據獲批程式碼、部署設定、契約和運作證據，整理元素與有向關係台賬。只讓 AI 起草能引用台賬的節點和連線，再由系統負責人審核標題、範圍、圖例、元素類型、關係方向、標籤、未知項和敏感細節。

模型能加快擷取和排版，但除非你提供經核實的觀察結果，否則它看不到運行時的真實狀況。安全輸入界線見AI 使用總指南。若只想理解一條程式路徑，應改用程式碼解釋流程；架構圖回答的是針對特定受眾、範圍明確的系統問題。

關鍵要點

先定架構圖要回答甚麼問題，再收集方框。

系統、容器、組件和部署視圖分開。

每個元素和關係都附證據出處。

用有方向、有標籤的關係，不用裝飾線條。

標出未知項和衝突，不畫看似合理的連接。

分享前刪除敏感細節，並經負責人批准。

架構圖給誰看、支援甚麼決定？

管理層、值班工程師和修改單一服務的開發人員需要不同的圖。先寫簡要說明：讀者是誰、支援哪項決定或工作、讀者已知道甚麼。例如：

向新同事解釋系統邊界和外部參與者；
為保安評估檢視信任邊界；
為營運交接展示可部署單元及基礎設施；
找出擬議遷移影響的依賴；
在事故檢討中解釋一次請求或事件流程。

C4 模型以一組抽象層級描述軟件架構，並強調按受眾選擇合適的溝通層級。［1］它是實用詞彙，不要求畫出所有可能的圖。若問題是「每個可部署單元在哪裏運行？」，部署視圖比原始碼層面的組件圖更有用。

寫明非目標。高層系統脈絡圖不應再塞進每個隊列主題、數據庫表格、類別和雲端資源。受眾需要兩個層級時，就畫兩張有標題的圖，以穩定元素 ID 對應。

應選哪個視圖層級和範圍？

C4 的圖表說明區分系統脈絡、容器、組件、動態和部署等視圖。［2］每張圖只用一個主要抽象層級：

視圖	核心問題	常見元素
系統脈絡	誰使用這個系統，它周邊有甚麼？	人、軟件系統
容器	系統由哪些可部署或可運行單元組成？	網頁應用程式、服務、數據儲存
組件	某容器內有哪些主要組件？	模組、轉接器、服務
動態	某情境中各元素如何協作？	編號互動
部署	各實例在哪裏運行？	節點、環境、容器實例

設定邊界，例如「類生產參考環境中的公開訂購系統及直接依賴」，並記錄排除的區域、管理工具、分析系統或災難復原資源。邊界屬圖的含義，應寫進標題或副標題。

哪些證據可以安全交給模型？

可用證據包括儲存庫結構、依賴清單、路由定義、依賴注入、API 及事件契約、部署清單、基礎設施設定、網絡政策、數據庫遷移、監控儀表板、運作手冊和服務目錄條目。凍結確切版本，只收集獲准給目標受眾看的資料。

刪除密鑰、憑證、私鑰、客戶資料、內部 IP 地址、敏感主機名稱、保安控制細節和未公開漏洞。公開圖通常以「身份提供者」這類邏輯名稱代替私人端點。去敏清單已足夠時，不要讓公共 AI 服務檢查整個私人儲存庫。

區分證據類別：

聲明： 設定或契約表示某個元素或關係應該存在；
實作： 程式碼中有相關路徑；
部署： 有版本的部署產物把它放在某個位置；
觀察： 經授權的運作證據顯示了流量或狀態；
未知/衝突： 來源互相矛盾，或不足以證明該說法。

匯入只證明可能的程式碼依賴，不證明請求在運行時經過它；部署清單證明期望設定，未必是生產環境現況。保留這些分別。

建立元素台賬

為每個元素指定穩定 ID，改名時證據連結不會斷。記錄類型、職責、技術（僅在相關時）、範圍、來源、負責人和可信程度。

元素 ID	類型	名稱	職責	技術	證據	狀態
C-WEB	容器	網頁端	接收用戶操作	獲批運行環境	網頁端部署設定及路由	已確認
C-API	容器	API 服務	驗證指令	獲批運行環境	API 部署設定及契約	已確認
C-WORK	容器	處理器	處理排隊中的工作	未知	隊列設定	待審核

不要把每個程式庫變成組件，只放有助回答所選問題的元素。職責無法一句說清時，可能範圍太大，或需在另一視圖拆解。

建立有向關係台賬

C4 標記法建議寫明元素類型、簡短描述，以及有方向和標籤的關係。［3］沒有動詞的線條意思含糊。記錄起點、終點、用途，有證據時才寫協議或數據，並附來源出處。

關係 ID	起點	終點	方向與用途	協議或數據	證據	狀態
R-01	C-WEB	C-API	發送已驗證的指令	HTTPS/JSON	客戶端及 API 契約	已確認
R-02	C-API	C-QUEUE	把已批准的工作放入隊列	事件數據結構	生產者設定	已確認
R-03	C-WORK	C-DB	寫入處理後的狀態	未知	只有程式碼路徑	待審核

不要因網頁端和數據庫都提及同一實體，就推斷兩者直連；也不要因回應經請求通道傳回就倒轉連線，應按該視圖關注的訊息或控制方向標示互動。雙向互動確實重要時，用兩條有標籤的關係，或標記法支援的精確標籤。

別名、衝突和欠缺證據應如何處理？

儲存庫和部署系統常以不同名稱指稱同一邏輯元素。建立別名表，每次合併都要有證據；名稱相似不是證據。反過來，同一名稱也可能指向不同實例或環境。

讓 AI 列出候選配對及理由和出處，由負責人批准。以下情況保留衝突記錄：

程式碼呼叫某服務，但部署設定沒有聲明；
設定聲明了隊列，卻找不到生產者或消費者；
運作手冊提到已退役、但仍在部署清單中的組件；
監控觀察到文件契約沒有的路徑；
負責人或所屬環境不清楚。

若某個未知元素對回答問題不可或缺，可用刻意區分的樣式畫出「未知」元素，但絕不可為版面對稱把它畫成普通的已確認方框。

先定義圖示契約，再處理排版

先訂明視覺語義，免得讀者猜測：

每種允許的元素類型各用一種矩形樣式；
已確認有向關係統一用一種箭嘴；
候選或未知項用明顯不同、合乎無障礙要求的樣式；
箭嘴上或旁邊寫簡短關係動詞；
圖例解釋元素類型和證據狀態；
標題寫明視圖、系統、範圍和相關環境；
需要追溯時，在標籤或附表保留穩定 ID。

顏色不能是唯一分辨方法，要配合文字標籤、邊框或圖案。不要用暗示未經證實的供應商、數據庫或保安控制的圖示。除非技術正是受眾的問題核心，技術名稱應次於職責。

用 AI 建立架構圖的受約束草稿

根據附上的台賬，產生一份架構圖規格。

受眾：[受眾]
問題：[問題]
視圖層級：[一個層級]
範圍與環境：[範圍]

只使用「已確認」的元素和關係，保留穩定 ID。每條連線都必須有方向、
簡短動詞短語和證據 ID。「未知」和「衝突」的項目放進獨立的審核清單，
不要畫成已確認。加入標題、範圍副標題、元素類型圖例和證據狀態圖例。
不要加入台賬沒有的供應商、協議、數據庫、保安邊界、區域或運作路徑。

先要求模型輸出文字中間表述，如節點與連線表格或獲批的圖表語言，再渲染成圖。文字較易比對差異、審核和重新產生。排版指示只屬呈現，不是架構事實。

合成證據圖範例

以下確定性示意圖採用完全虛構的網頁端、API 服務、工作隊列、處理器和數據庫拓撲，示範圖示契約：有類型的矩形節點、筆直有向箭嘴、關係標籤、範圍標題和圖例。它不代表任何真實項目、客戶、帳戶、部署或實測運作路徑。

配套台賬會記錄：網頁端到 API 服務是指令，API 服務到工作隊列是排入的工作，工作隊列到處理器是派送，處理器到數據庫是狀態寫入。不能只為畫面緊湊就加畫網頁端直達數據庫的連線。

為何要先審結構再調美觀？

按以下次序做語義審核：

問題： 圖有否回答列明的受眾問題？
邊界： 範圍內、外部和排除的系統是否清楚？
層級： 每個元素是否屬於所選抽象層級？
元素： 每個節點能否追溯到獲批台賬記錄？
關係： 每個箭嘴是否有方向、用途和證據？
未知項： 衝突是否在審核記錄中可見，而非被隱藏？
敏感程度： 圖是否適合預定的分享範圍？
可讀性： 標題、標籤、圖例和閱讀次序是否清晰？

之後才調整間距、對齊、顏色、交叉線和標籤位置。有錯誤連線的漂亮圖比樸素的正確圖更差。

部署圖為何要獨立處理？

C4 部署圖把軟件系統或容器實例對應到特定環境的部署節點。［4］開發、預備和類生產環境佈局可能不同，要寫明環境和快照，並分清邏輯容器、實例和基礎設施節點。

只有獲批證據支持且受眾獲授權查看時，才加入區域、叢集、節點、網絡分區、擴展數量、故障轉移或儲存。不要無必要暴露公開攻擊面或內部控制。數量屬動態時，僅在部署契約支持下使用 1..N 這類有文件依據的多重性，不要把某一刻觀察到的數量當作架構照抄。

怎樣令架構圖保持可維護？

政策許可時，把證據台賬和文字圖表原始檔放在持續維護的文件旁，記錄儲存庫或產物版本、審核日期、負責人和重新產生的觸發條件。實用觸發條件包括路由、契約、部署清單、服務目錄、隊列、數據庫或負責人變動。

盡量自動偵測偏差，但不要自動發佈架構變更。路由改名可能只是機械改動；新的外部數據流卻可能需要保安和私隱審核。自動產生的差異應小到負責人看得明白。

完成準則：每個可見節點和連線都能追溯到獲批證據；未解決事項已列出；層級一致；敏感資料已刪除；標籤和圖例清晰；負責的系統負責人已批准確切原始檔和渲染結果。

可複製的架構證據模板

# 架構圖說明卡
- 受眾：
- 問題／決定：
- 視圖層級：
- 系統與範圍：
- 環境／快照：
- 排除項目：
- 分享級別：

## 元素
- 元素 ID：
- 類型：
- 名稱：
- 職責：
- 技術（如相關）：
- 證據與版本：
- 負責人：
- 狀態：

## 關係
- 關係 ID：
- 起點／終點：
- 方向與動詞：
- 協議或數據（如有證據）：
- 證據與版本：
- 狀態：

## 審核
- 衝突和未知項：
- 已刪除的敏感細節：
- 已核對圖例與標題：
- 系統負責人批准：
- 保安／領域批准（如需要）：

若圖用來支援遷移決定，應連結到另行批准的程式碼遷移藍圖。別讓圖片悄悄成為更改系統的授權。

常見問題

AI 能直接從程式碼發現架構嗎？

它能擷取候選元素和靜態依賴；運行時路徑、部署、數據擁有權和外部關係仍需額外證據和負責人審核。

應該先畫哪一種架構視圖？

從能回答受眾問題的最小視圖開始。系統脈絡圖或容器圖通常比混雜一切的大圖更易核實。

一張圖應否展示所有層級？

不應該。混合系統、容器、組件、類別和部署節點會令含義模糊，應使用有標題、共用穩定 ID 的獨立視圖。

兩個來源對某條連接說法不一時怎麼辦？

把該關係留在衝突登記冊，由負責人解決，不要畫成已確認。

架構圖可以自動更新嗎？

可以自動擷取和產生偏差報告，但發佈前須審核，尤其涉及外部數據流、信任邊界、數據儲存和負責人變動。

怎樣避免架構圖變得難以閱讀？

收窄範圍，只用一個抽象層級，刪去不回答問題的細節，把不同情境或環境拆成獨立視圖。

應刪除哪些敏感資料？

憑證、私人地址、客戶資料、未公開漏洞、不必要的保安控制細節，以及受眾無權查看的任何拓撲。

架構圖何時才算完成？

每項可見說法都可追溯、未知項已記錄、視圖一致易讀、分享安全，且具名負責人批准原始檔和渲染結果時，才算完成。

來源

Sources checked 2026 年 8 月 29 日。

C4 Model, “Visualising software architecture” — https://c4model.com/
C4 Model, “Diagrams” — https://c4model.com/diagrams
C4 Model, “Notation” — https://c4model.com/diagrams/notation
C4 Model, “Deployment diagram” — https://c4model.com/diagrams/deployment

用 AI 建立架構圖：鎖定受眾與視圖層級，不畫無證據的連線