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.8 KiB
Raw Permalink Blame History

visionA Cloud — 產品需求文件PRD索引

項目 內容
產品名稱 visionA Cloud
產品代號 visionA-frontend / visionA-backend
文件版本 v0.1Phase 0 雛形規劃)
最後更新 2026-04-21
狀態 三方聯合討論中PM / Design / Architect 平行)
主要負責人 PM Agent
相關專案 local-tool/(離線版,不動)、edge-ai-platformPOC要轉正

文件結構

本 PRD 採用模組化結構PRD.md 為索引檔,各章節拆成獨立子檔案。

.autoflow/02-prd/
├── PRD.md                          ← 本檔(索引 + 各章節一句話摘要)
├── strategy.md                     ← 第 1 章:產品策略
├── product-positioning.md          ← 第 2 章產品定位visionA Cloud vs local-tool vs POC
├── market-analysis.md              ← 第 3 章:市場分析
├── user-research.md                ← 第 4 章用戶研究Persona、旅程
├── user-stories.md                 ← 第 5 章User StoriesRICE 排序)
├── features/                       ← 第 6 章:功能規格(按功能拆分)
│   ├── feature-device-management.md
│   ├── feature-model-management.md
│   ├── feature-inference.md
│   ├── feature-pairing.md          ← 新增Pairing 流程
│   ├── feature-cluster-inference.md
│   ├── feature-dashboard.md
│   ├── feature-workspace.md
│   ├── feature-auth.md             ← 雛形 TODO
│   ├── feature-converter-integration.md  ← 轉檔整合 TODO
│   └── feature-billing.md          ← 未來 TODO
├── nonfunctional.md                ← 第 7 章:非功能性需求
├── interface-contracts.md          ← 第 8 章:介面契約(重要,給 converter 團隊等)
├── success-metrics.md              ← 第 9 章:成功指標
├── roadmap.md                      ← 第 10 章開發範圍與階段Phase 0 / 1 / 2
└── risks.md                        ← 第 11 章:風險與相依

章節摘要

1. 產品策略

visionA Cloud 是把 edge-ai-platform POC 升格的正式雲端產品,定位為「Kneron 邊緣 AI 裝置的雲端操作平台」,讓開發者透過瀏覽器遠端操作自己筆電 / 現場機上的 Kneron 裝置KL520 / KL720支援單裝置與多裝置叢集推論。與 local-tool離線版共享相同 UI 與核心功能,差別在前端連的是雲端 API而非 localhost。

核心價值主張:「不用打開筆電,也能管你的 Kneron 裝置。」

目標受眾Kneron FAE內部、Kneron 生態系開發者(外部)、做 PoC 的系統整合商。

2. 產品定位

釐清 visionA Cloud 在 Innovedus 產品線中的位置:

  • local-tool(離線版):現場 demo、網路鎖死的客戶場景 → 完全不動
  • visionA Cloud(本專案):遠端協作、多人共用、長駐叢集 → Phase 0 雛形
  • edge-ai-platformPOC已完成歷史使命逐步 deprecate

兩種模式用「同一套前端」加上不同 API base URL 決定,不做模式切換 UI。

3. 市場分析

邊緣 AI 開發工具市場簡要分析,競品如 NVIDIA Triton Inference Server、Edge Impulse Studio、SenseCraft AI、AWS IoT Greengrass。差異化聚焦「Kneron 專用 + 雲端遠端存取 + 低延遲 tunnel + 叢集推論」的組合,這是現有競品都沒有單一提供的。

4. 用戶研究

主要 Persona

  1. 阿哲 — Kneron 客戶 FAE:常出差做 demo需要遠端查看現場客戶機台的推論狀態。
  2. Sarah — SI 系統整合商:在多個客戶端佈署 Kneron 裝置,需要統一介面管理。
  3. Mike — AI 應用開發者:寫應用 A/B test要叢集跑多裝置比對效能。

用戶旅程涵蓋「認知 → 註冊 → Pairing → 首次推論 → 日常使用」。

5. User StoriesRICE 排序)

所有 User Story 按 RICE 評分排序P0雛形必做、P1Phase 1、P2未來。重點 stories

  • 作為開發者,我要在瀏覽器註冊登入,看到我名下所有裝置。
  • 作為開發者,我要把我筆電上的 local agent 配對到 visionA Cloud 帳號。
  • 作為 FAE,我要選一個遠端裝置 + 模型 + 來源,按「開始」就看到即時推論結果。
  • 作為 SI,我要把多個裝置組叢集,做加權 round-robin 推論。

6. 功能規格

按功能拆成獨立檔,每個功能含描述、使用者行為、驗收條件:

功能 優先級 檔案 狀態
裝置管理 P0 feature-device-management.md 搬自 local-tool走 remote-proxy
模型管理 P0 feature-model-management.md 7 預設 + 上傳,走 S3 介面
推論操作 P0 feature-inference.md Camera / Image / Video / Batch
Pairing 流程 P0 feature-pairing.md 新增,取代 POC 的 MAC 寫死
工作區 P0 feature-workspace.md 裝置 → 模型 → 來源
叢集推論 P1 feature-cluster-inference.md 從 POC 搬,加權 RR
儀表板 P1 feature-dashboard.md 搬自 local-tool
會員系統 P2TODO feature-auth.md 雛形只定介面
轉檔整合 P0Phase 0.8 MVP feature-converter-integration.md upload→轉檔→半自動處理converter / FAA / MC 已就緒
Billing P2TODO feature-billing.md 未來

7. 非功能性需求

效能推論延遲、API RT、tunnel throughput、安全pairing token 生命週期、傳輸加密、隔離、可擴展性Session 狀態管理、無狀態 API Server、可用性降級策略、離線覆蓋、可觀測性metrics / log

8. 介面契約Interface Contracts

本章節特別重要,因為 Phase 0 有很多 TODO介面契約是跨團隊合作的合約

  • AuthProvider 介面(給未來會員系統填血)
  • kneron_model_converter API 契約visionA-backend 作為 client反向定義
  • ObjectStorage 介面S3-compatible雛形用 local filesystem 實作)
  • SessionStore 介面(雛形 in-memory未來 Redis
  • BillingProvider 介面(未來)

9. 成功指標

Phase 0 雛形指標跑得動、Pairing 成功率、推論端到端延遲、Phase 1 MVP 指標WAU、Pairing conversion、首次推論時間、長期北極星指標每週推論次數 per user

10. 開發範圍與階段

  • Phase 0本次雛形建骨架、跑得動、介面清楚、Auth/DB/Storage 用 stub
  • Phase 1(未來 1-2 季):接真 Auth、接真 DB、接真 Storage
  • Phase 2(未來 2-4 季轉檔整合、Billing、多區域部署

11. 風險與相依

  • 和 kneron_model_converter 團隊的協作節奏
  • 不能改壞 local-tool 的風險
  • tunnel 在企業網路 NAT / Proxy / 防火牆的穿透風險
  • Pairing token 洩漏的安全風險

使用說明(給其他 Agent

Design Agent、Architect Agent

  • 需要全貌時讀本索引檔
  • 需要細節時讀對應子檔案
  • 不要所有檔案一次讀,會爆 context

Orchestrator

  • 追蹤 TODO 清單時讀 roadmap.mdinterface-contracts.md
  • 追蹤 Phase 0 驗收時讀各 feature-*.md 的「驗收條件」段落