做CAD自动化这些年我一直在琢磨一件事能不能让设计软件听懂人话。比如你敲一句在原点画一个直径50的圆它就直接给你画好你说把这50张图纸里的标题栏全部改成新格式它就批量处理完。这个方向现在有个专门的名字叫text-to-cad。它不是什么玄学本质上是把自然语言翻译成CAD能理解的图形指令再通过程序自动执行。这篇文章我就把这条技术路线从头到尾拆一遍从原理到选型从最小可用的代码实现到真实生产环境里的坑通通讲透。适合三类人看被重复绘图折磨的机械/建筑设计师、想给公司做CAD二次开发提效工具的工程师、以及纯粹对语言驱动设计感兴趣的效率控。1. text-to-cad的本质不是魔法而是三层映射1.1 一句话说透这个概念text-to-cad字面意思就是文字转CAD。但别把它想象成科幻电影里那种——你说一句给我设计一栋别墅软件就变出一套完整的施工图。那是AGI干的事离我们还远。现阶段真正能落地的text-to-cad解决的其实是更具体的需求把结构化的、带参数的文本描述转换成可编辑的CAD实体集合。举个例子你在文本里写M12螺栓长度50mm系统自动在图纸里给你画好螺栓的俯视图和主视图你写距左边界30mm处画一条垂直中心线系统自动换算坐标并落笔。这些指令背后都是有明确规则的不是靠猜。我自己的理解是text-to-cad的核心价值不在于理解语义而在于消除从需求到图纸之间的翻译损耗。设计师脑子里的想法是语言空间想象CAD软件能识别的是坐标实体类型参数。这两者之间原本隔着键盘鼠标的操作成本text-to-cad就是把这个成本压缩掉。1.2 三层映射结构语言层、规则层、图形层一个能用的text-to-cad系统内部一定分三层。我画个简化模型给你看第一层语言层意图理解。这层负责把用户输入的文本拆解成语义单元。比如在(10,20)处画半径5的圆要识别出动作是画圆、位置是(10,20)、半径是5。这一层可以做得简单用正则表达式匹配也可以做得复杂用大模型做意图识别。关键是产出一个结构化的指令字典比如{action: circle, center: [10, 20], radius: 5}。第二层规则层约束解析。这层是关键它把语言层产出的结构化指令结合CAD的几何规则、图层规则、绘图标准翻译成真正的绘图动作序列。还是上面的例子规则层要做的事情包括这个圆画在哪个图层线型是实线还是中心线是按毫米还是英寸计算需不需要自动标注尺寸这些规则决定了图纸符不符合规范。第三层图形层实体生成。这层跑在CAD内核上把规则层给出的绘图动作逐条执行生成真正的点、线、圆、弧、多段线等实体写入DXF/DWG文件或者通过API直接操作打开的CAD软件。三层缺一不可。市面上很多翻车的文字转CAD工具问题都出在只做了第一层或者第一层和第三层之间没有规则层约束导致生成的图纸一塌糊涂——圆画出来了但图层是乱的尺寸对了但线型全错。1.3 和传统CAD操作的根本差异传统CAD操作是人直接操作软件眼睛看着屏幕手动输入命令或者点击菜单。这个过程有三个痛点慢、重复、不标准化。同样一个法兰盘每个人画出来的图层命名可能不同线宽可能不同标注风格可能不同。text-to-cad把操作从人找命令变成命令找人。你不需要记住c是画圆、rec是画矩形、L是画直线你只需要用自然语言描述需求剩下的交给规则层去匹配。更重要的是一旦文本描述和图形生成之间的映射关系确定下来同样的描述在任何项目里执行产出的图纸都是一模一样的标准样式。这就解决了企业最头疼的图纸规范化问题。2. 实现text-to-cad的几条主流技术路线2.1 规则解析路线最成熟、最可控规则解析是text-to-cad的正统路线。它的核心思路是用正则表达式、语法分析器或者简单的状态机把用户输入的自然语言指令解析成固定格式的参数表。我早期做过一个小工具就是专门处理画孔指令的。用正则提取关键信息import re pattern r(?:在)?\((\d)[, ](\d)\)(?:处)?(?:画|绘制)(?:一个)?(孔径|孔|圆)(?:直径|半径)?(\d)?只要用户输入符合约定格式就能提取出坐标、孔类型和尺寸。这种方法的好处是完全可控不会出现意外输出适合处理命令式、命令项明确的输入。坏处也很明显它本质上不是理解自然语言而是匹配自然语言。用户必须按照某种约定俗成的句式输入稍微曲折的表达就识别不了。针对这个弱点我后来在规则层加了一个同义词表和句式模板库。比如画一个直径50的圆和做个圆直径给到50这两个句式先做一遍归一化处理统一转成ACTION:DRAW_CIRCLE|DIAMETER:50再进解析器。这样识别的容错率高了不少而且不需要引入重型依赖。2.2 参数化模板路线适合标准化零件如果你仔细想想工厂里80%的图纸其实都在重复画相似的零件。法兰盘几百种规格但每种规格就是孔径、孔数、外径、厚度这几个参数在变。这个时候强行上自然语言解析其实是杀鸡用牛刀不如直接上参数化模板。参数化模板的思路是提前把一个系列零件的图纸逻辑写成模板模板里每个尺寸都是变量。text-to-cad系统要做的事情就是从用户文本里提取出那几个变量的值往模板里一填自动生成图纸。比如你做一个标准法兰的模板用户输入PN16法兰DN50系统查表得到公称直径50对应的外径165mm、螺栓孔直径19mm、螺栓孔数4个然后自动驱动模板生成完整的法兰图纸。这本质上是文本 → 参数 → 模板实例的管线全过程没有歧义生成速度快而且图纸质量比人工画的还稳定。我就是靠参数化模板帮一个阀门厂做了套选型出图工具原来一个技术员画一张阀门图纸要半小时现在在系统里输入几个参数图纸和BOM表一起出来30秒搞定。这个路线特别适合产品系列化程度高的制造业比如紧固件、管件、阀门、电机底座。2.3 大模型辅助路线前沿但可控性存疑随着大语言模型火起来很多人开始尝试让大模型直接从自然语言生成CAD代码比如生成Python脚本用ezdxf库画图或者从自然语言生成参数表再驱动CAD。这个方向确实有想象力我身边也有团队在做类似的概念验证。但我要泼一盆冷水截至目前大模型直接生成图纸的路子还处在玩具阶段。原因有三。第一几何推理能力还不可靠模型很容易在一些需要强空间想象的环节出错比如复杂的相切关系、三维投影关系。第二输出不可控同一个需求换个问法生成出来的图纸可能就有细微差别这在工业场景里是致命的。第三误差不可追溯——生成的代码如果说错了画错了排查起来比人工画错难多了。当然大模型在这个链路里不是完全没用。我现在更看好的是人机协作的混合模式用大模型做意图识别和参数提取的前端把用户的自然语言翻译成结构化指令再把这些指令丢给底层的规则引擎和参数化模板去执行。这样既利用了语言模型的泛化能力又保住了规则层和图形层的确定性。这个混合模式我判断会在未来两三年里成为text-to-cad的主流落地形态。2.4 脚本自动化路线无数工程师已经在用的野路子严格来说脚本自动化不完全算text-to-cad但我必须把它单拎出来说因为现实中大量的人就是这么干的——写Python脚本调用ezdxf库或者pyautocad库去批量生成、批量修改CAD图纸。这种方式虽然没有自然语言界面但它是text-to-cad最扎实的地基。你写的每一行脚本本质上就是在把你脑海里的文字需求变成代码再变成图形。我自己日常工作流里最常用的是ezdxf库。它是纯Python实现不需要本机安装AutoCAD就能读写DXF文件非常适合批量处理。后面第3节和第4节的实操我都会基于这个库来展开。3. 手把手实现一个最小可用的text-to-cad系统3.1 为什么选Python ezdxf这套组合市面上能操作DXF/DWG的库选择不少AutoCAD的ActiveX接口、python-dxf、ezdxf等。我最终选ezdxf作为主力理由有三个纯Python实现安装零负担pip install ezdxf就能用不需要装AutoCAD也不依赖Windows COM环境。这意味着它可以在Linux服务器上跑可以塞进CI/CD流水线里做图纸自动生成和检查。DXF格式是开放的文本格式而DWG是封闭的二进制格式。DXF虽然官方文档复杂但ezdxf已经把底层解析做了封装你只需要关心实体层面的操作。社区活跃文档齐全遇到问题基本都能查到示例。当然它有个绕不开的限制原生不支持DWG格式。但实际工作中我们可以让用户把DWG转存成DXF再处理或者用ODA File Converter做批量格式转换这个后面我会详细讲。3.2 环境准备从零搭起来先装依赖。我建议用虚拟环境防止污染系统Pythonpython -m venv cad_env source cad_env/bin/activate # Windows下是 cad_env\Scripts\activate pip install ezdxf装完之后可以快速验证一下import ezdxf print(ezdxf.__version__)能正常输出版本号说明环境就绪了。我用到的ezdxf版本是1.3.x这个版本对Python 3.8到3.12都有很好的支持。如果你要处理中文标注建议额外安装一个中文字体文件并注册进ezdxf的字体系统后面第5节我会专门讲这个坑。3.3 核心代码把画一个半径50的圆变成CAD实体我们来写一个最简单的text-to-cad引擎。它接收一段文本输出一个DXF文件里面包含用户想要的图形。先定义一个指令解析函数import re import ezdxf def parse_command(text): 解析输入文本返回结构化指令字典。 支持格式 - 画一个半径50的圆圆心在(10,20) - 在(0,0)到(100,50)画一条直线 - 画一个矩形左下角(0,0)宽100高50 # 归一化处理全角转半角、去除多余空格 text text.replace(, ().replace(, )) text re.sub(r\s, , text.strip()) # 提取坐标对 (x,y) coord_matches re.findall(r\((\d(?:\.\d)?)[,](\d(?:\.\d)?)\), text) coords [(float(x), float(y)) for x, y in coord_matches] # 判断动作类型 command None if 圆 in text or circle in text.lower(): command circle elif 直线 in text or 线段 in text or line in text.lower(): command line elif 矩形 in text or rectangle in text or rect in text.lower(): command rect # 提取半径或宽度高度 radius None r_match re.search(r半径\s*(\d(?:\.\d)?), text) d_match re.search(r直径\s*(\d(?:\.\d)?), text) if r_match: radius float(r_match.group(1)) elif d_match: radius float(d_match.group(1)) / 2.0 width None height None w_match re.search(r宽\s*(\d(?:\.\d)?), text) h_match re.search(r高\s*(\d(?:\.\d)?), text) if w_match: width float(w_match.group(1)) if h_match: height float(h_match.group(1)) return { command: command, coords: coords, radius: radius, width: width, height: height, raw_text: text }接着写生成函数把这个结构化指令变成DXF实体def generate_dxf(instruction, output_pathoutput.dxf): 根据结构化指令生成DXF文件。 doc ezdxf.new(R2010) msp doc.modelspace() cmd instruction[command] coords instruction[coords] radius instruction[radius] width instruction[width] height instruction[height] if cmd circle: # 圆需要圆心和半径。如果用户给了坐标就用坐标否则默认(0,0) if coords: center coords[0] else: center (0, 0) if not radius: raise ValueError(画圆指令需要提供半径或直径) msp.add_circle(centercenter, radiusradius) print(f已绘制圆圆心{center}半径{radius}) elif cmd line: if len(coords) 2: raise ValueError(画直线指令需要两个坐标点) msp.add_line(startcoords[0], endcoords[1]) print(f已绘制直线{coords[0]} - {coords[1]}) elif cmd rect: if len(coords) 1: base_point coords[0] else: base_point (0, 0) if not width or not height: raise ValueError(画矩形指令需要提供宽度和高度) # 用多段线画矩形 points [ base_point, (base_point[0] width, base_point[1]), (base_point[0] width, base_point[1] height), (base_point[0], base_point[1] height), base_point # 闭合 ] msp.add_lwpolyline(points) print(f已绘制矩形左下角{base_point}宽{width}高{height}) else: raise ValueError(f暂不支持的命令类型{cmd}) doc.saveas(output_path) print(fDXF文件已保存{output_path})最后写一个简单的CLI入口接收参数直接跑import sys if __name__ __main__: if len(sys.argv) 2: # 允许传入画一个半径50的圆圆心在(10,20) text_input .join(sys.argv[1:]) else: text_input input(请输入绘图指令) try: inst parse_command(text_input) print(解析结果, inst) generate_dxf(inst) except Exception as e: print(f出错了{e})保存为text2cad.py跑一下python text2cad.py 画一个半径50的圆圆心在(10,20)输出了output.dxf之后你可以用任意支持DXF的CAD软件打开查看。这个最小系统已经能实现文字 → 图纸的基本闭环了。别小看这几十行代码它就是text-to-cad的骨架——解析器加生成器。后面所有复杂功能包括批量处理、图层管理、标注自动生成都是在这个骨架上长出来的。3.4 扩展支持多实体、图层和标注真正干活的时候光画一个圆是不够的。我基于上面这个骨架扩展出了几个高频能力。图层管理在绘图行业图层就是秩序。我习惯把所有实体按中心线层、实线层、标注层分开。在ezdxf里这样做doc.layers.add(CENTER, color1) # 红色中心线层 doc.layers.add(OUTLINE, color7) # 白色实线层 doc.layers.add(DIM, color3) # 绿色标注层 # 创建中心线层上的实体 msp.add_line(start(-100, 0), end(100, 0), dxfattribs{layer: CENTER, linetype: CENTER})自动标注用ezdxf的add_linear_dim方法可以添加线性尺寸标注。这个功能在批量出图时特别好用省掉了大量重复的标注工作。dim msp.add_linear_dim(base(50, -10), p1(0, 0), p2(50, 0), dimstyleEZDXF) dim.render()文字注记在图纸上写技术要求、标题栏信息用add_textmsp.add_text(技术要求未注圆角R3, height3.5, dxfattribs{layer: DIM}).set_placement((10, -50))3.5 关于这套代码的实用补充我实际跑过很多次之后有几个细节必须提醒你。第一坐标习惯。CAD图纸里原点位置很讲究很多企业喜欢把原点定在图纸边框左下角。批量生成图纸时如果没注意原点位置后面合并图纸的时候会一堆问题。我建议在生成函数的入口增加一个origin_offset参数统一做偏移。第二DXF版本。ezdxf.new(R2018)和ezdxf.new(R2010)生成的DXF文件在新旧版CAD软件里的兼容性不一样。如果你要发给用老版本CAD的协作方务必用R2010甚至R2000格式。我吃了不少亏才总结出这个别迷信最新格式兼容性比先进性重要。第三中文文字注记。ezdxf生成DXF时中文字体会因为字体映射问题在CAD里显示成一堆问号。我的解决办法是在DXF文件的$FONTCONFIG头变量里指定一个CAD软件能找到的中文字体比如simhei.ttf。具体做法是在保存前手动设置doc.header[$FONTCONFIG] simhei.ttf这样在支持字体映射的CAD软件里文字就能正确显示了。如果你要发给别人的机器上预览这一步很关键。4. 从单指令到批量工作流真实场景里的落地姿势4.1 批量修改CAD文件text-to-cad从玩具到工具的关键一跃单个指令生成单个图纸只是热身把整个文件夹的图纸批量改掉才是text-to-cad真正值钱的地方。我接过一个很典型的活儿一家设计院要把过去三年的图纸统一改标题栏格式原来标题栏里的设计人校核人位置要调整还要新增一栏审定人。几百张图纸全部手工改的话一个人干两周。用脚本的话半小时跑完。核心逻辑是这样的import glob import ezdxf def batch_modify_titleblock(input_dir, output_dir): 批量修改DXF图纸的标题栏。 为了演示这里把标题栏文字全部加一个前缀VER:。 for dxf_path in glob.glob(f{input_dir}/*.dxf): doc ezdxf.readfile(dxf_path) msp doc.modelspace() # 遍历所有文字实体找到标题栏范围内的文字 for text_entity in msp.query(TEXT MTEXT): insert text_entity.dxf.insert # 假设标题栏在图纸右下角x 100000, y 1000 if insert[0] 100000 and insert[1] 1000: old_text text_entity.dxf.text if text_entity.dxftype() TEXT else text_entity.text new_text fVER: {old_text} if text_entity.dxftype() TEXT: text_entity.dxf.text new_text else: text_entity.text new_text # 保存到新目录保留原文件 output_path f{output_dir}/{dxf_path.split(/)[-1]} doc.saveas(output_path) print(f已处理{dxf_path} - {output_path}) batch_modify_titleblock(./raw_drawings/, ./processed_drawings/)这个脚本逻辑很简单但它展示了text-to-cad自动化的核心套路读取 → 遍历 → 条件匹配 → 修改 → 另存。实际项目里把找到标题栏区域这个条件做得更精细就能处理各种图纸格式。4.2 多图纸合并把散件图拼成装配图热词里有个cad图纸合并我简单说说自动化怎么干。图纸合并最常用的场景是把一个总装图对应的所有零件图合并到一个文件里方便归档和打印。手动合并的痛点在于坐标对齐——每张零件图的基准点都不一样合并后得手动移动到位。用ezdxf做合并的核心思路是把每个源文件的所有实体读出按基准点偏移后加入目标文档的模型空间。注意一定要处理图层、块定义、尺寸样式这些依赖项。我有一个取巧的办法直接用doc.modelspace()的实体作为根把其他文件的实体复制进来然后用doc.blocks统一处理块引用。复杂的代码这里就不贴了因为PDF排版有限。记住这个操作的关键流程就好实体级复制、图层重映射、样式重映射、坐标平移。这四个步骤缺一不可否则合并完的图纸轻则图层混乱重则图形错位。4.3 导出PDF和格式转换管线cad转pdf也是高频需求。生产环境里很多下游协作方不需要源文件只需要PDF用来打印或者批复。CAD软件自带打印到PDF功能但几百张图纸一张张打印太慢了。我建议的自动化管线是这样用AutoCAD的-PLOT命令行模式写一个脚本通过accoreconsole.exeAutoCAD 2015以后自带的无界面命令行工具批量打印DXF/DWG到PDF。如果不想依赖AutoCAD就用ezdxf先做图纸内容整理再转成SVG最后用通用PDF库打包。我实际用得多的是第一条路稳定可靠而且支持直接从DWG出PDF。accoreconsole的调用方式大致是accoreconsole.exe /i input.dwg /s plot.script其中plot.script里写的是AutoCAD命令行命令包括设置打印机为DWG To PDF.pc3、设置纸张大小、指定输出路径最后_PLOT执行打印。这种方式跑几百张图没问题就是注意脚本里的文件路径不能含中文否则偶尔会抽风。4.4 嵌入日常设计流程的姿势批量脚本再厉害如果它跟设计师的日常工作流脱节最后还是会吃灰。我的经验是text-to-cad自动化工具一定要嵌进设计师已经习惯的工具链里。具体来说有几种集成方式作为CAD软件内的插件用AutoCAD的.NET API或者LISP把text-to-cad的能力做成一个面板命令。设计师在软件里框选图纸范围输入一段文字指令插件就地执行。这是最顺滑的形态。作为独立批处理工具针对批量修改批量出图这类场景做一个小工具设计师把图纸文件夹拖进去选几个选项点执行。适合非软件用户的下游部门。作为服务接口把text-to-cad的核心能力封装成一个HTTP服务其他系统比如PDM/PLM系统可以调用。你输入物料编码系统自动返回图纸文件。这个适合企业级集成。我个人体会是先做批处理再嵌软件。原因是批处理工具见效快老板和技术员都能看到价值等大家认可了再把能力拆分成插件形式嵌入CAD体验上一个台阶。5. 适配生产环境前必须解决的五个坑5.1 第一个坑坐标系和单位不一致这个坑真的是血泪教训。DXF文件本身是带单位设置的但很多人不知道的是DXF的图形数据本身不带物理单位单位信息只存在于头部变量里。如果A系统的图纸单位是毫米B系统是英寸你把两个DXF直接合并图形会差25.4倍。处理方案在读取文件时显式检查doc.header[$INSUNITS]或$MEASUREMENT做统一换算。我习惯在所有工具入口都强制目标单位制比如def ensure_units(doc, target_units6): # 6表示毫米 current_units doc.header.get($INSUNITS, 0) if current_units ! target_units: scale_factors {1: 25.4, 4: 25.4, 5: 1.0} # 1英寸25.4毫米 factor scale_factors.get(current_units, 1.0) if factor ! 1.0: msp doc.modelspace() for entity in msp: try: entity.scale(factor, factor, factor) except Exception: continue doc.header[$INSUNITS] target_units这个函数能在一定程度上救回单位错乱的图纸。但注意实体内部的标注文字不会跟着缩放需要另行处理。5.2 第二个坑字体与shx字体大全的适配问题CAD圈搜shx字体大全的比搜text-to-cad的人多得多可见字体问题有多普遍。DXF文件里文字实体的字体信息通常记录的是一个字体名但实际渲染时CAD软件按自己的字体映射表去找。如果你在ezdxf里用了某个中文字体名但CAD软件里没装打开就是一堆问号。最稳妥的做法有两个思路。思路一在生成DXF时直接用简单实体代替复杂文字——能画线表达的就别用文字比如特殊符号用块来画不依赖字体。思路二如果必须用文字就统一指定CAD软件普遍自带的字体比如txt.shx、simplex.shx配合中文字体simhei.ttf或者hztxt.shx。另外提一个很多人不知道的细节DXF里指定字体的方式有两种一种是通过TX系列组码指定样式名一种是在$FONTCONFIG或$FONTALT里设置。ezdxf默认创建的文字实体用的是样式表里的默认字体你要确保样式表里设置的是目标机器上存在的字体。上面第3节提到的$FONTCONFIG就是一个全局替代方案能兜底解决大部分乱码。5.3 第三个坑精度和图层管理的隐性问题这些坑算不上坑但积累起来会坑死人。生成图纸时如果不注意精度设置后续做数值分析或者机械加工时就会出大问题。角度精度如果没有显式指定很多CAD系统默认保留小数点后4位但圆弧起点和终点角度如果四舍五入偏差过大在数控加工时会产生微小的断差。我用ezdxf生成圆弧时都会手动保留到小数点后8位。图层规范自动化生成的图一定要在规则层里就和客户约定图层命名规范比如OUTLINECENTERDIMHIDDEN这些英文层名还是轮廓线中心线这些中文层名。命名不规范后期做图纸归档系统的时候痛苦到怀疑人生。实体去重批量修改时如果脚本不小心重复执行了一遍同一位置会出现两条重叠的线段。肉眼根本发现不了但加工的时候刀具会走两遍浪费时间还容易出错。我写批量工具时都会加一步实体去重用坐标和图层信息作为去重键。5.4 第四个坑CAD软件安装与卸载的兼容性搜cad如何彻底卸载不影响二次安装的人八成都是装坏了。这个问题跟你做text-to-cad自动化其实有直接关系——因为你的自动化脚本很可能要在不同的电脑上跑而这些电脑上的CAD环境五花八门。ACCoreConsoleAutoCAD命令行核心对系统环境要求很高如果本机装过多个版本的AutoCAD有时候会出现COM组件注册混乱导致accoreconsole跑不起来。我的经验是在自动化机台上尽量保持纯净环境装一个固定版本的CAD禁用自动更新关闭不必要的启动加载项。如果真的出了卸载重装的问题记住几个关键点卸载后用微软的msizap清理残留注册表项删除C:\Program Files\Autodesk、C:\ProgramData\Autodesk等目录残留再用CCleaner清理一次预注册表最后重启再装新版。这流程虽然土但实测比各种卸载工具都靠谱。如果纯粹跑ezdxf其实不依赖本机CAD软件那就完全避开这些坑了。所以我给很多没有CAD正版授权的朋友的建议是能用ezdxf解决的别惊动AutoCAD。5.5 第五个坑DXF/DWG格式转换中的信息丢失DXF是文本格式DWG是二进制压缩格式两者之间转换时如果没有正确映射会出现信息丢失。尤其是**自定义对象、代理实体、扩展数据XDATA**这三类转换时最容易丢。我处理DWG转DXF的标准流程是用ODA File Converter这个工具由Open Design Alliance发布免费支持批量转换DWG到DXF。转换前要求源文件在CAD里清理过用_PURGE命令清理无用块和图层转换后检查一遍图层、块、标注样式是否齐全。检查信息丢失的方法很简单在ezdxf里读取转换后的DXF统计实体数量再和源DWG在CAD里看到的实体数对比。不一致就说明有东西丢了。6. text-to-cad的边界、场景选择与未来走向6.1 适合用什么场景标准化程度越高越好用text-to-cad的黄金场景一定要具备一个特征规则清晰、重复度高。给大家列几个我实际验证过的适用场景标准件出图螺栓、螺母、垫片、法兰、轴承座这类有国标/行标可查的零件文字输入型号直接出图带标注。批量图纸更新几十上百张图纸统一改标题栏、改图层颜色、替换某个标准件型号。这类工作人干又累又容易漏脚本干又快又齐。参数化选型出图从产品系列表里选一个规格自动生成对应的安装图、外形尺寸图。比如泵、减速机、电机这些。热词里提到的金林钣金cad版就是钣金行业的专业扩展——用参数化展开图输入折弯参数就能生成展开图。地形图简化热词里cad切地形也属于这类。把复杂的地形数据按指定边界裁切、抽稀、生成等高线用脚本处理比人肉框选高效太多。6.2 不适合用什么场景别硬上text-to-cad不是万能的以下场景用它就是灾难创意设计阶段方案阶段需要的是头脑风暴、快速迭代设计师的意图是模糊的、发散的。你让系统按模糊意图出方案它给你的是一个四不像。这时候手绘、CAD交互操作仍然是主力。复杂曲面造型自由曲面、汽车A面这些文字描述根本描述不清参数化建模软件如RhinoGrasshopper、Catia才是正道。需要反复协商的依赖关系一个零件的修改会牵动其他几十个零件的配合关系这属于PLM系统的范畴单纯text-to-cad解决不了。一句话总结需求越具体、规则越明确、重复度越高text-to-cad的价值越大。反之先别急着上。6.3 未来走向文本驱动设计会走向哪里从我的视角看text-to-cad正在沿着一条清晰的路径演进。第一个阶段是批处理自动化也就是我现在主要在做的事情——用脚本代替重复劳动。这个阶段已经成熟任何懂点Python的人都可以上手。第二个阶段是智能辅助设计自然语言交互界面大幅增强设计师说把这个孔阵列成3x4避开中间的加强筋系统能理解约束并自动完成操作。目前的大模型混合路线正在往这个方向走但离工业级还有距离。第三个阶段是设计意图的完整数字化。到那个时候从客户需求文本、技术协议、甚至会议纪要里系统就能提取设计约束自动生成方案图纸并完成校核。这个愿景很诱人但它需要的不只是算法突破还需要整个行业的图纸数据规范化、知识图谱建设。路还很长但值得期待。我个人目前最推荐的起步路径是先把Python ezdxf这套组合玩熟用它解决自己手上的重复性绘图的痛点。不需要一上来就搞大模型、搞SaaS平台先把画一个半径50的圆这种小事自动化了再一步步扩大战果。text-to-cad不是一个遥不可及的概念它就是你的第一段脚本第一张自动生成的图纸第一个省下来的加班夜晚。