1. text-to-cad到底解決什么問題1.1 先把“能生成3D模型”和“能生成零件”分清楚先說個結論text-to-cad 不是讓 AI 隨手吐一個三維模型出來而是要輸出能進加工、裝配、仿真流程的“正經 CAD 模型”。很多第一次接觸這個概念的人以為只要對著電腦說一句“幫我畫一個圓角矩形盒子”就能得到和 SolidWorks 里一模一樣可編輯的零件——這個期待是對的但離技術現(xiàn)狀還有一段距離。我見過不少項目在這個點上栽跟頭。團隊拿一個文本生成點云或網(wǎng)格的開源模型跑通了 demo興奮地拿去給機械工程師看結果對方打開模型第一句話就是“這個孔是貫通的嗎圓角能不能改 R3壁厚均勻嗎”工程師關心的不是渲染效果而是這個模型能不能放進加工環(huán)境、能不能改尺寸、能不能做有限元。text-to-cad 的核心價值恰恰就藏在這些“能不能”里。這里要區(qū)分兩個概念一個是“生成 3D 形狀”另一個是“生成 CAD 模型”。前者可以是一團點云、一個 mesh、一張深度圖只要視覺上像就行后者必須包含參數(shù)、特征、約束、歷史樹。CAD 模型的本質不是形狀而是一串“制造意圖”的連續(xù)記錄。比如一個法蘭盤在 CAD 系統(tǒng)里不是一個圓柱加六個孔而是由“拉伸基體、切除材料、陣列孔”這些特征組成的操作序列。text-to-cad 要解決的就是這個問題把自然語言描述轉換成工程師能繼續(xù)編輯的特征序列。我常用一個類比來解釋傳統(tǒng)建模就像口述做菜給一個廚師廚師會按你的步驟切菜、配菜、下鍋但你要是只給“我要一道好吃的菜”廚師只能自由發(fā)揮而 text-to-cad 的目標是讓 AI 變成那個能聽懂“少鹽、多醋、不要香菜”的幫廚而不是直接把外賣端上桌。1.2 直接生成網(wǎng)格為什么難落地市面上很多“文本轉 3D”項目比如文本生成點云、文本生成神經輻射場其實走的是另一條路線。它們擅長生成視覺上驚艷的有機體一只貓、一把椅子、一個角色概念。但這類結果到了 CAD 場景里幾乎不可用原因很現(xiàn)實。網(wǎng)格模型沒有工程語義。一個由幾十萬三角面片組成的 mesh里面根本沒有“圓柱”“通孔”“圓角”這些概念。你想把孔直徑從 8mm 改成 9mm網(wǎng)格模型只能整體重生成或手動雕刻沒法像參數(shù)化模型那樣改一個數(shù)字。同時網(wǎng)格模型的拓撲質量很難保證經常出現(xiàn)破面、重疊三角形、法線翻轉、非流形邊。拿去切片打印切片軟件可能會直接報錯拿去 CAM 編程刀路更是沒法算。還有精度問題。工業(yè) CAD 的尺寸精度通常是微米級一個機械零件如果臺階厚度差了 0.1mm裝配就可能出問題。而生成式網(wǎng)格模型天然是近似表示它的頂點坐標、面片密度都服務于“看起來像”而不是“量起來準”。這就像用像素畫去指導數(shù)控機床加工本質上不是同一個信息載體。所以 text-to-cad 的技術路線從一開始就注定不能走“生成網(wǎng)格”這條捷徑而是要讓模型學會輸出參數(shù)化操作。哪怕最終也要導出成 mesh 用于渲染或打印但在中間環(huán)節(jié)必須有可編輯、可約束、可重算的 CAD 數(shù)據(jù)結構。誰能在這一層做得穩(wěn)誰才能真正落地。1.3 誰適合用text-to-cad先說最直接的用戶非專業(yè)建模者。很多 3D 打印玩家有明確需求我要一個能卡住攝像頭的小支架、一個路由器掛架、一個補缺的塑料墊片。他們不想學一整套 CAD 軟件只想用自然語言描述尺寸和功能。text-to-cad 可以成為“設計助手”幫他們生成第一版模型再進軟件微調。另一類是設計師和結構工程師的草圖階段。工程師經常開會時口頭描述一個零件寬度大概 60長度 100厚度 3四周開四個沉頭孔。過去要回工位慢慢畫如果有一個 text-to-cad 工具能先畫出基礎特征再到 CadQuery 或 SolidWorks 里補細節(jié)效率會高不少。注意這里說的是“輔助”不是“替代”目前替代還不現(xiàn)實。還有自動化批量生成場景。比如電商平臺要按不同參數(shù)生成成千上萬款定制銘牌、外殼、齒輪。用傳統(tǒng)模板參數(shù)化當然也能做但如果有自然語言入口業(yè)務人員就能直接描述需求不需要開發(fā)改代碼。教學場景也很有意思讓學生用自然語言描述設計意圖再對照生成的 CAD 特征樹學建模邏輯比從零學命令快得多。我個人的判斷是text-to-cad 短期不是要取代 CAD 軟件而是把人和三維建模之間的“輸入門檻”降低一大截。它能做的事是讓“畫一個東西”變得更像“說一個東西”。2. 主流技術路徑從文本到參數(shù)化模型2.1 核心是把語言翻譯成構造步驟目前比較靠譜的 text-to-cad 實現(xiàn)幾乎都是同一個思路讓大型語言模型把文本翻譯成一份 CAD 構造腳本。所謂 CAD 構造腳本就是一系列可執(zhí)行的建模操作例如“創(chuàng)建一個平面草圖畫一個矩形拉伸到 10mm在中心打一個直徑 5mm 的孔”。這類腳本語言包括 OpenSCAD、CadQuery、SolidPython、FreeCAD 的 Python API 等。為什么要用代碼作為中間表示因為文本是離散的代碼也是離散的語言模型處理連續(xù)的點云反而不擅長。文本描述“凸臺邊長 20高 5”可以直接映射到代碼里的cube([20, 20, 5])這種 token 級別的映射關系是語言模型天然可以學習的。反過來如果讓模型直接回歸三維坐標誤差控制非常難而且很難引入“約束”信息。這里有個關鍵點CAD 腳本不是簡單的一句代碼而是一棵樹。OpenSCAD 的布爾運算本身就是一個 CSG 樹CadQuery 則是面向對象的特征序列。我們要讓 AI 學會的是如何從自然語言中提取實體、屬性、空間關系并組織成合法的操作樹。比如“在圓盤中央打一個通孔”模型不僅要識別出“圓盤”和“孔”兩個實體還要知道“中央”是位置約束、“通孔”是貫穿特征。所以在實際項目里我不建議直接用大模型輸出純 OpenSCAD 代碼。更穩(wěn)的方案是設計一個受限的中間 DSL領域專用語言比如 JSON 格式的特征列表{ features: [ {type: cylinder, radius: 20, height: 10, origin: [0, 0, 0]}, {type: hole, radius: 4, origin: [0, 0, 0], through: true} ], units: mm }然后寫一個解釋器把這個 JSON 轉成 OpenSCAD 或 CadQuery 腳本。這樣做的原因是讓大模型直接生成自由代碼語法錯誤率太高但如果讓它生成結構化 JSON再交給固定解釋器渲染就把“語義理解”和“語法生成”分離了。前者是大模型擅長的后者是傳統(tǒng)代碼可以兜底的。2.2 三種常見表示空間怎么選text-to-cad 的技術路徑中中間表示的選擇決定了整個系統(tǒng)的上限。我總結下來主流方案有三類。第一類是程序化代碼表示代表工具是 OpenSCAD、CadQuery。它生成的模型自帶參數(shù)和特征可編輯性最強也最容易驗證。缺點是表達能力受限于腳本語言復雜的自由曲面很難表達需要依賴放樣、掃掠、曲面建模等高級操作。第二類是隱式場表示比如 SDF符號距離場、占用場。這類表示適合生成有機形狀比如閥體、外殼、人體工程學手柄。模型輸出一個函數(shù)空間中每個點返回“到表面的距離”或“是否在體內”再從函數(shù)里提取等值面生成網(wǎng)格。優(yōu)點是表達能力強能生成任意拓撲缺點是提取網(wǎng)格后仍然是 mesh無法直接進入 CAD 特征樹需要再做逆向。AutoSDF、Point-E 這類方法都在這個方向上。第三類是點云或體素表示通常作為中間輸出再配合后續(xù)的曲面重建進入 CAD。點云本身不帶任何工程語義需要額外步驟因此目前更多用于“文本生成形狀”的研究不太適合直接做機械零件。我給一個不太嚴謹?shù)軐嵱玫倪x擇建議如果目標是加工件、標準件、裝配體優(yōu)先選代碼生成因為特征、尺寸、約束都在如果目標是概念外形、外觀件可以考慮隱式場如果只是做設計靈感預覽那就無所謂了點云、網(wǎng)格都行。也就是說越接近制造環(huán)節(jié)越要偏向可編輯的程序化表示。2.3 端到端生成與傳統(tǒng)兩步走的取舍有些研究論文追求一個模型從文本直接輸出 CAD 操作序列也就是端到端。這種方案聽起來很爽實際訓練起來卻非常吃數(shù)據(jù)和算力。CAD 操作序列本身是一種帶層級結構的程序語言模型要同時學會語義理解、幾何推理、語法約束和參數(shù)回歸任何一個環(huán)節(jié)出錯都會崩盤。我見過的端到端 demo大多是訓練數(shù)據(jù)里見過的類似句式能跑通換一個說法就完全失靈。相比而言兩步走方案在工程上更穩(wěn)妥。第一步先用語言模型做信息抽取識別文本中的實體、數(shù)量、單位、位置關系。第二步再用規(guī)則或模板規(guī)劃生成 CAD 操作。比如“一個 40mm × 30mm × 5mm 的底座四角帶 M3 沉頭孔”第一步先抽取出“底座、四個孔、M3、矩形陣列”第二步查標準件庫得到 M3 沉頭孔的尺寸然后生成 CadQuery 代碼。兩步走的好處是可以引入外部知識庫和規(guī)則約束。沉頭孔的標準尺寸不該靠模型“想象”而是查表。倒角該倒多大、螺紋底孔該鉆多大都應由工藝規(guī)范決定。這些信息用外部規(guī)則注入比讓模型硬記可靠得多。所以我的判斷是當前階段工程應用應優(yōu)先做可控的分步系統(tǒng)而不是迷信一個“黑盒”端到端模型。3. 落地實操從一句描述到可打印的STL文件3.1 先搭一個最小可用的環(huán)境拿一個最簡單的場景舉例從自然語言生成 OpenSCAD 模型再導出 STL 用于 3D 打印。這個流程足夠小卻覆蓋了 text-to-cad 的幾個關鍵節(jié)點語義解析、代碼生成、渲染校驗、導出制造格式。環(huán)境準備只需要三樣東西Python 環(huán)境用于調用大模型和編寫解析邏輯OpenSCAD 命令行工具用于把腳本渲染成 PNG 或導出 STL以及一個文本編輯器或 Jupyter Notebook。如果你希望生成更現(xiàn)代的腳本式模型也可以裝 CadQuery它的 Python API 比 OpenSCAD 更接近傳統(tǒng) CAD 的特征思維但最小示例用 OpenSCAD 就夠了。安裝 OpenSCAD 之后記得確認命令openscad在 PATH 里。在 Linux 下可以用apt install openscadmacOS 下用 Homebrew 安裝Windows 下安裝后手動把可執(zhí)行文件路徑加進 PATH。這個步驟看起來簡單但很多人卡在腳本調用時找不到可執(zhí)行文件后面所有自動化都會報錯。3.2 一個從文本到OpenSCAD腳本的完整示例假設用戶輸入這樣一句話“一個直徑 40mm、高 10mm 的圓柱中心打一個直徑 8mm 的通孔?！边@是一個非常典型的入門級描述。先讓大模型做結構化抽取輸出 JSON{ base: {type: cylinder, radius: 20, height: 10}, hole: {type: hole, radius: 4, through: true} }然后由一個解釋器生成 OpenSCAD 腳本$fn 64; difference() { cylinder(r 20, h 10); cylinder(r 4, h 10); }這里有兩個細節(jié)常被新手忽略。第一文本說“直徑 40mm”半徑是 20mm文本說“直徑 8mm”半徑是 4mm。模型如果不理解“直徑”和“半徑”的轉換生成結果會大錯特錯。所以在結構化表達中我建議直接統(tǒng)一使用半徑并把“直徑/半徑”的轉換放在語義解析階段完成不要讓解釋器再去猜。第二OpenSCAD 的$fn參數(shù)控制圓的逼近精度。實際打印時如果$fn設置成 64圓柱側面看起來已經足夠光滑但如果用于精密零件建議用更高的$fn或改用$fa、$fs控制角度和尺寸誤差。還有一點通孔的建模用cylinder加上difference布爾減法是常規(guī)做法但如果你希望孔在工程上更真實考慮錐角、沉頭等特征時就不能只用一個簡單的圓柱了那屬于后處理階段需要補充的工藝細節(jié)。生成腳本后立刻進行渲染預覽在命令行執(zhí)行openscad -o preview.png -D $fn64 part.scad如果命令沒有報錯并生成了一張正常圖片說明基本語法沒問題。但別高興太早這只是第一步。3.3 不能只看渲染圖自動校驗的四個環(huán)節(jié)文本生成代碼最大的風險是“看起來對實際不能用”。很多 AI 生成的 OpenSCAD 模型渲染預覽能通過切片時卻出問題。我自定義了一套四步校驗流程每次批量生成都跑一遍。第一步是語法校驗。用 OpenSCAD 的--check-parameters這類參數(shù)檢查或直接用 Python 的 AST 解析腳本看看有沒有未定義變量、括號不匹配、函數(shù)名拼錯。代碼層面的錯誤要最先干掉。第二步是幾何校驗。導出 STL 之后用admesh、MeshLab或 Python 的trimesh庫檢查 STL 是不是閉合的流形有沒有朝向錯誤的面、破洞、自相交。對于打印來說非流形模型等于廢件。第三步是尺寸校驗。把腳本里的關鍵參數(shù)抽出來和用戶輸入的要求做比對直徑對不對、高度對不對、孔位間距對不對。這一步不是看渲染圖而是做數(shù)值斷言。比如用戶要求“中心孔距底面 30mm”生成的代碼里translate([0, 0, 30])就必須真有一個30。第四步是工程校驗。是否有拔模角度壁厚是否小于打印機能承受的極限孔是否有過盈配合需要這類規(guī)則沒法靠單一模型解決需要一套規(guī)則庫。我的做法是把校驗規(guī)則寫成 Python 檢查器在生成流水線里逐個執(zhí)行檢查不通過就觸發(fā)“重新生成”或“標記人工審核”。3.4 批量生成時的工程化提示當你開始批量處理幾十條描述時就不能一條條手動跑命令了。我會把所有流程包裝成一個函數(shù)def text_to_stl(description: str, out_path: str): spec llm_extract(description) script build_openscad(spec) if not validate_syntax(script): raise ValueError(syntax check failed) tmp_scad write_temp(script) preview render_preview(tmp_scad) stl_path export_stl(tmp_scad, out_path) if not validate_mesh(stl_path): raise RuntimeError(mesh not manifold) return stl_path這個函數(shù)里我刻意把每一步拆開原因是方便定位問題。如果生成的 STL 流形不通錯誤信息可以直接告訴你是語法、幾何還是尺寸階段失敗而不是讓你面對一團亂麻的報錯日志。還有一個工程化細節(jié)大模型的 temperature 參數(shù)要調低。text-to-cad 和聊天不同這里要的是穩(wěn)定輸出不是創(chuàng)意發(fā)揮。temperature 設置在 0.1 到 0.2 之間能顯著減少隨機生成的“胡話參數(shù)”。另外system prompt 里必須寫明“只輸出 JSON不要解釋”否則模型把思考過程也輸出出來解釋器直接崩潰。4. 常見問題與排查技巧實錄4.1 文本歧義AI把“薄壁”理解成模型的一個薄片自然語言天生有歧義這在 text-to-cad 里會被放大。比如“兩孔之間的薄壁厚度是 2mm”AI 可能把這個“薄壁”理解成單獨一個薄片實體而不是兩個孔之間的距離約束。我遇到最典型的例子是用戶說“做一個小外殼壁厚 1.5mm”結果生成的模型是“一個壁厚 1.5mm 的實體板”而不是一個空心的薄壁容器。解法有兩種。第一種是在提示詞工程里做約束要求模型把“壁厚”識別為“殼操作”或“布爾減去的內部偏移”并且在中間表示里明確字段wall_thickness。第二種是后規(guī)則校驗如果檢測到文本里出現(xiàn)“外殼”“盒體”“壁厚”等詞匯而生成的模型沒有布爾挖空操作就判定為語義解析失敗觸發(fā)重新生成。遇到歧義時我傾向于讓模型輸出多個候選解釋再讓用戶選擇。比如“做一個長 50 的盒子”到底是內長還是外長先讓模型生成兩個版本標注“內尺寸版本”和“外尺寸版本”這種交互比強行讓 AI 猜一個要可靠得多。4.2 尺寸單位與半徑直徑混淆單位問題是 text-to-cad 的隱形殺手。CAD 領域默認用毫米但普通用戶可能說“4 厘米”“3 英寸”。如果系統(tǒng)沒有單位換算后面所有尺寸都會對不上。我的建議是在語義解析階段直接統(tǒng)一到毫米并在 JSON 里記錄原始單位和原始數(shù)值方便追溯。另一個高頻錯誤是“直徑/半徑”不分的幻覺。用戶說“直徑 10 的孔”模型卻生成r 10。這個問題看起來很蠢但語言模型非常容易混淆因為“10”出現(xiàn)在描述里模型就傾向于直接作為參數(shù)。補救方法是建立關鍵詞歸一化表與“直徑”對應的 key 是diameter然后在解釋器里做radius diameter / 2而不是讓模型自己換算。4.3 布爾運算與拓撲錯誤OpenSCAD 的difference、union、intersection是 CSG 布爾運算對輸入幾何體的要求很嚴格。當兩個圓柱共面、一個立方體正好貼住另一個立方體的面時OpenSCAD 可能產生退化面、零厚度邊最后導出的 STL 流形不閉合。最典型的場景是“在方形底板的中心挖一個剛好與板厚度相等的貫通槽”。由于槽高度和板厚度完全相等布爾求差時兩個體在 Z 方向“恰好相切”軟件無法穩(wěn)定判斷邊界渲染圖上可能顯示正確導出 STL 后卻出現(xiàn)裂縫。排查策略是對每個布爾操作“留一點點余量”。比如挖槽的高度比底板厚度多 0.001mm或者把分割平面做一次微小偏移讓布爾操作“穿過”而不是“擦過”。經驗規(guī)則是參與布爾運算的體盡量讓它們有明確的相交區(qū)域避免共面接觸。4.4 LLM幻覺代碼與參數(shù)失控大模型生成代碼時會一本正經地編造不存在的函數(shù)或參數(shù)。比如 OpenSCAD 里根本沒有chamfer圓角命令它卻可能生成chamfer(...)。這種問題特別的隱蔽因為腳本報錯后初學者第一反應是去查 OpenSCAD 文檔沒想到是模型在“一本正經地胡說八道”。解決辦法是不要讓它直接輸出“自由文本代碼”而是讓它生成受限的 JSON 特征指令再由本地的“可執(zhí)行函數(shù)庫”映射到 OpenSCAD 或 CadQuery。如果某個特性比如倒角當前還不支持JSON 解釋器就直接報“不支持該特征”而不是讓模型臨場發(fā)揮。另一個幻覺點是參數(shù)范圍。模型可能生成半徑 1e8 的巨大圓柱或者負高度的立方體。所以每個參數(shù)都要做范圍檢查radius 必須大于 0 且小于 1000height 必須大于 0 且小于 1000。數(shù)值校驗是成本最低、收益最高的防線。4.5 數(shù)據(jù)依賴與泛化邊界text-to-cad 模型的泛化能力目前受限于訓練數(shù)據(jù)。開源社區(qū)在做 Text2CAD 這類數(shù)據(jù)集把 CAD 模型的操作序列和文本描述配對。這類數(shù)據(jù)合成思路是對的但覆蓋范圍還比較窄大多是機械零件、規(guī)則幾何體。一旦遇到汽車曲面、復雜裝配體、需要自由曲面建模的造型模型的表現(xiàn)就會斷崖式下跌。所以我的建議是把它當“規(guī)則零件的輔助設計器”用別拿它當“萬能建模師”。在業(yè)務落地時先盤點自己的需求是否落在訓練數(shù)據(jù)覆蓋范圍內。如果都是板件、軸、套、孔系結構那 text-to-cad 能發(fā)揮很大價值如果涉及外觀創(chuàng)意設計建議找另一個技術路線。5. 工具選型與學習建議5.1 不同需求對應不同技術棧需求場景推薦中間表示推薦工具理由機械零件、標準件特征序列CadQuery / SolidPython貼近 CAD 特征思維參數(shù)改動方便3D 打印外殼、支架CSG 樹OpenSCAD語法簡單AI 容易生成驗證快概念外觀、自由曲面隱式場SDF / 神經隱式模型表達能力更強適合有機形態(tài)裝配體、多零件設計參數(shù)約束網(wǎng)絡FreeCAD Python API支持裝配關系但技術門檻更高純設計靈感預覽點云或網(wǎng)格現(xiàn)成文本生成 3D 模型快但不適合工程化這段表格不是絕對標準但可以作為技術選型的第一層過濾器。機械場景里我強烈建議優(yōu)先掌握 CadQuery。它的思想是“先建平面草圖、再拉伸旋轉、再打孔”和主流 CAD 軟件的操作邏輯一致所以模型生成的代碼也更接近真實設計步驟。5.2 開源項目怎么讀才不走彎路很多人讀 text-to-cad 相關的論文或開源倉庫一上來就盯模型架構、loss 函數(shù)結果越看越暈。我建議先看數(shù)據(jù)再看中間表示最后看模型結構。因為這類任務最大的難點往往不是模型而是數(shù)據(jù)如何構造。先看訓練數(shù)據(jù)長什么樣一條文本描述對應幾個操作步驟操作步驟是用序列化的 JSON 表示還是一段 CadQuery 代碼如果數(shù)據(jù)本身質量不高模型再先進也白搭。再看中間表示是否支持“可逆執(zhí)行”。也就是從表示能不能直接重建出模型并且能不能方便地做局部修改。如果中間表示是固定長度的向量那基本不具備工程價值頂多發(fā)論文。最后才是模型。我個人的經驗是當前階段與其去訓練一個新模型不如先在大模型預訓練基礎上做少量微調或直接做 in-context learning。LSTM 時代那種從零訓練序列模型的方式已經被大模型取代了別走回頭路。5.3 幾條寫在最后的大實話如果讓我總結 text-to-cad 真正重要的東西我會說不是模型從文本生成能力而是“約束系統(tǒng)”。一個能讓 AI 自由發(fā)揮的文本生成器和一個能把結果約束在制造規(guī)則之內的生成器是完全不同的產品。普通用戶只看到渲染圖工程師卻會檢查尺寸、公差、螺紋孔、壁厚、材料收縮率。這些約束越早進入系統(tǒng)落地的概率越大。在實際操作中我把大模型當“翻譯官”而不是“設計師”。它負責把用戶的話翻譯成結構化訴求剩下的幾何生成和校驗交給規(guī)則系統(tǒng)。這樣可以充分發(fā)揮大模型的語義理解能力同時避免它的幻覺和不確定性。你可以在提示詞里加上一句話“如果你的描述有歧義請輸出你能想到的默認假設并單獨列出假設條件。”這比讓模型悶頭生成更可控。還有一個小技巧每個生成的模型都保留當時的“輸入文本、中間 JSON、最終腳本”三件套存成一個可追溯的 case。下次模型表現(xiàn)不對時翻出歷史 case 對比能更快定位是語義抽取問題還是解釋器問題。我就靠這個辦法把模型的單次成功率從八成提到了九成以上。最后再分享一個我常用的驗證思路拿到一個 text-to-cad 生成結果別先急著看正面渲染圖先剖開看內部。把模型切一半看壁厚是否均勻、孔道是否貫通、倒角是否如預期。文本生成模型的很多錯誤藏在內部比藏在表面多得多。做設計工具的人一定要有“切開模型”的習慣。