分類: DEVB Technical Circular

近年發展局在推動建造業數碼轉型方面動作頻頻：先有 BIM、其後是 DWSS（Digital Works Supervision System）、MiC、高效建造機械人、AI 應用清單等。這一系列政策背後，都是圍繞同一個方向——把工程項目由「紙本＋口頭」管理，轉為「數據驅動＋平台協同」管理。

最新推出的「Co‑supervision Platform for Smart Construction Management」（下稱「聯合監督平台」），可以視為這條路上的另一個關鍵拼圖。它的重點不在於再多一個系統，而是：把業主、工程師／顧問、承建商、甚至分判和供應商之間，原本分散在不同系統甚至 WhatsApp、Email 的資訊流，盡量整合到一個可協同、可追蹤的平台之上，讓「監督」不再是單向，而是「共監督、共用數據」。

以下用分享和說明的角度，嘗試拆解這個平台在公共工程中的定位，以及它與 BIM 和 Digital Construction 的關係。

---

一、從「監督」到「共同監督」：平台要解決的核心問題是什麼？

傳統工地監督模式，多半是業主方或其工程師／顧問掌握主要資訊，承建商和分判提供資料、填表、交圖，再經人手審批和記錄。即使這幾年引入 DWSS，很多時候也只是把紙本的表格電子化，仍然存在幾個典型問題：資料分散在不同系統、格式不一；同一件事在多方之間重覆輸入；監督記錄與圖則／模型／現場實況之間難以在同一視窗看到；最重要的是，資訊流往往是「點對點」，每一方看到的只是自己的那一小塊。

「Co‑supervision」的概念，就是把這些資訊放回一個共同平台上，不再只是「某一方監督另一方」，而是所有持份者都在同一套數據和流程裏工作：同一張圖、同一份模型、同一條巡查紀錄、同一張相片和感測數據，讓決策和責任基於同一個「資訊事實」。

公共工程採納聯合監督平台，實際上是希望做到幾件事：其一，是讓政府部門、顧問和承建商對工程進度、安全表現、質量問題等，有同步和透明的視野；其二，是減少重覆填報和多頭紀錄，把巡查、檢查、試驗、RFI/AI 等資料盡量集中；其三，是為未來引入 AI、數據分析和數碼孿生打好基礎——沒有一個乾淨而共享的數據平台，這些高階應用都難以落實。

---

二、聯合監督平台與 DWSS、BIM 的關係：不是另起爐灶，而是「疊加一層協同」

很多同工第一個問題是：「我們已經用 DWSS 了，為什麼還需要另一個 Co‑supervision 平台？」要理解這點，可以把 DWSS 視為「工程日常操作和監督的數碼化工具」，而聯合監督平台則是「把這些日常操作數據拉進一個可以跨方協同、分析和可視化的平台」。

在理想情況下，DWSS 作為工地日常使用的系統，繼續負責表單、流程和文件管理，例如工地巡查紀錄、不合格項目（NCR）、試驗報告、檢驗批次、施工記錄等。聯合監督平台則透過接口（API）或定期同步的方式，接收 DWSS 中的核心數據，並把這些數據與 BIM 模型、CDE 中的設計／施工資料、甚至 IoT／影像系統整合，變成一個給多方查看和分析的「共用視圖」。

用一個簡單例子來說明：當監督人員在現場發現一個混凝土蜂窩，透過 DWSS 填寫紀錄、上載相片、標註位置。這條紀錄如果只是留在 DWSS 裏，之後要追蹤或跟設計資料比對，需要人手再查。但如果這條紀錄經由聯合監督平台，與 BIM 模型中的該構件、自動連結的圖則、施工進度資料等一並展示，業主方、顧問和承建商在同一個平台就可以看到：問題發生在哪個樓層、哪個構件、該位置原設計要求是甚麼、相關工序由哪支隊伍負責、之前有沒有類似情況、是否影響其他工序或安全。這種「多系統的疊加視圖」，正是聯合監督平台所要帶出的價值。

---

三、對 Digital Construction 的推動作用：把資訊「看得見、用得到」

從 Digital Construction 的角度，聯合監督平台有幾個關鍵作用。

第一，它把現場數據「看得見」。即使早已有 DWSS 和 IoT，很多時候數據仍然停留在「存在系統中」，但難以在合適的時間和介面呈現給合適的人。聯合監督平台如果設計得當，應該可以為不同角色（項目總監、駐地工程師、安全主任、分判管理）提供相對簡潔但關聯完整的儀表板，透過圖表、地圖、3D 視圖和列表，讓大家在沒有翻查大量原始紀錄的情況下，也能掌握重點問題和趨勢。

第二，它讓資訊「用得到」。單有視覺化不夠，關鍵是平台是否支援篩選、關聯分析和導出報告。例如，能否一鍵整合某段期間的安全事故、質量缺陷和進度偏差，按工區、分判商或工種分類？能否把 AI 或規則引擎引入，標示出「超過某個頻率的重複問題」，或根據過往資料預警高風險區域？這些都是「Smart Construction Management」的真正內涵，而聯合監督平台正是一個容器，讓這些功能有機會在公共工程中標準化和規模化。

第三，它為未來的 AI 及數碼孿生鋪路。發展局已經透過另一份 TC(W) 3/2026，要求在一定規模以上的工程採用 AI 技術，而該通告附帶的 AI Inventory，也包括從 DWSS 抽取資料、生成報告和分析的用例。聯合監督平台若能與這些 AI 用例緊密結合，會令 AI 不再只是「一個獨立小工具」，而是自然嵌入監督和管理流程的一部分。

---

四、對顧問與承建商的實際影響：不只是「多一個系統」

從實務的角度來看，採納聯合監督平台，對顧問和承建商最直接的影響，是在投標及執行階段，需要清楚回答幾個問題。

首先，你如何把現有的 DWSS、BIM、CDE、IoT 設施和內部系統與這個平台對接？這不只是技術上的 API 開發問題，還涉及資料結構、權限設定和更新頻率。例如，哪些表單或記錄會被同步到聯合監督平台？是即時同步還是按日批次？哪些欄位涉及個人資料或機密資訊，需要作匿名化或權限限制？

其次，你如何在內部工作流程中定義「誰在平台上做甚麼」？若平台只被視為「上面有人會自己去看」，最後多半會變成資訊孤島。相反，如果在 BEP 或項目執行計劃中，把某些定期匯報、聯合巡查、協調會議的前置工作，都設計成「先在聯合監督平台上準備和檢視資料」，那麼這個平台才會變成大家日常會主動使用的工具。

最後，顧問和承建商還要學會，如何在這樣的「共用數據空間」裏，既保持透明，又妥善管理責任和風險。例如，在平台上標示一項不合格項目或高風險情況，其實是一種「全體看見」的宣告，對於內部反應時間、糾正措施和溝通紀錄，都提出了更高要求。但換個角度看，這也是一個建立專業及信任的機會：願意早報早改、公開處理問題的團隊，更能向業主展示其數碼能力和管理成熟度。

---

五、總結：從「資訊上載」到「共同監督」，是一個心態上的轉變

發展局推動 Co‑supervision Platform for Smart Construction Management，本質上是希望把公共工程的監督工作，由「多方各自為政、資訊分散」的模式，提升至「多方在同一個數碼事實基線上，協同監督與管理」。

對 BIM 和 Digital Construction 社群來說，這不只是一個新平台，而是一個可以把多年來建立的數碼能力——BIM 模型、CDE、DWSS、IoT、AI——真的串連成一個連續工作流程的機會。關鍵不在於學會哪一個工具，而在於能否在新一輪公共工程投標及執行中，用更成熟的流程設計、責任分工和數據治理，說服別人：你不只是「懂得上載模型」，而是懂得設計整個「共同監督」的數碼環境。

發展局發出的 TC(W) 2/2026，把 MiC 在公共工程中的地位再往前一步：對特定類型的政府建築，MiC 不再只是「鼓勵採用」，而是要達到整體樓面面積不少於五成的採用率，並配合認可供應商名單、里程碑付款、精簡審批等一整套配套。

如果單從施工方法去看，這是一份關於「工廠預製＋現場組裝」的技術通告。但如果用 BIM 和 Digital Construction 的視角去看，其實這份通告也在傳遞另一個訊息：MiC 不是獨立於數碼建造之外的「另一個新技術」，而是迫使整個項目，由設計到施工管理，都要進入一個更高層次的數碼協同狀態。

一、MiC 的前提：標準化設計＋可機器讀取的資訊

通告對 MiC 的定義，是「在工廠預製獨立模組，運往工地組裝的建造方式」，並強調模組內已包含裝修、機電設備、家具等，基本上接近「完整房間」的水平。要做到這一點，從設計而言，建築物內的構件就不能以「逐層、逐間自由發揮」的傳統手工式及現場建造(in-situ)考量，而是需要把平面、結構、機電等，盡量標準化與模組化：同類空間要有高程度重複性，管線要走在可預計的位置，構件尺寸和節點要有重複使用的邏輯。

這一切，若仍然停留在 2D 圖則層面，很快就會因為複雜度而失控。相反，如果一開始就以 BIM 模型為核心，並配合參數化設計（parametric design）和生成式設計（generative design）去配置模組、統一構件規格、協調結構與機電，就會更容易在設計初期建立出一套「可重複、可製造、可審查」的數碼基礎。

簡而言之，MiC 要求背後，其實是一句：若沒有足夠好的 BIM 和數碼設計能力，要穩定落實 MiC 是非常困難的。

二、MiC 模組＝一個數碼／實體一體化的物件

在傳統建築採購流程中，無論是三維模型、批核圖則、上游供應商、施工方案，往往存在不少斷層。MiC 模組的出現，把這幾個環節「綑綁」在一起：一個模組，背後同時對應着 BIM 模型中的元件、工廠生產圖、材料清單、裝配指引、檢驗記錄、運輸和安裝計劃。

當通告引入 MiC 製造商認證（MiC‑MAS）和認可供應商名單時，本質上是在說：模組不是「臨時砌出來」的一坨東西，而是一個有完整、可追溯資料鏈的產品。這個產品自然就是 BIM 模型中的對應元件，加上 CDE 裏儲存的設計、製造、運輸、安裝和驗收資料。

對於 Digital Construction 的實踐者來說，MiC 是一個很好的切入點，把「模型」和「實物」真正連成一個閉環：

• 設計時，模組在 BIM 中被定義為有明確幾何、屬性和接口的物件。
• 工廠生產時，以同一份模型／數據作數控加工、材料配置和工序安排。
• 法定機構以模型生成的圖紙作為批核圖則的主要資料來源。
• 運輸與安裝時，BIM 模型為 4D 模擬提供基礎。
• 施工及竣工後，所有檢驗和維修紀錄，再回寫到 AIM（資產資訊模型）中。

這種「一件模組，一串數據」的模式，恰恰是數碼建造和未來 FM 數據治理所需要的。

三、里程碑付款與認可供應商：逼出更嚴謹的數據與流程管理

通告裏的里程碑付款機制和認可供應商名單，看似是財務和合約安排，其實也和數碼建造息息相關。

里程碑付款要求在特定階段認定工作成果，例如所有 MiC 圖則獲批、樣板通過、工廠預製完成、模組抵達工地、模組安裝完畢。要公平而客觀地認定這些「里程碑」，單靠口頭報告和零碎照片並不足夠，最好是有系統地透過 DWSS、CDE 及 BIM 模型，去記錄每個模組在不同階段的狀態。這自然催生出一套更正式的「狀態管理＋證據文件＋數據追蹤」流程，也就是在 CDE 裏一直強調的那種：WIP／SHARED／PUBLISHED／ARCHIVED 狀態清晰、Meta Data 定義完備的數碼協作環境。

另一方面，MiC‑MAS 認證要求工廠有嚴謹的 QA／QC 流程和紀錄，當政府接受這個認證作為 ISO 9001 等的替代方案，表示它相信這些資料管理和質量控制是可被第三方審核和信任的。要維持這樣的認證，工廠必須用比較系統化的方式管理設計變更、材料批次、工序檢驗等資料，這些資料很多時會透過 API 或標準格式，對接回項目的 BIM／CDE 平台。這種雙向數據流，其實正是 Digital Construction 一直想達到的狀態：不只是現場把訊息「手動抄回系統」，而是不同參與者的數碼系統之間，有實質、可機器讀取的資訊交換。

四、把 MiC 看成一個「Digital Construction 的放大器」

綜合來看，DEVB TC(W) 2/2026 並不只是一份施工方法技術通告，而是一個把 MiC、BIM 和 Digital Construction 鎖在一起的數碼城市大方向：

以「強制採用率」要求在設計層面真正認真地模組化和數碼化；
以「認證工廠＋認可供應商」把製造端的數據與質量監管納入制度；
以「里程碑付款」和「精簡審批」鼓勵用更嚴謹的數據和流程證明工作進度；
以 MiC 專責小組和高生產力建造督導委員會，減少純粹因為技術不熟悉而選擇「放棄」。

對於已經在 BIM 和數碼建造上行得比較前的團隊，這是一個把優勢放大的機會：不只是在做一個 MiC 項目，而是在建構一條由設計、預製、運輸到營運的完整數碼鏈。

對於仍在適應 BIM 和 CDE 的團隊，這份通告則是一個明確的訊號：僅僅「會畫 BIM 模型」已經不夠，下一步必須學會的是「如何把模型與真實建造方法、供應鏈、合約付款和質量保證連在一起」。在這個意義上，MiC 不是 BIM 的替代品，而是迫使 BIM 和 Digital Construction 真正走向實務核心的一個加速器。

2026 年 3 月 4 日，發展局發出《技術通告（工務）第 3/2026 號──Adoption of Artificial Intelligence (AI) Technology》。和早年推動 BIM 的技術通告相似，這份新通告標誌着另一個重要轉變：在一定規模以上的公務局工程項目，採用 AI 不再是「自願創新」，而是「政策要求」。

以下嘗試用分享的角度，為工程界同工整理這份通告的關鍵內容，並連繫到我們熟悉的設計、招標、施工流程，以及 BIM／CDE 的數碼化背景。。

---

一、政策框架簡述：誰需要用 AI，用在哪些範疇？

根據 TC(W) 3/2026，所有在 2026 年 6 月 1 日或之後招標、前期估算超過 1,500 萬港元的顧問合約，以及超過 3,000 萬港元的工程合約，在資本工程計劃之下都需要「採用 AI 技術」。通告本身沒有逐一列出要用哪種 AI，而是引用了一份獨立的《AI 應用清單》，把當前被視為「技術成熟、值得推廣」的 AI 用例逐項列出，並為每一項定下「背景說明、基線要求和成果交付」。

目前的清單只有三個案例，覆蓋了設計、招標文件處理，以及施工階段的 DWSS 數據使用，基本上已經打通了由設計到施工監督的三個代表性環節。

---

二、AI‑1：基礎及擋土結構的設計優化——從手動試算到自動生成與比較

第一個案例 AI‑1，是「Design Optimisation（by AI or RPA）」。清單一開始就指出，傳統設計工作很大程度上依賴手動反覆試算和規則式計算，在時間有限的情況下，只能評估少量設計方案，而且往往傾向保守或過度設計。AI 或機械流程自動化（RPA）的目的，就是把這一段「重覆、規則清晰、但非常花時間」的工作交給系統處理，讓設計人員把時間集中在策略性和價值導向的決策上。

在這一版（2026 年 3 月版本）的清單裏，發展局特別點名：地基（foundation）和挖掘擋土結構（earth retaining structure）的設計，採用 AI 或 RPA 進行設計優化。這意味著，在相關顧問合約中，不能只說「我們用 Excel／程式自動計算」了，而是要有明確的 generative 或 parametric 設計流程，能夠基於既有設計規範和標準，自動生成和評估多個設計選項，找出更接近合理利用率的方案，而不是一味用很保守的安全系數把所有不確定性「蓋過去」。

清單寫得很實在：設計優化工具必須內嵌適用的設計規範和標準；要透過生成式或參數化演算法去產生和評估設計方案；要能指出哪一些構件不符合要求，並提供解釋；亦要能與不同的設計軟件和平台互通，支援開放格式（例如 IFC），以便與 BIM 整合；最後還要能為設計相關的交付文件提供自動化的文檔和報告輔助。

最重要的是，AI‑1 規定顧問必須提交一份「Design Optimisation Report」，說明設計如何透過 AI 或自動化得到改善，包括節省了多少時間，以及設計在「利用率」（utilisation rate）上的提升。清單中甚至給出利用率的定義，例如在地基設計中，以實際設計負載與最大容許承載力的比例作為指標。這份報告並不是「可以有更好」，而是被列為顧問合約下的正式交付成果。

對設計顧問來說，這個案例的訊息很清楚：地基和擋土結構的設計，未來不能只交一套「結果」，還要交代設計空間是如何被 AI／RPA 探索過的，你在其中作出了什麼價值取捨，時間和材料利用上獲得了什麼實際優化。

---

三、AI‑2：標書文件檢查——用 RAG 幫你對照 PAH、通告和標準條款

第二個用例 AI‑2，是「Checking of Tender Document」。背景部份點出了一個大家都熟悉的痛點：當一個設計進入招標階段，要準備和檢查完整的標書文件，往往非常耗時，尤其是要逐條對照工程手冊（PAH）、技術通告、標準條款和功能性條文等。AI‑assistant 在這裏的角色，是把「對照標準文本、找出遺漏和非標準條文」這部分先做了，讓項目團隊可以把精力放在項目特定的條款和風險上。

清單的要求是，項目團隊需要建立一個檢查架構，實際上就是一個 Retrieval‑Augmented Generation（RAG）或類似的框架，背後接駁着一個 version‑controlled 的知識庫，裏面包括 PAH、備忘錄、技術通告、標準條款等文件，而且這個知識庫要能隨着新版本發佈、更新或撤銷而被維護。當用戶把標書草稿或某段條文輸入系統時，AI 助手必須能夠指出：這段內容是否遺漏了某些標準要求、在哪些地方用了非標準表述，並且提供連結回原始標準文件以便人工核對。

這個案例要求工具能夠在一些常用的格式之間導入和導出，例如在 Word 檔與系統之間往返。完成檢查後，標書文件需要附上一份簡要總結，說明 AI 助手在這次檢查中起了什麼作用，例如已經對照過哪些標準條文、哪些內容已確認符合，哪些地方是 AI 建議人手再審視。這份總結需提交給客戶方作最終審閱。

換句話說，AI‑2 的真正目標並不是「AI 自動寫標書」，而是讓 AI 幫你把「標準條文對照、遺漏檢查」這部分做好，並把過程透明化，讓決策者能夠更專注於做決定和風險判斷，而不是耗在對照工作上。

---

四、AI‑3：從 DWSS 抽取資訊與自動生成報告——現場數據不再「只存在系統裏」

第三個用例 AI‑3，針對的是「Information Retrieval and Reporting from Digital Works Supervision System (DWSS)」。DWSS 本身有三大核心功能：流程管理、智能施工管理和智能文件管理。通告形容，這些系統裏面存放了大量實時更新的數據和資訊，只是目前要從中找出有用內容，再整理成管理層看得懂的報表，往往仍需大量人手。

在這個場景下，AI 助手要做的，是透過類似 RAG 的框架，讓用戶能夠用自然語言或語意搜尋，跨越 DWSS 裏不同模組的資料庫（表格、紀錄、智慧工地數據、項目文件等），抽取出與問題相關的資訊，然後整理成簡潔而易於閱讀的摘要或表格，並提供回到原始記錄的連結以便核查。

清單亦要求，系統應該支援按照預設模板自動生成報告，例如進度報告等，並以 Word 等可編輯格式輸出。同時，介面需要在桌面和流動裝置都易於使用，尤其是要清楚顯示搜尋結果和來源。若查詢涉及受限或機密資料，系統亦要配合角色基礎的權限控制，確保只有獲授權的人可以看到相關內容。

同樣地，AI‑3 要求每個項目定期準備一份簡要說明，作為進度報告的附件，向客戶展示在日常運作中，這個「檢索與報告助理」到底被用來產生了哪些分析或報表，部分或全部由 AI 協助完成。

---

五、對工程界的實際意義：AI＋BIM＋DWSS，一條完整的數碼鏈

把三個案例放在一起看，其實可以很清楚看到：在設計階段，用 AI 協助 design optimisation，減少過度保守和重覆試算；在招標階段，用 AI 幫忙檢查標書與標準條文的一致性；在施工監督階段，則用 AI 在 DWSS 裏幫你把「海量數據」變成「能講故事的報告」。

對設計顧問來說，這要求你重新思考設計流程：不再只有「人工計設計、計完出圖」，而是要在流程中加入一個 AI／RPA 的 design loop，然後用報告說明 AI 如何幫你更接近合理利用率，節省時間和材料。

對工程團隊和監督人員來說，這要求你開始把 DWSS 當成一個真正的「數據資產庫」，而不只是「交差用的電子表格平台」。若要把 AI‑3 用好，你需要先確保 DWSS 中的數據質量、結構和命名有一定標準，否則 AI 只會把雜亂資料「包裝」成看起來漂亮的表格，而不會帶來真正洞見。

對於整個行業來說，最重要的訊號可能是：政府不再只是鼓勵個別項目試用 AI，而是開始透過技術通告和 Inventory，把具體案例制度化，並要求在招標和合約中清楚交代 AI 的採用和成效。

在這個背景下，工程界的下一步，不只是「買幾套 AI 工具」那麼簡單，而是要把 AI 視為 BIM、CDE、DWSS 之上的一層新能力，並且在流程設計、責任分工、數據治理和報告機制上，用同樣嚴謹的態度去規劃和實踐。