visionA/docs/autoflow/02-prd/strategy.md

1. 產品策略 — visionA Cloud

父文件：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 後才開始埋點追蹤。

---

連結

• 下一章：產品定位
• 或跳回：PRD 索引