# Design 第一輪分析 — visionA-local 方向變更(2026-04-14) > Design Agent · 第一輪分析筆記(非正式規格) · 2026-04-14 > 對應事件:使用者提出方向重大變更 — Wails 桌面 app 由「跑 Next.js 主 UI 的殼」**退化**為「Local Server 控制台」,主 UI 改為純瀏覽器網頁。 --- ## 摘要(3 行) - 使用者要求把 visionA-local 從「Photo Booth 型桌面 app」轉為「**Docker Desktop / Ollama 型服務控制台 + 瀏覽器網頁 UI**」雙 UI 架構:桌面殼只管「server 生命週期 + log」,瀏覽器端承擔所有業務操作。 - 推論輸入從目前的 `camera / image / video(file) / video(url)` **砍為三種**:`camera / image / video 檔案上傳`,**URL/YT-DLP 整條移除**;模型來源只剩「預置 + 使用者上傳」,不再有第三方目錄。 - 這個改動在體驗面有實質 upside(多視窗、devtools、書籤、和 localhost 生態整合),但也讓原本已完成的 splash regression 修復方向逆轉、和第三輪 Q-A「砍 tray」決策再度打架(因為沒有 tray 又沒有主視窗、server 要不要在桌面 app 關閉後繼續活)。**這幾個衝突必須在進開發前先解。** --- ## A. 變更解讀(體驗面) ### A1. 為什麼使用者想這樣 使用者沒明講動機,但以 UX 研究角度推測有幾個合理動機,**按可能性由高到低**排序: 1. **對齊 localhost 生態的心智模型** 使用者自己是 FAE / 開發者,日常工具鏈是 `docker desktop` / `ollama serve` / `jupyter notebook` / `stable-diffusion-webui`。這些工具都走「桌面端只是 server 控制器,真正操作在瀏覽器 / CLI」的雙重介面模式。把 visionA-local 做成同樣形狀,學習成本 = 0,符合「這類工具應該長這樣」的直覺。 2. **瀏覽器能力是 Wails WebView 的超集** - **多視窗**:同時開兩個 tab 對照 camera 推論 vs 影片推論 - **devtools**:F12 即用,可以看 network、console、storage - **書籤 / 分頁歷史**:跳回上次看的裝置 - **瀏覽器擴充**:screenshot、錄影、Postman 等 workflow 工具直接接上 - **瀏覽器字體 / 高 DPI / 縮放**:Wails 在 Windows 的 WebView2 某些版本字體渲染有 bug,瀏覽器沒這問題 - **分享 URL**:`http://localhost:3721/workspace/xxx` 可以貼給同事或記在筆記裡 3. **推論結果可以在不同視窗同時看** 目前 Wails 單視窗模式,使用者只能看一個 workspace。FAE 到客戶現場 demo 時常見需求:一邊跑 camera、一邊準備下一段影片 — 開兩個瀏覽器 tab 就解決了。 4. **切換到不同 OS 或遠端機時維持一致** 雖然 visionA-local 定位單機,但使用者也許會在 Linux 無頭機器上 run server,然後用 Mac 筆電瀏覽器連 LAN 過去 demo。**這個動機如果存在,就不是單純的 UX 偏好,而是產品範圍的擴張**(LAN 可訪問),要主動問清楚(見 D 節)。 5. **Server 健康度獨立可見** 目前 Wails UI 把 server 當成黑盒子,server 崩了 UI 才喊 fatal dialog。獨立 log 面板讓使用者**在事情出錯前**就看到徵兆(例如 Python sidecar 有 warning),降低 debug 門檻。 **最有說服力的論證是 1 + 5 的組合**:使用者想要的不是「瀏覽器介面」這個手段,而是「**把 visionA-local 從『桌面軟體』重新定位為『本機服務 + 網頁控制台』**」這個心智模型。這是產品層面的 re-positioning,不只是 UI 重排。 ### A2. 對使用者旅程的影響 #### 首次開啟流程(First-Run) **現況(M7 splash + Next.js)**: ``` 雙擊 app → Wails 視窗開 → splash 輪詢 GetServerStatus → server 起來 → window.location.replace 跳 Next.js 主 UI → First-Run 歡迎頁(歡迎 / 模式 / 偵測)→ Dashboard ``` **新方向**: ``` 雙擊 app → 桌面控制台視窗開 → 自動 start server → log 跑 → status: running → 使用者點「Open in browser」→ 瀏覽器開 localhost:3721 → 進 First-Run → Dashboard ``` **體驗斷裂點**: - 使用者從「雙擊 app → 看到 app」變成「雙擊 app → 看到 server 控制台(不是我要的)→ 還要再點一下」。這是**多一個步驟**。 - 對第一次用的 FAE 來說,看到「Local server: running · Open in browser」可能會愣一下 — 「我不是要裝網頁工具啊?」 - **解法**:首次啟動**自動**彈出瀏覽器(桌面控制台照樣開著在背景)。Docker Desktop 沒這麼做是因為 docker daemon 不需要瀏覽器,但 Ollama / Stable Diffusion WebUI 都會自動開。對齊後者體驗。 #### 日常使用流程 **現況**:雙擊 app → 直接操作 **新方向**:雙擊 app → 瀏覽器自動彈(或從 dock/tray 記憶上次狀態)→ 操作 - 如果使用者前一個 session 還沒關瀏覽器 tab,雙擊 app 時不該又彈一個新 tab — 應該偵測既有 tab 並 focus(技術上 `window.open` with same `target` name 就行)。 - 如果桌面控制台已經在跑、使用者雙擊 app 第二次,要 raise 既有控制台視窗(single-instance,第四輪決策有定義 `/ipc/raise` endpoint,可重用)。 #### 錯誤排除流程 **這是新架構最大的 UX 升級點。** 目前 server 崩潰時,使用者看到的是: - Wails 視窗從 Next.js UI 變回 splash - 或者彈出 fatal dialog「Server 已停止」 - 使用者要自己去 `~/Library/Application Support/visiona-local/logs/` 翻 log **新架構**: - 桌面控制台永遠看得到 log,server 崩了會有紅色行 / stack trace 直接 inline - 一鍵 Restart 按鈕就地重試 - 可以 Copy log 貼 slack 問人 - 「Open logs folder」按鈕開 Finder/Explorer 到 log 目錄 **這個價值是 A1 論證 5 的具體落地。桌面控制台不是退化,是獲得一個「自助除錯介面」。** #### 離開流程 **第四輪決策 Q7 是「B 傳統式(關閉 = 結束)」。新架構打到這個決策頭上:** - 如果桌面控制台關了 = server 停了 → 瀏覽器的網頁就 **突然變磚塊**(fetch 全 500,camera 串流斷線)。使用者會很困惑:「我只是關掉那個 log 視窗啊?為什麼我的推論頁面壞了?」 - 如果桌面控制台關了 ≠ server 停 → 又回到 tray / 背景服務心智模型,和第三輪 Q-A「砍 tray」決策衝突。 - **這是 D 節最重要的待決策問題**。 ### A3. 現有頁面搬遷工作 現有 Next.js 頁面結構: ``` frontend/src/app/ ├── layout.tsx ← 全域 layout(sidebar + header) ├── page.tsx ← Dashboard(/) ├── workspace/[deviceId] ← 推論主畫面 ├── devices/ ← 裝置列表 ├── devices/[id] ← 裝置細節 ├── models/ ← 模型列表 ├── models/[id] ← 模型細節 └── settings/ ← 設定(4 分頁) ``` **搬遷需要改動的點**: | 面向 | 現況 | 新架構需要做什麼 | 工作量 | |------|------|-----------------|--------| | **頁面結構** | Next.js pages | **完全不用動**。現有頁面直接以瀏覽器開 `http://localhost:/` 就能跑 | 0 | | **workspace 推論源 tabs** | camera / image / video,video tab 內有 file/url 雙模式 | **砍掉 video tab 內的 url 按鈕**,video tab 變成單一「upload file」。`pasteUrl` / `urlPlaceholder` / `urlHelpText` i18n keys 刪除。`source-selector.tsx` 的 `videoMode` state 和 `startFromUrl` 呼叫都刪。另外 `batch_image` sub-mode 保留(它是 image tab 的多檔上傳變體)。 | S | | **第四輪「url 推論首次 ≤ 250ms」指標** | 本來假設 url 來源也算在延遲指標內 | URL 整條砍後,這條指標只剩 camera + 本地 video file。更新 PRD 的 R4-2 註記。 | XS(文字調整) | | **模型來源** | models 頁面有預置模型 + Upload Dialog | 使用者說「除了預設的幾種只能用上傳的」→ 確認這和目前狀態一致(預置 + 上傳),**不需要改**。只是要刪掉任何「從 URL 下載模型」或「線上模型市集」的殘留(目前沒有,但要檢查) | XS | | **devices 頁面 scan/connect** | 現有已經有 `Refresh Devices` 按鈕(快捷鍵 ⌘Shift+R),也有 per-device connect | 不用改,使用者說的「scan/connect device 介面」已經存在 | 0 | | **Wails 原生呼叫** | splash 用 `GetServerStatus()` binding、fatal dialog 用 `runtime.EventsEmit` | **splash 從瀏覽器消失**,變成桌面控制台內部邏輯。Next.js 主 UI 必須**徹底不用任何 Wails JS binding**(M7-B 設計時已經做到,這點不用改)| 0 | | **Dark Mode 偵測** | 現況走 CSS `prefers-color-scheme`(第四輪決策) | 瀏覽器原生支援,不用改 | 0 | | **i18n 切換** | Settings > 一般 > 語言 | 不用改,瀏覽器 localStorage 持久化即可 | 0 | | **OS 通知** | 第四輪 R4-8:裝置連/斷 toast、server 崩潰 native notification | **toast 完全不變**(瀏覽器支援好)。**Server 崩潰的 native notification 換位置**:不再由 Wails 處理,改由**桌面控制台自己處理**(它本來就是服務管理者,由它發通知比瀏覽器更合邏輯) | S | | **Sidebar 與 Top bar** | Next.js 的 `layout.tsx` 已實作,含 sidebar navigation + user-friendly chrome | 不用改,但要考慮**要不要隱藏任何「return to desktop app」按鈕**之類的東西(目前沒有) | 0 | | **Window chrome tokens** | 第四輪 `spec/07-design-tokens.md §7.5` 有 desktop 專用 elevation / window chrome token | 這些 token 只在桌面控制台用;網頁端不用(瀏覽器 chrome 由瀏覽器繪製)。不需要刪,但桌面控制台可以沿用 | 0 | | **快捷鍵集**(⌘1-4 切換主區塊、⌘,、⌘U 等) | 現有由 Next.js 內部 keyboard handler 綁定 | **分裂為兩套**:桌面控制台只有 `⌘W(關閉=結束)/ ⌘Q`;其餘 ⌘1-4、⌘, 、⌘Shift+R、⌘U 全部留在瀏覽器端。`⌘W` 在瀏覽器是「關 tab」這是原生行為,不衝突。**但 `⌘Q` 在瀏覽器是「結束 browser」會誤殺所有 tab**,要和使用者確認怎麼處理(見 D 節) | M | **總結**:**現有 Next.js 頁面 80-90% 可以零改動直接搬**。實際修改集中在三個點: 1. 砍 workspace 的 URL 推論 UI(1 個元件 + 相關 i18n) 2. 桌面控制台是全新 app(Wails main.go 大改) 3. First-Run 自動開瀏覽器的新 hook ### A4. 砍掉 URL 推論的影響 使用者這句「推論只需包含這三種 camera/image/上傳影片」等於宣判 URL 推論死刑,影響面: **UX 面影響**: 1. **workspace 的 video tab 簡化**: - 現況:點 video tab → 看到 `[上傳檔案] [貼上連結]` 兩顆 button → 選 file → 再點 Select Video - 新方向:點 video tab → **直接就是檔案上傳區**(大 drop zone + 檔案選擇) - 這**改善**了 video tab 的體驗(少一個決策層),符合 Jakob Nielsen 的「減少選擇負擔」原則。 - 支援格式:使用者說 `avi, mpeg, mp4, 瀏覽器能吃的格式`,實際上瀏覽器 `` 就能列一批。我建議 accept list 顯式寫 `.mp4,.avi,.mpeg,.mpg,.mov,.mkv,.webm`(瀏覽器相容格式的超集),因為後端是 ffmpeg 而非 `