Case study · OneStroke 一拍

用手機影片
看懂每一拍的網球分析產品

我在球機場自主練球，市面的分析工具給了分數，卻說不出差在哪、下一步練什麼。我把這個困擾做成一個可以拿去試賣的產品：上傳一段練習影片，自動切出每一拍、打分數、像教練一樣診斷，再把人還原成 3D。

角色: 產品負責人（定義、研究、驗證、設計決策）
階段: 可試賣的 MVP
團隊: 我＋AI 編碼代理（Claude Code）
形態: 手機網頁＋本機運算，PDF 報告與分享影片

48 秒產品介紹影片；點「開聲音」從頭聽原創配樂。

0 元每場的運算成本，影片不離開自己的電腦

107次提交，每一步都能單獨驗收

13版評分模型，歷史紀錄一鍵重算

158 拍8 分半影片自動切出，本人逐拍確認

0.91轉肩速度與 OptiSwing 的逐拍相關

Problem

分數很多，但不知道下一步該練什麼

現有工具的缺口

我用 OptiSwing 分析同一段影片：「手臂旋轉」直接 100 分，分數飽和、失去區分度
只給每項數字，看不出「最該改的是哪一個」
沒有練習方法，也不會在下一次幫你驗收有沒有進步

替代方案的成本

一對一私人課每小時約 NT$800–1,600（PRO360 行情），教練也很少拿數據說明
國外人工影片分析單次 £35–55，要等好幾天
機會：手機錄影已經很普及，姿態估計模型也成熟到可以在一般電腦上跑

Users & context

先服務一個非常具體的情境

第一版只鎖定我自己的使用情境，讓每個假設都能用真實資料檢查；架構上預留教練帶學員的延伸。

主要使用者：自主練球的業餘球員

室內球機場、一個人打、手機固定在場邊。一次練 10 分鐘左右、100 拍以上。想知道今天哪裡打得好、哪裡要改、下次練什麼。

延伸使用者：帶學員的教練

要分開管理每位學員的資料、給學員只看得到自己的連結，並交出一份正式的報告。這是核心流程驗證過之後才加進來的，作為之後帳號系統的基礎。

Principles

我先寫下的五條規則

這些規則寫在專案規格的最前面，後面每一個取捨都回頭對照它們。

授權先行

保留商業化的可能，所以選型一律優先可商用授權。主流的 SMPL 系 3D 人體模型不能商用，直接排除；每引入一個模型，就把版本、授權、能不能商用記下來。

原始值是資料，分數是衍生層

永遠只存角度、速度、位移這些原始指標，分數在產生報告時才算，評分公式標版本。公式改了，所有歷史練習可以重算，趨勢不會斷。

每個數字都有出處

評分的參考值來自運動生物力學文獻：高水準選手的平均換算成 80 分、平均減兩個標準差是 50 分；出處逐條記在評分說明文件裡。

比排序，不比絕對值

單一鏡頭的 3D 跟實驗室動作捕捉有系統性偏差。驗證時不要求數字一樣，只要求哪幾拍高、哪幾拍低的排序和趨勢一致。

像教練說話

報告的讀者是打球的人。內文用白話和身體的比喻，例如「三球有一球」「一個拳頭」；原始數字收進可以展開的「看數據」，當作證據。

Product architecture

一個閉環：診斷 → 練習 → 驗收

產品的核心不是「給分數」，而是讓每一次練習都接到下一次。上傳之後的每個畫面，都在這個閉環的某一步上。

01架好手機錄側拍、正面、背後都可以；一次 10 分鐘

02上傳手機直接傳；先檢查幀率、解析度、拍攝時間

03自動處理切拍、分類、姿態、指標、評分；自動挑 5 拍跑 3D

04看報告一句話診斷、做到 vs 沒做到、3D

05照練本週重點、練法、組數、做不到時的替代練法

06下次自動驗收下一場上傳時逐項比對方案的目標值

驗收的結果寫進下一份報告的「上次的功課」，決定重點要延續還是換下一個

首頁每位球員一個

今天本週重點、最新一場、平均分

計畫練習方案、追蹤目標、關卡

進步跨場趨勢、NTRP 參考等級

紀錄每場一張卡、備註、刪除

報告每場練習一份

診斷最主要的一個問題、做到 vs 沒做到、上次的功課

數據各項分數、最佳 5 拍、分佈範圍、檢查點

每一拍切片、3D 檢視器、對照教學

輸出帶得走的

分享影片3D 子彈時間、光軌、做到 vs 沒做到

最佳 vs 典型兩個 3D 人體並排同步繞一圈

PDF 報告深色正式版：封面、章節、頁碼

教練多學員

學員管理切換球員、新增學員

專屬連結學員只看得到、只能上傳自己的

資料各自獨立持拍手、身高、基線、趨勢分開算

Technical architecture

本機運算、網頁介面，預留帳號與雲端

第一版刻意不上雲：影片留在自己的電腦，運算成本是零，又能在手機上看。每一層都留了往雲端與帳號系統走的接口。

用戶端手機／電腦瀏覽器

單頁報告資料直接寫進頁面，沒網路也能開

3D 檢視器three.js：假人網格、骨架、揮拍光帶

分享影片編碼瀏覽器 WebCodecs；不支援時交給伺服器

深淺色主題同一套設計系統 token

HTTPS · 金鑰

本機伺服器Python

權限擁有者看全部；學員金鑰只看自己的；區網自簽憑證

上傳＋工作佇列一次處理一支、進度回報、失敗重試

按需運算補跑 3D、產生高精細假人、匯出 PDF

用量紀錄每次 3D 記球員與拍數，之後計費用

子行程

處理流程兩個環境

切片＋2DPyAV、ONNX（CoreML 加速）、MediaPipe

3DPyTorch（Apple MPS）、SAM 3D Body、MHR 網格

報告與 PDFPython 產生 HTML；Chrome 無頭模式印 A4

綜合分析Claude Code 無頭模式，照撰寫規範寫

讀寫

資料每位球員一個資料夾

路徑層所有位置集中管理；換帳號系統只改這層

報告每一場一個資料夾：切片、姿態、3D、分享影片reports/球員/練習

快取每支影片的 2D／3D 姿態與人工修正，重做報告不用重算data/球員/日期/影片

名冊與回收區球員名冊；刪除的練習保留 30 天

Model architecture

聲音＋動作找出每一拍，2D 為主、3D 補強

每個模型都有明確的分工與授權。2D 每一幀都跑、成本低；3D 只跑關鍵的拍與關鍵的幾格，補 2D 量不到的轉動與手臂。

音訊

擊球聲偵測1.5–8 kHz 帶通後找波峰；比背景高 8 dB 才算候選

視覺

人體偵測 YOLOX鎖定目標球員（最大、最靠中間的人）APACHE-2.0

2D 姿態 RTMPose每一幀 17 個關節；另一個模型 RTMW 做資料稽核APACHE-2.0

兩條線配對

切片：聲音 × 手腕速度峰值兩者在 −0.35～+0.2 秒內同時出現才算一拍；只有聲音（球機、隔壁場）或只有動作都排除；擊球前 1 秒到後 0.5 秒

每一拍

正反手分類兩手距離、在身體哪一側、揮拍方向，依拍攝角度加權的邏輯迴歸自訓 · 留一場 97%

3D 骨架 MediaPipe33 點世界座標，量轉身與面向APACHE-2.0

學生模型以 SAM 3D 為老師、只吃 2D，判斷手腳前後自訓

自動挑 5 拍，按需補跑

3D 人體 SAM 3D Body（Meta）每拍只算擊球前後 11 個關鍵幀再插值；輸出 70 個關鍵點、各關節旋轉與 MHR 人體網格：手臂旋轉、腕部、轉肩都從這裡量；網格做成霧面假人，用在 3D 檢視器與分享影片SAM LICENSE

原始指標

指標30 多項原始值：轉肩速度、手臂鞭打、屈膝、上步、重心前移…；只存原始值

評分層文獻參考值經 logistic 映射到 0–100；職業／進階／入門三種尺度；版本化，可整批重算

檢查點與診斷逐拍判斷做到沒做到；找出跟速度最相關的問題

撰寫

綜合分析 Claude照撰寫規範把數據寫成教練口吻：一句話診斷、三段分析、練習方案；每個數字先算過再寫，數字收進「看數據」

產品的關鍵環節模型或處理步驟標籤是授權或驗證結果

Decision log

七個關鍵取捨

決策 01

3D 人體要用哪個模型

情境: 要量轉肩、手臂旋轉，2D 不夠；但準確度最好的幾個模型都是 SMPL 系，授權不能商用。
選項: WHAM / GVHMR（SMPL）SAM 3D Body只用 2D
決定: 3D 用 Meta 的 SAM 3D Body，2D 用 Apache-2.0 的 RTMPose 與 MediaPipe；把商用前仍需律師確認的條款列成清單。
結果: 保住商業化的路，同時拿到手臂旋轉、腕部這些 2D 量不到的指標。

決策 02

2D 量不準的指標怎麼辦

情境: 做了兩個姿態模型互相比對的資料稽核，發現髖肩分離角在 2D 下兩個模型對不起來。
決定: 把它移出計分，只當參考；之後每個指標依拍攝角度標「可信／參考／不可信」。
結果: 寧可少一項分數，也不給使用者錯的數字；後來支援正面、背後等角度時，這張可信度表直接沿用。

決策 03

3D 太慢，要不要上雲端

情境: SAM 3D 在 Mac 上每拍 13–25 秒，一場 150 拍要 40 分鐘以上；雲端 GPU 的成本還沒實測。
選項: 全部上雲端全部本機關鍵幀＋插值，只跑關鍵的拍
決定: 只算關鍵幀再插值；上傳後自動挑 5 拍（本場最佳、典型、方案的目標拍與問題拍、待改進），其他拍按需補跑，並記下每次用量。
結果: 每場的 3D 從 40 分鐘以上降到約 2 分鐘；用量紀錄直接成為「基本 5 拍、全場加購」收費方案的計費依據。

決策 04

沒有 3D 時，骨架常把手腳前後弄反

情境: 2D 只看得到平面，四肢前後顛倒的比例在不同角度有 11–28%。
決定: 用 SAM 3D 的結果當老師，訓練一個只吃 2D 的小模型判斷前後，混合進原本的骨架；同時確認 SAM 授權沒有禁止用輸出訓練。
結果: 顛倒率降到正面 2%、右後 3%、側面 9%、背後 14%，而且不用多付 3D 的運算成本。

決策 05

分享影片要長什麼樣子

情境: 使用者想把好球分享出去，這也是最便宜的獲客管道；需求是「要高級、能病毒傳播、展示厲害的東西」。
決定: 預設樣式做成「3D 子彈時間」：原片播一次 → 擊球瞬間定格 → 本人變成 3D 雕塑繞一圈 → 回原片收拍；片尾品牌畫面固定、不能關。
結果: 每一支分享影片都是一則產品示範；之後的「最佳 vs 典型」對比影片也沿用同一套 3D 舞台。

決策 06

要不要在手機端先壓縮再上傳

情境: 一場原片約 580 MB，手機上傳很慢。
實驗: 手機端先切片：仍要上傳 79–84%，不划算。壓成 720p 2Mbps：大小降到 1/4，拍數、正反手幾乎一樣，但壓縮雜訊讓速度類指標偏高 3–17%。
決定: 先不上線。偏高的數字混進歷史紀錄，會讓使用者誤以為自己進步了；等決定好歷史資料怎麼銜接再做。
結果: 把一個看起來簡單的優化，變成一份有數據的取捨紀錄，避免傷到最核心的「趨勢可信」。

決策 07

要給學員用，資料要怎麼分

情境: 準備找球友試用，之後可能要做帳號系統。
選項: 在現有資料上加標記每位球員一個資料夾＋路徑層
決定: 做最徹底的版本：所有路徑集中到一層，每位球員各自的設定、基線、趨勢與首頁；學員有專屬連結，只看得到、只能上傳自己的資料；刪除先進回收區，30 天內可復原。
結果: 端對端測試通過（上傳、3D、自動分析都落在學員自己的資料夾）；之後換成帳號系統，只要改路徑那一層。

Validation

怎麼知道它是對的

每個開發階段都先訂好驗收標準，再拿真實資料檢查。第一段測試影片是我在球機場錄的 8 分半正手練習。

項目	方法	結果
自動切拍	驗收標準：與人工計數差距小於 5%；我逐拍看過縮圖	158 拍，本人確認
正手／反手分類	10 場、110 拍逐拍目視標註；另做留一場交叉驗證	108 / 110 判對
跟 OptiSwing 對照	同一段影片的前 10 拍，逐拍比較高低排序	轉肩 0.91、手速 0.90
單項數值抽查	第 10 拍擊球瞬間的屈膝角	25° vs OptiSwing 26°
整體分數	最佳 5 拍平均的力量／技術分	73 / 62 vs 71 / 62
畫面類功能	每場、每種拍攝角度、有沒有 3D，至少實際產生一支再交付	成為固定的交付規則