十八萬三角形與一條反向的弧線：醫院三維大屏這份實戰紀錄，貴的是驗收那一欄

2026年10月27日，掘金一位署名「夏天要喝冰可樂」的開發者發布了一篇完整的實戰紀錄：用Codex下任務、透過Blender MCP建模、再以React與Three.js組裝，做出一座醫院院區的三維數據大屏演示專案。專案規模可以先用幾個數字定框：源碼約800行，模型18萬三角形、112個mesh，中間來回修改多輪。作者自己先承認成品與設計稿有落差，材質沒跟上、植被是色塊，但場景能轉、能點、能從院區走進樓層，數據對得上。

這則紀錄值得產業面解讀的地方，在於它把AI輔助開發的成本結構翻開給你看：AI壓縮的是建模與寫碼的工時，但驗收、比對與返工的工時不減反增，而這一欄在傳統的開發報價裡經常被低估。

先看流程被改寫的部分

作者描述的分工方式很直接：人在Codex裡下任務、驗收、打回重做；人負責判斷「像不像」與「能不能用」，AI負責把活做出來。這與我們先前整理的Codex加速Java開發的實戰紀錄呈現同一個結構：生成端的速度提升之後，瓶頸移到人的判斷端。

流程設計上，作者把工作切成六個階段：調研收斂、整屏方案、代表區域建模、樣片驗證、逐區開發、最終驗收。每個階段都要求一個可驗證的交付物。兩條經驗被明確寫下：範圍必須提前砍，作者把業務專題限縮到門診與急診兩區，其餘樓棟只做空間導覽，理由是不虛構自己講不清的專題；判斷標準必須可驗證，說「做得好看點」對AI沒有意義，說「入口弧線以這張實拍照片為準，中段後退16米」才有意義。

一條反向弧線的返工帳

整篇紀錄中最具量化價值的段落，是入口弧線出錯的善後過程。門診入口的真實幕牆是中間後退、兩端前伸，具體是一條作者自己都沒量過的曲線，中段相對兩端後退16米。Codex從「弧形入口」四個字出發，推了一個視覺合理但方向相反的曲面：中間鼓出、兩邊內縮。

修正這個錯誤的帳是這樣記的：參數本身改了幾分鐘，但屋頂弧形壓條要跟著重彎、幕牆豎向構件要重排、雨篷門洞要重新定位、入口鋪地與草地在曲線反向處裂開的縫要重建模銜接，修修補補花了小半天。作者從此事得出的工程判斷是：三維場景的可信度與單一模型的精細度關係不大，與模型之間接不接得上關係極大。

這正是三維內容生產與一般程式碼生成最大的成本差異。程式碼錯了有編譯器與測試兜底，幾何錯了沒有自動化檢查會報錯，只能靠人眼對照實拍。AI把建模的單位工時壓低之後，比對與驗收在總工時裡的佔比被推高，這對按人天報價的三維外包與可視化專案廠商，直接影響毛利結構的算法。

身分錨點與資料對帳

另一個翻車點是三維大屏的經典問題：點一棟樓，右側數據與這棟樓無關。作者的解法不是寫更聰明的拾取邏輯，而是在建模階段就把身分埋進模型，每個建築、樓層組與分區面導出時帶上userData，並額外掛空物體做錨點。載入時按約定取名，取不到直接拋錯，不允許靜默降級。

這個設計來自一次實際教訓：早期缺錨點只打warning，改完模型忘記同步，點擊某些樓棟鏡頭沒反應，查了半小時才發現是名字改了。把隱性錯誤轉成顯性錯誤，是AI大量生成程式碼後必須反向加強的工程紀律，與我們在噴氣起飛Roadster小遊戲的開發成本分析中看到的趨勢一致：生成成本趨近於零之後，錯誤暴露的時點決定了修錯的單價。

誰受惠、誰承壓

受惠方是具備領域判斷力的整合者。這份專案證明，一個人加上AI工具鏈可以做出過去需要建模師、前端工程師與資料工程師協作的演示級產品，且源碼量被壓到800行左右。對接案型可視化廠商，這意味着投標門檻與原型成本同時下降。

承壓方有兩類。一是低階建模外包，Blender MCP讓「按圖建模」這段工序的可替代性大幅上升；二是缺乏驗收能力的中間商，當客戶拿著實拍照片挑錯時，返工成本會直接喫掉被AI省下的工時。三維場景的對帳成本不像程式碼可以被測試覆蓋，它留在人的眼睛裡。

邊界與判斷

作者在文末劃清了專案邊界：個人演示專案，非醫院官方產品，數據全為模擬，內部空間是示意設計，不可用於導航或營運決策。這段聲明本身也是產業訊號：當生成門檻下降、演示級數位孿生大量出現時，可營運版本與演示版本的差距，會落在資料接源、驗證流程與責任歸屬上，而這三項目前都沒有被AI壓縮的跡象。

這份紀錄的價值不在成品，在帳本。生成那一欄的工時確實被壓掉了，但驗收與返工那一欄被證明難以壓縮，兩者的相對變化，正在重新定義三維可視化這門生意的成本結構。