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）。
119 lines
6.7 KiB
Markdown
119 lines
6.7 KiB
Markdown
# 11. 風險與相依 — visionA Cloud
|
||
|
||
> 父文件：[PRD.md](PRD.md)
|
||
|
||
---
|
||
|
||
## 11.1 風險分析
|
||
|
||
| # | 風險 | 可能性 | 影響 | 緩解措施 | 負責人 |
|
||
|---|------|-------|------|---------|--------|
|
||
| R01 | **破壞 local-tool** — visionA Cloud 開發過程中意外改到 local-tool | 中 | 高 | Monorepo 分離目錄、local-tool 完全獨立的 Go module、CI 持續跑 local-tool 測試、code review 嚴格檢查 | Orchestrator |
|
||
| R02 | **Tunnel 在企業網路穿透失敗** — NAT / Proxy / Firewall 擋住 WebSocket | 中 | 高 | Phase 0 在至少 3 種企業網路測試、使用標準 443 port + TLS、提供 HTTP CONNECT proxy 支援（Phase 1） | Architect |
|
||
| R03 | **Pairing Token 洩漏** — token 被截獲，別人接管使用者裝置 | 低 | 高 | 強制 TLS、一次性 + 15min TTL、Phase 1 加 hash 儲存、IP 紀錄、rate limit | Architect |
|
||
| R04 | **converter 團隊延遲交付** — 我們等 converter 團隊實作 API | 高 | 中 | Phase 0 用 stub 讓前端流程能走完；轉檔整合 list 在 Phase 2（不卡 Phase 1 MVP） | Orchestrator / PM |
|
||
| R05 | **推論延遲過大** — tunnel 的 WAN RTT 導致推論體驗不如 local-tool | 中 | 中 | 前端延遲透明化、Phase 1 支援就近 region 部署、衡量後如果 P95 > 500ms 考慮降級（只給高速網路用） | Architect |
|
||
| R06 | **Scope Creep** — 雛形做著做著功能就暴增 | 高 | 中 | PRD 明確列 Phase 0 Scope、PM 嚴格守門、超過 Scope 的功能一律往 Phase 1 / 2 推 | PM |
|
||
| R07 | **in-memory state 讓雛形不能 restart** — Phase 0 的 in-memory session / auth 一 restart 就全部沒 | 高 | 低 | 這是 Phase 0 預期行為；Phase 1 換 Redis + DB 解決；使用者教育（內部 FAE 知道雛形就是這樣） | Architect |
|
||
| R08 | **資料隔離 bug** — 使用者 A 看到 B 的裝置 / 模型 | 低 | 高 | 所有 API handler 必做 ownership 檢查、Reviewer 特別關注、Phase 1 加整合測試 | Reviewer |
|
||
| R09 | **MJPEG over tunnel 效能不足** — yamux 吞吐不夠跑 camera stream | 中 | 中 | Phase 0 早期做 spike test、若不行改用 WebRTC（但複雜度高）、降低 MJPEG 解析度與 fps | Architect |
|
||
| R10 | **UI 雙模式不一致** — local-tool 和 cloud 版前端漸漸 diverge | 中 | 中 | Phase 0 先不共用程式碼；Phase 1 規劃 monorepo 共用 package、UI 測試截圖比對 | Frontend |
|
||
| R11 | **內部 FAE 缺乏動機測試雛形** — 大家都很忙 | 中 | 中 | 提前協調資源、提供簡單的測試腳本、給測試者獎勵（公開表揚）、主管背書 | PM |
|
||
| R12 | **Auth stub 不小心上線給外部** — Phase 0 安全性極弱 | 低 | 極高 | 部署環境用網段限制（只內部 IP 可連）、環境變數明確標 `DEV_MODE=true`、Banner 顯示「雛形」 | DevOps |
|
||
| R13 | **converter 團隊改 API spec** — 我們定義的 spec 對方做不出來或要改 | 高 | 低 | Spec review session、版本化（v1 / v2）、stub 先跑前端 UX 不綁死 | PM |
|
||
| R14 | **Kneron USB 驅動在 local agent 跑不穩** — agent 端的 Kneron SDK 掛掉 | 中 | 中 | 這是 local-tool 既有風險，不新增；agent 端加健康檢查 + 自動重啟 | Local-tool team |
|
||
| R15 | **Legal / 合規未處理** — Phase 1 對外開放但沒有 Terms / Privacy | 中 | 高 | Phase 1 前 1 個月開始準備法律文件、用樣板 + 律師審 | PM / 法務 |
|
||
|
||
---
|
||
|
||
## 11.2 技術相依
|
||
|
||
### 11.2.1 對外部團隊的相依
|
||
|
||
| 相依對象 | 相依項目 | 時間敏感度 | 備案 |
|
||
|---------|---------|-----------|------|
|
||
| kneron_model_converter 團隊 | 轉檔 API 實作 | Phase 2 才需要 | 用 stub 撐住 Phase 0-1 |
|
||
| Innovedus IT | Staging 環境（子域名、TLS）| Phase 1 前 | Phase 0 在本機跑即可 |
|
||
| Kneron 官方 | KneronPLUS SDK 穩定性 | 持續 | 既有依賴，不新增 |
|
||
|
||
### 11.2.2 對內部專案的相依
|
||
|
||
| 相依對象 | 相依項目 | 備註 |
|
||
|---------|---------|------|
|
||
| local-tool | 作為 local agent 使用 | Phase 0 用**未修改版** local-tool 測試；Phase 1 才考慮整合新功能 |
|
||
| edge-ai-platform POC | 從中搬 relay / tunnel / cluster / wsconn 模組 | Phase 0 完成後 POC 就封存 |
|
||
|
||
### 11.2.3 對第三方套件的相依
|
||
|
||
**前端**（沿用 local-tool 版本）：
|
||
|
||
- Next.js 16（App Router）
|
||
- React 19
|
||
- Tailwind 4
|
||
- Radix UI
|
||
- Zustand
|
||
- **新增**：無（都沿用 local-tool 的 stack）
|
||
|
||
**後端**（沿用 POC 架構）：
|
||
|
||
- Go 1.26
|
||
- Gin
|
||
- gorilla/websocket
|
||
- hashicorp/yamux
|
||
- **新增（Phase 0 用 stub，但介面要預留）**：無實作層面的新依賴
|
||
|
||
**Phase 1 會新增**：
|
||
|
||
- PostgreSQL / pgx
|
||
- Redis / go-redis
|
||
- JWT library（例如 `golang-jwt/jwt`）
|
||
- AWS SDK 或 minio-go
|
||
- bcrypt
|
||
- email library（sendgrid 或 SES）
|
||
|
||
---
|
||
|
||
## 11.3 Phase 0 的已知限制（透明告知）
|
||
|
||
使用者（內部 FAE）在使用 Phase 0 雛形時需知道：
|
||
|
||
- **Auth 是 stub**：重啟 backend 後所有 user / session 消失，需重新註冊
|
||
- **資料不持久**：上傳的模型在 backend 重啟後會消失（local fs 存的話仍在，但 in-memory metadata 會消失）
|
||
- **Pairing Token 不撤銷**：Phase 0 一旦發出就無法主動撤銷，只能等 15min TTL
|
||
- **不支援大規模**：同時 10+ user 可能遇到效能問題
|
||
- **安全性極弱**：絕對不可用真實密碼，也不可佈署到公開網際網路
|
||
|
||
以上限制會在 visionA Cloud 前端明顯位置顯示 Banner（「⚠️ 雛形版本，僅供內部測試」）。
|
||
|
||
---
|
||
|
||
## 11.4 不可跨越的紅線
|
||
|
||
以下情況必須立即停下專案重新討論：
|
||
|
||
1. **local-tool regression** — 任何新改動導致 local-tool 既有測試 fail
|
||
2. **Auth stub 意外對外** — 任何真實使用者能訪問 Phase 0 環境
|
||
3. **資料隔離穿透** — 使用者 A 能看到 B 的資料
|
||
4. **Pairing 流程無法在任何企業網路跑通** — 代表核心技術路線需重新評估
|
||
5. **Phase 0 超時 2 個月以上** — 代表 Scope 有問題，需重新定義
|
||
|
||
---
|
||
|
||
## 11.5 開放問題（待使用者決定）
|
||
|
||
以下問題目前沒有明確答案，建議在 Phase 0 進行中釐清：
|
||
|
||
- [ ] **Q1**：雛形環境要部署到哪？本機 / 公司內部 VM / 外部 cloud？（影響安全設計）
|
||
- [ ] **Q2**：`visionA` 是正式產品名嗎？還是只是代號？（影響 domain 選擇與對外命名）
|
||
- [ ] **Q3**：Pairing Token 的 TTL 15 分鐘合適嗎？（影響使用者體驗）
|
||
- [ ] **Q4**：Phase 0 是否允許「一個 user 只能 pairing 一台 agent」的限制？（簡化設計但影響測試覆蓋）
|
||
- [ ] **Q5**：內部 FAE 測試後，哪些回饋算是 Phase 0 bug（要修），哪些推到 Phase 1？（判準）
|
||
- [ ] **Q6**：轉檔 API spec 要交給 converter 團隊的正式時機？（影響他們的排程）
|
||
|
||
---
|
||
|
||
## 連結
|
||
|
||
- 上一章：[開發範圍與階段](roadmap.md)
|
||
- 跳回：[PRD 索引](PRD.md)
|