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）。
140 lines
7.9 KiB
Markdown
140 lines
7.9 KiB
Markdown
# 4. 用戶研究 — visionA Cloud
|
||
|
||
> 父文件：[PRD.md](PRD.md)
|
||
|
||
---
|
||
|
||
## 4.1 用戶 Persona
|
||
|
||
### Persona 1：阿哲 — Kneron FAE（主要用戶）
|
||
|
||
| 項目 | 內容 |
|
||
|------|------|
|
||
| 角色 | Kneron FAE（Field Application Engineer）|
|
||
| 年齡 / 背景 | 32 歲，資工本科，5 年嵌入式系統經驗 |
|
||
| 工作內容 | 跑客戶 demo、POC 支援、技術諮詢 |
|
||
| 目標 | 把 Kneron 晶片賣出去，讓客戶相信 Kneron 能做到 |
|
||
| 痛點 | 1. 出差要帶整台筆電 + 裝置，體力活<br>2. demo 環境每次不同，配置繁瑣<br>3. 客戶問「能不能遠端來看進度？」目前說不行 |
|
||
| 行為模式 | 每週 2-3 次出差，每次 demo 1-3 小時，demo 後客戶還會持續發問 |
|
||
| 技術素養 | 高（Linux、Python、C++）|
|
||
| 願意付費 | 公司付，不在意 |
|
||
| 一句話描述 | 「我希望能**遠端讓客戶看到 Kneron 跑推論**，這樣我就可以**不用飛來飛去**。」 |
|
||
|
||
### Persona 2：Sarah — SI 系統整合商（主要用戶）
|
||
|
||
| 項目 | 內容 |
|
||
|------|------|
|
||
| 角色 | SI 技術主管（系統整合商）|
|
||
| 年齡 / 背景 | 38 歲，電機本科，資深工程師轉管理 |
|
||
| 工作內容 | 把 Kneron 導入客戶專案（例如零售店頭人流分析、工廠瑕疵檢測）|
|
||
| 目標 | 讓客戶的 Kneron 部署順利運轉，減少現場支援 |
|
||
| 痛點 | 1. 一個專案 3-10 台 Kneron 佈在不同地點，沒統一畫面<br>2. 客戶回報「裝置怪怪的」只能派人去現場<br>3. 模型改版要逐台更新 |
|
||
| 行為模式 | 每週管 2-5 個專案，每個專案生命週期 3-12 個月 |
|
||
| 技術素養 | 高，自己帶一個 3-5 人的工程團隊 |
|
||
| 願意付費 | 願意（公司成本），但要有明顯 ROI（省出差費 / 人力）|
|
||
| 一句話描述 | 「我希望能**一個儀表板看到所有客戶現場的 Kneron 狀態**，這樣我就可以**少派工程師出差**。」 |
|
||
|
||
### Persona 3：Mike — AI 應用開發者（次要用戶）
|
||
|
||
| 項目 | 內容 |
|
||
|------|------|
|
||
| 角色 | 獨立開發者 / 新創 ML engineer |
|
||
| 年齡 / 背景 | 28 歲，資工碩士，2 年 ML 經驗 |
|
||
| 工作內容 | 開發 AI 應用原型，評估不同邊緣硬體（在 Jetson、Coral、Kneron 間比較）|
|
||
| 目標 | 找到性價比最好的硬體 + 模型組合 |
|
||
| 痛點 | 1. 想同時跑多個模型比效能，但 local-tool 一次只能一個<br>2. 轉檔要去 converter 網站，使用者體驗斷裂<br>3. 沒辦法和隊友共享推論結果 |
|
||
| 行為模式 | 每天開發 4-6 小時，2-4 週評估一次硬體 |
|
||
| 技術素養 | 高（PyTorch、ONNX、熟悉 ML pipeline）|
|
||
| 願意付費 | 個人用戶，willing-to-pay 低（< $50/mo），但公司預算可以 |
|
||
| 一句話描述 | 「我希望能**在一個介面跑 A/B test 不同模型**，這樣我就可以**快速選出最佳方案**。」 |
|
||
|
||
---
|
||
|
||
## 4.2 用戶旅程地圖
|
||
|
||
### 主要旅程：阿哲第一次使用 visionA Cloud
|
||
|
||
| 階段 | 用戶行為 | 想法 / 感受 | 痛點 | 機會點 |
|
||
|------|---------|-----------|------|--------|
|
||
| **認知** | 聽到內部公告「visionA Cloud 雛形可試用」| 「終於有雲端版了，以前一直說要做」| 不知道和 local-tool 有什麼差別 | 用清楚的對照表說明定位 |
|
||
| **註冊** | 打開 visionA Cloud 首頁 → 輸入公司 email | 「希望不要填太多欄位」| 表單太長會跳出 | Phase 0 雛形：只要 email + 密碼，其他 TODO |
|
||
| **Pairing** | 登入後看到空的裝置列表 → 點「配對新裝置」→ 複製 Pairing Token → 打開筆電上的 local-tool → 貼 token | 「步驟不能太多，5 步內要搞定」| 不確定 local-tool 該從哪裡貼 token | Phase 1：local-tool 要內建「Pairing」UI；Phase 0：TODO，手動編輯 config |
|
||
| **首次推論** | 配對成功 → 裝置列表出現 → 選裝置 → 選模型 → 選 Camera 來源 → 開始推論 | 「畫面跟 local-tool 一樣，直覺」| 遠端有延遲，會不會卡 | 在 UI 明確顯示連線狀態和延遲 |
|
||
| **持續使用** | 每週 demo 前開 cloud 確認裝置在線 | 「和本機一樣順」| Tunnel 斷線重連體驗 | 自動重連 + 狀態透明 |
|
||
| **推薦** | 和其他 FAE 分享 | 「你也試試，不用帶筆電了」| — | 內建「邀請隊友」功能（Phase 2）|
|
||
|
||
### 次要旅程：Sarah 導入 visionA Cloud 管理多客戶現場
|
||
|
||
| 階段 | 用戶行為 | 痛點 | 機會點 |
|
||
|------|---------|------|--------|
|
||
| 認知 | 從 Innovedus 業務聽到產品 | 擔心可靠性（企業專案不能當機）| 強調雙模式 — cloud 斷線時還有 local-tool 可用 |
|
||
| 評估 | 在內部測試環境試 Pairing | 企業網路 proxy 可能擋 WebSocket | TDD 要規劃 proxy / TLS 穿透測試 |
|
||
| 導入 | 逐個客戶現場佈署 local agent | 客戶 IT 可能要審 | 提供安全白皮書（Phase 1）|
|
||
| 日常 | 每天早上開儀表板巡房 | 裝置離線沒通知 | Phase 1：加 alerting / email 通知 |
|
||
| 升級 | 介紹給下一個客戶 | — | 打造 SI-friendly pricing（Phase 2）|
|
||
|
||
---
|
||
|
||
## 4.3 關鍵洞察
|
||
|
||
### 洞察 1：使用者不想學新 UI
|
||
|
||
兩個 Persona 都是已在用 local-tool 的人。visionA Cloud 的 UI **必須和 local-tool 幾乎一樣**，只加上必要的雲端元素（裝置列表含「遠端 / 本機」狀態、登入頁、Pairing 頁）。
|
||
|
||
**Design Agent 請留意**：設計規格 90% 參考 local-tool 現有頁面，新增的只有 `/login`、`/register`、`/account`、`/pair`、`/clusters`（從 POC 搬），其他頁面**保持一致**。
|
||
|
||
### 洞察 2：連線狀態必須極度透明
|
||
|
||
local-tool 是 localhost，連線成功率 99.99%。visionA Cloud 過 tunnel，連線會斷會重連。使用者對「遠端不可靠」有心理預期，但**不透明的斷線最讓人抓狂**。
|
||
|
||
**設計要求**：
|
||
|
||
- 裝置狀態要明確分「在線 / 離線 / tunnel 斷線重連中」
|
||
- 推論中如果 tunnel 斷，要立即提示並自動重連
|
||
- 延遲要顯示（例如 header 上顯示「tunnel RTT: 120ms」）
|
||
|
||
### 洞察 3：Pairing 是最大摩擦點
|
||
|
||
從「註冊」到「首次推論」的轉換漏斗中，**Pairing 那一步最容易掉用戶**。使用者要跨兩個介面（瀏覽器 + 筆電 local-tool），要複製貼上 token。
|
||
|
||
**Phase 0 的妥協**：允許 token 手動編輯 local-tool config 檔（給技術高素養用戶）。
|
||
|
||
**Phase 1 的理想**：local-tool 內建「配對到 visionA Cloud」按鈕，瀏覽器 callback 自動帶 token 過去。
|
||
|
||
### 洞察 4：SI 最在意的是「少派人出差」
|
||
|
||
對阿哲（FAE），核心價值是「自己少累一點」。對 Sarah（SI），核心價值是「團隊少派工程師出差」，這是**可量化的成本節省**。
|
||
|
||
**Phase 1 行銷素材**可以用這個角度：「每月省下 X 次出差 = 省 Y 元 + Z 天工程師時間」。
|
||
|
||
### 洞察 5：Mike 是次要但不能忽視的用戶
|
||
|
||
Mike（獨立開發者）不是主力，但他們是**未來 SI 和 FAE 的潛在來源**（獨立開發者可能被 Kneron 挖角或進 SI）。而且 Mike 的使用量高（每天開發），對 UX 細節敏感。
|
||
|
||
Phase 0 不會針對 Mike 做客製，但 Phase 2 要考慮：
|
||
- 個人訂閱方案（比 SI 方案便宜）
|
||
- 模型 A/B 比較功能（workspace 升級）
|
||
- 開放 API（讓 Mike 寫自動化腳本）
|
||
|
||
---
|
||
|
||
## 4.4 未回答的問題（需要用戶訪談）
|
||
|
||
Phase 0 後期 / Phase 1 前，建議做 5-10 次用戶訪談，回答以下問題：
|
||
|
||
- [ ] SI 客戶的 IT 政策有多嚴？（NAT / Proxy / TLS 要求）
|
||
- [ ] FAE 做 demo 時 tunnel 斷一次能忍受嗎？還是直接失敗？
|
||
- [ ] 使用者期待的 pairing token 生命週期是多久？（1 小時？7 天？永久？）
|
||
- [ ] 叢集推論是否真的對 SI 有價值？或只是 nice-to-have？
|
||
- [ ] 使用者是否願意把模型（可能是商業機密）上傳到 visionA Cloud 的 S3？
|
||
|
||
這些問題的答案會影響 Phase 1 的功能優先級與 Auth / Security 設計。
|
||
|
||
---
|
||
|
||
## 連結
|
||
|
||
- 上一章：[市場分析](market-analysis.md)
|
||
- 下一章：[User Stories](user-stories.md)
|
||
- 跳回：[PRD 索引](PRD.md)
|