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）。
7.8 KiB
visionA Cloud — 產品需求文件（PRD）索引
| 項目 | 內容 |
|---|---|
| 產品名稱 | visionA Cloud |
| 產品代號 | visionA-frontend / visionA-backend |
| 文件版本 | v0.1（Phase 0 雛形規劃） |
| 最後更新 | 2026-04-21 |
| 狀態 | 三方聯合討論中（PM / Design / Architect 平行） |
| 主要負責人 | PM Agent |
| 相關專案 | local-tool/（離線版，不動）、edge-ai-platform（POC，要轉正） |
文件結構
本 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 Stories（RICE 排序）
├── 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-platform（POC）：已完成歷史使命，逐步 deprecate
兩種模式用「同一套前端」加上不同 API base URL 決定，不做模式切換 UI。
3. 市場分析
邊緣 AI 開發工具市場簡要分析，競品如 NVIDIA Triton Inference Server、Edge Impulse Studio、SenseCraft AI、AWS IoT Greengrass。差異化聚焦「Kneron 專用 + 雲端遠端存取 + 低延遲 tunnel + 叢集推論」的組合，這是現有競品都沒有單一提供的。
4. 用戶研究
主要 Persona：
- 阿哲 — Kneron 客戶 FAE：常出差做 demo，需要遠端查看現場客戶機台的推論狀態。
- Sarah — SI 系統整合商：在多個客戶端佈署 Kneron 裝置，需要統一介面管理。
- Mike — AI 應用開發者：寫應用 A/B test，要叢集跑多裝置比對效能。
用戶旅程涵蓋「認知 → 註冊 → Pairing → 首次推論 → 日常使用」。
5. User Stories（RICE 排序）
所有 User Story 按 RICE 評分排序，P0（雛形必做）、P1（Phase 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 |
| 會員系統 | P2（TODO） | feature-auth.md | 雛形只定介面 |
| 轉檔整合 | P0（Phase 0.8 MVP） | feature-converter-integration.md | upload→轉檔→半自動處理；converter / FAA / MC 已就緒 |
| Billing | P2（TODO） | 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.md和interface-contracts.md - 追蹤 Phase 0 驗收時讀各
feature-*.md的「驗收條件」段落