企业官网建设流程全解析

“把一句‘我要一个带四个螺栓孔的外壳’丢进去，几分钟后拿回来一个能编辑、能出工程图、能直接导出 STEP 的 CAD 模型，这放在五年前我是不信的。”干这行的人都知道，CAD 建模最磨人的从来不是“想不出来”，而是“画不出来”。从草图、约束、特征树再到参数关联，软件操作的比重远大于设计本身。text-to-cad 想做的就是这个切口：用自然语言取代那套冗长的建模操作序列。今天我不打算只给你列一堆模型和论文标题，而是把这条链路整个拆开，把技术选型、实测流程、踩过的坑，以及怎么稳定拿到 STEP 文件的完整方案，一次说清楚。无论你只是想快速玩玩，还是准备把 AI 接进正式设计流程，这份内容都能直接照着落地。

1. text-to-cad 不是什么“文字生成图片”，而是把语言翻译成可编辑的实体模型

1.1 它和文生图的本质区别

很多人第一次听到 text-to-cad，第一反应是“这不就是文字生成 3D 图片吗”。大错特错。文生图输出的是像素矩阵，你可以拿它当效果图参考，但它没有尺寸、没有特征树、没有公差概念，也没法进加工流程。而 text-to-cad 要输出的，是一个真正的参数化 CAD 模型，包含实体几何、特征历史、草图约束和可调整的变量。

打个比方：文生图是在给你画一张零件照片，text-to-cad 是在给你交一份完整的建筑图纸，两者虽然都叫“AI 生成”，但信息密度和工程价值完全不在一个量级。前者看一眼就完，后者要能被修改、被重新生成、被送去加工。我最早接触这类项目时，最震撼的也不是模型生成得多漂亮，而是它真的能输出 STEP 这样的标准交换格式，直接丢给 CAM 软件就能干活。

1.2 它到底解决了谁的痛点

过去十年，CAD 软件的功能越来越强，操作也越来越繁琐。一个熟练的工程师能把 SolidWorks 或 FreeCAD 玩出花来，但对大多数非标件、3D 打印爱好者、机械专业学生来说，软件操作本身就是一道高墙。你脑海里想得很清楚的一个支架，打开软件后要先建草图、标约束、拉特征、倒圆角，光是把想法变成模型就得折腾半天。

text-to-cad 想压缩掉的，正是这一大段“人机交互”成本。描述清楚形状、功能、关键尺寸，系统替你完成底层的建模操作。它不取代设计师对结构和功能的判断，但确实把执行层的效率拉高了一大截。我自己的实际感受是：以前一天能画三五个简单零件，现在同样时间可以清掉二十多个，省下来的精力都用在了更值得思考的方案分析上。

1.3 哪些场景最能吃到红利

按我的实测，这三类场景收益最明显。第一类是 3D 打印快速验证，很多配件其实就几个孔、几条筋、一个卡扣，用语言描述比开软件建草图快得多。第二类是机械非标件的前期概念，客户一句话说“我要个电机安装座，四角带孔，中心开大孔”，你先把模型生成出来再逐步精修，比从空白画布开始从容很多。第三类是设计自动化管道，把 text-to-cad 接到上游的 BOM 或配置表，秒级生成不同尺寸的变体，传统手工建模根本跟不上这个节奏。

当然，复杂装配、精密模具、需要严格工程图纸的场合，目前的 text-to-cad 还远不能完全替代人工。但作为前段提速工具，它已经实打实能用了。

2. 技术路线怎么选：代码生成、特征树生成、端到端生成

2.1 路线一：让大模型写 CadQuery 或 OpenSCAD 脚本

这条路线最接地气。大模型天然擅长生成代码，而 CadQuery、OpenSCAD 这类程序化建模库本来就是用代码描述几何。把“一句话需求”交给大模型，让它生成一段 CadQuery Python 脚本，然后本地执行脚本，直接得到实体模型并导出 STEP。

它的本质是“大模型负责把自然语言翻译成程序化建模接口调用，几何内核负责真正算模型”。CadQuery 底层基于开源几何内核 OCP，支持真正的 BREP 实体建模，导出的 STEP 文件包含实体拓扑信息，可以被 FreeCAD、Fusion 等软件继续编辑。OpenSCAD 则更偏 CSG 布尔建模，语法更简单，但参数化能力和实体质量弱一些。

实际操作中，这条路线的可靠性很高，因为大模型写代码的能力已经在过去两年被验证得很充分。只要提示词给够约束，生成脚本的语法错误率可以压到很低。而且代码是文本，可以走 Git 版本管理，每一步改动都可回溯，这比操作一堆 UI 状态踏实得多。

2.2 路线二：让大模型直接生成特征树或调用 CAD 内核 API

更“根正苗红”的路线，是让大模型直接输出一个特征操作序列，比如“创建草图→约束坐标→拉伸→倒角”，然后由 CAD 内核逐条执行。这条路线的输出最接近传统建模流程，模型里会保留完整的特征历史，用户拿到手后可以像原生模型一样改参数、看步骤。

不少 CAD 厂商的研究项目和早期产品走的都是这个方向。它对大模型的要求更高，因为特征树的生成比代码生成更依赖对几何内核的深度理解，而且不同 CAD 软件的特征体系并不通用，要做大量适配。我见过的公开演示确实惊艳，但一遇到复杂特征组合就容易卡壳，稳定性暂时比不过代码生成路线。

2.3 路线三：端到端生成 B-rep 模型或图生 CAD

还有一些研究在尝试让模型直接预测 B-rep 拓扑结构，或者先从文本生成一张或多张 2D 视图，再用视图重建 3D 模型。这条路线远看很美，近看问题不少。直接预测 B-rep 的训练数据很难搞，目前生成结果的拓扑错误率偏高；图生 CAD 则绕了一大圈，误差会在视图重建环节被放大。

所以我的判断很明确：对于个人开发者和小团队，路线一是当下性价比最高的落地方案。它不依赖任何厂商的闭门生态，用免费开源的 CadQuery 加上主流大模型就能搭起一套可用的管道，输出格式标准，出错还能直接改代码。路线二更适合有实力的大团队去做产品化，路线三目前更多停留在学术价值层面。

3. 我用过的工具组合，和一套可以直接照搬的选型逻辑

3.1 工具横向对比

先说结论：如果你的目标是“把文本稳定变成 STEP 文件并纳入后续流程”，CadQuery + 通用大模型是最省心的组合。OpenSCAD 更轻但导出 STEP 需要额外转换，而且它对实体倒角、圆角这类操作的支持比较绕。厂商内测功能体验确实顺畅，但格式和 API 都被绑定，不适合作为可移植的解决方案。学术原型适合做研究参考，离普通工程使用还有点距离。

3.2 我的选型逻辑

选型时我就三个标准。第一是输出必须能进专业流程，不能只是 STL 网格，因为网格模型没法在 CAD 里做特征编辑。第二是链路必须可拆开干预，哪一步错了我能单独修，而不是黑盒一团。第三是成本可控，不依赖昂贵的闭源 API，也不要求特定厂商的软件环境。

CadQuery 精准满足这三点。它是纯 Python 库，几何内核 OCP 开源且活跃，导出的 STEP 文件能被所有主流 CAD 软件打开和二次编辑。更关键的是，CadQuery 是代码构建模型，大模型对它的语法理解足够好，我实测下来，在提示词里给一个 mini 示例后，模型生成的脚本甚至不需要大改就能运行。

如果你是零基础小白，也不用担心。CadQuery 的建模思维跟传统 CAD 不完全一样，但它的 API 设计非常直觉化，工作平面、拉伸、挖孔这几个核心操作花半天就能上手。配合大模型生成代码，你甚至不需要完全读懂每一行，会改关键尺寸参数就能把流程跑通。

4. 完整实操：从一句需求描述到干净可用的 STEP 文件

4.1 第一关：需求描述怎么给才不翻车

很多人第一次玩 text-to-cad 失败，不是 AI 不行，而是自己的描述太像口头禅。“做个带孔的板子”这种话，换个人类工程师来也没法直接开干。想要稳定输出，需求描述必须包含四个要素：零件类型与功能、关键外形尺寸、必须包含的特征、约束条件。

我习惯用固定的描述模板，字段对齐后端解析也方便。一份合格的描述长这样：

请用 CadQuery 实现一个电机安装支架： 底部是矩形底板，长 80 毫米，宽 60 毫米，厚 5 毫米； 四角各有一个直径 6 毫米的通孔，孔心距边缘 8 毫米； 底板中心有一个直径 30 毫米的圆台凸台，高 15 毫米，凸台中心开直径 12 毫米的通孔； 所有尺寸使用毫米单位，孔必须是贯穿孔。

这段描述里，零件、尺寸、特征位置、加工约束全部交代清楚了。模型生成出来即使细节不完美，大方向绝不会错。如果只说“做个支架底座”，AI 就只能在各种可能形状里猜，结果自然不可控。

4.2 第二关：把自然语言翻译成 CadQuery 代码

描述文本准备好后，直接把它丢给大模型，并在提示词里要求“只输出 CadQuery Python 代码，不要解释”。大模型会返回类似下面的脚本：

import cadquery as cq # 参数化变量 base_length = 80.0 base_width = 60.0 base_thick = 5.0 hole_d = 6.0 hole_offset = 8.0 boss_d = 30.0 boss_h = 15.0 center_hole_d = 12.0 result = ( cq.Workplane("XY") .box(base_length, base_width, base_thick) .faces(">Z") .workplane() .rect(base_length - 2*hole_offset, base_width - 2*hole_offset, forConstruction=True) .vertices() .circle(hole_d / 2) .cutThruAll() .faces(">Z") .workplane() .circle(boss_d / 2) .extrude(boss_h) .faces(">Z") .workplane() .circle(center_hole_d / 2) .cutThruAll() )

这段代码的逻辑很直观：先建立一个底板，在底板上表面画四个定位孔并打穿，再在中心位置拉伸一个圆台，最后在圆台中心打穿一个通孔。

这里有一个关键点：代码里的尺寸全部被变量名收纳了，而不是一堆散落的数字。这带来的好处是，导出 STEP 之后，你只要改上面的变量值，重新跑一次脚本，就能秒生成一个尺寸变体。参数化才是 text-to-cad 的隐藏价值，很多人只盯着“生成”两个字，忽略了这一步。

4.3 第三关：对大模型输出做自动校验

大模型写的代码不一定一次就过。我的习惯是先做语法检查，再实际执行，不直接拿结果去导出。这一步看似多余，却是整个流程稳定性的关键。

我写了一个简单的校验脚本：

import ast import cadquery as cq # src 是大模型返回的代码字符串 def validate_and_build(src): try: # 1. 语法检查 ast.parse(src) except SyntaxError as e: return None, f"语法错误: {e}" ns = {} try: # 2. 执行代码，拿到 result exec(src, ns) except Exception as e: return None, f"执行错误: {e}" result = ns.get("result") if result is None: return None, "出错了：脚本里没有 result 变量" return result, None shape, err = validate_and_build(llm_output) if err: print(err) # 可以把错误信息回喂给大模型，让它修正后重新生成 else: print("模型构建成功，实体数量：", len(shape.vals()))

如果校验失败，我的流程是把错误信息连同原始描述一起再次提交给大模型，让它自行修复。通常这一轮迭代后，绝大多数脚本都能跑通。这个“描述→生成→校验→反馈→再生成”的闭环，是 text-to-cad 工程化最核心的套路，比指望模型一次写对靠谱得多。

4.4 第四关：导出 STEP 并检查质量

模型构建成功后，导出 STEP 只是最后一小步：

import cadquery as cq # 假设 result 已经由前面的代码生成 cq.exporters.export(result, "motor_bracket.step")

导出之前我还会顺手检查几项硬指标：零件包围盒尺寸对不对、实体体积是不是合理值、有没有异常的自由边。CadQuery 的 bounding box 接口可以直接拿到尺寸：

bbox = result.val().BoundingBox() print(f"X: {bbox.xlen:.2f} mm") print(f"Y: {bbox.ylen:.2f} mm") print(f"Z: {bbox.zlen:.2f} mm")

这里特别提醒一个单位坑。大模型经常在不同单位间摇摆，有时候把毫米描述理解成厘米，生成结果的包围盒会整体大十倍。所以我要求描述里必须显式标注单位，并在校验阶段用包围盒数据做一次尺寸核对。跑通了这一整套流程，STEP 文件的质量基本不会让你在后续环节丢人。

4.5 从描述到 STEP 的实际效果

用第 4.1 节那个电机安装支架的案例，我在本地跑完整条管道耗时大约十几秒，其中大头是大模型的推理时间，CadQuery 本身执行只占一两秒。导出的 STEP 文件能被 FreeCAD 顺利打开，特征可以被重新编辑，四角孔中心距与底板边距和描述完全一致，中心凸台的尺寸也分毫不差。

一个小提示：生成的 STEP 虽然带实体几何，但并不意味着你已经拿到了“原生特征历史”。CadQuery 导出的是 BREP 实体，进入其他 CAD 软件后还是会被当作“哑模型”，需要用软件里的特征识别功能转成可编辑特征。想要保留参数特征树，就得停留在 CadQuery 脚本阶段，把代码当模型源文件来管理。这是两条不同路线，别混为一谈。

5. 常见问题与排查技巧实录

5.1 生成出来的模型能被编辑吗

这是被问得最多的问题。很多人拿到 STL 文件，放进切片软件一看是能打印的，就说“text-to-cad 成功了”。严格讲，这不算真正的 CAD，因为 STL 是网格，没有几何特征，在 CAD 里只能看不能改。

我自己的做法是坚持走 STEP 导出，只把 STL 当作可视化预览。CadQuery 这条链路天然是 BREP 实体，导出 STEP 后模型的几何拓扑是完全的，任何专业 CAD 软件都能加载并继续操作。如果你的工具链只能产 STL，多半是用了 OpenSCAD 或某些简化模型，建议换成 CadQuery 或加一道格式转换环节。

5.2 生成尺寸和描述对不上

尺寸跑偏九成是单位问题。大模型没有内在的“毫米直觉”，它在训练数据里见过毫米、厘米、英寸混用的场景，经常自作主张换单位。解决方法是描述文本强制写明单位，并在提示词末尾加一句“所有尺寸默认使用毫米，不要进行任何单位转换”。校验阶段再用 bounding box 核对一遍，基本能防住。

另一个常见原因是方位词理解偏差。“左上角”“右边”这类相对位置，大模型偶尔会把坐标系搞反。我的经验是尽量用绝对数字描述位置，比如“孔心距左边距 10 毫米，距上边距 10 毫米”，比“左上角”可靠得多。

5.3 布尔运算老是失败

在 CadQuery 里做复杂的多实体布尔操作时，偶尔会遇到几何内核报错，比如面与面刚好贴合导致运算不稳定。这不是大模型的错，而是几何内核的数值容差问题。

遇到这种情况，先别急着让大模型重写整段代码，先把布尔操作的实体稍微改一点重叠量，或者把“恰好贴合”的两个面改成有意交叉，让内核能稳定求交。也可以提示模型“优先使用 cutThruAll 贯穿操作，不要用 cutBlind 带深度盲切”，后者更容易触发精度问题。

5.4 环境装不起来

CadQuery 的安装经常被吐槽。它依赖 OCP 几何内核，PyPI 上虽然有安装包，但某些平台容易编译出错。我实测比较稳的是用 conda 建独立环境安装，命令就两条：

conda create -n cq python=3.11 conda activate cq pip install cadquery

装好后导入一下验证环境没问题再跑后续流程。如果你还同时装了其他 CAD 相关库，建议尽量隔离，避免依赖冲突把整个 Python 环境搞崩。

5.5 一次生成一堆废模型

高成功率的前提是描述规范、校验闭环、模型选型合适，缺一个都会疯狂翻车。我用过一个比较弱的开源小模型，同样的描述，生成 CadQuery 代码的语法错误率接近一半，根本没法工程化。换成能力更强的通用大模型后，一轮通过率直接跳到八成以上。

我的建议是：别在最开始就把大量精力花在调一个小模型上。先用主流大模型把完整链路跑通，确认流程没问题以后，再考虑用开源小模型做私有化部署。链路本身是通用的，换模型只是换掉底层“翻译器”，前面的校验和导出逻辑完全能复用。

6. 从踩坑到顺手，我沉淀下来的几条实战心得

6.1 提示词模板别贪多，稳定才是第一

我见过不少人上来就写两千字的提示词模板，把材料、公差、表面处理、渲染要求全塞进去，结果模型反而不知道重点在哪。提示词的核心是把几何关键信息说清楚，而不是堆砌越多越好。

我自己长期用的模板短到只有几行：零件名称、外形尺寸、特征列表、位置约束、输出格式要求。额外信息只有在确实会影响几何结构时才加，比如“需要卡扣”“需要加强筋”。其他工艺信息建议放到导出后的工程阶段再说，别再这一步给模型添乱。

6.2 把“参数化”刻进 DNA，而不是只追求一次生成

text-to-cad 最容易被忽略的威力，是配合参数化设计做“模型族”。同一个支架逻辑，底板从 80 毫米改到 200 毫米，孔数从 4 个改成 8 个，在 CadQuery 里就是改两个变量和循环体的事。我只用一次生成建立起代码模板，之后每个变体都是秒级出图。

这也意味着你的描述文本最好结构化：把尺寸、数量、位置都拆成独立变量，而不是揉在一段散文里。这样当你需要批量生成多个规格时，只需要写一个小循环去改变量，调用 text-to-cad 管道批量跑即可，一次能出几十个变体。

6.3 别指望它能一步到位，把它当“可执行草图”

我个人的最终体会是，text-to-cad 成熟度远没到“甩锅式使用”的程度，它更像一个可以自动执行的草图助手。你给它足够清晰的约束，它把 90% 的建模体力活干完，剩下的 10% 仍然需要你动脑：特征顺序是否合理、加工工艺是否可行、装配关系有没有冗余。这些判断能力，恰恰是一个工程师真正的价值所在。

我踩过几次“完全放手”的坑之后，现在的使用习惯是：设计初期先用 text-to-cad 快速出方案，再拿到传统 CAD 里精修关键配合面。一套组合拳下来，既有速度又不丢质量。这套玩法还会继续迭代，我已经把下一步方向定在让 CadQuery 代码模板和本地知识库联动，等跑顺了再回来分享。