為什麼台灣 Revit 建模到最後都沒辦法使用：命名標準

從事建築資訊模型（BIM）相關工作已經好些年，特別是在台灣這個市場，看過不少專案從一開始雄心壯志地導入 Revit，到最後卻變成一團亂，甚至連基本的模型都沒辦法好好用下去。每次跟業界朋友聊起來，大家都會搖頭嘆氣，說這模型到後面根本沒人敢碰，交出去的成果也只能勉強湊合。為什麼會這樣？我觀察下來，問題的核心其實出在一個很基礎、但又常被忽略的地方：命名標準。

在台灣，Revit 建模的習慣跟文化有它獨特的一面，但也因為這些習慣，讓我們在面對複雜專案時，總是卡在「最後一哩路」。這篇文章，我想從我看到的現象出發，探討為什麼命名標準會變成台灣 Revit 建模的致命傷。從什麼該命名、什麼不該命名，到哪些要考慮組織分工、哪些不用寫上工作人名，甚至哪些應該直接指定統一管理，我會帶著大家一步步檢討這些重點。當然，我不會直接把答案攤在桌上，而是希望讀完這篇，您會覺得這問題值得深思，甚至想找我跟我的團隊聊聊怎麼解——畢竟，這可是我們吃飯的專業！

—

什麼要命名？什麼不命名？

日本接觸 Revit 專案時，就被它那個乾淨的專案瀏覽器吸引住了。平面圖、立面圖、剖面圖、3D 視圖，還有圖紙、排程，全都分門別類地列在那邊，看起來井然有序。但沒過多久，我就發現這漂亮的表象底下藏著大麻煩。台灣的專案裡，很多人一開始建模時根本沒想過命名這回事。視圖名稱隨手填個「Plan 1」、「Section A」，圖紙編號亂丟個「A-1」、「Sheet 2」，等到專案大了，這些名稱就像脫韁野馬一樣亂跑。

你身邊一定有人或者那個人就是你，一看到這邊就說：
那是因為在日本啊……

為什麼要命名？我覺得這問題的答案很簡單：因為我們需要「找得到東西」。一個專案動輒幾十個視圖、上百張圖紙，如果名稱沒規矩，誰知道「Plan 1」是哪棟樓的哪一層？更別提後面還要交給別人用，像是顧問、業主，甚至下游的施工單位。命名就像給模型裡的東西貼標籤，沒標籤的東西遲早會變成垃圾堆裡的無名屍。

但什麼不該命名呢？我看過有些團隊走另一個極端，什麼都想命名，連模型裡的牆、門、窗的參數名稱都要加一堆前綴，結果名稱長到 Revit 都顯示不下了。這真的有必要嗎？我覺得不是。有些東西，比如 Revit 內建的系統族（牆、地板之類），它的型錄名稱當然得管，但細到每個參數欄位都硬要加規則，反而是自己找麻煩。台灣的習慣常常是「做越多越好」，但在命名上，這種心態有時候反而讓事情更亂。

—

多棟建築的挑戰：命名怎麼分？

我記得有一次參與一個社區開發案，裡面有五棟樓，A 棟、B 棟到 E 棟，每棟的功能還不一樣。專案一開始，大家信心滿滿地說要用 Revit 做出漂亮的模型。結果到了中期，我打開專案瀏覽器一看，傻眼了。所有的平面圖都叫「1F Plan」、「2F Plan」，圖紙編號也是「A-101」、「A-102」，完全看不出來是哪棟樓的。問負責的工程師，他們說：「反正瀏覽器有分類嘛，平面圖都在 Floor Plans 下面，不用特別寫吧？」我聽了只能苦笑。

這就是台灣 Revit 使用上的一個大盲點：我們太依賴軟體的預設功能，卻忘了專案規模一大，這些功能根本不夠用。多棟建築的專案，命名如果不把棟別分清楚，後面誰來接手都會崩潰。我試過跟團隊建議加個棟別識別，像是「A_1F」、「B_2F」之類的，但他們覺得這樣太麻煩，還說「反正模型分開就好」。問題是，模型真的能保證都分開嗎？還是說，到最後還是得硬著頭皮把所有東西塞進一個檔案，然後祈禱不要出錯？

這時候，我就開始想，命名到底要怎麼設計，才能讓多棟建築的專案不亂套？是每個視圖都要標棟別，還是有些東西可以共用？這問題不簡單，因為牽涉到團隊怎麼分工、怎麼管理檔案。我只能說，台灣的習慣常常是「先做了再說」，但這一招在多棟專案裡真的行不通。

—

組織分工：哪些要加進去？

再來談談多人協作，這也是台灣 Revit 建模常栽跟頭的地方。我看過不少專案，一個模型裡同時有五六個人在弄，有人負責建築、有人弄結構，還有人在搞機電。理論上，Revit 的工作集 (Worksets) 應該能幫忙分工，但實際上呢？大家還是習慣各做各的，視圖複製來複製去，結果同一個樓層的平面圖有三四個版本，名稱還都差不多，像「1F Plan」、「1F Plan Copy」、「1F Plan 2」。這種情況到後期，根本沒人知道哪個是真的。

我覺得，命名標準在這裡應該要扛起分工的責任。視圖名稱能不能直接告訴我，這是誰在弄的？還是說，現在做到什麼階段？台灣的團隊常常覺得「分工靠溝通就好」，但我得說，靠嘴巴講真的不夠，尤其專案越大，人越多，溝通成本越高。命名如果能把組織架構加進去，像建築組、結構組，或者製作中、待審查的狀態，至少能省下不少麻煩。

但問題又來了，真的要把每個工作人員的名字寫進去嗎？我看過有些專案試著這樣做，結果視圖名稱變成「A_1F_John」、「A_1F_Mary」，長得要命不說，還有一個大隱憂：人會換啊！今天 John 離職了，換 Peter 來接，這名稱是要改還是不改？改的話工作量超大，不改的話又沒意義。所以我開始懷疑，命名裡到底該不該寫人名？還是說，有些東西根本不用加作業者，直接指定一個單位管到底？

—

哪些不用寫人名？哪些要直接指定？

說到人名這件事，我有個很深的感觸。台灣的 BIM 團隊通常人不多，一個專案可能就五六個人，大家都覺得「反正知道誰在做什麼」，所以命名上很少考慮責任歸屬。但我發現，這種想法在小型專案還行，一旦碰到大案子，或者有外包、顧問進來，馬上就露餡。模型裡的視圖、圖紙亂七八糟，問誰做的，沒人答得出來。

我覺得，有些東西真的不用寫人名。比如說範圍框 (Scope Box)，這玩意兒是 3D 的，影響平面、立面、剖面，甚至跨樓層的連續性。如果每個人都能隨手加一個 Scope Box，名稱又是「Scope 1」、「Scope 2」，那模型範圍肯定亂掉。我就親眼看過一個專案，兩個工程師各弄一個 Scope Box，結果平面圖跟剖面對不上，主管氣到差點翻桌。這時候，我就想，Scope Box 這種東西，是不是應該直接指定由一個人——像是 BIM Manager——來統一管？其他人只能用，不能亂加？

還有圖紙編號，這也是我覺得沒必要加人名的地方。台灣的習慣是圖紙編號要跟交付順序對得上，像「A-101」、「A-102」，這是專案的骨幹，隨便讓人改編號或加名字，只會讓交圖時更麻煩。所以我開始覺得，有些東西與其讓大家自由發揮，不如一開始就鎖死，指定一個單位負責到底。

—

主管檢核的難題

再來講講主管的角色，這也是台灣 Revit 建模到最後沒辦法用的關鍵之一。我遇過不少專案，工程師忙著建模，畫了一堆視圖跟圖紙，但交給主管看時，主管完全抓不到重點。為什麼？因為命名沒幫到忙。視圖名稱還是那老樣子，「1F Plan」、「Section A」，主管得一個個打開來看，才能知道進度到哪、誰負責。這效率低得嚇人，更別提有些專案還有外包，主管根本不認識人，怎麼檢核？

我覺得，命名標準如果能幫主管省點力氣，事情會好辦很多。比如說，視圖名稱能不能直接告訴主管，這是製作中的，還是已經可以審了？或者能不能有個專屬的檢核視圖，讓主管一看就知道該從哪下手？台灣的習慣是「主管自己會找」，但我得說，這種想法在多人協作的專案裡真的太天真。命名如果不把檢核需求考慮進去，到最後還是得靠人工翻模型，浪費時間又容易出錯。

—

台灣習慣的根本問題

講到這裡，我忍不住想問：為什麼台灣的 Revit 建模總是到最後沒辦法用？從我觀察，問題出在我們的習慣太隨性，又太依賴軟體的預設功能。Revit 的專案瀏覽器很聰明，能把視圖分門別類，但我們卻忘了，這分類只是表面功夫，真正的管理還是得靠命名撐起來。多棟建築的專案不分棟別，多人協作不標分工，主管檢核沒指引，這些習慣加起來，讓模型變成一團亂麻。

我還發現，台灣的 BIM 團隊很喜歡「先做再改」。專案一開始沒定好命名規則，覺得「後面再整理就好」，但事實證明，到了後面根本沒時間改，也沒人想改。結果就是模型越做越大，問題越積越多，最後只能棄之可惜、用之無奈。這跟國外的做法差很遠，像歐美很多專案一開始就會把命名標準寫進 BIM Execution Plan (BEP)，每個人都照著走，亂不下去。

—

結語：一個值得深思的難題

寫到這裡，我其實沒打算給出完整的答案。為什麼？因為我知道，每個專案的情況都不一樣，沒有一套命名標準能通吃所有問題。但我希望這篇文章能讓您停下來想一想：您的 Revit 專案，是不是也卡在命名這一關？您有沒有碰過視圖找不到、圖紙搞亂、主管罵翻的狀況？如果有，那麼問題可能不在技術，而在我們怎麼用它。

什麼要命名？什麼不該命名？哪些要加組織分工？哪些不用寫人名？哪些該直接指定統一管理？這些問題，我在這篇文章裡丟了出來，但答案得看您的專案怎麼走。