這一系列文章主要是帶大家去了解Physical AI真正在研究什麼?

從機器人年會帶回來的第一個問題

🎬 影片／照片位置：

觀看重點：不要先看機器人像不像人，先找出它服務的對象、工作場域與唯一主要任務。

我這次參加 2026 TAIWAN ROBOTICS 開發者年會，聽到許多不同形式的機器人：會搬運的移動機器人、加上手臂的居家平台、餐飲機器人、巡檢機器人、自駕車，以及醫療與照護場域中的輔助應用。

它們的外形差異很大，但背後其實有一個共同問題：我們是先做出一台看起來很通用的機器人，再去找用途；還是先確認工作任務，再倒推機構、感測器與控制方法？

本篇只回答一個問題：一個機器人專案，應如何從任務倒推規格？

「什麼都能做」通常不是可驗證的需求

如果需求只寫「開發一台通用服務機器人」，工程團隊很難做出明確決定：

• 機器人需要幾個軸？
• 要輪式底盤、雙足，還是固定式機械臂？
• 馬達需要多大扭矩？
• 電池要支撐多久？
• 需要相機、LiDAR、力量感測器，還是只要位置編碼器？
• 任務失敗時要停止、退回，還是交由人員接手？

這些都不是先由「機器人的理想外形」決定，而是由任務、環境與風險共同決定。

年會第一場分享的重點可以濃縮成一句話：先確認機器人要解決哪一個場域問題，規格才有辦法被定義。

例如，清潔機器人真正卡住的可能不是吸塵，而是如何跨越樓梯；醫院物流的問題可能不是辨識所有醫療行為，而是固定路線上的檢體或物資配送；拉麵機器人的價值也不是模仿人類全部動作，而是把煮麵、配料與出餐流程拆成可以穩定執行的工作站。

從任務倒推的五個問題

一個適合進入開發的機器人任務，至少要回答下列五個問題。

這五個問題沒有寫清楚，後面即使選了昂貴硬體，也很難證明它是否適合任務。

用醫院檢體搬運做一個示例

假設我們要做的是「受控院內環境的檢體搬運示範」，需求不應只寫「開發醫療機器人」。比較可檢查的版本可以寫成：

• 使用者：檢體收送人員與工作站人員。
• 環境：固定樓層、已知取件點與交付點、有人員通行。
• 任務：讀取指定檢體容器的識別資料，完成取件、搬運、入架與交付紀錄。
• 成功條件：正確物件、正確位置、完整追溯紀錄，且沒有碰撞與遺失。
• 失敗處理：辨識不一致、路徑被阻擋或定位可信度不足時停止並通知人員。

到這一步，我們仍未決定要不要使用人形機器人。若固定路線的移動平台加上簡單升降機構就能完成任務，就不需要為了外形增加額外自由度與風險。

開源平台告訴我們的另一件事

年會第二場展示 Reachy Mini、LeRobot 與 XLeRobot 的整合。這類開源平台的優點，是成本較低、可以依需求增加相機、LiDAR、超音波與 IMU，也能把 Navigation2、語音工具與手臂控制模型串起來。

但可改裝也代表整合責任回到開發者身上。地板高低差、底盤走偏、玻璃對 LiDAR 的影響、模型只能在固定位置抓固定物件，以及安全模組不足，都會限制它從展示走向穩定應用。

所以，「買得到硬體」只代表可以開始試驗，不代表產品需求已經完成，更不代表能直接進入醫院或產線。

本篇完成品：一張機器人任務定義卡

讀者可以先用下列格式整理自己的專案：

任務名稱：
主要使用者：
使用場域：
唯一主要任務：
輸入資料／感測：
主要動作：
成功條件：
可預期失敗：
安全停止／退回方式：
目前不處理事項：

如果這張卡還寫不完，現在最需要的通常不是選機器人型號，而是回到場域釐清工作流程。

可以支持到哪裡？

本文可以支持的是機器人專案的需求拆解方法；不能用來判定特定機器人的性能，也不能把年會展示直接視為產品或臨床證據。

涉及醫療或照護場域時，技術示範、醫療器材功能、臨床有效性與臨床效益必須分開評估。場域測試還需要用途定義、風險管理、人因、資安、軟體驗證及適用法規評估。

今天帶走三件事

1. 機器人規格應由任務與場域倒推，不應先由外形決定。
2. 專用型機器人不一定比通用型落後，反而更容易定義完成條件。
3. 開源硬體降低試驗門檻，但不會自動解決整合、可靠度與安全責任。

Day 2 會進一步說明：當機器人開始接收相機、LiDAR、力量與位置資料時，Physical AI 與一般生成式 AI 到底差在哪裡。