jim800121chen
fb7da5d180
依 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）。
168 lines
7.5 KiB
Markdown
168 lines
7.5 KiB
Markdown
# 2. 產品定位 — visionA Cloud vs local-tool vs edge-ai-platform POC
|
||
|
||
> 父文件：[PRD.md](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 核心原則：兩種模式，同一套前端
|
||
|
||
**使用者不需要選「模式」。** 前端程式碼只有一份，差別在：
|
||
|
||
```typescript
|
||
// 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）
|
||
|
||
### 為什麼這樣做
|
||
|
||
1. **不用維護兩份 UI**：改一次 bug 兩邊都好
|
||
2. **local-tool 不被動到**：Phase 0 階段 local-tool 的前端原始碼不動，等 Phase 1 再評估是否把 visionA-frontend 反向 sync 回 local-tool
|
||
3. **使用者體驗一致**：用過 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
|
||
|
||
---
|
||
|
||
## 連結
|
||
|
||
- 上一章：[產品策略](strategy.md)
|
||
- 下一章：[市場分析](market-analysis.md)
|
||
- 跳回：[PRD 索引](PRD.md)
|