Day 21：為什麼技術文章需要圖表，視覺代理人的定位 結尾留下一句話，定位與邊界確立之後，接下來要一種一種具體打造這些能力，第一個要處理的是架構圖，讓視覺代理人依文章內容自動繪製流程性質的圖表，這件事今天還沒有答案，將在下一篇正式揭曉。今天要正面回答這件事。

定位確立了，第一種能力該長什麼樣子

Day 21 已經把視覺代理人的定位與職責邊界確立下來，它的輸入是已經存在的文字或數據，輸出是對應的視覺呈現，不判斷論述邏輯，不修改正文。定位有了，接下來要一種一種具體打造這些能力，第一個要處理的，是架構圖，讓視覺代理人依文章內容自動繪製流程性質的圖表。

今天要正面回答這件事，答案的方向分兩步走，先劃清架構圖這個產出類型的範圍，再定案視覺代理人如何從文字內容轉譯出架構圖。

在往下走之前，先把今天的任務範圍畫清楚。今天只定義架構圖這一種視覺產出類型的轉譯原則，不涉及具體繪圖語法或工具，也不涉及資料視覺化、封面插圖、雙代理人協同實戰，這些留給接下來幾天處理。

架構圖畫的是結構，不是數字

先回答第一個問題，架構圖這個產出類型，範圍究竟畫在哪裡。

架構圖指的是流程性質的圖表，涵蓋系統架構圖、工作流程圖、狀態轉換圖這類呈現步驟或元件之間關係的圖表。這三種類型看起來各自處理不同場景，系統架構圖畫的是元件如何組成一套系統，工作流程圖畫的是步驟如何依序推進，狀態轉換圖畫的是狀態如何依條件轉移，但三者共同特徵完全一致，內容本質是結構或順序關係，畫面呈現的是元件與元件之間、步驟與步驟之間如何連接與轉移。

這個範圍界定，需要與另外兩種即將登場的視覺產出類型明確區隔。第一個要區隔的是資料視覺化，也就是 Day 23 的範疇。資料視覺化處理的是數值大小、比例、趨勢這類數量關係，架構圖處理的是結構或順序關係，兩者關注的內容本質完全不同。一段文字如果描述的是某個指標隨時間如何變化，或是幾個選項各自佔比多少，這屬於數量關係，不屬於今天要定義的架構圖範圍，這是 Day 23 才會展開的範疇，今天只劃清界線。

第二個要區隔的是封面插圖，也就是 Day 24 的範疇。封面插圖偏向美術創作性質，目的是吸引目光或營造氛圍，架構圖的目的是如實呈現既有的結構關係，不涉及美術創作的判斷。一張封面該用什麼構圖、什麼色調吸引讀者點閱，這是創作性質的決策，與架構圖忠實轉譯結構關係的性質完全不同，這是 Day 24 才會展開的範疇，今天同樣只劃清界線。

把三者的區隔判準收束成一句話，本質是結構關係、還是數量關係、還是美術創作，這是辨識一段內容該歸入哪一種視覺產出類型的判準。架構圖這個產出類型的判準也就清楚了，一段內容是否包含可辨識的節點與節點之間的關係，這正是接下來要定案轉譯原則時的判斷起點。

那個一直出現的 HTML 註解，原來是這麼回事

系列讀到這裡，細心的讀者可能已經注意到，Day 16：程式碼生成的正確性保證機制、Day 17：狀態管理，讓寫作代理人記得前幾天寫過什麼、Day 18：處理複雜內容，長篇論證與公式推導的撰寫策略 的正文裡，都已經出現過說明流程的圖片。像是在 Day 16

在寫作代理人寫好的文章內，這邊圖片的位置，原本都是形式相似的 HTML 註解，開頭固定寫著圖表佔位，後面接著一段描述。在後面，由視覺代理人根據寫作代理人留下的圖表佔位資訊，然後畫出對應的架構圖。

先把三處確切原文攤開來看。

Day 16 正文，在描述完查詢動作與執行驗證兩道關卡如何嵌入同一段落節點之後，出現：

<!-- 圖表佔位：呈現寫作代理人在單一段落展開過程中，遇到程式碼片段時，查詢動作與執行驗證兩道關卡如何依序或並存嵌入同一段落節點內部運作，並標示驗證未通過時回頭調整、通過才繼續往下一段的路徑 -->

Day 17 正文，在描述完查閱與回填這個迴圈如何鑲嵌在逐段展開節奏裡之後，出現：

<!-- 圖表佔位：呈現寫作代理人在逐段展開的節奏裡，每當某一段落涉及具體案例或程式碼版本時，先查閱共享記錄再動筆、完稿後回填新內容的迴圈，並標示這個迴圈與段落展開節奏是同一條時間軸，而非獨立於外的另一套流程 -->

Day 18 正文，在描述完論證步驟拆解如何要求每一步顯式交代依據之後，出現：

<!-- 圖表佔位：呈現寫作代理人展開一段長篇論證時，論證步驟依序被觸發的節奏，每一步驟先確認立足的前提、寫出這一步的結論，才允許進入下一步驟，並標示步驟之間顯式交代依據的銜接關係 -->

三處格式一致，都緊接在描述完某段流程邏輯的文字之後，以 HTML 註解形式插入，開頭固定為「圖表佔位」，接續一段描述這個流程該呈現哪些節點、哪些關係、哪些路徑分支的文字。

今天要正式定案，這個佔位符正是規劃代理人或寫作代理人在撰寫過程中，為視覺代理人預留的輸入介面。它不是排版裝飾，也不是隨手留下的備註，而是明確標記出這個位置需要一張圖、以及這張圖該呈現的內容線索。

系列前面三天已經埋下這個伏筆，讀者當時可能只是略過，今天正式收穫回報。視覺代理人今天要做的事，正是讀取這則佔位描述，把描述裡點出的節點、關係、路徑分支轉譯成實際的架構圖，取代這個佔位符原本所在的位置。這是系列設計上早就埋好的一段閉環，不是今天才臨時發明的新機制。

從一段佔位描述，到一張真正的架構圖

定案了輸入介面之後，接下來要定義，視覺代理人具體如何從一則佔位描述，轉譯出一張實際的架構圖。這是本篇的技術核心，全篇維持原則與工作模式層級論證，涵蓋判斷依據、轉譯輸入、轉譯輸出三個層次。

第一個層次，判斷依據。視覺代理人如何判斷一段內容適合轉譯成流程性質圖表，依據是這段文字或佔位描述裡是否明確點出多個節點、以及節點之間的先後或依附關係。以 Day 18 那則佔位描述為例，裡面點出了論證步驟、每一步驟的前提與結論、步驟之間顯式交代依據的銜接關係，這些都是可辨識的節點與關係，適合轉譯成流程圖。反過來說，若一段內容單純是敘述性文字，沒有可辨識的節點與關係結構，就不適合轉譯成架構圖，這種情況該交給哪一種視覺呈現，不在今天討論的範圍內。

第二個層次，轉譯輸入。視覺代理人讀取的是佔位描述裡已經點出的節點、關係、路徑分支這些結構化線索，不是自己重新閱讀通篇正文去猜測畫面該長什麼樣子。以 Day 16 那則佔位描述為例，視覺代理人要畫的節點是查詢動作與執行驗證兩道關卡，要畫的路徑是驗證未通過時回頭調整、通過才繼續往下一段，這些線索已經寫在佔位描述裡，視覺代理人不需要重新回頭讀一遍 Day 16 整篇正文才能決定畫面內容。這一點呼應 Day 21 定案的視覺代理人輸入是已經存在的文字或數據。

第三個層次，轉譯輸出。視覺代理人產出的圖表必須忠實呈現佔位描述裡點出的節點與關係，不能自行增減節點，不能自行調整關係方向。以 Day 17 那則佔位描述為例，圖表該呈現的是查閱共享記錄、動筆、完稿、回填新內容這個迴圈，並標示這個迴圈與段落展開節奏是同一條時間軸，視覺代理人不會因為自己覺得畫面需要更豐富，就額外加上佔位描述裡沒有出現的節點，也不會擅自把迴圈畫成獨立於段落展開節奏之外的另一條時間軸。這一點呼應 Day 21 定案的不判斷論述邏輯、不修改正文，視覺代理人畫的是佔位描述已經點好的結構，不是自己重新詮釋一遍。

這裡可以簡短類比 Day 14：寫作代理人的架構設計，從規格到草稿 定案的工作模式。就像寫作代理人讀取規劃代理人的段落規格，依循規格裡點出的重點與前提展開成文字；視覺代理人讀取圖表佔位描述，依循描述裡點出的節點與關係轉譯成圖表。兩者都是讀取一份結構化或半結構化輸入、依循輸入已經點出的重點轉譯成對應產出形式，這同一種轉譯邏輯的體現。

不過這個類比僅用於幫助理解轉譯這個動作的性質，不代表兩個角色的職責出現任何模糊地帶。寫作代理人的輸入是段落規格裡的重點與前提，它負責把這些重點展開成完整的論述文字，視覺代理人的輸入是佔位描述裡已經點出的節點與關係，它不負責重新判斷文章要講什麼，這條邊界與 Day 21 定案的視覺代理人不判斷論述邏輯完全一致，兩個角色各自守在自己的轉譯範圍內，不互相跨界。

至於這個轉譯過程具體要用哪一種繪圖語法或工具產出最終畫面，今天不指定，交由實作時依當下條件決定。這與 Day 16 不規定具體要用哪一種沙箱或執行環境、Day 17 不規定具體要用哪一種資料庫或版本控制系統，是同一種原則層級論證方式。今天只定案這個轉譯原則方向，全篇維持在原則與工作模式層級論證。

流程圖有答案了，數字呢

今天正面回答了 Day 21 留下的伏筆，視覺代理人第一個要具體打造的產出類型是架構圖，讓視覺代理人依文章內容自動繪製流程性質的圖表，這件事今天有了答案。

架構圖的範圍今天劃清楚了，系統架構圖、工作流程圖、狀態轉換圖這類呈現步驟或元件之間關係的圖表，處理的是結構或順序關係，與資料視覺化處理的數量關係、封面插圖偏向的美術創作明確區隔。

今天最重要的定案，是系列正文裡反覆出現的圖表佔位符，Day 16、Day 17、Day 18 都各自留下過一句形式相似的 HTML 註解，這正是規劃代理人或寫作代理人為視覺代理人預留的輸入介面，系列前面已經埋下的伏筆，今天正式收穫回報。視覺代理人讀取這則佔位描述，判斷依據是描述裡是否點出多個節點與節點之間的關係，轉譯輸入是佔位描述裡已經點出的結構化線索，轉譯輸出必須忠實呈現這些節點與關係，不自行增減、不自行調整方向，這條邊界呼應 Day 21 定案的輸入是已經存在的文字或數據、不判斷論述邏輯、不修改正文。

架構圖這類流程性質圖表，今天有了明確的轉譯原則。但技術文章裡還有另一種完全不同性質的視覺需求尚未處理，統計或比較性質的數據，該如何被讀取並生成對應的圖表，這個問題今天還沒有答案，將在下一篇正式揭曉。