『400 萬次飛行』不等於 1,070 套 Dock 各自完成的完全自主飛行。Skydio 的公告把前者寫成公司整體累計規模,沒有提供 Dock 專屬分母或無人值守比例。先修正這個分母,才能判斷成熟度。

先拆掉總飛行次數的錯誤等式
4M+ 是公司整體累計,沒有證明全由 Dock 或完全無人值守完成。
常見誤解還包括把部署數當成同時上線數。1,070 套可能位於不同客戶、任務、軟體版本與運作時數;沒有啟用日和在線時間,就無法估計平均飛行數。
同樣地,『自主』可以指避障、航線執行、起降、充電或遠端監督,不一定表示現場與遠端都沒有人。每一層都應有獨立分母。
讀任何總量時,先建立三個分母:已安裝、可上線與實際執行任務。設備可能已交付但仍在施工,也可能上線卻因天候或許可長時間不飛。將三者分開,才不會把資本部署誤當成持續服務,也能看出擴張卡在硬體、法規還是營運。
1,070 套代表部署廣度,不代表相同使用
設備數要搭配啟用日、在線時間、任務與版本,才能比較。
Skydio 官方里程碑表示第一批量產 Dock 出貨一年後,已有 1,070 套分布於 3 國,服務公共安全、關鍵基礎設施與國防。這可支持部署廣度,不能支持所有客戶的平均成效。
公開案例包含失蹤搜尋、火災熱點、配電線檢查與軍事設施 ISR。案例存在不等於各任務有相同航線、風險、感測器與成功門檻。
部署廣度還需按產業與地理分層。消防、配電線和國防任務的飛行頻率、資料敏感度與可接受風險不同;三個國家的空域和隱私規則也不同。只有在同類任務中比較,才能判斷某個站點是否成熟,而不是讓高頻任務掩蓋低頻站點。
輸入與輸出都包含營運組織
天候、空域、健康與人員進入任務;影像、告警、介入和維護才是完整輸出。
遠端運作的輸入包含任務、天候、空域、機體與 Dock 健康、通訊和操作員可用性;輸出不只是影像,還有飛行狀態、告警、介入與維護。
Skydio 支援文件顯示,Dock for X10 仍需要機體、Dock、雲端或控制台及操作程序共同運作。安裝一個箱體不會自動建立值班和事件回復組織。
輸入資料的品質會直接影響自動排程。天候來源延遲、臨時空域限制未同步、Dock 感測器髒污或電池健康錯估,都可能讓任務在起飛前就不應執行。系統應記錄哪個來源阻止任務,並讓操作員知道是否可重試或需要現場檢查。
從 Dock 開門到資料交付逐段計數
起飛成功不能取代返航、充電、上傳和下一次就緒。
運作機制從排程、開門、機體檢查、起飛、任務、返航、精準降落、充電到資料上傳。任何一段失敗,都可能需要遠端或現場人員。
可用率要把天候停飛、空域限制、機體維護、Dock 門或充電故障、網路中斷與人工取消分開,不能只用成功起飛數。
一個站點的可用率可以拆為排程可用、起飛可用、任務可用和下一趟就緒。返航成功但充電失敗,不應算完整循環;影像取得但未上傳,也可能不符合客戶任務。以工作流程終點定義完成,避免把飛行事件本身當成全部價值。
案例要附嘗試與取消分母
公共安全和基礎設施任務各有不同成功標準。
一個具名公共安全案例可以說明可能用途,但要形成證據,需有嘗試次數、成功、取消、介入、發現時間與既有流程比較。只列出戲劇性成功,無法估計日常值班價值。
可搭配 戶外機器人測試基準建立氣象、通訊和復原分母,也可用 實體 AI 無人機架構分開機體自主與 Dock 營運。
具名案例最好提供現有流程對照。例如配電線人工巡檢需要多少時間,Dock 任務在相同範圍內減少多少出勤,以及例外仍需誰到場。沒有對照時,案例能證明功能可用,不能證明節省人力、改善反應或降低風險。
總量仍回答不了站點成熟度
公開資料缺少客戶別加動率、完成率、事件率與介入;缺資料也不能反過來當成效能差的證據。
反例是低頻使用的 Dock:它已安裝並有飛行,但因天候、空域或人員只在少數時段運作。另一個反例是高頻訓練飛行拉高總量,卻不能代表真實任務成功。
FAA waiver 實例還顯示,功能測試、維護紀錄、遠端駕駛責任與具體運作條件仍附在遠端或 BVLOS 作業上;單一 waiver 也不會自動適用所有人。
waiver 條件也會限制數字的可移植性。某一營運商在特定機型、區域和程序下獲准,不代表另一客戶可沿用。採購評估應確認自己的遠端駕駛、維護、通訊、觀察與緊急程序,並把取得或維持核准所需工時算入總成本。
| 名詞 | 公開數字可支持 | 仍不能支持 |
|---|---|---|
| 部署 | 1,070 套、3 國的公司統計 | 全部同時在線或同型號 |
| 飛行 | 公司整體 4M+ 累計 | Dock 專屬或完全自主分母 |
| 自主 | 指定功能可遠端運作 | 零操作員、零現場介入 |
| 案例 | 具名使用情境存在 | 平均任務成效或事故率 |
| waiver | 特定申請人的條件案例 | 所有美國作業自動獲准 |
下一份報告要補的不是另一個大數字
站點分布、介入、取消、維護和事件率,才讓部署數變成營運證據。
下一步應要求每個站點月度在線時數、任務嘗試、完成、天候取消、空域取消、遠端介入、現場出勤、維護和事件。數字不必公開客戶敏感資訊,仍能用分布呈現成熟度。
多站點擴張時,另看權限、資料保存與供應商鎖定;多廠牌機器人營運可延伸到控制與資料主權問題。
下一份成熟度報告若能提供中位與高百分位,而非只有累計,就更有價值:每站月任務、介入間隔、故障修復、天候取消、現場出勤和任務完成時間。這些分布也能揭露少數高頻站點是否拉高整體總量,讓買方看見典型而非最佳表現。
資安與資料也要進入站點成熟度。遠端帳號、機體憑證、Dock 實體防護、雲端權限、影像保存與事件日誌都需管理。若一個帳號能跨多站點控制,權限錯誤的影響會隨部署擴大;應採最小權限、分站審計和快速撤銷。
維護數據最好分成遠端可解決與必須到場。軟體重啟、任務重排或天候等待可遠端處理,門故障、充電接點、機體損傷和感測器污染可能要現場。各自的平均與高百分位復原時間,能直接回答無人值守是否只是把人移到支援中心。
最後不要把未公開指標填成零。Skydio 沒有公布事故率或客戶別完成率,正確寫法是『無法由公告判定』。資料缺口既不是負面證據,也不應被行銷總量取代;它是買方在合約與試辦中需要補證的清單。
- 站點啟用日與在線時數
- 任務嘗試、完成與取消原因
- 遠端介入與現場出勤
- 機體、Dock、網路和軟體故障
- 事件、維護與再放行紀錄
讀者接著會問
這些數字不能證明什麼?
不能證明每次飛行都由 Dock 發起、完全無人值守、沒有事故,或每個站點有相同任務成功率與妥善率。還需要站點與任務分母。
資料最後查核:2026 年 8 月 25 日