依 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)。
6.7 KiB
6.7 KiB
11. 風險與相依 — visionA Cloud
父文件: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 不可跨越的紅線
以下情況必須立即停下專案重新討論:
- local-tool regression — 任何新改動導致 local-tool 既有測試 fail
- Auth stub 意外對外 — 任何真實使用者能訪問 Phase 0 環境
- 資料隔離穿透 — 使用者 A 能看到 B 的資料
- Pairing 流程無法在任何企業網路跑通 — 代表核心技術路線需重新評估
- 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 團隊的正式時機?(影響他們的排程)