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）。
175 lines
7.6 KiB
Markdown
175 lines
7.6 KiB
Markdown
# 1. 產品策略 — visionA Cloud
|
||
|
||
> 父文件：[PRD.md](PRD.md)
|
||
|
||
---
|
||
|
||
## 1.1 產品願景（模擬新聞稿）
|
||
|
||
### 標題：visionA Cloud 正式推出 — 讓 Kneron 邊緣 AI 裝置「人在家中坐，推論千里來」
|
||
|
||
### 副標題：為 Kneron FAE 與生態系開發者打造的雲端操作平台，瀏覽器即能遠端管理、監控、推論自己的 Kneron 裝置
|
||
|
||
**問題背景**
|
||
|
||
Kneron KL520 / KL720 是強大的邊緣 AI 推論晶片，但開發者與 FAE 在實際使用時有三個痛點：
|
||
|
||
1. **demo 現場得帶筆電**：目前唯一穩定的開發工具是 local-tool 離線版，demo 必須把整台筆電搬去客戶那。
|
||
2. **多裝置難以集中管理**：一個 SI 客戶可能同時在不同分店佈署 5 台 Kneron，沒有統一的遠端介面。
|
||
3. **叢集推論只有 POC**：edge-ai-platform POC 展示了多裝置加權 round-robin 的潛力，但沒有正式產品化。
|
||
|
||
**visionA Cloud 的解法**
|
||
|
||
visionA Cloud 是一個雲端 SaaS。使用者在自己的筆電、工廠機台、店頭機裝上「local agent」（即現有 local-tool），透過 Pairing Token 把裝置配對到雲端帳號。之後在任何瀏覽器開啟 visionA Cloud，就能看到自己所有裝置、上傳模型、啟動推論，跟操作本機一樣流暢 — 但**人不用在裝置旁邊**。
|
||
|
||
**典型用戶體驗引述**
|
||
|
||
> 「以前去客戶做 POC，要帶一整個後背包裝筆電。現在我筆電放辦公室，裝置留在客戶現場，我在咖啡廳開瀏覽器就能跑推論給客戶看 Teams 螢幕分享。體驗完全不同。」
|
||
>
|
||
> — 阿哲，Kneron FAE
|
||
|
||
**如何開始使用**
|
||
|
||
1. 在 visionA Cloud 註冊帳號
|
||
2. 筆電上安裝 visionA local agent（即 local-tool，未來會內建 Pairing 功能）
|
||
3. 從雲端頁面取得 Pairing Token，貼進 local agent
|
||
4. 刷新雲端頁面，裝置自動出現，開始推論
|
||
|
||
### FAQ
|
||
|
||
- **Q：這跟 local-tool 有什麼不同？**
|
||
A：local-tool 是離線桌面 app，適合網路鎖死的 demo 場景；visionA Cloud 是雲端 SaaS，適合需要遠端操作、跨裝置管理的場景。**兩者共用同一套 UI 與核心功能**，使用者可以自由選擇或同時使用。
|
||
|
||
- **Q：和 Edge Impulse、SenseCraft 比？**
|
||
A：他們是「訓練模型 + 部署到裝置」的通用平台，我們是「Kneron 專用 + 雲端遠端存取」的操作平台。我們不做模型訓練，只做已訓練好的 `.nef` 模型的部署與推論操作（但有提供對接 kneron_model_converter 的介面）。
|
||
|
||
- **Q：定價如何？**
|
||
A：Phase 0 雛形階段免費內部使用。商業模式（訂閱 / 按推論次數 / freemium）在 Phase 2 規劃，Phase 0 只定介面不接金流。
|
||
|
||
- **Q：什麼時候可以用？**
|
||
A：Phase 0 雛形目標 2026 Q2 完成（架構跑得動、基本頁面可用、in-memory auth）。Phase 1 MVP 目標 2026 Q3（接真 Auth/DB/Storage）。
|
||
|
||
---
|
||
|
||
## 1.2 目標用戶
|
||
|
||
### 主要用戶群（Phase 0 / Phase 1）
|
||
|
||
1. **Kneron 內部 FAE 與 Innovedus 業務**（~50 人）
|
||
- 最熟悉 Kneron 裝置的人，常跑客戶現場
|
||
- 容忍雛形不穩，會給詳細回饋
|
||
|
||
2. **Kneron 生態系 ISV / SI 開發者**（~數百人）
|
||
- 已經在用 local-tool 或 edge-ai-platform POC 的現有用戶
|
||
- 痛點明確：多客戶多裝置要集中管理
|
||
|
||
### 次要用戶群（Phase 2）
|
||
|
||
3. **試用 Kneron 晶片的新開發者**（長尾）
|
||
- 從 visionA Cloud 這個「門面」第一次接觸 Kneron
|
||
- 對他們而言，雲端門檻比離線桌面 app 低
|
||
|
||
### 非目標用戶（明確排除）
|
||
|
||
- ❌ 想做**模型訓練**的人 — 他們應該用 Edge Impulse 或 kneron_model_converter
|
||
- ❌ 想部署**非 Kneron 硬體**的人 — 不在產品範圍
|
||
- ❌ 企業級 MLOps / 大規模 inference production — 我們不是 NVIDIA Triton 競品
|
||
|
||
---
|
||
|
||
## 1.3 核心問題與價值主張
|
||
|
||
### 問題（用戶視角）
|
||
|
||
| 問題 | 現況 |
|
||
|------|------|
|
||
| P1：Kneron 裝置必須連實體筆電才能操作 | local-tool 是桌面 app，使用者人不在時沒辦法用 |
|
||
| P2：多裝置沒有集中式管理 | 一個 FAE 手上可能有 3-5 台機台，要一台一台開 local-tool |
|
||
| P3：POC 的叢集推論沒產品化 | 加權 round-robin 很好用，但 POC 的 auth / 多租戶 / token 都沒做 |
|
||
| P4：非 Kneron 格式的模型要手動轉檔 | kneron_model_converter 目前是獨立網站，使用者體驗斷裂 |
|
||
|
||
### 價值主張
|
||
|
||
**對開發者**：用瀏覽器就能操作 Kneron 裝置，不用被綁在實體機器旁。
|
||
|
||
**對 SI / FAE**：一個帳號管所有客戶現場的裝置，一個畫面看到全貌。
|
||
|
||
**對 Kneron 生態系**：降低 Kneron 的使用門檻，讓「試用 Kneron」不用裝一堆東西。
|
||
|
||
### 為什麼是現在做
|
||
|
||
1. **local-tool 已穩定**：UI 與業務邏輯成熟，前端可以直接搬
|
||
2. **edge-ai-platform POC 驗證了核心技術**：WebSocket + yamux tunnel、叢集推論都跑得動
|
||
3. **Kneron 生態系正在成長**：需要一個「雲端門面」承接新用戶
|
||
4. **kneron_model_converter 團隊要整合**：visionA Cloud 是整合入口
|
||
|
||
---
|
||
|
||
## 1.4 OKR（Phase 0 雛形階段）
|
||
|
||
### Objective（O）：建立 visionA Cloud 的技術基座與產品框架
|
||
|
||
- **KR1**：Phase 0 雛形 2026 Q2 完成，包含以下可驗收產出
|
||
- visionA-frontend 所有 P0 頁面可打開、可操作（接 mock 或真 API）
|
||
- visionA-backend 兩個 binary（api-server + remote-proxy）可起得來
|
||
- 至少一個 local-tool 可透過 Pairing Token 連上 visionA Cloud，並跑通一次端到端推論
|
||
- **KR2**：Phase 0 內部測試，至少 5 位 Kneron FAE 完成 Pairing + 推論測試
|
||
- **KR3**：介面契約文件（interface-contracts.md）完成，與 converter 團隊對齊一次 API spec
|
||
|
||
### Objective（O）：為 Phase 1 MVP 打好基礎
|
||
|
||
- **KR1**：所有 TODO 項目（Auth / DB / Storage / Converter）有明確的「替換點」與介面定義
|
||
- **KR2**：文件完整度 — PRD / Design Spec / TDD 三方交叉審閱通過
|
||
- **KR3**：避免 local-tool 被破壞 — local-tool 的所有既有測試持續通過（0 regression）
|
||
|
||
---
|
||
|
||
## 1.5 北極星指標與指標體系
|
||
|
||
### 北極星指標（長期）
|
||
|
||
**每週活躍裝置數（Weekly Active Devices, WAD）**
|
||
|
||
定義：過去 7 天內，至少成功完成一次推論的已 pairing 裝置數。
|
||
|
||
為什麼選這個：
|
||
- 對 B2B / 開發者工具，WAU（User）容易膨脹（人來註冊就算），但 WAD（Device）代表**真正在用**
|
||
- Kneron 裝置本身是硬體投資，裝置被使用 = 用戶正在從中獲得價值
|
||
- 一個用戶多個裝置 / 多個用戶共用一個裝置都反映在這個指標
|
||
|
||
### 指標體系
|
||
|
||
```
|
||
WAD（每週活躍裝置數）
|
||
├── 驅動指標：新 Pairing 數、每週人均推論次數、裝置留存率
|
||
│ ├── 輸入指標：註冊到 Pairing 的轉換率
|
||
│ ├── 輸入指標：Pairing 後 24 小時內首次推論率
|
||
│ ├── 輸入指標：每週上傳模型數
|
||
│ └── 輸入指標：叢集建立數
|
||
└── 護欄指標（不能惡化的）：
|
||
├── 推論端到端延遲 P95 < 500ms（比 local-tool 多 ~300ms tunnel overhead）
|
||
├── Tunnel session uptime > 99%
|
||
├── API 錯誤率 < 1%
|
||
└── local-tool regression bug 數 = 0
|
||
```
|
||
|
||
### Phase 0 可追蹤的指標（簡化版）
|
||
|
||
Phase 0 雛形只追蹤最小集：
|
||
|
||
| 指標 | 目標值 | 追蹤方式 |
|
||
|------|--------|---------|
|
||
| Pairing 成功率 | > 90% | Server log |
|
||
| 端到端推論可跑 | Yes | 手動測試 |
|
||
| API Server 崩潰 | 0 次 / 週 | Log / Monitoring |
|
||
| local-tool 測試全過 | 100% | CI |
|
||
|
||
其他指標等 Phase 1 接 DB 後才開始埋點追蹤。
|
||
|
||
---
|
||
|
||
## 連結
|
||
|
||
- 下一章：[產品定位](product-positioning.md)
|
||
- 或跳回：[PRD 索引](PRD.md)
|