企业官网建设流程全解析

1. Text-to-CAD 到底是什么：从"画图"到"说图"

输入一句"帮我做一个M8螺栓的参数化模型"，几秒钟后拿到一个可以被 SolidWorks、中望CAD 这类软件正常打开、继续编辑、出工程图的三维实体——这不是影视特效，而是当下的 text-to-cad 技术正在做的事。你可能已经听说过"AI生成图片""AI写代码"，但 text-to-cad 不太一样：它交出来的不是一张效果图，而是一份真实可加工的CAD数据。对画了二十年图的工程师来说，这可能是CAD工作流里最值得重新审视的变化。

这篇文章不想堆概念，只想把关于 text-to-cad 的几件事说透：它到底交付什么、目前有哪些路可以走、底层原理是怎么转起来的，以及我个人实测半年后踩过的坑。简单说，你读完以后不光知道"能干嘛"，还能判断"该不该用、怎么用"。

1.1 自然语言到三维模型：一条提示词背后发生了什么

先说清楚 text-to-cad 到底交付什么。给AI一句"外径60mm、内孔20mm、厚度8mm，带六个均布M6孔的法兰盘"，它需要给你一个可编辑的参数化三维实体，而不是一张渲染图、一段描述文字或者一个stl网格。

这里有个容易混淆的点：很多人把"AI生成3D模型"和 text-to-cad 划等号。两者有交集，但有本质区别。文生3D模型（比如根据描述生成物件网格）交付的是三角网格，适合放进游戏、做3D打印预览，但在工程软件里没法对孔位做尺寸约束、没法修改倒角、没法把圆柱面转成螺纹规格——它没有工程语义。text-to-cad 交付的是带特征树、可参数化修改的真实模型，甚至能追溯到"拉伸""打孔""阵列"这些操作记录。

举个例子你就明白了。一款CAD软件里的法兰盘，左侧列表通常记录着：基体旋转、中心孔切除、六个孔阵列、端面倒角。你要修改某一步，双击参数就能重算。而一个STL网格文件，本质上就是一堆三角形，改一个孔位等于把局部三角形全部重建。text-to-cad 要做的，是把那句自然语言翻译成"特征树的操作序列"，再由CAD内核按顺序执行，最终生成可编辑的实体模型。

在技术实现上，text-to-cad 通常分两步：先把自然语言拆解成一系列建模操作（拉伸多高、哪个面打孔、阵列几个），再交给CAD内核按这些操作精确计算几何体。简单说，AI负责"理解并设计"，内核负责"算得准"。这两步的衔接质量，基本决定了生成结果能有多大的工程可用性。

1.2 为什么是现在才火起来：大模型与代码生成能力成熟

text-to-cad 的概念并不新，学术圈很早就有人做"语义到CAD"的翻译。但过去效果差，根本原因是传统自然语言处理模型对"多高""几个孔""均布"这类带空间关系和工程约束的描述几乎没有理解力，更别说把描述拆成精确的建模步骤。

真正让 text-to-cad 走向实用的是大语言模型的代码生成能力。CAD建模步骤可以用 CadQuery、OpenSCAD 这类程序化建模语言完整表达，而程序化建模语言本质上是代码；只要LLM能准确地把自然语言翻译成代码，CAD内核就能稳定执行出几何结果。这就把"AI直接算几何"这个难啃的骨头，转移成了"AI写代码"这种已经被验证过的能力。我试过用几个不同的大模型去写 CadQuery 代码，只要模型见过足够多的开源建模脚本，生成质量基本可用。

另一个因素是工具链成熟。CadQuery、FreeCAD Python API、OpenSCAD 这些方案让"程序化建模"有了健壮的基础，加上 STEP 格式在主流CAD软件之间的互操作越来越顺畅，AI生成的模型可以被下游正常打开和修改。甚至可以说，text-to-cad 能火，靠的不是某个天才算法，而是三样东西恰好凑齐了：能写代码的大模型、能稳定执行几何的内核、能交换数据的标准格式。

2. 主流实现路线盘点：商业API与开源自建的取舍

聊实现之前，先盘点一下现在能触碰到的方案。目前 text-to-cad 大致分两条路线：一条是用商业API，一条是自己搭"LLM + 程序化建模库"的开源链路。两者各有优势，也各有明显短板，下面展开说。

2.1 商业平台：直接调用API的体验

国外比较有代表性的是 Zoo（前身 KittyCAD）提供的 Text-to-CAD API。它的用法接近现在常见的AI接口：传一段文本描述和想要的输出格式（STEP、STL等），API返回可下载的模型文件。Backflip AI 也做了类似的事，支持文本和图片生成CAD模型，重点服务3D打印用户。

这类商业API最大的优势是封装度高：几何内核在云端完成，返回的模型格式规范，不需要自己搭建环境。我实测过一轮，简单零件（垫片、支架、带孔板）的成功率相当可观，复杂曲面和螺纹类特征稳定性会差一些。对没有Python基础的CAD使用者来说，这类工具确实能"开箱即用"。

但也别对商业API期待过高。首先是自由度有限，想调整生成逻辑、约束规则，不给你碰。其次是数据敏感度问题，图纸是很多公司的核心资产，把设计描述丢给第三方API，很多企业法务关过不去。最后是成本，按次数付费，批量生成零件族的时候费用很快会堆起来。我见过一个做非标设备的团队，想用API批量生成几百个变体支架，算完预算以后果断放弃了。

2.2 开源自建：用LLM生成CadQuery/OpenSCAD代码

如果你有Python基础，我更推荐第二条路线：自己组装一条"LLM → CadQuery/OpenSCAD → CAD内核"的开源链路。这条路线的基本架构是：先让大语言模型把自然语言需求解析成 CadQuery/OpenSCAD 脚本；再在本地执行脚本，生成 STEP 或 STL 文件；最后把文件导入专业CAD软件做后续修改和出图。

CadQuery 是一个基于 Python 的程序化建模库，写法接近面向对象建模：Workplane("XY").circle(30).extrude(8)就是"在XY平面画半径30的圆，拉伸8毫米"。OpenSCAD 更偏向数学描述，用类似 C 的语法组合几何体。两者都能被LLM稳定生成，因为它们在开源社区里有大量代码样本，模型训练时见过足够多模式。

我用一张表总结两条路线的主要差异，方便你判断：

我的经验是，如果只是偶尔玩票，商业API很香；一旦涉及批量生产或内部工具化，开源自建的长期价值明显更高。唯一的门槛是前期搭建那两三个小时。

2.3 选型建议：你的场景适合哪条路

我在实际项目里总结了一个简单判断标准。如果你只是偶尔生成一两个零件用于3D打印预览，用商业API最快；如果模型将来要进入正式工程流程、需要被同事用中望CAD或 SolidWorks 继续改图，建议走开源自建，把生成逻辑沉淀成公司内部工具。

这里还要提到一个容易被忽略的点：商业API生成的模型通常只有"结果"，没有清晰的参数化过程。也就是说，你拿到一个STEP文件，但打开以后特征树可能非常简单甚至只有一个"导入实体"。这对于只做加工的人没问题，但对于需要继续迭代设计的工程师来说，反而是个麻烦。开源自建因为是自己控制代码，可以把尺寸定义成变量，生成带有完整参数化逻辑的模型，后期改一个数就能重算。

另外，无论选哪条路，都不要把 text-to-cad 当成"一句话替代设计师"。它目前更适合处理参数明确的标准件、规则几何体，比如法兰盘、支架、铭牌、钣金展开件；像复杂的曲面造型、需要大量工程经验判断的装配结构，它还没法替代人的工作。把它当成"超级草图工具"，心态会稳健很多。

3. 核心原理拆解：为什么"生成代码"比"生成网格"更靠谱

这一节把技术原理拆开讲。只有理解了"为什么是生成代码而不是生成几何"，用起来才知道边界在哪里，遇到问题时也才明白该去修哪里。

3.1 CAD模型的本质：特征树与B-Rep

工程CAD里的三维模型，远不是一个"形状"那么简单。它背后是特征树（Feature Tree）：先有基体拉伸，然后是切除、倒角、阵列、螺纹孔，每个特征都带着参数，后期双击就能改。这个数据结构在CAD内核里对应的是B-Rep（边界表示）——用面、边、顶点的拓扑关系精确描述一个实体。

说个生活化的类比：B-Rep 模型就像一份"结构化档案"，里面记录了每一个面的边界是哪条边、每条边连接哪个面；而网格模型就像一张马赛克照片，离远了看是形状，放大全是格子。你要修改马赛克里的一个色块很容易，但要把整个鼻子的轮廓改流畅，就难了。

所以一个真正可用的CAD模型，必须同时具备两样东西：精确的B-Rep几何，毫米级甚至微米级的尺寸误差都不接受；完整的特征历史，让后人能修改参数、看懂设计意图。网格模型只沾了"形状"，丢掉全部工程语义。这也是我强烈建议做 text-to-cad 时优先选择"文本→代码→内核执行"，而不是"文本→神经网络→网格"的原因。神经网络直接生成网格，短期看很炫，但生成物进不了工程体系，最后只能沦为展示品。

3.2 从文本到代码再到大纲：LLM在此扮演的角色

把这条链路展开：大语言模型读入自然语言后，先做意图解析。比如"均布6个孔"里的关键词是"polar array count=6 angle=360"；"外径60内孔20"需要换算成"半径30的圆，再在一个同心圆上打半径10的通孔"。接着，LLM把这些意图映射成 CadQuery/OpenSCAD 的API调用序列。最后在本地执行脚本，由CAD内核精确计算布尔运算、倒角、阵列结果。

这个过程中LLM很像一个"翻译+程序员"的角色：它并不直接算几何，而是写一份几何构造程序的源代码。真正保证"算得准"的是内核，LLM负责的是"翻译得对"。

这也是为什么 text-to-cad 的可实现性比很多人想象的高——它承接了大模型在代码生成上的成熟能力，而不是重新发明一个几何引擎。我在调试时发现，大部分生成失败都卡在"语义歧义"而不是"代码语法"。比如"带六个孔的法兰"没说孔是通孔还是盲孔、孔心所在的分布圆直径是多少，LLM只能靠猜。写提示词时把这类关键参数交代清楚，成功率会成倍上升。

3.3 精度与可编辑性：两个绕不开的坎

即便原理说得通，落地时还是有两个坎。第一是精度。LLM生成代码时可能把"半径10"写成"直径10"，或者把毫米当英寸算，一个符号之差模型就报废。这类错误不会少，必须配合验证环节。我见过最离谱的一次，AI把"板厚2mm"理解成"圆角半径2mm"，生成结果外形尺寸完全不对，但肉眼看缩略图根本看不出来。

第二是可编辑性。LLM经常生成"一坨"代码：全部写在一个函数里，不给参数分层，没有命名约束。这种代码能跑出模型，但后期改尺寸等于重写。所以真正工程化使用时，得在提示词里强制要求"把尺寸定义为变量，集中放在文件头部"。

我自己踩过的办法是在系统提示词里固定模板，要求LLM必须遵循"参数区+建模区+导出区"三段落结构，并且默认单位是毫米。这样生成结果的可用率提升非常明显，肉眼可见地从"经常要改"变成"偶尔要改"。模板化对LLM非常重要，它本质上限制了自由发挥的空间，而工程领域恰恰不需要自由发挥。

4. 实操演示：用文本生成一个可用的零件模型

理论讲完，直接上实际操作。下面这套流程我跑了小半年，从"一句话"到"可加工模型"大概三步。先说明一下，我用的是开源自建路线，因为这样一来每一步都透明可控，适合对照学习。

4.1 准备环境：CadQuery 与文本生成

环境上我建议用 CadQuery 而不是 OpenSCAD。原因很简单：CadQuery 对 STEP 的导出支持更好，生成结果进主流CAD软件基本无痛。安装方式：

pip install cadquery

CadQuery 启动时会拉取内置的 OpenCASCADE 内核，装完可以先跑一段官方示例确认环境正常。这里有个小坑：如果你用的是 Windows，且Python环境比较旧，CadQuery 的依赖安装偶尔会报缺少编译器的错。我的处理办法是先装 Microsoft C++ Build Tools 再重试，或者直接用 Python 3.10 以上版本创建干净虚拟环境。

文本生成部分，你可以用任何你习惯的大模型API，也可以本地部署一个开源模型；关键是给它配好一段系统提示词，说明"你是一名CAD程序生成助手，输出CadQuery Python代码，单位毫米，参数放文件头部，不要输出额外解释"。这段提示词是你整个工具链里最重要的一块，值得反复打磨。

4.2 从自然语言需求到CadQuery代码

我以一个实际需求为例，这是我在测试中反复用的经典场景：

需求：一块120mm x 80mm x 2mm的铝制铭牌，四角倒R5圆角，四个安装孔直径4mm，孔心距边缘10mm，表面刻字"TEXT-TO-CAD"。

大模型输出的CadQuery代码如下：

import cadquery as cq # 参数区 L, W, H = 120, 80, 2 R = 5 # 倒角半径 D, M = 4, 10 # 孔径、孔心距边缘 # 建模区：底板 plate = cq.Workplane("XY").rect(L, W).extrude(H) # 四个竖边倒圆角 plate = plate.edges("|Z").fillet(R) # 四个安装孔：构造100x60的构造矩形，取四个顶点 plate = ( plate.faces(">Z").workplane() .rect(L - 2*M, W - 2*M, forConstruction=True) .vertices() .hole(D) ) # 表面刻字：向下切除0.2mm plate = ( plate.faces(">Z").workplane() .text("TEXT-TO-CAD", 8, -0.2) ) cq.exporters.export(plate, "plate.step")

这段代码的建模逻辑对应了需求里的每一条：板上拉伸、四角倒圆角、构造矩形顶点定孔位、刻字。现实中大模型第一次输出未必一次通过，常见错误包括edges("|Z")写错导致倒角倒到顶面、text方法在旧版本CadQuery中不存在等。遇到代码报错，直接把报错信息贴回给大模型，让它自己修正，通常两三轮内能解决。

这里分享一个习惯：让LLM输出代码时，我会要求它在代码尾部加上一个简单的尺寸自检打印语句，比如打印模型的外形包围盒。这样每次生成完，马上就能在终端里看到关键尺寸，不用等导入CAD软件才发现尺寸不对。这个技巧成本极低，但能省下大量来回调试时间。

4.3 迭代修正与导出STEP/STL

导出文件时根据下游用途选格式：发去3D打印，导出STL；发去机加工或进装配体，导出STEP。CadQuery支持的导出很简单：

cq.exporters.export(plate, "plate.stl") cq.exporters.export(plate, "plate.step")

导出的STEP文件可以直接用 FreeCAD、SolidWorks、中望CAD 打开。我的习惯是先在 FreeCAD 里做一次几何快速检查，打开后看有没有破面、孔位对不对。LLM生成的模型"看起来对"不代表"几何对"，这一步不能省。

除了看，我还会做一步程序化校验：写一个读取STEP的小脚本，自动检查外形尺寸是否与需求一致。CadQuery本身可以读取STEP文件并访问实体的边界框，几行代码就能把宽高比出来。如果你不会写这个脚本，也可以在CAD软件里用测量工具手工核对，只是效率低一些。批量生成场景下，程序化校验几乎是必须的，否则你没法保证上百个生成件都没有尺寸漂移。

4.4 接回日常CAD工作流

模型生成只是第一步。真正的工程交付通常还要出二维图、标注尺寸、转PDF。CadQuery本身不擅长出工程图，我的做法是把STEP导入FreeCAD，用TechDraw工作台出三视图和标注，再导出PDF。如果你所在公司使用中望CAD这类国产软件，STEP导入后可以在软件里继续做标注和排版。

要特别说一个坑：刻字或注释类特征用AI生成时，字体是个大问题。CadQuery的text方法依赖本地字体，中文环境下经常出现找不到字体文件的情况；即使生成成功，导出后的文字在国产CAD软件里也可能变成乱码或缺字。这和很多同事日常遇到的"shx字体不足导致文字显示不全"是同类问题。稳妥做法是模型里不刻字，文字留到工程图阶段再添加，那里字体管理成熟得多。

另外，模型交付给人看的时候，别只丢STEP文件。我的习惯是 text-to-cad 生成模型后，同时导出一份PDF工程图给人看，STEP文件给机器用。图纸适合开会评审和归档，模型适合后续编辑和制造。人看图纸，机看模型，两条路都通畅。

5. 半年实测总结：这些坑我提前替你踩过了

最后把这段时间实测的坑和心得一次性交代完。这些经验不写进官方文档，但恰恰是能不能用好的关键。如果你准备在自己的工作流里引入 text-to-cad，这几点值得先有个预期。

5.1 尺寸幻觉与单位混乱

LLM有一个非常顽固的毛病：尺寸幻觉。你让它做"M8螺栓"，它大概率会生成一个"看起来像螺栓但尺寸完全不标准"的东西，比如把螺纹螺距写成2.5mm（M8实际是1.25mm）。问题在于LLM是从语料统计中学出的"平均印象"，不是查标准件手册。解决办法只能靠人工审查加标准件库校验。我现在遇到标准件需求，会让AI直接引用标准件库数据表，而不是凭记忆生成。

单位混乱更是重灾区。CAD领域英文社区默认英寸，中文环境默认毫米。模型看到"厚度2"会当成什么，完全取决于训练数据分布。我的应对方法是：系统提示词里强制声明"所有尺寸单位均为毫米"，并且输出代码的参数区直接带上单位注释。这样即使生成结果错了，人工一眼就能发现问题，而不必在几段代码里猜数字含义。

5.2 几何错误需要自动化校验

AI生成代码跑通、能导出STEP，并不意味着几何正确。比如孔和边距离太近、壁厚小于工艺要求、布尔运算产生自相交，这些错误在图形上可能很不明显，但到了加工阶段全部暴露。我现在的做法是在解析完模型后，用脚本检查关键尺寸——写一个简单的CadQuery脚本，读取生成的STEP，程序化核对孔数、孔径、外形尺寸，再生成一份校验报告。这个思路和"python批量对cad修改"的玩法是一脉相承的：程序能做校验，也能做批量修改。

import cadquery as cq part = cq.importers.importStep("plate.step") bb = part.val().BoundingBox() print(f"外形: {bb.xlen:.2f} x {bb.ylen:.2f} x {bb.zlen:.2f}") # 简单的孔数统计逻辑可继续扩展

别小看这几行脚本，批量生成场景下它就是在给你省时间。有一次我生成50个变体支架，就是用这段脚本自动筛出3个外形尺寸异常的，瞬间定位问题。如果全靠肉眼在CAD界面里看，没有一上午搞不定。

5.3 中文环境与国产CAD的互操作

在国内工程环境里，模型最终往往要进中望CAD、浩辰CAD这类软件。我实测的结论是：STEP格式的实体数据互操作基本正常，但带注释、带特征名称的模型偶尔会有信息丢失。AI生成模型时通常不会设置材料属性、公差、表面粗糙度这些制造信息，所以从AI到可加工之间，还必须有人在CAD里补一轮工程属性。

另一个小提醒：国内很多CAD插件和二次开发脚本对文件路径、中文目录名很敏感。text-to-cad 生成的STEP文件如果放在带中文的路径下，有些软件导入时会报异常。习惯把所有生成文件放在纯英文路径下，能省掉很多莫名其妙的报错。这听起来像玄学，但实际遇到过不止一次。

5.4 什么人适合现在就用 text-to-cad

这个问题我问过自己很多次。结论是：如果你是机械设计老手，text-to-cad 目前能帮你消灭大量重复的标准件和规则件建模时间；如果你是三维建模初学者，它可以当"免费老师"——让AI生成代码，你读代码学习建模思路，比单纯看视频教程更有效率。

反过来，如果你指望"输入一句话，AI全自动出一套符合国标的完整图纸"，那目前还不行。从模型到图纸中间还缺大量的工艺判断和经验信息。更现实的做法是把它当成一个"超级草图工具"：快速得到基础几何，再由人完成工程设计。对我个人来说，用它处理重复性参数件，效率提升是实打实的；但真正有价值的地方，反而是逼着我把设计需求描述得更精确，因为提示词写不清楚，模型就一定生成不对。这个约束，对很多习惯了边画边想的工程师来说，其实是一种挺有益的锻炼。