企业官网建设流程全解析

做CAD建模这行当的人，应该多少都有过这种体验：软件里点了半天对话框，调完拉伸距离又调倒角半径，一个零件还没露雏形，几分钟就过去了。如果碰上改图，尺寸一联动连带着特征树全得重排，脑壳生疼。而最近这一年多，AI生成代码和3D模型的能力猛涨，"text-to-cad"（文字直接生成CAD模型）这个方向突然从实验室里的Demo变成了大家认真考虑的落地工具。说白了，就是你对电脑说一句"我要一个带四个通孔的安装底板，长120宽80厚5，四个角倒R10"，然后脚本自动给你把模型建出来。

这篇文章我不打算整一堆论文腔的说教，就以实际动手做过的经历为主线，把这个技术背后的核心思路、选型逻辑、实操步骤和踩过的坑，全部摊开聊。内容适合几类人看：一类是做机械设计和产品结构的人，想搞清楚AI建模目前到底能干多少活；另一类是搞软件和算法开发的，想自己搭一个能跑通的最小原型；还有一类纯粹是3D打印玩家，想让AI帮你快速出个可打印的零件模型。无论你是哪一类，看完至少能明白这个技术该怎么上手，以及它现阶段哪些事靠谱、哪些事别抱幻想。

1. 先搞清楚text-to-cad到底在解决什么问题

1.1 传统CAD建模的痛点：从"画图"到"写剧本"

传统CAD建模工具（SolidWorks、Fusion 360、AutoCAD这些）本质上是让设计师通过GUI交互，一步步把几何特征叠加起来。拉伸、切除、倒角、阵列、布尔运算，每一个操作都在改变特征树的状态。这种方式的优势是所见即所得，但劣势也很明显：操作链路特别长，而且高度依赖"操作者本身熟悉软件"。

这里有个很关键的类比：传统CAD建模很像你在用Word一个字一个字敲排版，而text-to-cad相当于你用一句话让Word自动生成一篇带格式的文档。前者自由度最高，但效率瓶颈在人；后者把意图表达从"操作级"提升到了"语义级"，效率瓶颈转移到了AI模型的理解能力上。

我实际接触的工程师里，有不少人建模能力很强，但每天花大量时间在做重复性操作——建底板、打孔、倒角、加加强筋，这类零件的结构相似度极高，但每次都得从头点一遍。text-to-cad真正解决的，恰恰是这种"结构明确、参数可变"的重复劳动。它不是说让AI替代设计师的创造力，而是把那些模块化的脏活累活自动包办了。

1.2 三类典型场景：生成、修改、衍生

我把text-to-cad的实际应用场景粗略分成了三类，这也是我判断一个项目该往哪个方向投资源的基本框架。

第一类是零基础生成。用户给一句描述，系统直接输出一个完整零件。比如"做一个圆柱体，外径30，内径24，高度15，顶端带一圈6个M3螺纹孔"。这类场景最适合快速概念验证，也是大多数Demo展示的效果。

第二类是参数化修改。已有模型已经很接近预期了，但某些尺寸或特征需要调整。传统做法是去特征树里改草图约束，一旦草图和外链参数脱钩，改起来就很痛苦。text-to-cad在这类场景的好用之处在于：它生成的模型本身就绑定了一套参数，用户只需要用文字提需求"把这个孔往右移5毫米""内径放大到28"，AI直接改动对应的几何约束关系。

第三类是拓扑衍生。从已有的模型库出发，A型号的底座改成B型号的支架，本质上就是换参数。"输入描述+模板引导"的模式在衍生零件设计里效率提升最明显。业内叫"配置化设计"或者"变形设计"，text-to-cad让这个过程的入口变得更简洁了。

1.3 为什么这两年会突然火起来

坦白讲，text-to-cad这个想法并不是2024年才有的，早年间就有AutoCAD的Scripting、OpenSCAD这种用代码描述模型的方案，而"自然语言直接生成CAD"其实可以追溯到更早期的专家系统研究。但当时的瓶颈有三个：没有足够大的"自然语言-3D模型"对齐数据集、生成模型的泛化能力太弱、以及没有足够便宜的推理算力来做后端计算。

这两年条件变了。一方面LLM已经具备了较强的代码理解和生成能力，可以把"自然语言"映射成"合法的参数化建模脚本"；另一方面，开源CAD模型数据集（比如ABC Dataset、Fusion 360 Gallery Dataset）越攒越多，给训练对齐提供了原料。再加上CadQuery、OpenSCAD、Build123d这波代码化建模库逐渐完善，让AI生成的脚本能真正被CAD内核解析并输出B-rep实体——于是text-to-cad从"读论文让人觉得有戏"变成了"跑个Demo真能出模型"。

2. 主流技术路线解析：三种方案怎么选

2.1 路线A：LLM直接生成脚本代码

目前最主流、最容易被落地的方案，就是让大模型生成一种CAD脚本，然后丢给对应的脚本化建模内核去实际执行。比较常见的后端有CadQuery（Python库）、OpenSCAD（自有脚本语言）、Build123d（CadQuery的升级替代）。

举个例子，用户输入"一个40x40x10的方块，中心有一个直径12的圆孔，四角做R5倒角"，CadQuery脚本长这样：

import cadquery as cq result = ( cq.Workplane("XY") .box(40, 40, 10) .faces(">Z") .workplane() .hole(12) .edges("|Z").fillet(5) ) cq.exporters.export(result, "result.step")

大模型要做的事情，就是把用户那句自然语言准确映射成上面这段代码。这里有个核心逻辑：并不是让模型"凭空想象"一个模型，而是让它熟练运用CadQuery这个"语言"来描述模型。所以这条路线对后端库的稳定性要求很高，你选的库是成熟的开源库，AI生成的代码才有足够的先验数据可以模仿。

这条路线最大的优点是可解释性和可控性。脚本是文本，你可以审查、修改、重跑，出了问题知道该改哪个参数。而且输出的STEP文件可以直接进入传统CAD生态，这在工业环境里非常关键。缺点是模型对"尺寸的精确记忆"能力有限，很容易把12写成21，后处理必须有校验兜底。

2.2 路线B：生成式模型直接输出几何体（体素/点云/神经隐式场）

另一种路线是纯端到端：用户文字进模型，直接吐出一个体素网格或者点云，甚至是一个NeRF/3D Gaussian表示。这条路线听起来更加"AI原教旨"，但实际落地过程中我遇到过很多麻烦。

核心问题在于：CAD模型在工业里讲究的是精确的边界表示（B-rep），是参数曲面和边界边，而不是一堆点。体素和点云转成STEP格式，要么精度损失严重，要么根本没法转成可加工的B-rep。你3D打印用个STL图个乐可以，但在CNC加工、公差配合面前，这条路线远远不够格。

不过这条路线在"概念草图"和"形状检索"场景仍然有价值。有些团队的做法是端到端先生成一个粗糙形状，再逆向拟合出参数化特征。但拟合的过程健壮性不高，我是不会把它放进生产管道的，最多拿来团队内部做灵感参考。

2.3 路线C：混合式——"LLM+CAD库+规则引擎"

说实话，真正在工程上能稳定产出的text-to-cad系统，九成以上是混合式架构：LLM负责意图理解和代码框架生成，程序化规则负责约束校验和参数修正，最后CAD内核负责精确计算。

比如LLM生成了一段CadQuery代码，但里面倒角半径是8，几何上倒角半径大于壁厚导致内核报错，这时候规则引擎就要捕获异常，把参数缩到合理范围，或者让模型二选一："要么减小倒角半径，要么增加板厚"。这种"感知-生成-校验-修正"的循环，比单纯依赖大模型一次成型的方案要可靠得多。

另外一个环节是参数提取。用户说"差不多手掌大小的方块"，LLM要能转化为合理的数值（比如90x60x15），这其实需要一些先验约束——比如生活场景里"手掌大小"对应什么量级。我个人的做法是，把这类"模糊语义到精确数值的映射表"放进提示词里，让模型参考映射做数值猜测，准确率能提高一个档次。

2.4 工具选型速查表

3. 实操过程：10分钟搭一个text-to-cad最小原型

3.1 环境准备与依赖安装

我建议第一次做这个方向的朋友直接从CadQuery起步，原因有三：语法和自然语言的距离近，模型生成的代码可读性好；输出的STEP文件可以被主流CAD软件直接打开；库本身是纯Python，安装调试成本低。

pip install cadquery pip install openai # 或其他LLM SDK，按你自己的接入方式

如果你想本地跑模型，也可以用Ollama跑qwen这类开源模型，把API地址换成本地端口就行。我实测下来，本地小模型在CAD任务上表现远不如商业大模型，但做原型验证完全够用。另外强烈建议在Jupyter Notebook里做原型，因为CadQuery内置了jupyter渲染插件，可以直接在单元格里看3D效果，省去导出文件的流程。

3.2 核心引擎代码：构造一个"文字到脚本"的流水线

先说整体架构。我搭的原型分三个模块：意图解析（LLM）、脚本执行（CadQuery）、结果校验（规则）。意图解析把用户输入变成一段CadQuery代码；脚本执行把代码跑起来输出实体；结果校验检查实体尺寸、体积、拓扑是否合法，不合法就把报错信息回喂给LLM再尝试一次。

import cadquery as cq import openai import re client = openai.OpenAI(api_key="your-api-key") SYSTEM_PROMPT = """ 你是一名资深CAD工程师,精通CadQuery库。 根据用户的自然语言描述,生成对应的CadQuery Python代码。 要求: 1. 只输出代码,不要任何解释文字 2. 所有尺寸默认单位为毫米 3. 代码必须可以直接执行,不能使用cq.exporters导出 4. 使用result作为最终变量名 5. 优先使用链式调用风格 """ def generate_cad_code(text: str, attempts: int = 3) -> str: for i in range(attempts): response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": text}, ], temperature=0.2, # 低温度保证代码稳定性 ) code = response.choices[0].message.content code = extract_code_block(code) if validate_syntax(code): return code raise RuntimeError("多次生成后代码语法仍然非法") def extract_code_block(raw: str) -> str: # 模型经常会把代码包在```python里,需要剥掉 pattern = r"```(?:python)?\s*(.*?)```" match = re.search(pattern, raw, re.DOTALL) return match.group(1).strip() if match else raw.strip() def validate_syntax(code: str) -> bool: try: compile(code, "<generated>", "exec") return True except SyntaxError: return False

这段代码里有三个细节值得说明。一是temperature设成0.2，CAD代码生成是确定性任务，温度太高会带来随机语法错误，实测在0~0.3之间出错率最低。二是extract_code_block，大模型几乎总是会用Markdown代码块格式来回复，你不剥掉就没法直接执行。三是compile语法预检，这比直接把代码丢进exec要安全得多，可以先拦截一批低级错误。

然后写执行和校验部分。我这里给了一个简单的体积合理性校验，你可以按需扩展成"部件是否有两个以上特征""孔直径是否过小"等规则。

def execute_cad_code(code: str): namespace = {"cq": cq} exec(code, namespace) return namespace["result"] def validate_model(cad_obj): # 简单校验:体积不为零、包围盒不过于夸张 bbox = cad_obj.val().BoundingBox() vol = cad_obj.val().Volume() if vol <= 0: raise ValueError("生成模型体积为0,可能代码逻辑有问题") if bbox.xlen > 1000 or bbox.ylen > 1000 or bbox.zlen > 1000: raise ValueError("模型尺寸超出合理范围( > 1000mm)") return True

整个原型跑通以后效果大概是这样的：输入"做一个外径20的内六角螺母，对边16，厚度8，中间螺纹孔直径10"，LLM生成的CadQuery脚本会在两秒内被内核编译成实体，然后你可以在Jupyter里看到模型，或者导出STEP丢进SolidWorks继续做装配。第一次跑通的时候，旁边同事都觉得"这玩意要革建模师的命"，当然实际用下来发现远没有那么夸张，这个后面细聊。

3.3 设计输入模板：把模糊描述变成可执行指令

如果你的需求只是"给我生成一个零件"，效果一般不会好。原因在于大模型对模糊的物理世界概念（比如"一个小支架""一个圆润的块"）很难直接映射成精确参数。所以我在原型里加了一个结构化输入模板，引导用户描述补全关键信息。

模板大致长这样：

- 零件类型: 底座 / 支架 / 壳体 / 法兰 / 自定义 - 整体尺寸: 长x宽x高(单位mm) - 需要哪些特征: 孔/槽/倒角/圆角/阵列等，注明位置和尺寸 - 安装要求: 比如"四个角落要有8.5mm安装孔" - 材质或工艺备注: 比如"考虑3D打印，壁厚至少2mm"

这看起来有点繁琐，但对生成质量提升巨大。我做了一个对比测试，不带模板直接说"给我一个机器人支架"，出来的模型五花八门且基本不可用；带模板描述"一个L形支架，立板厚5，底板厚5，宽40，高60，底板上有两个直径6的孔，间距30"，模型基本一次成型。所以说text-to-cad并不是真的"你随便说一句就出图"，它更接近"你把需求稍微结构化，AI帮你完成剩余建模动作"。

3.4 参数化扩展：让AI改图比人快

原型跑通后，我加了一个功能：允许用户在生成模型的JSON参数基础上修改个别值，让LLM重新生成脚本。这里的关键是"以原脚本为上下文，只修改差值"。

def modify_cad_model(original_code: str, modification: str) -> str: response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"原脚本如下:\n{original_code}\n\n请根据要求修改:{modification}"}, ], temperature=0.1, ) code = extract_code_block(response.choices[0].message.content) if validate_syntax(code): return code raise RuntimeError("修改后的脚本语法错误")

这个"改图"场景实际上比"从零生成"更贴合真实工作流。机械设计里大部分时间不是在创造新零件，而是在改旧零件。参数化脚本一旦建立，修改台词就只是一两句话的事。比如"把孔距从30改到35，孔径改成6.5"，整个脚本在几秒内重跑一遍，比去SolidWorks里拖动草图尺寸线快得多。实测下来，改图场景的LLM成功率比从零生成高不少，因为上下文里有完整的参照代码，模型只需要做局部文本替换。

4. 实测中出现的高频问题与排查实录

4.1 生成的代码有语法错误或者API误用

这是最开始最常遇到的。CadQuery的API有它自己的怪脾气，比如faces(">Z")是选择Z轴正方向的面，edges("|Z")是选择平行于Z轴的边，这种符号旧模型学习得不够扎实，就容易生成一些看起来很像、实际跑不通的代码。

我的应对思路有两个。第一个是给系统提示词里加一段"CadQuery高频规范速查表"，把最常用的几种操作标准写法贴进去，模型生成时就会照着模板走。第二个是失败重试机制：代码执行抛异常后，把异常信息拼到下一次请求里，让LLM根据报错自己修。这个循环最多跑三次，三次后还失败就放弃。实测下来大概六到七成的语法错误可以在重试中自愈。

def execute_with_feedback(code: str, user_text: str) -> cq.Workplane: for attempt in range(3): try: return execute_cad_code(code) except Exception as e: print(f"[Attempt {attempt+1}] Error: {e}") code = repair_code(code, str(e), user_text) raise RuntimeError("经过三次修复仍然失败")

4.2 尺寸与语义错位：说好了12毫米，出来120毫米

这类问题的核心是LLM对数字并不真正"感知"，它只是在做Token概率预测，12和120在它看来长度差不多的文本片段。一旦你给的是间接描述（"比上一个加宽一点"），偏差就更离谱。

我的校验层会对所有关键尺寸做范围约束。比如用户声明"总长不超过100"，那我就把校验规则传入，最后模型生成完自动检查包围盒。如果超了就不返回结果，直接告诉用户"你的描述给的参数是矛盾的，最大长度100，但你又要求孔距110，这不可能同时满足"。这其实是在把错误判断前置到对话阶段，至少比默默生成一个错误模型要好。

另外一个小技巧：让模型把关键尺寸参数单独提取出来，放到脚本顶部的变量区。这样即使模型在后面的代码里写错了数字，人工检查也容易发现。能不能让模型"理解几何"，现阶段别把期望拉太高，先保证"错得能看见"。

4.3 布尔运算和几何约束冲突

CadQuery里最让人头疼的报错之一是布尔操作失败。常见场景是"给一个薄壁件的外表面加一圈加强筋，加强筋和主体边缘产生了微小的重合/分离"，内核在对两个B-rep做布尔并集时可能因为浮点容差问题直接崩溃。

这不算AI独有的问题，传统建模也会遇到。但在text-to-cad里你没法通过拖动几何体来手动修复，所以需要在模型侧规避。我总结的有效策略：

• 在提示词里强调"所有几何特征之间必须保留至少0.01mm的间隙或完全相交，避免共面接触"
• 在代码执行前，对生成脚本做正则检查，找出是否有大量重叠面操作
• 如果布尔失败，捕获异常并回传到LLM，要求它"改用先合并后再进行一次圆角处理"等重写策略

注意，CadQuery的容差机制在处理共面重叠时确实存在历史bug，很多情况下是库的问题而不是你提示词的问题。所以遇到这类错误，备选方案是直接把失败场景转成"拆分成多个单独实体导出STL"，而不是坚持做单个B-rep实体。

4.4 推理速度与成本：批量生成时别大意

如果你只是偶尔生成几个模型，成本不是问题。但我做批量压测的时候发现，一个两千字的生成请求带上一整段CadQuery示例代码，token消耗比想象中大得多——而且并不一定总是一次成功，失败重试一次成本就翻倍。

几个实用的省钱建议：

• 系统提示词里不要放冗长的CadQuery使用手册，放精简版速查即可，把详细文档作为RAG内容按需检索
• 优先使用小参数模型做"代码生成初稿"，大模型只做"失败修复"，成本可下降一个数量级
• 温度调低一方面稳定，另一方面其实也减少了token重复输出的浪费
• 缓存机制很有用：相同或相似的模型描述，把生成结果哈希存起来，二次命中直接读取

4.5 准确性评估：怎么判断模型到底"对不对"

这是最后一个但也是最重要的一个环节。文本到CAD系统的评估，我目前用的是一套"三维一体"指标：代码可执行性、几何参数接近度、特征语义完整度。

代码可执行性是硬门槛，执行都不过关直接归零；几何参数接近度看的是包围盒长宽高、体积、主要孔径实测值与目标值的偏差；特征语义完整度则比较难量化，目前我用的是"用LLM把生成的STEP模型特征再翻译回文字，和原始需求做语义相似度打分"。这个闭环目前依然存在很多误判，但对于早期项目体检已经完全够用。

我个人经验：如果你的系统在"特征语义完整度"上经常拿低分，问题往往不在后端执行，而在前面的需求解析环节——你给LLM的提示词可能没说清楚哪些特征是必选、哪些是可选，它对"需要体现的关键特征"优先级判断就会乱。我后来在系统提示词里明确加上一个规则：优先保证必选特征的完整性，再考虑美观和衍生特征。

5. 这些踩坑经验，给后来者几条实在建议

5.1 别贪"一句话搞定一切"的漂亮话

外面很多演示视频让人产生错觉：AI好像已经完全理解了设计师脑子里的想法。实际上，text-to-cad现阶段更适合被当作一个"快速原型生成器"和"参数化脚本助手"，而不是"无人驾驶建模系统"。我的经验是，如果需求描述里包含超过五个关键特征，LLM的生成质量就会明显下降，它开始顾此失彼。合理的方式是把复杂模型拆成多个子部件，分别生成后做装配，而不是让它一步到位生成一个包含几十个特征的加工级零件。所以我会建议所有上手这个方向的人：先让AI做"会画"的部分，再做"精确"的部分，雷达图永远比黑盒更稳妥。

5.2 给模型做"示例示范"比修改指令更有效

我最初做修改任务时，直接告诉模型"把轴径改成30"，结果模型总是把轴径的所有关联特征（比如键槽深度、倒角大小）都改了，导致几何关系崩坏。后来换了个方式：在输入里附上一小段"正确修改片段"——比如"原来这段代码中轴径变量是d=20，现在请改成d=30，注意保持键槽宽高比例不变"，模型的表现立刻好了很多。少让模型去做隐含推理，多给它显式参照，这比它自己瞎猜要可靠得多。

5.3 模型生成不完美，但可以让工具链补位

坦白说，就我目前测试过的几个主流大模型，还没到能完全取代CAD操作的程度。但换个角度想，它也不需要一步到位替代所有功能。只要它能自动生成一个"占位结构"，让工程师把精力放在拓扑优化和装配设计上，就已经价值巨大了。工业界一直讲"专家在环"，text-to-cad的正确用法也是"人在环上做决策，AI在环内做执行"。把校验规则写进管道，把失败信息做成可读的日志，这个辅助工具的完成度完全够格进日常设计了。

5.4 后续还可以往哪些方向折腾

我在这个原型上目前主要做的是基于预训练LLM的直接生成，不涉及微调。如果你有足够多的"自然语言-脚本"配对数据，微调一个小模型（比如Qwen或Llama的7B/13B版本）专门做代码翻译，效果和延迟会比调用通用API好不少。另一个方向是结合RAG把企业内部的建模规范、标准件库、材料库塞进知识库，让模型生成时自动参考标准件规格，这个对所有结构设计团队来说都是可以直接见效的功能。

我个人下一步的计划是尝试Build123d作为后端，它的构造方式比CadQuery更接近"工程语义"，比如Chamfer和Fillet的构造参数化更符合直觉。再把生成结果做成一个Web小服务，让团队里非技术成员也能通过浏览器里一个输入框用上。技术成熟度还不够完美，但它已经足够成为一个"值得每个设计团队自己去跑一遍"的方向了。