用大模型写代码做高精度3D建模这个方向最近值得认真看。它解决的并不是“文字直接生成一个能看的模型”而是让大模型把自然语言需求转成可执行的建模脚本再由脚本程序生成高精度、参数化、可编辑的三维实体。核心价值一句话模型不是一次性生成的贴图而是“代码即模型”可以改尺寸、拆零件、进CAD、出工程图。这个思路绕开了直接生成三维网格的路线。传统AI生成模型通常输出点云、隐式场或网格视觉上很像工程上却很难用。代码生成路线把大模型最擅长的需求理解和代码生成与程序化建模的精确几何计算、参数化、可重复执行结合起来。后面我会按这个路径拆一遍先讲原理和对比再讲环境、实测、零件分解、常见排查最后给落地建议。1. 先看清楚为什么是“写代码建模”而不是“直接生成模型”1.1 传统AI生成3D模型的短板在哪里在计算机图形学里AI生成三维内容主要有几条路线文字或图片生成点云、生成隐式神经场再提取网格、直接生成三角网格以及这两年比较热的三维扩散模型。这些方法在可视化、概念设计、游戏资产预览里效果不错但一旦进入工程场景短板非常明显。第一个问题是拓扑不可控。直接生成的网格往往有密集且无序的三角形边缘不整齐表面可能有自交、空洞、非流形边。做渲染可以做3D打印切片、有限元仿真、CNC加工都会出问题。你很难把这个网格直接丢给一个CAM软件去加工因为几何内核不接受这种“看着像但内部乱”的网格。第二个问题是不具备参数化关系。传统生成模型出来的是一堆顶点坐标和面索引你想改一个孔的直径实际上代码里没有“孔直径”这个概念。它只是表面形状近似不是一套有逻辑的建模特征。想精确修改只能重新生成或手工修复成本很高。第三个问题是无法拆零件。复杂机械结构由多个零件装配而成每个零件有独立的约束、配合关系和公差。直接端到端生成一个整体网格模型里没有零件分层也就谈不上“可编辑零件分解”。即便在后处理里做网格分割也很难把每个零件的语义、尺寸、装配约束完整还原出来。传统生成方法并不是没有价值。在概念设计、数字内容创作、游戏资产草稿这些对精度要求不高的场景里它依然有不可替代的位置。但如果你要的是一个能编辑、能制造、能进入生产流程的三维模型直接生成网格这条路目前走不通。1.2 代码生成路线的底层逻辑代码生成路线的做法完全不同。你不让大模型输出三维文件而是让它输出一段建模脚本比如CadQuery的Python代码、OpenSCAD脚本或者Blender的Python API代码。建模脚本里明确定义了从哪里开始画草图、拉伸多少、倒角半径多少、哪个部分是一个独立函数。程序化建模的精度由几何内核保证长度就是长度角度就是角度导出的STEP文件可以直接被专业CAD软件识别。关键是代码里的所有数字都是可以改的参数。把变量放在文件顶部改一个数字整个模型的尺寸、装配关系都跟着更新。这就是“大模型写代码做高精度3D建模”的真正含义大模型负责把模糊需求翻译成结构和参数程序化建模负责把代码变成实体。AI不直接做几何而是做“需求转代码”。这一层转移让精度和可编辑性重新回到传统CAD的体系里。从计算机图形学的角度看这相当于把“三维内容生成”拆成了两个子任务语义理解由大模型完成几何计算由确定性算法完成。大模型不需要知道一条NURBS曲线的数学细节它只需要知道什么时候调用extrude、fillet、union这些操作。这样既避免了生成式模型在几何精度上的天然劣势也保留了AI处理自然语言的能力。1.3 谁适合用这个方案第一类是机械设计和产品设计的人。要做结构件、外壳、支架、法兰这类规则几何用这个方案可以快速从一段文字得到一个能修改的CAD模型。第二类是自动化设计方向的开发者。把大模型接到参数化建模库上实现“需求-代码-模型”的流水线。第三类是计算机图形学的研究者。代码生成提供了一个新的比较对象它不跟网格生成比谁的表面更平滑而是比谁的输出更接近工程可用。如果你只是想要一个好看的雕塑模型那这个方案不适合。它最适合的是几何关系明确、需要精确尺寸、需要后续编辑和拆分的场景。下面这张表能更直观地看到两种路线的差异。对比维度直接生成三维网格大模型写代码建模输出形式点云、mesh、隐式场可执行脚本、参数化模型几何精度近似依赖网格密度高精度基于几何内核可修改性差难改单一尺寸好改参数即可零件分解需要事后网格分割代码结构天然分层工程可用性偏可视化、游戏资产可进CAD/CAM流程适合形状有机曲面、自由形态规则机械件、结构件所以如果你要处理的是“一个带安装孔的电机支架孔距可以调”代码生成明显更靠谱。如果你要的是“一个像鲸鱼一样的摆件”那还是交给三维扩散模型更合适。2. 环境准备跑通自然语言到三维脚本需要哪些条件2.1 大模型怎么接入先解决一个问题用哪个大模型。这里不绑定任何具体厂商。你只需要一个代码生成能力较强的大模型可以是云端API也可以本地部署。两者的区别主要在数据隐私、延迟、显存资源和成本。如果是学习验证我建议优先用API方式因为流程短不容易在环境准备阶段被劝退。等确认整个链路没问题再考虑把模型部署到本地。本地部署需要关注模型大小、量化方式和推理框架显存不够就把量化等级降一档但代码生成质量可能略有下降。这里没有“一定最好”的选择只有“够用”和“不够用”。需要注意的是大模型只负责生成脚本它自己不执行脚本。真正把模型跑出来的是本地的CAD内核。所以即便你本地部署了一个很小的模型只要它能稳定生成格式正确的脚本建模效果就不会受影响。反而是那些代码生成能力强、但你不方便接入的云端模型如果因为网络、费用、数据边界问题没法用那就等于零。先把能稳定接入的方式确定下来再考虑“更好的模型”。2.2 建模内核怎么选目前常见的选择有三个。CadQueryPython库基于OpenCascade几何内核能用Python写参数化实体建模适合机械零件、装配体导出STEP/STL/AMF精度很高。缺点是安装体积大环境依赖稍重。OpenSCAD用类似编程语言的方式描述CSG模型适合规则几何和布尔运算文件小、启动快有命令行接口适合批量处理。缺点是不太适合复杂曲面界面也相对简陋。Blender Python API适合做可视化、动画、游戏资产和复杂表面建模也能参数化但工程精度和特征树不如专门CAD工具。我个人做高精度结构件的验证会优先用CadQuery。原因是它的建模思路更接近传统CAD先画草图再拉伸、旋转、开孔、倒角。而且Python生态方便接入大模型、做自动化校验和批量生成。如果你以前用过OpenSCAD也可以继续用只要大模型会写这门语言就行。2.3 最小环境配置这里给一个可以照做的参考。安装Python 3.9或更高版本创建虚拟环境安装CadQuery和相关依赖。如果用OpenSCAD就去官网下载对应安装包并把命令行工具加入PATH。开发环境用VS Code就可以装好Python扩展有代码提示排查大模型生成的脚本会方便很多。执行下面几条命令可以做基础验证python --version python -m venv venv source venv/bin/activate # Windows用 venv\Scripts\activate pip install cadquery python -c import cadquery; print(cadquery.__version__)openscad --version如果import cadquery报错先看是不是虚拟环境没激活再看Python位数、网络源。CadQuery安装包比较大因为它包含完整的几何内核这是正常现象不是卡死。磁盘预留2到3GB会比较稳。还要说明一下资源占用。单纯运行CadQuery脚本8GB内存的开发机完全够用CPU建模也不会很慢。真正吃资源的是“本地部署大模型”这一步。如果你打算本地推理一个代码生成模型尽量准备16GB以上内存并根据显存选择合适尺寸的量化模型。如果只是通过API调用本地不需要额外的GPU资源。这里最容易踩的坑是环境没隔离。有人直接把CadQuery装进系统Python后来又装了其他版本库结果互相冲突。我建议所有测试都在虚拟环境里做哪怕只是学习也要养成这个习惯。后面批量跑的时候环境隔离能省掉大量“在我电脑上明明能跑”的问题。3. 第一次实测从文字需求到高精度模型3.1 写好提示词的三个要素第一次测试别一上来就让大模型生成“一个复杂的减速器”。先选一个简单但带有特征的单零件比如带法兰套筒。这意味着你的提示词必须包含三样东西产品角色、几何需求、输出格式。产品角色告诉模型你是一个程序化建模工程师使用CadQuery。几何需求外径、内径、高度、法兰尺寸、是否圆角。输出格式每个零件是函数参数放顶部导出STEP和STL只给代码不要解释。写清楚单位也很重要。CAD里单位错了会非常麻烦。我会在提示词里显式写“所有尺寸单位默认为毫米”。这样可以减少很多后期返工。很多人忽略了一个细节大模型并不知道你要的文件名是什么。你不指定它就可能生成model.py、part.py、result.step。第一次测试时建议在提示词里把文件名固定下来比如“导出文件名为flange_sleeve.step和flange_sleeve.stl”这样执行后找文件更直观。3.2 生成CadQuery脚本并执行下面是一个提示词示例你是一个CadQuery建模工程师。请根据以下需求生成Python脚本。 需求带法兰套筒法兰直径60mm厚度5mm套筒外径40mm内径30mm高度15mm。 要求 1. 每个特征拆成独立函数便于编辑。 2. 所有参数放在脚本顶部。 3. 生成后导出STEP和STL文件。 4. 只输出可运行代码不要额外解释。大模型返回代码后保存为flange_sleeve.py执行python flange_sleeve.py如果一切正常目录下会出现flange_sleeve.step和flange_sleeve.stl。代码主体大致长这样但不是唯一写法import cadquery as cq # 参数区 flange_d 60.0 flange_t 5.0 sleeve_od 40.0 sleeve_id 30.0 sleeve_h 15.0 def make_flange(): return cq.Workplane(XY).circle(flange_d / 2).extrude(flange_t) def make_sleeve(): return ( cq.Workplane(XY) .circle(sleeve_od / 2) .circle(sleeve_id / 2) .extrude(sleeve_h) ) def assemble(): flange make_flange() sleeve make_sleeve().translate((0, 0, flange_t)) return flange.union(sleeve) if __name__ __main__: result assemble() cq.exporters.export(result, flange_sleeve.step) cq.exporters.export(result, flange_sleeve.stl)这段代码你不一定完全照抄只是用来理解“零件函数 装配 导出”的结构。实测时大模型生成的代码可能略有不同但只要结构对能跑通就算成功。3.3 怎么判断结果是否合格判断一个生成模型是否合格有几个标准。第一脚本能否无错执行这是底线。第二导出后能否被CAD软件正常打开而不是一个空文件。第三尺寸是否和需求一致。用FreeCAD、CAD Assistant或者其他软件打开STEP测量一下套筒内外径和法兰厚度。第四修改参数后重新运行模型是否按预期更新。第五检查零件树。如果导出的STEP里能区分法兰、套筒这两个实体说明“零件分解”初步生效。实测时最容易出现的错误是大模型生成了看起来很完整的代码但执行时因为API拼写错误、对象名错误而报错。这不是大模型能力不足而是代码生成场景中常见的“幻觉API”问题。后面会专门说排查方法。还有一点经验第一次跑通后不要立刻清理脚本。先复制一份留档然后把参数改掉比如法兰直径改成80mm再跑一次。这样做是为了确认代码真的和参数联动而不是恰好生成了一段写死的几何体。如果改参数后模型没变化说明这段代码不具备可编辑性需要回到提示词重新约束。4. 自带可编辑零件分解的实现思路4.1 零件分解的本质是代码结构化标题里的“可编辑零件分解”其实不是指模型生成后进行网格分割而是在代码层面预先定义好零件边界。每个零件是一个函数或对象有自己的参数、坐标系和建模步骤装配体由这些零件组合而成。这样带来的好处是你可以单独修改某个零件而不影响其他零件也可以把某个零件导出成独立文件单独加工或仿真。这和大模型直接生成一个整体网格有本质区别。网格分割是事后猜测代码结构是设计时就确定的。要让大模型具备这个能力核心在提示词约束。你要告诉它不要把所有特征写进一个执行到底的长函数里要按照零件维度拆分。很多模型默认会写“一段到底”的代码因为这样看起来流畅。但工程要求恰恰相反每个零件的边界要清晰函数要短参数要集中。4.2 如何约束大模型输出零件清单我常用的做法是在提示词里加一段“交付要求”。比如交付要求 - 先输出零件清单每个零件一行零件名、功能、关键尺寸。 - 每个零件一个独立Python函数。 - 单独写一个assemble函数把零件按装配关系组合。 - 每个函数都接受参数参数默认值放在顶部。 - 不要把一个零件内部的多个特征拆到多个顶层函数也不要跨文件。这样大模型就不太会把零件写散也不会把多个零件揉成一个复合体。它输出的代码天然带“零件树”后面的装配、导出、文档生成都方便。这里的关键不是提示词越长越好而是要把“边界”说清楚。到底什么算一个零件什么算一个特征不同人理解完全不同。比如“底座”和“底座上的螺丝孔”是零件与特征的关系不是两个零件。漏掉这层说明模型可能把每个孔都当成一个零件最后生成一大堆零碎函数。注意不要把零件和特征混为一谈。零件是装配级别特征是零件级别。这个边界在提示词里写得越明确输出越可控。4.3 一个典型装配体示例拿一个简单“L型支架”来举例。支架由底板、立板和加强筋组成。结构如下def make_base(): # 底板 pass def make_vertical(): # 立板 pass def make_rib(): # 加强筋 pass def assemble(): base make_base() vertical make_vertical() rib make_rib() return base.union(vertical).union(rib)实际运行时每个函数内部是CadQuery的建模步骤。因为每个零件都是独立函数你可以只改make_rib的尺寸然后重新执行脚本装配体自动更新。你甚至可以只导出某个零件的STEP文件做到零件级交付。真正的装配体还需要考虑相对位置。CadQuery里可以用translate、rotateOpenSCAD可以用translate和rotate组合。如果零件很多建议在每个函数里把坐标系先定义好例如“零件原点放在自己的左下角”这样装配时对接更清晰。再提醒一点装配体的实体如果通过布尔合并导出的STEP里可能变成一个整体肉眼看不到零件层级。如果希望保留零件树可以导出成STEP装配或者在文档里额外记录每个零件的尺寸和变换关系。这取决于你的下游需要。很多3D打印切片软件只需要一个STL整体但机械加工、BOM清单、装配仿真需要的是独立零件数据。5. 对比传统方法精度、可编辑性、复用能力5.1 几何精度与拓扑质量传统AI生成三维模型通常输出三角网格。网格的精度取决于面数面数越多越接近真实形状但文件变大、计算变慢而且表面仍然是离散近似。代码生成路线走的是CSG和B-rep几何体由精确曲面和实体定义。圆柱就是一个精确圆柱而不是几百个三角形拼出来的近似圆柱。这一点在“高精度”这个词上尤其重要。如果你要3D打印一个零件孔的直径是8.05mm还是8.10mm直接影响装配是否顺利。网格生成的模型需要再重建曲面才能用于制造而代码生成的模型本身就是CAD原生数据。从计算机图形学的角度说网格生成关心“看得像不像”代码生成关心“尺寸对不对”。这两个目标在工程场景里完全不是一回事。一个模型就算视觉上非常逼真只要关键尺寸偏差超过公差就没法进入生产流程。5.2 修改、复用和批量传统生成方法里你改一个模型通常需要重新推理。生成式模型没有“改一个参数”的概念想要一个尺寸不同的变体只能重新给条件结果还不一定连续。代码生成模型则完全不同所有尺寸都是变量。你只需要批量替换参数文件就能生成一系列规格。例如要生成10种不同法兰直径的套筒写个循环改参数就行而不是让大模型重新生成10次。这让它非常适合产品系列化设计和自动化批量建模。批量生成时要注意不是简单把参数写进循环就完事。还要考虑文件命名、输出目录、日志记录、失败重试。比如批量跑20个配置跑到第15个报错如果没有日志你就不知道前面哪些成功了哪些失败了。所以在批量之前一定要先把单条任务跑稳再谈并发和自动化。5.3 与网格生成和扩散模型的边界代码生成也不是万能的。复杂有机形状比如人物头像、雕塑、树木、地形用代码去描述会非常困难。这时候网格生成、神经辐射场、三维扩散模型反而更合适。换句话说这两类方法不是替代关系而是分工关系规则机械件用代码生成自由曲面用直接生成中间层可以用Blender脚本和程序化几何过渡。成本上也可以做一些对比。传统生成需要GPU推理代码生成主要消耗token以及本地脚本执行。如果你的大模型是API成本主要是token如果是本地部署则主要看显存和推理时间。对于批量建模token消耗会比网格生成小很多因为代码本身短而网格顶点数据非常大。这个判断可以作为一个方向参考实际成本以你的环境和计费方式为准。我建议不要陷入“哪种方法更强”的争论。实际项目通常不是纯机械件也不是纯有机曲面而是两者混合。一个产品外壳可能是自由曲面但内部卡扣、螺丝柱、定位孔全是规则特征。这时候可以先用三维扩散模型生成外壳概念再用代码生成内部结构件最后在Blender或CAD里合成。关键不是信仰某条路线而是清楚每种方案适合哪一层。6. 踩坑记录常见报错与排查顺序6.1 脚本能生成但执行报错这是最高频的问题。现象大模型给出了完整代码看起来逻辑没问题但python xxx.py一执行就报错。常见原因包括模块没装、API拼写错误、参数类型不匹配、CadQuery版本差异、文件路径不存在。排查顺序不要乱。先看报错第一行是ModuleNotFoundError还是AttributeError还是TypeError。如果是模块问题检查环境如果是属性问题把报错中的API名称复制到文档或搜索引擎里查一下确认这个版本里到底有没有这个方法。很多“幻觉API”就是在这里暴露的。不要在报错后直接让大模型重新生成一版那样可能换一种错法。先把报错信息原样贴回去让它针对性修复同时提供你本地的CadQuery版本。给模型足够上下文修复效率会高很多。6.2 模型尺寸和单位不对有时候脚本能运行也导出了文件但打开后尺寸离谱。比如本来40mm的圆变成了40英寸或者因为没指定单位大模型把直径写成了半径或者把毫米当成了米。这个问题靠肉眼看不出来所以要在流程里加入尺寸校验。生成后用代码读取实体边界框和预期尺寸对比。CadQuery里可以获取实体的BoundingBoxbbox result.val().BoundingBox() print(长, bbox.xlen, 宽, bbox.ylen, 高, bbox.zlen)如果边界框尺寸和需求不一致说明参数或单位有误。调整提示词里的单位约束比手动改每个数字更高效。6.3 零件分解不彻底有时大模型生成一个“巨型函数”把所有特征都写在一个表达式链里布尔运算一结束零件就变成一个整体。这样虽然也能用但和“可编辑零件分解”的目标相去甚远。解决办法不是修改代码而是修改提示词。在交付要求里强制增加“每个零件一个函数”并把“禁止合并多个零件到单个函数”写进去。如果还是不行可以给模型一个结构模板让它按模板填空效果通常更稳定。还有一个容易被忽视的情况模型确实把零件拆成了独立函数但装配时直接用union把所有实体合成了一个。如果下游需要单独零件就不能用union而应该生成一个装配体对象或者把零件分别导出成独立文件。提示词里要写清楚“装配体保留零件边界”而不是笼统说“组合在一起”。提示生成后检查导出文件的实体数量。如果只有一个实体说明布尔并集把零件焊死了如果有多个实体说明零件边界保留得比较好。6.4 大模型输出不稳定大模型天生有随机性。同一个提示词两次生成结果可能差异巨大。要稳定输出可以采取几个方法把temperature调低减少随机性。在提示词中给出固定结构比如“先零件清单再代码再导出”。生成后做自动校验不合格就重新生成或让模型根据报错信息修复。把常用提示词和代码模板沉淀成文件不让模型每次从零想结构。记住一点大模型是助手不是替代品。它擅长快速出草稿但最终的结构、正确性、版本管理需要你把关。尤其是机械设计领域一个尺寸错误可能意味着整个零件报废。AI生成代码之后必须有人工校验这一关。7. 从Demo到实际项目落地建议7.1 先单零件后装配体不要一开始就让大模型生成一个几十个零件的复杂装配体。先从单零件开始跑通“提示词-代码-建模-导出-打开”整个闭环。单零件稳定之后再逐步增加零件数量和装配关系。我见过不少失败案例问题不在大模型而是自己跳过了单零件验证直接上复杂装配最后报错信息根本分不清是几何问题还是代码问题。把范围缩小才能定位问题。7.2 把提示词沉淀成模板项目做久了提示词会反复使用。我会把角色定义、通用要求、交付格式单独放在一个系统提示词文件里根据需求再动态插入具体尺寸。这样既减少token也保证输出结构稳定。模板的核心是“稳定结构 可变参数”。固定句写死“使用CadQuery”“所有尺寸单位毫米”“零件函数化”“导出STEP/STL”可变部分是具体零件清单和尺寸。这样模型每次都知道自己扮演什么角色输出结构不会跑偏。7.3 用自动校验兜底批量生成时不能靠人眼一个个看。要写一个校验脚本自动检查STEP/STL文件是否生成且非空。实体边界框尺寸是否在允许范围内。布尔运算是否成功有没有报错。文件名是否符合命名规则。校验不通过就写入日志并触发修复流程。自动校验是批量任务的底线否则在模型生成和脚本执行之间夹着一个不可控的环节很难长期维护。一个比较务实的流程是先由大模型生成脚本再用静态检查工具扫一遍语法然后执行脚本最后用尺寸校验脚本复核模型。只有全部通过才进入人工确认。这个流程一开始看起来繁琐但能救命。7.4 模型选型与资源规划到了落地阶段模型选型会影响整个流程。如果你要处理敏感设计数据优先本地部署如果只是快速原型API足够。本地部署要算显存、内存、推理延迟和量化损失。API方案更省事但要考虑token费用、网络延迟和数据边界。无论选哪种我都不建议把“模型生成的脚本直接用于生产”。先让它生成再经过静态检查、自动测试、人工确认然后才进入正式零件库。这跟代码开发里“代码评审”是一个道理。最后别追求全自动。“需求进来模型一生成零件直接上机床”这种流程在目前阶段风险很大。更务实的做法是大模型帮你把80%的重复建模工作做完你负责校验和决策。把单零件跑稳把模板积累好后续的收益会很可观。