模組四｜從 2D 到 3D（Day 20–25）

模組四結算。

先給證據，再講結論。

證據

全 repo 搜尋所有可能引用那個模型的方式（trellis 是 Microsoft TRELLIS.2，那個 4B 參數的 image-to-3D 模型，Day 21 實跑的就是它，產物檔名與資料夾都帶這個字）：

grep -rniE "\.glb|gltf|GLTFLoader|trellis" \
  --include="*.html" --include="*.js" --include="*.json" --include="*.md" .

結果：

(無輸出)

0 hit。

沒有任何 HTML 引用它、沒有任何 JavaScript 載入它、沒有任何設定檔提到它、沒有任何文件連結它。

那個 12.59 MiB 的檔案，從產出到今天，在專案裡的引用次數是零。

而實際上線的角色頁 chenger.html，617 行 JavaScript，用的是：

SphereGeometry      16      ConeGeometry         6
TorusGeometry       12      CatmullRomCurve3     4
CylinderGeometry    12      TubeGeometry         3
BoxGeometry          7      LatheGeometry        2
                            ExtrudeGeometry      1
                            InstancedMesh        1

全部是 Three.js 內建的參數化幾何，沒有一個外部模型。

兩條路線的完整對照

A 在「像」這個維度贏，而且贏很多。B 在其他每一個維度贏。

而那份限制清單，Day 20 列的就是這三條，一條都沒多：

1. 純靜態站，零 build step。 index.html 打開就跑，任何需要編譯、打包、跑轉檔工具鏈的方案都要付代價。
2. 載入預算。 這是一頁角色誌不是遊戲，使用者不會為了看一個角色等十秒。
3. 主題色要能即時換。 不是重新載入資源，是改一個變數、模型跟著變色。

而我的限制清單裡，沒有一條是「要像」。

這不是「SOTA 沒用」的故事

我要非常小心地講這件事，因為結論很容易被誤讀。

路線 A 沒有失敗。 它做到了它宣稱的事：三張圖進去，一個帶完整 PBR 材質、拓撲複雜、細節豐富的模型出來，分鐘級完成。以它自己的目標而言，它表現得很好。

是我的限制組合讓它不適用。

而且時序很重要（Day 20 講過）：路線 B 早了四天。 我不是走投無路才手刻的，我是已經有一個能跑的 34 KB 版本，然後去評估要不要換掉它。

在那個情境下，A 要贏，不能只是「做得出來」，得是「好到值得付出 376 倍的體積、放棄即時換色、放棄可重製性」。

它沒有好到那個程度。

如果我的需求是「做一張漂亮的角色渲染圖放在頁面上」，A 完勝，B 根本不用考慮。

什麼時候該用哪條

我把這個判斷整理成三個問題，照順序問：

問題一：這個東西之後會不會被改？

• 不會（一次性素材、宣傳圖、demo）→ 走 A。生成式路線在一次性需求上壓倒性地划算。
• 會 → 往下問。

問題二：要改的是什麼？

• 改外觀細節（這裡再細一點、那裡加個東西）→ 走 A，然後在 3D 軟體裡改。前提是你有那套工具鏈和技能。
• 改參數（顏色、比例、狀態、組合）→ 走 B。參數化的東西才有參數可以改。

問題三：要做幾個？

• 一到三個 → 兩條都可以，選你順手的。
• 十個以上 → 看瓶頸。A 的瓶頸是 GPU 與費用（可以花錢解決），B 的瓶頸是人工拆解（花錢也不太能解決）。

我的答案是：會改、改的是參數、20 個，所以是 B。

那顆模型完全沒有價值嗎

它在專案裡的引用是 0，這是事實。

但我不會說它是浪費，理由有三個：

一、它讓我知道 A 這條路的實際邊界在哪。 在跑之前，我對 image-to-3D 的印象來自 demo 影片。跑完之後我知道了體積、貼圖形式、拓撲狀態、硬體門檻。這些不會有人在 demo 裡告訴你。

二、它讓「不用 A」變成一個有根據的決定。 沒有跑過的話，我對 B 的信心會一直有個缺口：「說不定 A 更好？」那個問號會在每次 B 遇到困難時冒出來。現在它被關掉了。

三、它是這篇文章。 一個沒有被採用的方案，如果留下了完整的比較資料，它的價值就從「產物」轉成了「知識」。

但我必須誠實：這三個價值都是事後的。 我當初跑它的時候不是為了做技術評估，是覺得「這個很酷來試試看」。價值是回頭整理才長出來的。

代價

代價一：0.72 就是 0.72。

上線的那個模型，看起來就是用球和圓柱堆出來的。認得出是這個角色，但它不是那張圖。

我選的是可控，不是像。 如果有人說「這看起來很粗糙」，那個評價是正確的。

代價二：617 行手寫程式碼是一個真實的維護負擔。

它不會憑空更新。角色設計如果改了，那 617 行要有人去對應調整，而那個人是我。

image-to-3D 至少可以重跑。我這條路線的「重跑」是重寫。

代價三：這個結論只在我的限制下成立。

我列的那三個判斷問題，答案完全取決於你的專案。我甚至可以想像同一個專案的不同部分會有不同答案——比如宣傳用的高品質渲染走 A，網頁上的互動模型走 B。

不要把「我最後沒用 SOTA」讀成「SOTA 不好用」。

帶走什麼

一、選型要對照你的限制清單，不要對照方案彼此。

「A 比 B 好嗎」是錯的問題，因為它沒有參照系。正確的問題是「A 過得了我的限制嗎？B 呢？」

我的限制裡沒有「要像」，所以 A 在它最強的維度上得到的分數是零。這不是 A 的問題，是它強在我不需要的地方。

二、生成式工具的正確用法，有時候是「當參考，不當產出」。

我們預設生成出來的東西就是要拿去用的。但它還有另外兩種用法：

• 當探針——用它快速知道「這條路的產物長什麼樣」，然後決定要不要走
• 當基準——用它的結果當作品質參照，去評估你自己做的東西

產出是一次性的價值，知識是持續的價值。 一個沒被採用的生成結果，如果留下了完整的觀察，它的投資報酬可能比被採用還高。

三、「烤死 vs 參數化」是選型時最值得問的一個問題。

濃縮一下模組四的核心：

這個流程把我之後想改的東西，變成資料還是變成像素？

• 變成資料 → 之後改一個值就好
• 變成像素 → 之後只能重跑整個流程

這個問題適用於遠比 3D 廣的範圍：圖片 vs SVG、截圖 vs 程式碼、影片 vs 動畫、PDF vs 結構化文件、烤好的報表 vs 查詢。

每一次「烤」都是用未來的彈性換現在的方便。 划不划算，看你之後會不會回來改。

四、記錄下你沒選的那條路。

大部分專案只留下「最後採用的方案」。而「我們考慮過 X，因為 Y 沒有採用」這句話的價值，往往比方案本身高：它讓後來的人（包括你自己）不用重跑一次同樣的評估。

我的那顆模型還留在硬碟上，沒有刪。它是這個決定的證物。

模組四到這裡結束。六天講的是同一個決定的六個面向：先寫限制（Day 20）、跑 SOTA（Day 21）、發現它的四個問題（Day 22）、訂驗收契約（Day 23）、拆成 9 個元件（Day 24）、結算（Day 25）。

明天進模組五，回到比較日常的東西：200 回的閱讀端怎麼產出、怎麼稽核、以及一個人到底維護得動多少。