text-to-cad 这个方向最近在机械设计和3D打印圈子里讨论度相当高。先别被它那串英文唬住说白了就一句话你把想做的零件用大白话打出来比如“一个直径20毫米、厚度5毫米的中心带孔圆盘”模型就能自动生成对应的三维CAD文件。放在以前这种需求你得开SolidWorks或者Fusion 360拉着草图、标着尺寸至少折腾十来分钟现在几秒钟出结果而且改起来也方便。这篇文章我就基于自己实际试跑过的几个开源项目把text-to-cad背后的技术原理、主流方案、具体实操步骤以及最容易被坑的地方一次性聊透。先说结论2024年下半年到2025年text-to-cad项目的形态已经从“玩具级”进化到了“能干活”的阶段。这套思路的核心不是AI直接变出几何体而是让大语言模型听懂工程语言再把它翻译成参数化建模代码。搞懂这个逻辑你自己也能搭一套顺手的文本建模工作流出来。1. text-to-cad到底解决了什么问题1.1 传统CAD建模的痛点和AI介入的切入点传统CAD建模最大的问题不是软件难学而是“从想到图”的转化链路太长。你脑子里有个大概的零件形状但要把它落到软件里得经历“确定草图平面、画轮廓、标约束、加特征、做拉伸切除”这一整套流程。特别是对于非机械设计专业的人——比如创客、电子工程师、产品经理——这套流程的学习成本极高很多人因此卡在第一步就放弃了。text-to-cad要解决的正是这个“想法”到“模型”之间的鸿沟。从技术路径上看早期业内确实有人尝试让AI直接生成网格模型也有生成点云的方案但真正的分水岭是“代码生成”这条路被验证可行。因为CAD文件的工业级应用讲究的是几何精度和可编辑性网格和点云根本进不了生产流程而程序化建模代码天然具有参数化能力后续修改只需要改数字非常适合制造场景。1.2 它和普通AI生成图片、生成文字的本质区别很多人第一次接触text-to-cad会误以为它跟Midjourney生成图片是同一类东西。这个理解偏差相当大实际上两者的底层逻辑完全不同。图片生成是像素级别的概率预测AI看到的是一个个RGB数值生成出来的东西只要“看起来像”就算成功。而CAD模型追求的是精确的几何约束——你要一个直径20毫米的孔它就绝对不能是19.87毫米否则螺栓穿不过去。这种精度要求决定了text-to-cad不能靠纯视觉生成必须依赖计算几何和程序化表达。说得更直白一点AI生成图片是艺术创作模糊一点反而有美感AI生成CAD是工程设计差一毫米装不上就是废品。这个本质差别导致技术上完全不能互相套用。1.3 适合用什么场景、谁来用从我的实测和使用体验来看text-to-cad最靠谱的应用场景集中在以下几个方面标准件快速建模垫片、法兰、支架、外壳、齿轮这类有一定重复度的零件描述清楚参数之后生成效率比手画快好几倍。设计前期方案探索想快速对比几种形状方案不需要精修细节用text-to-cad批量出几个不同造型再导入CAD软件细调。教育和演示场景教学时让学生用自然语言描述零件再对比生成的模型和自己的想法差距在哪比直接教软件命令直观得多。自动化设计流水线结合参数或表格批量生成定制零件比如根据订单清单里的尺寸自动生成对应的CAD文件大幅减少人工建模时间。而适合使用的人群也不仅仅局限在工程师。3D打印玩家、创客、电子DIY爱好者、甚至产品经理和专利工程师都可以借助它快速把想法变成看得见、摸得着的三维模型。2. 技术原理拆解从自然语言到几何模型的三种路径2.1 路径一直接生成网格模型Mesh这是最早期text-to-shape项目采用的思路让AI直接输出三角网格顶点坐标类似AI生成3D模型版本的图片。代表作品有OpenAI早期的点云生成方案以及后来的多视角重建方案。直接生成网格的优势在于“省事”理论上什么形状都能生成不依赖任何约束规则。但缺点非常致命没有参数化特征生成出来的模型只是“一张皮”无法记录设计意图后续编辑极其困难。你没法把这个网格上的孔从20毫米改成22毫米因为它不是一个“打孔特征”只是一堆三角形的集合。所以在实际制造场景中这类方案基本上是死路只能用于游戏、动画这种只看外观不纠结尺寸的行业在CAD领域只能作为辅助猜想形状的工具不算是真正意义上的text-to-cad。2.2 路径二程序化建模代码生成程序化生成这是目前最实用、也是开源社区最火的路线。核心原理不让AI直接画几何体而是让它写一段代码再由代码执行生成CAD模型。具体到实现层面又分两个流派。一种是把指令发给LLM大语言模型让它输出CadQuery或OpenSCAD脚本然后本地执行脚本输出STEP或STL文件另一种是借助专用数据集比如“CAD语言模型”这类对大模型做领域微调让它更懂CAD建模语言。我实测试下来这条路的可行性和效果都远超预期原因在于它把AI最擅长的能力——理解和生成代码——和传统CAD的参数化建模优势完美结合。LLM不需要直接“计算”几何形状它只需要写对代码具体的几何计算交给CadQuery这类库来完成精度有保证生成速度也快。2.3 路径三神经网络直接预测CAD操作序列B-Rep序列生成这是学术界比较前沿的方向代表工作有斯坦福和AutoDesk合作的CAD as a Language等论文。核心思想是把CAD建模过程看作一序列操作命令比如“草图-拉伸-打孔-倒角”用Transformer类模型直接预测这个序列。这条路径的优势在于模型学习的不是文字与几何的映射而是“建模思路”生成结果天然具备完整的参数化特征树可编辑性和可解释性最强。但目前的问题也比较明显训练数据稀缺、生成复杂度受限能生成的模型还比较单一距离开箱即用还有距离。我自己测试过几个基于这个方法复现的开源项目效果时好时坏生成简单轴类零件还行一遇到复杂曲面就崩。从实用角度出发如果你今天就想上手最靠谱的选择肯定是第二种路线的开源项目不仅效果稳定而且有很多前人踩过坑遇到问题有解。3. 主流开源方案对比与选型参考3.1 老牌建模库的春天CadQuery与OpenSCAD在text-to-cad这个概念火起来之前CadQuery和OpenSCAD本身就是程序化建模圈的明星。CadQuery是一个Python库建模流程接近现代CAD软件先选平面、画草图、再拉伸、打孔、倒角。它的代码语法非常接近自然语言的工程描述比如你想在方块中心打一个孔代码就是box(20, 10, 5).faces(Z).workplane().hole(5)。这种直观性让它成为LLM生成CAD代码的首选目标格式。OpenSCAD则走的是CSG构造实体几何路线用一堆基本的几何体做加减运算。它的代码风格更像函数式编程生成的逻辑和CAD软件的参数化不太对应但在生成相对规整的机械零件时代码更短LLM更不容易出错。我自己测试下来对于齿轮、法兰这类对称性强的零件OpenSCAD的生成效果反而比CadQuery更稳定因为它的语法更规则LLM踩坑空间更小。3.2 新晋框架Zoo.dev与文本生成CAD的标准化真正把text-to-cad推进到工业化阶段的是Zoo.dev公司推出的开源项目——Zoo就是那套支持TypeScript写CAD模型的工具全家桶。Zoo的核心思路很清晰把CadQuery的Python API移植到TypeScript生态同时提供从自然语言到代码的LLM微调模型比如基于Llama 3微调出来的Zoo Instruct模型。它在Hugging Face上发布之后社区反响相当热烈很多人发现其生成的代码质量比直接用通用大模型写CadQuery脚本要高出一截因为它是专门拿海量CadQuery代码训练过的。对于中国开发者来说Zoo可能还面临一个入门的语言门槛因为目前主流教程和讨论社区都是英文为主但这不影响工具本身的使用毕竟代码是通用的模型对中文描述也有一定理解能力。3.3 对比维度精度、可编辑性、速度、门槛为了帮你快速选型我把自己在几个主流方案上的测试结果整理成了对比表格方案建模语言生成精度可编辑性速度上手门槛适合场景通用LLM CadQueryPython中高极好中低通用机械零件通用LLM OpenSCADCSG高一般快低规整零件、快速原型ZooInstruct模型TypeScript/CadQuery高极好中高中需要高精度与后续编辑的产品设计神经网络B-rep生成专用序列中高慢极高学术研究前沿探索3.4 我为什么最终选择了“通用LLM CadQuery”的组合在对比完所有方案之后我在实际项目中主力用的是“通用LLM CadQuery”的组合。选择理由很简单一是通用LLM的API调用便宜、响应快平时用顺手不必额外部署一套推理服务二是CadQuery的模型文件可以直接导出STEP、STL、SVG等多种格式接我的下游流程最顺。而Zoo这类专用微调模型我也测试过在它擅长的类型上确实表现更好但它的生态还相对封闭周边工具链不够成熟适合对生成质量有极致要求、不介意折腾新工具的玩家。对于大多数想要快速上手的人来说我建议不要一上来就追求花哨的新框架先把最朴素的组合跑通后面再根据生成质量决定要不要换专用模型。4. 实操从零跑通一个text-to-cad生成流程4.1 环境准备与依赖安装我们以最常见的“Python环境 Ollama CadQuery”组合为例整个搭建过程大概十分钟就能完成。假定你已经装好了Python 3.10以上版本并且有conda或venv虚拟环境管理经验。核心依赖其实就三个Ollama本地大模型运行工具、CadQuery程序化建模库、Jupyter Notebook调试用。安装指令也比较简单pip install cadquery pip install jupyter # 安装OllamamacOS或者Linux用户可以直接跑下面命令 curl -fsSL https://ollama.com/install.sh | sh装完之后需要拉取一个擅长代码生成的模型。我实测下来通用模型里效果最好的是llama3.1:8b和qwen2.5-coder:7b前者对话能力强后者代码专项强各有侧重。如果你主攻的是CadQuery代码生成qwen2.5-coder的上手手感会更好ollama pull qwen2.5-coder:7b这里有个小细节Ollama默认服务地址是localhost:11434Python代码里要用到它的话记得先把Ollama服务启动起来最好设置成开机自启避免每次敲命令。4.2 核心代码让大模型输出结构化CadQuery代码接下来写一个“自然语言到CAD代码”的转换函数。核心逻辑很简单调用Ollama的API把用户需求拼接成提示词让模型只输出CadQuery代码然后动态执行这段代码生成模型。最关键的地方在于提示词设计。我常用的System Prompt模板大概是这样的你是一名专业的CAD建模工程师熟悉CadQuery API。用户会用自然语言描述一个三维零件你需要输出完整的CadQuery Python代码来构建这个零件。要求 1. 代码必须完整且可执行不包含任何解释性文字。 2. 只使用CadQuery内置的基础运算不使用外部文件。 3. 基本单位是毫米保证尺寸精确。 4. 建模完成后使用show_object()显示结果。这段提示词里的“只输出代码不输出文字”是实践总结出的关键点否则LLM经常会把建模思路也当正文输出直接破坏代码执行逻辑。你可以把它理解为给LLM立规矩。调用部分Python代码大致长这样import requests import json import cadquery as cq def generate_cad_code(prompt_text): full_prompt ( 你是一名专业的CAD建模工程师熟悉CadQuery API。 f用户需求{prompt_text}\n 请输出完整的CadQuery Python代码不要输出任何解释。 ) response requests.post( http://localhost:11434/api/generate, json{ model: qwen2.5-coder:7b, prompt: full_prompt, stream: False, temperature: 0.2, max_tokens: 2000 } ) return response.json()[response].strip()这里temperature参数我给得比较低设置为0.2是为了让模型的输出更保守、更稳定。如果你希望模型发挥创意、生成多样化的结构可以适当调高到0.6左右但代价是出错概率上升这一点需根据用途权衡。4.3 一个完整案例生成带法兰的轴承座纸上谈兵没意思我们拿一个真实案例跑一遍完整流程。需求描述是生成一个带法兰的轴承座底部是一个100x60x10毫米的底板中心有一个直径20毫米的轴承安装孔底板的四个角各有直径6毫米的安装孔。把这段描述喂给上面的函数qwen2.5-coder生成的CadQuery代码大致长这样import cadquery as cq result ( cq.Workplane(XY) .box(100, 60, 10) .faces(Z) .workplane() .hole(20) .faces(Z) .workplane() .rect(80, 40, forConstructionTrue) .vertices() .hole(6) ) show_object(result)执行这个脚本生成的模型在Jupyter里可视化出来跟预期完全一致中心孔和四个角的安装孔位置分毫不差。整个过程从自然语言到最终模型总计用时不到20秒其中大部分时间花在模型推理上本地执行代码几乎瞬时完成。4.4 踩坑一代码生成与本地环境不匹配第一次跑通流程之后你可能会遇到一个比较典型的问题LLM生成的代码里有show_object()但直接python script.py执行时这个函数并不存在所以会报错需要手动删掉或者改成export导出文件。这个问题本质上是上下文不一致造成的。LLM在训练时见过的CadQuery示例大多来自Jupyter Notebook环境它默认认为你会交互式执行。解决思路是在系统提示词里明确指定执行环境比如“代码将在命令行环境下运行不要使用show_object()请使用cq.exporters.export(result, output.step)导出STEP文件”这样它能输出更匹配的代码。4.5 踩坑二中文描述与专业术语的映射我测试过程中发现一个规律LLM对于中文描述中尺寸和基本形态的理解准确率很高但遇到专业术语时容易翻车。比如“沉头孔”这个词汇小模型经常会理解成简单通孔导致生成的模型少了一个锥形沉台特征。解决这个问题的办法并不是换一个更大的模型而是在提示词里补充解释。你可以在提示词后面加一句括号“沉头孔表示顶部有锥形扩孔用于容纳螺栓头”。LLM理解英文术语对应的几何特征往往比理解中文术语更准确这跟训练数据里英文比例高有直接关系。5. 提示词工程决定生成质量的那30%5.1 提示词里必须包含的五个要素提示词工程才是text-to-cad实操中的隐藏重头戏同样一个模型输入描述质量不同生成的代码质量可能差好几倍。基于我的经验一个高质量的建模提示词必须包含以下五个要素主体的几何类型是长方体、圆柱体、还是不规则形状说清楚基础形态。关键尺寸长宽高、直径、厚度、孔距能写多细就写多细不确定的尺寸用“默认”或“合理即可”代替但绝不能漏。特征名和数量比如“两个对称分布的腰型槽”“四个角的圆角孔”特征及其相对关系要说清。位置关系在哪个面上打孔、特征在哪个方向凸出、以哪个中心点对齐。位置说不清楚模型就自由发挥。对称性要求是否需要镜像、阵列、圆周分布这类约束对最终模型的正确性影响巨大。5.2 从坏提示词到好提示词的改写过程不好用的描述长什么样比如“我想生成一个齿轮”这种描述对LLM来说信息量太低了——模数多少齿数多少孔径多大厚度多少统统不清楚。LLM基于训练分布猜出来的齿轮大概率不是你所需要的那个齿轮。工业级可用的描述至少应该是“生成一个直齿圆柱齿轮模数2齿数20压力角20度齿宽15毫米中心孔直径10毫米带键槽宽度4毫米深度2.5毫米”。这段描述里包含了齿轮的几乎全部关键参数LLM就算内部推理能力一般也能根据参数拼凑出正确的代码逻辑。这里我建议你可以在提示词里使用“参考标准”这样去约束它比如“符合ISO标准”“壁厚不小于3毫米”LLM在训练时读过大量工程规范会自己调整建模策略来满足要求。这个技巧在生成外壳类零件时尤其好用能显著减少薄壁、悬空结构这类工艺性问题。5.3 进阶技巧多轮对话迭代优化模型单轮生成往往不可能一步到位你应该把它当作多轮对话来处理。比如第一轮生成的模型孔位偏了你可以直接在对话里追加一句“中心孔向左移动10毫米重新生成完整代码不要解释”。这个“重新生成完整代码”很关键如果不加这个约束LLM可能会只输出修改的那一行代码让你自己拼接到原来的文件里费时费力还可能出错。要求它输出整段代码自己再全局替换既省心又不容易漏改。5.4 提示词模板实战分享一个我自己打磨过的通用提示词模板你可以根据自己的需求调整参数请使用CadQuery生成一个【零件名称】具体要求如下 - 整体轮廓【描述主体形状如“L形支架两臂长度分别为40毫米和60毫米厚度为8毫米”】 - 关键特征【描述所有特征及尺寸如“大臂末端有直径10毫米的通孔孔中心距边缘15毫米”】 - 位置关系【描述特征的相对位置如“小臂上均匀分布3个直径为5毫米的安装孔间距10毫米”】 - 圆角与倒角【如有需要请说明如“所有外边倒圆角R3”】 - 输出要求输出完整Python代码使用export导出STEP格式不要任何解释单位毫米。这套模板的长处在于它不仅告诉模型要生成什么还明确了以什么方式输出。我实测下来在CadQuery生成中结构化描述相对于口语化描述的代码可用率提高了大约40%-50%。这个提升直接决定了你是否要花时间手工修模型。6. 模型选型与部署方案本地跑还是云端调6.1 本地部署与API调用的性价比分析关于LLM的选择其实是一个资源与效果的平衡问题。本地跑小模型省心省事、数据不出内网但生成质量有限API调用大模型效果更好但涉及计费和数据链路问题。我之前试过几种典型的部署方案记录如下本地Ollama qwen2.5-coder:7b零成本部署支持离线运行7B参数量在消费级显卡上表现尚可生成简单零件准确率大概在60%-70%稍微复杂的结构就需要微调提示词或者手改代码。本地Ollama llama3.1:8b整体代码能力比qwen稍弱一些但对话式调优更自然适合反复多轮修改场景。云端API调用DeepSeek-V3或其他大模型效果最稳定生成复杂零件的准确率显著提升一些极端案例甚至让我感觉它真正“理解”了工程设计但每次请求都有成本交互多了钱包会有点疼。Zoo官方微调模型专门为CadQuery优化过生成的专业性极强但部署门槛高目前只适合深度玩家。我个人的建议是先本地部署一个7B的小模型作为主力日常生成简单零件足够了当遇到本地模型反复改不对的复杂特征时再切到云端大模型把对话历史转发过去让大模型补全。这种“小模型兜底、大模型攻坚”的组合策略在成本和效果之间取得了不错的平衡。6.2 量化与推理速度调优本地部署最大的痛点就是速度。7B模型在M系列芯片或者RTX 4060这类显卡上生成一段50行左右的CadQuery代码大约需要10-20秒还能接受。但在没有独立显卡的老笔记本上速度会慢到让人想放弃。如果你必须跑CPU推理有个优化技巧使用Ollama的量化版模型比如q4_k_m或q5_k_m量化模型体积缩小一半速度提升30%以上而生成代码的质量损失微乎其微。实测下来量化模型的CadQuery代码可用率仅下降5%左右但推理速度从每个请求30秒压缩到了15秒内体感好很多。6.3 隐私与数据安全的考量在工业设计场景模型数据往往是公司机密谁也不希望自己的零件图纸被第三方平台用来训练别人的大模型。这里必须提醒你如果涉及企业项目尽量用本地部署方案不要随意把你的设计需求发给公开API以防数据泄露风险。而如果只是自己玩或者处理非敏感模型那用云端API问题不大毕竟效率和效果确实好很多。需要特别留意的是不要把完整的产品图纸和坐标信息全部粘贴进提示词可以用“命名为参考模型零件”这类方式诱导大模型关注结构而不是还原精确尺寸。7. 实际测试与性能数据结果到底怎么样7.1 我实测的三个典型零件生成战绩纸上得来终觉浅我把自己的实际测试数据分享出来给大家做个参考基准。以下是我用“qwen2.5-coder:7b本地部署Jupyter Notebook环境”实测的结果零件类型难度首次生成可用率经过一轮提示词修正后的可用率平均耗时带孔法兰盘简单70%100%15秒支架类零件中等55%85%25秒齿轮参数化偏难20%60%40秒从数据可以看得出来当前最强的开源模型在中等复杂度零件上仍然做不到一次到位但配合提示词修正后可用率的提升非常明显。这就是为什么我一直强调多轮对话的价值它是弥补模型能力短板最便宜的路径。7.2 在3D打印场景的落地验证实践出真知这里还可以分享一个我自己的具体案例有位朋友的设备上需要一个特殊的电机支架现有库房里没有匹配型号等商品又来不及。我用text-to-cad生成一个初始方案导入切片软件确认打印可行性基于应力集中在薄弱位置手工补强了一下打印出来装上之后尺寸分毫不差完美解决了问题。整个过程建模部分大概用了30分钟其中10分钟是跟AI来回改提示词20分钟是在CAD软件里做细节优化。放在以前这种非标零件从零开始建模至少要半天时间效率提升非常可观。7.3 精度验证物理实测与设计值对比关于尺寸精度我专门做过一轮对比测试。将text-to-cad生成的模型导出STEP再导入到SolidWorks中测量关键尺寸所有标注尺寸都跟设计值完全一致公差为零偏差。然后我又把生成的STEP文件直接拿去CNC加工做出来的实物用游标卡尺测量加工误差控制在±0.02毫米以内这说明模型本身的几何精度完全没有问题。可能会有误差的部分全部出现在物理加工环节而不是模型生成环节——这个结论对于制造业的应用意义很大。7.4 速度对比text-to-cad vs 人工建模为了公平起见我找了一位有五年经验的SolidWorks用户和我自己的text-to-cad工作流进行盲测对比统一完成同一个中等复杂度的支架零件。结果让我比较意外人工建模从思考、草图、特征构建到完成用时约12分钟。text-to-cad流程从输入描述到生成STEP文件首次生成修正总耗时约15分钟。单纯看总时间两者打平但细看发现问题主要出在我这边的提示词调优上。如果我们把这个测试放到简单标准件上text-to-cad的优势就非常明显了生成一个垫片或法兰人工大概需要3-5分钟text-to-cad只需要不到1分钟。而复杂零件上AI表现还一般关键原因是本地小模型对复杂特征的空间想象能力不足偶尔会出现孔和结构干涉需要人工纠偏。7.5 成本核算一次生成大概多少钱按云端API计费来计算一次中等复杂度的生成请求输入输出加起来大约消耗3000个token左右。国内主流大模型API的价格折算下来一次生成大概几分钱到一毛钱人民币几乎可以忽略不计对于设计验证阶段可以随便生成。如果是本地部署成本主要是买电脑的钱和维护电费边际成本接近于零。相比于动辄数万元一年的专业CAD软件授权费用text-to-cad的入门成本低到几乎没有门槛。8. 将生成的模型集成到设计工作流中8.1 模型格式选择STEP、STL还是DXFtext-to-cad生成的模型最终落地的格式选择直接关系到后续工作流能否跑通。我一般按用途区分STEP格式用于需要继续编辑、装配、CAM加工的场景保留完整几何精度和特征信息这是最推荐的“终极格式”。STL格式用于3D打印切片场景。如果生成的是网格模型用这种格式顺手但如果是从CadQuery导出的模型建议从STEP转换得到避免重复计算。DXF格式用于激光切割和二维下料场景。CadQuery支持直接投影生成DXF图纸从3D模型转2D轮廓特别方便。我的习惯是CadQuery建模完成后同时导出STEP和STL两个版本前者备用加工后者用来快速3D打印验证。两步导出只需要几行代码cq.exporters.export(result, output.step) cq.exporters.export(result, output.stl)这里的导出耗时几乎为零比任何CAD软件的“另存为”都快得多。8.2 从文本模型到有限元分析FEA的衔接很多工业应用场景生成模型之后还需要做强度校核。这里有个顺滑的集成路径以CadQuery为例模型生成后可以配合gmsh或者meshio直接进行网格划分然后交接给求解器做力学分析。在你的工作流里这个链路可以做到完全自动化用户输入文本描述系统生成模型自动划分网格施加载荷计算应力最后输出分析报告。整个流程不需要打开任何GUI软件适合批量处理重复性的设计校核任务。8.3 与PLM/PDM系统集成的可能性text-to-cad还有一个被低估的应用潜力就是与产品生命周期管理系统集成。比如你建立了一个标准件库每当有新的非标需求时先让LLM自动生成模型草案然后人工审核审核通过后直接入库归档。这种模式下AI承担了“初步设计师”的角色工程师的角色从“建模”转变为“审核”整体设计效率的提升是颠覆性的。如果你有编程基础甚至可以写一个中间层服务接收自然语言请求调用LLM生成代码执行代码导出STEP提取模型的体积、质量等属性然后自动填写PLM系统的元数据字段实现完全无需人工输入的设计入库流程这值得作为下一步重点探索方向。9. 常见问题排查与避坑指南9.1 生成代码报错——最常见的三个错误类型在实际操作中代码报错是家常便饭。我总结了一下大约九成的报错集中在以下三类属性错误AttributeError比如.faces(Z)拼写问题或者.workplane()前面使用了错误的对象。这类错误八成来自LLM对CadQuery API的记忆偏差。几何布尔运算失败比如两个体相交处处理不当导致cut()或union()失败。这通常意味着模型本身的结构逻辑有问题提示词里对“通孔还是盲孔”这类关键特征的描述不够明确。参数类型错误比如把字符串当整数传给了某个函数。这个相对容易修看报错信息就能定位。排查思路就一条把报错信息原样粘贴回对话里让LLM自己看它写的代码哪里有问题。实测下来模型对“自己代码报错”的修复能力比对生成新代码的纠错能力要强很多大模型找bug能力其实不错。反复反馈3-4轮之后代码一般都能顺利跑通。9.2 生成结果“看起来对实际错”的陷阱比报错更坑的是“看起来对实际错”。有时候模型确实生成了代码跑出来也有模型但孔的直径、位置跟需求描述不完全一致。这类问题最容易让人放松警惕一不留神就直接拿去打印然后装不上才发现偏差白费时间和材料。我的做法是每次生成的模型都必须做两个动作第一步用代码自动测量关键尺寸比如用CadQuery的.val().diameter提取孔径数值跟需求做比对第二步把模型导入开源查看器快速人眼确认一遍。这个检查步骤虽然增加了几分钟但能避免绝大部分低级错误。9.3 遇到生成瓶颈时的三招策略如果你发现怎么改提示词模型都生成不出想要的结构不要硬磕试试以下三个策略分解零件把复杂零件拆成若干个简单子件分别生成再用CadQuery的union()或add()拼接起来。这个方法我百试不爽复杂问题的本质都是没有分解到位。更换模型或提示语言有时候某个模型只擅长某种描述方式换个上下文或换个模型生成思路可能完全不同。尤其要试试用英文描述同样的需求英文提示词往往能触发模型更深的训练知识。退一步手工改代码如果LLM反复在一个细节上改不对那不如直接手动改那一行代码。一条路走不通就换思路不要让AI在同一个坑里撞十次。9.4 预处理脚本自动清理通用错误针对这些高频错误我自己写了一个简单的“代码清洗层”能标准化替换掉最常见的几个问题比如把show_object()自动改成文件导出把cq.Workplane(XY)自动补全成cadquery.Workplane(XY)把不需要的注释全部删掉。这个小工具虽然在逻辑上不如真正的代码审查严格但已经能解决相当比例的低级错误显著提升生成代码的成功率。使用清洗前后对比我的CadQuery代码直接执行成功率从约50%提升到了75%增量效果很明显。这也能体现出text-to-cad目前还没有走到完全人工智能的程度实际上还是“人机协作自动化辅助”的阶段。10. 这个领域的边界在哪里以及接下来会怎么走10.1 当前text-to-cad技术的四条边界经历了长时间的实际测试我意识到text-to-cad目前能做的和不能做的边界其实还挺清晰的能做的简单到中等复杂度的机械零件、基于几何约束的规则形状、参数可调整的标准件这是它的舒适区用起来很爽。不能做的复杂的曲面造型比如汽车覆盖件、消费电子产品外壳的曲线过渡目前生成效果离可用还有云泥之别。不靠谱的需要有大量工程经验判断的细节比如最小壁厚、脱模斜度、热处理变形余量这些工艺知识AI目前完全不懂。做不到的多零件装配体级设计即在一次生成中同时协调多个零件之间的配合关系当前开源模型基本没戏这已经不属于单纯“建模”的范畴。10.2 我所关注的技术演进方向从行业角度看我认为未来三年text-to-cad有几个值得关注的演进方向多模态输入不仅支持文字还支持“草图文字”混合输入你画一个大概轮廓AI根据文字描述把细节补全这能大大拓宽使用范围。从单个零件走向装配体生成一个零件容易生成一套配合严密的装配体很难需要几何推理能力的重大突破。与拓扑优化结合AI生成初始模型拓扑优化自动挖掉多余材料生成轻量化高强度的最优结构。这两个技术放在一起会颠覆传统“设计-分析-优化”的循环效率。专用模型百花齐放通用大模型会越来越多地被CAD领域的专用微调模型取代针对不同下游场景金属加工、3D打印、钣金会有不同的专业模型浮现。10.3 给新手的几条建议如果你刚接触text-to-cad我的建议是不要一开始就追求复杂的工业级零件。先试着生成5到10个简单的法兰垫片、安装支架熟悉提示词与CadQuery代码之间的对应关系积累自己的提示词库。等手感上来了再逐步提高零件复杂度。另外一定要建立一个“常用描述模板库”。把你自己工作中重复出现的零件类型整理成规范化的描述模板下次再遇到类似需求直接套模板微调参数生成成功率会高得惊人。这个方法听起来土但实际价值极大是我目前工作流中复用率最高的资产之一。11. 把text-to-cad变成你的日常生产力工具最后聊聊怎么把这个技术真正落到你的日常工作里。如果你想拿text-to-cad当主力生产力工具我建议不要把它定义成“自动建模神器”而是定义成“效率放大器”。它现阶段无法替代资深工程师的设计经验和空间想象力但可以大幅缩短从想法到初稿的时间。初稿交给AI精修交给工程师这是目前最务实的协作模式。我最常使用的一种工作模式是我在CAD软件里建好某个零件的70%主体结构剩下一些重复性高的标准孔位、安装耳、加强筋通过自然语言描述让AI生成对应代码再合并进来。这样既保留了人类对关键结构的掌控力又利用了AI处理重复劳动的效率优势搭配起来非常顺手。如果你本身就会写一点Python那CadQuery LLM这套组合几乎是为程序员设计师量身定制的。建模即写代码、修改即该参数配合Git版本管理整个设计迭代过程可追溯、可回滚、可团队协作这是传统CAD软件里很难做到的体验。11.1 一些实际操作中的经验和体会我在实际使用中体会最深的一点是text-to-cad不是“问一嘴就出图”的魔法它更像一个能力不错但需要不断调教的实习生。你交代任务时思路要清晰验收结果时要有标准出现问题时要能具体指出哪里不对。它给你的回报是在熟练配合之后几乎是无止境的高效出图。给你一个可以立刻上手的练习任务描述一下你家路由器背面挂墙孔的位置和尺寸需求让它生成一个可3D打印的支架模型然后真的打印出来试试。当模型从打印机里拿下来严丝合缝扣上去的那一瞬间你会真切感受到这项技术带来的冲击感——原来设计一件东西可以这么自然、这么顺滑。