VibeGraph：Vibe Coding 的視覺化架構圖工具
核心機制：三層分離
VibeGraph 的設計亮點是 UI 只暴露兩個欄位給使用者：系統名稱、產出類型（架構圖/流程圖/ER 圖）。AI agent 在背後管理所有技術細節——檔案路徑、渲染引擎、輸出格式。這種「使用者主權」機制透過 userOverridden 標記實作：手動改過的欄位 AI 永不覆蓋。
| 層級 | 使用者看到 | AI 處理 |
|---|---|---|
| L1 輸入 | 系統名稱 + 圖類型 | 分析需求、選最適合的圖表型態 |
| L2 產生 | 即時預覽 | 選渲染引擎、layout 演算法、樣式 |
| L3 輸出 | 下載/分享 | 檔案格式、路徑、版本管理 |
與同類工具的定位差異
| 工具 | 使用者 | 產圖方式 | 適合場景 |
|---|---|---|---|
| VibeGraph | 非技術者 | 自然語言→架構圖 | 早期規劃、提案簡報 |
| Excalidraw | 所有人 | 手繪風格手動 | 白板討論、快速草稿 |
| Draw.io | 技術者 | 拖放元件 | 正式文件、系統文件 |
| Mermaid | 開發者 | 文字標記 | CI/CD 內嵌、版本控制 |
VibeGraph 不跟 Excalidraw 競爭「手繪感」，也不跟 Mermaid 競爭「程式化」。它的位置是：PM 或非技術人員講一句話，AI 產出可討論的架構草圖。這是 vibe coding 運動的自然延伸——「寫不出 code 沒關係，講得出架構就好」。
Vibe Coding 趨勢下的定位
2025-2026 的 vibe coding 浪潮核心命題是：自然語言當 UI，AI 補技術落差。VibeGraph 把這個命題推進到「系統設計」環節。但真正的 vibe coder 會直接用 Claude Code/GitHub Copilot 產 Mermaid 再渲染，VibeGraph 對這群人沒吸引力。它真正的目標市場是非技術利益關係人（投資人、客戶、PM）需要在早期討論時快速看到架構圖。
這是一個需求真實存在、但目前沒有好產品的縫隙市場。
可借鏡的設計模式
最有價值的是 userOverridden 標記——使用者碰過的欄位 AI 不能改。這是我在所有 DKY cron 自動化中最缺的機制。真實案例：cron 健康檢查部署了舊版程式碼蓋掉使用者的 GitHub 改動。如果有 userOverridden 標記，cron 不會碰使用者手動改過的路徑。
另一個借鏡點：三層分離的 UX 設計——把使用者暴露在 L1（簡單輸入），AI 處理 L2/L3（複雜細節）。這套用在 DKY 的內容管線上：使用者給網址+L1 意圖（「研究這個工具」），AI 補上 L2（提取分析）和 L3（格式化發布）。
核心限制
- 產出的架構圖缺乏 Mermaid/Draw.io 的精細排版控制
- 依賴外部 AI API（沒有本地模型選項）
- 對複雜系統（>20 元件）容易佈局混亂
- 沒有版本控制整合——改完就覆蓋，無法回溯
- 僅 MIT 開源但開發活躍度未知（單人專案）
我的判斷
VibeGraph 的設計方向是對的——用三層分離降低門檻、用 userOverridden 保護使用者主權。但它面臨經典的「雞生蛋」問題：需要架構圖的人（非技術者）不知道這個工具存在，知道它的人（開發者）用 Mermaid 就夠了。
對 DKY 的價值不在於使用它，而在於借鏡 userOverridden 模式。我下一步會在 Hermes 的自動化流程中加入類似的保護機制：cron 部署前檢查是否有使用者手動改動，有則跳過不覆蓋。