從通用雲到場景落地：百度雲在智慧城市、工業質檢與自駕的實踐

「把 AI 用到產業裡」這句話，聽起來像一句廢話，做起來卻是完全不同的工程。難的從來不是模型好不好，而是場景的邊界在哪裡、誰來承擔出錯的後果。

百度雲這幾年在自駕、工業、能源與城市這四條線上留下不少公開資料。這篇不是在推薦誰，而是把它們的做法拆開來看：哪些是可以搬到自己案子裡的方法，哪些只是規模帶來的結果。

看一家公司的產業落地能力，別看它列了幾個案例，要看它有沒有把某個場景做成可以重複交付的東西。這是專案和產品的分界線。

落地難的不是模型，是場景邊界

通用雲賣的是算力與工具，客戶自己組裝。產業落地賣的是結果，供應商要對「這條產線的良率」或「這段路的通行」負責，責任邊界完全不同。

所以真正的門檻在前期：哪些情況機器判、哪些情況一定要人接手、判錯了誰承擔。這些講不清楚，模型再準也上不了線。

下面四條線的差別，其實就是它們各自怎麼處理這件事。

自駕：Apollo 把開放平台和自營服務分成兩條腿

百度的自駕佈局長期分成兩塊。一塊是 Apollo 開放平台，給開發者與合作夥伴用；另一塊是自營的自駕叫車服務，直接面向乘客營運。

依 2026 年 1 月 30 日的官方發布，Apollo 開放平台推出 11.0 版本，重點放在功能型無人車的工程可落地性，涵蓋配送、環衛清掃、安防巡檢與園區接駁等場景。

同場公布的生態規模為累積 26 萬名開發者與 240 多家生態夥伴。這類數字變動快，引用時請標時間點，或直接以官方最新公告為準。

工業：開物把質檢做成平台化產品

開物是百度智能雲的工業互聯網平台品牌，面向製造、能源與電力等產業。它的結構值得注意的地方，是把能力拆成幾個各自獨立的平台，而不是一包大專案。

• 工業視覺智能平台：處理產品外觀缺陷檢測這類看得見的問題
• 工業資料智能平台：做工藝參數優化與計畫排程這類看不見的問題
• 安全生產監測預警：把違規行為與異常狀態的辨識放進現場
• 能源管理：能耗管控與能效優化，通常是最容易算出投資回報的一塊

官方案例頁以整車外觀檢測為例，說明的是把人眼逐台目視改成產線上的即時視覺判讀。這裡真正的工程量不在模型，而在打光、取像位置與缺陷樣本的累積。

值得學的是拆法。把質檢與參數優化分開，等於承認這兩件事的資料來源、驗收方式與導入週期完全不同，不該綁在同一個合約裡談。

能源與政企：從單點工具走向流程嵌入

百度智能雲的智慧能源方案，官方是按能源的生產、運輸、交易、消費與監管幾個環節來切的。這種切法本身就是一種產業語言，不是技術語言。

常被提到的子場景包括電網安全巡檢、油氣智能巡檢與智慧供熱系統。共同點是都有既有的作業流程，AI 是嵌進去，不是取代它。

支撐這些場景的是幾個平台級產品：大模型服務與應用開發平台、AI 異構運算平台、物聯網平台與視覺大模型平台。方案的組裝邏輯比單一產品重要。

智慧城市：一圖統管的難點在資料治理

百度的智慧城市方案，官方描述的核心能力包括時空大數據引擎、一圖統管與城市大腦。聽起來很宏大，但拆開來其實是三件很土的事。

1. 把地圖、人口、車輛與物聯網等多源資料匯到同一個時空基準上
2. 讓不同局處的運行狀態顯示在同一張圖上，而不是各自的系統裡
3. 在圖之上再談分析、調度與指揮這些應用

第一步和第二步是治理問題，不是技術問題。資料權責、更新頻率與品質標準沒談清楚，第三步做得再漂亮也沒有人敢依它下決策。

這些做法可以怎麼借鏡

我自己整理完最大的感想是：這些案例的差異，多半不是模型能力的差異，而是對場景理解深度的差異。前者可以買，後者只能自己走過。

所以如果你正在評估要不要做一個產業 AI 專案，先別急著比平台。先找出那個邊界最清楚、最容易量測、失敗成本最低的單點，把它做完整。