1. 当画图变成打字Text-to-CAD到底在解决什么问题第一次看到Text-to-CAD这个词我脑子里蹦出来的不是设计师要失业了而是终于有人来收拾参数化建模那堆重复劳动了。如果你在机械设计、工业设计或者建筑BIM这条线上待过一定懂我在说什么——一个标准法兰盘改个孔径、改个倒角、改个孔距就要在CAD里点几十次鼠标拉伸、切除、阵列、约束一套流程走下来手都酸了。Text-to-CAD想干的事情很直接你用自然语言把需求描述清楚它直接吐给你一个可编辑的CAD文件通常是STEP、IGES这类通用格式背后是B-Rep边界表示实体模型而不是一堆没法编辑的网格。这件事的价值不在于AI会画图了而在于把设计意图到几何模型之间的翻译成本压到接近零。传统流程里设计意图在你脑子里你得手动翻译成草图、约束、特征树中间任何一步理解偏差都会导致返工。Text-to-CAD试图让模型直接理解一个直径80毫米、厚度10毫米、中心带20毫米通孔的法兰盘这种描述然后生成对应的B-Rep实体。关键词里的B-Rep是核心因为只有B-Rep才能被后续的CAM加工、有限元分析、装配约束真正用起来网格模型STL那种在工程链条里基本是死路一条。那它适合谁用我梳理了三类人。第一类是做标准件、通用件批量设计的工程师比如管道法兰、支架、连接件这类零件参数化程度高、变体多用文本生成能省掉大量重复建模。第二类是产品经理或非设计岗的创客脑子里有个大概形状但不会用SolidWorks、中望CAD这些工具想快速把想法变成能3D打印或CNC加工的模型。第三类是做CAD二次开发的技术人员想在自己的系统里集成文本生成能力比如做一个输入需求自动出图的内部工具。如果你属于这三类这篇内容值得往下看如果你做的是复杂曲面、自由造型那目前这类工具还帮不上太多忙别抱不切实际的期待。需要先泼一盆冷水Text-to-CAD不是说一句话就出成品的魔法。它生成的是初版几何尺寸链、公差、材料、表面处理这些工程属性还得你自己补。把它当成一个超级快的草图助手而不是替代设计师的AI心态就对了。下面我从技术原理、实操流程、踩坑经验几个角度把这件事拆开讲透。2. 文本怎么变成实体B-Rep生成的技术链路拆解2.1 从token到几何中间到底发生了什么很多人以为Text-to-CAD是大模型直接画图其实中间隔了好几层。我把它拆成四个阶段你就能明白为什么有时候生成的东西看着对但用不了。第一阶段是意图解析。你输入的文本先被LLM处理提取出结构化的设计参数。比如一个长100、宽60、高20的盒子顶部中心有个直径10的孔LLM要输出的是类似{shape: box, length: 100, width: 60, height: 20, feature: hole, position: top_center, diameter: 10}这样的结构化描述。这一步的难点在于歧义消解——顶部中心到底是几何中心还是重心直径10是半径还是直径工程语境里这些默认约定模型不一定懂。第二阶段是参数化脚本生成。结构化参数会被翻译成CAD内核能执行的脚本常见的是CadQuery基于Python的参数化建模库或者OpenSCAD的脚本。这一步是关键分水岭如果生成的是CadQuery代码那出来的就是真正的B-Rep实体如果生成的是网格描述那出来的就是STL那种没法参数化编辑的东西。关键词里提到的API很多时候就是指这类文本→脚本→实体的调用接口。第三阶段是几何内核执行。脚本交给几何内核比如OpenCASCADE、Parasolid去实际运算生成B-Rep数据结构。这一步会暴露很多问题布尔运算失败、自相交、退化面都是常见的。我实测下来简单零件成功率能到八成以上稍微复杂点的带圆角、抽壳的零件失败率就上去了。第四阶段是格式导出与校验。生成的实体导出成STEP或IGES同时要做几何有效性检查——是不是封闭实体、有没有零厚度面、法向是否一致。很多工具跳过这步导致你拿到的文件在CAD里打开是烂面根本没法用。2.2 为什么B-Rep这么重要网格模型差在哪这里必须把B-Rep和网格模型的区别讲清楚否则你选工具时会踩大坑。对比维度B-Rep实体网格模型STL/OBJ数据结构面、边、顶点的拓扑关系解析曲面三角面片集合可编辑性可参数化修改改尺寸不重建基本不可编辑改尺寸要重做精度解析精度理论无限受三角面片密度限制CAM加工直接可用需转换精度损失有限元分析直接可用需重新划分网格文件大小小大生成难度高低我见过太多人拿AI生成的STL去做CNC结果刀路算出来全是台阶因为网格模型的曲面是多边形逼近不是真正的圆弧。所以选Text-to-CAD工具时第一件事就是确认它输出的是不是B-Rep。如果只输出STL那它顶多算个3D打印玩具生成器进不了正经工程流程。2.3 当前主流实现路径的差异市面上这类工具的实现路径大致分三种各有取舍。第一种是LLM直接生成CadQuery/OpenSCAD代码。优点是透明、可调试生成的代码你能看懂、能改缺点是LLM写代码会出错语法错误、API用错、逻辑漏洞都常见需要人工修。我比较推荐这条路径给有编程基础的人因为可控性最强。第二种是LLM生成中间表示再由专用编译器转几何。比如生成一种领域特定语言DSL再编译成B-Rep。优点是稳定性好LLM不用懂CAD API细节缺点是灵活性差DSL覆盖不到的形状就生成不了。第三种是端到端的神经几何生成直接用神经网络预测B-Rep的拓扑和几何。这是学术界的热点但工程上还不成熟生成结果的可用性不稳定我不建议在生产环境用。理解这三条路径你在选工具或自己搭系统时就知道该往哪个方向使劲了。3. 动手跑一遍从一句描述到可用的STEP文件3.1 环境准备里最容易被忽略的两件事假设你要自己搭一套Text-to-CAD流程或者用现成工具做验证环境准备阶段有两个坑我必须提前说。第一个坑是几何内核的版本兼容。CadQuery依赖OpenCASCADEOCCT而OCCT不同版本之间的API有 breaking change。我试过在一台机器上用CadQuery 2.2配OCCT 7.6跑得好好的换台机器OCCT是7.4同样的代码直接报Standard_Failure。所以第一步是锁定版本建议用conda建独立环境别用系统自带的Python包管理器瞎装。conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge cadquery2.4 occt7.7第二个坑是LLM的API调用配额和上下文长度。关键词里出现了maximum context length is 1048576 tokens这类报错说明有人拿超长上下文模型硬怼。实际上生成CAD代码不需要那么长的上下文但如果你把整个零件库的示例都塞进prompttoken数会爆炸。我的做法是只放3到5个最相关的示例用检索的方式动态选而不是全量塞。3.2 提示词怎么写才能出可用的几何这是全文最核心的实操部分。我踩了无数次坑之后总结出一个提示词模板你直接抄生成一个CadQuery脚本创建以下零件 - 基础形状长方体 - 尺寸长100mm宽60mm高20mm - 特征1在顶面几何中心打一个直径10mm的通孔 - 特征2四条竖直边做R5圆角 - 输出导出为STEP文件路径 ./output/part.step - 要求使用B-Rep实体确保布尔运算后是单一封闭实体关键点在于尺寸必须带单位特征位置要说清楚是几何中心还是重心明确要求B-Rep和封闭实体指定输出格式和路径。我对比过加了这些约束之后一次生成成功率从大概四成提到七成以上。还有一个技巧分步生成别一次到位。先让模型生成基础形状确认没问题再加特征。因为LLM在长代码里容易忘记前面的约束分步能显著降低出错率。3.3 生成结果的验证清单拿到STEP文件别急着用按这个清单过一遍实体有效性在CAD里打开看是不是单一实体solid body有没有报非流形或开放边界。尺寸核对用测量工具量关键尺寸LLM算错尺寸是常事尤其是涉及角度和三角函数的地方。特征位置孔、槽、凸台的位置对不对有没有偏到边上去。圆角/倒角有没有因为半径过大导致几何失败圆角面有没有破面。单位制STEP文件默认单位可能是米导入时注意缩放我遇到过生成的零件小了1000倍的。这套验证流程走下来大概能筛掉八成有问题的生成结果。剩下的两成要么手动修要么重新生成。4. 实测中的翻车现场与修复思路4.1 布尔运算失败最常见的生成成功但打不开这是最高频的问题。LLM生成的脚本语法没问题几何内核也执行了但导出的STEP打开是空的或者只有部分实体。根因通常是布尔运算的容差问题——两个面贴得太近比如距离小于内核的容差1e-7内核判定为重合但又不是完全重合运算就失败了。修复思路有三条。第一在脚本里显式设置容差CadQuery里可以用cq.Workplane的clean()方法清理几何。第二避免面贴面让特征和基础体有明确的重叠量比如孔的位置稍微往里偏0.1mm保证布尔运算有明确的相交区域。第三分步布尔别一次性做多个特征的并集/差集一个一个来出问题好定位。我实测下来第二条最有效。让LLM在生成脚本时把特征位置故意偏移一个微小量反而能提高成功率这听起来反直觉但工程上就是这么回事。4.2 尺寸理解偏差模型不是算错是理解错有一次我让模型生成一个M8的螺纹孔它给我生成了一个直径8mm的光孔。技术上没错M8的底孔确实接近8mm但工程上M8螺纹孔的标准底孔是6.8mm。这就是工程语义和字面语义的差距。修复方法是在提示词里把工程约定写死。别指望模型懂标准件的默认参数你要么直接给数值要么在prompt里附上标准表。我现在的做法是维护一个工程约定库把常用标准件的参数螺纹底孔、键槽尺寸、倒角标准都列进去生成时动态注入prompt。4.3 圆角导致的几何退化圆角是几何生成的重灾区。当圆角半径接近或超过相邻边的长度时圆角面会退化成一个点或一条线导致实体无效。LLM不懂这个几何约束它会老老实实按你给的半径生成然后内核报错。我的处理方式是在prompt里加约束检查如果圆角半径大于相邻边长的1/3自动减小到边长的1/3。让LLM生成带条件判断的脚本而不是硬编码半径。这样即使你给的半径不合理生成的几何也是有效的。4.4 API调用层面的坑关键词里有一堆API相关的报错我挑两个典型的说。no api key for provider route这类错误通常是provider配置和模型名不匹配。比如你配了DeepSeek的key但模型名写的是别的provider的路由就找不到。解决方法是检查配置文件里的provider和model字段是否对应。permission denied while trying to connect to the docker api这是权限问题不是Text-to-CAD本身的错。如果你把几何内核跑在Docker里需要把当前用户加入docker组或者用sudo。但生产环境别用sudo跑服务正确做法是配好用户组权限。5. 这套东西现在能用到什么程度边界在哪5.1 适合自动生成的零件类型根据我这段时间的实测以下类型生成成功率高、可用性好板类零件带孔、槽、倒角的平板成功率最高能到九成。轴类零件阶梯轴、带键槽的轴成功率七成左右键槽位置偶尔出错。法兰、连接件标准件变体配合参数表生成成功率八成。简单支架L形、U形支架带安装孔成功率七成。这些零件的共同特点是特征数量少、拓扑简单、参数化程度高。换句话说能用一张工程图说清楚的零件基本都能生成。5.2 目前搞不定的场景以下场景我建议你别浪费时间自由曲面汽车外形、消费电子外壳那种A级曲面Text-to-CAD目前无能为力生成的曲面质量根本达不到工程要求。复杂装配体多个零件的配合关系、运动约束模型理解不了生成的装配基本是散的。工程图标注尺寸公差、形位公差、表面粗糙度这些工程语义目前不在生成范围内。钣金件展开、折弯系数、K因子这些专业规则模型不懂。认清边界很重要否则你会对工具产生不切实际的期待然后失望。5.3 和传统参数化设计的关系我的判断是Text-to-CAD不会替代参数化设计而是给参数化设计加了一个自然语言入口。传统流程是人写参数→驱动模型新流程是人说需求→生成参数→驱动模型。中间那层参数化逻辑还在只是输入方式变了。对设计师来说这意味着重复性建模工作会大幅减少但设计决策、工程判断、创新造型的价值会更高。与其焦虑会不会失业不如把精力放在怎么用这个工具把自己从重复劳动里解放出来。6. 如果你想自己搭一套我的选型建议6.1 技术栈组合如果你要自己搭我推荐这套组合LLM层用支持函数调用function calling的模型方便结构化输出。国内可用的有智谱、DeepSeek等选你手头有key的就行。参数化层CadQueryPython生态文档全社区活跃。几何内核OpenCASCADE开源免费和CadQuery配合好。服务层FastAPI轻量适合做API封装。验证层自己写几何校验脚本检查实体有效性、尺寸、单位。这套组合我跑下来比较稳成本也可控。6.2 提示词工程的关键原则三条原则记住就行结构化输出优先让LLM先输出JSON格式的参数再转脚本比直接生成脚本稳定。示例要精选3到5个高质量示例比20个凑数的强。约束要显式所有工程约定、单位、容差都写进prompt别指望模型懂。6.3 一个最小可用的代码骨架import cadquery as cq from your_llm_client import call_llm def text_to_cad(prompt: str, output_path: str): # 第一步LLM生成CadQuery脚本 script call_llm(prompt) # 第二步执行脚本 namespace {} exec(script, namespace) result namespace[result] # 第三步校验 if not result.val().isValid(): raise ValueError(生成的几何无效) # 第四步导出 cq.exporters.export(result, output_path) return output_path这个骨架很粗糙但能跑通。实际用的时候校验和错误处理要做得更细。7. 几个我踩过之后才明白的经验最后分享几条实打实的经验都是文档里不会写的。第一条别追求一次生成完美。我一开始总想让模型一次生成完整零件结果反复失败。后来改成先生成基础体再逐步加特征效率反而高。这跟人建模的思路是一样的分步走每步验证。第二条把LLM当会写代码的实习生不是资深工程师。它写的代码你要审它给的尺寸你要核它做的假设你要确认。心态摆正了用起来就顺。第三条几何校验脚本比生成脚本更重要。生成错了可以重来但如果你没校验就把错误模型流到下游那才是灾难。我现在的流程里校验环节的代码量比生成环节还多。第四条单位问题会坑死你。STEP文件默认单位是毫米还是米不同内核不一样。我建议在导出时显式指定单位导入时也显式确认别偷懒。第五条保留生成日志。每次生成的prompt、脚本、结果、报错都存下来。积累一段时间你就能看出哪些描述方式成功率高哪些零件类型容易翻车这些数据比任何教程都值钱。Text-to-CAD这个方向现在还在早期工具不成熟、边界不清晰、坑很多。但它的价值是真实的——把设计意图到几何模型的距离缩短这件事本身就有巨大意义。早一点上手早一点踩坑早一点积累经验等工具成熟的时候你就是那个会用的人。