樓宇大屏可以一層層走進去：Codex 接上 Blender 之後，三維專案的順序變了

2026 年 10 月 19 日，掘金用戶「夏天要喝冰可樂」發布一篇長文，記錄自己用 Codex 串起 Vue 3、Three.js 與 Blender MCP，做出一套以武漢光谷為產業背景的三維樓宇大屏。打開頁面先看到城市與湖泊，點擊示範園區後鏡頭向園區推進，再進入 A1 科創大廈，視角落到玻璃塔樓與退臺裙房；左側資訊也隨觀察尺度變化，從園區概況切換到樓宇檔案與空間利用。

這類「數位大屏」在前端圈並不新鮮，真正值得留意的是它的製作順序。過去做三維園區展示，設計、建模、前端互動多半是三批人接力；這個專案把 AI 放在流程中間，讓一個人可以同時推進概念設計與工程實作。

為什麼要分三層

作者設定的使用場景是招商展示與彙報。最初的結構只有「園區總覽、重點樓宇」兩級，後來往外補上城市區域，形成「城市區域、園區總覽、重點樓宇」三層瀏覽路徑。城市層交代尺度，湖泊、道路與連續街區構成背景；進入園區後八棟樓與中央公共空間成為主角；再進到 A1，建築立面與經營資訊佔據主要視野。

三層之間的物件一致性是硬約束：園區裡的 A1 與近景裡的 A1 必須是同一棟建築，點擊 C1 後浮卡與左側摘要要一起更新，城市頁面的園區指標也要與園區頁面一致。這些要求讓技術問題變得非常具體，模型怎麼命名、資料從哪裡來、三層要載入幾份模型、切換時相機怎麼動、卡片怎麼跟隨建築又不擋住導覽。

這與先前那篇Vue 加 Three.js 數字鄉村大屏的踩坑記碰到的問題高度重疊：視覺小樣、模型與業務資料的邊界設計，正是這類專案最容易失手的地方。

概念圖先做兩套，再收斂

正式建模之前，作者在 Codex 的工作流程裡整理業務內容與視覺要求，用圖像生成工具各生成兩張暗色夜景與淺色日景概念圖。A 方案是深色建築沙盤，深藍底色壓住背景，中央園區靠暖色窗光與青藍輪廓凸顯；B 方案是淺色日景，左側集中放資訊，右側留出完整的建築與景觀視野。

兩者放在天平上的差別很實際：A 用燈光把園區從夜景中提出來，B 用日光與留白展示建築；A 把資訊鋪在頂部與兩側，B 把閱讀集中到左欄。這會影響場景能佔多大畫面、使用者先看哪裡，也會影響後續的材質與燈光製作。最終沿淺色 B 方案深化。

概念圖好看，但資料會說謊

文中最有教訓價值的一段，是作者對第一輪生成圖的勘誤。總覽指標寫著八棟樓，場景中卻只有七個樓棟身分能被清楚核對；近景出現「建築高度：24 層」這樣欄位與單位錯配；部分產業比例由圖像生成過程自行補出，需要回到規劃中核對。

於是修訂工作變成：在規劃中固定八個樓宇 ID 與相對排布，調整取景讓八棟樓都能核對；把樓層數與面積、出租率的口徑分清楚；模組展示的是軟體研發等類別，標題就改成「入駐產業」；未定義的比例不直接照抄進資料。光線也改過一輪，淺色初稿的金黃陽光與高光偏強，後續向中性柔和的日光收斂，保留古銅色翼片與局部暖反射。近景裡一處與數值不符的比例條，改成出租率文字行，讓圖形表達和資料一致。

這正是 AI 生成概念圖的典型陷阱：氣氛先抓住眼睛，物件與數字約束卻不會自動守住。作者的做法是把「選風格」和「修內容」拆成兩個獨立步驟，這個分工值得任何用生成圖起步的專案借鑑。

AI 工具進入流程中段，而不只是起點

把這個專案放進更大的脈絡看，AI 工具在開發流程裡的位置正在移動。Codex 之類的代理工具已經從「幫你寫程式」延伸到串接 Blender 這類創作軟體，一行 /import 搬走全部設定那篇談過的遷移趨勢，在這裡換了個面向：競爭不再只是誰寫碼快，而是誰能讓設計、建模與前端互動在同一條工作流裡來回修改。

對做視覺化與前端工程的讀者，這個案例的可用判斷有三條。概念生成階段可以大膽讓 AI 出多套方向，但物件數量、欄位口徑與資料一致性要由人逐一核對，生成圖不會替你守規矩。分層結構要先定物件對應關係再動工，模型命名與資料來源是體驗的地基，不是畫面做完後再補的細節。最後，一個人加一套 AI 工作流，已經足以完成過去需要設計、建模、前端三個角色接力的專案，這對接案型開發者與小型團隊的報價結構與分工方式，會有實際影響。

作者也在文中標明，專案為演示作品，園區、樓宇位置與經營指標均為演示設定，不代表真實測繪或營運資料。這句聲明本身，就是 AI 時代做展示型專案該有的起手式。