背景與挑戰
設計師或屋主拿到一張平面圖，要花數小時試擺家具。生成式模型一秒能擺出一套佈局，但會重疊、擋門、動線不通，而且不會告訴你它錯了。技術上的挑戰有兩層：讓模型的產出能被機械地驗證；把六個人各自寫的子系統接成一個服務。
我負責的部分
七人團隊組長。負責跨模組介面契約、repo 重組、幾何規則層、3D 場景效能與最終整合。模型呼叫與前端頁面由其他組員負責。
FastAPI · PostgreSQL · Shapely · three.js · Anthropic SDK
成果與驗證
21.5s → 0.33s家具操作延遲，約 65 倍；每通道像素平均差 0.04/255
14 / 27main 上的合併 commit 由我送出，全隊最多
793筆燈具資料（8.95 GB 模型）保住而非刪除
69個 API 端點、115 支測試檔、8,557 筆家具型錄
以上為專案在 2026-09-01 至 09-07 整理的成果；測試集與實際使用情境不同，個別量測範圍見各項說明。
實作過程
展開技術選擇、遇到的問題與解法
- 把六個互不相容的子系統收斂成一個服務。訂跨模組介面契約與三條架構不變量（家具座標只有引擎能算、單位換算只在兩個邊界、座標轉換集中一處），主導 repo 重組。
- 寫規則層。11 項空間檢核與加權評分；診斷家電邊界失守（過濾清單 11 個名稱有 6 個對不上型錄）並補 12 支雙向契約測試。
- 擋下一次不可逆的資料刪除。AI 產的檢視報告說兩份 manifest 重複可刪一份；逐列比對三萬餘列後確認差額 793 筆燈具只存在母集合，改為重建索引並分桶標記待審。
- 3D 場景效能。找出 shader 每次重編的根因，做資產模板快取與 LRU；用像素比對證明畫面沒變。
延伸閱讀：這個專案的工程筆記
- 快了 65 倍，而且證明畫面沒變 每次家具操作要等 21.5 秒。根因不是程式慢，是 shader 每次整場重編。修完用像素比對證明畫面沒變。
- 六個人、五套系統、零次整合 專題進行到一半做全案盤點：沒有任何兩個人的程式碼互相 import 過。整合要靠先定契約，不是事後對齊。