这次我们来看一个很实用的 AI 生成方向用大模型写代码做 3D 建模。注意这里的关键词不是“生成一个 3D 模型文件”而是“生成一段可以执行的 3D 建模代码”。用自然语言描述一个零件模型直接输出 OpenSCAD、CADQuery 或 Blender Python 脚本再由脚本引擎解析成可编辑、可拆解、可导出的实体模型。这个思路和传统文本生成 3D 的路线有明显区别。传统方法大多是让模型直接预测网格、点云或体素结果是一个“无法再修改的孤岛文件”而代码生成路线输出的是参数化建模脚本每个尺寸、每个孔位、每个倒角都是代码里可改的参数。标题里“自带可编辑零件分解”指的就是这种特性生成结果可以分成多个零件、多个布尔运算步骤而不是一个冻结的三角面集合。本文会按“思路分析 - 环境准备 - 启动部署 - 功能测试 - API 与批量任务 - 性能观察 - 排错清单”的顺序展开。如果你关心大模型能否用于工程级 3D 建模、显存门槛高不高、能不能接成接口服务、能不能批量出图出模型这篇文章可以直接看完再决定值不值得落地。1. 核心能力速览能力项说明项目方向大模型 程序化 3D 建模代码生成文本生成可编辑建模脚本核心能力自然语言描述转参数化建模代码、零件分解、装配关系生成、导出 STL/STEP 等格式与传统生成对比传统方法输出不可编辑网格/点云本路线输出可执行脚本尺寸和结构可二次修改硬件门槛取决于承载大模型的推理方式纯 API 调用不需要本地 GPU本地推理则取决于模型版本显存占用不确定需按实际选择的模型和推理框架测试代码生成类任务通常比图像生成温和支持平台Windows / Linux / macOS取决于所选的建模引擎与推理框架启动方式WebUI、命令行脚本、API 服务不同实现差异大是否支持 API可基于 FastAPI / Gradio 等框架自行封装或使用项目自带接口是否支持批量任务可以做成批量目录任务按提示词文件批量生成建模脚本适合人群机械设计、3D 打印、创客教育、零部件参数化设计、装配体建模从能力表可以看出来这个方向的优势不在“生成一个好看的雕塑”而在“生成一个能改尺寸、能拆零件、能进生产链路的工程模型”。如果你要做的是机械零件、外壳、支架、装配体这个路线比直接生成网格更符合实际需求。2. 与传统 3D 生成方法的对比在继续部署之前先理解为什么“用大模型写代码做高精度 3D 建模”比传统方法更适合某些场景。2.1 传统文本生成 3D 的主流路线传统方案可以分成三类点云生成模型输出一组三维坐标点需要后处理才能转成网格。体素生成模型输出 3D 体素栅格分辨率低的时候细节很差分辨率高的时候内存爆炸。神经隐式场 / 扩散模型直接生成网格效果直观但生成结果通常是单一闭合曲面很难拆成多个可独立编辑的零件。这些方法都有一个共同问题输出结果不可参数化。你拿到一个 OBJ 或 GLB 文件想改一个孔的位置只能回到网格编辑软件里手动拖拽。对于艺术类、角色类、场景类的 3D 内容这个问题还能接受但对于机械设计、3D 打印、装配体设计这就是致命缺陷。2.2 代码生成路线的优势大模型写代码做 3D 建模本质上是把“几何生成问题”转化为“程序生成问题”。模型不需要直接预测顶点坐标而是生成一段描述几何构造过程的脚本。这样做有几个明显好处精度高代码里的尺寸是精确数值不是采样出来的近似表面。可编辑修改代码中的长宽高参数模型会重新计算整个几何体。可分解程序化建模天然支持布尔运算、特征组合可以把一个装配体拆成多个零件逐一生成。可验证脚本由建模引擎解析如果语法错误或几何冲突引擎会直接报错便于定位问题。这些特征正好对应标题中的“自带可编辑零件分解比传统生成方法效果更好”。需要说明的是“更好”是相对于工程建模、参数化建模这类任务而言。如果目标是生成一个有复杂纹理的动漫角色模型代码生成路线不见得比扩散模型更合适。3. 适用场景与使用边界3.1 适合什么场景机械零件设计法兰、支架、齿轮箱外壳、传感器固定座这类零件形状规则、强调尺寸代码生成优势明显。3D 打印快速原型生成脚本后直接导出 STL 切片打印修改尺寸只需要改一个变量。装配体设计用代码表达“基座 上盖 螺丝孔 定位销”的装配关系实现零件级分解。批量衍生设计同一类零件只需要换一组尺寸参数就能批量生成多种规格。教学演示计算机图形学课程中用大模型展示“自然语言 - 程序化几何 - 实体模型”的完整链路。3.2 不适合什么场景高细节角色建模、生物建模、有机曲面建模。带有复杂 PBR 材质、纹理贴图烘焙的完整游戏资产制作。对拓扑结构有严格要求的实时渲染模型。需要物理仿真级网格质量的生产环节仍需人工检查。3.3 使用边界与合规提醒涉及 3D 建模和 AI 生成有几个边界必须提前讲清楚不要将未经授权的商业图纸、专利设计文件、他人原创模型作为提示词输入到在线大模型服务。如果设计数据属于公司保密信息建议优先使用本地部署的大模型推理服务避免数据外发。生成结果用于商业生产前必须对结构强度、尺寸公差、装配干涉做人工复核。涉及外观专利、商标形状、受版权保护的角色造型不允许直接生成并商用。4. 环境准备与部署启动这一部分的思路分成两条线一条是准备“承载大模型的推理环境”另一条是准备“解析建模脚本的 3D 工具链”。两条线缺一不可。4.1 基础环境检查清单先检查以下项目具体版本号以你选择的实现为准操作系统Windows 10/11、Ubuntu 20.04/22.04 或 macOS。Python 版本建议 3.9 及以上代码生成类项目通常要求现代 Python。GPU 与驱动如果使用本地大模型推理需要确认 Nvidia 驱动和 CUDA 环境如果只调用 API则不需要。磁盘空间大模型权重文件通常在数 GB 到数十 GB 量级3D 工具链占用较小但需要预留输出目录。端口占用WebUI 或 API 服务默认端口如果被占用需要提前准备替代端口。4.2 大模型推理环境如果你的目标是本地部署可以采用以下通用流程选择一个支持代码生成的对话模型并按模型要求下载权重。使用 vLLM、Ollama、Transformers 等推理框架加载模型。启动一个兼容 OpenAI 格式的 API 服务或者直接加载到 WebUI 中对话。如果机器显存有限可以选用量化版模型但需要自行验证代码生成质量。如果目标是快速验证效果也可以通过云端大模型 API 完成。注意区分“本地推理”和“API 调用”的边界后文给示例时会单独说明。4.3 3D 工具链准备推荐准备以下三个工具链之一用来执行和验证模型生成的建模代码OpenSCAD免费开源使用文本描述几何体适合验证“代码即模型”思路。CadQueryPython 库适合用代码构建参数化 CAD 模型导出 STEP 等通用格式。Blender Python API适合生成后直接渲染预览也能导出多种格式。下面是一段可以直接本地执行的 CadQuery 参考代码先手动运行确认工具链正常import cadquery as cq # 生成一个带四个角的圆形安装孔的基座 base ( cq.Workplane(XY) .box(80, 60, 10) .faces(Z) .workplane() .rect(60, 40) .cutBlind(-3) ) for x in (-25, 25): for y in (-15, 15): base ( base.faces(Z) .workplane() .center(x, y) .hole(6) ) cq.exporters.export(base, base_plate.step)运行成功后你会得到一个带安装孔、可用于装配的 STEP 文件。这就是“代码生成 3D 建模”的物理基础。4.4 启动示例不同项目启动方式差异很大这里给一个通用的 API 服务启动模板实际操作时需要按项目目录和入口文件调整# 示例启动项目自带 API 服务 # 实际命令需要按项目 README 调整 python app.py --host 127.0.0.1 --port 8000如果项目提供 WebUI通常会启动后自动输出一个本地访问地址例如http://127.0.0.1:7860建议启动前先确认模型权重路径是否正确、端口是否被占用。如果项目依赖本地模型服务还需要先启动推理框架再启动 WebUI 或 API。5. 功能测试与效果验证部署完成后不要急于接业务先用四组测试验证整个链路是否稳定。5.1 测试一自然语言描述生成参数化零件测试目的验证大模型能否把自然语言描述转成可执行的建模代码。输入示例设计一个矩形基座长 100mm宽 60mm高 10mm。基座上有四个安装孔孔的直径为 6mm分别位于四个角附近。操作步骤在 WebUI 中粘贴提示词。选择目标建模语言比如 Python CadQuery 或 OpenSCAD。点击生成等待模型输出代码。将代码保存为独立文件并执行。预期结果模型输出完整的、可运行的代码而不是“解释怎么做”的纯文本。代码中包含明确的尺寸参数、孔位置参数。执行后能成功导出 STL 或 STEP 文件。判断标准如果模型只输出文字说明不输出代码提示词里要明确“只输出代码”。如果代码执行报错说明提示词表达不够精确或模型对目标 API 不熟悉。5.2 测试二零件分解与装配体生成测试目的验证标题中的“自带可编辑零件分解”。输入示例生成一个简单的电机支架装配体包含三个部分底板、左支撑板、右支撑板。底板长 120mm宽 80mm高 8mm左右支撑板高 50mm。使用 CadQuery 实现每个零件单独导出 STEP 文件。操作步骤提交提示词。检查模型的输出结构是否按零件拆分。运行代码确认是否生成多个 STEP 文件。在 CAD 查看器中打开检查三个零件是否能装配。预期结果输出包含完整的装配体生成逻辑但不把多个零件合并成一个实体。每个零件有独立变量名、独立导出逻辑。代码中能看到移动、旋转等装配定位操作。判断标准如果生成结果是一个整体实体说明提示词没有强调“零件分解”。如果模型只生成一个零件说明需要补充每个零件的规格描述。这个测试是整个流程里最重要的一个因为它决定了生成结果能否进入装配设计流程而不是一张“只能看不能用”的模型图。5.3 测试三尺寸精度与参数化修改测试目的验证模型输出代码是否具备参数化修改能力。操作步骤先用“基座长 100mm、宽 60mm”生成一段代码。不重新让模型生成直接修改代码中的length 100为length 150。重新运行脚本。检查导出模型的尺寸是否同步变化。预期结果代码使用变量命名尺寸而不是写死的裸数字。修改参数后整个几何体重建且孔位、圆角等相对关系保持不变。判断标准如果模型输出的代码全是裸数字后续修改只能全文替换参数化能力较差。可以在提示词中要求“所有尺寸定义为变量”。5.4 测试四导出与预览验证测试目的确认生成的模型可以进入实际使用链路。操作步骤将生成的脚本导出为 STL 或 STEP。在 OpenSCAD、FreeCAD、Blender 或在线 CAD 查看器中打开。检查模型是否出现破面、重叠体、零厚度面。预期结果模型在查看器中正常显示。网格导出后尺寸与实际设置一致。没有明显的几何自交。常见失败原因生成的代码里使用了错误的坐标方向导致零件重叠。布尔运算顺序错误导致最终实体结构异常。尺寸单位理解错误比如把生成器默认单位当成毫米。6. 接口 API 与批量任务如果项目只提供 WebUI你可以自己封装一层 API如果项目本身自带 API测试方式类似。下面给出一套通用封装示例实际接口路径需要按项目文档调整。6.1 通用 API 服务封装示例from fastapi import FastAPI from pydantic import BaseModel import subprocess import tempfile import os app FastAPI() class ModelRequest(BaseModel): prompt: str language: str cadquery app.post(/generate) def generate_model(req: ModelRequest): # 这里需要通过项目提供的大模型接口获得代码 # 下面只是示意实际代码由大模型推理结果填充 code f# {req.prompt}\n# 模型生成的 CadQuery 代码 with tempfile.TemporaryDirectory() as tmp: script_path os.path.join(tmp, model.py) with open(script_path, w, encodingutf-8) as f: f.write(code) # 执行脚本并捕获错误 result subprocess.run( [python, script_path], capture_outputTrue, textTrue, cwdtmp ) if result.returncode ! 0: return {error: result.stderr} return {message: success, code: code} if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务python api_server.py注意以上是服务骨架真正的“大模型生成代码”环节需要接入项目实际的模型接口不能直接使用这段骨架完成生成。6.2 批量任务设计批量任务是工程落地中最常被问到的能力。最稳妥的做法不是“同时调用多个并发请求”而是“按目录顺序批量执行每个输出单独记录日志”。批量任务目录结构参考batch_input/ part_01.txt part_02.txt part_03.txt batch_output/ part_01/ model.py model.step preview.png part_02/ part_03/批量任务脚本骨架import os import requests import time input_dir batch_input output_dir batch_output api_url http://127.0.0.1:8000/generate os.makedirs(output_dir, exist_okTrue) for file_name in os.listdir(input_dir): if not file_name.endswith(.txt): continue prompt_path os.path.join(input_dir, file_name) with open(prompt_path, r, encodingutf-8) as f: prompt f.read() payload { prompt: prompt, language: cadquery } try: resp requests.post(api_url, jsonpayload, timeout300) result resp.json() # 保存生成结果 item_dir os.path.join(output_dir, file_name.replace(.txt, )) os.makedirs(item_dir, exist_okTrue) with open(os.path.join(item_dir, generated.py), w, encodingutf-8) as f: f.write(result.get(code, )) print(f[OK] {file_name}) except Exception as e: print(f[FAIL] {file_name}: {e}) time.sleep(2)这里有三个建议批量任务必须加失败重试逻辑单条任务失败不能中断整个队列。每一条任务要单独记录日志否则出问题后很难定位。建议在提示词文件头部加入明确的建模语言、尺寸单位、导出格式要求。7. 资源占用与性能观察关于资源占用这里不给死数字因为不同模型、不同推理框架、不同输入长度产生的差异很大。以“文本生成长度为 1000 token 的建模代码”为例重点观察以下几个指标7.1 显存与内存观察方法使用nvidia-smi观察 GPU 显存占用。使用top或任务管理器观察内存变化。使用推理框架自己的日志接口观察单次请求耗时。# 实时刷新 GPU 状态 watch -n 2 nvidia-smi7.2 影响性能的主要因素模型参数量参数量越大显存和内存占用越高。输入长度提示词越长首 token 延迟越高。输出长度代码越长整体生成耗时越长。并发数并发请求越多显存占用呈线性增长达到上限后会排队等待。量化等级量化模型可以降低显存占用但输出稳定性需要自行测试。7.3 降低资源占用的策略优先使用 API 推理本地只跑建模引擎资源开销最小。选用量化模型如果本地 GPU 显存有限优先尝试低比特量化版本。控制 max_tokens生成前预估代码长度不要无限制输出。限制并发批量任务建议单卡同时只跑 1 到 2 个请求。及时释放进程用完的推理服务、WebUI、脚本进程要主动关闭避免残留进程持续占显存。8. 常见问题与排查方法问题现象可能原因排查方式解决方案模型只输出文字说明不输出代码提示词缺少“只输出代码”约束检查模型输出首段内容在提示词中明确“不要解释只输出可执行代码”生成的建模代码执行报错模型对目标 API 语法不熟悉读取报错堆找具体函数名在提示词中给出正确的 API 使用示例代码能运行但模型尺寸不对单位理解错误检查提示词是否有“毫米”单位在提示词中明确“所有尺寸单位为毫米”导出 STEP 文件无法打开CadQuery 版本不匹配查看导出日志升级或固定 CadQuery 版本多个零件渲染后重叠缺少装配定位逻辑在 CAD 查看器中逐零件检查提示词中要求“每个零件使用独立变量并写清相对位置”API 调用超时模型生成代码太长查看请求耗时与日志限制 max_tokens或者将超时时间改为 300 秒以上WebUI 页面打不开端口被占用netstat -ano查端口更换端口启动本地显存不够模型版本过大nvidia-smi观察占用使用量化版本或调用远程 API批量任务执行几个后卡住线程或进程异常查看任务日志与进程数加失败重试单条任务超时后杀死子进程代码生成质量不稳定温度参数过高对比多次输出降低 temperature比如 0.1 到 0.3 区间9. 最佳实践与使用建议9.1 提示词模板化不要每次都临时写提示词建议沉淀一套固定模板工程化效率更高使用 CadQuery 生成 3D 模型要求如下 1. 所有尺寸单位为毫米。 2. 所有参数定义为文件开头的变量。 3. 按零件拆分多个零件分别导出 STEP 文件。 4. 只输出代码不输出解释。 5. 使用 {target_language} 实现。 具体需求 {prompt}把目标语言、需求说明、导出格式都标准化后续批量任务只需要替换{prompt}部分。9.2 分目录管理建议按以下方式组织工作目录3d_codegen_project/ models/ # 大模型权重或配置文件 prompts/ # 提示词模板 batch_input/ # 批量任务输入 batch_output/ # 批量结果输出 logs/ # 运行日志 scripts/ # 工具脚本日志文件命名带上时间戳例如batch_run_20250611_1530.log9.3 第一次先小参数验证正式大规模跑批量之前先用一个最简单的零件做全链路验证生成一段 1 到 2 个特征的代码。确认能导出 STEP。确认能在查看器中打开。确认尺寸正确。链路通了再逐步加大复杂度不要一上来就生成几十个零件的装配体。9.4 人工复核不可省略AI 生成的模型代码原则上都应该经过人工复核。重点检查尺寸是否符合设计需求。孔位、圆角等特征是否合理。零件之间是否干涉。材料强度是否满足使用场景。是否涉及他人专利或版权设计。10. 总结与下一步用大模型写 3D 建模代码是目前少有的、能把“AI 生成”真正接进工程设计流程的方向。它的优势不在花哨而在输出结果可以继续编辑、继续拆解、继续生产。核心能力上建议最先验证三件事自然语言转参数化代码是否稳定、零件分解是否完整、修改尺寸后模型是否同步重建。最容易踩的坑有三个模型只给解释不给代码、生成的代码 API 语法错误、尺寸单位理解错。前两个通过规范提示词解决第三个在提示词里写死“单位毫米”即可。下一步扩展方向可以考虑把批量任务接入你的内部系统按 SKU 自动生成不同规格的零件模型把 API 服务接到设计工具插件里实现“对话即建模”或者把生成结果接入自动标注流程为每个零件自动生成 BOM 表。建议收藏备用后期做 3D 打印或结构设计时这条链路会非常顺手。