企业官网建设流程全解析

1. 为什么text-to-cad在一夜之间从玩具变成了刚需

先聊个实际的场景。我前阵子帮朋友做一批非标零件的三维建模，对方给的需求只有一句话：“一个能卡进42mm标准铝型材槽里的直角连接件，厚度4mm，带两个M6沉头孔。”放到过去，我得打开CAD软件，建草图、约束尺寸、拉伸、打孔、倒角，一套流程走下来快则半小时，慢则一小时。但那天我直接把这句话扔给了一个text-to-cad流程，几分种后STEP文件就出来了，尺寸分毫不差，直接丢进切片软件和数控编程都行。

这就是text-to-cad的核心价值：用自然语言描述三维对象，让系统自动完成从语义到几何的转换。它不是一个单一软件，而是一套方法论和技术栈的组合。对我这种经常要在“脑子里的想法”和“能加工的文件”之间来回倒腾的人来说，它相当于把过去那套“软件操作语言”换成了“人类语言”，门槛降了一个量级。

这个方向之所以在最近两年突然爆发，有几个关键推力。第一，大语言模型的代码生成能力成熟了，它们不再只是“聊天”，而是能稳定输出结构化的、可执行的建模指令。第二，程序化建模生态攒够了家底，CadQuery、OpenSCAD这类用代码描述几何的工具已经非常可靠，过去十几年积累的函数库、社区案例都是现成的训练语料。第三，工业界对“快速验证概念模型”的需求越来越强，传统CAD重交互、重精度，但在早期设计阶段，往往只需要一个能表达设计意图的粗模型，text-to-cad刚好补上这个空档。

这套东西适合谁？我觉得分三类。第一类是机械工程师和结构设计师，用来快速生成标准件、辅件、工装夹具的初版模型。第二类是产品设计师和创客，脑子里有想法但没有系统学过CAD软件，用自然语言就能把想法变成可打印、可加工的模型。第三类是搞自动化的人，想把“自然语言需求”接入参数化设计流水线，批量生成系列化零件。

需要说明的是，现在的text-to-cad并不是万能的。它擅长的是结构相对规则、参数清晰的机械零件，对于自由曲面、有机形态、复杂装配体，还有很长的路要走。但如果你做的恰好是“规则几何体为主”的领域，它已经能实打实地省下大量时间。

2. 三条技术路线，到底该押哪一条

text-to-cad不是一个算法搞定一切，目前业内探索的路线大致分成三类。看懂这三条路线的差异，你才能判断手里的需求到底适不适合它，以及遇到问题该往哪个方向排查。

2.1 直接生成网格或隐式场：画面好看，精度难控

这条路走的是“文本到3D生成”的老路，代表方向是各类扩散模型和NeRF/SDF变体。你输入“一把椅子”，它直接生成一个三角网格文件，长得还挺像回事。问题在于，这种结果本质上是“看起来像”的几何，不是“能制造”的几何。网格是离散的，没有参数化特征树，没有尺寸标注，更谈不上约束关系和可编辑性。

我实测过几个开源模型，生成一个花瓶、一只猫的摆件确实惊艳，但一旦要求“这个法兰盘外径80mm、内径40mm、厚度8mm、均布6个螺丝孔”，它就崩了。不是偶尔崩，是大概率崩，因为这类模型根本没有理解“mm”和“均布”的能力，它们学的是形状分布，不是工程语义。

所以我的判断是：这条路线适合视觉预览、概念展示、游戏资产这类“不需要精密制造”的场景，离CAD意义上的“设计”还很远。如果你只是想快速看到一个大致的形态，可以玩；如果目标是出加工文件，趁早换路线。

2.2 生成CAD命令序列：学术界的宠儿，落地还差点意思

第二条路线是让模型直接输出CAD软件的原生命令序列，比如草绘的线段、圆弧、约束、拉伸操作。学术界很多工作走这个方向，比如MIT的Text2CAD，就是用控制流和几何参数生成带序列结构的CAD命令，再用AutoCAD的脚本接口重放。

这条路的优点在于，生成的模型保留了完整的历史记录和特征树，理论上是可以回到CAD软件里继续编辑的。而且基于原生命令，尺寸精度可以得到保证——因为命令本身是带参数的，比如“画一条从(0,0)到(100,0)的直线”。这个语义足够精确，LLM能生成代码，自然也能生成这类序列。

但实测下来有几个痛点。第一，不同CAD软件的命令体系差异太大，AutoCAD的脚本、SolidWorks的宏、Fusion 360的API完全是三种东西，模型训练时只能绑死某一个平台，可迁移性差。第二，命令序列的调试成本高，一旦中间有一句命令的坐标或约束逻辑出错，整个模型就是坏的，而且你无法像看代码那样快速定位。第三，工业场景里，CAD模型最终要进入装配、仿真、CAM流程，命令序列生成的结果往往缺少数模里常见的命名属性和材料信息。

这条路线我会持续关注，但短期内不太适合个人或小团队直接拿来搭生产工具，更适合学术研究和平台方做技术储备。

2.3 生成程序化建模代码：目前最可靠的落地选择

第三条路线，也是我自己目前主用的方案：让LLM生成CadQuery或OpenSCAD的建模代码，然后在本地环境里执行代码、输出B-rep实体模型。这条路线本质上是“把几何构建问题转化为代码生成问题”，绕开了原生CAD命令的封闭性，用程序化建模库的开放性来承接LLM的代码能力。

为什么这个方案最稳？首先，CadQuery和OpenSCAD都有明确的执行语义，代码写对了，模型就一定对，尺寸分毫不差。其次，代码本身就是可追溯的，出错了能看log，能定位是哪一行的问题。再次，这类库是纯文本生态，天然适合被当作LLM的训练语料，互联网上有海量案例。最后，输出格式是STEP、STL这类工业标准格式，后续接CNC、3D打印、仿真都没障碍。

我见过有人质疑“这不就是让LLM写代码吗，有什么新鲜的”。对，本质上确实是，但关键在于领域约束。通用代码生成你可以让它写个爬虫、写个排序算法，错了改改就行；CAD代码生成要求模型同时理解几何语义、参数约束和制造可行性，这是三维空间推理能力，不是两行print语句能比的。这几年LLM在这方面的能力提升非常明显，生成的建模代码从“能跑但很丑”进化到了“能出图且接近人工习惯”，这才让这条路线从理论上走到了实际可用的位置。

3. 搭一套text-to-cad最小可用流程：从一句话到STEP文件

说了这么多，直接上实操。我以一个工程师的身份，把整个完整流程拆给你看，你可以照着搭，也可以按自己的需求改造。

3.1 环境准备和工具选型

我的建议是直接选CadQuery作为建模后端，而不是OpenSCAD。原因很简单：CadQuery的建模范式是“先选面、再画草图、然后拉伸/旋转/扫掠”，这跟传统CAD软件的心智模型高度一致。LLM生成这类代码时的成功率明显更高，因为语义空间和人类工程师的思考方式是对齐的。OpenSCAD更偏“CSG布尔运算”，代码写起来像拼积木，几何一复杂，代码就难读。

安装也不复杂，直接用pip装就行：

pip install cadquery pip install jupyterlab-cadquery # 可选，方便在Jupyter里预览

另外需要准备一个可以调用的LLM接口。我自己试过几个模型，结论是：代码能力强不强不是关键，关键是对“几何语义”的敏感度。有些模型在通用编程上很猛，但给出“在Y轴负方向一侧开一个槽”这种带空间方向描述的需求时，容易搞错坐标系。建议你在选型时，拿下面这个例子当基准测试：

请用CadQuery生成一个长方体，长60、宽30、高10，在顶面中心挖一个直径20的通孔，四角倒半径5的圆角。

能一次写对并且尺寸正确的模型，才算过了第一关。不同模型的API调用方式不同，这里不展开具体品牌，核心就是用你顺手的大模型编程接口。

3.2 核心执行流程：生成、执行、校验、反馈

我搭的流程分四步，你可以直接复刻：

第一步，把自然语言需求包装成生成提示词。关键不是把用户的话原样丢给LLM，而是先做一次“需求结构化”。比如用户说“帮我做个支架，能托住一个直径50的圆管”，我会在提示词里显式补充：圆管中心高度、支架底座尺寸、壁厚、是否要螺栓孔。让LLM补全缺失的尺寸参数比让它猜要可靠得多。

这里有个我踩过的坑：千万不要让LLM自己给所有尺寸赋值。你要么在提示词里写清楚，要么让它输出参数占位符并在代码里统一管理。否则它可能这次生成壁厚3mm，下次同一句话生成壁厚5mm，模型形态完全对不上。

第二步，让LLM生成CadQuery代码。提示词里我会包含这么几项：任务描述、单位制（mm）、坐标系约定、输出要求（必须返回Workplane对象）、禁止事项（不允许修改传入参数、不允许数组越界等）。效果最好的提示词模板大概是这样的：

你是资深CadQuery建模工程师。请根据以下需求生成CadQuery代码： 需求：{user_requirement} 要求： 1. 使用公制毫米单位 2. 自底向上建模，先用Workplane("XY")创建草图，再进行拉伸 3. 尺寸参数集中以变量形式放在代码顶部 4. 最后一行返回最终Workplane对象，变量名必须是result 5. 禁止输出解释，只输出Python代码

这一套下来，生成的代码质量会稳定很多。LLM其实非常擅长“照章办事”，你约束得越清楚，它发挥得越稳定。

第三步，执行代码并捕获结果。这一步不是在Jupyter里跑一下就完了，而是要做一个隔离执行环境。原因很直白：LLM生成的代码不是100%安全的，哪怕没有恶意，也可能因为坐标系算错导致异常，或者死循环卡死进程。我的做法是用Python的exec配合超时控制：

import json from cadquery import exporters def run_cadquery_code(code_str, timeout_seconds=30): result = {} exec_globals = {} try: import signal def handler(signum, frame): raise TimeoutError("代码执行超时") signal.signal(signal.SIGALRM, handler) signal.alarm(timeout_seconds) exec(code_str, exec_globals) signal.alarm(0) result_obj = exec_globals.get("result") if result_obj is None: return {"status": "error", "message": "没有找到result变量"} exporters.export(result_obj, "output.step") return {"status": "success", "output_file": "output.step"} except Exception as e: return {"status": "error", "message": str(e)}

第四步，把错误信息或校验结果回传给LLM做修复。这是整套流程里最容易被忽略却最关键的一环。LLM生成的代码第一次跑通的比例，我实测大概在60%到70%之间，剩下的需要一轮甚至两轮“报错-修复”。做法很简单，把执行阶段的异常堆栈或一个自定义的校验结果拼进新的提示词：

你之前生成的CadQuery代码执行失败，错误信息如下： {error_message} 请分析原因并输出修正后的完整代码。

就这么一个循环，能把成功率拉到90%以上。我的经验是：不要指望一次生成就对，要把LLM当成一个“会自我修正的实习生”，给它反馈路径，它就能越改越准。

3.3 一个完整的实测案例

拿我们公司最近做的一个零件举例子。需求是“一个用于固定传感器支架的L型连接板，水平面长80、宽50，垂直面高60，板厚5，水平面上开两个直径6.5的通孔，孔距40，对称分布”。

我给LLM的提示词就是上面那个模板，它生成的代码大致长这样：

import cadquery as cq length = 80 width = 50 height = 60 thickness = 5 hole_diameter = 6.5 hole_spacing = 40 result = ( cq.Workplane("XY") .box(length, width, thickness) .faces(">Z") .workplane() .pushPoints([(-hole_spacing/2, 0), (hole_spacing/2, 0)]) .hole(hole_diameter) .faces(">Y") .workplane() .center(0, thickness/2) .box(thickness, height, width) ) result = result.faces(">Z").workplane().center(-length/2 + thickness/2, 0).box(thickness, height, width)

第一版代码其实有个问题：第二个box的位置偏移算错了，导致垂直面没有和水平面的边缘对齐。执行出的模型我看着别扭，把错误反馈回去之后，它重新计算了坐标，补了一句center来修正。最后一连导出STEP，在FreeCAD里打开确认尺寸完全正确，整个过程五分钟搞定。

4. 实测翻车记录：那些看似没问题却暗藏坑的案例

只有跑过足够多的坏例子，你才知道这套流程的边界在哪里。我把这半年实测中反复踩过的坑整理出来，每个都是真实教训。

4.1 尺寸单位错误：AI以为你在说英寸

有一次我让LLM“做一个直径1的圆盘”，它毫不犹豫生成了半径1英寸，也就是25.4mm的零件。我的预期是1mm，结果模型尺寸差了25倍。这种错误在纯文本交互下极其隐蔽，因为在提示词里你没提单位，LLM就会按训练数据里的统计习惯来——而英文语料里inch的使用频率非常高。

排查链路：发现模型尺寸不对后，我先查了代码里的数值，没看出问题。再查导出的STEP文件的全局属性，发现单位元数据写的是inch。最后才定位到是LLM在生成时默认采用了英制。解决办法很简单：在提示词里强制加一条“所有尺寸默认单位为毫米，禁止使用英寸”，并且在代码执行前做一次数值边界检查——凡是超过1000mm的尺寸都弹警告，因为大部分我做的零件不可能超过一米。边界检查这步非常值，等于给尺寸错误装了一道保险丝。

4.2 草图参考面选错：模型看起来对，方向上全反

CadQuery建模里一个经典问题是参考面的选择。我让LLM生成一个“左侧开槽的基座”，它给出的代码把槽开在了右侧。从代码语法上看完全没错，faces("<X")和faces(">X")的语义它理解反了，导致镜像翻转。这种问题反馈给LLM时也很容易踩坑——如果你只是说“方向反了”，它可能改一次还是错的，因为它没搞清楚到底“反”在哪根轴上。

排查链路：我后来总结了两个办法。第一个是在提示词里明确坐标系约定：“X轴向右，Y轴向上，Z轴指向观察者，'<X'代表左侧面，'>X'代表右侧面，其余轴类推。” 第二个是让LLM在代码注释里写出每一步的空间推理过程。加注释这个技巧是从一个老同事那学的，他说“让AI解释它的几何推导，比直接改代码更容易暴露逻辑漏洞”。实测下来确实如此，LLM在强行写注释时往往会发现自己方向搞反了。

4.3 参数化形同虚设：改一个尺寸，关联全崩

text-to-cad一个很大的卖点是可以反复调整参数——你改一个长度，其他特征应该跟着变。但LLM生成的代码经常是“一次性筷子”，所有尺寸都是硬编码字面量，没有变量之间的约束关系。比如你把一个板子的长度从80改成100，上面开的孔距还是40，看着没事；但你如果把宽度从50改到20，原来按绝对坐标写的孔位就跑到了板子外面。

排查链路：这个问题的根源在于LLM默认生成的是“数值计算代码”，而不是“参数化设计代码”。修复方法是提示词里增加一条要求：“将关键尺寸定义为变量，并显式表达特征之间的位置依赖关系，例如孔的中心必须在板子的宽度范围内居中，所有定位坐标一律使用变量表达式，禁止使用未经解释的魔法数字。” 再加上代码生成后的一轮“参数扰动测试”——我手动把主尺寸改大10%，重跑一遍，检查是否有特征越界或布尔运算失败。这一步能筛掉至少一半的“伪参数化”代码。

4.4 布尔运算与自相交：CAD引擎的物理极限

CadQuery底层用的是OpenCascade几何内核，这个内核很强，但对某些病态几何会直接报错或生成破碎实体。最常见的情况是：拉伸体之间存在零距离接触面、两个体只共享一条边或一个点、或者倒角半径比壁厚还大。这种错误不是LLM的“逻辑错误”，而是几何内核本身的限制。

排查链路：有一次我让LLM生成一个“中心带十字加强筋的矩形壳体”，它生成的代码看着完全合理——先建外壳，再建两条垂直的加强筋，然后执行union。结果OpenCascade直接抛了一个Type::NullShape异常，没有任何说明。我逐行注释代码，发现加强筋的高度和外壳内腔高度完全相等，两个体在顶部形成了零厚度的共面接触，这在B-rep布尔运算里就是临界条件。解决办法是让LLM把加强筋的高度减掉0.01mm，留一个微小的间隙。这个经验后来被我固化成了提示词里的规则：“凡是需要与另一实体合并的特征，必须避免完全重合的面，最小偏移量取0.01mm。” 在此之后，这类报错基本绝迹。

4.5 输出格式与下游兼容性：STEP文件也会“缺胳膊少腿”

最后一个坑不在生成端，在交付端。STEP文件虽然号称是工业标准，但不同格式版本差异不小。CadQuery默认导出的STEP可能是AP203或AP214版本，AP203不带颜色和图层信息，AP214带一部分。如果你的下游软件或者生产方一定要带颜色属性的STEP，默认导出就会“看起来正常但缺信息”。此外，有些LLM在生成代码时会把exporters.export的格式参数写成"STEP"大写，CadQuery某些版本会识别为未知格式，导致导出静默失败——代码不报错，但文件没生成。

排查链路：这个坑我卡了整整一个下午。确认代码逻辑没错、没有异常，但输出目录就是空文件。最后是打了个断点去看exporters.export的返回值，发现它抛了个warning被吞了。解决办法是统一封装导出函数，固定参数为exporters.export(obj, "output.step", exportType="STEP")，避免LLM自由发挥。同时也建议在导出后加一道“文件非空且大于1KB”的校验，防止静默失败造成的后续流程中断。

5. 从Demo到工作流：让text-to-cad真正在团队里跑起来

如果你试过上面这套流程，觉得“挺酷但用不上”，那说明还差最后这步——把它嵌进真实工作流。一个只在自己电脑上跑得通的demo，价值有限；能跟团队现有流程配合的text-to-cad，才算真正值钱。

5.1 模型验证：生成不等于正确，必须做几何校验

LLM生成的模型即使能导出STEP，也不代表它就是正确零件。我的做法是加三道校验关卡。第一道是数值边界检查，确保所有关键尺寸在合理范围内。第二道是质量属性检查，用Workplane.val().Volume()和.Area接口计算体积和表面积，跟人工预估的数值对比，偏差超过10%就判定为失败。第三道是干涉检查，如果这个零件要装到某个装配体里，我会把它和相邻零件的STEP丢进一个简单的碰撞检测脚本，跑一下看是否交集。这三道关卡最初都是人工做的，后来写成了自动脚本。说实话，校验脚本的代码量比生成脚本还多，但这是保证交付质量不能省的成本。

5.2 与现有CAD环境衔接：以FreeCAD和Onshape为例

目前text-to-cad最平滑的落地方式不是替代主流CAD软件，而是作为它们的“前置生成器”。我们的工作流是：先用text-to-cad快速生成初版模型，导出STEP；然后导入FreeCAD或Onshape做微调、出工程图、添加公差标注。整个过程从“一句话到能看得见的实体”压缩在几分钟内，而过去这个阶段往往要花半天。

衔接过程中有个细节值得说：CadQuery导出的STEP模型是“无特征树”的，到了FreeCAD里就是一个孤零零的实体，没有建模历史。这意味着你没法在FreeCAD里改草图的尺寸，只能直接改实体或重新做特征。所以如果你想保留参数化能力，建议同时导出CadQuery源文件(.json或.py)，在CadQuery里改参数重新生成，再同步到下游。这个“双轨制”目前是体验最好的方案。

5.3 把自然语言沉淀成团队模板库

text-to-cad的另一个隐藏价值，是它能帮你把团队的经验沉淀成可复用的模板。我们做了几件事：把常见零件类型（法兰、支架、壳体、轴套、钣金件）的典型提示词模板整理成库；把每条模板的约束规则、禁忌项、典型错误案例写成注释；把历史生成成功的代码块按特征拆解，存成可复用的函数片段。这样新来的同事不需要会CadQuery，只需要用自然语言描述需求，系统就能基于模板库生成符合团队规范的模型。

这个思路借鉴了我们写代码时的做法：没人会从零写一个排序函数，都是从库里调。同样，text-to-cad的提示词和代码片段，也应该是一个持续累积的资产库。到现在为止我们已经有超过50个经过验证的模板，新零件的生成成功率从最初的70%提升到了95%左右，大部分失败案例集中在复杂型腔和螺纹配合这类高难度几何上。

6. 下一步会在哪里突破，以及如果你想入坑该从哪开始

text-to-cad远没到成熟期，但它的演进方向已经比较清晰。我根据自己的观察和实测体验，梳理了三个值得关注的方向，以及给想动手试试的人的建议。

6.1 尺寸标注和公差语义的嵌入

现在的text-to-cad能把几何形状做对，但工程图不只是几何，还有尺寸公差、几何公差、表面粗糙度这些制造语义。目前这些信息主要还是靠人在CAD里后补。我预计下一步的发展方向是让LLM在生成模型的同时，输出一组与特征关联的制造注释——比如“这个孔径是H7配合”“这个面要求Ra1.6”。这需要LLM对制造工艺有更强的理解能力，但一旦打通，从设计到制造的链路就真正缩短了。

我自己现在已经在提示词里约定：如果可以，在代码注释中标注关键配合尺寸的推荐公差等级。虽然这些注释还不会被下游软件读取，但至少保证了生成代码的人在后续出图时不会漏掉关键公差。养成这个习惯之后，因为漏标公差导致的返工明显少了。

6.2 逆向生成：从已有模型反推自然语言描述

有个方向大家聊得少，但我认为价值很大：逆向的text-to-cad，也就是“从STEP文件生成设计说明书”。我们遇到过很多次这种情况——供应商发来一个模型，但没有图纸也没有设计意图，团队需要反向理解这个零件的功能、拆解它的特征、估算它的工艺成本。如果有一套系统能读取模型并输出“这是一个带有四个M8通孔的法兰，外径120，高度18，建议采用铝合金加工”这样的描述，对供应链协同、成本评估、设计审查都是巨大的效率提升。

目前这个方向的难点在于特征识别和语义映射，但好在现有的CAD库提供了不少基础能力，比如CadQuery可以遍历实体的面、边、孔特征，只是需要有人把这些底层数据组织成LLM能理解的语言。我自己做过一个粗糙的原型：把STEP文件的面、边、孔洞统计信息生成结构化文本，输给LLM让它总结成设计意图描述。虽然离“智能逆向工程”还很远，但已经能在部分简单零件上蒙对七八成。

6.3 多模态输入的融合：草图加文本

最后一个我认为会明确推进的方向，是融合手绘草图与自然语言。你画一个大概的轮廓，同时补一句“厚度5，孔距20”，系统结合两种输入生成精确模型。草图解决的是“形状意图”，文本解决的是“尺寸和特征语义”，两者天然互补。现有的图像生成模型和关键点检测已经能处理粗略的草图，难点在于把草图语义和CAD几何参数对齐。往远了说，这可能是设计师最舒服的输入方式——毕竟画草图是设计师的本能，打字说参数也远比菜单点击直观。

6.4 给想入坑的人的行动路线

如果你看完这篇想动手试，我给一个务实的路线图。第一步，不用一上来就搭完整系统，先装好CadQuery，用Jupyter手工写几个零件，把Workplane、box、circle、extrude、hole这些基础API跑熟。这个阶段的目标是建立“代码如何映射几何”的直觉。第二步，把写过的代码丢给LLM，让它改参数、加特征，观察它改得对不对，慢慢摸清模型的脾气。第三步，再尝试搭建文中的四步循环流程，先接受60%的成功率，然后逐步加提示词约束和校验逻辑。最后一步，选择一个真实的、重复性高的小零件品类做试点，把它彻底跑通，再考虑扩大范围。

我个人的体会是，text-to-cad不是一个“装了就完事”的工具，它更像是一个需要持续调教的协作伙伴。你喂给它的领域知识越具体，它给你的回报就越稳定。别指望它零成本替代你的CAD技能，但如果你愿意花两周时间把流程调顺，它替你省下的时间会是长期的、复利的。