3JSBench 揭露 AI 3D 物件的連接問題：做 Three.js 作品，如何同時驗收外觀與結構？
3JSBench 將 AI 生成 3D 物件的結構與外觀分開評估。用書桌、檯燈和招牌的假設作品，建立接觸、穿模、文字與多視角檢查，避免只看一張漂亮截圖。
3JSBench 是 General Context Labs 推出的模型評測，檢查 AI 生成的 Three.js 物件是否連接正確。Three.js 是在瀏覽器呈現三維畫面的程式庫。
把一句需求交給模型，很快就能看到一張像書桌的畫面。但桌腳可能懸空，檯燈可能穿過桌板，從正面看像連上的零件，轉個角度就分離了。
這次評測提醒開發者，漂亮的畫面與正確的物件是不同成果。若作品要讓使用者旋轉、放大或拿來做產品展示，單一角度的截圖便不足以驗收。
依 2026 年 10 月 10 日核對的原作者討論串，評測包含一百個任務和六百九十七項確定性檢查，也收集創作者並排比較的偏好投票。
我會把這則消息用在作品驗收，而非當成替所有模型排出唯一名次的證據。讀者可以先從一個書桌場景，學會把外觀與結構寫成兩張檢查表。
3JSBench 為什麼把結構另外拿出來測？
畫面只呈現你正在看的那個方向，物件結構卻決定其他方向是否也說得通。模型生成的桌子，在一張截圖裡合理，不代表四隻腳真的接在桌面上。
原作者提到，這次使用的是可以重複執行的確定性檢查。意思是按照固定條件判斷結果，不把每件作品的正確與否都交給另一個語言模型評分。
一百個任務與六百九十七項檢查，描述的是測試範圍。它們不能直接換算成某家模型在你的網站中有多少成功率，因為你的物件與互動需求可能不同。
討論串同時談到幾何連接、交疊表面的閃爍與文字錯誤。這些都可能在作品能正常開啟時存在，所以「程式跑得動」只是其中一個通過條件。
幾何結構是物件形狀、位置和彼此關係的描述。桌腳是否碰到地面、燈座是否放在桌上，都是能用明確條件表達的結構問題。
美感則包括色彩、構圖與造型。原作者收集超過九千五百票、來自逾一千位創作者的並排偏好，這能反映該批作品的審美選擇，不能代替結構驗收。
兩種結果可以放在同一份報告，卻不宜混成一個未說明權重的總分。開發者要先決定作品會怎麼被使用，再選擇最關鍵的檢查條件。
從書桌與檯燈，寫一份可檢查的需求
假設你想做課程網站的互動書桌，畫面包含桌子、檯燈、電線與一塊英文招牌。使用者可以繞著場景看，也能放大觀察桌上的物件。
這是本文設計的練習作品，並非 3JSBench 的實跑結果。它用來示範如何把「做得像」改寫成開發者可以逐項核對的要求。
先把桌子的基本關係寫清楚：桌面保持水平，四隻腳各自接觸桌板下方，底端落在同一個地面，桌腳不可從桌面上方突出。
檯燈則要求燈座放在桌面上，支架連到燈座，燈罩連到支架。這些句子把物件之間的接點說明白，模型才有明確的結構目標。
電線可以暫時簡化成一條連續曲線，起點接在燈座後方。先檢查有沒有斷裂或懸在燈旁邊，再考慮增加細緻的插頭與材質。
招牌文字指定為「STUDY」，字母完整且順序固定。對產品展示來說，文字也是內容的一部分，不應因造型好看就接受缺字或反向文字。
把外觀條件寫得同樣具體
結構條件完成後，再指定整體風格。假設目標是明亮的課程首頁，可以用低彩度木色桌面、暖色燈光與清楚背景，避免擺進太多裝飾。
這些是作者為練習設定的設計方向，並非模型預設能力。你可以換成自己的品牌規範，但不要在修結構時順便重寫所有配色，否則難以比較變化。
初版提示詞可以寫成：「製作可旋轉觀察的書桌場景。先列出桌腳、燈座與支架的接觸關係，再生成作品。文字固定為 STUDY，完成後列出檢查結果。」
請模型列出檢查結果，只能作為自述。你仍要用實際畫面與程式資料核對，尤其是它說「已連接」的零件，是否真的在不同角度都接得上。
需求不必一次寫成複雜工程規格。先用少量物件建立一個清楚場景，找到生成流程容易失敗的關係，再決定是否增加更多零件與互動。
驗收結構時，先旋轉再看接點
第一輪檢查使用普通光線與固定背景，讓邊界容易看清。太強的陰影可能遮住懸空距離，反光材質則會讓穿模位置不容易辨認。
先看正面、側面和背面，再看桌面下方。每個角度都用同一套問題：物件是否接觸應接觸的位置，有沒有穿入其他物件，有沒有不合理的間隙。
桌腳從正面看似接上，側面卻出現縫隙，就是結構未通過。此時把問題位置記下來，要求只修該接點，保留已經符合需求的桌面形狀與配色。
燈座是否浮起來，可用靠近桌面的視角檢視。若作品提供物件位置與尺寸資料，也能請開發者核對底面高度，避免只依靠陰影猜測距離。
電線要沿著路徑檢視，確認是一段連續物件。如果某一段只是被桌面遮住，與真的斷裂是不同問題，記錄要說明具體位置與觀察角度。
穿模和表面閃爍怎麼分辨？
穿模是一個物件不合理地進入另一個物件。例如支架穿過燈罩頂部，或招牌底座卡進桌面深處，通常需要修改形狀、位置或尺寸。
閃爍則可能出現在非常接近或重疊的表面。旋轉畫面時，顏色像在搶著顯示，這種情況應先檢查兩層表面的位置，而不是只換一個材質。
原作者將這類缺陷列入討論，提醒作品的問題常超出提示詞是否漂亮。發現缺陷時保留初版、修改版與相同角度的畫面，才能看出修正是否有效。
不要用關閉旋轉功能來掩蓋背面錯誤。如果最後決定作品只需要一張靜態圖，可以重新縮小交付範圍，但也應明確說這是靜態展示的選擇。
外觀驗收要放回實際使用畫面
結構通過後，再把場景放進預定頁面看大小與構圖。桌子在全螢幕裡漂亮，放進首頁的小區塊後，招牌文字可能變得太細而看不清楚。
先檢查使用者第一眼看得到的重點。若課程首頁要表達閱讀與學習，桌面和燈光應清楚可辨，裝飾物則不應蓋住招牌或主要按鈕。
縮小畫面後再檢查文字完整性，尤其是相近字母與陰影遮擋。模型把字母做成三維物件，不表示拼字自然就會正確，仍要與指定字串逐字核對。
手機使用者可能無法像桌機一樣精準拖曳。檢查初始視角是否已經足以理解場景，互動只是增加細節，不能讓重要資訊依賴轉到某個隱藏角度。
下面這張表把兩種驗收分開，讀者可以直接照著建立自己的交付檔案。每一項都留下觀察角度與問題位置，比只寫「好看」或「有 bug」容易修正。
| 驗收面向 | 書桌作品的通過條件 | 要留下的證據 |
|---|---|---|
| 接觸 | 桌腳接桌板並落地，燈座接桌面 | 正面、側面與底部畫面 |
| 連續 | 支架與電線的連接沒有斷裂 | 接點近距離畫面 |
| 交疊 | 無不合理穿入與表面閃爍 | 旋轉時的問題位置 |
| 文字 | STUDY 字母完整、順序正確 | 原字串與招牌截圖 |
| 構圖 | 網頁中主體清楚，文字可讀 | 桌機與手機實際尺寸 |
如果結果表只有外觀通過，還不能說三維資產全部合格。交付者應指出剩下的結構缺陷，讓接手的人知道能用在哪些場合。
修正版本如何保持可比較？
每次送出修正之前，先記錄目前通過的條件。桌面與四隻腳已經正確，只剩燈罩連接問題時，提示詞就限定修燈，避免把整個場景重做。
新版本仍要看原本通過的位置。模型修好燈罩，卻把桌腳移離地面，這是修正引入的新缺陷，不能因本輪主問題解決就忽略。
比較畫面可以固定相機角度、縮放與光線。若舊版看側面、新版看正面，很容易以為縫隙消失，其實只是被另一個物件擋住。
對照檔名也要保留版本順序，並在記錄裡說明改動要求。接手者看到一張截圖時，應找得到它對應哪一版程式，才有辦法繼續修。
若要請另一個模型修正，先把已通過的結構與未通過的位置交代清楚。新模型可以提出做法，但不要讓它自行改寫已核准的文字與品牌風格。
修稿次數多時，還可以把接點問題分成位置、尺寸與形狀。一次只調一種條件，觀察哪個變動有效，會比每輪都重新描述整個畫面更容易回查。
最後交付檢查表與可操作版本，不只交一張漂亮截圖。使用者能自己轉動確認，開發者也有問題位置與版本紀錄，結構驗收才有延續性。
如何挑模型與控制修改時間？
這份評測最實用的用途，是提醒你用自己的小作品比較。相同書桌需求、相同觀察角度與同一張驗收表，比看不同示範圖更容易判斷模型是否適合。
比較時先保留原始需求，不要為甲模型加上更詳細的接點描述，再拿它與乙模型的簡單提示詞相比。需求程度不同，結果就難以解讀。
修改成本也一起記錄。哪個模型初版比較漂亮、哪個需要修文字、哪個反覆破壞接點，都可能影響最後的工作時間，不能只數生成了幾次。
如果修一個接點又破壞另一個地方，可以把物件拆開處理。先固定桌子，再處理燈，最後加入電線與招牌，每一步都保留可回復的版本。
本文沒有實際比較各模型，也不據原作者投票推出固定冠軍。作品的使用方式才是選擇依據，單張宣傳圖與可旋轉產品模型可能需要不同取捨。
延伸閱讀：ThreeUI 是什麼？160+ 個免費 Three.js 3D 元件、安裝教學與 Pro 方案分析
延伸閱讀：【Vibe Coding】Gemini 3 + three.js 3D 教學｜不用寫程式也能做 3D 手勢互動粒子特效
3JSBench 常見問題
結構通過，就代表作品好看嗎？
結構檢查判斷的是物件關係是否符合條件，並沒有替你決定配色與品牌風格。先通過可檢查的接點要求，再在實際網頁上驗收構圖與可讀性。
創作者投票最多，就能直接選那個模型嗎？
投票代表該批並排作品的偏好，不代表所有類型的三維任務都會有同樣結果。先用自己的小作品比較結構、外觀和修改成本，再決定採用哪個工具。
我不懂 Three.js，還能照這份方法驗收嗎？
可以先從可見的接點開始，旋轉、放大並記錄問題位置。尺寸與程式資料的檢查交給開發者，但產品負責人仍能確認文字、構圖及實際使用的畫面。
這篇提供官方評測程式的安裝指令嗎？
本文依據原作者公開討論串整理評測意義與驗收方法，沒有使用未核對的安裝入口。書桌場景是自行設計的練習，不能當作已完成原評測的結果。
先交付一個能轉過去看的作品
3JSBench 把容易被截圖掩蓋的缺陷變得更具體。對需要三維互動的團隊，這比單純選一個畫面漂亮的模型，更能改善交付方式。
拿下一個 Three.js 作品試做一張結構表與一張外觀表，至少留下正面、背面、側面和手機畫面。逐項修完接點與文字，再決定要增加哪些互動細節。
訂閱 AI 郵報，持續取得 AI 工具的新功能與可執行教學；也把本篇的方法用在下一個小任務，留下自己的驗收記錄。
資料來源
資料查詢日期：2026 年 10 月 10 日。書桌作品為本文設計的假設案例，未宣稱執行官方評測。
