企业官网建设流程全解析

1. 从一句话到三维模型：text-to-cad 到底在解决什么问题

第一次听到 “text-to-cad” 这个词，很多做机械设计或者工业软件的朋友第一反应是：又来了一个蹭大模型热度的概念。但如果你真的在产线里待过，或者帮客户做过非标自动化项目，就会明白这个方向背后压着多大的痛点。传统 CAD 工作流的起点永远是一个人类工程师打开 SolidWorks、UG/NX 或者中望 CAD，然后从草图开始一笔一笔画。这个过程慢、贵、且高度依赖个人经验。而 text-to-cad 想做的事情非常直接：你用自然语言描述一个零件或者一个装配体，系统直接吐出可用的 CAD 文件，最好是 STEP 这种通用格式，再进一步还能生成 URDF 给仿真环境用，甚至输出 G-code 给加工设备。

我最早接触这个方向是在一个非标夹具的项目里。客户给的输入是一段文字描述加上几张手绘草图，要求三天内出三维模型用于报价。当时团队里两个工程师加班加点画了两天半才勉强搞定，而且中间因为理解偏差返工了一次。那时候我就在想，如果有一个工具能把“一块 200mm x 150mm x 20mm 的底板，四角打 M8 沉头孔，中心开一个直径 60mm 的通孔”这样的描述直接转成 STEP 文件，哪怕精度只有 80%，剩下的 20% 人工修一修，效率也能翻好几倍。text-to-cad 要做的就是这个事情，它不是要取代工程师，而是把工程师从重复性的建模劳动里解放出来。

这个方向适合谁来关注？第一类是做非标设计、夹具检具、钣金件的工程师，你们每天面对大量相似但不完全相同的零件，text-to-cad 可以帮你快速生成基础几何体。第二类是做机器人仿真的朋友，URDF 文件的编写极其繁琐，如果能把文字描述直接转成 URDF 再导入 CoppeliaSim 或者 Gazebo，调试效率会高很多。第三类是做 CAM 加工的师傅，从三维模型到 G-code 的链路如果能和 text-to-cad 打通，小批量定制的响应速度会有一个质的提升。第四类就是做工业软件、CAD 插件开发的程序员，这个方向的技术栈涉及几何内核、大模型微调、文件格式转换，有大量的工程问题值得深挖。

需要提前说明的是，text-to-cad 目前还远没有到“一句话出成品”的程度。它更像是一个高级的建模助手，输出的模型需要人工校验尺寸、公差、装配关系。但即便如此，它在概念设计阶段和快速原型场景下的价值已经非常明显了。接下来我会从整体设计思路、核心技术细节、实操流程、常见问题几个维度，把这个方向拆开来讲清楚。

2. 整体架构设计：text-to-cad 的技术链路是怎么搭起来的

2.1 从文本到几何：三层架构的拆解逻辑

一个完整的 text-to-cad 系统，不管你是用开源方案拼还是自己从头搭，基本都逃不开三层结构：语义理解层、几何生成层、格式输出层。这三层各司其职，层与层之间的接口设计决定了整个系统的上限。

语义理解层负责把自然语言变成结构化的几何参数。举个例子，用户输入“一个长 100mm、宽 50mm、高 30mm 的长方体，顶部中心有一个直径 10mm、深 15mm 的盲孔”。这一层要做的不是直接生成三维模型，而是输出一个结构化的 JSON 或者类似的数据结构，里面包含：基体类型是长方体，尺寸参数是 100x50x30，特征列表里有一个盲孔，位置在顶部中心，直径 10mm，深度 15mm。这一步的准确性直接决定了后续几何生成的质量。我见过很多团队一上来就想着端到端训练一个大模型直接输出 STEP 文件，结果发现模型根本学不会精确的尺寸约束，最后还是要回到“先结构化、再生成”的路子上来。

几何生成层拿到结构化参数后，调用几何内核来构建三维实体。这里的选择很关键。如果你追求工业级精度和 STEP 兼容性，OpenCASCADE 是目前最稳妥的选择，它是很多商业 CAD 的底层内核，对 B-rep 表示的支持非常成熟。如果你只是做快速原型或者可视化，可以用 trimesh 或者 pythonocc 这类轻量级方案，但要注意它们导出的 STEP 文件在复杂曲面上的精度损失。几何生成层的核心挑战在于特征操作的顺序和布尔运算的稳定性。比如先打孔再倒角，和先倒角再打孔，结果可能完全不同。系统需要有一套合理的特征排序策略，通常的做法是按照“基体→减材特征→增材特征→倒角圆角”的顺序来执行。

格式输出层负责把几何内核里的实体转换成目标文件格式。STEP 是最通用的选择，几乎所有的 CAD 软件都能打开。URDF 主要用于机器人仿真，需要额外处理关节、连杆、惯性矩阵等信息。G-code 则是给 CNC 加工用的，需要做切片和路径规划。这一层看起来简单，但实际上坑很多。比如 STEP 文件的版本选择，AP203 和 AP214 在颜色和层信息的支持上就不一样。URDF 的惯性矩阵如果随便填，导入 CoppeliaSim 后仿真结果会完全不对。

2.2 为什么选择“结构化中间表示”而不是端到端生成

这里我要重点讲一下为什么“文本→结构化参数→几何”的三段式设计比端到端生成更靠谱。端到端的意思是训练一个模型，输入文本直接输出 STEP 文件的字节流或者点云。这个思路听起来很酷，但实际做起来有几个致命问题。

第一是尺寸精度。大模型对数字的敏感度远不如对文本的敏感度。你让它生成一个“直径 10mm 的孔”，它可能在大部分情况下生成 10mm，但偶尔会生成 9.8mm 或者 10.2mm。在 CAD 场景下，这种误差是不可接受的。而结构化中间表示可以把尺寸参数单独拎出来，用规则引擎或者专门的数值回归模型来处理，精度可以控制在 0.01mm 以内。

第二是可解释性和可编辑性。端到端生成的模型是一个黑盒，你很难知道它为什么生成了这个形状。而结构化表示是一份清晰的“建模配方”，工程师可以逐项检查参数，发现哪个尺寸不对直接改，改完重新生成即可。这在工程实践中非常重要，因为第一版模型几乎不可能完全正确。

第三是训练数据的获取。端到端训练需要大量的“文本-CAD 文件”配对数据，这种数据非常稀缺。而结构化中间表示可以把问题拆解成“文本→参数”和“参数→几何”两个子问题，前者可以用合成数据来训练，后者本身就是确定性算法，不需要训练。这大大降低了数据门槛。

我自己的经验是，用三段式架构，即使语义理解层只有 70% 的准确率，整体系统的可用性也能达到 85% 以上，因为工程师可以快速修正那 30% 的错误。而端到端方案如果准确率只有 70%，基本就没法用了，因为错误不可预测也不可修正。

2.3 工具选型：几何内核、大模型、格式转换库的搭配方案

具体到工具选型，我推荐一套经过验证的组合。几何内核用 OpenCASCADE，通过 Python 的 pythonocc 或者 cadquery 来调用。cadquery 的 API 设计非常友好，写起来像在写伪代码，适合快速开发。比如生成一个带孔的长方体，cadquery 的代码大概是这样：

import cadquery as cq result = (cq.Workplane("XY") .box(100, 50, 30) .faces(">Z") .workplane() .hole(10, 15)) result.val().exportStep("output.step")

这段代码的可读性极强，即使不懂 CAD 的人也能大致看懂在做什么。语义理解层可以用 OpenAI 的 API 或者本地部署的开源模型，关键是做好 prompt engineering，让模型输出结构化的 JSON。我通常会在 prompt 里给出几个 few-shot 示例，把输入文本和对应的 JSON 结构都写清楚，这样模型的输出稳定性会高很多。

格式转换方面，STEP 的导出用 cadquery 自带的 exportStep 就够了。URDF 的生成需要额外处理，因为 URDF 是 XML 格式，描述的是连杆和关节的树状结构。我一般会写一个转换脚本，从几何模型中提取每个连杆的质心、惯性矩阵、碰撞体形状，然后按照 URDF 的 schema 生成 XML。G-code 的生成可以用 FreeCAD 的 Path 模块或者 pycam，但要注意刀具半径补偿和进给速度的设置。

还有一个容易被忽略的环节是模型校验。生成的 STEP 文件需要做几何有效性检查，比如是否有自相交、是否有零厚度面、是否封闭。OpenCASCADE 提供了 BRepCheck_Analyzer 工具，可以在导出前跑一遍，把有问题的模型拦截下来。这个步骤在实际项目中非常关键，因为一个无效的 STEP 文件导入到下游软件后可能导致整个装配体崩溃。

3. 核心细节解析：语义理解、几何生成与格式输出的关键要点

3.1 语义理解层的 prompt 设计与参数提取技巧

语义理解层是整个系统的入口，它的输出质量决定了后续所有环节的上限。我试过很多种方案，从最开始的纯规则匹配，到后来的微调 BERT，再到现在的 LLM + few-shot，最终发现对于中小规模的应用场景，LLM + 精心设计的 prompt 是性价比最高的方案。

prompt 的设计有几个关键点。第一是要明确输出格式。我会在 system prompt 里写清楚：“你是一个 CAD 参数提取助手，用户会给你一段零件描述，你需要输出一个 JSON 对象，包含 shape_type、dimensions、features 三个字段。”然后给出两个完整的示例。第二是要处理歧义。比如用户说“打一个孔”，没有说直径和深度，这时候模型应该输出一个默认值或者标记为待确认，而不是瞎猜。我会在 prompt 里加一条规则：“如果用户没有指定某个参数，将该参数设为 null，并在 warnings 字段中说明。”

第三是要支持多轮修正。实际使用中，用户很少一次就把所有参数说清楚。系统需要支持“把孔改成直径 12”这样的增量修改指令。我的做法是在对话历史里保留上一轮的结构化参数，让模型基于历史做增量更新，而不是每次从头解析。

参数提取的准确性方面，我实测下来，对于常见的几何特征（长方体、圆柱、孔、倒角、圆角、阵列），LLM 的提取准确率能到 90% 以上。但对于复杂的自由曲面或者非标准特征，准确率会骤降到 60% 左右。所以我的建议是，系统要明确自己的适用范围，在 UI 上引导用户用标准特征来描述，而不是指望模型能理解“一个像水滴一样的形状”这种模糊描述。

还有一个实用技巧是单位处理。用户可能说“10 厘米”也可能说“100mm”，系统需要统一转换成毫米。我通常会在 prompt 里要求模型把所有尺寸转换成毫米后再输出，同时在 JSON 里保留原始单位信息以便追溯。

3.2 几何生成层的特征排序与布尔运算稳定性

几何生成层最头疼的问题不是单个特征怎么生成，而是多个特征之间的顺序和相互作用。我踩过的一个坑是：用户要求在一个圆柱侧面打一个径向孔，然后再在孔口倒角。如果先倒角再打孔，倒角会被孔切断，结果不对。如果先打孔再倒角，倒角会沿着孔的边缘走，这才是用户想要的效果。所以系统需要有一套特征排序规则。

我的做法是把特征分成几类：基体特征（拉伸、旋转、扫掠）、减材特征（孔、槽、切除）、增材特征（凸台、筋）、修饰特征（倒角、圆角、拔模）。执行顺序严格按照“基体→减材→增材→修饰”来。同一类特征内部，按照用户描述的先后顺序执行。这个规则覆盖了 90% 以上的常见建模场景。

布尔运算的稳定性是另一个大坑。OpenCASCADE 的布尔运算在大多数情况下是可靠的，但当两个面几乎共面或者间隙极小时，可能会产生微小的裂缝或者自相交。我的经验是，在布尔运算之前，对参与运算的实体做一次“清洗”，把公差范围内的重合点合并，把小于某个阈值的边去掉。OpenCASCADE 提供了 ShapeUpgrade_RemoveInternalWires 和 ShapeFix_Shape 工具，可以在布尔运算前后各跑一遍。

还有一个细节是圆角的处理。圆角半径不能大于相邻面的最小尺寸，否则会失败。系统需要在生成圆角之前做一个检查，如果半径过大，自动缩小到安全值并给出警告。我通常会把安全阈值设为相邻面最小边长的 40%，这个比例在实际项目中比较稳妥。

3.3 STEP、URDF、G-code 三种输出格式的生成要点

STEP 文件的生成相对直接，但有几个参数需要注意。首先是精度设置，OpenCASCADE 的 STEP 导出可以设置 write.step.unit 和 write.step.schema。单位我一般设为 MM，schema 用 AP214，因为 AP214 支持颜色和层信息，方便下游软件识别。其次是曲线和曲面的精度，默认的 0.001mm 对于大多数机械零件足够了，但如果零件尺寸很大（比如几米长的结构件），可以适当放宽到 0.01mm 以减小文件体积。

URDF 的生成要复杂一些。URDF 描述的是机器人模型，包含 link 和 joint 两类元素。每个 link 需要定义视觉几何、碰撞几何、惯性矩阵。视觉几何可以直接用 STEP 转换过来的网格，碰撞几何通常用简化后的凸包或者包围盒。惯性矩阵的计算需要知道每个 link 的质量和质心，如果用户没有提供，系统需要根据体积和默认密度来估算。我一般用 7850 kg/m³ 作为钢的默认密度，2700 kg/m³ 作为铝的默认密度。导入 CoppeliaSim 之前，一定要检查 URDF 的 joint 轴方向和限位，这两个参数错了仿真结果会完全不对。

G-code 的生成是另一个维度的挑战。从三维模型到 G-code 需要经过 CAM 处理，包括刀具选择、切削策略、进给速度、主轴转速等。text-to-cad 系统如果要做 G-code 输出，通常需要集成一个简化的 CAM 引擎。我的做法是只支持 2.5D 加工（平面轮廓和钻孔），因为 3D 曲面加工的 CAM 太复杂，不适合在 text-to-cad 阶段处理。2.5D 的 G-code 生成可以用 FreeCAD 的 Path 模块，设置好刀具直径和步进深度后自动生成。输出前一定要做仿真验证，检查是否有过切或者撞刀。

4. 实操过程：从零搭建一个 text-to-cad 原型系统

4.1 环境准备与依赖安装

搭建原型系统的第一步是把环境准备好。我推荐用 Python 3.10 以上的版本，因为 cadquery 和 pythonocc 对新版本 Python 的支持比较好。创建一个虚拟环境，然后安装以下依赖：

python -m venv text2cad_env source text2cad_env/bin/activate # Windows 用 text2cad_env\Scripts\activate pip install cadquery openai numpy trimesh

cadquery 的安装在某些平台上可能需要编译，如果遇到问题，可以用 conda 安装：conda install -c conda-forge cadquery。OpenAI 的 API 需要设置环境变量OPENAI_API_KEY，如果你用的是本地模型，可以用 ollama 或者 vllm 来部署，然后把 API 地址指向本地服务。

还需要安装一个 URDF 的解析库，方便校验生成的 URDF 文件：pip install urdf-parser-py。G-code 的生成依赖 FreeCAD，这个需要单独安装，因为 FreeCAD 不是一个纯 Python 库。如果你不想装 FreeCAD，可以用 pycam 作为替代，但功能会弱一些。

环境准备好之后，先跑一个最小验证：用 cadquery 生成一个简单的长方体并导出 STEP，确认几何内核工作正常。这一步很重要，因为 OpenCASCADE 在不同平台上的行为可能有差异，提前发现问题比后面调试半天要好。

4.2 语义解析模块的实现与调试

语义解析模块的核心是一个函数，输入是用户文本，输出是结构化的 JSON。我用 OpenAI 的 API 来实现，prompt 的设计如下：

SYSTEM_PROMPT = """你是一个 CAD 参数提取助手。用户会用自然语言描述一个机械零件，你需要输出一个 JSON 对象。 JSON 结构要求： { "shape_type": "box" | "cylinder" | "sphere" | "cone" | "torus", "dimensions": {"length": float, "width": float, "height": float, ...}, "features": [ {"type": "hole", "position": [x, y, z], "diameter": float, "depth": float}, {"type": "fillet", "edge": "all" | "top" | "bottom", "radius": float} ], "warnings": ["未指定孔深度，已设为默认值 10mm"] } 所有尺寸单位统一为毫米。如果用户没有指定某个参数，设为 null 并在 warnings 中说明。 """

然后写一个函数来调用 API 并解析返回的 JSON：

import json from openai import OpenAI client = OpenAI() def parse_text_to_params(user_input): response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_input} ], response_format={"type": "json_object"} ) return json.loads(response.choices[0].message.content)

调试的时候，我会准备一组测试用例，覆盖常见的零件描述。比如“一个 100x50x30 的长方体，四角打 M6 通孔”、“一个直径 80、高 120 的圆柱，顶部中心有一个直径 20、深 30 的盲孔”、“一个 200x200x10 的板，中心有一个 100x100 的方孔，四角 R5 圆角”。跑一遍看输出的 JSON 是否符合预期，不对的地方调整 prompt。

实测下来，gpt-4o 在几何参数提取上的表现相当不错，标准特征的准确率能到 92% 左右。但要注意 API 的延迟，一次调用大概 2-3 秒，如果要做交互式系统，需要考虑流式输出或者本地缓存。

4.3 几何生成与格式导出的完整代码实现

拿到结构化参数后，下一步是生成几何。我写了一个通用的生成函数，根据 shape_type 分发到不同的构建逻辑：

import cadquery as cq def build_geometry(params): shape_type = params["shape_type"] dims = params["dimensions"] if shape_type == "box": result = cq.Workplane("XY").box(dims["length"], dims["width"], dims["height"]) elif shape_type == "cylinder": result = cq.Workplane("XY").circle(dims["diameter"]/2).extrude(dims["height"]) else: raise ValueError(f"不支持的形状类型: {shape_type}") for feature in params.get("features", []): if feature["type"] == "hole": result = result.faces(">Z").workplane().hole(feature["diameter"], feature["depth"]) elif feature["type"] == "fillet": result = result.edges("|Z").fillet(feature["radius"]) return result

这段代码是简化版，实际项目中需要处理更多特征类型和边界情况。比如孔的位置可能不在面中心，需要根据 position 参数做平移。圆角可能只作用于特定的边，需要根据 edge 参数来筛选。

生成几何后，导出 STEP 文件：

def export_step(shape, filename): shape.val().exportStep(filename, write_pcurves=True)

导出 URDF 需要额外的工作。我写了一个函数，把 cadquery 的实体转换成 URDF 的 link 和 joint：

def export_urdf(shape, filename, link_name="base_link"): # 提取质心和惯性矩阵 volume = shape.val().Volume() center = shape.val().Center() inertia = shape.val().MatrixOfInertia() urdf_content = f"""<?xml version="1.0"?> <robot name="text2cad_robot"> <link name="{link_name}"> <visual> <geometry> <mesh filename="{filename}.stl"/> </geometry> </visual> <collision> <geometry> <mesh filename="{filename}.stl"/> </geometry> </collision> <inertial> <mass value="{volume * 7.85e-6}"/> <origin xyz="{center.x} {center.y} {center.z}"/> <inertia ixx="{inertia[0][0]}" ixy="{inertia[0][1]}" .../> </inertial> </link> </robot>""" with open(filename, "w") as f: f.write(urdf_content)

注意惯性矩阵的单位转换，cadquery 返回的是 mm^5 量级，URDF 需要 kg·m²，需要乘以密度和单位换算系数。这个坑我踩过，导入 CoppeliaSim 后模型直接飞出去了。

4.4 端到端测试与效果评估

把上面几个模块串起来，就是一个完整的 text-to-cad 原型。我跑了一组端到端测试，输入是 20 条不同复杂度的零件描述，输出是 STEP 文件。评估指标有三个：语义解析准确率、几何生成成功率、人工修正时间。

测试结果如下：

从数据可以看出，text-to-cad 在标准机械零件上的表现已经相当可用，但在复杂自由曲面场景下还有很长的路要走。我的建议是，现阶段把系统定位为“标准特征快速建模工具”，在 UI 上明确引导用户用标准特征来描述，避免让用户产生不切实际的期望。

还有一个重要的评估维度是生成速度。从用户输入文本到输出 STEP 文件，整个链路耗时大约 5-8 秒，其中语义解析占 2-3 秒，几何生成占 1-2 秒，格式导出占 1-3 秒。这个速度对于交互式使用是可以接受的，但如果要批量处理几百个零件，就需要考虑并行化和缓存优化。

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

5.1 语义解析常见错误与修正方法

语义解析层最常见的错误是尺寸单位混淆。用户说“10 公分”，模型可能理解成 10mm 而不是 100mm。我的修正方法是在 prompt 里明确列出常见单位的换算关系，并且在输出 JSON 里增加一个 original_unit 字段，方便追溯。如果发现单位错误，可以在后处理阶段做一次校验，比如一个“手机壳”的尺寸不可能是 1000mm，如果解析结果超出合理范围就触发警告。

第二个常见错误是特征位置描述模糊。用户说“在顶部打一个孔”，但“顶部”是指上表面的中心还是某个角落？我的做法是在 prompt 里要求模型对模糊位置输出默认值（通常是面中心），并在 warnings 里说明。用户看到警告后可以补充说明，系统支持多轮对话来细化。

第三个错误是特征之间的依赖关系丢失。用户说“先拉伸一个圆柱，然后在侧面打一个径向孔，孔的中心距底面 30mm”。模型可能只提取了孔的存在，但丢失了“距底面 30mm”这个定位信息。修正方法是在 prompt 里强调要提取所有定位尺寸，并且在 JSON 结构里为每个特征增加 position 字段，支持绝对坐标和相对坐标两种模式。

5.2 几何生成失败的典型原因与排查路径

几何生成失败最常见的原因是布尔运算失败。表现是 cadquery 抛出异常或者生成的实体为空。排查路径是：先检查参与运算的实体是否有效，用shape.val().isValid()判断；如果无效，用ShapeFix_Shape修复；如果有效但布尔运算仍然失败，检查两个实体是否有面重合或者间隙过小，尝试微调其中一个实体的位置或尺寸。

第二个原因是圆角半径过大。cadquery 的 fillet 操作在半径超过相邻面尺寸时会失败。排查方法是先计算相邻面的最小边长，然后检查圆角半径是否超过这个值的 40%。如果超过，自动缩小半径并给出警告。

第三个原因是孔深度超过了基体厚度。比如在一个 20mm 厚的板上打一个 30mm 深的孔，cadquery 会生成一个贯穿孔而不是盲孔。排查方法是检查每个孔的深度是否小于所在方向的基体尺寸，如果大于，自动截断到基体尺寸并给出警告。

5.3 URDF 导入 CoppeliaSim 的常见坑与解决技巧

URDF 导入 CoppeliaSim 是最容易出问题的环节。我整理了一个常见问题速查表：

还有一个坑是 URDF 的坐标系约定。URDF 使用右手坐标系，Z 轴向上。而有些 CAD 软件默认 Y 轴向上。导入前需要做一次坐标变换，否则模型会躺倒。我通常会在导出 URDF 时自动做这个变换，把 Y-up 转成 Z-up。

5.4 性能优化与批量处理的经验分享

当需要批量处理大量零件时，性能会成为瓶颈。我总结了几个优化技巧。第一是缓存语义解析结果，相同的文本描述不需要重复调用 API。可以用一个简单的字典做内存缓存，或者用 Redis 做持久化缓存。第二是并行化几何生成，cadquery 的几何生成是 CPU 密集型的，可以用 multiprocessing 并行跑多个零件。第三是延迟导出，先把所有零件生成到内存，最后统一导出，减少 IO 开销。

还有一个容易被忽略的点是 STEP 文件的体积优化。一个复杂的装配体导出的 STEP 文件可能几百 MB，传输和打开都很慢。优化方法是：移除内部不可见的几何、合并共面、降低曲线精度。OpenCASCADE 提供了 ShapeUpgrade_UnifySameDomain 工具，可以合并共面，通常能减小 30%-50% 的体积。

6. 这个方向后续还能怎么扩展

text-to-cad 目前还处于早期阶段，但它的扩展空间非常大。我个人的判断是，接下来最值得探索的方向有三个。第一个是和现有 CAD 软件的深度集成，比如做一个 SolidWorks 插件，用户在 SolidWorks 里输入文字描述，插件直接在当前装配体中生成零件。第二个是和 CAM 加工链路的打通，从 text-to-cad 生成的 STEP 文件直接进入 CAM 模块生成 G-code，实现从描述到加工的全自动化。第三个是和机器人仿真的结合，把 URDF 生成和 CoppeliaSim 的仿真验证做成一个闭环，用户描述一个机器人臂，系统自动生成 URDF 并跑一遍运动学仿真，验证关节限位和碰撞。

我在实际项目中最大的体会是，text-to-cad 的价值不在于完全替代人工，而在于把工程师从重复性的建模劳动中解放出来，让他们有更多时间去做真正需要创造力的工作。一个熟练的 CAD 工程师用传统方式建一个标准零件大概需要 10-15 分钟，用 text-to-cad 加上人工修正，可以压缩到 3-5 分钟。这个效率提升在批量项目中非常可观。

最后分享一个小技巧：如果你打算在自己的项目里引入 text-to-cad，不要一上来就追求大而全。先从一个细分场景切入，比如只做钣金件或者只做轴类零件，把这一类零件的生成准确率做到 95% 以上，再逐步扩展。这样更容易落地，也更容易让团队接受。