使用 Claude 進行 3D 開發的工作技巧

背景

本文探討了開發者在使用 Claude 進行 3D 網頁開發與 CAD 建模時的實務技巧與限制。作者指出，儘管 Claude 在處理程式碼邏輯與 CSS 表現優異，但在缺乏視覺反饋的情況下，其空間推理能力相當有限。為了克服這一點，作者提出了一種「迭代驗證循環」的開發模式，透過自動化工具讓 AI 能夠自行操作相機、截圖並觀察 3D 場景中的標記物，從而建立起 AI 與開發者之間的共同視覺語言。

社群觀點

在 Hacker News 的討論中，許多開發者對「建立共同語言」這一觀點深表認同。支持者認為，與其期待大型語言模型能直接理解複雜的空間指令，不如先為其建構一套專屬的工具鏈，讓模型透過工具來界定問題。這種做法在 3D 領域尤為重要，因為當維度增加時，多數模型的邏輯推理能力會迅速下降。部分留言指出，將 3D 轉換與空間運算作為 LLM 的基準測試（Benchmark）是非常有必要的，因為目前大多數模型在處理如 Three.js 或 OpenSCAD 等三維任務時，往往會陷入邏輯死循環。

有趣的是，社群對於不同模型的空間能力有著截然不同的評價。雖然原文推崇 Claude，但有評論者指出 Gemini 在 3D 空間推理、建模以及 2D 版面配置上表現更為出色，甚至能獨立完成複雜的 CAD 計算與零件設計。另一派意見則分享了在 FreeCAD 或 Revit 等專業軟體中的成功經驗，認為只要能透過 Python 腳本或 CLI 介面將軟體功能暴露給 AI，並結合「寫碼、截圖、修正」的循環，即使是老舊的 CAD 應用程式也能發揮強大的自動化潛力。

然而，並非所有開發者都對 AI 輔助開發感到滿意。有反對意見批評 Claude 在審查程式碼時常出現邏輯前後矛盾的情況，甚至在指出錯誤後又自我否定，認為這反而浪費了開發者的時間。此外，關於開發流程的權重分配也引發了討論。有人質疑為何作者堅持手寫 CSS 與架構，卻將核心邏輯交給 AI；對此，支持者反駁這正是「在意品質」的表現，因為架構與設計模式決定了專案的長遠走向，若讓 AI 隨意生成骨架，後續的維護與模式統一將會變得極其困難。

最後，成本與效率的權衡也是社群關注的焦點。雖然「截圖回傳」的視覺循環能顯著提升準確度，但頻繁的圖像輸入會導致 Token 消耗量激增，進而使開發成本翻倍。有開發者分享了在 Unity 中的折衷方案，透過將視覺分析封裝成巢狀操作，並要求 AI 在請求視覺資訊時必須附帶具體的觀察指令，以減少不必要的上下文負擔。這種從單純的對話轉向「任務導向型工具調用」的趨勢，被視為未來 AI 參與複雜工程設計的主流方向。

延伸閱讀

• GrandpaCAD：一個整合了截圖修正循環的 3D 建模產品。
• Claude Code：文中提到的自動化開發工具，用於執行程式碼編寫與環境操作。
• Three.js / OpenSCAD / FreeCAD：討論中頻繁提及的 3D 渲染與建模框架，是目前 AI 輔助 3D 工作的主要戰場。