團隊一起完成
平面圖辨識、需求輸入、家具配置、3D 檢視與成果簡報串接成完整流程。模型呼叫、前端與辨識由團隊分工完成。
團隊專案 · 七人畢業專題 01 / TL;DR
RoomPilot 室內配置助手
從平面圖與居住需求出發，協助使用者在 3D 場景裡查看家具配置，並檢查重疊、越界與動線問題。
我負責的部分
擔任組長，整理模組之間的資料契約、整合程式結構，並處理幾何驗證與 3D 操作效能。以下深入說明這些整合工作。
操作影片
跟著畫面走一遍
從上傳平面圖、確認格局，到查看與調整家具配置。
02 / WHY
配置看得見之後，還要確認能不能用
團隊想把平面圖與居住需求變成可以直接查看的空間配置，減少只靠文字與想像溝通的落差。目標是讓使用者先確認格局，再看家具擺放是否符合需求。
對我來說，難處在於把不同模組接成同一套系統：辨識結果、家具座標與 3D 畫面各自合理，不代表合起來就正確。單位、欄位與驗證責任需要先說清楚。
- 輸入可確認
- 辨識格局後先由使用者確認，避免把錯誤一路帶到配置。
- 配置可檢查
- 除了外觀，也檢查家具與房間的幾何關係。
- 調整有回饋
- 使用者操作家具後，畫面應能及時更新。
03 / ARCHITECTURE & CHOICES
架構與技術選型
從輸入到結果
由上往下沿藍色箭頭閱讀，右側是各階段的工作。小螢幕可在圖內左右滑動。
結構化契約，對齊模組邊界
不同模組用同一套欄位與座標約定溝通，單位轉換集中處理，避免每一層各猜一次。
取捨：契約修改需要同步更新呼叫端與測試，整合前的溝通成本會增加。
Shapely 檢查空間關係
將房間與家具轉成幾何物件，用明確規則檢查配置。模型提出的結果仍需要通過程式驗證。
取捨：幾何規則只能檢查已定義的條件，不能代替完整的室內設計判斷。
Three.js 資產快取與 LRU
家具操作重複使用模型及材質，房間外殼沒有改變時就沿用，減少重建與 shader 編譯。
取捨：快取需要明確的容量與釋放規則；冷啟動仍需要下載和首次編譯。
04 / DEEP DIVE
兩個實作差異與內容
A讓座標有一個共同的意思
多個模組各自換算單位，問題往往到 3D 畫面才被發現。先定義資料契約，再把轉換集中在邊界，幾何檢查才能比較同一個世界裡的物件。
做法差異 · A各層自行換算，畫面偏移時難以追查。
本專案採用 · B邊界統一座標；配置交由固定規則檢查。
# 示意：在模組邊界統一座標與單位
scene = normalize_to_scene_contract(payload)
# 驗證結果保留原因，供修正與介面顯示
violations = validate_geometry(scene)
if violations:
return needs_revision(scene, violations)
return accepted(scene)normalize 與 validate 代表責任分層，不是專案中的函式名稱。重點是先統一輸入，再檢查結果；有問題時保留可追查的原因。
B家具更新，不必每次重建整個房間
排查發現，等待不只來自下載：重建物件、材質及程序貼圖會觸發大量重複工作。因此改用資產範本快取，並以房間輸入的指紋判斷外殼是否需要重建。
做法差異 · A家具操作也清掉資產，重新建立場景內容。
本專案採用 · B沿用未改變的外殼及資產；超出容量再淘汰。
# 示意：房間幾何未變，不重跑外殼生成
if room_fingerprint != previous_fingerprint:
rebuild_room_shell()
# 快取擁有資產生命週期，移出場景不等於釋放
asset = asset_cache.get_or_load(asset_key)
update_furniture_instance(asset, transform)
asset_cache.evict_least_recently_used()資產可重用，不代表永遠不釋放。LRU 讓最近不用的資產先離開快取，避免操作越久記憶體越大。
05 / TROUBLESHOOTING
遇到的問題
畫面能顯示，契約卻不一致
發現：欄位命名或座標約定不一致，可能讓配置漏掉特定家具或造成偏移。
排查與處理：沿著輸入、轉換、驗證到渲染逐層對照；將家電命名不一致的情境加入契約測試，避免只靠目視驗收。
更換家具時等待很久
發現：單件操作也觸發資產釋放、shader 編譯與外殼重建。
排查與處理：拆開冷啟動與後續操作量測，保留可共用物件。再比對畫面像素與家具診斷數量，確認沒有用漏畫換取速度。
06 / IMPACT & TAKEAWAYS
成果
同一場景，家具操作的等待時間
長條共用 0–22 秒刻度，越短越好；冷啟動不在這次比較內。
以下為 2026 年 9 月整理的歷史開發紀錄；數據依各自的樣本與量測情境解讀，並非即時統計。
同一場景的家具操作
歷史 QA：林宅全室、14 件家具、有視窗的 Edge 瀏覽器。約縮短 98.5%；是特定操作的前後對照，不是整站載入速度。
每通道平均像素差
同組畫面比對，沒有像素差超過 8/255；14 件家具均可見、沒有失敗或替代模型。這支持該場景的畫面一致性。
當時仍存在的冷啟動
下載 GLB 與首次 shader 編譯屬另一個瓶頸。後續家具操作變快，不代表第一次開啟也同樣變快。
回顧
這次整合讓我更重視「快了之後，是否仍然正確」。如果重新安排，我會更早建立固定場景與契約測試，讓團隊在接線之前就能對照輸入與輸出。
07 / ROADMAP
未來展望
以下是依目前限制整理的後續方向，尚未完成，也尚未排定時程。
把冷啟動拆成可量測的階段
分別記錄模型下載、解析、貼圖與 shader 編譯時間，再判斷要採漸進載入、資產壓縮或預先編譯。
怎麼確認有改善：用同一裝置、同一場景區分首次與再次開啟，同時觀察首個可互動畫面及記憶體用量。
擴充配置的失敗案例
收集狹長房、門邊家具及多件物品互相遮擋的案例，將規則錯誤轉成可閱讀的原因。
怎麼確認有改善：驗收時不只看通過率，也要檢查漏報、誤報，以及使用者是否知道下一步怎麼改。
讓契約修改更容易協作
為核心輸入輸出增加版本與範例資料，建立辨識、配置、渲染可共用的最小測試場景。
怎麼確認有改善：每個模組都能獨立重現同一份資料；欄位改動時，及早指出受影響的介面。