1. 先搞清楚text-to-cad 到底在解决什么建模难题第一次听到“text-to-cad”这个词的时候我脑子里冒出来的画面是扔给电脑一句话它直接还你一个能编辑、能装配、能出工程图的三维模型。这个画面听起来很科幻但最近围绕这个方向已经有不少实验性项目和论文在往外出。简单说text-to-cad 就是把自然语言描述转换成可编辑的CAD模型它解决的是“脑子里想得清楚、手上画不出来”或者“重复建模太费时间”这两类问题。这篇文章不打算复述宣传文案而是从技术拆解、最小原型实操、常见坑位和落地场景几个角度把这条链路掰开看看。如果你要做三维打印零件、机械结构概念设计、标准件库自动化或者你在做CAD二次开发和自动化工具这篇文章值得花十分钟过一遍。即便你是刚接触CAD的新手也可以先建立整体认识现在这条路走到什么程度、卡在哪里、哪些地方可以先用起来。1.1 CAD建模的隐性门槛在哪CAD建模这件事表面上是一堆按钮和命令底层其实是“几何思维 特征历史 参数约束”的组合。新手第一次打开参数化建模软件面对的不是一张白纸而是一整套逻辑先建草图再定尺寸加约束拉伸、旋转、打孔最后还要维护特征顺序。这里面的每一个环节都可能让新人在第一步就卡住。更不用说工程出图、装配约束、公差标注这些后续环节每一个都有一套独立规则。而真正画过图的人都知道很多零件的形状并不复杂复杂的是那句描述里的“含糊地带”。比如“一个方板四角倒圆角”这句话里面有板厚、边长、圆角半径、是否贯穿四个信息没有说清。人跟人沟通可以靠上下文脑补机器没有上下文就只能猜或者生成一个“看起来差不多但完全不可编辑”的东西。text-to-cad 要处理的核心问题不是“如何画出一个形状”而是“如何把一个不完整、有歧义的自然语言描述转换成一个完整、无歧义、可参数化修改的几何模型”。这个转换过程本质上是一个信息补全和结构化过程也是一个把“人话”翻译成“机器能执行的建模指令”的过程。1.2 定位不是替代设计师而是压缩重复劳动我个人的观点很明确text-to-cad 现阶段不是替代设计师而是把“重复劳动”压缩掉。很多企业的零件库里一类标准件有几十上百种规格每个规格就是长宽高孔径不同。人工一个个建模不仅无聊而且容易出错。这类工作如果有 text-to-cad 或者参数化脚本辅助从描述到模型几乎是一键完成。更常见的使用场景是概念方案的前期。设计师脑子里先有一个粗略想法需要快速出几个三维草案来讨论。传统流程里这一步要么靠手绘要么在CAD里从头画。后者最大的问题是改一个尺寸后面一堆特征跟着动往往改一轮就乱了。text-to-cad 如果能生成带特征历史的参数化模型修改就变得便宜。所以它真正的价值在于“缩短从语言到三维草图的路径”而不是替代人的判断。最终把关的仍然是人。如果你期待它直接生成一个能投产的零件现阶段大概率会失望如果你把它当成“从想法到草图”的加速器它确实能省出大量时间。1.3 谁最适合从这个方向入手从我的观察看有三类人最适合碰这个方向。第一类是机械设计和产品结构工程师他们的大多数需求都是标准化零件和简单钣金件这类模型最容易被文本描述覆盖。第二类是3D打印玩家和创客他们需要快速验证想法对“工程标准”不那么敏感即使生成结果只有八成像也能拿来当参考。第三类是CAD自动化工具开发者他们在做批量建模、模型检索、BOM生成时text-to-cad 提供了一种新的交互入口。如果你是这三类人中的任意一类我建议你不要把 text-to-cad 当成一个“自动建模器”而是当成一个“自然语言输入法”它接管的是打字的过程字怎么排、段落怎么分还是你说了算。这个定位决定了你怎么设计提示词、怎么处理生成结果也决定了项目能不能在团队里真正用起来。2. 拆解技术链路一句话怎么变成可控的三维模型2.1 第一步不是建模而是提取“可执行意图”很多人的直觉是text-to-cad 的核心在“三维生成”但实际跑通一遍就会发现最先卡住的是自然语言理解。模型收到“创建一个法兰盘内孔直径40外圆直径80厚度10均匀分布6个螺栓孔”它首先要把这句话拆成几个可执行规格。拆解包括几个层面对象与特征识别法兰盘、内孔、外圆、螺栓孔数值与单位解析40、80、10默认毫米空间关系判断同轴、均匀分布还有隐含假设法兰盘的厚度方向是拉伸方向螺栓孔是否贯穿要语义猜测。任何一个点出错后面的几何都会跟着错。这里有一个很容易被忽视的细节大语言模型擅长“补全”但CAD描述最怕“过度补全”。例如说“直径40的孔”模型可能默认孔是通孔也可能默认是盲孔。要规避这个问题不能只靠模型自觉而是在输入阶段把描述结构化。可以用模板让用户补充必要参数或者用追问的方式把歧义消解掉。后面实操部分我会给一个提示词模板专门解决这类问题。2.2 中间表示的选择为什么代码生成比直接输出网格更可控当前这个方向的技术方案大致分两类一类是直接生成三维几何体素、点云、隐式曲面、三角形网格另一类是生成一段构建模型的代码或特征序列。直接生成三维几何的好处是快坏处是结果往往是一个“数字雕塑”看起来像但不能编辑不能改参数不能进装配体工程上几乎没法用。相比之下生成代码或特征序列的方式更符合CAD行业的习惯。它输出的是一条条建模指令建草图、加尺寸约束、拉伸、打孔、倒角。这些指令进到几何内核后生成的是带特征树的实体模型。改一个尺寸整个特征树都能联动更新。对工程师来说这才是真正的CAD模型。所以我的建议是只要你的目标不是纯视觉展示而是后续要加工或出图就优先选“代码生成/特征生成”路线。具体到落地可以用语言模型生成某个CAD软件的脚本或者生成一个中立的结构化指令序列再由后端适配器转换成各家软件的操作。前者的工程实现更简单后者的通用性更好。做一个最简单的对比就能看明白中间表示可编辑性参数约束工程可用性实现难度三角形网格低无只能渲染/3D打印参考低体素/隐式场低无视觉预览中CSG布尔树中可部分参数化可加工但特征不直观中特征脚本/代码高完整保留可直接装配出图高在工程上“可编辑性”和“参数约束”这两列几乎是生死线。这也是为什么我强烈建议走代码/特征生成路线。2.3 几何内核、约束求解与拓扑重建容易被忽略的一层语言模型输出代码后并不代表万事大吉。代码里写的“拉伸10毫米”要真正变成一个实体需要几何内核去执行。这里涉及两个关键概念几何表示和拓扑操作。几何表示常见的是边界表示和构造实体几何。边界表示记录实体的面、边、顶点以及它们之间的拓扑关系构造实体几何则记录基本体素和布尔运算的树结构。参数化建模软件大多会把两者结合使用。举个例子“中间掏空的长方体”如果用构造实体几何表达就是长方体减去一个内部小长方体如果用边界表示表达就是外表面加内腔面再维护孔口处的边。代码生成路线通常会生成类似“先画长方体再画内部小长方体然后做减运算”的指令最终由内核算成边界表示。约束求解也是关键一步。文本里的“对称”“相切”“同心”“等长”这些词最后都要转成几何约束。语言模型可以“说出”这些约束但能不能在几何上满足需要约束求解器去迭代。如果约束冲突比如同时指定“直径40”和“直径50”模型再聪明也画不出来。多数CAD软件会把冲突报错整个流程就会失败。这个环节通常不在“文本生成”这一步的讨论范围里但实际跑的时候大量报错都发生在这里。2.4 完整调用链从自然语言到可编辑模型中间发生了什么把上面的环节串起来一条完整的 text-to-cad 调用链大概是用户输入文本 → 第一层语义解析与意图提取用大语言模型或规则模板得到结构化描述 → 第二层中间表示生成生成特征序列/CAD脚本/参数化指令 → 第三层几何内核执行把指令变成实体并做约束求解 → 第四层质量检查与反馈检测是否自相交、是否非流形、尺寸是否符合 → 第五层返回给用户一个可编辑模型。注意这不是单向直线而是一个带反馈的循环。很多工程实现里第四层如果发现失败会把错误信息重新送给第二层让模型修正后再试一次。这个“反馈重试”机制比单纯堆一个大模型更能提高成功率。最简单的实现就是用异常捕获加循环重试后面代码示例也是按这个思路写的。我见过不少团队把精力都放在第一层和第二层的模型调优上忽略了第三层和第四层结果线上成功率一直上不去问题恰恰出在几何内核的异常没有回传。3. 实操跑通一个最小可用的 text-to-cad 原型3.1 环境准备先别急着上大模型把基础链路打通很多新手拿到这类项目第一步就去调大模型接口结果输入输出都是黑盒出了问题根本不知道卡在哪一层。我更建议先搭一个“最小闭环”用一个固定的、写死的规则把文本转成结构化描述用一个半成品的脚本库去生成CAD模型最后只把“从文本到脚本”这一步替换成语言模型。这个闭环需要准备的东西不多一个Python环境一个能执行CAD脚本的本地内核或者一个能调用的CAD命令行接口一组简单的几何操作库。数据方面不必追求大而全准备五到十个典型样例就够了比如“带四孔的板”“带倒角的轴套”“均匀分布散热孔的盒子”。每一样都配好文本描述、尺寸参数表和期望输出的模型文件。这里强调一下如果第一次跑通就要接满真实数据和大模型问题会被噪音掩盖。先用十个样例把链路跑通再考虑扩展。我在实际调试时遇到的绝大多数低级错误都是因为一开始就想跑复杂装配体最后花了几个小时排查发现只是脚本里的单位写错了。3.2 提示词模板把约束说清楚的五个要点我实际用下来给语言模型的提示词决定了最终生成质量的七八成。写提示词有两个原则第一把默认假设显式化第二把单位、坐标系、特征顺序写清楚。下面是一个最简模板你可以根据自己的业务替换请根据以下描述生成一段CAD建模脚本。要求单位为毫米坐标系XY平面为草绘平面Z轴为拉伸默认方向所有孔默认贯穿除非另有说明圆角/倒角默认半径为2毫米除非另有说明描述中未提到的尺寸使用默认值并在注释中标记脚本顺序先建草图再拉伸或旋转然后打孔最后倒角。用户描述{用户输入}这段模板有几个细节值得注意。我故意写了“所有孔默认贯穿”因为这是最常见的歧义来源又把“未提到的尺寸使用默认值并标注”写进去避免模型自作主张生成一个看起来合理的尺寸导致后面改参数时对不上号。标注默认值这个动作能让返回的脚本更可审查人工一看就知道哪些值是猜的。3.3 核心代码示例文本到脚本再到模型的最小实现下面给你一个能跑通思路的最小代码骨架。这里的llm和cad_lib是示意接口你换成自己用的环境即可。核心逻辑是“先生成脚本再执行脚本失败就把错误信息送回模型修正”。import traceback # 示意接口调用语言模型返回文本 def llm_complete(system_prompt, user_prompt): # 实际实现可能是调用你选用的模型服务 # return your_llm.chat(system_prompt, user_prompt) ... # 示意接口本地CAD内核执行一段建模脚本并生成模型文件 def execute_cad_script(script: str): # 把脚本交给几何内核成功返回模型路径失败抛异常 ... def text_to_cad(user_text, max_retries3): system_prompt 你是CAD脚本生成助手。根据用户描述生成可执行的建模脚本。 要求单位毫米先草图后特征未说明的尺寸用合理默认值并在注释中标注。 只输出脚本不要额外解释。 for attempt in range(max_retries): script llm_complete(system_prompt, user_text) try: model_path execute_cad_script(script) return {ok: True, path: model_path, script: script} except Exception as exc: error_msg traceback.format_exc() # 把错误信息回填再试一次 user_text ( f{user_text}\n\n上次生成的脚本如下\n{script}\n\n f执行报错\n{error_msg}\n\n请修复脚本后重新输出。 ) return {ok: False, error: 重试次数用尽} if __name__ __main__: result text_to_cad( 创建一个带四个通孔的矩形板长度100宽度60厚度5孔直径10 ) print(result)这段代码里最关键的是max_retries循环。实际测试中一次生成成功率可能只有六到七成加上一次错误回填能提到八成以上。不过要注意设置重试上限避免模型在一个错误上来回兜圈。重试次数太高不仅浪费时间还可能让模型越改越离谱。3.4 效果评估生成对了没有不能只看“看着像”判断一个 text-to-cad 系统的输出好坏不能只看渲染图“长得像不像”。我建议至少看四个维度第一几何尺寸是否准确。用测量工具和模型对比比如设计值是长100宽60实际实体线框测量是否一致相差超过0.5%就要标记失败。第二可编辑性。生成结果是否保留特征树和参数改长度后孔距会不会跟着变。如果生成的是一堆网格面片在工程上等于废品。第三约束是否保留。同心、对称、等距这些约束有没有真正写进特征里而不是画完就没了。第四稳定性。同样的描述输入三遍得到的结果是否一致加了微小措辞变化是否输出合理。我建议你建一个“回归测试集”把二十个典型描述放进去每次修改提示词或模型后都整体跑一遍看成功率、尺寸准确率和特征保留率的变化。没有这个测试集你很难判断改动到底是在变好还是变坏。我自己踩过这个坑凭感觉调了一个提示词觉得某几个例子变好了结果回归测试一看整体成功率反而下降了八个点。4. 真实使用中一定会遇到的坑问题与排查速查表4.1 语义歧义一句话里有十种理解模型选了第十一种text-to-cad 最典型的失败不是模型不会画而是它“太会脑补”。举个例子“一个板子中间挖一个方孔”在这个句子里没有说方孔是否居中、是否贯穿、尺寸多大。如果模型默认“居中、贯穿、边长为板宽的30%”这不一定是你想要的。我的经验是在输入端把歧义显性化要么在提示词模板里要求“未说明的参数使用默认值并标注”要么在人机交互界面上增加一次确认环节。更高级一点的做法是让模型先输出“它理解的参数表”用户确认后再生成脚本。多花这几秒能避免后面整轮返工。如果想更进一步可以做一个“参数回显”模块把模型要执行的草图尺寸、拉伸深度、孔数量全部列出来用户确认后再往内核送。4.2 几何与拓扑错误自相交、悬空边、非流形执行脚本时最常遇到的几何错误主要有三类。第一类是自相交比如拉伸方向写反导致特征互相穿透第二类是悬空边或零厚度的面常见于布尔运算的相切退化情况第三类是非流形多个实体通过一条边或一个点连接CAM软件无法处理。这类问题不能靠语言模型自己发现必须在几何内核层做检查。模型生成之后用内核自带的检测工具跑一遍流形检查、最小边/面检查、体积非负检查。一旦发现异常把错误信息反馈给模型告诉它“布尔运算产生非流形结果请改用先拉伸后打孔或调整特征顺序”。这种针对性反馈比笼统说“生成失败”有效得多。下面是一个常见错误速查表可以直接贴在团队文档里。错误现象常见原因排查方法修复建议自相交实体多个特征拉伸方向冲突检查特征方向与草图平面统一拉伸方向或分步操作零厚度/悬空边布尔运算相切退化检测最小边长度与最小面面积调整孔位与边界距离非流形边多个体只通过边连接用流形检查工具定位增加连接特征或改为合并体尺寸严重偏差单位识别错误核对输入单位与脚本单位提示词中强制声明毫米孔位置乱排均匀分布约束丢失检查脚本中的阵列参数改用圆周阵列或线性阵列指令4.3 与现有CAD工作流的兼容问题别让生成的模型变成一座孤岛即使模型生成成功离真正用起来还有一段路。最大的坑是格式兼容。如果输出的是网格文件表面上看没问题但下游的装配、出图、仿真都用不了。你需要的是带特征历史的原生产品文件或至少是带参数化定义的交换格式。这里我的建议是不要直接拿网格文件当交付物而是把“生成的脚本”作为第一交付物。脚本是可读文本出了问题能改能进版本管理能适配不同CAD软件。一定要保留生成过程中的参数表和脚本这样别人拿到手能知道这个模型是怎么来的而不是一个“来路不明”的实体。另外要注意坐标系和命名规范。有的团队习惯Z轴向上有的习惯Y轴向上语言模型生成的脚本默认用哪个坐标系要在提示词里写死。项目里最好是统一模板不然一个人生成的模型另一个人打开就定位不准。这个问题看起来小但在多人协作时最容易引发返工。5. 落地场景与扩展方向它能改变什么又不能改变什么5.1 短期内最值得落地的场景如果从“投入产出比”看我觉得有三类场景最值得先落地。一是标准件库的批量生成。企业维护一套统一的提示词模板和参数表把几十上百个规格的标准螺栓、垫片、法兰一次性生成出来效率和一致性都远高于人工建模。二是概念方案的快速可视化。结构评审之前用自然语言快速生成初步三维草案不用再花几个小时建模。三是教学场景。CAD教学里有一类典型问题学生知道零件长什么样但不知道用什么命令画。text-to-cad 可以生成“教学用脚本”学生对照脚本和模型学习特征顺序比对着视频一步一步抄效率高很多。这些场景有一个共同点模型本身不复杂但数量大、重复度高、对人的判断要求不高。正因如此它们最适合作为第一批生产落地场景。反过来如果一上来就做复杂装配体或者曲面造型大概率会卡在语义理解和几何重建的交叉地带。5.2 还做不到的事设计意图的完备表达也要泼一盆冷水。text-to-cad 目前还不能表达完整的设计意图。一个真实零件背后的信息远不止几何形状为什么要用这个材料为什么这个面要加工公差要求是多少装配时哪个面是基准工艺上讲究尽量少换刀……这些信息在自然语言里可能几句话就带过但机器几乎没有能力把它们转化成可执行的制造约束。这不是单纯提高模型能力就能解决的而是需要更丰富的训练数据和更强的领域知识建模。比如“螺纹孔”三个字很多人以为生成一个圆柱孔加螺旋线就行但实际制造涉及到底孔直径、深度、攻丝长度、螺纹规格、尾部处理等多个参数。文本输入时如果漏掉任何一个生成的模型在生产线上就会出问题。所以现阶段text-to-cad 更适合处理“几何意图明确的零件”还不适合处理“包含大量隐性工艺知识”的复杂件。真要用于生产至少需要一个工艺工程师把模型重新审核一遍。这个边界清楚了你对项目的预期就不会跑偏。5.3 怎么把它接进团队现有工作流而不是推倒重来最后一个问题是工程化。很多团队听到 text-to-cad第一个反应是要不要上一套新软件。我的看法恰恰相反这个方向最好的落地形态不是新平台而是现有CAD软件里的一个插件或侧边栏。具体可以分三步走。第一步在现有CAD软件里做一个输入框用户输入描述插件调用后端生成脚本再通过软件接口重建模型。第二步加入“人工确认”按钮用户对生成结果做标注和修改修改后的模型和原始文本一起存入数据。第三步用这些人工修正过的数据去微调提示词和模型。这样形成的闭环每次使用都在积累数据越用越准。这里最忌讳的是把 text-to-cad 做成一个独立的孤岛工具生成的模型和公司现有零件库、编码体系、工艺数据库都不通。一旦不通前端再智能后端也没人敢用。实际推进时最好先选一个标准化程度最高的小品类作试点跑通后再往其他品类扩散而不是一开始就追求覆盖所有模型。我自己的体会是text-to-cad 现阶段最适合干的事是充当“高级草图生成器”。它不能替你完成设计但能让你提前好几个小时看到三维草案。你只需要把它当成一种新的输入方式把精力留给人最擅长的判断和决策。如果准备上手别从复杂装配体开始先拿一个带孔板练手把提示词、约束提取和几何检查这三关跑通再往复杂场景扩展。这样做踩坑最少收益最直接。