1. 一句自然語言憑什么能變成可編輯的三維模型如果你在工位上接過這樣的需求同事發(fā)來一段話“幫我建個法蘭盤外徑80內(nèi)徑25厚度10中心孔周圍有個2mm高的凸臺螺栓孔6個均布分度圓直徑60”然后你打開CAD軟件從草圖、拉伸、打孔一路做到下班。那你應該能立刻理解text-to-cad這個方向的價值——它想做的事情就是讓上面這種“語音轉(zhuǎn)需求”的場景直接變成“文字轉(zhuǎn)模型”而且轉(zhuǎn)出來的不是一張“看起來像”的圖片不是STL網(wǎng)格而是一份帶參數(shù)、帶特征歷史、能繼續(xù)改孔改尺寸的完整CAD文件。我在本地搭過好幾套不同技術(shù)棧的text-to-cad原型從早期玩票式地讓大模型直接輸出STL到后來老老實實讓大模型寫參數(shù)化腳本中間踩的坑比想象中多得多。這篇文章想把這些經(jīng)驗整理出來包括技術(shù)路線為什么繞不開“腳本生成”這條老路落地時哪些環(huán)節(jié)最容易翻車以及我是怎么把一套能跑通的鏈路搭起來的。適合正在做CAD自動化、做AI設計和工具集成的人參考也適合那些想給自己的3D打印、非標設計流程提效的工程師。先說一個經(jīng)常會誤導新人的點text-to-cad不是“文字生成圖片”套了一層CAD皮。圖片生成追求視覺合理性網(wǎng)格可以有瑕疵、可以夸張比例但CAD模型是要拿去加工、拿去裝配、拿去出工程圖的它必須精確到小數(shù)點后至少兩位必須能被選中面、改草圖的尺寸必須是一棵可回溯的特征樹。哪怕你只想要一個3D打印的手柄你也希望回去改改圓角半徑而不是重新生成一遍。所以“能生成什么”和“能不能被工程師接受”之間隔著一整條野路。我最后跑通的方案本質(zhì)上是一個組合拳先用大語言模型把自然語言需求拆解成結(jié)構(gòu)化參數(shù)和特征順序再讓它生成一段CadQuery腳本最后由OpenCASCADE內(nèi)核執(zhí)行這段腳本并導出STEP。整個過程跑下來一個中等復雜度的機械零件從文字到可用模型穩(wěn)定的話兩分鐘之內(nèi)能完成不穩(wěn)定的時候它會給你演示什么叫“一本正經(jīng)地胡說八道”讓你深刻體會到AI建模離全自動還差著一段必須由人來兜底的路。2. 為什么技術(shù)路線選的是“生成建模指令”而不是直接生成網(wǎng)格2.1 CAD和Mesh的底層差異一張照片和一份可編輯工程圖的區(qū)別很多人第一次接觸text-to-cad時會下意識想到擴散模型、點云生成、神經(jīng)輻射場那一套。這些技術(shù)在生成圖片和3D掃描重建上確實猛但放在CAD領域就水土不服原因不是你模型不夠大而是輸出的數(shù)據(jù)格式從根上就不是CAD的菜。一張STL網(wǎng)格本質(zhì)是一堆三角形的頂點和法線它記錄了“表面長什么樣”但沒有記錄“這個面為什么在這里”“這個孔是通孔還是盲孔”“倒角半徑是多少”。你拿到一個STL法蘭盤想改內(nèi)孔從25變成30不好意思你得重新雕刻網(wǎng)格或者走一遍逆向建模流程那活兒的痛苦程度堪比讓設計師用像素畫板畫畫。CAD模型的底層是B-Rep邊界表示更關鍵的是它帶著特征歷史樹——拉伸、切除、倒角、陣列、鏡像每一步都是可回放的“操作記錄”。所以text-to-cad如果只輸出一個光禿禿的網(wǎng)格那它解決的只是“可視化”問題不是“建?！眴栴}。工程上要的不是一張好看的照片而是一份能拿回去改尺寸、更新裝配關系的“原文件”。這也是為什么我一開始就排除了“用擴散模型直接生成網(wǎng)格”的路線。你讓擴散模型畫一個法蘭盤畫出來十有八九是視覺上很圓潤、孔位很對稱的漂亮網(wǎng)格但真要導入Fusion 360再編輯一次全部特征都變成“網(wǎng)格化實體”修改自由度幾乎為零。換句話說它像一個能說會道但不會畫施工圖的乙方交付物漂亮但不頂用。2.2 現(xiàn)在真正在跑的幾條路從“直接生成網(wǎng)格”到“生成腳本”我翻了從論文到開源項目到商業(yè)工具的一大圈之后把text-to-cad的技術(shù)路線歸成下面四類實際選型時基本繞不開這個四分法。第一條文本轉(zhuǎn)圖像再轉(zhuǎn)網(wǎng)格。典型玩法是先從文字生成多視角圖再通過單目重建或點云擬合得到幾何體。這條路勝在通用理論上什么形狀都能“編”出來但輸出基本沒有參數(shù)化信息曲面擬合也是靠猜精度勉強夠做概念示意不夠做加工。第二條直接訓練模型輸出CAD操作序列。把構(gòu)建歷史當成自然語言一樣去訓練模型一個token一個token地吐“創(chuàng)建草圖、拉伸30mm、打孔”。這個方向?qū)W術(shù)界很熱因為理論上最接近真實建模行為。但它的問題在于訓練數(shù)據(jù)極難搞——需要大量帶完整特征樹的CAD源文件而且操作序列的排列組合復雜度遠高于自然語言模型很容易在前面幾步就崩掉目前離工程可用還有距離。第三條讓大語言模型生成CAD腳本再交給傳統(tǒng)內(nèi)核執(zhí)行。給LLM一個目標格式比如CadQuery、OpenSCAD、FreeCAD的Python API讓它把文字需求翻譯成代碼腳本跑出來的結(jié)果直接就是帶特征歷史的B-Rep模型。這條路線沒有重新發(fā)明建模輪子而是把LLM當成一個“翻譯官”翻譯成本被大幅壓縮。第四條文本轉(zhuǎn)點云或深度圖再逆向擬合成CAD曲面。相當于多了一條信息中間層比文本直接跳模型更容易對齊語義但擬合出來的往往是NURBS曲面塊不是工程師習慣的拉伸、旋轉(zhuǎn)、倒角特征后續(xù)修改依然要重新“伺候”一遍曲面。2.3 我為什么最終選了CadQuery 大模型腳本生成綜合對比下來上面第三條路是我能最快跑通、且交付物最滿足工程要求的方案。原因很現(xiàn)實LLM最擅長的事情之一就是寫代碼而CadQuery的代碼本身讀起來就和自然語言非常接近。你看下面這段import cadquery as cq result ( cq.Workplane(XY) .circle(40) # 外徑80mm .extrude(10) # 厚度10mm .faces(Z) .hole(25) # 中心孔內(nèi)徑25mm )就算你沒寫過CadQuery也能猜出這個模型是什么形狀。對LLM來說這種“用英語寫建模指令”的任務天然比直接生成B-Rep數(shù)據(jù)要順手得多。另一個原因是后端內(nèi)核成熟CadQuery基于OpenCASCADE生成的實體就是標準的B-Rep可以導出STEP、STL可以和主流CAD軟件互通也可以直接拿去做有限元仿真前置。FreeCAD的Python API我也試過它的接口比CadQuery更接近原生OCC能力上限更高但語法臃腫、容易把LLM繞暈OpenSCAD的文本語言對布爾運算友好但圓角、倒角、復雜放樣這些操作寫起來就費勁。最后我的選擇很明確復雜曲面和裝配級應用交給專業(yè)CAD軟件text-to-cad原型統(tǒng)一用CadQuery做主力輸出格式因為它的“腳本即特征歷史”屬性最適合讓大模型發(fā)揮。3. 從文本到CAD的完整落地鏈路環(huán)境、數(shù)據(jù)與核心流程3.1 環(huán)境準備與工具清單別在安裝這一步就卡住整個鏈路不復雜但環(huán)境依賴處理不好會浪費半天時間。我按可復現(xiàn)的方式把工具列一下Python 3.10以上建議用虛擬環(huán)境隔離別直接裝進系統(tǒng)PythonCadQuery負責把腳本變成B-Rep實體它裝完會自帶OpenCASCADE內(nèi)核trimesh用于把STEP或STL加載進來做快速體積、水密性檢查一個大語言模型閉源API或本地部署都可以關鍵是代碼能力要強小模型寫CadQuery經(jīng)常漏括號一個簡單的文件輸出模塊把生成的STEP按零件編號歸檔安裝命令在這里pip install cadquery pip install trimesh如果你在Windows上裝CadQuery耐心等它拉預編譯的OCC包就行體積挺大但基本不會失敗。Mac M系列芯片我踩過坑需要先確保有可用的OpenCASCADE依賴實在不行就換Docker跑反而省心。3.2 提示詞結(jié)構(gòu)比“模型聰明”更關鍵很多人一上來就給大模型丟一句“生成一個法蘭盤”然后抱怨輸出質(zhì)量差。這其實跟CAD做圖一樣你給需求方一張白紙他怎么知道你要什么。我試了幾十輪之后固定下來一套自己的提示詞模板效果穩(wěn)定很多。我要求模型始終按照四個區(qū)塊輸出需求理解把用戶文本里的尺寸、特征、約束提取出來列成結(jié)構(gòu)化清單建模思路用自然語言描述特征的先后順序CadQuery代碼只輸出一個代碼塊不要夾雜解釋自檢說明指出輸出里哪些尺寸可能是猜測的哪些特征存在歧義比如你輸入“做一個帶6個螺栓孔的法蘭盤”模型會先給你列外徑多少、厚度多少、孔分度圓直徑多少如果沒有給就明確標記為“猜測值”。這一步太重要了。CAD建模最怕的不是模型不會畫而是模型默認了某個尺寸你卻毫不知情。3.3 核心流程與自檢回路生成腳本只是開始我的完整處理流程是一個五段式回路缺一不可文本解析從自然語言里抽取實體類型、關鍵尺寸、特征列表、約束關系腳本生成讓大模型按提示詞模板輸出CadQuery代碼內(nèi)核執(zhí)行運行代碼生成實體捕獲異常和警告幾何校驗檢查實體是否有效、體積是否合理、孔的數(shù)量對不對反饋迭代如果校驗不過把錯誤信息回灌給模型讓它修正重試這里最容易被忽略的是“反饋迭代”。很多人跑一次生成就放棄了覺得模型不行。實際上讓模型看到報錯信息再改成功率會直線上升就像代碼調(diào)試沒人規(guī)定第一版必須能編譯通過。我實測下來一個中等復雜零件平均需要1到2次修正才能達到可用狀態(tài)第一次就完美的情況大概只有四成。下面這段代碼是我用來做幾何快速校驗的簡化版import cadquery as cq from pathlib import Path def build_flange(): result ( cq.Workplane(XY) .circle(40) .extrude(10) .faces(Z) .hole(25) ) return result model build_flange() solid model.val() print(體積:, solid.Volume(), mm^3) print(是否有效:, solid.isValid()) bbox solid.BoundingBox() print(長:, bbox.xlen, 寬:, bbox.ylen, 高:, bbox.zlen)校驗邏輯不復雜但能篩掉大部分明顯翻車的生成結(jié)果。比如模型生成的實體體積出現(xiàn)負值、邊界盒尺寸和預期完全不符或者實體有效性校驗直接報false這種情況基本不用看細節(jié)直接讓模型重新生成就對了。4. 實測拆解讓模型生成一個法蘭盤的完整記錄4.1 輸入描述與約束拆解為了讓你直觀感受這條鏈路跑起來是什么效果我用一個實際例子過一遍。用戶原始輸入是“外徑80mm、內(nèi)徑25mm、厚度10mm中心孔周圍做一個2mm高的凸臺凸臺外徑30mm法蘭平面均布6個直徑8mm的螺栓孔螺栓孔分度圓直徑60mm?！边@段描述在人類工程師眼里幾乎沒有歧義但模型不一定。我先讓LLM做需求拆解它輸出的結(jié)構(gòu)大概是這樣主體圓柱體外徑80厚度10中心孔直徑25貫穿凸臺以中心孔為軸線外徑30高度2螺栓孔6個直徑8均勻分布在直徑60的分度圓上角度間隔60度特征順序先拉伸主體打中心孔再凸臺拉伸再凸臺打孔最后陣列螺栓孔如果你直接用這句話去生成大概率會得到一堆“看著對但實際錯位”的結(jié)果。關鍵問題是特征順序。如果先打螺栓孔再做凸臺拉伸凸臺會蓋住部分螺栓孔。讓模型先把特征順序列出來再寫代碼這類低級錯誤會明顯減少。4.2 生成腳本與執(zhí)行結(jié)果整理并修正后的CadQuery代碼如下import cadquery as cq result ( cq.Workplane(XY) .circle(80 / 2) .extrude(10) # 主體法蘭 .faces(Z) .workplane() .hole(25) # 中心孔 .faces(Z) .workplane() .circle(30 / 2) .extrude(2) # 凸臺 .faces(Z) .workplane() .hole(25) # 凸臺內(nèi)的中心孔 .faces(Z) .workplane() .polarArray(60 / 2, 0, 360, 6) # 分度圓直徑60均布6個 .hole(8) # 螺栓孔 )保存成flange_gen.py之后直接執(zhí)行python flange_gen.py輸出會生成一個STEP文件同時打印實體體積和有效性信息。我這邊跑出來的時間大約0.6秒非?？?。真正的時間都花在LLM生成和修正腳本上CPU執(zhí)行CAD內(nèi)核反而是整個鏈路里最不愁的一環(huán)。4.3 模型可用性驗證別只看“像不像”生成完不是結(jié)束我會額外跑一遍幾何檢查因為靠肉眼判斷孔位對不對很容易被渲染器騙過去。solid result.val() print(體積:, solid.Volume()) print(是否有效:, solid.isValid()) bbox solid.BoundingBox() print(邊界盒:, bbox.xlen, bbox.ylen, bbox.zlen)這個模型的理論體積可以手算主體圓柱體積約40212立方毫米減去中心孔約3927加上凸臺環(huán)體積約 2π(152 - 12.52)再減去6個螺栓孔的體積最后應該落在45750立方毫米左右。如果模型輸出的體積偏差超過2%我會判定生成有問題直接回灌給模型調(diào)整?？椎臄?shù)量和分度圓位置我會額外用代碼檢查遍歷實體上的圓柱面統(tǒng)計直徑8的孔數(shù)量是不是6個直徑25的孔是不是2個。這種自動化檢查比肉眼靠譜得多畢竟LLM最擅長干的事之一就是“少打一個孔但不告訴你”。4.4 第一次實測的翻車現(xiàn)場角度單位與特征順序我也不是一開始就跑得這么順。印象最深的一次失敗是模型把polarArray里的起始角度從0度寫成了math.pi/2又把360寫成了2 * math.pi。表面看沒錯6個孔還是均勻分布但實際上整組孔相對于法蘭的相位轉(zhuǎn)了90度。如果這是個需要和對接法蘭配對的零件裝配時就會對不上螺栓孔。另一個高頻失敗是特征順序錯亂。有一次模型先做了凸臺拉伸再打中心孔結(jié)果凸臺上留下一個完整的圓孔但主體上的孔和凸臺孔中間出現(xiàn)了臺階面。從渲染圖看似乎沒問題但實際加工時這個臺階面就是干涉隱患。所以我現(xiàn)在把“特征順序”單獨列為提示詞必填項并且要求模型在自檢說明里逐條核對直到“主體拉伸 主體孔 凸臺 凸臺孔 陣列孔”這個順序完全正確才放行。5. 目前階段最容易踩的坑和我的應對習慣5.1 語義歧義同一個“凸臺”有無數(shù)種建模方式CAD里的術(shù)語在不同人口中經(jīng)常指不同的東西?！巴古_”可以是圓柱凸臺、矩形凸臺、帶斜度的凸臺甚至可以是旋轉(zhuǎn)體凸臺“倒角”可以是等距倒角、不等距倒角或者圓角。LLM不會主動追問你是哪一種它會按訓練數(shù)據(jù)里的高頻統(tǒng)計猜一個默認答案。我遇到過一次用戶說“做一個帶凸臺的底座”模型生成了圓柱凸臺但用戶其實想要的是矩形凸臺。應對辦法很簡單別讓模型猜。我在提示詞里加了一個術(shù)語表把“凸臺圓柱拉伸體斜度默認0倒角默認C1”這種約定寫死模型就不會自由發(fā)揮。如果需求方自己都說不清楚那就讓模型把所有理解成多個方案并輸出人再選一個這比讓它猜一個“看起來合理”的方案穩(wěn)得多。5.2 尺寸幻覺與單位問題這是text-to-cad最讓工程師抓狂的坑。同一個數(shù)字模型可能有時理解成毫米有時理解成厘米甚至有時為了“形狀好看”直接把某個尺寸偷偷改了。我遇到過模型把內(nèi)徑25寫成了“25mm”結(jié)果實際生成時用了25英寸的邏輯雖然輸出文件里數(shù)字是25但實體尺寸差了幾十倍。我的鐵律是全項目統(tǒng)一單位并且在提示詞第一行寫明“所有尺寸默認毫米只能是數(shù)字不允許換算不允許單位換算不允許四舍五入?！比绻脩糨斎搿?cm”我會讓模型先換算成10mm再寫進代碼最后在自檢說明里明確標出“原輸入為1cm已轉(zhuǎn)換為10mm”。很多尺寸錯誤不是因為模型不會換算而是它懶得確認就自行發(fā)揮了。5.3 特征順序和布爾運算沖突CAD建模像做菜先后順序錯了味道就完全不對。最常見的錯誤是“先倒角后打孔”。如果模型先給某個邊加了倒角再打一個孔孔和倒角的邊界相交位置會出現(xiàn)詭異的曲面碎片或者整個布爾運算直接失敗。反過來先打孔再倒角通常就沒事。我在校驗環(huán)節(jié)專門加了一個“特征順序檢查器”規(guī)則很簡單拉伸必須在切除之前打孔必須在凸臺之后倒角必須放在所有影響面確定之后。如果生成的代碼不滿足這個約束就標記為失敗讓模型重寫。這些規(guī)則聽著笨但自動化流程里沒有這些笨規(guī)則模型就會反復用同一個錯誤邏輯挑戰(zhàn)你的耐心。5.4 評估指標怎么定不被“看起來像”迷惑很多人給text-to-cad系統(tǒng)評價一看渲染圖覺得“很厲害”就放過去了。這是大忌。工業(yè)場景要的是數(shù)值可驗證的結(jié)果我給自己定了一套最低通過標準檢查維度通過標準實體有效性solid.isValid() 為True無自相交面尺寸精度關鍵尺寸偏差小于0.5%特征完整性孔數(shù)量、陣列數(shù)量、凸臺數(shù)量完全一致體積誤差與理論體積偏差小于2%導出互通能導出STEP并在其他CAD軟件正常打開這套標準不算苛刻但能顯著篩掉“看起來能用”的模型。事實上很多生成結(jié)果連第一關都過不了實體有效性直接就是False。所以如果你的text-to-cad流程里沒有自動校驗那你就等于在高空走鋼絲全靠肉眼當安全網(wǎng)。6. 把text-to-cad放進真實工作流后我的幾個變化跑了大半年之后我的建模習慣確實被改變了。最明顯的一點是以前接到一個非標零件的建模需求我第一反應是打開CAD軟件開始畫草圖現(xiàn)在我的第一反應是先在文檔里把需求描述寫清楚尺寸、公差、特征順序、默認單位全部結(jié)構(gòu)化。因為如果這段描述能讓LLM生成一個靠譜模型那這段描述本身已經(jīng)足夠讓我自己快速建模了。說白了text-to-cad逼著我養(yǎng)成了“先定義清楚再動手執(zhí)行”的習慣。第二個變化是建模時間分布完全變了。以前畫一個中等復雜度的零件畫草圖加拉伸加打孔加陣列熟練工大概15到20分鐘其中有10分鐘其實是在做機械性操作。現(xiàn)在讓LLM生成加校驗穩(wěn)定情況下3分鐘以內(nèi)能出一個版本但校驗和修正時間增加了。我每天做的不是“更快地建模”而是“更快地判斷這次生成是不是靠譜”。第三個變化是協(xié)作模式。以前別人找我建模要把需求寫得很詳細我再翻譯成CAD操作現(xiàn)在同事只需要在群里發(fā)一段自然語言我把它整理成結(jié)構(gòu)化需求扔給模型生成省掉了中間反復溝通的成本。當然我依然會在關鍵尺寸和裝配關系上自己過一遍這種事沒法偷懶。最后說一個很實際的體會你不需要等text-to-cad成熟到“輸入一句話就得到精準能加工模型”再用?，F(xiàn)在這個階段它已經(jīng)能在標準件、結(jié)構(gòu)件、簡單殼體這類建模中幫你省掉大量重復勞動。它不穩(wěn)定、會犯錯、需要你兜底但就像一個能幫你打草稿的實習生方向感大致對細節(jié)要你檢查用好了效率提升非常明顯。如果你打算試我最想提醒的就是務必把校驗環(huán)節(jié)做扎實否則你省下的時間都會在后期修改模型時加倍還回去。