Frame0、HTML、ASCII —— 線框的三種畫法

2026-05-23 · 6 min read

這兩天在跟 Claude 討論一個 GPS app 的設計，講到「接受半徑」應該設多少。20m？50m？100m？光講數字不夠直覺，想畫個圖比較看看。

前兩天才剛量過 Frame0 對上 ASCII 的成本，那是 93 個形狀的複雜 UI 線框；這次的場景簡單得多——一個十字路口加三個同心圓——但我想多比較一個選項：HTML+SVG。

問題來了：在跟 AI 對話的情境下，要怎麼畫這個圖？

                       100 m
                  .------+------.
              .---'             '---.
            .'        50 m           '.
          .'      .----+----.          '.
         /      .'   20 m    '.          \
        /      /   .---+---.   \          \
       |      |   |        |    |          |
  -----+------+---+--------+----+----------+-----
       |      |   |        |    |          |
        \      \   '---+---'   /          /
         \      '.            .'         /
          '.      '----+----'          .'
            '.                       .'
              '---.             .---'
                  '------+------'

三個選項

1. Frame0：透過 MCP 給 AI 畫圖能力。有形狀庫、可以匯出 PNG，使用者可以在 Frame0 app 裡繼續拖動編輯。
2. HTML + SVG：寫一段網頁原始碼，瀏覽器打開就看到。
3. ASCII：純文字，直接寫在訊息裡。

三個都能畫出「一個十字路口加三個同心圓」這個場景。問題是——它們的成本差多少？

量出來看

我請 AI 畫同一個畫面：兩條交叉的路、三個同心圓（20m、50m、100m）、加上標籤。

HTML+SVG 版（瀏覽器打開）：

Frame0 版（匯出 PNG）：

ASCII 版在上面已經看過了。三個版本生出來之後量字數，而且要把寫出去跟回傳的資料都算進來——Frame0 每次 create_* 呼叫都會把完整的 shape descriptor 回傳到 context，這筆不能漏掉。

ASCII 最便宜這沒什麼意外。讓我比較訝異的是 Frame0 跟 HTML 的差距比表面上還大——Frame0 不只 outbound 重，每次 create_* 回來的 shape descriptor 又是一份完整資料，所以一來一回幾乎是 outbound 的兩倍。HTML 寫完就只剩一個「檔案已寫入」的確認，幾乎沒有 inbound 成本。

還有一筆沒列進表格的隱形支出：Frame0 的 export_page_as_image 會把 PNG 直接送進 AI 的 context，大概等同 600–1,500 個 image token。HTML 沒有這個問題——使用者自己在瀏覽器打開，圖片從來沒進過 AI 的 context。

還有讀回來的成本

寫出去只是一面，AI 之後如果需要再讀一次這個畫面，又是另一筆。實際量過 get_page 的回傳結果：

這比我原本預期還好——Frame0 的 read-back 只比輸入大一點點（多了 id、parent ref、計算後的幾何），不像我擔心的會膨脹一倍。

但別忘了：read-back 本身的字數雖然不可怕，為了能 read-back，前面那筆 4,756 字的 round-trip 已經花掉了。Frame0 的成本是在創建時付清，不是在讀取時延後。

但只看成本不夠

便宜不代表就是最好的選擇。三個方式各有強項：

ASCII 在訊息裡看起來最直接。HTML 的好處是 diffable，瀏覽器打開就看得到，可以塞進靜態網站；SVG 的座標系統跟 Frame0 共通，要轉回去也不痛苦。Frame0 真正回本的場景是形狀數量夠多——當你要畫一個有手機外框、navigation bar、十幾個按鈕和 list item 的真實 UI mock 時，內建元件庫會把每個元件的 boilerplate 攤平到「整體還是比較便宜」。我估算大概要 15 個以上的形狀才會跨過這個臨界點。

三軸盤點

成本、速度、產出三條軸線一起看：

讀法：條數越多代表這條軸的程度越強——成本越高、速度越快、產出越精緻。整體規律：要省要快就吃輕產出，要精緻產出就吃貴吃慢。