為項目團隊而設的工地決策支援系統

想像一個 20 人建築及項目團隊，正在交付一個商業翻新項目。

項目已在工地進行。客戶想快速得到答案。承建商發來 RFI 和相片。設計團隊更新圖則。工程師就限制作出意見。項目經理追蹤工期風險。決定在會議、電郵、工地報告和正式登記冊之間流動。

團隊不需要軟件替他們作設計判斷。他們需要一個更好的方法，去準備圍繞那些判斷的背景。

這正是 Proximity 可以被調整成工地決策支援系統的地方。

系統的工作，是連接每個工地問題周邊的紀錄，讓建築師、工程師、項目經理和客戶可以用最新證據審閱。它不應批准設計變更、認證工程、指示承建商，或決定專業意見。

工作流程

這個工作流程，是每週工地決策審閱。

團隊需要一個可靠視圖，顯示：

• 未完成的 RFI，以及由誰負責回覆。
• 相關圖則修訂和模型參考。
• 工地相片和觀察。
• 檢查筆記或執漏事項。
• 客戶決定和限制。
• 對工期或成本的影響。
• 行動前仍需取得的批核。

目前常見的失效模式並不陌生。承建商問題引用了舊圖則。工地相片顯示的情況沒有進入正式紀錄。客戶偏好曾在會議討論，但沒有連到 RFI。設計回覆在團隊檢查結構、成本或批核影響之前已經開始草擬。

Proximity 會透過把證據串連起來，為這個工作流程建立基礎設施。

在建築環境項目中，背景斷裂很容易變成實際成本。項目團隊常常同時面對業主代表、顧問、總承建商、分判商和審批單位；每一方都有自己的紀錄、版本和時間壓力。若 RFI 回覆只看見問題本身，卻看不見最新圖則、會議決定、現場相片和成本影響，團隊就可能太快給出一個看似清楚、實際上未準備好的答案。

因此，工地決策支援不是要令 AI 成為設計師或項目經理，而是要令每次審閱更接近真實項目狀態。當問題被提出時，系統應幫助團隊看見它牽涉哪個位置、哪個專業範疇、哪個版本、哪個人，以及哪項批核仍未完成。

Proximity 會建立甚麼模型

在這個部署中，Proximity 會以「工地問題」作為核心對象。

經批准來源可能包括：

• 圖則和圖則登記冊。
• 可取得的 BIM 或模型元數據。
• RFI 和回覆。
• 工地相片和觀察。
• 會議筆記。
• 檢查和執漏紀錄。
• 工期里程碑。
• 變更紀錄。
• 客戶決定紀錄。
• 批核登記冊。

系統會把這些內容結構化成項目背景：

• 工地問題、位置、專業範疇和負責人。
• 相關圖則、修訂版和狀態。
• 來源相片、日期、作者和位置。
• 相關 RFI、變更、檢查或會議筆記。
• 所需審閱人。
• 未解問題和欠缺證據。
• 決策狀態：已準備、審閱中、已由人批准，或已關閉。

ISO 19650 是有用背景，因為它把建成資產資訊管理視為一項橫跨生命周期的紀律，涵蓋交換、記錄、版本管理和組織資訊。ISO 關於 BIM 的發布說明亦強調協作式資訊管理，而不只是建模。對 Proximity 來說，教訓很簡單：AI 支援需要項目資訊環境，而不是孤立碎片。

「工地問題」作為核心對象，比單純搜尋文件更有用。原因是同一個問題通常跨越多種紀錄：一張相片顯示現場情況，一封電郵提出限制，一份會議紀錄記下客戶偏好，一張修訂圖則改變可行方案，一個工期里程碑決定回覆急切程度。把這些材料放在同一個可審閱對象周圍，團隊才可以看到問題的依據和缺口。

這也讓版本和狀態更清楚。系統不應只說「找到相關圖則」，而應顯示圖則編號、修訂、日期和狀態；不應只顯示「有相片」，而應顯示拍攝日期、位置、作者和相關觀察；不應只顯示「需要批核」，而應顯示需要哪一類人審閱，以及目前是否只是草擬回覆。

系統會準備甚麼

工地決策審閱之前，Proximity 可以為每個未解問題準備一份資料包。

資料包可能包括：

• 問題的簡短描述。
• 當前圖則或模型參考。
• 相關相片和觀察。
• RFI 討論串摘要。
• 客戶或顧問意見。
• 可取得的工期或成本筆記。
• 欠缺證據。
• 所需的人手審閱人。
• 清楚標示供審閱的草擬回覆選項。

系統亦可以準備一個決策佇列：

• 可交設計團隊審閱。
• 需要工程師意見。
• 需要客戶確認。
• 需要成本審閱。
• 向承建商發出指示前需要正式批核。
• 欠最新圖則參考。

價值不在於 Proximity 知道設計答案。價值在於它幫助團隊看見答案依賴甚麼。

Centre for Digital Built Britain 的 Gemini Principles 以目的、信任和功能描述 digital twins。在本文中，實用的「孿生」不是資產的完美複製品，而是一個已連接的項目狀態，讓專業人士可以帶着最新證據和清楚邊界審閱工地問題。

資料包亦應把草擬內容和已批核內容分開。設計團隊可能想比較幾個回覆方向，但這些方向仍可能需要工程師、成本顧問、客戶或合約管理角度審閱。若系統把草擬選項寫得像正式指示，反而會增加風險。較好的做法，是把每個選項標明來源、假設、仍欠資料和需要誰確認，讓會議可以集中在真正的判斷上。

對項目經理而言，決策佇列的價值也不只是排序。它能顯示哪些問題因欠缺最新圖則而不能前進，哪些問題需要客戶確認後才可回覆承建商，哪些問題會影響工期或成本。這種透明度讓團隊避免把所有問題都當成同一種「待回覆」。

甚麼仍然由人負責

專業判斷仍然由人負責。

Proximity 不得決定設計意圖、批准變更、認證工程、指示承建商、接受工地情況、簽署合規，或傳達最終專業意見。這些責任仍屬於建築師、工程師、項目經理、客戶、認證人或其他具名專業人士。

人仍然負責：

• 設計判斷。
• 技術審閱。
• 客戶建議。
• 認證。
• 承建商指示。
• 變更批核。
• 回覆的最終措辭。
• 專業責任和問責。

系統準備背景。人作決定。

這條界線重要，因為建築環境工作涉及真實資產、合約、安全、成本和責任。NIST 的 AI Risk Management Framework 將可信 AI 視為涉及角色、責任和風險管理的治理問題。這正是這裏需要的姿態：工作流程應令責任更清楚，而不是更模糊。

所以產品設計應保留責任鏈。誰要求資料、誰審閱草稿、誰批准回覆、誰發出正式指示，都應清楚記錄。系統可以指出某項資料看來過時，但不能自行決定以新版本取代正式紀錄；可以提醒某個工地情況可能需要工程師輸入，但不能自行把它變成技術意見。

試點形態

一個實際試點，可以集中於一個進行中項目和一個重複審閱：影響設計協調的 RFI。

第一階段會梳理來源，並定義哪些登記冊具權威性。第二階段會為部分 RFI 建立工地問題資料包。第三階段會在每週審閱中使用 Proximity，並調整欠缺證據標示。

成功訊號包括：

• 更快準備工地決策會議。
• 較少根據過時圖則草擬回覆。
• 每個未解問題的負責人更清楚。
• 更容易看見影響工地工作的客戶決定。
• 專業審閱前有更一致的證據包。
• 會議中花在重新拼合背景的時間減少。

試點期間，團隊亦應留意系統是否真的改善了審閱質素，而不只是產生更多摘要。如果會議仍然花大量時間追問「這是哪一版圖則」、「相片是哪天拍的」、「客戶有沒有正式確認」，就代表模型仍未捕捉到足夠的項目狀態。成功的標誌，是專業人士能更快看見問題脈絡，然後用自己的責任和判斷作決定。

試點也應避免一開始就試圖覆蓋整個項目交付。RFI 設計協調是一個較好的窄範圍，因為它有清楚問題、來源、負責人、回覆和關閉狀態。當團隊證明系統能可靠連接 RFI、圖則、相片、會議決定和批核，再逐步擴展到變更、執漏或交付風險，會比一次過建立大型項目知識庫更穩陣。

團隊亦應定期檢查來源權威性。若正式登記冊、圖則平台和會議紀錄之間有衝突，系統應標示衝突，而不是自行選一個答案。工地決策需要清楚知道哪份紀錄可作依據，哪份只是一個待核實訊號。

這亦適用於相片、模型參考和會議紀錄。它們可以提供重要背景，但未必等同正式指示或批准。Proximity 應把它們放進同一個審閱包，讓專業人士看到關聯和缺口，而不是替團隊決定哪個來源勝出。

因此，成功的試點不是建立一個更大的項目資料庫，而是讓每次 RFI 或工地問題在回覆前都有更清楚的來源、版本、負責人、欠缺資料和審閱邊界。