1. 從一句話到三維模型text-to-cad 到底在解決什么問題第一次聽到“text-to-cad”這個說法是在一個做機械設計的朋友那里。他當時正對著屏幕上一堆草圖發(fā)愁嘴里念叨著“要是能直接打字生成模型就好了?！蔽耶敃r覺得這想法挺天真的畢竟CAD建模在大多數(shù)人印象里就是鼠標點來點去、參數(shù)調(diào)來調(diào)去的手工活。但后來接觸了一些生成式模型的項目之后我發(fā)現(xiàn)這個方向并不是空想它背后有一套相當清晰的邏輯。text-to-cad直譯過來就是“文本到計算機輔助設計”。它的核心目標很直接你輸入一段自然語言描述比如“一個邊長50毫米、壁厚3毫米、帶四個安裝孔的法蘭盤”系統(tǒng)輸出一個可編輯的三維CAD模型文件。這件事如果做成影響的是整個產(chǎn)品設計的前端環(huán)節(jié)——從“腦子里有個想法”到“屏幕上有個能看的模型”之間的時間可能從幾小時壓縮到幾十秒。它解決的核心痛點有三個。第一是建模門檻。傳統(tǒng)CAD軟件如SolidWorks、Fusion 360、FreeCAD學習曲線陡峭一個沒接觸過參數(shù)化建模的人光搞清楚草圖約束和特征樹的關系就要花好幾天。第二是重復勞動。很多標準件、常見結構設計師每次都要重新畫一遍雖然可以用模板但模板的靈活性有限。第三是早期溝通效率。產(chǎn)品經(jīng)理或客戶說“我想要一個圓角一點的、看起來穩(wěn)一點的支架”設計師得先理解再建模來回改幾輪才能對齊預期。text-to-cad試圖把“語言”直接變成“幾何”跳過中間的手工翻譯環(huán)節(jié)。適合關注這個方向的人我大致分了三類。一類是CAD二次開發(fā)者想在自己的工具鏈里嵌入文本生成模型的能力一類是AI應用工程師在探索大語言模型與三維幾何的結合點還有一類是產(chǎn)品設計從業(yè)者想了解這個技術到底能不能用在日常工作中現(xiàn)在到了什么程度。不管你是哪一類下面我會從整體設計思路開始一步步拆到實操層面把我知道的、試過的、踩過的坑都攤開來講。2. 整體設計思路拆解為什么不能直接讓語言模型畫圖2.1 核心矛盾語言是離散的幾何是連續(xù)的text-to-cad最根本的難點在于語言和幾何之間的表示鴻溝。自然語言是離散的符號序列而三維模型是連續(xù)的坐標、曲線、曲面。你讓一個語言模型直接輸出“一個邊長50毫米的立方體”它可能會輸出一堆數(shù)字但這些數(shù)字怎么變成CAD軟件能識別的邊界表示B-rep或網(wǎng)格中間缺了一座橋。我見過一些早期嘗試思路是讓模型直接生成頂點坐標和面索引也就是網(wǎng)格數(shù)據(jù)。這種做法在簡單形狀上勉強能用但一旦涉及圓角、倒角、孔位陣列這些CAD里最常見的特征網(wǎng)格表示就力不從心了。因為CAD的核心是參數(shù)化特征歷史不是一堆三角面片。一個孔不是一個圓柱面的網(wǎng)格而是一個“拉伸切除”特征加上直徑、深度、位置這些參數(shù)。所以合理的思路不是讓語言模型直接“畫”而是讓它生成建模指令序列。這就像你告訴一個熟練的CAD操作員“先畫一個矩形拉伸50毫米然后在四個角打直徑8毫米的孔”他聽到的是操作步驟不是最終的坐標點。text-to-cad系統(tǒng)要做的就是把自然語言翻譯成這種操作步驟序列再由一個確定性的幾何內(nèi)核去執(zhí)行。2.2 方案選型三種主流路線的取舍目前能看到的text-to-cad實現(xiàn)大致分三條路線。我在不同項目里都試過或評估過各有各的適用場景。第一條是基于腳本生成。系統(tǒng)讓語言模型輸出一段CAD腳本比如OpenSCAD的代碼或者CadQuery的Python代碼然后調(diào)用對應的解釋器生成模型。這條路線的好處是幾何內(nèi)核成熟OpenSCAD和CadQuery背后是CGAL和OpenCASCADE布爾運算、圓角、倒角這些都有現(xiàn)成實現(xiàn)。缺點是模型必須能表達成腳本對于自由曲面、復雜有機形狀腳本寫起來非常吃力。而且語言模型生成的腳本經(jīng)常有語法錯誤或邏輯錯誤需要額外的校驗和修復環(huán)節(jié)。第二條是基于特征序列生成。系統(tǒng)定義一套領域特定的建模指令集比如“創(chuàng)建草圖”“拉伸”“旋轉(zhuǎn)”“打孔”“陣列”然后讓語言模型輸出這些指令的序列和參數(shù)。這條路線更貼近CAD的原生邏輯生成的模型天然具有參數(shù)化特征樹后續(xù)修改方便。缺點是需要自己實現(xiàn)一個幾何執(zhí)行引擎或者對接現(xiàn)有CAD軟件的API。開發(fā)成本比第一條路線高不少。第三條是基于隱式表示生成。系統(tǒng)讓模型輸出一個隱式函數(shù)或符號距離場SDF然后用 marching cubes 之類的算法提取網(wǎng)格。這條路線在學術研究里比較常見能生成復雜形狀但輸出的模型沒有特征歷史不可參數(shù)化編輯而且網(wǎng)格質(zhì)量往往一般。對于工程應用來說實用性打折扣。我個人的判斷是如果你的目標是做工程可用的CAD模型第二條路線最靠譜。第一條路線適合快速原型驗證第三條路線適合形狀探索和概念設計。下面我主要以第二條路線為基準來展開因為它的技術挑戰(zhàn)最全面也最能體現(xiàn)text-to-cad的核心價值。2.3 系統(tǒng)架構四個模塊的協(xié)作方式一個完整的text-to-cad系統(tǒng)我把它拆成四個模塊。第一個是語言理解模塊負責把自然語言解析成結構化的建模意圖。第二個是指令生成模塊把建模意圖翻譯成具體的建模指令序列。第三個是幾何執(zhí)行模塊調(diào)用幾何內(nèi)核執(zhí)行指令生成三維模型。第四個是校驗與反饋模塊檢查生成的模型是否滿足約束如果不滿足回傳給語言模型重新生成。這四個模塊里語言理解模塊和指令生成模塊通常由一個大語言模型承擔但需要針對CAD領域做微調(diào)或提示工程。幾何執(zhí)行模塊是確定性的不涉及AI它的可靠性直接決定了最終輸出的質(zhì)量。校驗與反饋模塊是最容易被忽視但最關鍵的一環(huán)因為語言模型生成的指令經(jīng)常有各種問題沒有校驗就等于把錯誤直接暴露給用戶。我試過一個簡化版的架構用提示工程讓通用語言模型輸出CadQuery代碼然后本地執(zhí)行。結果大概有30%的生成結果因為語法錯誤或幾何錯誤無法執(zhí)行。加上一個基于規(guī)則的校驗層之后成功率提升到70%左右。這個數(shù)字說明text-to-cad不是“模型一跑就完事”的事情工程化的工作量比想象中大。3. 核心細節(jié)解析與實操要點3.1 語言理解模塊怎么讓模型聽懂“人話”語言理解模塊的任務是把用戶那句可能很模糊的話變成明確的建模意圖。這里最大的挑戰(zhàn)是歧義消解和缺省補全。用戶說“一個圓角盒子”圓角半徑是多少盒子尺寸是多少壁厚有沒有這些信息語言模型不知道但它不能隨便猜也不能一直追問。我的做法是設計一套默認值策略加槽位填充的機制。系統(tǒng)預定義一套建模意圖模板每個模板有若干槽位比如“創(chuàng)建盒子”這個意圖有長、寬、高、圓角半徑、壁厚五個槽位。語言模型的任務是從用戶輸入里抽取槽位值抽不到的用默認值填充。默認值不是隨便定的而是根據(jù)常見工程實踐來設。比如圓角半徑默認2毫米壁厚默認3毫米這些數(shù)值在大多數(shù)場景下不會出大錯。提示工程在這里很關鍵。我用的提示詞大致是這樣的結構先給模型幾個示例展示從自然語言到槽位填充的映射然后給出當前用戶輸入最后要求模型以JSON格式輸出意圖和槽位。示例的選擇要覆蓋常見表達方式比如“帶四個孔”和“四角打孔”要映射到同一個意圖。實測下來給5到8個高質(zhì)量示例通用語言模型在簡單場景下的槽位抽取準確率能到85%以上。注意不要指望語言模型一次就能抽對所有槽位。我的經(jīng)驗是對于尺寸、數(shù)量這類數(shù)值槽位模型容易搞混單位或漏掉。最好在提示詞里明確要求輸出單位并且在后續(xù)模塊里做單位統(tǒng)一。還有一個容易被忽略的點是否定表達的處理。用戶說“不要圓角”和“圓角半徑為零”是同一個意思但模型可能理解成“沒有提到圓角”。我在提示詞里專門加了一類示例覆蓋“不要”“去掉”“取消”這些否定詞讓模型學會把它們映射到槽位的零值或空值。3.2 指令生成模塊從意圖到可執(zhí)行代碼拿到結構化的建模意圖之后指令生成模塊要把它變成幾何內(nèi)核能執(zhí)行的代碼。我選的是CadQuery因為它基于OpenCASCADE幾何運算可靠而且Python語法對語言模型比較友好。生成的代碼大致長這樣import cadquery as cq result ( cq.Workplane(XY) .box(50, 50, 20) .edges(|Z) .fillet(2) .faces(Z) .workplane() .rect(30, 30, forConstructionTrue) .vertices() .hole(8) )這段代碼創(chuàng)建一個50x50x20的盒子Z方向邊倒2毫米圓角頂面打四個直徑8毫米的孔。語言模型要生成的就是這種風格的代碼。但直接讓模型生成完整代碼出錯率很高。我的做法是分步生成先生成特征序列的偽代碼再翻譯成CadQuery代碼。偽代碼的格式很簡單每行一個操作比如create_box length50 width50 height20 fillet_edges directionZ radius2 create_holes facetop diameter8 count4 patternrectangular這樣做的好處是偽代碼的語法空間比完整Python代碼小得多模型更容易生成正確。而且偽代碼和CadQuery之間的映射是確定性的可以用規(guī)則引擎完成翻譯不依賴模型。實測下來分步生成的成功率比直接生成代碼高出不少。提示在提示詞里給模型提供CadQuery的API文檔摘要比讓它自己回憶API要可靠。我通常會把常用的十幾個API函數(shù)的簽名和說明放在提示詞里模型生成代碼時參考這些信息錯誤率明顯下降。另一個實操要點是參數(shù)傳遞的格式。語言模型生成的數(shù)值經(jīng)常是字符串而CadQuery需要浮點數(shù)。我在翻譯層里加了一個類型轉(zhuǎn)換和單位換算的步驟把所有長度單位統(tǒng)一到毫米角度統(tǒng)一到度。這個步驟看起來簡單但少了它后面幾何執(zhí)行就會報一堆類型錯誤。3.3 幾何執(zhí)行模塊確定性內(nèi)核的可靠性保障幾何執(zhí)行模塊是整個系統(tǒng)里唯一不涉及AI的部分但它的重要性怎么強調(diào)都不過分。語言模型可以犯錯但幾何內(nèi)核不能。一個布爾運算失敗或者圓角半徑過大導致幾何無效整個生成流程就斷了。我用的CadQuery底層是OpenCASCADE這是一個經(jīng)過幾十年驗證的幾何內(nèi)核可靠性很高。但即便如此還是有一些常見的坑。比如圓角半徑超過相鄰邊長度的一半會導致圓角失敗。打孔位置太靠近邊緣可能導致孔穿透到外面。布爾運算的兩個實體沒有交集會返回空結果。這些情況在手工建模時設計師會自然避免但語言模型不知道這些約束生成的參數(shù)可能越界。我的做法是在幾何執(zhí)行之前加一個參數(shù)合法性檢查層。這個檢查層根據(jù)建模意圖的類型驗證參數(shù)是否在合理范圍內(nèi)。比如對于圓角操作檢查半徑是否小于相鄰邊最短長度的一半對于打孔操作檢查孔中心到邊緣的距離是否大于孔徑。如果檢查不通過不是直接報錯而是把問題回傳給語言模型讓它調(diào)整參數(shù)重新生成。這個反饋循環(huán)我設了最多三輪三輪還不行就返回失敗讓用戶手動調(diào)整。def validate_fillet(shape, edge_selector, radius): edges shape.edges(edge_selector).vals() for edge in edges: length edge.Length() if radius length / 2: return False, f圓角半徑{radius}超過邊長度{length}的一半 return True, OK這段校驗代碼很簡單但能攔住大部分幾何錯誤。我統(tǒng)計過加上校驗層之后幾何執(zhí)行失敗率從25%降到了5%以下。剩下的5%主要是OpenCASCADE內(nèi)部的數(shù)值精度問題比較難完全避免。3.4 校驗與反饋模塊讓系統(tǒng)自己發(fā)現(xiàn)錯誤校驗與反饋模塊是text-to-cad系統(tǒng)里最像“工程”而不是“研究”的部分。它的任務是在模型生成之后檢查模型是否滿足用戶的原始意圖。這里分兩個層次幾何有效性校驗和語義一致性校驗。幾何有效性校驗比較簡單調(diào)用幾何內(nèi)核的檢查函數(shù)就行。比如檢查模型是否是有效的實體solid有沒有自相交體積是否大于零。這些檢查CadQuery和OpenCASCADE都有現(xiàn)成的API。語義一致性校驗就復雜一些。用戶說“帶四個孔”生成的模型是不是真的有四個孔用戶說“邊長50毫米”模型的包圍盒尺寸是不是50毫米這些檢查需要從生成的模型中提取幾何特征然后和原始意圖做比對。我的做法是寫一組特征提取器比如統(tǒng)計孔的數(shù)量、測量包圍盒尺寸、檢測圓角是否存在。然后把這些提取結果和意圖槽位做比對不一致就觸發(fā)重新生成。注意語義一致性校驗不要做得太嚴格。比如用戶說“大約50毫米”模型生成49.8毫米這不應該算錯誤。我在比對時設了一個容差尺寸類參數(shù)容差5%數(shù)量類參數(shù)要求精確匹配。這個容差范圍可以根據(jù)實際需求調(diào)整。反饋模塊的提示詞設計也有講究。不能只說“錯了重新生成”而要告訴模型具體哪里錯了、期望值是多少。比如“生成的模型有3個孔但用戶要求4個孔請調(diào)整陣列參數(shù)”。這種具體的反饋能讓模型更快收斂。我試過帶具體反饋的重新生成成功率比不帶反饋高出40%左右。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 環(huán)境搭建從零開始的最小可行系統(tǒng)如果你想自己搭一個text-to-cad的驗證系統(tǒng)我建議從最小可行版本開始。不需要一上來就搞微調(diào)用提示工程加通用語言模型就能跑通基本流程。下面是我實際用的一套環(huán)境配置。首先是Python環(huán)境建議3.9以上。核心依賴是CadQuery和OpenAI的API客戶端或者任何兼容的本地模型接口。CadQuery的安裝用conda比較省事pip安裝有時候會遇到OpenCASCADE的二進制依賴問題。conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge cadquery pip install openai然后是項目結構。我習慣分成四個文件intent_parser.py負責語言理解code_generator.py負責指令生成geometry_executor.py負責幾何執(zhí)行main.py是入口。每個模塊之間用JSON格式的數(shù)據(jù)結構傳遞信息這樣方便調(diào)試和替換。# intent_parser.py 的核心邏輯 def parse_intent(user_input): prompt build_prompt(user_input) response call_llm(prompt) intent json.loads(response) intent fill_defaults(intent) return intentbuild_prompt函數(shù)里放示例和格式要求fill_defaults函數(shù)里放默認值策略。這兩個函數(shù)是語言理解模塊的核心值得花時間打磨。4.2 提示詞工程讓通用模型輸出結構化結果提示詞的質(zhì)量直接決定了語言理解模塊的準確率。我經(jīng)過多次迭代總結出一個比較穩(wěn)定的提示詞模板。它的結構分四部分角色設定、任務說明、示例、輸出格式要求。角色設定部分告訴模型它是一個CAD建模助手負責把自然語言轉(zhuǎn)成建模意圖。任務說明部分解釋槽位填充的規(guī)則包括哪些槽位是必填的、哪些有默認值、數(shù)值的單位是什么。示例部分給5到8個覆蓋常見場景的輸入輸出對。輸出格式要求部分明確指定JSON的schema。你是一個CAD建模意圖解析助手。用戶會用自然語言描述一個三維模型你需要把它解析成結構化的建模意圖。 可用的意圖類型 - create_box: 創(chuàng)建長方體槽位有l(wèi)ength, width, height, fillet_radius - create_cylinder: 創(chuàng)建圓柱體槽位有radius, height - create_hole: 打孔槽位有face, diameter, count, pattern 默認值 - fillet_radius: 2 - 單位: 毫米 示例1 輸入一個50毫米長、30毫米寬、20毫米高的盒子帶2毫米圓角 輸出{intent: create_box, slots: {length: 50, width: 30, height: 20, fillet_radius: 2}} 示例2 輸入頂面打四個直徑8毫米的孔 輸出{intent: create_hole, slots: {face: top, diameter: 8, count: 4, pattern: rectangular}} 現(xiàn)在請解析以下輸入 {user_input} 請只輸出JSON不要有其他內(nèi)容。這個模板的關鍵在于示例的質(zhì)量。示例要覆蓋不同的表達方式比如“盒子”和“長方體”要映射到同一個意圖“打孔”和“鉆孔”也要映射到同一個意圖。我通常會準備20個左右的示例根據(jù)實際測試中出現(xiàn)的錯誤不斷補充。提示如果你的模型支持系統(tǒng)提示詞和用戶提示詞分離把角色設定和任務說明放在系統(tǒng)提示詞里示例和用戶輸入放在用戶提示詞里。這樣模型對角色和規(guī)則的記憶更穩(wěn)定。4.3 代碼生成與執(zhí)行從偽代碼到三維模型指令生成模塊的輸入是結構化的建模意圖輸出是CadQuery代碼。我采用兩階段生成先生成偽代碼再翻譯成CadQuery。偽代碼的生成也用提示詞工程但比意圖解析簡單因為偽代碼的語法空間很小。偽代碼的格式我定義得很簡單每行一個操作操作名和參數(shù)用空格分隔。比如create_box length50 width30 height20 fillet_edges directionZ radius2 create_holes facetop diameter8 count4 patternrectangular生成偽代碼的提示詞里我會給出所有可用操作的列表和參數(shù)說明。模型的任務就是根據(jù)建模意圖選擇合適的操作并填參數(shù)。因為操作數(shù)量有限模型的選擇空間不大準確率比較高。翻譯層是一個純規(guī)則的Python函數(shù)把每行偽代碼映射到對應的CadQuery調(diào)用。這個函數(shù)不需要AI寫起來很直接。def execute_pseudo_code(pseudo_code): result None for line in pseudo_code.strip().split(\n): parts line.split() op parts[0] params dict(p.split() for p in parts[1:]) if op create_box: result cq.Workplane(XY).box( float(params[length]), float(params[width]), float(params[height]) ) elif op fillet_edges: result result.edges(params[direction]).fillet(float(params[radius])) elif op create_holes: result result.faces(params[face]).workplane().rect( 30, 30, forConstructionTrue ).vertices().hole(float(params[diameter])) return result這段代碼是簡化版實際項目中需要處理更多操作類型和參數(shù)組合。但核心邏輯就是這樣順序執(zhí)行偽代碼指令每一步在上一步的結果上操作。4.4 完整流程走一遍一個法蘭盤的生成實例我用一個具體例子把整個流程串起來。用戶輸入是“一個外徑100毫米、內(nèi)徑60毫米、厚度10毫米的法蘭盤帶六個直徑8毫米的安裝孔孔均勻分布在一個直徑80毫米的圓上?！钡谝徊揭鈭D解析。語言模型輸出{ intent: create_flange, slots: { outer_diameter: 100, inner_diameter: 60, thickness: 10, hole_diameter: 8, hole_count: 6, hole_circle_diameter: 80 } }第二步偽代碼生成。模型輸出create_cylinder radius50 height10 create_hole diameter60 create_holes diameter8 count6 patterncircular circle_diameter80第三步代碼翻譯和執(zhí)行。翻譯層把偽代碼轉(zhuǎn)成CadQuery代碼result ( cq.Workplane(XY) .circle(50) .extrude(10) .faces(Z) .workplane() .hole(60) .faces(Z) .workplane() .polarArray(40, 0, 360, 6) .hole(8) )第四步校驗。幾何有效性檢查通過模型是一個有效的實體。語義一致性檢查外徑100毫米內(nèi)徑60毫米厚度10毫米孔數(shù)6個孔分布圓直徑80毫米全部匹配。生成成功。整個流程從輸入到輸出在我本地環(huán)境上大概需要5到10秒主要時間花在語言模型的API調(diào)用上。如果換成更小的本地模型時間可以壓縮到2秒以內(nèi)但準確率會下降一些。注意polarArray的參數(shù)是半徑、起始角度、終止角度、數(shù)量。這里半徑是40毫米因為孔分布圓直徑是80毫米。這個換算關系容易搞錯我在翻譯層里加了一個檢查如果偽代碼里給的是直徑自動除以2再傳給polarArray。5. 常見問題與排查技巧實錄5.1 語言模型輸出格式錯誤怎么辦這是最常見的問題。你要求模型輸出JSON它可能輸出一段解釋文字加JSON或者JSON的鍵名拼錯或者數(shù)值帶了單位字符串。我的處理策略是多層容錯。第一層在提示詞里反復強調(diào)“只輸出JSON”。第二層用正則表達式從模型輸出里提取JSON部分忽略前后的解釋文字。第三層用JSON schema校驗如果鍵名不對或類型不對嘗試自動修復。比如把length: 50mm修復成length: 50.0。第四層如果修復失敗把錯誤信息回傳給模型讓它重新生成。import re import json def extract_json(text): match re.search(r\{.*\}, text, re.DOTALL) if not match: return None try: return json.loads(match.group()) except json.JSONDecodeError: return None這個函數(shù)能處理大部分格式問題。實測下來加上這層提取之后格式錯誤率從15%降到了3%以下。5.2 幾何執(zhí)行失敗怎么排查幾何執(zhí)行失敗的原因很多我整理了一個排查順序。先看錯誤信息OpenCASCADE的報錯通常比較具體比如“BRep_API: command not done”通常意味著布爾運算失敗“Standard_ConstructionError”通常是參數(shù)越界。然后檢查參數(shù)合法性用前面說的校驗層過一遍。最后檢查操作順序有些操作必須在特定操作之前或之后執(zhí)行比如打孔必須在拉伸之后圓角必須在打孔之前否則圓角可能被孔打斷。我遇到最多的幾何失敗是圓角半徑過大。語言模型經(jīng)常生成一個看起來合理但實際超過邊長的圓角半徑。比如一個10毫米高的盒子模型生成5毫米的圓角這剛好等于高度的一半OpenCASCADE會報錯。我的校驗層里設的閾值是邊長的0.4倍超過就觸發(fā)重新生成。另一個常見問題是孔的位置越界。語言模型生成孔陣列時可能把孔放在實體外面。比如一個50x50的盒子模型生成孔分布圓直徑60毫米孔就跑到外面去了。校驗層里檢查孔中心到實體邊緣的距離小于孔徑就報錯。5.3 生成結果和預期不符怎么調(diào)整有時候幾何執(zhí)行成功了但模型不是用戶想要的。比如用戶說“一個圓角盒子”模型生成了一個帶圓角的盒子但圓角在錯誤的邊上?；蛘哂脩粽f“四個孔”模型打了四個孔但位置不對。這類問題的根源通常在意圖解析階段。語言模型對“圓角”的理解可能是在所有邊上倒圓角而用戶想要的是只在垂直邊上倒圓角。解決辦法是在意圖解析的槽位里增加更細粒度的控制比如fillet_edges槽位指定哪些邊需要倒圓角。然后在提示詞里增加示例展示不同邊選擇對應的輸出。還有一種情況是默認值不符合用戶預期。用戶說“一個盒子”沒有指定尺寸系統(tǒng)用了默認的50x50x20。但用戶心里想的是100x100x50。這種情況沒法完全避免但可以在生成之后給用戶一個反饋界面讓用戶看到實際使用的參數(shù)方便手動調(diào)整。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決策略模型輸出不是JSON提示詞不夠明確檢查提示詞是否強調(diào)只輸出JSON加正則提取層回傳錯誤重新生成JSON鍵名拼寫錯誤模型幻覺對比schema檢查鍵名加鍵名映射表自動糾正幾何執(zhí)行報錯參數(shù)越界或操作順序錯誤查看OpenCASCADE錯誤信息加參數(shù)校驗層調(diào)整操作順序圓角失敗半徑超過邊長一半檢查圓角半徑和相鄰邊長度設閾值0.4倍邊長超限重新生成孔位置越界陣列參數(shù)錯誤檢查孔中心到邊緣距離校驗距離大于孔徑否則重新生成生成結果不符預期意圖解析偏差對比用戶輸入和解析結果增加示例細化槽位粒度生成速度慢語言模型API延遲測量各模塊耗時換本地小模型或緩存常用意圖提示這張表是我在實際調(diào)試中慢慢積累的建議你在自己的項目里也維護一份。每次遇到新問題就加一行時間長了就是一份很有價值的排查手冊。5.5 幾個容易被忽視的實操心得第一個心得是緩存常用意圖的解析結果。很多用戶輸入是重復的比如“一個50x50x20的盒子”可能被不同用戶反復輸入。把意圖解析的結果緩存起來相同的輸入直接返回緩存能省不少API調(diào)用。我用一個簡單的字典做緩存命中率大概有20%左右。第二個心得是給語言模型提供幾何約束的反饋。在重新生成的提示詞里不僅告訴模型“錯了”還要告訴它“為什么錯了”。比如“圓角半徑5毫米超過了邊長10毫米的一半請把半徑改到4毫米以下”。這種具體的約束信息能讓模型更快找到可行解。第三個心得是不要追求一次生成完美。text-to-cad系統(tǒng)的最佳交互模式是“生成-預覽-調(diào)整”而不是“一次生成最終模型”。用戶看到初步結果后可以用自然語言繼續(xù)調(diào)整比如“把孔的數(shù)量改成8個”“圓角再大一點”。這種迭代式的交互比一次性生成更符合實際設計流程。6. 這個方向后續(xù)可以怎么擴展我在實際項目里跑通基本流程之后發(fā)現(xiàn)text-to-cad的擴展空間比預想的大。一個方向是多模態(tài)輸入用戶不僅可以打字還可以畫一個粗略的草圖或者拍一張照片系統(tǒng)結合文本和圖像一起理解意圖。另一個方向是裝配體生成不只是單個零件而是多個零件的裝配關系比如“一個齒輪箱包含輸入軸、輸出軸和殼體”。這個難度比單零件高一個量級因為涉及零件之間的配合約束。還有一個我覺得很有價值的方向是與現(xiàn)有CAD軟件深度集成?，F(xiàn)在的實現(xiàn)大多是生成獨立的模型文件用戶還得導入到CAD軟件里繼續(xù)編輯。如果能做成CAD軟件的一個插件生成的模型直接出現(xiàn)在當前的設計樹里并且保留完整的特征歷史那實用性會大大提升。我試過用FreeCAD的Python API做類似的事情技術上可行但穩(wěn)定性和性能還需要打磨。最后分享一個小技巧。如果你也在做類似的項目建議從標準件庫開始驗證。標準件形狀固定、參數(shù)明確、生成邏輯簡單是驗證text-to-cad流程的理想場景。等標準件跑通了再逐步擴展到自由形狀和復雜裝配。我在項目初期花了兩周時間只做螺栓和法蘭盤把整個流程的坑都踩了一遍后面擴展到其他零件時順利很多。