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.9 KiB
4. 用戶研究 — visionA Cloud
父文件：PRD.md
4.1 用戶 Persona
Persona 1：阿哲 — Kneron FAE（主要用戶）
| 項目 | 內容 |
|---|---|
| 角色 | Kneron FAE（Field Application Engineer） |
| 年齡 / 背景 | 32 歲，資工本科，5 年嵌入式系統經驗 |
| 工作內容 | 跑客戶 demo、POC 支援、技術諮詢 |
| 目標 | 把 Kneron 晶片賣出去，讓客戶相信 Kneron 能做到 |
| 痛點 | 1. 出差要帶整台筆電 + 裝置，體力活 2. demo 環境每次不同，配置繁瑣 3. 客戶問「能不能遠端來看進度？」目前說不行 |
| 行為模式 | 每週 2-3 次出差，每次 demo 1-3 小時，demo 後客戶還會持續發問 |
| 技術素養 | 高（Linux、Python、C++） |
| 願意付費 | 公司付，不在意 |
| 一句話描述 | 「我希望能遠端讓客戶看到 Kneron 跑推論，這樣我就可以不用飛來飛去。」 |
Persona 2：Sarah — SI 系統整合商（主要用戶）
| 項目 | 內容 |
|---|---|
| 角色 | SI 技術主管（系統整合商） |
| 年齡 / 背景 | 38 歲，電機本科，資深工程師轉管理 |
| 工作內容 | 把 Kneron 導入客戶專案（例如零售店頭人流分析、工廠瑕疵檢測） |
| 目標 | 讓客戶的 Kneron 部署順利運轉，減少現場支援 |
| 痛點 | 1. 一個專案 3-10 台 Kneron 佈在不同地點，沒統一畫面 2. 客戶回報「裝置怪怪的」只能派人去現場 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 一次只能一個 2. 轉檔要去 converter 網站，使用者體驗斷裂 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 設計。
連結
- 上一章：市場分析
- 下一章：User Stories
- 跳回：PRD 索引