企业官网建设流程全解析

text-to-cad这个词，我第一次听说时以为只是某个小众实验项目，真正自己上手跑通之后才发现，它极可能是未来几年机械设计领域最值得关注的方向之一。把一句"做一个直径40mm、内径25mm的轴套，外沿带两个通孔"直接变成可以打开检查、修改尺寸、导出加工的实体模型，这套流程在今天已经可以稳定落地。这篇文章不打算讨论太远的AI前景，而是把我从选择路线、配置环境、写提示词、排查错误到最终产出STEP文件的完整过程整理出来，给正在观望或者刚入坑的读者一份可以照着做的参考。

1. text-to-cad解决的不只是"把话变成模型"

1.1 传统建模流程里的三个真实痛点

第一，学习和记忆成本。传统CAD交互方式虽然直观，但设计师要记住大量命令的位置、面板名称、约束类型。一个草图拉伸加倒角，新手可能要反复找菜单；即便是老手，换一套软件也要重新适应。我见过不少从二维制图转三维设计的工程师，前两周都在跟"约束不闭合""草图过定义"较劲，真正能把精力花在结构设计上的时间少得可怜。语言输入天然绕过了菜单层级问题，用户只要说清楚想要什么，剩下的是模型理解层面的挑战。

第二，改型的重复劳动。机械设计里大部分工作不是从零设计，而是改现有零件：法兰孔直径从48改成52，壁厚从2加到3，长度缩回去10mm。在传统流程里，你得进入草图画改、退出、检查关联特征是否报错，还要小心下游装配的参考面有没有跟着爆红。一次两次还行，每周几十次就很痛苦。参数化能缓解一部分，但参数化本身也需要预先做好命名、公式、逻辑，很多中小团队实际项目里根本来不及维护得那么干净。

第三，设计意图难以传递。三维模型保存了几何，但"这里为什么倒角""这个孔和轴承外圈是什么配合关系"，这些信息很容易丢。等同事接手模型时，往往只能靠猜。更常见的是图纸评审时，别人问一句"这个壁厚能不能再薄一点"，你得在模型里翻半天，才能找到对应到底是哪个特征在控制这件事。text-to-cad之所以让人兴奋，是因为它把语言这种人类最自然的表达方式，变成了几何模型的前端接口。它解决的不仅是最初那句"少点几下鼠标"，而是让设计意图从需求描述开始，就一直跟着模型走。

1.2 关键设计：生成脚本而不是直接生成面片

很多人第一次看到text-to-cad，会以为它像AI生图一样，从文字直接"变"出一个三维网格模型。这个方向确实存在，但真正适合工程场景的做法，是让它先生成一段可执行的三维建模脚本，再通过脚本库执行，得到精确的边界表示模型。

这样做的原因有三个。一是可追溯。脚本里每一行对应一个具体的建模操作，尺寸变了改一行参数就行，不用重头生成。二是可复现。同一个需求描述放在同一个环境里，理论上每次都能得到一样的模型，这对版本管理和质量回溯很有价值。三是可对接下游。脚本库最终可以导出STEP这类工业标准格式，后续的装配、仿真、CAM加工都能无缝衔接，而不是拿到一个只有好看面片的轻量模型。所以在整套流程里，真正依赖的能力是：把自然语言转换成一段结构良好的参数化脚本。

2. 三条实现路线怎么选：先把思路理清楚再动手

2.1 路线一：端到端生成网格，适合概念阶段

端到端生成的核心，是让模型学习从文本到三维表示的映射，可能的输出是点云、体素、隐式曲面或三角网格。优点是上手快，输入一句话就能出一个形状，特别适合把"大概长什么样"的想法快速变成可视化的形态。前几年这类模型刚出来的时候，我身边的工业设计师还挺兴奋，因为他们能用它快速探索多种造型，不需要先学建模软件。

但它有几个明显短板。第一，尺寸精度低，生成的网格很难保证某个圆孔正好是直径6.5mm，实测经常是6.48mm或者6.53mm。第二，拓扑结构不稳定，薄壁、倒角、阵列这类机械设计特征，在纯网格生成里经常出错，孔的边缘不是规则圆弧，法兰面也不是平整平面。第三，无法参数化修改——拿到一个mesh，想改直径，只能重新生成，没办法在模型里直接编辑参数。所以我把这条路线定位成灵感工具，适合设计前期做造型探索，不适合作为text-to-cad主流程。

2.2 路线二：文本转参数化脚本，我推荐的主线

这就是前面说的主线。我在实操中把流程拆成四步：需求描述、生成脚本、执行脚本、检查模型。其中最关键的是要有一个表达能力足够强的脚本库作为后端。它需要支持基本实体（圆柱、方块、球）、布尔运算（并、差、交）、草图拉伸旋转、倒角圆角、阵列复制，最好还能直接导出STEP。

用大语言模型生成脚本，最常遇到的风险是"幻觉"——模型会编造不存在的函数名，或者把参数顺序写反。比如让模型画一个带通孔的圆柱，它可能会写出一个看起来合理但实际不存在的punch_hole()函数。规避方法其实不复杂：第一，在提示词里明确要求"只输出可执行代码，不写解释"；第二，把当前脚本库已知可用的函数名和典型用法片段一起贴给模型，相当于给它一份小抄；第三，让脚本自带自检逻辑，比如生成后打印所有关键尺寸，方便立刻确认。这三招组合下来，成功率能提高一大截。这条路线的优势最贴近工程实际：尺寸精确、可修改、可复用、能导出标准格式。

2.3 路线三：检索加程序化组合，标准件场景最稳

第三种路线不是让模型从零生成，而是先从参数化零件库里找到最接近的模板，再把文本里提到的关键参数填进去。比如用户说"外径40、内径25、长度30的轴套"，系统会在库里检索到轴套模板，然后把三个尺寸写进参数变量，直接生成实例。这适合标准件、常用件和系列化零件，稳定性最高，几乎不会出现几何错误。

缺点也很明显，模板库覆盖有限，真遇到一个形状怪异的非标件就无能为力。实际项目里它更适合跟路线二配合用：标准件走检索，非标件走脚本生成，两者都汇到同一个输出格式。我常跟团队同事说，不要神化AI生成，稳定可靠才是生产工具的前提。基于这一条，我对所有涉及大批量出图的任务，都优先搭建零件库，把text-to-cad用在真正的非标设计上。

2.4 我实际使用的环境配置一览

环境是基础，我一般用一个干净的虚拟环境跑整套流程：

python -m venv cad_env source cad_env/bin/activate pip install z-lib

这里z-lib只是一个代号，指代某个基于Python的开源参数化建模脚本库。它把三维建模操作封装成了易于阅读的链式调用，底层是成熟的几何内核。装好之后，先用一段最简脚本验证环境：

import z_lib # 创建一个直径20mm、高度10mm的圆柱，并导出为STEP文件 result = z_lib.add_cylinder(radius=10, height=10) z_lib.export_step(result, "smoke_test.step")

如果这条跑通，说明整个链路是通的。后续所有生成脚本都基于同样的导入、建模、导出三段式结构，排查问题的时候会非常方便。别小看这个冒烟测试，它能在你真正跑业务模型前，先把环境层的坑筛掉。

3. 实操一个带法兰轴套：从一句话到STEP文件

3.1 需求描述怎么写才不会让AI"懵"

我见过很多失败的生成案例，问题往往不在模型能力，而在需求描述太含糊。比如只写"帮我画一个轴套"，模型不知道该用毫米还是英寸，不知道该不该带法兰，孔的大小也没有边界条件，最后生成出来自然没法用。

比较稳妥的描述模板包含这几块信息：零件类型、整体外形尺寸、关键特征、特征位置关系、单位约定。举例，我这次要生成的是一个带法兰的轴套，完整描述如下：

创建一个带法兰的轴套模型。主体是外径40mm、内径25mm、长度30mm的圆柱套筒，两端做0.5mm倒角。右端带法兰，法兰外径55mm，法兰厚度6mm，4个直径6.5mm的通孔沿法兰圆周均布，分布圆直径48mm。所有尺寸单位统一为毫米。

这里的关键点，一是明确写"直径"而不是"半径"，二是有"分布圆直径"这种工程标准说法，三是单位约定放在最后，避免模型自行换算。你可以试试把这些信息去掉任意一项，生成结果的偏差立刻就会出现，所以这套模板值得背下来。

3.2 生成与执行：让模型只输出可以跑的代码

拿到需求之后，构造提示词：

请把下面的零件需求转换成z-lib可执行的Python代码： （需求内容） 要求： 1. 只输出代码，不要任何解释； 2. 所有尺寸直接使用给定数值，不做单位换算； 3. 最后调用export_step导出为bushing.step； 4. 代码中不要使用不存在的函数名。

生成出来的脚本结构大致如下：

import z_lib # 第一步：主体外圆柱，对应需求"外径40mm" result = z_lib.add_cylinder(radius=20, height=30) # 第二步：挖出内孔，对应需求"内径25mm" result = z_lib.add_hole(result, radius=12.5, depth=30) # 第三步：右端法兰，对应需求"法兰外径55mm、厚度6mm" result = z_lib.add_fillet(result, ...) # 第四步：法兰上的4个均布孔 result = z_lib.add_circle_pattern(...) z_lib.export_step(result, "bushing.step")

这段代码并不是真实库的完整写法，用途是展示基本结构。实际操作中把脚本保存为generate_bushing.py，再执行：

python generate_bushing.py

如果报错，就把完整的错误信息原样贴回模型，让它基于错误修正脚本。这一步通常需要来回两三次，属于正常现象，不用慌。常见错误大多集中在函数名拼写和参数数量上，有了错误信息当作上下文，模型很快能改对。

3.3 三维可视化检查：别只看到"模型出来了"就高兴

生成成功不等于需求被满足。我会打开开源查看器，从线框、着色、半透明三种模式检查模型。

首先是总体轮廓，外圆柱和法兰是否比例正常；其次用测量工具验证关键尺寸——外径40、内径25、法兰外径55、分布圆48；最后数一下孔的数量，4个孔是否都在，倒角是否朝向正确的边。测量这一步，我用的是查看器自带的距离和直径测量，通常点选两个面或一条边就能读出来。

如果发现孔跑到法兰外面，多半是分布圆直径和法兰外径之间的关系搞错了；如果内孔跟外圆不同轴，就要回头检查草图基准面和圆心位置。这一步千万别省。早期踩坑时经常因为多花五分钟在这里，省掉了后面加工厂那边才发现的返工。

3.4 导回CAD环境：从几何模型到装配体

一个STEP文件导回某主流参数化CAD环境，就能开始做装配验证。把轴套和一根直径25mm的轴放到同一个装配里，给轴套内孔和轴外圆的配合面添加同心约束，检查有没有干涉。

这个环节能验证两件事：一是STEP导出精度是否符合预期，二是装配语义是否清晰。需要注意，STEP文件保留的是精确几何和坐标系，但不会保留操作历史树。想继续用参数控制模型，最好把原始脚本放在版本仓库里管理，CAD环境只负责做装配和出图。如果团队里有人习惯在CAD里改尺寸，你可以让他改完再导出参数对照表，反过来同步到脚本里，两边保持一致。

4. 踩坑实录：text-to-cad排错手册

4.1 尺寸漂移和单位混乱

遇到的第一个经典问题，是生成的轴套整体放大了1000倍。一查代码，模型把"毫米"理解成了"米"来写，圆柱半径直接写了20000。这种问题在提示词里不一定能根治，更有效的做法是在生成的脚本里加一段自检输出：

# 调用自检函数，打印模型包围盒尺寸 print(z_lib.bounding_box(result))

把输出和需求对比，如果数量级不对，一眼就能发现。单位问题看起来低级，实际发生频率非常高，尤其是模型训练数据里有大量的英制单位样例，容易在某些语境下把inch和mm搞混。描述里写明"所有尺寸单位统一为毫米"能挡掉大部分问题，但如果发现输出还是有偏移，就靠这行自检代码来兜底。

4.2 特征丢失或位置偏移

法兰上的孔有时数量不对，有时偏移了方向。排查时先看脚本里孔是怎么定位的，是用了极坐标角度，还是绝对坐标点。大多数问题是缺乏明确基准面：模型不知道孔的参考平面应该放在法兰表面还是主体端面。

我的解法是先定义原点，描述里加上"模型原点位于法兰左侧面圆心，Z轴指向轴端方向"。之后描述每一个特征位置，都基于这个基准。这个技巧简单但极其好用，尤其适合有多个特征相对位置要求的零件。再复杂一点的情况，可以把整个建模拆成几步执行：先生成主体，再单独生成法兰，确认无误后再合并，这也减少了模型在一个超长脚本里把坐标系搞混的概率。

4.3 布尔运算失败怎么修

做内孔和孔阵列时，脚本可能报错，大意是"无法完成剪切操作"。这种问题通常是布尔运算的目标面和被减面贴合，比如钻孔的起始点恰好和法兰表面完全共面，导致拓扑退化，几何内核处理不了。

修法有两类。第一，把剪切体的长度稍微增大，让它穿过目标体而不是正好停留在表面，这样布尔运算就有明确的相交区域；第二，给孔留一个极小的间隙，比如在配合面上偏移0.01mm。优先级是先保证几何稳健，再谈表面精度。这个思路跟实际加工里的"留余量"非常像，理解了这个类比，后面遇到类似拓扑错误就不会慌。

4.4 常见失败模式速查表

整理成一张表，方便对照：

这张表是我一边跑一边记下来的，每遇到新问题就补一行。现在排查速度比以前快很多，因为可以直接从症状跳到嫌疑原因，省掉好几轮试错。

5. 反复跑几十次之后才想明白的事

5.1 好的写模型提示词有哪些共同点

跑多了以后发现，成功率高的人和成功率低的人，差别往往不在模型，而在提示词写法。三个共同点很明显：第一，多用精确数值，少用"大一点""厚一点"这种模糊表达；第二，位置关系都有基准，谁在谁的哪个方向、基于哪个面，说清楚比让模型猜靠谱得多；第三，复杂零件拆成多轮来生成，先主体、后特征、再把特征逐个合并，比一次性描述整个零件成功率高一大截。

还有一个技巧：让模型在代码里写注释，标注"这里对应需求的哪句话"。这样出问题的时候，顺着注释就能找到是哪一步理解错了，沟通成本低很多。我现在做所有生成脚本都要求带注释，相当于给每一步建模操作做了天然的追溯索引。

5.2 从"能出模型"到"能交付加工"

模型能出STEP，离能交给加工厂还有一段路。首先是公差，只写"直径40mm"不够，要写"直径40mm H7/h6配合"这类工程语言，AI也能更好地理解配合意图。其次是最小壁厚和拔模角，一些奇怪的孔位可能让壁厚只剩0.2mm，这在机加工里是灾难。最后是螺纹特征，描述"M6螺纹孔"而不是"打一个6mm的孔"，否则加工出来没有螺纹，后续装配才发现问题就晚了。

我的习惯是在需求描述最后加一段制造约束小节：写明材料、加工方式、表面要求。这些信息虽然不会直接改变布尔运算结果，但会让生成出来的模型更贴近实际交付标准。比如要求45钢和表面发黑，模型至少会避免生成过于极端的薄壁结构，整体设计会更合理。

5.3 这个方向还能往哪里扩展

text-to-cad目前还处于比较早期的阶段，但它和现有工具链结合的点已经很多。比如标准件库：把公司内部常用零件全部转成参数化模板，加上检索，工程师只需要说"用上一版的法兰，孔距改成52"，就能出新的模型。又比如反向流程：给AI一个已有模型，让它生成一份自然语言描述，相当于自动写设计说明。再比如多轮对话：生成之后说"把法兰再薄1mm"，系统直接修改脚本参数重跑，而不需要重新描述整个零件。

这些扩展都建立在脚本化模型这个基座上，所以每次我看到有人在纠结要不要在生成结果里保留历史参数，都会建议他一定保留下来。脚本化程度决定这套玩法能走多远，只导出STEP不保留脚本，等于放弃了后续所有高级功能。

我自己这段时间跑下来的最大体会是，text-to-cad不会让设计师失业，但它会显著改变工作方式。以前改一个法兰位置，进草图画约束要五分钟；现在改一句话重新跑脚本，可能只要十秒。节省下来的时间被用来多验证几个方案，整个设计质量会明显提升。最后再分享一个小习惯：所有生成脚本我都会存档，并且写一句和需求对应的说明。几天后要改版，翻出脚本改参数，比对着STEP文件逆向快得多。把这个习惯坚持下来，你会发现这个工具越用越顺手。