OpenHome3D 實測：一張戶型圖真的能秒變 3D 家居場景嗎？五句網傳宣稱逐一驗證

30 秒版

網路上流傳的五句宣稱，我們一句一句實測後的判定：

| 宣稱 | 判定 |

|---|---|

| 一張戶型圖丟進去直接變 3D 家居場景 | 屬實，但有前提 |

| 337 種免費家具 | 屬實，但要看組成 |

| 用 Codex AI 變寫實效果圖 | 誇大 |

| 完全開源免費 | 部分屬實 |

| 一人公司做室內設計必收 | 不成立 |

先講安裝門檻：這不是打開網頁就能用的服務。手動 3D 編輯器免費開箱即用，但兩個 AI 功能（平面圖辨識、寫實重繪）需要你自己在本機裝 Node、跑 dev server、裝好 Codex CLI（版本 ≥0.153.1），而且吃的是你自己的 ChatGPT 方案額度，不是 OpenHome3D 出的。

它是什麼

OpenHome3D 是 GitHub 上的開源專案（yuyou-dev/OpenHome3D，MIT 授權，⭐122），一個卡通 cel-shaded 風格的瀏覽器 3D 家居設計器：套模板、拖拉家具、切換軸測／透視視角、匯出自家格式的專案檔。官方線上 demo 是純靜態部署，只有手動編輯器，沒有 AI 功能——平面圖辨識與寫實重繪這兩個賣點，都要靠你自己跑本機 dev server、透過 Vite middleware 呼叫你自己裝的 Codex CLI 才能用。

我們怎麼測

測試環境：Apple M4 Pro / 64GB / macOS 26.2，Node v24.13.1、npm 11.8.0，用 headless Chromium（Playwright，1440×900）操作，測的是 2026-09-05 的 commit（cb52afc0）。git clone + npm ci（409 個套件、3.5 秒，npm cache 已熱）+ npm run dev（Vite 88–345ms 起服務），過程順利。首載（dev server，未打包）load 事件 0.27–0.28 秒、networkidle 2.8–3.4 秒、畫面穩定 5.7–7.3 秒，三次重跑 console 零 error。加減家具、切換投影、匯出專案檔（.home3d 8,798 bytes、layout.json 14,992 bytes）都正常。

有一個地雷值得先說：套模板要按兩下——第一下按鈕會變成「確認覆蓋？」，3 秒內沒按第二下就沒生效。我們第一輪只按一下，拿到「2BR 只有一個客廳」的假結果，回頭查程式碼才發現是兩段式確認。測到反直覺的結果，先懷疑自己的操作，不要急著下結論。

平面圖辨識：這是它最讓我們意外的部分

我們沒有用任何現成的戶型圖檔案，而是自己用 Python PIL 畫了一張 1200×900 的合成戶型圖（客廳／主臥／次臥／廚房／衛浴／陽台，含 mm 標註、100 px/m 比例），丟進「導入戶型圖」功能：

• 耗時 93.2 秒
• 辨識出 6 個空間、19 道牆、10 個開口、0 件家具（圖上本來就沒畫家具符號，判斷正確）
• 比例辨識為 0.01 公尺/像素——跟我們畫圖的 100 px/m 完全對上
• 9 條尺寸標註全部讀對、全部標記為已使用，沒有任何一條被判為衝突

面積誤差（辨識值 vs. 我們用牆內面反算的理論淨面積）：

| 空間 | 理論淨面積 | 辨識值 | 誤差 |

|---|---|---|---|

| 主臥 | 13.10 m² | 13.14 m² | +0.3% |

| 次臥 | 13.47 m² | 13.47 m² | 0% |

| 廚房 | 7.16 m² | 7.16 m² | 0% |

| 衛浴 | 7.58 m² | 7.58 m² | 0% |

| 客廳 | 21.85 m² | 21.85 m² | 0% |

| 陽台 | 6.49 m² | 6.43 m² | −0.9% |

開口辨識也全中：4 扇窗（辨識出 1.61／1.61／1.21／0.81 m，我們畫的是 1.6／1.6／1.2／0.8 m）、4 扇門（辨識 0.81／0.91／0.81／0.90 m，我們畫 0.8／0.9／0.8／0.9 m），廚房那個沒畫門片的開口被正確判成「open 通道」，陽台那個推拉符號被正確判成「sliding 推拉門 1.81 m」（我們畫的是 1.8 m）。牆厚同樣對得上：辨識出外牆 0.16 m、隔間 0.10 m，跟我們畫的 16 px／10 px 一致。匯入後 App 自己列的「標註 vs 場景」對照表，最大偏差只有 1 公分。

它也沒有假裝準：辨識完自動列出 9 條 warning，包括「raster 追圖是近似值，不構成 CAD 測量精度」「牆高 2.8 m 是估的」「窗台 0.9 m／窗高 1.4 m 是假設的」，甚至主動指出我們自己標的面積是按牆體中心線算的、不是淨面積——這點反而是它對、我們的標註偏粗。

⚠️ 但這是我們自己畫的合成圖：正交、線寬一致、標註工整、沒有家具符號、沒有填充線、沒有掃描雜訊。真實的建商平面圖或掃描件難度完全不同，這組數字不能外推到真實圖檔。要下「它看得懂真實戶型圖」的結論，需要另外拿真實圖再測一輪，我們這次沒有做。

匯入後的自動擺家具明顯比套用模板路徑弱：面板列出「主臥未匹配到識別家具，已生成可用擺放」，六個空間全部走了 fallback 擺法，結果是辨識出來最大的客廳幾乎空著，只有茶几、盆栽、幾張矮凳，沒有沙發。辨識準不等於擺得好。

寫實重繪：跑得起來，但「寫實」兩字對不上產出

這個功能走的路徑是：瀏覽器 → Vite middleware /api/ai/render → 呼叫 codex exec --model gpt-6-astra（reasoning 設為 high）→ 由它呼叫圖片生成工具出圖，設定寫死在專案的 scripts/ai-config.mjs。預設提示詞本身就要求「寫實攝影風格＋自然日光」。

我們跑了兩次：

• 整宅視角（48.0 秒）：材質變細緻了，但整體仍是插畫感的等距模型圖，離「室內照片」很遠。
• 單房視角（42.8 秒）：明顯好很多——沙發有布料織紋、地板有木紋、窗外有景、陰影自然。但它仍然是一個等距娃娃屋剖面，不是照片。

原因在提示詞裡寫死「嚴格保留原始相機角度與構圖」，而 App 的相機是繞著模型轉的軌道相機（限制在 83° 仰角、最近 3 公尺），根本沒有站在室內的人眼視角。輸入是剖面等距圖，輸出自然不可能變成照片。

它做得好的一件事是：完全不亂改家具。我們逐件比對單房重繪前後——沙發、單椅、書架、垃圾桶、盆栽、電視櫃、落地燈、門窗，數量、位置、朝向全部一致，只有地毯顏色微調，這在 AI 生圖工具裡是少見的克制。

判定：「變得更有質感的 3D 算圖」屬實，「寫實效果圖」不成立。

337 件家具，實際上是什麼組成

硬碟上 public/models 底下確實有 337 個 .glb 檔案，manifest 也列了 337 筆，數字沒造假。但介面自己列出的完整數字是 355 件 = Kenney 140 件 + KayKit 197 件（合計 337 個 GLB 模型）+ 內建參數化家具 18 件。

授權都查過：Kenney Furniture Kit 與 KayKit Furniture / Restaurant Bits 的 LICENSE 都是 CC0，可商用。但組成很偏——依 App 自己的分類統計，355 件裡「廚房」類就有 130 件，那是 KayKit 餐廳系列的桌面小道具（刀、鍋、盤、菜單、紙巾架），不是可以放進房間的大件家具。真正算得上大件家具的：床 11、座椅 38、桌几 27、收納 41、燈具 12、衛浴 12，合計 141 件。所以「337 種家具」心裡要換算成「約 140 件真家具 + 約 200 件桌面小道具」。

適合誰、不適合誰

它適合的場景很窄：拿到一張平面圖後，想快速變成一個可以轉動的量體模型，用來討論格局、走動線。這件事它做得比預期好，而且是免費、不用學 CAD 軟體。

它不適合的地方也很明確：

• 不能出效果圖——寫實重繪的產出是等距算圖，不是人眼視角的照片感效果圖
• 不能出施工圖——匯入只吃 PNG / JPEG，不吃 PDF、DWG、DXF、IFC，這點連專案自己的說明都寫明「未實現」
• 沒有 CAD 匯入，也沒有任何 3D 場景匯出格式。唯一的 GLTFExporter 是拿來把「你上傳的模型」轉存成 GLB，不是匯出整個場景。能匯出的只有它自家的 .home3d 與 layout.json 兩種私有 JSON
• 案件資料綁瀏覽器——場景存在 localStorage、上傳模型與原始戶型圖存 IndexedDB，都綁在瀏覽器 origin（含連接埠）。dev 環境的連接埠是隨機挑選並快取在 .port 檔案，換一個連接埠開就看不到之前存的東西
• 牆高預設是隨機值（我們三次套模板拿到 3.34／3.43／3.53／3.65 公尺），只有走平面圖辨識匯入時才會固定填 2.8 公尺並標明是估計值

所以與其說它是室內設計工具，不如說它是一個做得很用心的卡通 3D 家居玩具，附帶一個意外準確的平面圖解析器，兩者之間隔著一段路，「一人公司必收」是行銷語言。

想自己跑的話

我們實際做過、能保證跑得通的路徑：

1. git clone 專案，npm ci 裝依賴，npm run dev 起本機 server（不需要額外設定就能用手動 3D 編輯器）
2. 想用兩個 AI 功能，本機要另外裝 Codex CLI，版本要 ≥0.153.1——我們手上原本裝的是 0.148.0，版本檢查直接擋下、/api/ai/status 回報功能不可用，升級後才打得通
3. 一般讀者照 README 全域安裝 npm i -g @openai/codex@latest 即可；我們自己因為這台機器的全域 Codex 另有他用，改成把 Codex 裝進獨立目錄、用 App 支援的環境變數指過去，這是我們這台機器的特殊狀況，不是一般讀者需要做的事
4. 平面圖辨識只吃 PNG / JPEG，圖片畫得越乾淨（正交、線條清楚、標註工整）辨識越準，這點我們的合成圖測試已經驗證過
5. 額度消耗看不到：辨識與重繪都是「跑完即清」的暫時性 session，不會留下額度使用紀錄，這條路徑下你沒辦法知道這次操作花了多少 Token，要有心理準備

常見問題 FAQ

OpenHome3D 免費嗎？

程式碼是 MIT 授權、家具是 CC0，都可以免費使用與商用。但兩個 AI 功能（平面圖辨識、寫實重繪）跑的是你自己的 Codex CLI 與 ChatGPT 方案額度，這部分的花費不是 OpenHome3D 出的。

需要 Codex 帳號嗎？

手動 3D 編輯器（套模板、拖拉家具）不需要。但平面圖辨識和寫實重繪這兩個 AI 功能，需要本機裝好 Codex CLI（版本 ≥0.153.1）並完成登入，才會被判定為可用。

真實建商平面圖的辨識率如何？

我們這次只測了自己用 PIL 畫的合成戶型圖——正交、線寬一致、標註工整、沒有雜訊。真實的建商圖或掃描件難度完全不同，我們沒有另外測試，辨識率未知，不能用這次的數字外推。

能不能用它出施工圖？

不能。匯入只吃 PNG / JPEG，不吃 PDF、DWG、DXF、IFC，專案自己也寫明未實現。也沒有 3D 場景匯出格式，只有自家的 .home3d 與 layout.json 私有 JSON，沒有 CAD 或施工圖層級輸出。

337 件家具真的都能商用嗎？

可以。Kenney 與 KayKit 兩份授權都是 CC0。但要注意組成：337 個模型裡有 130 件左右是餐廳桌面小道具，真正算得上床、座椅、桌几、收納、燈具、衛浴這類大件家具的合計約 141 件。

換瀏覽器或清快取，之前做的東西會不見嗎？

會。場景存在 localStorage，模型與戶型圖存在 IndexedDB，兩者都綁定瀏覽器 origin（含連接埠）。dev server 連接埠隨機挑選並快取本地，換連接埠重啟就看不到之前資料。

但書

這是單次實測（n=1），用的是我們自己畫的合成戶型圖，不是真實建商圖或掃描件，也沒有跟其他平面圖辨識工具做對照。上面所有數字都來自這一次的測試環境（Apple M4 Pro、2026-09-05 的 commit），不同機器、不同圖檔品質，結果可能不同。

資料來源

• OpenHome3D GitHub：https://github.com/yuyou-dev/OpenHome3D
• 本站實驗紀錄（實驗腳本、產出檔與截圖保存於 5min-ai 專案的 lab/openhome3d-2026-09-13/）