可視即意圖:把思維導圖變成人與 AI 共讀的意圖介面

副標:一份技術白皮書——記前人已做的,與我們未來能做的

EveMissLab 工作稿 · EML-VIC-2026-v0.1 · 2026 年 6 月

作者:Neo K.(許筌崴) · 一言諾科技有限公司(EveMissLab)

立場聲明:本文記錄一個構想,以及在它周圍、別人已經做出來的工作。我不在乎是我先想到還是別人先做——如果別人先做了,我尊重他們、感謝他們,並在文中如實引用。把它放到網路上,是希望有人看到之後能接手去做;即使現在來看的多半是 AI,至少它被記下來了。文中引用為 2026 年 6 月檢索所得,連結與年份待日後再核。

摘要

打開一個陌生的 GitHub 專案,你看到的是資料夾樹;你需要的是架構理解。資料夾是語法,架構是語義——GitHub 給了語法,把語義留給你自己猜。更一般地說:一個專案的意圖,在它的程式碼與目錄裡是隱形的。

本文圍繞一個構想:可視即意圖(visualization = intent)——讓一張思維導圖成為人與 AI 共讀的意圖介面。它有兩個方向。反向是「程式碼 → 圖」:把既有的 repo 解析成可互動的架構圖,讓人快速看懂(這是作者 2025 年初〈GitHub 架構透視器〉一文的主題)。正向是「圖 → 專案」:人畫一張思維導圖、直接編譯成專案骨架;而 AI 讀同一張圖,理解並建構、維護這個專案。兩個方向接起來,就是一個迴圈:人 ⇄ 導圖 ⇄ 程式碼,AI 作為其間的編譯器與維護者。

本文要誠實地報告地貌。反向那一半,已經有人做出來、而且幾乎一比一——開源的 GitDiagram 與作者那篇透視器的設計高度重合;這一半的工作不是「做」,是「改」。正向那一半,以及把兩端焊成迴圈的「可視即意圖」,目前沒有統一的成品:能用的零件散落各處(prompt→導圖、自然語言→圖即程式碼、畫 UI→碼、AI 讀寫畫布、古典的模型驅動工程、文字版的規格驅動開發),但沒有人把「思維導圖作為雙向的、人與 AI 共讀的唯一意圖真理」這件事焊起來。那個缺口,是本文留給後來者的設計與記錄。

本文不主張新穎優先;它主張一張地圖加一份設計,外加一個立場:記錄、歸功、交棒。

0. 立場與閱讀須知

這篇白皮書的寫法,被一個立場決定,所以先把立場講清楚。

我不在乎優先權。一個構想若有價值,它由誰先做出來,不改變它的價值。本文裡凡是別人已經做的,我盡量如實引用、清楚歸功;若有遺漏,是我檢索不周,非有意掠美。把東西放到網路上,本來就是為了讓它被接手——哪怕個人學術實驗站現在來看的人很少、且多半是 AI 爬蟲,至少它被記下來,成為一個未來的人或 AI 可以撿起來的起點。

這篇因此分三層。第一層是地貌:別人做了什麼(§3、§4),這是可被查證的事實,我用引用標出處。第二層是缺口:還沒有人做什麼(§5),這是一個判斷,我會說清楚判斷的依據。第三層是設計:我們能做什麼(§6 起),這是一份構想,不是一個成品,讀者應以「設計草案」待之,而非既成系統。

引用以 2026 年 6 月檢索為準。開源專案演化很快(模型換代、API 變動、倉庫更名),所以本文所列的連結、版本與年份,都應在採用前再核一次。凡涉及「這個工具現在到底長什麼樣」,答案以該專案當下的官方倉庫為準,本文只負責指出它在地圖上的位置。

一句話的閱讀守則:地貌當事實看,缺口當判斷看,設計當草案看。

1. 問題:意圖是隱形的

先把問題講到位,因為整篇都掛在這個問題上。

當你打開一個陌生的開源專案,面對的是一棵資料夾樹。即使它有詳盡的文件,大多數人第一次看到那幾十個資料夾時,仍然困惑:這些資料夾之間是什麼關係?哪些是核心、哪些可選?我該從哪裡開始讀?這個困惑揭示一個根本落差:頁面展示的是原始的目錄結構,而你需要的是架構理解。資料夾是語法,架構是語義;工具給了你語法,卻把語義留給你自己去猜[1]。

為什麼一棵目錄樹不足以傳達架構?認知科學給過答案,作者在前作中已援引[1]:人的工作記憶容量有限(Miller 的 7±2),一次看幾十個名稱無法整體把握,只能分批處理,導致理解碎片化;而人腦更擅長處理空間化的層次結構——組織圖、地鐵圖、思維導圖那樣——當資訊被組織成「中心—外圍」「上層—下層」的空間關係時,理解效率顯著提升(Tversky 一系關於空間與認知的研究)。一個平鋪的列表,既無語義標註(contrib/ 到底是核心還是可選?),也無關係呈現(forms 依賴 validators 這件事,只能逐一打開檔案讀 import 去推),認知成本極高。

把這個落差講得更一般:不只「架構」是隱形的,一個專案的意圖整體是隱形的。為什麼這樣分模組、為什麼這條依賴存在、哪些是骨幹哪些是裝飾——這些設計意圖,在程式碼與目錄裡不是不存在,而是潛在而未顯。我們缺的不是資訊,是讓潛在意圖顯現的介面。

這個落差有兩個方向的修法。一個方向是事後的:對著已經寫好的程式碼,把它的架構透視出來給人看。另一個方向是事前的:讓人先把意圖畫成一張圖,再由它生成程式碼,並讓 AI 讀這張圖去理解與維護。前者是「程式碼→圖」,後者是「圖→程式碼」。本文主張,真正值得做的,是把這兩個方向接成一個迴圈——讓那張圖,成為人與 AI 共讀的、唯一的意圖真理。下一節先把這個雙向框架立清楚。

2. 兩個方向:透視與編譯

把「可視即意圖」拆成兩個方向,各有各的成熟度,混為一談會看不清哪塊該做、哪塊該改。

反向:程式碼 → 圖(透視)。 拿一個既有的 repo,自動解析出它的架構,畫成一張可互動、可點擊跳轉到原始碼的圖。這條方向解的是「看懂別人的、或自己舊的專案」。它的輸入是已經存在的程式碼,輸出是一張顯現其架構的圖。作者 2025 年初的〈GitHub 架構透視器〉一文,主題正是這個方向:用 AI 讀資料夾樹與 README、推斷架構模式、生成帶語義標註與依賴關係的互動圖,並讓圖上每個節點超連結回對應的資料夾[1]。

正向:圖 → 專案(編譯)。 反過來,人先畫一張思維導圖,把意圖、模組劃分、依賴、骨幹與裝飾畫進去;然後由它編譯成專案骨架,再由 AI 填入程式碼;而且 AI 把同一張圖當成理解與維護這個專案的依據。它的輸入是一張表達意圖的圖,輸出是一個專案,外加一個能持續被 AI 讀懂的意圖來源。

迴圈:可視即意圖。 把兩個方向接起來,就得到一個環:人畫導圖 → 編譯成專案 → 專案演化 → 透視回導圖 → 人再改導圖。在這個環裡,那張思維導圖不是一張被生成一次就丟的圖,而是人與 AI 共讀的、隨專案來回同步的唯一意圖真理。「可視即意圖」這四個字的全部份量,就在這裡:讓「看得見的那張圖」直接就是意圖本身,而不只是意圖的插畫。

這個框架立清楚之後,接下來兩節要誠實地報告:這兩個方向、與這個迴圈,別人已經做到哪了。先講反向(§3),再講正向的散落零件(§4),然後指出缺口(§5)。

3. 前人已做的:反向(repo → 圖)

先講反向,因為這一半已經被做得相當完整,而且和作者那篇透視器高度重合。誠實地說:這一塊,不是該做,是該改。

最直接的對應是 GitDiagram(ahmedkhaleel2004/gitdiagram)[2]。它是一個開源 web 應用,把任何 GitHub repo 自動轉成可互動的系統架構圖:當你丟一個 repo URL,它向 GitHub API 取預設分支、遞迴檔案樹與 README,過濾掉噪音與依賴資料夾,再餵進一條串流生成管線——先由一個模型寫出白話的架構說明,第二個模型把說明加檔案樹轉成系統、節點、邊與真實 repo 路徑的結構圖,用 Mermaid 渲染,點擊節點可直接跳到對應檔案;它支援公開與私有 repo,可自架,還有一個「把 URL 裡的 hub 換成 diagram」的便捷存取技巧[2]。

把這個對照作者 2025 年初那篇〈GitHub 架構透視器〉[1],會發現設計幾乎一比一:同樣是「讀 tree+README → AI 推斷架構 → 生成可點擊節點的架構圖」,同樣偏好 Next.js 前端 + FastAPI 後端 + 關聯式資料庫 + 快取的技術棧,同樣強調節點超連結回原始碼。GitDiagram 初期以 Claude 3.5 Sonnet 為生成模型,其倉庫現已把模型改為可配置(GPT-5 系列等)、支援自架切換供應商[2]。換句話說,作者那篇白皮書描繪的反向系統,別人已經獨立做出來、且公開了。依本文的立場:尊重、感謝,然後撿來改,而不是從零重寫。

值得留意的是 GitDiagram 停在哪裡:它解的是「看懂既有 repo」,把架構顯現出來給人看。它沒有做的,正是作者那篇白皮書裡真正獨特的延伸——把透視出來的架構導出成一份結構化的架構規格(作者稱 MSSP-Lang),反過來去生成新專案[1]。也就是說,GitDiagram 完成了「程式碼→圖」,但沒有接上「圖→程式碼」。那道接縫,是反向工具普遍缺的,也正是本文正向設計的起點。

在更廣的脈絡裡,反向方向還有同族:把整個 repo 轉成帶圖的說明文件(repo→wiki)一類工具近年也出現了;而它更古老的祖先,是軟體工程裡的逆向工程與程式碼視覺化(從程式碼反推 UML、呼叫圖、依賴圖),那是幾十年的傳統,只是非 AI、也不互動。AI 這一代做的,是把這件事變得即時、便宜、且能讀懂自然語言層面的「這個專案在幹嘛」。總之,反向是一片已開發的地,GitDiagram 是其中最乾淨的 fork 目標。

4. 前人已做的:正向的散落零件

正向比較複雜:它不是一塊完整的地,而是一地散落的零件。每個零件都做了「圖↔意圖↔程式碼」這條鏈的一小段,但沒有人把它們串成一條完整的鏈。逐塊點名,並如實引用。

零件一:文字/prompt → 思維導圖。 這塊最成熟,工具一大把。Whimsical 用一句 prompt(底層為 Claude)生成可編輯的思維導圖[9];GitMind 從技術文件與筆記生成流程圖、UML 圖、心智圖[10];Jeda.ai 一類平台用多個 LLM 做「會診式」的導圖與圖表[11]。這些解的是「從文字長出一張圖」,但圖是產物,不是編譯源。

零件二:自然語言 → 圖即程式碼。 LLM 能把日常描述轉成 PlantUML 或 Graphviz 之類的「圖即程式碼」,直接在對話裡渲染成專業圖,改一句話就重生程式碼、重畫一次[12]。這塊的價值是:圖有了一份文字的、可版控的源(diagram-as-code),這正是「可視即意圖」需要的 IR 雛形——但它生成的是圖,不是專案。

零件三:畫 → 程式碼。 tldraw 的 make-real 是這塊的代表:畫一個 UI,就讓它變成真的、可運行的程式碼[3]。它證明了「視覺 → 程式碼」這條路在 LLM 時代走得通,但它的範圍是 UI/線框 → 前端碼,不是一張結構導圖 → 整個專案。

零件四:AI 讀寫畫布。 這塊最接近「AI 看圖理解專案」。tldraw 的 SDK 內建一個 Agent,能讓 AI 讀取、詮釋、修改畫布內容,還有一個拖拉節點的 Workflow 建構器,做自動化管線、視覺編程與 no-code[4];2026 年推出的 tldraw MCP App,更讓 Cursor、VS Code、ChatGPT、Claude 等 agent 能在對話裡畫圖、「diagram 我現在這個檔案」、把草圖變成現實[5];Whimsical 也提供 MCP,讓 AI 編碼代理直接讀寫它的工作區[9]。這塊把「AI 在畫布上工作」做出來了,但定位是協作面(AI 和你一起在畫布上塗改),不是「把一張導圖當成專案的唯一真理去編譯與維護」。

古典祖先:模型驅動工程。 「圖 → 程式碼」並非 AI 時代才有。軟體工程裡的模型驅動工程(MDE/MDA)早在二十年前就做「從 UML/領域模型生成程式碼」(Eclipse EMF、Sirius、Acceleo 一脈)。它和本文構想的差別有二:其一,它是非 AI 的、規則化的程式碼生成,模型必須畫到極精確;其二,它的模型是 UML 那種工程圖,不是思維導圖那種人類自然的意圖載體。它證明了這條路在原理上可行,也提醒我們:形式化過頭,圖就變得和寫程式一樣累,於是沒人想用。

文字版的近親:規格驅動開發。 這是最重要的定位坐標。2025 年起,一個叫規格驅動開發(spec-driven development)的範式快速成形:不先寫程式碼,而是先寫一份詳細的規格,讓它成為 AI 代理「生成、驗證、回報」所依據的唯一真理。GitHub 於 2025 年開源的 Spec Kit 提供 CLI、模板與提示,把工作流推過「規格 → 計畫 → 任務 → 實作」,且 agent 無關,能搭配 Copilot、Claude Code、Gemini、Cursor 等[14];AWS 於 2025 年 7 月推出的 Kiro,是一個建在 Code OSS 上的 agentic IDE,以 EARS 需求語法、三階段(需求/設計/任務)把開發者「從 vibe coding 帶到可用的程式碼」[15]。這個範式的核心洞見是:當 AI 能廉價產出程式碼,瓶頸就從「寫」移到「對齊」——而讓規格成為單一真理,是對齊的解法[14][15]。

把這個洞見記住,因為它直接撐起本文的賭注:規格驅動開發用的是文字規格;而本文主張,對許多人、許多專案,一張思維導圖是比散文更好的意圖載體——因為它把層次與關係空間化地攜帶。本文要的,是規格驅動開發的視覺版:不是用打字描述意圖,是用一張人與 AI 共讀的圖。順帶一提,「vibe coding」這個詞 2025 年 2 月才被提出,指開發者用 prompt 描述、LLM 自動生成程式碼[13];本文構想可以看成把 vibe coding 從「對著文字 prompt 即興」升級成「對著一張結構化意圖圖協作」。

5. 缺口:沒有人把它焊成迴圈

把 §3 與 §4 擺在一起,缺口就清楚了。零件全在地上,但沒有人把它們焊成一個迴圈。

具體而言,目前沒有一個工具,把「一張思維導圖」當成雙向的、人與 AI 共讀的、與 codebase 來回同步的唯一意圖真理。反向有 GitDiagram(repo→圖)但不回灌;正向有 prompt→導圖(圖是產物不是源)、有畫 UI→碼(範圍是 UI)、有 AI 讀寫畫布(定位是協作面)、有規格驅動開發(用的是文字而非圖)、有古典 MDE(非 AI 且要求工程精度)。每一塊都做了鏈的一小段,但「導圖 → 編譯成專案 → AI 據圖維護 → 演化回灌導圖」這整個環,沒有人焊起來。

為什麼這個環值得焊?三個理由。其一,意圖可見:把意圖畫成一張人看得懂的圖,降低了理解門檻——這正是 §1 那個落差的正面解法。其二,意圖可版控:若那張圖有一份文字的源(像 diagram-as-code 那樣),它就能進版本控制、能 diff、能和程式碼一起演化,不會像傳統架構文件那樣畫完就過時。其三,人與 AI 同源:在規格驅動開發裡,規格成為人與 AI 共讀的單一真理,解決了「AI 產出看似對卻不對」的對齊問題[14][15];本文主張把那個單一真理從文字換成圖,讓人用空間直覺把握、讓 AI 用結構讀取,兩邊讀的是同一張底圖。

缺口的形狀因此可以一句話說定:把規格驅動開發的「單一真理」做成一張人與 AI 共讀的思維導圖,並讓它與 repo 雙向同步。 反向的一半可以撿 GitDiagram 來改,正向與迴圈的一半沒有成品、需要從底座造起。下一節給出這個迴圈的設計。

6. 設計:可視即意圖的迴圈

這一節給出迴圈的設計。再提醒一次:這是一份草案,不是一個成品。它的價值在於把缺口的形狀畫成可以動手的樣子,讓接手的人有起點。

整個設計圍繞一個環:人畫思維導圖 → 編譯成專案 → 專案演化 → 透視回導圖 → 人再改導圖,而 AI 是這個環裡的編譯器與維護者。下面把環拆成六塊講。

6.1 思維導圖作為意圖的中間表示

第一個、也是最關鍵的設計決定:思維導圖不是插畫,是意圖的中間表示(IR)。它有雙層——一層是視覺層,人畫的、人讀的那張圖;一層是文字源,可版控、可 diff、AI 解析的那份底稿。這兩層綁在一起:你動視覺層,文字源跟著變;文字源進版本控制,圖跟著重畫。這不是新發明的綁法,「圖即程式碼」(diagram-as-code,如 Mermaid/PlantUML)早就讓圖有了文字源[12],markmap 一類工具也讓「導圖的源碼和專案一起存」成為常態[8]。本設計只是把這個雙層,正式當成「人與 AI 共讀的同一份意圖」。

6.2 編碼什麼:接母集子集(MSSP)

導圖裡畫的不是隨意的主題樹,是架構意圖。這裡直接接作者既有的母集子集(MSSP)框架[1]:節點是模組;節點的顏色/標記區分核心母集(SMS,不可移除)與可選子集(TMS,可插拔),並標出穩定性(核心/穩定/演化/實驗);邊是依賴(強依賴/弱依賴);節點大小反映被依賴的廣度。換句話說,這張思維導圖,就是視覺化、且人畫得動的那份架構規格(mssp.config)。作者那篇透視器已經定義過「把架構導出成 MSSP-Lang」[1];在本設計裡,這份規格不只是反向的導出物,而是正向的編譯源。

6.3 正向編譯路徑

正向的管線是:思維導圖 → 結構化規格 → 專案骨架 → AI 填碼。逐步說:視覺層的導圖被解析成它的文字 IR;這份 IR 就是 mssp.config(模組、依賴、穩定性);再由 FPL(作者構想的「資料夾程式語言」編譯器[1])把規格轉成完整的專案骨架——資料夾結構、模組劃分、依賴佈線;最後由 AI 代理依著這份規格,把每個模組的實作填進去。這條路徑解的是「圖 → 專案」那一半;它和規格驅動開發的「規格 → 計畫 → 任務 → 實作」[14]同構,差別只在源是一張圖、不是一篇文字。

6.4 反向回灌

反向的一半,撿 GitDiagram[2] 來改:讓演化中的 repo 反過來被解析成架構圖、再轉回導圖的形式。這一步把環閉上,並啟用漂移偵測——把「從 repo 反推出來的導圖」和「人畫的意圖導圖」對比,哪裡分岔,就代表要嘛程式碼偏離了意圖、要嘛意圖移動了,把它顯示出來讓人對帳。這正是 GitDiagram 缺、而作者透視器構想裡有的那道「回灌」接縫[1][2]。

6.5 AI 讀圖:導圖作為代理的單一真理

AI 在這個環裡不只負責「生成導圖」,更要把導圖讀成建構與維護的單一真理。這是規格驅動開發的視覺版:在規格驅動開發裡,一份文字規格是代理執行、驗證、回報所依據的唯一真理[14][15];在這裡,那份唯一真理是導圖(經由它的文字 IR)。「AI 讀畫布」的管線其實已經有人鋪好——tldraw 的 MCP App 讓代理能讀取並圖示一個工作區[5],Whimsical 也把工作區經 MCP 開放給編碼代理[9]。所以本設計要做的,不是發明「AI 怎麼讀圖」,而是把導圖從一個協作面,提升成代理據以行動的規格本身。

6.6 迴圈與漂移

把六塊合起來,完整的環是:人畫/改導圖 → 編譯成專案 → 專案(人與 AI 一起)演化 → 反向轉回導圖 → 與意圖導圖對帳 → 人調和差異。在這整個循環裡,導圖始終是那唯一的真理。漂移偵測是這個環的紀律核心:一張會和真實 repo 對 diff 的活導圖,讓意圖與程式碼不再悄悄分家——而「悄悄分家」正是傳統架構文件畫完即過時的死因,也正是 2025 年被稱為「vibe coding 宿醉」、規格驅動開發要對治的那個對齊問題[13][14][15]。

6.7 底座選擇(依決策規則)

照作者的規則——已有近似就 fork,沒有就挑底座造——分兩半落地。反向那一半:fork GitDiagram[2],把「回灌成 MSSP-Lang/導圖」那段補上去。正向與迴圈那一半:沒有成品,從底座造。最強的底座,是要「AI 能讀寫畫布 + 視覺編程 + 可被代理經 MCP 操作」的——tldraw SDK[4][5] 最對路(內建 Agent、節點 Workflow、MCP app),make-real[3] 是現成的「畫→碼」參考實作可拆解;若要純導圖 UI,simple-mind-map[6](MIT,功能完整,匯出 json/md/xmind)或 mind-elixir7;文字 IR 的來回,用 markmap[8](markdown ⇄ 導圖)。

6.8 為什麼是思維導圖,不是別的圖

值得停下來回答一個前面跳過的問題:意圖介面為什麼非得是思維導圖?別的圖不行嗎?逐一比過,答案就清楚了。

UML 與類圖那種工程圖太精確、太形式——它要求你把型別、介面、關係畫到能直接生成程式碼的程度,於是畫圖和寫程式一樣累,這正是模型驅動工程沒普及的原因[16]。流程圖擅長表達時序與控制流,適合描述一個過程怎麼跑,卻不擅長表達架構那種「整體—部件」的層次。ER 圖鎖在資料與結構層,太低階,離「意圖」太遠。另一端,自由白板(如手繪式的 Excalidraw、tldraw 塗鴉)夠自由、人愛畫,但太無結構——AI 很難穩定地把一團自由塗鴉解析成一份可編譯的規格。

思維導圖剛好落在中間那個甜蜜點。它天生就以「中心 → 分支」的方式編碼層次,這既對應架構的整體—部件結構,也順著 §1 講的空間化認知;它鬆到人真的願意畫(不像 UML),又有足夠的結構(樹加跨節點連線)去承載 SMS/TMS 與依賴(不像自由白板那樣無從解析)。換句話說,思維導圖正好坐在 §7 那條核心張力——「鬆到人願意畫、結構到 AI 能編譯」——的最佳位置上。這不是隨意的偏好,是被那條張力選出來的:在所有常見的圖裡,思維導圖是最能同時讓人畫得動、又讓 AI 讀得懂的那一種。

7. 設計原則

把作者透視器一文的幾條原則[1],延伸到這個雙向迴圈,得到五條設計守則。

非侵入。 反向工具直接分析公開的 repo 資訊,不要求專案方做任何改動;正向工具不把人鎖進專有格式——導圖的文字 IR 是開放、可版控的,人隨時能把它帶走。

漸進展開。 不是生成一張塞滿所有東西的大圖,而是先給全景(幾個主要模組),點一下展開內部,再點一下深入檔案。這順著 §1 的認知限制——人先把握整體、再深入細節。

雙向連結。 圖上每個節點超連結回對應的程式碼;整張導圖與 repo 來回同步。看圖理解、點圖跳碼、改碼回灌,無縫切換視圖與實作。

人畫得動,且 AI 讀得懂。 這是本設計的核心張力,也是它和古典模型驅動工程的分野。MDE 失敗的地方在於模型要畫到像寫程式一樣精確,於是沒人想用;但若導圖鬆散到沒有結構,AI 又無從編譯。所以 IR 必須卡在中間——鬆到人願意畫,結構到 AI 能編譯。怎麼拿捏這條線,是整個專案最難、也最值得做的工程判斷。

圖即真理,不是插畫。 導圖必須可版控、可 diff、可與 repo 來回同步,而不是被生成一次就丟的圖片。一張會過時的圖,和傳統架構文件沒兩樣;一張會對帳的活圖,才配當「意圖」。

8. 風險與邊界

一份誠實的白皮書要標出自己會在哪裡撞牆。這個構想至少有六處需要正視。

精度的兩難。 §7 已點出核心張力:導圖鬆到人願意畫、又要結構到 AI 能編譯,這條線不好拿捏。偏鬆,AI 編出來的東西和你想的有落差;偏緊,它就退化成 UML,沒人想畫——這正是模型驅動工程二十年沒普及的原因[16]。這個專案成敗,很大程度押在這條線拿捏得好不好,而它沒有現成答案,只能在做的過程中不斷校準。

漂移與同步是硬問題。 「圖與 repo 雙向同步」說起來漂亮,做起來難。程式碼一直在變,要讓導圖持續、自動地反映變化而不過時,需要可靠的反向解析與差異對帳;規格驅動開發的工具至今也還在和「規格與程式碼悄悄分家」搏鬥[14][15]。漂移偵測是這個迴圈的紀律核心,也是它最可能先壞掉的地方。

AI 填碼的可信度。 正向管線最後一步是「AI 依規格填實作」,而這一步繼承了 vibe coding 的全部風險:產出看似對、跑得動,卻可能藏著沒被發現的錯[13]。把導圖當單一真理、讓每段程式碼可追溯回圖上的某個節點,是為了讓錯誤可被定位;但它不能消滅錯誤,只能讓對齊變容易。這個工具降低的是對齊成本,不是審查責任。

有些意圖,圖畫不出來。 思維導圖擅長表達層次與關係,但不是所有意圖都是層次與關係。時序邏輯、效能權衡、邊界條件、那些住在「為什麼這樣而不那樣」裡的細微取捨,未必塞得進節點與邊。導圖是意圖的一個強投影,不是意圖的全部;硬要把所有東西畫進去,會把它壓垮成另一種難讀的文件。知道它能表達什麼、不能表達什麼,才用得好它。

讀者多半是 AI——而這反而是設計線索。 作者坦言,個人學術實驗站現在來看的人很少,多半是 AI 爬蟲。但這件事換個角度看是設計輸入:如果這套東西未來的主要讀者(無論是讀這份白皮書、還是讀那張意圖導圖的)有很大比例是 AI,那麼「AI 讀得懂」就不是次要需求,而是第一需求。導圖的文字 IR 該為機器可解析而設計,文件該為被檢索與被理解而寫。把 AI 當一等讀者,不是退而求其次,是順應這個工具真正的使用情境。

鎖定風險。 任何「意圖編譯器」都有把人鎖進專有格式的危險。對治的方式只有一個:讓導圖的文字 IR 開放、可版控、可被任何工具讀寫,讓人隨時能把意圖帶走。這條原則(§7「非侵入」)不是錦上添花,是這類工具能不能被信任的底線。

評估的困難。 還有一個繞不開的問題:你怎麼衡量編譯出來的專案,到底有沒有符合意圖?麻煩在於,意圖本身就是那張導圖——導圖即規格,於是「符不符合」有點循環:除非有導圖之外的驗收標準(測試、實際跑起來的行為、使用者的回饋),否則你只是在確認「程式碼符合圖」,而不是「圖符合你真正要的」。這和規格驅動開發面對的驗證難題同源[14][15]:規格再清楚,也不保證規格本身是對的。所以這個迴圈需要一個圖之外的錨——可執行的驗收——否則它會在自己的閉環裡自我滿足。

標出這七處,不是勸退,是定位:這是一個值得做、但難做對的東西,而它最難的部分(精度的線、漂移的同步)恰恰也是最有價值的部分。

9. 應用情境

把抽象落成幾個具體的人(或 AI)會怎麼用它的場景,呼應作者透視器一文裡的鏈條[1]。

情境一:看懂一個陌生專案。 你想參與一個開源專案,但它有上百個檔案。你打開它的反向視圖(fork 自 GitDiagram[2]),五分鐘看懂整體架構:哪些是核心、哪些可選、依賴怎麼流。這是今天就能用的那一半。

情境二:從一張圖起一個新專案。 你有個構想。你不先寫程式,而是畫一張思維導圖:中心是專案目的,主幹是幾個核心模組(標成 SMS),外圍是可選功能(標成 TMS),節點之間連上依賴。畫完,按「編譯」——它轉成 mssp.config、由 FPL 生成資料夾骨架[1],AI 把實作填進去。你從一張圖,得到一個專案骨架。

情境三:AI 接手維護。 半年後,你或別人要改這個專案。AI 代理把那張意圖導圖讀成單一真理,知道每個模組該幹嘛、彼此怎麼依賴,於是它的修改不是盲改,而是對著意圖改——每段變更都可追溯回圖上的某個節點[14][15]。

情境四:架構漂移告警。 專案演化了一陣子,程式碼可能悄悄偏離了當初的意圖。反向解析把當前 repo 轉回一張導圖,和意圖導圖對 diff;凡分岔處,系統告警:這裡的程式碼長得和你畫的不一樣了——是程式碼跑偏,還是你的意圖該更新?讓人來對帳。這把「架構文件畫完即過時」這個老問題,變成一個可被持續偵測的訊號。

情境五:跨專案的架構模式庫。 當夠多專案的意圖導圖累積起來,你就有了一座架構模式庫[1]。你可以搜:「我想做一個 CLI 工具,有什麼架構推薦?」可以比:「同樣是 Web 框架,這個和那個的架構差在哪?」可以學:成功的專案通常怎麼劃分核心與可選、怎麼佈線依賴。每一張意圖導圖,既是一個專案的起點,也是一塊可被後人複用的模式;個別的圖匯成庫,庫又餵養新的圖——生態正向循環[1]。這一層要等前四個情境跑順、導圖累積到一定量才長得出來,但它是這套東西規模化之後最有價值的回報:讓「站在巨人的肩膀上」從一句口號,變成一個可搜尋、可複用的模式庫。把這件事再推一步,模式庫本身也能被反向解析、被 AI 讀懂——於是「別人怎麼蓋的」這個知識,不再鎖在各自的 repo 裡,而成為人與 AI 都查得到、用得上的共同資產。

五個情境共用同一張導圖。它不是五個工具,是一張意圖底圖在一個迴圈裡的五種讀法——這正是「可視即意圖」要的:一張人與 AI 共讀的圖,貫穿看懂、生成、維護、糾偏。

10. 與既有工作的關係與致謝

按本文開頭的立場,這一節把歸功講清楚。

反向的「程式碼→架構圖」,GitDiagram(ahmedkhaleel2004)做得又早又好[2],它和作者 2025 年初的透視器構想[1]高度重合。我尊重也感謝這個專案;依本文立場,這一半該撿來改,而不是重做。正向的零件,分別感謝:tldraw 團隊的 make-real[3]、SDK 的 Agent 與 Workflow[4]、以及 MCP App[5],把「畫→碼」與「AI 讀寫畫布」做了出來;simple-mind-map(wanglin2)[6]、mind-elixir[7]、markmap[8] 提供了可靠的開源導圖底座;Whimsical[9]、GitMind[10]、Jeda.ai[11] 推進了 AI 導圖;GitHub Spec Kit[14] 與 AWS Kiro[15] 把「規格作為單一真理」這個關鍵範式立了起來,而這正是本文視覺版構想的文字版近親。更古老的模型驅動工程[16],則早已證明「圖→碼」在原理上可行。

那麼,在這些之上,這份白皮書添了什麼?三件事:其一,把散落的零件焊成一個迴圈——把反向透視、正向編譯、AI 讀圖、漂移回灌,串成一張導圖貫穿的環。其二,用母集子集(MSSP)給導圖一個架構語義[1]——讓圖不只是主題樹,而是 SMS/TMS、依賴、穩定性都編碼在內的、人畫得動的架構規格。其三,把「規格作為單一真理」從文字推到視覺——主張思維導圖是比散文更貼合人類直覺、也能被 AI 讀取的意圖載體。

如果這三件事,別人也已經做了而我沒查到,那麼這份文件就退化成一份「我也想到了」的記錄——而那也完全沒關係。我把它寫下來、放上去,是為了讓接手的人省一段路,不是為了爭一個名分。

11. 連回更大的線

這個構想不是孤立的,它接在作者既有的幾條線上,這裡輕點,不展開。

它是「視覺意圖」這條線(VIML,視覺意圖標記語言)的具體產品化——把「視覺即意圖」從一個語言構想,落成一個導圖編譯器加一個 repo↔圖透視器。它也接在作者的「切口」那條線上:那張思維導圖是一個場,把它編譯成專案是縫(把局部意圖縫成一個整體系統),而 repo 與導圖的來回同步,正是「切—縫」的一個工程實例——打散(把系統解析回局部節點)與重建(把節點編譯回系統)的雙向操作。從這個角度,意圖導圖也可以看成一個因果場:節點是元素,依賴邊是因果/依賴關係,而「能不能從圖乾淨地編譯出可運行的系統」,測的是這張意圖圖本身有多自洽、多可實現。

往最大處看,它接在「意圖即創造」這條總線上[1]:人用自然的方式表達意圖 → 經對話與工具挖掘、結晶成一份結構化規格 → 編譯成專案骨架 → AI 填入實作 → 推上 GitHub → 別人(或 AI)透視、學習、再複用 → 生態正向循環。在這條鏈裡,本文的思維導圖編譯器補的是最前面那一段——把「人表達意圖」從打字描述,換成畫一張人與 AI 共讀的圖,讓意圖在進入編譯之前,就已經是可見、可版控、可被機器讀取的。把入口從文字換成圖,看似只是換了個介面,但它改變的是整條鏈的起點品質:意圖越清晰、越結構化地被表達出來,後面每一段的對齊成本就越低。這也是為什麼這個看似小的工具,值得放進那張更大的網裡認真做。

這些連結這裡只記一筆,留待各自的正式論文展開。點出它們,是要說明:這個白皮書不是一時的工具構想,它是一張更大的網裡的一個節點。

12. 路線圖

把它落成可以一步步做的階段。誠實地說,這是一份設計與記錄,不是一個進行中的工程進度;階段是給接手的人的順序建議。

第零階段,反向先撿現成:fork GitDiagram[2],跑通「repo → 架構圖」,並把「回灌成 MSSP-Lang/導圖」那段接上去——這是今天就能動手、且站在別人肩膀上的一步。

第一階段,立導圖底座:在 tldraw SDK[4] 或 simple-mind-map[6]/mind-elixir[7] 上,做出帶 MSSP 語義(SMS/TMS、依賴、穩定性)的思維導圖編輯器,並讓它有一份開放的文字 IR(可參考 markmap[8] 的 markdown ⇄ 導圖)。

第二階段,通正向編譯:把導圖的文字 IR 接成 mssp.config,再接 FPL 生成專案骨架[1],打通「圖 → 專案骨架」,先不求 AI 填碼完美,求骨架正確。

第三階段,讓 AI 讀圖:循 tldraw MCP[5]/Whimsical MCP[9] 的模式,讓編碼代理把意圖導圖讀成單一真理去填碼與維護,對齊規格驅動開發的做法[14][15]。

第四階段,閉環與漂移:接上反向回灌,做漂移偵測——讓意圖導圖與真實 repo 持續對帳。這一階段最難,也是「可視即意圖」真正成立的標誌:那張圖,從此是活的、是真理、是人與 AI 共讀的同一份意圖。

每一階段都可以獨立交付、獨立有用;不必等到第四階段才見價值。這也是這份路線圖的用意:讓接手的人,從任何一階段都能開始。

13. 結論

GitHub 是全球最大的程式碼倉庫,但它少了一層:意圖的顯現層。一個專案的架構與設計意圖,潛伏在目錄與程式碼裡,等著被翻譯,而我們長期缺一個翻譯器。

本文圍繞一個構想:讓一張思維導圖,成為人與 AI 共讀的意圖介面——反向把既有專案透視成圖,正向把圖編譯成專案,兩端接成一個迴圈,讓那張圖始終是唯一的意圖真理。誠實的地貌是:反向那一半,別人已經做出來、且幾乎一比一,撿來改就好;正向與迴圈那一半,零件散落各處,但沒有人焊成一個環——而那個環,就是這份文件留下的設計與記錄。

我不在乎是我先想到,還是別人先做。如果別人先做了,我尊重他們、感謝他們。我把它寫下來、放到網路上,即使現在來看的多半是 AI,至少它被記下來了——成為一個未來的人、或未來的 AI,可以撿起來接手的起點。地圖畫到了路的盡頭,而路的盡頭之外那段還沒人走的,我把它標了出來;走不走、誰去走,那是後來者的事。退一步說,這份文件最實在的價值,或許不在那個迴圈最終會不會被造出來,而在它把「現在有什麼、缺什麼、可以怎麼接」記成了一張清楚的地圖。技術會換代、工具會更名,但「意圖該被顯現」這個問題不會過時;只要問題還在,這張地圖就還有人、或還有 AI,用得上。

把隱藏的意圖顯現出來,讓看得見的圖直接就是意圖本身——這件事值得有人去做,無論那個人是誰,無論是不是我。

引用

引用為 2026 年 6 月檢索所得;開源專案演化快,連結、版本與年份請於採用前再核。

[1] Neo K.(許筌崴),〈GitHub 架構透視器:讓隱藏的架構可視化〉,一言諾科技有限公司(EveMissLab),2025 年 1 月。(作者前作) [2] GitDiagram — ahmedkhaleel2004/gitdiagram. https://github.com/ahmedkhaleel2004/gitdiagram ; https://gitdiagram.com/ [3] tldraw make-real. https://github.com/tldraw/make-real ; https://makereal.tldraw.com/ [4] tldraw SDK(Agent / Workflow / 畫布). https://github.com/tldraw/tldraw ; https://tldraw.dev/ [5] tldraw MCP App. https://tldraw.dev/blog/tldraw-mcp-app [6] simple-mind-map — wanglin2. https://github.com/wanglin2/mind-map [7] mind-elixir(框架無關的導圖核心). https://github.com/SSShooter/mind-elixir-core [8] markmap(markdown ⇄ 導圖). https://markmap.js.org/ [9] Whimsical AI Mind Maps(含 MCP). https://whimsical.com/ai/ai-mind-maps [10] GitMind. https://gitmind.com/ [11] Jeda.ai Visual AI / AI Mind Maps. https://www.jeda.ai/ [12] 自然語言 → 圖即程式碼(PlantUML / Graphviz via LLM);參 Galileo, "How Code Interpreters Generate Visuals From Natural Language". https://galileo.ai/blog/code-interpreters-visual-models [13] Vibe coding(術語,2025 年 2 月提出). https://en.wikipedia.org/wiki/Vibe_coding [14] GitHub Spec Kit(規格驅動開發開源工具,2025). https://github.com/github/spec-kit [15] AWS Kiro(agentic IDE,規格驅動,2025 年 7 月). https://kiro.dev/ [16] 模型驅動工程(MDE / MDA);Eclipse EMF、Sirius、Acceleo 一脈為代表參考。

本文為 EveMissLab 技術白皮書工作稿。立場已於開頭與 §0 標明:記錄、歸功、交棒;地貌當事實,缺口當判斷,設計當草案。