Physical AI 基礎論述 / 05

智慧設備加入 AI 後，產品經理要開始懂哪些新問題？

當 AI 進入相機、家電、穿戴、機器人與其他智慧設備，產品不再只是硬體加 App。從感測器、模型、功耗、連線、OTA、安全與隱私，重新拆解 AI 裝置的產品生命週期。

M.K.2026年9月2日9 分鐘閱讀

近未來城市中的智慧設備、邊緣運算節點與分散式基礎設施彼此連結，呈現 AI 產品從硬體出貨走向長期更新與維運的生命週期

M.K. / 文章與筆記實體 AI / AI 基礎設施 / 2026

當一台智慧設備的規格表多了一項「AI 功能」，最容易犯的錯，是把它當成另一個 software feature。

模型準確率多少？要不要放 NPU？要不要連雲端？這些當然重要，但都還不夠。

設備一旦真正出貨，就被綁在一組很難臨時改變的物理條件上：感測器已經選定、記憶體已經焊上去、電池容量固定、散熱空間有限、網路品質不受你控制，bootloader 與 OTA 路徑甚至可能在量產前就已決定。

AI 又在這個既有難題上多加一層變數：模型會更新，runtime 會變，硬體加速器有相容性差異，prompt 可能跟模型版本互相影響，資料邊界也會隨 local / cloud routing 改變。

所以我認為，AI 智慧設備真正改變產品經理工作的地方，不是「PM 要開始懂模型」。

而是 PM 必須開始懂一個會持續變動的 system。

上一篇我談 Edge AI 為什麼重新變重要，核心問題是「哪一個判斷應該在哪裡發生」。這一篇往產品管理再推一步：當這些判斷真的被放進一台會出貨、會斷網、會老化、會更新、會被使用數年的設備裡，產品規格到底要多問哪些問題？

AI feature 不是一個功能，而是一條跨層依賴鏈

傳統智慧硬體本來就不是純硬體。

它至少包含 sensor、MCU / SoC、firmware、OS 或 RTOS、connectivity、mobile app、backend service 與 device management。AI 加進來後，鏈條又被拉長：

sensor → preprocessing → runtime → accelerator → model → rules / tools → local action → cloud service

這條鏈裡任何一層改變，都可能影響最後的使用者體驗。

今天的 on-device AI runtime 很清楚地反映這種現實。Google 2026 年把 LiteRT 的 GPU / NPU acceleration 推進正式 production stack，強調同一套部署流程仍要面對不同 SoC、NPU、CPU 與 GPU backend；PyTorch ExecuTorch 的文件也直接指出，backend optimization 是 target-specific，同一模型若要支援 XNNPACK、Core ML 或 Vulkan 等不同 target，部署 artifact 需要依 backend 分別產生與驗證。

這不是在說產品經理要自己做 model export。

真正的產品問題是：

「我們承諾的這個 AI 功能，到底依賴哪些 hardware / OS / runtime / model 組合？」

如果這個問題沒有在規格階段寫清楚，後面很容易出現一種假象：demo 在開發機上成立，但真正的產品矩陣裡只有部分 SKU、部分 OS 版本或部分硬體 revision 能穩定交付。

我會把這張表叫做 AI dependency map。這不是業界正式標準，而是我認為 PM 應該比功能清單更早建立的一張圖。

「有 AI」不是 yes / no，真正要定義的是 capability envelope

AI feature 很容易被產品文件寫成 checkbox：有摘要、有語音控制、有影像理解、有離線推理。

但實際設備世界通常不是這麼乾淨。

Apple 的 SystemLanguageModel 文件要求開發者在使用模型前先檢查 availability，因為裝置資格、地區與模型是否已準備完成，都可能讓功能不可用；官方文件甚至直接要求產品設計 fallback experience。

另一邊，Google 在 2026 年 8 月更新的 Play for On-device AI beta，已經把模型本身當成可管理的 distribution asset：可以 install-time、fast-follow 或 on-demand 下發，也可以依 device model、system properties 或 RAM 提供不同 model variant。它還沿用 test track 與 staged rollout 管理發布。

這兩個例子都指向同一件事：

「支援 AI」不能只是一個 checkbox。

更完整的產品定義應該問：

這個功能在哪些 device class 可用？模型不存在或尚未下載時怎麼辦？沒有適合的 accelerator 時是否降級？離線時剩下哪些能力？雲端不可用時是不是仍有基本模式？舊裝置會拿到相同模型，還是較小版本？

我更願意把這叫 capability envelope：產品不是承諾一個抽象的 AI 能力，而是承諾「在什麼硬體、軟體、網路與模型條件下，這個能力成立」。

功耗、延遲與熱，不該留到工程最後再最佳化

我在 Edge AI 那篇文章裡已經談過 local / cloud placement，所以這裡不再重複「為什麼 on-device inference 很重要」。

產品管理真正該往前一步問的是：

一個 AI 功能每天可以花掉多少資源？

Google 2026 年 4 月談 LiteRT 與 NPU 的實際部署時，直接把 device thermals、battery life 與 frame drops 列為 on-device AI 的核心工程挑戰。Arm 的 Edge AI 資源也把低功耗、resource-constrained device 與 low-latency inference 放在同一個設計問題裡。

推理不是抽象的 API call。它會消耗電、記憶體、頻寬與熱設計空間。

同一個功能如果每秒推理一次、每十秒推理一次，或只有 sensor event 發生才喚醒，產品結果可能完全不同。相機 frame rate、麥克風 wake strategy、定位頻率、模型大小、量化方式、是否常駐記憶體，都會變成 battery life 與 responsiveness 的一部分。

我會把這組約束稱為 intelligence budget。

它至少應包含 latency、memory、power、thermal、bandwidth 與 cloud cost。

這也不是正式業界名詞，而是一種產品規格思維：如果 AI 沒有 budget，最後通常只剩「盡量快、盡量準、盡量省電」三個互相衝突的要求。

模型版本開始變成產品版本

我認為這是 AI device 最容易被低估的新問題之一。

過去智慧設備更新時，我們通常會追 firmware version、app version、backend version。

現在還要多追一個 model version，而且它不一定跟 firmware 同步。

如果設備使用平台提供的 system model，模型可能跟著 OS 更新；如果使用自有模型，團隊又可能透過獨立 model package 下發；如果同時有 local model 與 cloud model，兩邊甚至可能在不同節奏更新。

Apple 在 2026 年的 Foundation Models 更新文件把這個問題講得很直接：系統模型會隨 OS 更新而改變，開發者應重新測試 prompts；另一份 prompt versioning 文件更建議比較新舊模型輸出，必要時對不同 model version 維護不同 prompt。

這代表一件以前比較少見的事：

App 沒改版，AI 行為仍然可能改變。

因此我認為 PM 需要開始管理 behavior version，而不只是 software version。

產品規格除了「功能是否能用」，還要有一個更難的問題：

「這個版本的 AI 行為，哪些部分是我們承諾不變的？」

我會把這稱為 model behavior contract。

例如某個安全提醒功能允許文字措辭改變，但不能因模型更新跨過既定的風險判斷門檻；某個推薦功能可以變聰明，但不能在 model update 後突然改變資料上傳範圍。

這種 contract 不一定能寫成傳統 API schema，卻必須能被 regression test 驗證。

否則模型每次更新，都像把一個部分未知的新產品送進既有設備。

OTA 不再只是維護工具，而是產品能力

智慧設備一定會遇到更新問題，但 AI 讓更新的版本關係更複雜。

NIST 的 IoT cybersecurity baseline 把 Software Update 列為核心 device capability，要求更新只能由授權實體透過安全且可設定的機制執行，並能驗證更新來源。這裡值得注意的是，NIST 並沒有替所有產品指定同一套 rollout 或 rollback 架構；那些仍然是產品與系統設計選擇。

實際平台可以看到更具體的工程做法。AWS IoT 的 firmware update guidance 建議對 firmware 做 code signing，讓終端設備在安裝前驗證真實性；NVIDIA Jetson Linux 的 image-based OTA 則支援 rootfs A/B 等更新路徑，文件也要求 OTA client 驗證 payload，並建議對更新包使用 signature 或 encryption 等安全機制。

技術細節背後有一個產品原則：

更新不是「有 OTA 就好」。真正需要規劃的是 failure path。

Firmware 更新失敗怎麼回復？Model 更新失敗要不要和 firmware 一起 rollback？Config 更新是否可以獨立撤回？新的模型是否先在小比例 fleet 驗證，再逐步擴大？設備離線一個月後重新上線，要跨幾個版本升級？支援期結束後，使用者還能不能安全使用基本功能？

AI device 的 update architecture 最好在量產前就被當成產品需求，而不是出貨後才交給維運團隊補。

因為設備一旦大量存在於使用者手上，某些缺失的更新能力根本無法靠「下一版再做」完整補回來。

Privacy by design，第一步其實是畫清楚 data flow

「我們把 AI 放在 local，所以比較隱私」是一句太容易說，也太容易誤導的話。

On-device inference 的確可以讓某些原始資料不需要離開設備。但只要產品還有 telemetry、cloud sync、remote support、model evaluation、crash log 或 user account，privacy 問題就沒有消失。

歐盟執委會對 GDPR 的 data protection by design and by default 解釋很清楚：隱私保護應在處理活動的設計早期就納入，預設只處理目的所需的資料，並限制保存時間與可存取範圍。

對 PM 來說，最實際的起點不是文案，而是 data flow：

sensor 原始資料在哪裡產生？哪些 preprocessing 在 local 完成？送到 cloud 的是 raw data、embedding、metadata 還是 event？資料保存多久？誰可以讀？模型改善需要收集什麼？使用者可以關掉哪些資料路徑？關掉之後產品還剩哪些能力？

正確問題不是 local 或 cloud 哪個天生安全，而是每一段資料為什麼要移動，以及移動之後由誰負責。

這也和我前一篇談 AI 相機的事件 pipeline 是同一個邏輯。好的 edge filtering 不只是省頻寬，它也可能縮小真正需要被傳輸與保存的資料範圍。

AI device 的產品生命週期，開始比上市日更重要

2026 年更新的 NISTIR 8259 Rev. 1，把 IoT product manufacturer 的 cybersecurity 活動放進完整產品生命週期，涵蓋 pre-market、post-market、ongoing support 與 end-of-life，而不是只看出貨前是否通過測試。

這個方向並不只存在於技術指南。

歐盟 Cyber Resilience Act 已在 2024 年生效。歐盟執委會 2026 年 7 月公布最新實施 guidance，而 CRA 的特定資安通報義務將從 2026 年 9 月 11 日開始適用，主要義務則自 2027 年 12 月 11 日起適用。歐盟目前的 reporting guidance 也列出 actively exploited vulnerabilities 與 severe incidents 的通報時限。

這不是在這裡替任何產品做法規判定；實際適用範圍仍應由公司的 legal / compliance 團隊依產品、角色與市場確認。

但從產品管理角度，訊號已經很清楚：

Connected product 不能再把「出貨」當成責任終點。

如果一台 AI device 預計使用多年，那麼 model、firmware、vulnerability handling、cloud dependency、support period 與 end-of-life communication 都是產品的一部分。

這也是 AI hardware 和一般 web product 很大的結構差異。

Web service 可以持續把多數使用者帶到最新版。

Physical product 則會把過去幾年的硬體與軟體決策一起留在世界上。

M.K. Angle：PM 真正新增的能力，是管理「變動中的依賴」

把這些問題放在一起後，我不認為未來的 AI hardware PM 必須變成 firmware engineer、ML engineer 或 security engineer。

真正需要補上的，是跨層依賴與 change management 的能力。

以前 PM 常用 feature、timeline、cost、UX 來管理產品。

AI device 還要多管理幾個 contract：

capability contract：哪些硬體、軟體與環境下功能成立。

intelligence budget：可使用多少 latency、power、memory、thermal、bandwidth 與 cloud cost。

data contract：哪些資料在哪裡產生、處理、保存與離開設備。

behavior contract：模型更新後，哪些行為可以改、哪些不能改。

update contract：firmware、model、config 如何更新、驗證、分批、失敗與回復。

lifecycle contract：產品承諾支援多久，以及 end-of-life 後還剩什麼。

這些名稱是我的整理，不是既有標準。

但我認為它們比「這台設備用了哪一顆 AI chip」更接近未來產品經理真正需要掌握的問題。

因為 AI 進入實體產品之後，競爭不會只發生在模型 benchmark。

真正難複製的，會是誰能把 sensor、silicon、runtime、model、cloud、security、update 與 support period 組成一個多年仍然可靠的產品系統。

接下來值得觀察什麼

我會特別看四個方向。

第一，system model 會不會讓 AI capability 越來越像 OS 能力，而不是每個產品自己帶一個模型。

第二，model update 是否會逐漸和 firmware / app update 分離，形成獨立的 fleet rollout、observability 與 rollback 機制。Google Play for On-device AI 已經顯示「模型作為獨立交付資產」正在變得更具體，但 embedded device 是否會形成跨平台的成熟做法，仍值得觀察。

第三，產品團隊是否會建立更成熟的 AI regression observability，不只監看 crash，而是監看不同 model / hardware / firmware 組合下的行為漂移。

第四，法規與資安框架是否會讓 support period、vulnerability handling、updateability 與 end-of-life disclosure 進一步變成 connected product 的基本採購條件。

如果這些方向成立，未來 AI device 的產品規格書會越來越不像傳統消費電子規格表。

它會更像一份長期系統合約。

而產品經理的工作，也會從「定義這台機器現在能做什麼」，逐步變成「定義這套智慧在未來幾年如何安全地變」。

常見問題

AI 智慧設備的產品經理需要會寫模型嗎？

不一定。更重要的是能理解模型、runtime、硬體、sensor、cloud 與更新機制之間的依賴，並把這些限制轉成可驗證的產品需求。模型訓練仍然可以由 ML 團隊負責，但產品承諾不能只由模型 benchmark 決定。

為什麼模型版本要由 PM 關心？

因為模型更新可能改變輸出行為、效能需求或硬體相容性。Apple 已明確要求使用 Foundation Models 的開發者在新 system model 版本出現時重新測試 prompts，必要時維護 prompt version。只要 AI 行為是產品體驗的一部分，model version 就不只是 ML 團隊內部資訊。

AI model 可以和 firmware 分開更新嗎？

技術上可以有不同架構。Google Play for On-device AI 已能把自訂模型包作為獨立資產依不同 delivery mode 與 device targeting 配送；embedded product 則仍需依 runtime、security、storage、相容性與 rollback 能力設計。真正重要的是在量產前定義 model、firmware 與 config 的版本依賴與失敗回復路徑。

On-device AI 是否一定比 cloud AI 更安全？

不是。Local inference 可以減少某些原始資料上傳，但整體安全仍取決於 access control、software update、data retention、telemetry、cloud service 與 device security。正確問題不是 local 或 cloud 哪個天生安全，而是資料在哪裡流動，以及每一段路徑如何被保護。

AI device 最容易被低估的成本是什麼？

我認為不是單次 inference cost，而是 lifecycle cost：多硬體版本測試、模型 regression、OTA、fleet monitoring、資安修補、cloud dependency、客服與 end-of-life support。這是分析性判斷，不是通用的會計分類，但值得在產品立項時先估。