iT邦幫忙

2026 iThome 鐵人賽

DAY 30
0
AI Engineering

30 天打造 Edge AI Product:一個 PM 從 0 到 1 的 AI Engineering 實戰系列 第 30 篇

只有兩個人,我們真的做出 Edge AI Product!

  • 分享至 

  • xImage
  •  

30 天前,我開始寫這個系列時,想記錄的是一個 AI PM 如何從 0 到 1 打造 Edge AI Product。

但如果要問我,這 30 天最值得記錄的是什麼,我想不是某一個 Model,也不是 QCS6490 的 NPU 跑出了多少 FPS。

而是我們真的把 AI 帶進了一個實際的場景。

一、從一個想法,到四樓機房的實際驗證

我們最初面對的問題其實很單純。

機房需要安全監控與維運管理,但如果只靠人工巡檢或傳統影像監控,就很難直接從影像中判斷人員正在做什麼,以及是否出現異常行為。

我們希望 AI 不只是辨識畫面裡有沒有人,而是進一步理解場景、判斷事件,讓影像能真正協助現場管理。

於是,我們選擇四樓機房作為 PoC 場域,設計 AI Scenario Script,將想法轉換成可以實際執行與驗證的測試情境。

最後,我們完成了六項關鍵情境的驗證。

  • S1|入侵行為偵測: 入侵者開門進入機房。https://ithelp.ithome.com.tw/upload/images/20261013/20183425KggQkHMk0i.jpg
  • S2|Panel 操作偵測: 入侵者開門後觸碰操作面板。https://ithelp.ithome.com.tw/upload/images/20261013/20183425IDp5OTZjXG.jpg
  • S3|配電盤操作偵測: 入侵者觸碰配電盤或 Switchboard。https://ithelp.ithome.com.tw/upload/images/20261013/20183425LnHveaWDSJ.jpg
  • S4|未穿 Vest 偵測: 巡檢人員未穿著反光背心便進行設備操作。https://ithelp.ithome.com.tw/upload/images/20261013/201834254tFwEsLqry.jpg
  • S5|未戴 Helmet 偵測: 巡檢人員未戴安全帽便進行設備操作。https://ithelp.ithome.com.tw/upload/images/20261013/20183425smTR66ojv9.jpg
  • S6|正常巡檢辨識: 巡檢人員穿戴完整 PPE,依正常流程操作設備。https://ithelp.ithome.com.tw/upload/images/20261013/20183425HgUpOn3V7G.jpg

這六個情境不只是六段 Demo 影片,而是我們把機房的安全監控與維運需求,轉換成可重複執行的測試腳本,並透過實際場景確認系統的運作情況。

對我來說,這是很重要的一步。

因為 AI 不再只是簡報裡的一個模型,也不只是畫面上出現一個 Bounding Box,而是開始與具體的工作情境、事件判斷及管理需求連接起來。

二、這背後,不只是把 Model 跑起來

這個 PoC 真正花時間的地方,其實不只是 AI Detection。

我們必須把影像來源、Video Pipeline、Model Inference、NPU 加速、偵測條件、Geofence、Event Trigger,以及後續的應用流程串接起來。

在 Qualcomm QCS6490 上,我們也實際面對了 Model、Runtime、硬體加速與系統整合之間的各種問題。

我們曾經測到 CPU 上的 PyTorch 推論約 2.7 FPS,也驗證過 GStreamer 搭配 NPU 加速後,推論效能可以達到約 31 FPS。

但我們也逐漸理解,單次推論的 FPS 並不等於整個產品的 End-to-End 效能;Model 可以執行,也不代表整個系統就具備產品化所需的穩定性、相容性與維運能力。

這些經驗讓我明白,Edge AI 的挑戰從來不是單純地把 AI Model 放上設備。

真正的挑戰,是讓 AI、影像串流、硬體資源、應用程式與事件流程能夠協同運作。

而這些問題,必須在真正動手做之後,才會一個一個浮現。

三、只有一位 PM、一位工程師,我們怎麼完成這件事?

我們沒有一個龐大的 AI 團隊,也沒有無限的開發資源。

在這個階段,我必須同時思考客戶問題、Use Case、PRD、功能優先順序、技術可行性與後續產品化方向。

工程師則需要在有限的時間內,處理 Model 整合、Qualcomm 軟硬體環境、影像串流與應用開發。

我們沒有辦法一次完成所有 Model、所有硬體平台,也不可能在短短幾個月內,把完整的企業級管理與維運平台全部建好。

所以,我們先聚焦在一個明確的目標:

選擇一個真正的場景,把核心流程做出來,再用實際測試確認它是否可行。

這也是為什麼我會一直強調 Must Have、Should Have 與 Could Have。

小團隊的價值,不是什麼都做,而是知道現階段最應該先完成什麼。

對 PM 來說,最重要的工作之一,就是讓有限的工程資源,投入最能驗證產品價值的地方。

四、30 天之後,我對 Edge AI Product 有了不同的理解

一開始,我可能會把重點放在 AI Model 能不能跑、NPU 能不能加速,以及功能能不能完成。

但經過這個專案,我更清楚地看到,一個 Edge AI Product 至少需要跨過幾個階段:

從 Customer Problem 開始,定義 Use Case;從 PoC 驗證技術可行性;再把 Model、Runtime、Video Pipeline 與 Application 整合起來;接著思考 Model Registry、版本管理、部署、穩定性與客戶操作體驗。

這些工作並不是在 Demo 完成之後才突然出現。

它們其實從第一天開始,就應該是產品設計的一部分。

我們目前完成的是一個可以在實際場域驗證的 Edge AI PoC,以及六項機房巡檢關鍵情境的實測驗證。這不代表所有誤報率、長時間穩定性、不同設備相容性與企業級維運需求都已經完成驗證。

但我們已經不再只是討論「AI 能不能做到」。

我們有了真實的場景、可執行的測試腳本、可以展示與驗證的結果,也更清楚知道接下來要解決哪些問題。

這就是 PoC 的價值。

五、這不是終點,而是一個真正的開始

回頭看這 30 天,我最想感謝的,是一起把這個想法實際做出來的工程夥伴。

從最初的需求討論,到 Qualcomm QCS6490 上的 AI 整合,再到四樓機房的情境驗證,每一步都不是只靠一張架構圖就能完成的。

也因為親自走過這個過程,我更確定 AI PM 不只是負責定義需求、排定 Roadmap,或協調工程師完成工作。

我們還需要理解技術的限制,知道哪些事情值得先驗證,能夠在資源不足時做出取捨,也必須誠實地面對已經完成的成果與尚未解決的問題。

我們沒有用兩個人打造出一個無所不能的 AI 平台。

但我們用一位 PM、一位工程師,以及一片 Qualcomm QCS6490 開發板,把原本停留在想法裡的 Edge AI Use Case,變成了可以在真實場域執行、可以重複驗證,也能繼續往產品化發展的成果。

四樓機房的六個情境,對我而言不只是六項測試。

它們代表我們已經跨過了從想法到實作的第一道門檻。

接下來,還有更多需要驗證的效能、穩定性、操作體驗、部署與維運問題。但至少,我們已經知道下一步要往哪裡走。

30 天結束了。

Demo 跑起來了,PoC 也完成了場景驗證。

而真正的 Edge AI Product,正從這裡開始。


上一篇
Demo 可以跑,但不代表客戶會用?
系列文
30 天打造 Edge AI Product:一個 PM 從 0 到 1 的 AI Engineering 實戰 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言