前言
過去三天,我們陸續寫出了讀取資料、呼叫 API、推送結果的程式碼片段。今天要退後一步,不寫新程式碼,而是把整個系統畫成一張圖。這聽起來像是額外的裝飾工作,但它其實有具體的實用價值——尤其是當這套系統未來需要交接、或你自己需要在幾個月後回頭維護時。

一、為什麼寫完程式之後,還需要畫圖
回顧 Day 22 談過的版本控制,我們建立了修改日誌,記錄「範本規則」怎麼演變。但程式碼本身的整體架構,通常不會被一份文字日誌完整涵蓋——日誌記錄的是「一條一條的變更」,而架構圖呈現的是「這些零件,合起來是怎麼運作的整體樣貌」。
當你的系統只有一個檔案、幾十行程式碼時,架構圖看起來確實像是多此一舉。但回顧 Day 26、27,你已經累積了讀取資料、組裝範本、呼叫 API、推送結果,至少四個功能區塊——當零件數量超過三、四個,靠純粹閱讀程式碼去重建「整體流程是怎麼串起來的」,開始變得吃力,這時候一張圖能節省的時間,就會遠遠超過畫圖本身花費的時間。
二、流程圖:呈現「資料怎麼流動」
流程圖的重點,是呈現資料從頭到尾,依序經過哪些處理步驟。把 Day 26、27 累積的內容整理起來,大致長這樣:

[監控平台匯出 CSV]
↓
[read_events() 讀取資料]
↓
[build_prompt() 套用範本、填入佔位符]
↓
[call_ai_api() 呼叫 AI 工具]
↓
┌───┴───┐
↓ ↓
[成功] [失敗]
↓ ↓
[save_report() [記錄錯誤日誌,
儲存 .md] 通知人工介入]
↓
[send_to_slack() / send_email()
推送到指定管道]
這張圖的價值,在於它把 Day 12 談過的「安全降落」邏輯,也視覺化地呈現出來——失敗不是流程的死路,而是一個明確被畫出來、有對應處理方式的分支,而不是消失在程式碼細節裡沒人注意到。
三、UML 類別圖:呈現「零件之間的關係」(進階選項)
如果你的系統之後會擴充得更複雜(例如同時處理日報、週報、月報,各自邏輯略有不同),流程圖可能就不夠用了——這時候可以考慮用 UML 類別圖,呈現不同「零件」各自負責什麼、彼此之間怎麼互動。
用簡化的方式理解,一個類別圖可能長這樣:

┌─────────────────┐
│ DataLoader │ 負責:讀取與初步驗證資料
│ + read_events() │
└────────┬─────────┘
│ 提供資料給
↓
┌─────────────────┐
│ PromptBuilder │ 負責:套用範本、填入佔位符
│ + build_prompt()│
└────────┬─────────┘
│ 提供 prompt 給
↓
┌─────────────────┐
│ AIClient │ 負責:呼叫 API、處理回應
│ + call_api() │
└────────┬─────────┘
│ 提供結果給
↓
┌─────────────────┐
│ ReportDispatcher│ 負責:儲存與推送
│ + save() │
│ + push() │
└─────────────────┘
這種拆分方式,呼應 Day 4 談過的變數化思維——每個零件負責單一、明確的職責,未來如果只有「推送方式」需要調整(例如新增一個推送到別的平台的功能),你很清楚只需要動 ReportDispatcher 這個部分,不需要擔心影響到資料讀取或 AI 呼叫的邏輯。
四、畫圖不用追求正式規範,重點是「讓自己跟別人看得懂」
這裡要提醒一件事:UML 有一套正式的繪圖規範,但對於這種個人或小團隊維護的自動化小工具,不需要追求學院派的標準畫法。重點是這張圖能不能達成兩個目的:

1. 幾個月後的你,回頭看這張圖,能不能快速想起「整個系統是怎麼運作的」
2. 如果要交接給同事,對方看這張圖,能不能在幾分鐘內大致理解架構,而不用逐行讀程式碼
   只要達成這兩個目的,用簡單的方框加箭頭手繪,也完全足夠。
   五、今天的行動練習
   依照今天的流程圖範例,把你目前實際寫出來的程式(Day 26、27 的內容),畫成一張屬於你自己系統的流程圖,並標註出每個步驟失敗時,分別會發生什麼事、由誰負責處理。

小結
今天我們暫停寫程式,退後一步把整個系統畫成圖。這不是形式主義的裝飾工作,而是讓「零散的程式碼片段」,變成一個有整體樣貌、容易維護、容易交接的系統的關鍵一步——尤其是失敗處理的分支,畫出來之後,才不會被淹沒在程式碼細節裡。
最後一天實質內容,我們要處理整個自動化系統裡最不能馬虎的一環:安全性與隱私考量,把 Day 13 提前建立的機敏資料原則,延伸到整個自動化流程的每個環節。