3D 商品展示網站的費用由什麼決定：看懂報價與範圍

3D 商品展示網站的價差，很少來自頁數，通常落在三處：模型要不要重做、互動要做到哪一層、手機要支援到什麼程度。三處的答案決定工作量，報價單的範圍條款則決定這份工作量在簽約後會不會變大，對最後付多少的影響比單價更大。本文只談價格為什麼會變動與報價單怎麼讀，不談金額。

模型這一端：建模師交的檔只是原料

發包 3D 網站時，一個容易出現的誤會是「模型已經有了，這一段可以省」。外包建模交出來的檔只是原料，不是成品。上線用的模型檔必須能從來源重現，每一處改動都要說得出原因。做不到這一點，畫面一出問題，就得先花工夫分辨是素材本身壞了，還是上線的處理壞了，這段分辨的工夫不會消失，只會在專案後段才出現。

外包建模交來的模型，常見缺面、重複匯出、夾帶多餘節點，或在前手被動過而沒有留下說明。進件時用逐項排除的方式找原因：輕量版與完整版各開一次，兩邊都出現的問題與編碼方式無關；貼圖單獨顯示再單獨關閉，排除貼圖的因素；改用背面模式檢視，出現透空就判定為幾何破洞；用建模軟體直接開來源檔，排除自家處理流程的因素；同款不同配色的同名部位互相比對。

曾有一份外包建模交來的模型，其中一個配色的零件缺了約 270 個三角面，另有約 60 個三角面的貼圖被拉伸。逐項排除後確認問題出在來源，修法只動幾何，貼圖完全沒動。

這件事會進到報價單，因為修復與重做是不同性質的工作。來源齊全、進件通過的模型，報價主體是輕量化與上線；來源說不清的，要先把修復單獨列出，修不起來才談重做。進件之前無法判斷時，模型相關的項目只能寫成有條件，不能先給出看似完整的數字。

模型規格也應指向公開依據，而不是廠商自己的口頭標準。Khronos Group 公開了一份為電商產品 3D 內容制定的資產指南（Khronos Group，2025），目標是讓產品的照片級數位孿生能在網頁、應用程式、遊戲與 XR 中使用。本文只引用這份指南的存在與目標，指南內文的建模細則不在此轉述。

檔案格式也是同樣的判斷。glTF 是開放且可互通的 3D 資產傳輸格式（Khronos 3D Formats Working Group，2021）。報價單若以這類開放格式為準，而不是某個軟體的專屬檔案，日後更換廠商或調整網站時，模型檔的沿用空間較大。

進件的檢查可以部分自動化。Khronos Group 提供開源的 glTF 驗證工具（Khronos Group，glTF-Validator），依 glTF 規格檢查 JSON、GLB、緩衝區與貼圖，提供瀏覽器版、命令列與程式套件。把這個工具放進進件流程是本文的建議用法，工具頁面本身沒有談進件。該工具對照的是規格；缺面或貼圖拉伸這類內容問題，仍要靠前面逐項排除的做法。

互動這一端：能做到哪一層，是算出來的

互動常被當成裝飾，卻是簽約後容易起爭議的部分。本文把互動大致分成三層：能轉動檢視、能選配置換色換件、能依序拆解與組回。每多一層，要處理的就不只是畫面，還有資料、時間軸與每個零件的獨立位移。

配置互動的價值並非憑空而來。一項大量客製化的研究發現，自行設計的產品，支付意願顯著較高，效果透過完成感產生（Franke 等，2010）。研究對象是客製化工具，並非專指 3D 配置器，只能當作配置本身有價值的旁證，不能用來預測任何一個網站的成效。互動要做多深，應先由業務目標決定，再換算成預算。

客戶若已有 CAD 的爆炸視圖，會關心能不能原樣搬上網頁。在 LIDROP 的 3D 配置器案例中，客戶提供的爆炸序列有 52 步，網頁版對應成 31 段時間軸，並在動工前先把不會對應到網頁版的部分列成清單：位移為零的佔位步驟、組合件內沒有獨立位移的子零件、爆炸時整條隱藏的線材。客戶要求組回的各步驟比展開更重疊，這項只是把同一條時間軸倒著走，沒有另做一套，也事先列為差異。

能做到哪裡，是算出來的，不是談出來的。報價單若沒有這份清單，驗收時的落差只會變成雙方各說各話。這類需求屬於 3D 互動網站開發的範疇。

裝置這一端：手機的上限由業主訂

手機要支援到什麼程度，會直接改變預算，因為手機的記憶體上限決定哪些功能放得進去。這個上限應由業主訂，開發團隊逐項換算，而不是由開發團隊事後決定犧牲什麼。

以下是一個房地產看屋 3D 網站的例子，數字取自 Chromium 模擬的手機環境。整段流程的記憶體起初約 2.6 GB。上限分階段收緊，先訂約 0.9 GB，再往更低的整段流程高點收緊，而且之後新增的功能一律要算進去。量測雜訊約在數十 MB 之間，這些數字用來判斷方向，不是保證值。

開發團隊的做法是逐項換算，不是整體壓縮。解碼用的背景執行緒每批載完就關閉；貼圖與幾何上傳到 GPU 後，釋放記憶體中的副本；手機上的環境貼圖、陰影、水面反射與全景快取各自降階；貼圖解析度的分級由業主決定。

功能取捨用量測決定。夜景與樹木兩項功能，各自增加的記憶體不到 5 MB，同時啟用時流程中的單一步驟卻跳升約 40 MB，原因是記憶體的高水位，不是兩者相加。量測後的決定是手機保留樹木，夜景城市只給桌機，業主同意。後來另做了手機專用的輕量夜景，只點亮塔樓，長流程的尖峰增量約為零。

所以手機的記憶體預算要在專案初期談定，像預算表一樣逐項分配。報價單該寫的是手機支援到哪一級、哪些功能只給桌機，而不是「支援手機」一句話。

範圍會自己長大

最後付多少，取決於範圍會不會長大。一篇針對軟體專案的實證研究（Komal 等，2020）以文獻回顧與專家訪談找出範圍蔓延的因子，再以問卷資料做 PLS-SEM 分析，發現這些因子與專案成功度呈負相關。研究量測的是專案成功度，不是單指價格或延誤，所以本文只用這項研究支持一件事：範圍失控不只是帳面問題，也會傷害專案成效。

3D 網站的成果能看見每一處細節，每一處都可能被要求再加一點。範圍若沒有寫死，這些追加就沒有邊界。下面四處，是讀報價單時最值得停下來檢查的。

報價單要讀的地方

Bug 與新需求，在簽約前分清

合約範圍內的功能壞了，與範圍之外的新要求，是兩種不同的事。報價單要把這兩種情況分成兩欄，各自寫明如何處理、如何計價。沒有這兩欄，驗收後的追加就沒有防線：任何一個要求，都可以被說成「原本就該有」。

「包含且不限於」與範圍聲明互相衝突

常見的條款寫法是「乙方需提供包含且不限於本報價單所載之服務」。這句讓乙方的範圍沒有上限，而同一份文件的範圍聲明又寫「所載即為完整範圍」。兩句同時存在，爭議時客戶會挑最寬的那一句。讀報價單時，要檢查條款之間有沒有這種矛盾；較不會衝突的寫法是「應依本報價單所載內容提供服務」。

一式總價，期間寫日期不寫月數

有些公部門的採購承辦要求報價以一式總價呈現，期間寫履約期限日，不寫月數。承辦給的理由是：實際決標日不確定，實際的履約期間會比預估的短；月數寫進報價，議約與驗收時就會被換算成單月費用，進而要求按比例減價。報價單只寫日期而不寫月數時，不一定是遺漏，可能是刻意避免這個換算。民間合約是否採用同樣的寫法，依合約型態而定。

正面表列做什麼，比列「不含項目」清楚

範圍聲明有兩種寫法：列出不含什麼，或寫明所載即為完整範圍、未列者另行議價。前者永遠列不完，後者把邊界放在文件本身。好的報價單要讓「沒寫到，但應該要做吧」這句話說不出口。否定句只留給最容易被誤會的一兩件事，例如與既有企業系統串接、App、金流。

切 MVP 邊界時要問的問題

預算有限時，第一期該做什麼，判準不是貴不貴，而是依序回答下列問題。

1. 義務文件有沒有要求：合約、法規或補助計畫等文件明文要求的項目，不能砍。
2. 客戶現在會不會用：需要真實營運資料才有意義的功能，例如結算與預測，先做資料表與後台欄位，產出功能等有資料之後再做。
3. 有沒有零成本的人工替代：自動判定先由人看規則表，狀態機先用下拉選單，結算報表先用 CSV 匯出。
4. 會不會引爆通路政治：例如官網直接顯示價格，可能引發經銷商反彈；這種功能砍掉，同時是省錢，也是保護客戶。

會員登入不是一律要砍。判準是有沒有把人拉回來的迴圈，例如回購、續約、再預約；有的話，這項功能就是營收的地基。

每砍一項功能，都要留下一句話說明「現在怎麼跑」，讓日後接手的人知道當時的取捨。

以建案為例的完整路徑，見建案 3D 看屋的路徑。

不適合用這套方式估價的情況

• 網站只需要呈現商品外觀、不需要訪客自己操作時，圖片或預錄影片通常已經足夠，3D 互動的成本項目不必發生。
• 模型來源與互動深度都還沒有定論時，一式總價並不合適；先完成進件檢查，再決定後續範圍，比一開始就簽死更誠實。
• 合約的計價方式不是一式總價時，履約期限日的寫法不一定適用，應依合約型態另行判斷。

下一步：要準備什麼

洽詢前先備妥下列資料，能讓範圍談得更清楚。缺的部分可以直接說明現況。

• 現有的模型與來源檔：建模軟體原檔或 CAD 都可以；沒有的話，說明目前只有什麼。
• 既有的 CAD 爆炸序列或動畫，若有。
• 手機要支援的範圍，以及對記憶體上限的想法；沒有定案，先列出想保留的功能。
• 文件上對範圍有要求的地方，例如合約、補助計畫或採購文件。

資料不齊也可以先到聯絡頁，說明 3D 網站的需求，缺漏的部分在進件時一併釐清。