大模型+CadQuery：从自然语言到STEP文件的全流程实践-北京尧图网络

你输入一句“给我一个直径80毫米的圆盘厚度12毫米中心一个直径25毫米的通孔外圈均匀分布8个直径6毫米的沉头孔”十来秒之后系统返回一个可直接导入数控程序的STEP文件。三年前我听到这种需求第一反应是“这人怕不是没睡醒”但最近我亲手把这条链路跑通了而且效果比我预想的好得多。text-to-cad本质就是让大模型把自然语言描述翻译成参数化建模脚本再由几何内核算成实体模型。我选了CadQuery作为中间语言OpenAI和大模型聊天接口作为翻译器中间加了一道带安全校验的Python沙箱和一套错误反馈迭代机制。整套流程虽然听起来全是热门词堆叠但它已经不是一个只能跑demo的玩具而是能真正参与前期结构设计、批量参数化改型和创客快速出件的工程方案。这篇稿子把我的完整实现、踩坑记录、Prompt设计思路和排查经验一次写透适合正在研究AI辅助设计的工程师、创客以及想在公司内部搭一套“语言出图”工具的开发者。1. 整体设计与路线选择为什么是“LLM CadQuery”1.1 端到端生成模型的问题先聊一个容易被短视频误导的点很多Demo展示的是“文字直接生成Mesh模型”看起来更酷但做机械设计的人拿到那种结果往往没法用。端到端方向确实有代表工作比如DeepCAD这类模型把CAD建模过程中的命令序列当成序列生成任务来训练。你给它一个条件编码它输出一条简化过的建模命令流。问题在于它的命令空间做过大幅精简能表达的特征类型有限生成结果在拓扑上经常会出现非流形、自相交这类工程上不可接受的问题更别说模型根本不可编辑。你想改一个参数抱歉整个命令序列都得重新生成。隐式场、点云重建到B-rep拟合的方案我也关注过。这类方法在“看形状猜建模过程”上确实有进展但精度受限于网络离散化输出到STEP这种精确几何表达时需要对齐和拟合误差控制非常麻烦。对我这种做实际零件的场景来说生成一堆三角面片是灾难。1.2 脚本生成路线的优势反观“LLM生成CadQuery脚本”这条路线它把最难的问题偷梁换柱了几何计算部分完全交给OpenCascade内核大模型只负责写代码。这样做有几个实质好处第一输出天然可编辑。文本生成的是参数化脚本不是一坨死网格。设计完想改直径直接找脚本里的radius变量改了重跑重量参数自动更新。对工程师来说这比端到端模型输出的实体重要得多。第二精度由几何内核兜底。OpenCascade是双精度内核你给它libetal参数它就能算到微米级不会因为AI生成步长而损失精度。模型生成的结果可以直接进入后续CAM、CAE环节不需要网格修复和重拓扑。第三错误可追溯。代码错了有traceback迭代修复是确定性的。端到端黑盒模型错了你只能换种子重新生成碰运气而脚本路线可以把报错信息反馈给大模型让它自己修这是完全不同的调试体验。第四工程对接成本极低。CadQuery脚本就是Python可以塞进现有的自动化流水线、参数化模板库、版本管理仓库里。不需要独立部署一个专用推理服务不需要掌握训练框架。一句话概括端到端方法像是让AI直接画一幅油画脚本生成路线的定位是让AI给熟练建模师写操作指令再由建模师去执行。哪个更容易落地到制造业答案很明显。2. 环境准备、模型选型与Prompt工程2.1 CadQuery环境搭建与版本注意事项CadQuery是这套系统里唯一不可替换的底层依赖环境装不对后面全是白忙。安装建议优先走conda-forge因为它会把OpenCascade、pyOCCT这些二进制依赖一起解决conda create -n cq python3.10 -y conda activate cq conda install -c conda-forge cadquery如果你的机器上已经装了Python环境也可以用pip试试pip install cadquery当前CadQuery已经是2.x时代API跟文档站上的示例基本一致。但我强烈建议锁定一个具体版本再写代码不同小版本之间的API变化相当折腾。比如Workplane.hole(diameter, depth)的深度参数、cutThruAll()方法、polarArray()方法都是后续版本才稳定的你要是拿旧版本跑新代码报错报得莫名其妙。版本号在业务侧怎么处理我习惯在系统提示词里直接写明“以CadQuery 2.4语法为准”并在沙箱代码里引入cadquery.__version__打印生成记录里留痕。这一步能省掉非常多的无效迭代成本。另外如果你要在Jupyter Notebook里做前端演示我推荐装一个jupyter-cadquery它能在Notebook里直接渲染几何体体验比导出STL再拖进MeshLab好很多。稳定自动化场景我还是建议后端静默跑导出STEP和STL后统一走预览服务。2.2 生成模型选型对比大模型的选择直接决定生成代码的质量和成本。我实地对比过几条路线直接说结论。如果你在公司内部跑数据不出域是硬性要求那优先考虑私有大模型API。如果对数据不敏感、想最快跑通方案云端通用大模型API是最省事的。以我实测经验云端大模型的CadQuery代码生成准确率明显高于本地开源模型。原因是CadQuery这个库虽然不算冷门但训练语料占比依然有限。能力强的商业模型在预训练阶段见过的CadQuery社区代码更多生成时更少出现幻觉API。本地开源模型我试过Qwen2.5-Coder系列和DeepSeek-Coder系列效果受Few-shot示例影响极大。你给两个靠谱示例它就能模仿出七分像不给示例它就是灾难级输出。所以本地模型方案不是不能走而是你必须把Prompt工程做到位并接受更高的失败率来换取迭代次数。如果让我给一个稳妥的起步建议先用云端模型跑通整个管道验证业务价值再根据数据合规要求决定是否切到本地模型。别一上来就纠结部署先把流程串起来比什么都重要。2.3 系统提示词与Few-shot设计Prompt是这套系统里投入产出比最高的一块。我把完整系统提示词贴出来你拿去就能用再根据自己的业务描述习惯微调。你是一个专业的CAD建模助手。用户会用自然语言描述一个机械零件你需要生成一个完整的Python脚本使用CadQuery库构建该零件。严格遵守以下规则 1. 坐标系约定默认XY平面为底面Z轴向上。“顶部”对应Z正方向“底部”对应Z负方向。 2. 所有尺寸单位默认毫米不要做任何单位换算。 3. 代码必须导入cadquery最终结果必须赋值给变量result。 4. 只允许使用这些CadQuery APIWorkplane、box、circle、cylinder、extrude、cut、union、intersect、fillet、chamfer、hole、translate、rotate、workplane、faces、edges、vertices、vertices、center、polygon、polarArray、cutThruAll。 5. 不得出现os、sys、subprocess、importlib等模块不得执行文件操作或网络请求。 6. 输出格式只用python代码块不允许输出任何解释性文字。这个Prompt有五个关键设计点坐标系约定是必须写的。没有这个约定大模型会把“顶部”理解成Y方向生成的模型方向和你的预期相差九十度。单位强制声明也很重要。我在实测中发现它偶尔会脑补出英寸的预设导致模型大二十四倍以上。单位声明放系统提示词里比在用户输入里提醒更可靠。API白名单的价值是降低幻觉概率。CadQuery的类方法有一两百个模型真实记住的可能只有三四十个你把这几个高频API列给它它就知道该在这个范围里选幻觉API的频次大幅下降。输出格式要求代码块且不带解释。如果不约束模型会在代码前后夹杂“好的我来分析这个零件”之类的废话解析时容易污染代码块。Few-shot示例我一般放一到两个别贪多。放太多会让输出风格僵化模型的思路会被示例带着跑遇到跟示例差异大的需求反而表现下降。3. 端到端工作流实现从自然语言到STEP文件3.1 主流程代码下面这套代码是我在工程里实际在用的简化版本核心流程五个步骤文本输入、大模型生成代码、提取代码块、安全审计、沙箱执行并导出。import re import ast import traceback import multiprocessing from openai import OpenAI SYSTEM_PROMPT 上面的完整Prompt粘贴到这里 def extract_code(text: str) - str: match re.search(r(?:python)?\s*(.*?), text, re.S) if match: return match.group(1).strip() return text.strip() def generate_cad_script(user_desc: str, error_log: str ) - str: client OpenAI() if error_log: prompt user_desc \n\n上次生成的代码执行失败错误信息\n error_log[:500] prompt \n请分析原因重新输出一份完整的修正代码只输出代码块。 else: prompt user_desc resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: prompt}, ], temperature0.1, ) return extract_code(resp.choices[0].message.content) def run_in_subprocess(code: str, output_step: str): def _runner(q): try: ns {result: None} exec(code, ns) result ns.get(result) if result is None: q.put((error, 代码执行完毕但没有result变量)) return from cadquery import exporters exporters.export(result, output_step) q.put((ok, output_step)) except Exception: q.put((error, traceback.format_exc())) ctx multiprocessing.get_context(spawn) q ctx.Queue() p ctx.Process(target_runner, args(q,)) p.start() p.join(timeout60) if p.is_alive(): p.terminate() return error, 执行超时60秒 return q.get()这一步解决了几个关键问题子进程的方式保证主服务不会因为一段烂代码崩溃超时终止防止大模型生成死循环exec之后从命名空间里取result而不是靠打印捕获避免文本解析的脆弱性。3.2 代码安全沙箱不能什么代码都放进来跑大模型写的代码不能直接裸奔执行。你在本地试一试发现没问题是因为你信自己写的上下文。但大模型是概率生成器它真的可能写出import shutil; shutil.rmtree(/home/user/projects)这种代码尤其是当你给它提供的示例里恰好有类似操作时。所以安全审计必须在exec之前做。我从AST层面做白名单校验不准导入白名单之外的任何模块禁止调用eval、exec、compile、open、__import__这类危险函数。class SafetyError(Exception): pass ALLOWED_MODULES {cadquery, math} FORBIDDEN_CALLS {eval, exec, compile, open, __import__, input} def audit_code(code: str): tree ast.parse(code) for node in ast.walk(tree): if isinstance(node, ast.Import): for alias in node.names: top alias.name.split(.)[0] if top not in ALLOWED_MODULES: raise SafetyError(f禁止导入模块: {alias.name}) elif isinstance(node, ast.ImportFrom): if node.module and node.module.split(.)[0] not in ALLOWED_MODULES: raise SafetyError(f禁止导入模块: {node.module}) elif isinstance(node, ast.Call): func node.func if isinstance(func, ast.Name) and func.id in FORBIDDEN_CALLS: raise SafetyError(f禁止调用函数: {func.id})这个审计代码还有一个隐藏好处它能提前拦截掉模型输出的注释字符串里“假装”导入了危险模块的代码块这类情况其实很常见。模型会在代码里写# 这里可以导入os之类的注释不影响运行但审计不能放过真正的import节点以外的字符串。另外补充一个实践不要在主进程里直接跑exec。Windows下多进程需要放if __name__ __main__:保护否则子进程会递归启动你自己这个问题我踩过一次排了半天才发现是Windows的spawn机制在捣乱。3.3 错误反馈迭代机制与成本控制大模型第一次生成的CadQuery代码能一次跑通的概率我实测只有四成到六成。这个数字听起来低但通过闭环反馈可以大幅拉高成功率。核心逻辑很简单执行失败后把错误信息的traceback截取前500个字符连同用户原始描述一起重新发给大模型让它自己看报错、自己修。这样循环最多三次三次都失败才抛出异常。MAX_ATTEMPTS 3 def text_to_cad(user_desc: str, output_step: str output.step): error_log for attempt in range(MAX_ATTEMPTS): code generate_cad_script(user_desc, error_log) try: audit_code(code) except SafetyError as e: error_log str(e) continue status, msg run_in_subprocess(code, output_step) if status ok: print(f第{attempt 1}次尝试成功导出文件{msg}) return output_step error_log msg raise RuntimeError(三次迭代均失败建议调整描述或检查Prompt。)三个细节对成本影响很大。第一错误信息截断到500字符不然三次迭代下来token消耗会翻倍。traceback几百行模型真正需要看的是最后几行的异常类型和消息前面的栈帧预测对当前问题帮助有限。第二每轮请求带上上一轮的代码。不然模型有可能忽略错误报告重新按第一轮思路写一遍等于没修。第三温度参数调到0.1。生成代码场景和写诗不同确定性比创造性更有价值低温能明显减少无意义的输出变化。关于成功率我补充一个真实数据在固定Prompt和固定示例的前提下三次迭代之内跑通的概率在八成以上如果把同样的描述翻译成英文再跑成功率还能再高一截因为CadQuery生态的代码与英文Prompt的语义匹配度更高。如果对中英文混排的要求不高建议直接用英文描述输出需求。4. 高频问题排查与质量验证4.1 高频错误速查表这几个月跑下来我整理了一张高频错误表每个问题都对应一套解决套路。错误现象根因处理方案ValueError: No faces found选择器方向错误比如选Z但模型中该方向没有面常见于描述称“顶部”但模型方向生成在侧面检查模型轴向按Prompt约定强制Z轴向上或改用faces(cq.selectors.NearestToPointSelector((0, 0, 999)))CAD algorithm failed或布尔运算报错切割体与被切割体没有实际相交边界共面或间隙太小检查translate方向与距离人为让切割体多穿透0.01毫米尺寸巨大或极小模型脑补英寸或小数点识别错误系统提示词全大写声明“单位毫米”后处理检查包围盒尺寸超出0.1到10000毫米范围直接判定失败使用了不存在的API大模型幻觉比如编造.boxed()、.hole_extrude()严格维护API白名单审计AST发现白名单外方法调用直接报SafetyError执行超时模型生成大数组循环比如range(1000)逐个切孔AST检查循环次数上限超过500直接拒同时靠子进程60秒超时兜底输出为空但无报错模型只输出了解释文字没输出代码或代码块里没有result变量提取代码块后检查代码里是否存在result 没有则直接当作失败走迭代第六类问题非常隐蔽因为大模型会一本正经地输出“好的这是一个生成法兰盘的CadQuery脚本”然后空一行什么都不给。提取代码块的正则拿不到任何代码extract_code返回空字符串最终exec空代码不会报错但result为空。必须显式校验result是否存在这个校验放在审计里而不是exec里能节省一轮无意义的执行周期。4.2 结果质量验证别让AI做的东西直接上机床大模型生成的CAD脚本看起来能跑但几何质量不一定靠谱。特别是布尔运算、倒角、阵列这些环节容易出现肉眼看不出来的拓扑瑕疵。加工前必须做一次兜底验证我每次导出STEP文件后都会跑一段检查脚本。import cadquery as cq def validate_step(path: str): result cq.importers.importStep(path) part result.val() bbox part.BoundingBox() volume part.Volume() print(f包围盒尺寸: {bbox.xlen:.2f} x {bbox.ylen:.2f} x {bbox.zlen:.2f} mm) print(f体积: {volume:.2f} mm^3) if bbox.xlen 10000 or bbox.ylen 10000 or bbox.zlen 10000: raise ValueError(模型尺寸超过预设范围疑似单位错误) if volume 0: raise ValueError(体积异常可能生成了空壳或非实体模型)尺寸和体积是两个最便宜的指标。单位错误通过包围盒一眼就能拦下来体积为负数或者为零时模型多半是生成了壳而非实体加工必然失败。如果要做更严格的检查还可以遍历所有边的最小长度判断是否存在特征尺寸小于加工极限的细节。比如你的加工设备最小能切0.5毫米那生成一个0.01毫米的倒角边就没有制造意义。不过我不建议把这条做成硬性拦截因为CAD设计阶段很多特征就是示意性的它只需要满足设计意图延后到工艺评审阶段再过滤更灵活。4.3 扩展场景与我的经验做完基础管道之后我陆续接了几个业务场景一是设计前期的方案对比。工程师把需求写成两三句话系统自动出十来个结构候选批量导出STEP给仿真组。过去这个工作需要一个实习生干半天现在二十分钟就能出一轮结果。二是培训场景。新同事想学复杂特征的建模思路直接问系统“这个卡扣怎么画”系统给的CadQuery脚本本身就是最好的教学素材比翻教程视频快得多。三是参数化模板复用。我把常用结构做成CadQuery模板文件故意不在Prompt里写具体坐标描述性需求通过模型映射到模板参数这样生成的不是一次性代码而是和公司标准模板挂钩的实例化参数。踩过几次坑之后我个人最深的体会是这套系统的天花板不在模型能力而在模板库的积累。大模型对通用零件的理解很好但对公司内部特有结构、特有命名规范、特有工艺约束一无所知。你把公司自己的模板写成Few-shot示例喂给模型效果比任何通用Prompt都提分明显。它是一个典型的“越用越准”的系统刚开始会嫌弃它蠢当你积累上百个能跑的CadQuery片段后你会发现它在内部零件上的表现已经超过了任何一个通用聊天机器人。再分享一个小技巧把每次成功生成的“用户描述代码”对存进数据库。下次遇到相似需求先在库里做embedding检索把最相似的几个真实案例塞进Prompt模型参考的是历史上已经验证能跑的代码而不是虚无缥缈的泛化知识。这一步操作简单但对准确率的提升可能是成倍的。

大模型+CadQuery：从自然语言到STEP文件的全流程实践

相关推荐

Impeccable怎么用？从词义辨析到职场技能培养的完整指南

YOLOv8在火箭检测中的实践与优化

Visio 2010 UML绘图：模板模具、ShapeSheet与VBA导出避坑

更多资讯

Visual Studio旧版下载与多版本管理全攻略

X-Plane 11飞行数据监控：200+原生DataRef实时采集与边缘部署

AI Agent 缓存架构实战：Redis 会话状态、工具调用与分布式锁设计

联软科技获华为认证级伙伴资质的技术解析

从天才少女到小米22级：大模型技术人的价值跃迁路径

营销技能全景地图：从用户洞察到数据分析的完整能力体系

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？