Day 26｜Web UI 與用量追蹤：一眼就看出預算與流量

昨天聊了健康檢測拆成兩層、修 bug 修出新 bug 的故事。今天要聊的是使用者實際會看到的畫面：Web UI 跟用量追蹤。

Web UI 跟用量追蹤在做什麼

Web UI 包含三塊：設定管理頁面（管理 Credential 跟 Deployment，新增/編輯/檢查健康狀態）、用量儀表板（花費、錯誤率、Fallback 觸發率的彙總數字，加上一張近期花費趨勢圖）、請求明細頁面（每一筆請求的時間、model、token、花費、狀態，可以篩選查詢）。

不管是個人版還是企業版，流量管控跟 UI 呈現都是很重要的功能——大部分開發者只要牽涉到管理，就一定會在意模型預算這件事。雖然各家廠商多半都會推出自家雲端模型的統一管理頁面，但目前市場上廠商眾多，同時用到好幾家模型的情況很常見，更別說還有地端模型也需要一起被管理——這正是這個 Web UI 存在的意義：不是要取代任何一家廠商自己的管理工具，而是把散落在不同地方的用量，收進同一個看得到全貌的地方。

假資料先行的開發順序

「先用假資料把畫面撐出來，再換真資料」這個順序，是一開始就決定要這樣做的。這也是 vibe coding 的一個好處：可以先做出雛形，再邊描述邊根據情況修改；有假資料撐著，資料視覺化的效果可以直接呈現出來，要調整畫面時也容易很多。

不過這個做法也是雙面刃：後來自己問出「我現在看到的 log 是不是假資料」，發現的當下其實還好，沒有太驚訝——但這也提醒了一件事：vibe coding 雖然方便，開發者還是得時刻記得自己執行到哪一步、順序是什麼，不然很容易陷入「系統看起來動了，其實根本沒真的完成」的窘境。

小結

Web UI 這個模組的價值，不只是把資料視覺化，而是把散落在多家廠商、多個 model 的用量收進同一個地方管理。開發順序上選擇先用假資料把畫面跑順，再逐步換成真資料，是 vibe coding 下很實際的做法，但也提醒了開發者：方便歸方便，還是得清楚掌握自己開發到哪一步。

明天要聊這個系統的認證大改造——一把 key 身兼兩種責任，為什麼最後決定拆成兩套機制。

專案開源與實作參考

如果大家看到這邊對這個專案有興趣，完整程式碼都已經整理並開源在 GitHub 上：

👉 GitHub Repo