當碰撞已經不是最大問題:數據中心 BIM 的價值

過往在一般樓宇項目中,機電建模很多時只需要完成管道及設備的接駁,便可以滿足空間協調及碰撞檢查的基本要求。

然而,在數據中心項目中,尤其是採用模組化機電設備的項目,情況可能有所不同。

由於許多模組化機電設備在設計標準組件時,已經預先處理了大部分設備之間的空間關係及碰撞問題。因此,當這些標準組件應用於實際項目時,BIM 在傳統碰撞檢查方面的價值,可能不如一般樓宇項目般明顯。

這並不代表 BIM 在數據中心沒有價值。相反,這正好提醒我們:當 BIM 應用於數據中心領域時,需要重新思考它的核心價值。

相比單純檢查「有沒有碰撞」,數據中心更需要處理的是:

  • 某一項設備由哪一個系統供電?
  • 電力經過哪些設備後,最終到達哪一個數據大廳?
  • 某一設備的上游及下游設備是什麼?
  • 當其中一組設備停止運作時,備用系統能否承接服務?
  • 設計、施工、測試及運維團隊是否使用同一套資訊?

以數據中心的供電網絡為例,一個數據大廳通常不會只由一組獨立供電系統提供電力。由於數據中心需要維持高度的服務連續性,即使發生設備故障、維修或其他突發事件,關鍵服務仍不能輕易中斷,因此項目通常會採用 N+1 或 2N 等冗餘設計理念。

這亦令供電網絡的資訊關係變得非常複雜。

我們可能需要清楚知道:某一個數據大廳由哪些電源提供支援;每一個電源經過哪一台變壓器、發電機、UPS、開關櫃或其他配電設備;最終又連接到哪一個機櫃列或 IT 負載。

這些資訊並不只是幾何位置,而是設備之間的功能關係、供電路徑及系統邏輯。

如果這些資料只分散在不同的設計圖紙、設備表、試算表及測試文件中,當項目進入施工、測試或運維階段時,便很容易出現資料不一致、版本混亂,甚至無法追溯的情況。

透過 BIM 模型,我們可以利用房間屬性、空間屬性及設備物件屬性,將不同機電設備及系統之間的關係連結起來。

例如,模型中的設備不只是代表一個幾何物件,亦可以包含:

  • 系統分類;
  • 電力來源;
  • 上游設備及下游負載;
  • 安裝位置;
  • 設備編號;
  • 維修要求;
  • 相關文件及測試記錄。

當需要進行核查時,團隊可以從模型導出試算表,按照房間、系統、設備類型或供電路徑進行檢查。完成核查及修正後,再根據已確認的模型生成相關圖紙,從而減少圖紙、試算表及模型之間出現資料不一致的機會。

因此,BIM 在數據中心項目中的角色,未必只是傳統意義上的三維協調工具。

它更可以成為一個用來管理設備關係、追蹤系統邏輯及核查工程資料的平台。

對於數據中心而言,真正重要的問題可能不只是:

這些設備有沒有碰撞?

而是:

這些設備之間的關係是否正確?當系統出現異常時,我們能否迅速知道影響範圍及替代路徑?

這正是數據中心 BIM 應用與一般樓宇 BIM 應用之間的重要差異:由以幾何協調為主,逐步轉向以資料管理、系統追蹤及運維支援為核心。

下一篇會再談一個更值得思考的問題:當 AI 開始懂得自動建立三維模型,BIM 的價值會否因此下降?

如何利用AI把BIM服務成本下降至少三倍

假設一項BIM 服務整體費用是 10 元,本地建模人力大約佔 4 元,其餘 6 元來自BIM管理、協調、以及軟硬件成本。過去行內常見的降本方式有兩種:其一把建模外判到人力成本較低的地區(如國內,東南亞地區等等),能夠把人力從 4 元減到約 2 元;其二是利用Dynamo 及大型族庫自動化編程提高速度。前者的問題在於跨地域溝通與品質控制的成本會隨之上升,實際上多數情況人力成本只能降到約 2.5 元,也就是整體 10 元減到 8.5 元;後者則受限於需要少數高技術人才來維護工具,中小型項目和團隊往往無法持續投入,效果有限。

我想探討的,是如何透過 AI 治理,把「10 元的 BIM 服務」結構性地壓低到接近 3 元,而不是只靠削價或外判。

1)圖紙生成模型:降低基礎建模量,但受限於圖紙語義

首先是「圖紙生成模型」,目標是大幅降低「初始模型」的建模量。由 2D 平面圖自動生成 BIM 模型時,AI 同步完成兩類工作:一方面,按圖紙內容將各類物件歸入合適的類別,並大致確定其幾何尺寸、高度位置及形狀方向,快速搭建模型骨架;另一方面,將圖上的文字與表格資訊讀入為模型參數,例如門表中的防火級數、編號與用途等。這能顯著減少前期從零開始繪製的建模工作,以及中期因方案調整而需要的大量模型更新,等於把很大一部分「手畫骨架」的工序交給機器處理。按我的估算,這部分可為整體BIM服務節省約 2 元的成本。

2)設計參數優化:先減少翻模,建模才會真正變快

第二個關鍵是「設計參數優化」,雖然這項技術主要在節省設計方時間並釋放其人力資源,從而將資源用於更具策略性和價值驅動,但亦能配合模型以預設的規則提示、警告或限制設計師、繪圖員及建模員執行電腦指令。除了建模,核心還是優化設計端,避免重覆修改影響整體項目進度。設計反覆、方案未定、淨高和機電策略拖到很後期才確定,模型便需一再重建與大面積修補。AI 在這裡的角色,是在設計階段利用模型引入優化和約束。舉例來說,參考發展局技術通告中對 AI 應用的定位,把 行業慣例 與 過往項目經驗 整理為對應設計領域的 規範和標準,進而轉化成模型中的 參數建議 與 約束條件,通告提及應用到地基及擋土牆(Foundation and earth retaining structue)的設計,當設計較早確定,後續的圖紙生成、碰撞檢查與多專業協調,就不會陷入高頻率翻模與反覆改動。這部分主要減少的是重覆翻模和不必要的協調資源,預計可為整體BIM服務再節省約 1.5 元。

3)LLM自然語言建模及修改:把編程與Dynamo門檻移走

隨著雲端服務與大型語言模型的成熟,Revit 2027 的 MCP(Model Creation Platform)服務為建模自動化開啟新的可能。MCP 不再只是提供傳統的匯入/匯出與 API,而是把模型建立、配置與資料化流程抽象成可被程式與服務呼叫的雲端模組;當這些模組連結到像 Claude 這類的自然語言 AI 時,使用者可以用口語或書寫(自然語言)的方式描述設計意圖,由系統自動翻譯成具體的建模指令與 Revit 元件,實現快速、標準化產處理重複性的工作。

技術架構與資料流向可想像為三層:

第一層是使用者介面層,負責接收自然語言輸入(文字或語音)並蒐集專案上下文,如場地條件、BEP、設計規範和預設族群。此層的任務包括引導使用者提供必要資訊(透過對話式提示或表單)、輸入專案模板以減少歧義、以及顯示系統回饋和審核介面,讓設計師能在自動化建模前確認關鍵參數和接受或修正 AI 建議。介面同時處理多輪對話、顯示模型預覽與變更歷史,並在必要時要求使用者補充細節以提高後續轉譯準確度。在使用者介面層,使用者應注意輸入的清晰與完整:自然語言雖然靈活,但模糊或缺少關鍵條件會導致錯誤或不符合需求的建模結果,因此應優先使用預設模板、填寫必要專案上下文(場地、樓層高度、族群規範、BEP 要求等),並回應系統的補問。使用者在每次自動化生成前要審閱系統預覽與變更歷史,確認重要決策(如主要樓梯、井道位置、結構模數)由人員簽核後再進行批量套用,避免把設計判斷完全外包給 AI。

第二層是語意轉譯層,由 Claude 類的大型語言模型擔任核心,負責將使用者的自然語言意圖解析並轉為結構化、可驗證的建模指令(包含空間規格、構造約束、族群選擇與屬性表)。在解析過程中,此層會執行語意核對與缺漏提問、將模糊敘述映射到受控詞彙或 IDS(Information Delivery Specification),並回傳可供人審核的指令摘要。語意轉譯層亦應產生驗證規則檢查清單、優先建議與變更說明,確保輸出既可機器執行又能被專業人員理解與覆核。在語意轉譯層,使用者需瞭解 prompt 與對話結果並非最終模型,應把 Claude 的結構化指令當成「建模建議」,檢視映射結果是否符合團隊受控詞彙與 IDS 規範,並留意模型是否自動填補未說明的假設。當出現不合理的自動映射或缺失屬性時,使用者要編輯指令、補充細節或拒絕執行,並記錄重要討論與決議以作審計與未來優化之用。

第三層是 Revit 2027 MCP(Model Creation Platform)執行層,負責接收第二層的結構化指令並以雲端或本地建模引擎實際建立族群、設定參數、布置構件並執行自動化檢核(如碰撞檢查與屬性驗證)。此層會呼叫 Revit API 或 MCP 的雲端模組來產生模型、維護版本控制、匯出 IFC/本地檔案,並回傳模型狀態、錯誤與可視化結果供前端審核。執行層同時負責審計紀錄、權限控管與復原機制,確保每次自動化操作可追溯且能在人工介入下安全調整。在 Revit MCP 執行層,使用者必須重視版本管理、權限與驗證結果:每次自動化操作要有明確的版本標記與復原機制,只有具備適當權限的人才能觸發輸入性變更;收到執行回報後要檢查、屬性驗證與匯出檔案是否達到交付標準,並在發現重大偏差時復原或人工修正。此外,使用者需關注資料治理與安全性,避免在未加密或無明確許可下上傳敏感專案資料到第三方 LLM,並定期參與系統使用訓練以提升對自動化建模流程的理解與監控能力。

這裡省下了的修改模型參數的建模及協調資源,預計佔服務的2元。

4)法規自動合規檢查:把問題提前暴露,減少後期大改

合規問題若在後期才被發現,代價往往是大量翻模,推高建模成本。如果把法規要求轉成可執行的檢核規則,讓模型在早期就能自動掃描並提示風險,便能有效縮短設計周期。

為促進BIM在私人開發項目中的廣泛應用,屋宇署(BD)開發了一系列自動化審核工具,以簡化BIM格式數位圖面的準備和處理流程。這些BIM自動化審核工具也可作為設計審查工具,能夠節省人工審核/計算以及設計修改後的更新/複核所需的時間和人力,從而提高提交文件的品質和可靠性。針對GBP,BD開發了適用於兩款常用BIM軟體(REVIT和ArchiCAD)的插件工具,用於自動審核樓層面積資訊(BIM面積工具)及衛浴設備供應。除了自動合規檢查及修正,面對需要專業判斷的條文,整體審核必須保留人工確認。另外同時要有規則庫的版本管理,確保法規更新不會造成誤判或交付風險。這裡省下了的建模及協調資源,預計佔服務的1.5元。

總結來說,AI對建模成本的真正影響,不只是在建模速度,而是同時降低翻模、降低自動化門檻、把檢核前移。當設計更早確定、修改更可控、協調更有效率,建模才會從「成本」中釋放成為交付的「價值」。

「AI 投毒」時代的工程風險:

當人工智能遇上錯誤資料,為何 CDE 的記錄與複核更重要?

隨着人工智能在各行各業的應用愈來愈廣泛,工程及建造行業亦開始討論:未來是否可以把設計優化、工程量估算、施工方案比較、風險預測等工作,交由 AI 協助處理?從效率角度看,這幾乎是必然趨勢。但在這個過程中,一個較少被討論、卻極其關鍵的風險逐漸浮現——「AI 投毒」(data poisoning)。

所謂「AI 投毒」,是指有人有意識地向演算法可能採用的資料來源中,注入大量錯誤或誤導性的資訊,令訓練或推理過程受到污染,從而影響 AI 的輸出結果,包括其準確性與可信度。當前多數生成式 AI 模型主要基於網上公開資料進行訓練,本身就存在「資料真偽難以完全把關」的問題。如果再有人刻意在網絡上製造、擴散錯誤內容,相關模型在回答問題或給出建議時,就有機會被這些錯誤資訊拉偏。

對一般用戶而言,錯誤輸出可能只是帶來認知偏差或決策失誤;但對於工程及建造項目,如果未來越來越多決策依賴 AI 的建議,風險就會上升到成本、安全、合規甚至法律責任的層面。這時,問題便不再單純是「AI 準不準」,而是「在 AI 參與決策的環境下,我們如何確保所依賴的資訊可以被追溯、被複核、被糾正」。

這正是 Common Data Environment(CDE)和整體 Digital Information Management 架構的重要性所在。


一、AI 的優點與盲點:它依賴的不是「真相」,而是「資料分佈」

現代的人工智能演算法,本質上並不「知道真相」,而是從大量數據中學習統計分佈與模式,然後根據新輸入,預測最「合理」的輸出。如果訓練或參考的資料,以真實、可靠的專業內容為主,那麼 AI 給出的建議通常會相對接近現實;但如果某一段時間內,某些錯誤論述被反覆大量複製、引用與轉載,這些錯誤就有機會在統計上看起來「像是主流」,令模型傾向於模仿它們。

在工程領域,這一點尤其值得警惕。想像一下,如果某些不準確的設計細則、錯誤理解的條例、過分簡化的計算方法,在網上被大量轉貼甚至有意擴散,而 AI 模型在缺乏權威標準比對的情況下,只是「見得多就當是真」,那麼未來當我們向 AI 詢問設計建議、施工方法甚至合規判斷時,得到的答案很可能在關鍵細節上出現偏差。

因此,問題不僅在於「網上有錯誤資訊」,更在於:只要訓練和推理主要依賴公開網絡資料,AI 就無法完全避免被這些錯誤拉偏。


二、工程專案的額外風險

若把 AI 當成輔助工具,用於生成初步概念、整理文書或作為靈感來源,錯誤輸出的風險仍可由專業人員在審查時攔截。但當 AI 被更深入地嵌入工程項目,例如:

  • 協助決定某些施工方案的優先次序;
  • 針對 BIM 模型提出設計優化建議;
  • 根據歷史項目數據預測成本、工期或風險;
  • 參與建築條例合規檢查的初步篩查;

此時,如果模型內部引入了被「投毒」的錯誤模式,而團隊又缺乏足夠的追溯與複核機制,便可能在不自覺的情況下,逐步把錯誤引入真實項目決策當中。

換句話說,問題已經不止於「AI 有時講錯」,而是「錯誤被整合進工程項目的正式流程」,並有機會傳遞到圖紙、報表、施工指示,甚至最終建成的資產之中。如果沒有一套嚴謹的資訊管理架構,事後難以查明:哪一項決策出錯、錯在何處、錯誤源頭是否與某次 AI 建議有關、當時使用了哪些數據作為依據。

這正是為何在談 AI 之前,必須先談「CDE 與數碼資訊管理」。


三、CDE 的角色:把「用過的資料」變成可追溯、可複核的資產

從 CIC BIM 標準與發展局技術通告的角度看,CDE 的核心,不是某個品牌的平台,而是一套關於「資訊如何被儲存、分享、審批與追蹤」的規則。當我們考慮在工程項目中使用 AI 時,CDE 可以在風險管理上提供幾個關鍵支點。

首先,CDE 透過 WIP、SHARED、PUBLISHED、ARCHIVED 等狀態,為每一份文件、模型、報告建立清晰的生命週期與責任人。這意味着:

  • 任何被用作決策依據的資訊,理論上應處於 SHARED 或 PUBLISHED 狀態,並已有明確的審批紀錄;
  • 若有人試圖把「來歷不明」或「未經審核」的 AI 輸出直接引入正式流程,至少在 CDE 層面會留下痕跡,或在流程設計上被阻擋(例如不允許 WIP 資料直接成為正式交付物)。

其次,透過文件與模型的 Meta Data(例如 Status Code、Approval Code、Revision/Version Code),CDE 能讓管理人員在事後重建每個決策的資訊背景:當時參考了哪個版本的模型、哪份報告、由誰審批、是否有 AI 工具参与產生某些內容。如果 AI 參與過程被設計為必須在 CDE 作出登記或附註(例如在報告中紀錄某部分內容由 AI 協助生成),將來一旦發現問題,就能追溯和分析:AI 在哪個環節起了作用,錯誤是否與資料來源或演算法偏差有關。

最後,CDE 為「複核」提供基礎。當某一 AI 建議要被納入正式決策前,CDE 可以要求:

  • 相關輸出需附上來源說明(例如參考了哪些內部資料集,而不是只依賴外部網絡);
  • 需由具特定職能的人(例如 discipline lead 或 BIM Manager)在系統中完成審閱與批註;
  • 必要時,需要與既有標準、條例或內部指南作 cross-check,並把比對結果紀錄下來。

這種做法的意義在於:不讓 AI 的輸出直接「滑入」決策流程,而是把 AI 視為一個資料來源,需要經過既定的審查與複核程序,才能轉化為可被依賴的資訊。


四、從「盲信 AI」到「用 CDE 管理 AI 的輸入與輸出」

未來在工程及建造領域,人工智能的角色只會越來越重要,但同時,「AI 投毒」以及資料真偽難以完全掌握的問題也只會越來越難忽視。這並不意味著我們應該拒絕使用 AI,而是意味著:

  • 不能把 AI 當成「自帶真相的黑盒」,而必須把它視為一個需要被管理的資訊來源與分析工具;
  • 需要用 CDE 和數碼資訊管理機制,為 AI 的輸入與輸出建立邊界、審批流程與追溯紀錄。

對 BIM 經理、Digital Engineer 或任何負責數碼建造的專業人員而言,一個重要的能力,就是在項目中為 AI 的使用設定規則,例如:

  • 哪些決策可以接受 AI 作為輔助參考,哪些決策必須以人為主導;
  • AI 在生成建議或報告時,應盡量以內部經 CDE 管理的資料集為主要依據,而不是完全依賴外部網絡;
  • 所有被納入正式交付或合約層面的資訊,無論是否由 AI 生成,都必須通過 CDE 所定義的審批與版本控制流程。

在這樣的架構下,即使外部世界的資料環境受到「投毒」干擾,只要我們能確保:真正進入工程項目決策層的資訊,必須經過 CDE 的記錄與複核,整體風險便能被大幅降低。

簡單來說,AI 可以幫你更快「看見」更多可能,但 CDE 與資訊管理,是確保你最終採用的是「可被負責任地引用的那部份」。

解讀 IFC schema、廠商中立的重要性、實務挑戰與 buildingSMART《Global IFC Mandates(2024)》

IFC(Industry Foundation Classes)是 openBIM 的核心標準,作為 ISO 16739‑1 的國際資料 schema,它為建築與基礎設施領域提供一套開放且標準化的資料語言,讓不同軟體、能以共同語意交換資訊,並支援全生命週期的應用。IFC 的存在可避免資料被單一廠商鎖定,促進資料長期保存與再利用,並成為圖則法規審查、模型聯集、資產管理與智慧城巿應用的共同基底,這些都是促使政府與業主採用 IFC 的重要動機。

所謂 data schema,是一組定義物件類別、屬性、關係與資料型態的架構;IFC 就是為建築產業量身設計的 schema。當各 BIM 軟體各自採用不同的內部資料結構時,若沒有統一 schema,就會產生為每一對軟體建立專屬介面的 N×M 問題,成本極高。IFC 的價值在於,只要軟體能正確匯出與匯入 IFC,便能在多套系統間流通資料、或被自動化檢核工具讀取,從而降低整合成本並提升資料延續性,這一點在許多政府機構與大型業主的實務案例中均被強調,例如澳洲 Transport for NSW(TfNSW)採用 IFC 建立一致的驗證規則並避免重複處理,以及新加坡 CORENET X 要求採用 IFC‑SG 作為提交與自動檢核的基礎。

廠商中立的重要性

IFC 的廠商中立性對市場與政策環境具有深遠的影響。開放與中立的標準能避免特定軟體壟斷資料與流程,使採購與競標更以需求為主,從而促成更公平的競爭環境。廠商中立也鼓勵工具供應商專注功能創新,而非耗費大量資源在不同專屬轉接上,進而催生多元的生態系。政府若以 IFC 作為提交或驗證標準,則更容易推動整體產業的數位化與流程標準化,減少公共支出的浪費;buildingSMART 的多國案例亦說明,採用 IFC 能提升專案一致性並支援自動化審查,對公共與基礎建設領域尤為重要。

儘管如此,IFC 在實務推廣上仍面臨多項挑戰。首先是語意對映問題:不同 authoring tool 在物件類別、參數命名與族群邏輯上的差異,導致匯出 IFC 時常出現屬性遺失或被泛化為通用實體,這會影響下游應用的正確性。

其次是幾何與參數表現的損失,複雜族群或動態參數在轉檔後可能只剩幾何形狀而失去關聯性,降低可重用性與再編輯性。再者是版本與在地化管理的複雜性,IFC 隨時間擴展出多種版本與專業拓展,各地又衍生本地化延伸(如中國 CN‑IFC;新加坡 IFC‑SG),不同專案若使用不同版本或擴充,互通性將受到挑戰。還有,品質驗證工具與產業能力仍需提升;雖然可以建立驗證規則,但建立可靠的自動化檢核流程與培訓人力需投入時間與成本。

面對上述挑戰,實務上宜在專案早期明確定義交換需求與資料交付規範,將「需交付的屬性、精度與驗證標準」寫入 BEP(BIM Execution Plan),以避免模糊要求。建立自動化驗證流程來及早發現映射錯誤與屬性缺失,並優先使用 schema 原生類別與標準屬性,只有在經過管控的情況下才使用自訂擴充,同時以中央化詞彙或資料字典管理在地化需求。此外,投入教育訓練與與供應商協作也很關鍵,這包括提供匯出設定手冊、推動軟體廠商改善匯出品質,以及建立跨業社群以分享最佳實務。這些做法能顯著提高 IFC 在專案中的實用性與穩定性。

實務挑戰

關於 buildingSMART 出版的《Global IFC Mandates(2024 Edition)》,此文件彙整了來自多國制定 IFC 採用或要求的政策與實例,目的在說明 IFC 在全球推廣的現況、法規與業界實務。報告以簡短文字說明 IFC 為「標準化、開放、廠商中立」的數位描述格式,並指出各國透過強制或推薦使用 IFC 來鼓勵數位化應用。文件的各章分別回顧了不同國家或地區的實務做法與成效,例如澳洲 Transport for NSW 如何將 IFC 納入其 Digital Engineering Framework 以使驗證流程標準化;中國與地方如何採用 GB/T 與 CN‑IFC 形式,以及深圳在 2023 年強制要求部分建築專案提交 SZ‑IFC;丹麥規範如何要求 IFC 作為政府採購與設計提交格式;新加坡 則示範了如何把 IFC 作為法規提交與自動化檢核的基礎;西班牙與加泰隆尼亞也示範了公共採購中逐步要求 IFC 的做法;美國 則展示聯邦與專業組織如何把 IFC 納入設計交付與基礎設施資料交換建議。整份文件不僅列舉成功案例,亦強調配套的訓練、驗證規則及產官學合作是落地關鍵,並可作為各國制定政策或業主制定驗收要求的參考藍圖。

綜合而言,IFC 作為一個開放且標準化的 data schema,對於促成跨軟體互通、資料延續與政府治理具有關鍵價值。buildingSMART 的《Global IFC Mandates(2024)》提供了豐富的國際案例,說明了政策如何配合技術與產業實務以推動 IFC 的採用。要將 IFC 的潛力轉化為實際效益,除了技術面外,同樣需要在治理、驗證、版本管理與人才培育上同步投入,並透過產官學協作逐步建立可複製的落地流程與工具。