▍老師雖然在分享沒有打開 repo，但她的工具一直在裡面
這一場跟上一場（家維老師）不一樣。家維老師是把 repo 裡的一條指令鏈從頭示範到尾；
劉可老師講的是 THINKLAB 自己事務所的建照面積系統——而雖然系統不在這個開源專案裡，你沒辦法照著跑。但這份筆記的應用目標是：我們把她在分享內容的每一個關鍵落地應用，幾乎都對應到她自己留在這個 repo 裡的工具。
2026 年 3 月到 5 月，她往 main 送進了 32 支 MCP 工具、15 個 Skill、4 份 Domain，
是「圖說管理」這一段目前貢獻量最大的人。她台上講的是為什麼要做，repo 裡放的是怎麼做。
她台上的痛點 你在 repo 裡可以直接練的 1 一案 60 幾筆建照，每棟只差 0.5 米面寬 /copy-sheets-cross-project、/floor-plan-from-template、/batch-apply-view-template2 面積分割圖要沿牆心線切 /auto-dimension、/unjoin-geometry3 外部算完的表格要貼回 Revit 建照圖說 /excel-to-legend4 「文字大小跑掉、跑出表格外」 /scale-drafting-width、/text-note-batch5 模型壓成 halftone，只檢查面積線 /view-category-visibility、/batch-material6 防呆：重複貼入的元件會害人誤判 /dedup-detail-elements這 6 條全部是她寫的，全部已經在 main。而在好學生筆記的再現段落的後面，我會把「這句話對應到哪一支工具」標出來。
雖然 REVIT_MCP 需要 Revit 才能跑 但就算你不是 Revit 使用者，這些 Skill 的
SKILL.md本身就很值得讀——它們記的是她應用上的知識累積，不是 API 說明書。更重要的機會可能是，你能將這相同的應用邏輯放進去不同的建築設計工具裡面使用。專案：https://github.com/shuotao/REVIT_MCP_study
她的 fork：lesleyliuke/REVIT_MCP_study＿
南台灣的連棟透天：一棟一照
我們是一家在高雄的小型事務所。我們事務所之前有四個人，今年學期畢業之後變成了六個人。然後我跟我先生莊子儀建築師，大概是四年之前回到台灣，然後開始做台灣的建築創作。
其實之前我們應該和在坐的建築師，都有一個超大型建築的夢想，但是回到台灣之後就會發現說，大部分時間都在處理數據計算跟法規檢討。
也因為有上面說的這個落差，那這張照片就是我們回台灣不久之後開始做的案子。我們第一個起步的類型是南台灣的連棟透天。那這個透天呢是有一個特性，就是它的建照數量非常的多。因為在南部大家比較喜歡買獨棟的房子，就是我不要跟人家是同一筆建照，這樣我之後想怎麼更改都可以。
那每一幢房子呢就是一筆建照，那通常開發商開發的數量都是二三十戶起跳的這種規模。所以這個數量的建案，對於我們的數據計算跟建照系統的上傳跟檢討造成了非常大的困擾。就像右下角寫的一樣，我們是一棟一照，不是一案一照，所以一個建案可能有六十幾筆建照。
▍「一棟一照」這件事，在 repo 裡是三支批次工具
60 幾筆建照、面寬只差 0.5 米——這正是她後來寫那批「跨專案／批次」工具的理由。一模一樣的圖，只有數字不同，人工複製一定會漏。
Skill 解決什麼 她的工具 /copy-sheets-cross-projectRevit 原生「Insert Views from File」不能匯入含 model view 的 sheet，這支用兩階段流程重建 read_source_file_sheets、copy_sheets_from_file、sync_sheet_parameters_from_source/floor-plan-from-template拿一個 FloorPlan 當範本，在多個 Level 上批次長出平面圖 create_floor_plans_from_template/batch-apply-view-template讓 60 幾筆建照的視圖樣式強制一致 batch_apply_view_template第一支特別值得看：它把 view 分成四級（自動建立／部分建立／只匹配／人工處理），
衝突一定要人確認才動。這是她在真實建案上被燙過才寫得出來的分級。
然後通常每一棟都會有不一樣，就是面寬可能在 5.35 米到 5.6 米之間，以 0.5 米為級距在變化。然後因為目前營建署在推行的那一個二維系統上傳，那屏東剛好就是試點之一，所以我們也必須要讓我們的系統可以適應這個二維建照上傳的系統。
先講前提是，那我為在座的如果不是建築專業的同學們介紹一下說：這個有多麻煩。就是我們從面積分割圖開始：首先我們要把這個面積的牆心線畫成一個分割圖，把它切分成好幾個方塊形狀，然後呢要把這個方塊形狀列成算式，寫成這個每一個面積分類的計算表。然後另外我們要把這個表上的所有數字，再謄到這一樣一份的概要表上面。那最後還要把所有的透天的數字結合成一個總表，那這個最後呢還要再把它上傳到二維系統上面。
▍第一步「把面積的牆心線畫成分割圖」——這步她也做了工具
她描述的流程第一關就是牆心線。這在 repo 裡有兩支對應的東西：
/auto-dimension→auto_dimension_walls，批次標牆尺寸，三種模式：
overall_bbox（外牆總尺寸）、chained（串接尺寸）、per_wall（逐道牆）。
分割圖要的通常是chained。
/unjoin-geometry→unjoin_element_joins、unjoin_column_joins，把牆柱的接合幾何解除。接合沒解，牆心線的判讀就會歪，這是就是我們透過每個人在與AI的對話過程中，記錄下來的反例。
在 Claude Code 裡直接說： 「用 chained 模式標這層樓的外牆尺寸」 「把這區的柱牆接合解除」順帶一提，
auto_dimension_walls是她 PR #30 裡最後一支才進 main 的工具，
中間隔了快三個月（PR #102 收編）。開源的節奏就是這樣。
所以如果我們以台積電的角度、加工的角度來思考的話，就是可能每一次我們的良率大概在 95 左右、95% 左右，那進行了四五次這樣的操作之後，我們的良率就會下降到 80% 以下，所以這是一個非常可怕的事情。
上一條路：Rhino.Inside Revit
那理解這樣一再重做的原因後，所以呢，之後我們就是有檢討自己的痛點之後，就對於這一個工作流程進行了一次認真的設計。那我們一開始走的路是用 Rhino.Inside Revit，我們寫了一個 Grasshopper 程序，讓它可以自動列這個計算式，然後再根據這個計算式算出它的面積。那有了這個程序之後，我們就信心滿滿的做了一些、一個左邊曲線形的這個建築，覺得這次一定沒問題了。對，但是我們發現在同事操作的過程中呢，他就忘記去按那個 Grasshopper 的那個更新按鈕，就是他面積先畫完之後他忘記去更新，所以這面積又錯了。
也就因為人為偏誤因素後，我們的應用就會變成：如果有 AI 之後，我們可以全盤的去顛覆我們的這個流程，讓模型一開始的數據直接一步一步的走到最後、最後的一個關鍵送審節點，中途都不要再有任何人工的出現。那這樣它的模型數據跟最後的送審數據，就會完全一模一樣。
自建資料庫系統：每個工具都有 MCP
順著這個「數據只走一條路」的想法，那後來就是在這個思路的基礎上呢，我們也開發了我們公司自己的一個資料庫系統，那這些資料庫系統都是我們平時可以應用到的各種小工具。我在這邊可以給大家稍微展示一下，這個就是我們在學會 MCP 跟 AI 之後呢，開始做的自己公司的資料庫系統。
先從最常用的講起：那最常用的就是這個。這個就是我們會請同事把圖說上傳到這個系統上面，然後一個是我跟莊子儀建築師，我們兩個會檢查；那另外我們也會請 AI 以 API 的形式介入這一個主要 review 的系統裡面去看這一份圖說，然後他就可以找到這一份圖說的前後不 match 的情況，並且在那個、這邊以一個 AI 結果、AI 檢核的結果來標記。
比如說像這個，我們這是一份變更設計的圖說。那我們第一次在建照階段，我們的圍牆長度寫的是 2830，那原本寫 2831，那新的時候它就變成了 2830，就是有這種微小的不 match 的情況也會被它發現。
所以其實江老師教的這個 MCP，對於我們來說，它不只是一個 Revit MCP，它其實是一個觀念：就是任何 AI 的工具、或者是我們自己開發的 APP，都可以擁有他自己的 MCP。比如說我們開發的一個這個 CodeWiki MCP，就是一個查法規的系統。那有了這個 MCP 之後呢，我們就可以把這個、就可以讓 Claude Chat 直接接入到這個 MCP 裡面，然後在它上面直接去問這個法規問題。
那有了這個法規問題之後，它就會跳入到我們的法規資料庫中，去查詢這個它對應的一些法規資訊，並且它最後會幫助我們整合成一個比較容易閱讀的 HTML 格式，它還會用圖示去標註說：這個法規具體是怎麼理解的。這個就是剛才介紹的這個法規系統。
為什麼把數據拿出模型外面算
介紹完法規系統，那我再介紹一下，就是剛剛江老師也提到說，為什麼我們會把這個模型的數據搬出去，然後在外面做一個 APP，然後再把這個 APP 算完的數據再套回 Revit 裡面。其中重要的原因是，在大量的使用MCP的應用下，我們發現 MCP 它不太擅長操控，而且會有控制上多做或少做的品質風險。
從左邊開始介紹：就是一個是版本與人員的控制，因為每次這個數據的匯出都會產生一個時間戳記還有匯出的人員，所以這個比較方便我們管理具體是哪一次的面積出錯了。然後另外就是我們不用浪費 MCP 接近 Revit 讀取數據的時間，那建模的人他的手就不用停下來。那另外的就是 MCP 不會去改到這個模型，所以會避免一些誤操作的出現。
同時，還有就是我們有一些同事，他們是沒有電腦上裝 Revit 的，所以他們用這個別的同事把數據導出來之後，他們可以直接在這個線上 APP 系統去閱讀這個面積，就不用再一台 Revit license。然後另外就是當 Revit 版本一直在更新的時候呢，他們也不用去擔心說 APP 就是會、也需要跟著同步更新。
面積系統怎麼運作
講完為什麼要拿出來算，那現在我再為大家展示一下，這個面積系統具體是怎麼運作的。那我們是先從這裡面匯入我們需要的面積數據，那從 Revit 中匯出數據之後呢，這個工具就會替他生成這一些面積的圖示，然後包括計算式跟分割線也都會畫好。那之後呢，我們就會批量的匯出 DXF 文件，那這個 DXF 文件之後是會重新再貼入 Revit 中。下一步就是會根據第一步產生的數字資訊，會形成對應的表格，它這個表格也是會在貼入 Revit 的建照圖說當中。那第三步呢，就是生成、生成這個我們需要的每一戶的造價計算。
▍「表格貼入 Revit 建照圖說」——這就是
/excel-to-legend她講的第二步（外部算完 → 生成表格 → 貼入 Revit），在 repo 裡是一支一站式指令：
/excel-to-legend→
import_excel_to_drafting_views它會把 Excel 的 worksheet 批次匯入 Revit Drafting View，而且忠實還原：
合併儲存格、表格框線、Excel 原始的 column/row 尺寸、長文字的 wrap 行為。
覆蓋舊 view 時還會自動把所有 sheet 上的 viewport 位置還原回去。⚠️ 不要先
read_excel_tables再串create_legends——那是被取代掉的舊多步驟模式。
她自己後來還特地送了一個 commit（6660626）改文件，強制 AI client 路由到一站式命令，
因為 AI 老是選錯路。她走的是 DXF、這支走的是 Excel，但要解的是同一件事：
外面算的數字，怎麼原封不動長進 Revit 的圖說裡。
這個視頻是跟剛剛展示的內容是一樣的。對，那這個就是 DXF 匯出的形式，之後我們會再把這個 DXF 用 MCP 的方式疊合到 Revit 裡面。那一整份的建照圖書也都是在 Revit 中完成的，然後直接印出來就是可以送審的文件。
▍「把 DXF Link 回去，這一步是 MCP 做的」
這句話在 Q&A 又被問了一次（賴冠成的提問）。repo 裡對應的是：
工具 用途 link_cad_to_view把單一 CAD/DXF 連結到指定 view link_cads_by_floor按樓層批次連結——60 幾筆建照要的是這支 座標怎麼對得上？她的答案是：Speckle 匯出時就帶著座標訊息，
所以 DXF 進 Revit 時座標是跟著走的，不是進去之後再對。
這是整條鏈能自動化的關鍵前提，不是細節。（這兩支不是她寫的，是專案既有工具。）
模型端的約定：C-檢測面積
把時間往回拉一點，那我們公司最開始的 Revit 系統是建置在新北市，有一個完整的 Revit 的送審系統。那那個時候它是通過「C-檢測面積」這個 Key Schedule 去控制說，哪些陽台面積要計容、哪些免計容，然後安全梯及不計容這樣子的。對，那同事會去勾這個對應的面積的參數，然後他是否需要計容、其實建築面積等等。
我們未來是希望說：這一套檢測面積的這一個數據，也作為一個資料庫去存在雲端。那假如說今天做的是集合住宅案子，它就可以套用這個 A 的計容規則方式；如果今天做另外一種 typology 的案子，它就可以套用另外一套計容方式。那這個就是我們開發的 MCP 程序，讓它可以把 DXF 重新疊回到這個 Revit Area Plan，然後我們會把這個模型設置成 halftone 的顯示模式。這樣子其實我們需要檢核的步驟，就只變成了說：這個面積線有沒有正確的疊在牆心線上，而不用檢查說這個數據到底有沒有 key 對。
▍halftone：把模型壓淡，只看那一根線
「我們會把這個模型設置成 halftone 的顯示模式，這樣需要檢核的步驟就只變成：
這個面積線有沒有正確疊在牆心線上。」這是整場分享裡最值得偷走的一招——把一個「要比對兩份數字」的問題，
改造成一個「用眼睛看兩根線有沒有重疊」的問題。人類做後者的良率遠高於前者。repo 裡對應的也是她的工具：
/view-category-visibility→set_category_visibility、hide_elements、unhide_elements——把干擾的類別整批關掉／壓淡
/batch-material→get_types_by_category、batch_set_material、assign_existing_material——複製原材質再改複本顏色，所以平面圖的切割填充圖案不會被破壞，事後也復原得回去
/batch-material那個「改複本、不改原件」的設計，就是為了這種「暫時改一下視覺、
待會要還原」的檢核情境。
走過的彎路
這邊跟大家分享一下，就是我們在開發過程中走過的彎路，希望可以讓大家也少走一些彎路。
第一個是，就是四捨五入，程式語言的這個 round（） 的並不是我們想像中的四捨五入，所以到在開發的時候，要特別跟他強調說：「我們要的就是四捨五入。」
▍彎路一：
round()不是四捨五入這個坑值得展開，因為它會默默給你錯的建照面積。
多數程式語言的
round()用的是銀行家捨入（round-half-even）：.5往最近的偶數靠。>>> round(0.5), round(1.5), round(2.5), round(3.5) (0, 2, 2, 4) # 不是 1, 2, 3, 4台灣建照面積要的是 ROUND_HALF_UP（逢五進位）。正確寫法：
from decimal import Decimal, ROUND_HALF_UP Decimal("2.5").quantize(Decimal("1"), rounding=ROUND_HALF_UP) # → 3而且一定要用
Decimal，不要用 float——0.1 + 0.2 != 0.3，
面積連加幾十次之後尾差會浮上來，剛好卡在小數點後兩位的送審欄位。她的建議「要特別跟 AI 強調我們要的就是四捨五入」是對的，但更保險的是
把這條寫進你的 domain 檔，讓每一次都自動生效，而不是每次重講一遍。
這個 repo 的domain/*.md就是幹這個用的。
第二個是談到精確與自洽的問題：那還有就是在送照的時候，主辦會去查看的是：面積計算式的結果跟你最後寫出來的數字是不是一致的，那主辦並看不到這個模型真正的幾何面積是多少。所以有的時候 Revit 給我們的幾何面積，並不是主辦想要看到的數字，所以這個時候我們就要嚴格要求 AI 說：它一定要得出這個計算式的結果，而不是去閱讀 Revit 裡面的幾何數字。
那還有就是，我們在繪製面積線的時候，有時候會發生這個面積線沒有交叉在一起的情況。那像這種情況來說，我們應該是取兩根線的延長線，把它交叉在一起。那可能 AI 在判讀的時候，它第一次會認為說：是需要直接連接這兩個點才是正確的面積線，這個是要格外讓他注意的。
當我們在外部 HTML 形成一個表格，然後會出成 DXF 再把它導回到 Revit 中之後呢，這個我們在 DXF 看到可能所有的文字都已經是在正確的表格範圍內，可是導進 Revit 之後，它的文字的大小會稍微出現一點差距，就是會導致它跑掉，有時候會跑出表格外面。所以這個也是要請 AI 它先分析好：說 DXF 中的文字大小跟 Revit 中的文字大小到底差多少，再把這一個倍數去算進它的表格裡面。那還有就是因為我們會避免說在 Revit 中再進行重新排版，所以我們一般都會先增加一個功能，就是讓使用者可以去調整這個表格欄位的大小，那這樣它匯入之後就不用再進行重新的排版。
▍彎路四：「文字跑出表格外」——她後來把這個做成了三支工具
DXF 裡文字明明在格子內，進 Revit 就跑掉。她的解法是先量出倍率再算進表格，
並且讓使用者能先調欄寬。而 repo 裡，這正是她 4 月連續送的那批工具：
Skill 工具 對應她講的哪一句 /scale-drafting-widthscale_drafting_view_width「讓使用者可以去調整這個表格欄位的大小」 同上 scale_drafting_view_height行高方向（ 2180212，隔幾天才補上）/text-note-batchmove_text_notes_in_views「它的文字會跑掉，有時候跑出表格外面」 /viewport-arrangementarrange_viewports_on_sheet、position_viewports_on_sheet、move_viewport_titles匯入後不想在 Revit 重新排版 看 commit 日期會發現一件有意思的事：
0af2dd7（4/11）一次送了move_text_notes_in_views+ 三個 Skill，兩天後2180212（4/13）才補上 Y 軸的行高縮放。
她是一邊做真案子一邊補工具的，不是先設計好才寫。
以上都是算得對不對的問題；那另外一個就是很重要的防呆機制。因為我們在做這個面積的部分還是會有需要人的參與，那人就是很有可能會出錯：比如說面積線畫歪了，比如說有的陽台線沒有畫到正確的陽台邊緣，那比如說它的面積的實際的幾何面積跟算式的面積差很多。那我們就增加了一些可以自動檢核的機制，去讓人在匯入 Revit 之前再 double check 一遍，自己的面積線有沒有畫對。那如果他的面積線在這個環節畫對的話，他後面的所有的數據計算就全部都會是正確的。那後來我們也是有了這個工具之後，就是可以大量的開發、可以大量的設計這種連棟型透天的案件。
▍防呆機制：
/dedup-detail-elements她說「人就是很有可能會出錯」，所以加了自動檢核讓人在匯入 Revit 前 double check。
repo 裡她留了一支同樣思路的工具：/dedup-detail-elements→
dedup_detail_elements_in_view找出視圖裡重複的 detail element（同 Type + 位置量化後相同）並刪掉。
兩個設計決定值得注意，都是「怕誤刪」的產物：1. 優先保留 Detail Group 內的副本，刪 group 外的——避免破壞共用的標準詳圖。
2. 一律先dryRun預覽 → 使用者確認 → 才真的刪。 邊界情形（全部都在 group、
或全部都不在）只列出來、不動手，交還給人決定。這跟她台上講的「讓犯錯的代價降到最小」是同一套價值觀：
不是不讓人犯錯，是讓錯誤在還便宜的時候被抓到。順帶一提，這是她 fork 裡最後一支送進來的工具（
0af9abe，5/7）。
給開發者的三條建議
從這些彎路回頭看，那這裡是給大家的三條建議。就是我們認為說，我們所有的計算全部都要回歸到原 Revit 模型，就是除此之外，再也不要有其他人工的 key 數字的步驟的介入，這樣之後才、這樣才能保證數據前後的一致性。那另外，外部系統就是只負責計算和檢核，它不能修改模型的匯出數據。那另外就是，我們接受大家都會犯錯，但是我們會透過優化這些機制，讓我們犯錯的代價降到最小。
這個是我們正在開發的一個坪效檢核系統，就是我們匯入 Revit 的數據之後呢，會把它自動做成一個可以出坪效報告、然後出每一戶的售價，這樣子去給業主簡報的一個線上工具。
那目前我們在開發的，就是把上述所有用到的數據都匯出到二維填表的線上系統中，然後直接接入營建署的那個系統去進行二維填表，就是整個步驟的最後一里路。那以上就是我這次分享的內容，謝謝大家。
問答：做了多久、誰在開發
碩濤：請問老師，你們系統到、從決定要做到上線是多久的時間？
劉可：好像是從去年開始，就是去年第一次開始用 MCP 的時候，就開始知道這個功能之後，就有很多的想像，就開始業餘時間都在做這個、搭建這個系統。大概可能是去年下半年快結束吧，11 月 12 月左右。
碩濤：那個 MCP 其實我跟徐灝大概知道的時間點是在前年、前年的 12 月開始。那正是在去年 7 月的時候，徐老師那邊就有開始在他的自己的地端的 agent，就把 MCP 放到他的 agent 裡面。我覺得要提醒大家一件事情是，我相信劉可老師現在給你們看到的這個東西是逐步迭代出來的。它一定是從去年、例如說 10 月 11 月的時候，開始可能會有剛開始的那一個面積的這件事情，然後呢不是一步到位，慢慢慢慢到現在這個樣子。
而且他現在正在增加他的第二個、最後這個二維填表的功能，我覺得這個是中間的過程裡面一定都會發生。所以大家不用想說要一步就到位，而是要慢慢慢慢的想你現在要用到的東西，然後去開發。
該下去做的是老闆，不是員工
碩濤：那老師另外一個問題是：老師你跟建築師兩個人，所以你們兩個人都下手用這個東西，這是你們兩個親自主導的東西對不對？還是你們的同事來做、你們來審核的？
劉可：是我們業餘時間做的，因為白天還是有很多案件要處理，下班之後做的。
碩濤：所以主要開發者是你跟、你跟莊建築師對不對？還是是你？
劉可：我跟莊建築師，我們每個人有不同的分工。他主要是做那個 NAS 上面的系統，我主要是在做 MCP。
碩濤：所以那你們家的員工用 AI 的成分是什麼？還是他們其實是享用你們的成果的人？
劉可：對，他們因為他們都非常忙，就是中堅力量，我們不希望說開發會、可能一個程序都要開發一兩天的時間，不希望他們耽誤本職工作。
碩濤：謝謝！
這個回答其實線上的、然後現場的，只要你跟我的層級是一樣的，例如說你是高階主管、你是老闆、你是建築師
『請不要、請不要叫你的員工過來學 AI 或者來開發 MCP。』
應該要做的事情是你自己要下去做，所以這從頭到尾都是我在講的：該上課的是建築師，該上課的是我們這些高階主管。然後呢，你應該要做的事情是，你認真把系統開發出來。我的那個好學生筆記裡面有一個之前有在分享，就是今年六月的時候、就是兩三個月前，我也去參加 GenAI 的年會，裡面有一個專門在做行銷的、裡面大部分都是老闆來說，裡面有一個叫在做行銷顧問的，他叫做多比、他叫做、反正他就是在做場內行銷的。真正在開發系統通通都是老闆。老闆每天都要用，而且老闆要成為他們員工的許願池。
＿
如果你想要看這場好學生筆記可以參考：
打造人人想當勇者的冒險者公會
傑哥 · 只要有人社群顧問 執行長
https://goodedunote.web.app/genai2026-day2/session-3.html （請自行來信索取閱讀密碼）
＿
就像你們現在在開發這個 MCP 一樣，你們在開 PR 或開 issue 的時候，你們就是對我許願，我就會幫你們把它做出來。對，老闆才知道痛點在哪裡，老闆才知道他經營狀況在哪，老闆才知道現在要填這個二維表單裡面他有 69 個。像剛剛大家看到 69 個，就是我們的老闆群呢就驚恐，就是他們就說：「天啊，這個數字也太恐怖了。」所以其實很辛苦，就是基本上是莊建築師跟劉可老師他們獨立開發出來的。
劉可：江老師我補充一點。最近因為暑期實習的期間，我們有讓實習生做一些 MCP 的練習，發現其實實習生在理解 MCP 的過程中，既可以學到建築知識，然後又可以不會佔用到本職員工工作的時間，又還是個蠻不錯的思路，跟大家分享。
碩濤：對，其實我會建議就是，老師在用我們這支 MCP，因為我們有特殊的開發邏輯，也就是說回應剛剛、就是我們上一位林老師，他的分享裡面剛剛講到 Domain 這個東西。每一個下面的同仁在跟這個 MCP、在製作的過程的討論中，其實有時候建築師或者是我們有經驗的人員介入的時候，他也可以幫助這個 Domain 的狀況更完整。
資料怎麼出模型：Speckle
Scott：請請教一下，那個你們把那個 Revit 說在外面處理，那個是什麼、存成 IFC 嗎？還是導出資料庫？但是那個 RVT 的資料的結構導出去以後是什麼？用這個東西導出去以後是個什麼樣的？你是用？
劉可：不是，我們是用一個叫做 Speckle 的系統。這個系統是開源的，然後他是一個國外在常常用在不同軟件之間交接內容的一個線上工具。
那我直接在螢幕上給大家說一下，就是他看你導出去的是什麼東西。你可以只導出房間，如果只是房間的話呢、room 的話，就是這樣子，就是一個塊狀的東西，然後也可以導出——
這個叫做 Speckle，就是左上角這個。
它是開源的，只是它目前更新的速度有點慢，所以它只適用於某些低版本的 Revit。所以它可以直接是 RVT 檔就直接變成現在這個樣子，這個是 RVT 的 room 導出來。
劉可：因為它可以選擇不同的 category，所以你每次不一定要全部導出所有的模型訊息，你可以只選擇 room 就會導出這個方塊。那如果你選擇的是建築模型的話，可能就會是我們這個吧，這個就是 Revit 的模型導出來，所以它裡面就會有它全部的參數訊息。那之後它可以跟別的軟件進行交接，比如說它導入 Rhino，它導入 Rhino 跟 SketchUp 之後，這個就會變成 Mesh。所以其實用這個，我們就可以做更完整的整合。
▍關於 Speckle：她台上講的那句「只適用於某些低版本的 Revit」，現在已經不成立了
這是需要更新的一則資訊，我另外整理了一份完整報告：
docs/Speckle.md。
她台上的說法 查證後的現況 Revit 版本 「更新速度有點慢，只適用於某些低版本」 現行 V3 連接器支援 Revit 2023／2024／2025／2026（Windows only）。2026 是官方已支援版本。 反而是 2022 已終止支援 世代 — Speckle 做過一次大改版：現在的叫 Next-Gen／V3，2025-06-01 起成為官方預設；舊的 legacy（v2）已於 2026-01-01 停止支援 她講的沒有錯，只是那是舊世代的狀況。 這也剛好說明為什麼網路上的 Speckle 教學
要特別看日期——2025 年 6 月之前的教學，講的多半是已經停止支援的那一代，
這是目前最容易踩的坑。至於她用 Speckle 做的事，報告第 5 節有一個可照做的最小範例
（把 Revit 模型／只挑 Room 發佈到 Speckle 專案，再在瀏覽器看）。
她示範的「只導出 room 就是一堆方塊、導出建築模型就帶全部參數」，
靠的是連接器可以選 category 發佈——這也是她能只把面積資料拿出模型外算的原因。
什麼留給人、什麼交給 AI
碩濤：老師我可以跟你看一下簡報的、剛剛上面有一頁，你就是把人在做檢核的那一邊的那個畫面嗎？就是你有一個流程，然後中間下面框一個就是在做 QC 的那個檢核的部分。你的簡報大概在上面、上面、上面的部分，在這邊，「AI 全自動運算」，對，剛剛下面這個。
我比較好奇的是，你什麼時候發現要把人抽出做檢核的部分？像你剛剛有重跑、核對跟抄寫的這些事情，那你是怎麼樣想這件事情？因為我昨天的那一個、那一個影片也是在告訴人家說，那這個很像你現在在做的事情。我想要聽一下你這樣子的一個流程跟概念的發想，以及你落實上去的真實步驟。
劉可：先講結論：因為我們的經驗是在數據方面，AI 的準確度是比人高非常多的。我們試過非常多的方法，比如說找外包團隊做建照，或者是訓練我們自己公司的人，或者是我跟子儀兩個人下去做，但這個準確率都會在一次一次的抄寫中變得越來越低。
就是像我剛才講的這個，因為建築設計是從前到後有非常多重複的數據，那如果用人工謄寫的方式，它這個數據每一次的良率是 95% 的話，乘個四五次就變成 80% 以下。所以我們後來也發現，就算結合 GH，還是會有人忘記去點 GH 按鈕這件事情的出現，而且新進同事進來培養的話，他出現這個的概率會更高，因為這個 SOP 還沒有被印刻在他的腦子中。
所以我們就決定說，這個步驟全部都不要人做，那 AI 他還可以一次一次的做版本記錄，他可以記住說：這個是 8 月 20 號由某某某同事上傳的數據。那如果這個數據有問題，他就去檢核那一天為什麼錯了，這樣子會更方便一些。
碩濤：那你留給人到底做了哪些事情？讓他去看計算表嗎？因為你現在計算表這個部分是，例如說你的匯出這個動作跟你的計算表這個動作，然後跟送審這些事情，都是真的人。就是應該這樣問：你在決定什麼東西要給人留下來做，以及什麼東西要給 AI 做，你的那一個、那條線跟那個尺是什麼？
劉可：人要做的是這個。就是當我們把這個面積圖全部在線上系統生成好之後，把它疊回到這個 Revit 模型之後，人要檢核說：這根線到底有沒有跟牆心線 match，然後這個上下陽台的對位關係是不是正確的。比如說上面這一塊板，它投影到樓下就應該是這條線，人要檢核說這個是不是正確的。那只要這一遍全部都做對的話，後面就都會是對的。
留給你的同仁做這件事情，是想要讓他學會這件事，在檢核這件事情上面，因為它涉及到蠻大成分在辨別建築裡面的法規檢討的這個人為判斷的部分。
碩濤：所以你把這塊留給人，因為事實上剛剛在做這個檢討，我也可以用所謂的圖形辨識去把它辨識出來，然後就再寫一個 QA 的部分就把它做掉。那我比較好奇是不是剛剛那個事情，你反而是想要讓同事學的，所以留下來？
劉可：這個其實是因為台灣的法規每一個城市的不太一樣，就尤其是比如說像這一邊過樑的計法，那個過樑到底計容不計容、計建蔽不計建蔽，在每一個城市、每一個主辦，他都會有不同的看法。所以我們如果要給 AI 寫這個規則的話，會變得太複雜。
碩濤：我們在上一個月的討論裡面有談論語意跟意義：只要是語意上面的偏差值越廣，你就越不能用 AI 去做。那當然因為現在 AI 越聰明的他越會通靈，那個原因是因為現在有越來越多人告訴自己怎麼樣做，但是實際上他就是會有幻覺。
有定義的東西，就像這樣子，這個面積可以疊完，他疊進去都 OK；但是到底要怎麼樣算，這個會跟每一個在地的人他的判斷、以及你跟你的承辦之間的關係，這個東西都要回到人。所以為什麼會去問老師說，剛剛那條線要怎麼樣去定義，我覺得這是重要的情況。
線上提問：DXF 疊回與檢核面積
賴冠成：怎麼樣把 DXF 疊回 Revit，做法是什麼？
劉可：把這個 DXF Link 回去，這一步是 MCP 做的，因為這數量實在太多了。
碩濤：但是，你的 DXF 你怎麼樣去做座標點的 fix？他怎麼知道你的座標在進 Revit 的時候會是對的？
劉可：因為剛剛給大家展示的那個線上的 Speckle 的那個系統，在匯出的時候他就有匯出座標訊息了，所以他的面積如果是從那個系統直接導入——就直接帶座標進來。
碩濤：老師另外想請教，如果檢核面積有錯誤的情況之下，下面的手動調整是要調整面積表，還是要改系統跑出來的正確呢？這個是賴冠成的問題。那老師你不知道怎麼說明這個狀況？
劉可：檢核面積錯誤有兩種情況。一個是面積線畫錯，那就是直接改模型中的面積線，然後重新上傳、重新匯出，再重新貼入就好了。那另外一種情況是，它是一個參數，也就是說它是可以被參數化的。可能我匯出的陽台，它如果有勾選計容的話，它在那個線上系統中它就會被讀到說：它要計入容積；如果這裡沒有被勾選到計容的話，它在線上系統就是不要計入容積。
所以如果我們手動把這個「C-檢測面積」這個表格改對的話，那線上系統反映出來的，就是它真實我們人類想要它計不計容的這個意圖。
碩濤：現在這一個樣板是大概十年前吧，就是新北市政府他們在做、所謂的黃裕舜建築師他開發出來的一個系統，所以大家可以去找。然後其實這個東西都存在，他很好找到。
▍那個樣板在哪裡下載
碩濤老師說的「很好找到」，就在新北市政府的 BIM 專區：
https://www.bim.ntpc.gov.tw/FileDown.aspx劉可老師整場在講的「C-檢測面積」Key Schedule，就是建立在這一份樣板的欄位約定上。
▍劉可老師在這個 repo 裡的完整戰績
我們非常感謝老師在這半年來的龐大貢獻，23 個 commit：
層 數量 已收編進 main MCP 工具 32 32／32（100%） Skill 16 新增 + 1 修改 15／17 Domain 4 新增 + 1 修改 4／5 目前尚未唯一沒收編 main的是一整條鏈：手稿向量化（
plan-sketch-to-dxf、sketch-to-revit、domain/sketch-color-convention.md與兩支 preview script）——彩色手繪平面圖用OpenCV 轉成 DXF，再建成 Revit 牆柱。粉色＝RC15 牆、藍色＝12cm 磚牆、黑點＝柱。這是正在整合的過程的，不是漏掉：它需要 Python OpenCV／numpy／skimage、一個 localhost node preview server，而且帶了一個
agents/openai.yaml的非 Claude 依賴，超出這個 repo「MCP 工具 + Claude skill」的執行面。想看的話它還在她 fork 上。▍如果你想自己練一遍
你是誰 從哪裡開始 需要什麼 只想學觀念 直接讀 .claude/skills/copy-sheets-cross-project/SKILL.md的四級分類，跟/dedup-detail-elements的 dryRun 設計。這兩份是「怎麼設計一個不會害死人的批次工具」的範本什麼都不用 手上有 Revit 和一套重複性高的圖 照上面表格的 6 條線走。建議順序： /view-category-visibility（最安全，只改顯示）→/excel-to-legend→/batch-apply-view-template→/copy-sheets-cross-project（最重，最後再碰）Windows + Revit 2022–2026 想做她那種「數據出模型外面算」的系統 先讀 docs/Speckle.md決定資料怎麼出去，再回來看她的工具怎麼把結果貼回圖說讀 domain/她的三條建議，其實可以壓成一句話：
所有計算回歸模型，外部系統只算不改，中間不准有人 key 數字。
這條規則比任何一支工具都重要——工具是為了讓這條規則有辦法被遵守。本文用到的連結
開源專案 https://github.com/shuotao/REVIT_MCP_study 她的 fork lesleyliuke/REVIT_MCP_study Speckle 研究報告 docs/Speckle.mdSpeckle 官方 speckle.systems ／ docs.speckle.systems _