jim800121chen fb7da5d180 chore(autoflow): migrate .autoflow/ 共享層文件至 docs/autoflow/

依 autoflow-agent workspace v2 設計把 PRD / 設計 / 架構 / 交付類
共享文件從個人層 .autoflow/（ignored）搬到 docs/autoflow/（進 git），
讓團隊可共享產品與架構文件，個人層只留 progress / review / testing 等
per-branch 筆記。

- 02-prd/        21 個檔（PRD、features、market-analysis 等）
- 03-design/     18 個檔（design-spec、wireframes、flows 等）
- 04-architecture/ 31 個檔（TDD、design-doc、ADR×14、API 規格等）
- 07-delivery/   3 個檔（project-summary、phase-0.6-handover、stage-deployment-setup）

合計 73 檔。原檔已從 .autoflow/ 移除（migration 工具執行 git mv，
但因 .autoflow/ 在 .gitignore 中、git 將此操作視為新增、無 rename history）。

2026-05-04 16:55:55 +08:00

7.5 KiB

Raw Blame History

2. 產品定位 — visionA Cloud vs local-tool vs edge-ai-platform POC

父文件：PRD.md

2.1 三個產品的關係圖

┌─────────────────────────────────────────────────────────────┐
│                   Innovedus 產品線關係                       │
│                                                              │
│   edge-ai-platform (POC) ─── Deprecate ────> 2026 Q3 封存   │
│           │                                                  │
│           │ 把核心模組搬過來（relay / tunnel / cluster）      │
│           ▼                                                  │
│   visionA Cloud（本專案，Phase 0 雛形中）                    │
│           │                                                  │
│           │                                                  │
│           │  共用同一套前端 UI（不同 API base URL）           │
│           │                                                  │
│           ▼                                                  │
│   local-tool（離線版，繼續維護，不動）                        │
│                                                              │
└─────────────────────────────────────────────────────────────┘

2.2 三者的定位比較

維度	local-tool	edge-ai-platform POC	visionA Cloud
產品形態	桌面 App（Wails 打包）	桌面 App + Relay Server	Web SaaS
網路需求	完全離線	有/無網路皆可	必須連網
目標場景	現場 demo、鎖網環境	POC 實驗	遠端操作、多裝置管理
使用者數	單人（本機）	單人 / POC 小隊	多用戶、多租戶
Auth	無	無（token hardcode）	有（雛形 stub）
模型儲存	本機 filesystem	本機 filesystem	S3-compat 介面
叢集推論	❌ 不支援	✅ 有（POC 版）	✅ 有（產品化）
Tunnel 遠端	❌ 不支援	✅ 有（token = MAC hash）	✅ 有（Pairing Token）
維護策略	持續維護、不變動	停止功能開發、2026 Q3 封存	主力產品，長期投入

2.3 核心原則：兩種模式，同一套前端

使用者不需要選「模式」。 前端程式碼只有一份，差別在：

// local-tool: 前端跑在 Wails WebView，API base URL 是 localhost
const API_BASE = "http://127.0.0.1:3721"

// visionA Cloud: 前端跑在瀏覽器，API base URL 是雲端
const API_BASE = "https://api.visiona.cloud"

實作上：

visionA-frontend 編譯成兩個產物：
- build/local/ → 餵給 local-tool 的 Wails embed（API_BASE=localhost）
- build/cloud/ → 部署到 CDN / 雲端 hosting（API_BASE=api.visiona.cloud）
兩者共用 95% 的元件、頁面、store。只有：
- API base URL 不同
- Auth 相關頁面（登入 / 註冊 / Pairing）只在雲端版出現
- local-tool 特有的 Wails 控制台事件只在離線版處理（透過 feature flag / build flag）

為什麼這樣做

不用維護兩份 UI：改一次 bug 兩邊都好
local-tool 不被動到：Phase 0 階段 local-tool 的前端原始碼不動，等 Phase 1 再評估是否把 visionA-frontend 反向 sync 回 local-tool
使用者體驗一致：用過 local-tool 的人轉到 cloud 不用重學

什麼情況下共享程式碼會破功

local-tool 的 WebSocket URL 是 ws://127.0.0.1:3721/ws/...，cloud 是 wss://api.visiona.cloud/ws/... — 必須抽到 config
local-tool 沒有 Auth，cloud 有 Auth — Auth 相關元件用 feature flag 隱藏
local-tool 顯示 ServerStatusDashboard（Wails 控制台），cloud 不該顯示 — 用 feature flag

Design Agent 需留意：設計規格需要標注哪些元件「只在 cloud 顯示」、哪些「只在 local 顯示」。

2.4 使用情境對照

情境 A：FAE 阿哲做客戶 demo

步驟	傳統做法（local-tool）	visionA Cloud 做法
準備	帶筆電 + Kneron 裝置到客戶現場	客戶現場先寄一台筆電 + 裝置過去（或客戶自備），裝 local agent 並 pairing
Demo 中	筆電螢幕分享給客戶	阿哲自己筆電開 visionA Cloud，畫面分享給客戶（或客戶自己用瀏覽器打開）
Demo 後	收回筆電	裝置留在客戶那，阿哲之後繼續用 cloud 管理

情境 B：SI Sarah 管多個客戶現場

步驟	傳統做法	visionA Cloud 做法
佈署	每個客戶一台筆電跑 local-tool，Sarah 要飛去每家	每個客戶佈署一台 local agent + pairing，Sarah 在辦公室集中管理
監控	打電話問客戶「現在裝置狀態？」	打開儀表板看所有裝置即時狀態
叢集	做不到	把多客戶的裝置組叢集，做加權 RR

情境 C：開發者 Mike 做模型 A/B Test

步驟	傳統做法	visionA Cloud 做法
對比	手動切換模型一個一個跑	叢集推論，同時在 3 台裝置跑不同模型，一個畫面看結果
轉檔	跑去 kneron_model_converter 網站手動轉	從 visionA Cloud 點「轉檔」，後端打 converter API

2.5 產品邊界（做什麼、不做什麼）

Phase 0 做：

✅ 裝置管理（遠端）
✅ 模型管理（上傳、瀏覽）
✅ 推論操作（Camera / Image / Video / Batch）
✅ Pairing 流程
✅ 基本儀表板
✅ 會員系統介面（stub，雛形不接真的 auth）
✅ 叢集推論（從 POC 搬）
✅ 轉檔整合的 API 契約（等 converter 團隊實作）

Phase 0 不做：

❌ 模型訓練（那是 Edge Impulse / converter 的事）
❌ 真實 Auth 系統（JWT、OAuth、2FA 等）— 留介面，用 stub
❌ 真實資料庫接入 — 用 in-memory
❌ 真實 S3 / MinIO — 用 local filesystem 實作 ObjectStorage 介面
❌ Billing、使用量計費
❌ Multi-region / HA 部署
❌ 真實 Converter 整合（等 API 建好再接）
❌ Observability（Prometheus / Grafana / Tracing）
❌ Mobile App

永遠不做：

❌ 取代 local-tool — local-tool 的離線場景是真實需求，會一直存在
❌ 模型訓練功能 — 超出產品邊界
❌ 非 Kneron 硬體支援 — 違反產品定位

2.6 對 local-tool 的影響（必須控制）

visionA Cloud 開發過程中，local-tool 必須保持 0 regression。

項目	處理方式
local-tool 的前端程式碼	Phase 0 完全不動
local-tool 的後端程式碼	Phase 0 完全不動
local-tool 的 Go module (`visiona-local`)	和 visionA-backend 的 module (`visiona-backend` 暫定) 完全獨立
共用程式碼	Phase 0 不共用，各自維護。Phase 1 再評估是否抽共用 pkg
local-tool 測試	繼續在 CI 跑，不能因為新專案而停擺

未來（Phase 1+）可能的整合方向（不在本 PRD 範圍）：

讓 local-tool 同時具備「pairing 上雲」的功能 → 變成同時是離線工具 + cloud agent
前端程式碼抽成 monorepo 共用 package

連結

上一章：產品策略
下一章：市場分析
跳回：PRD 索引

7.5 KiB Raw Blame History Unescape Escape