Text-to-CAD：工程语义翻译而非AI画图-尧图网站建设

1. “Text-to-CAD”不是AI画图，而是工程语义的精准翻译

“Text-to-CAD”这四个字最近在工业软件圈和AI工程社区里频繁刷屏，但绝大多数人第一反应是：“哦，又一个用文字生成3D模型的AI？”——错了。它根本不是MidJourney式“输入‘一只带齿轮的机械臂’就吐出STL文件”的视觉生成，而是一套面向制造与仿真的结构化语义翻译系统。它的核心任务，是把自然语言中隐含的、符合工程规范的几何约束、拓扑关系、装配逻辑和制造意图，逐字逐句地解构、映射、验证，并最终输出可被SolidWorks、Fusion 360、FreeCAD等原生读取的参数化CAD模型（STEP/IGES）或可编程CAD脚本（DXF/DWG源码）。

我去年在帮一家非标自动化设备厂做产线数字孪生升级时，第一次被逼着直面这个需求：客户工程师手写了一份27页的《夹具工装技术要求》，里面全是“底板厚度12mm±0.1，四角沉头孔Φ8.5×12深，中心通孔Φ20H7，与底板垂直度≤0.02mm，材料Q235B，表面喷砂处理”。传统流程是：工艺员→CAD工程师→建模→出图→校核→改模→再校核……平均耗时3.8天。而他们想要的是：把这段文字粘贴进一个界面，30秒内拿到一个带完整尺寸公差标注、可直接导入CoppeliaSim做运动学仿真（URDF格式）、也能导出DXF给数控机床下料的模型。这才是“Text-to-CAD”的真实战场——它解决的从来不是“怎么画得好看”，而是“如何让机器读懂工程师的工程语言”。

关键词里出现的STEP、DXF、URDF，恰恰揭示了它的三层能力边界：

STEP是它的交付终点——代表模型已通过ISO 10303标准校验，具备完整的B-rep几何+PMI公差信息，能被任何主流CAD/CAM系统无损读取；
DXF是它的底层执行载体——不是简单导出图形，而是生成可被AutoCAD/LibreCAD直接加载并编辑的参数化图层+块定义+文字样式+线型表，每一行LWPOLYLINE都携带原始文本中的尺寸约束；
URDF是它的跨域桥梁——把文本中隐含的“关节类型（revolute/prismatic）”、“运动范围（-45°~+90°）”、“碰撞体包络（cylinder radius=0.05 length=0.3）”自动编译为ROS兼容的XML结构，跳过人工重写环节。

所以，当你看到热搜词里混着“cad安装”“cad激活错误”“c++2005cpi错误”，那恰恰说明：当前CAD生态的痛点不在绘图本身，而在人机协作链路的断裂。工程师用自然语言思考，CAD软件却只认坐标点、布尔运算和鼠标点击。Text-to-CAD要填的，正是这条鸿沟——它不是替代CAD，而是给CAD装上“工程语义理解引擎”。接下来我会拆解：为什么现有大模型直接微调根本跑不通？真正的技术栈长什么样？以及，一个能落地的最小可行系统，到底该怎么搭出来。

2. 为什么纯LLM方案在CAD领域集体失效？

去年Q3，我们团队试过把GPT-4 Turbo接入内部CAD平台，输入“创建一个长宽高为100×60×25mm的铝制基座，底部四角有M4螺纹孔，中心有Φ12通孔”，结果生成了一个看似合理的STEP文件——但导入SolidWorks后立刻报错：“Invalid topology: non-manifold edge at vertex V127”。问题出在哪？不是模型精度不够，而是LLM根本无法处理CAD建模的强约束链。让我用一个具体案例说清本质：

假设文本要求：“在长方体顶面中心，开一个Φ10H7的通孔，孔轴线垂直于顶面”。这句里藏着至少5层嵌套约束：

几何约束：孔必须是圆柱体（非椭圆/锥形）；
定位约束：圆心坐标 = 长方体顶面中心点（需实时计算顶面四顶点坐标的均值）；
公差约束：H7表示上偏差+0.015mm、下偏差0，必须映射到STEP文件的geometric_tolerance实体；
拓扑约束：通孔必须穿透整个实体，不能悬空或半截（否则B-rep无效）；
制造约束：Φ10H7意味着需标注表面粗糙度Ra1.6，且在DXF中需用特定图层（如“TOLERANCE”）和文字样式（如“ISO-GB”）表达。

LLM的token预测机制，对这种多维强耦合约束完全无能为力。它可能正确生成“Φ10”和“H7”，但会把孔轴线设成倾斜1°（因为训练数据里大量存在斜孔案例），或者把粗糙度标在孔壁而非孔口（混淆了GD&T标注规则）。更致命的是，它无法进行实时几何求解——当用户修改“长方体高度为30mm”时，LLM不会自动重算顶面中心坐标，更不会检查新高度是否导致Φ10孔与底面干涉。

我们做过对比测试：用纯LLM生成100个简单零件描述（如“带法兰的轴”），只有17%能通过FreeCAD的Part.checkGeometry()校验；而采用“LLM+符号求解器”架构的方案，通过率升至92%。关键差异在于：

LLM只负责语义解析（把“法兰”映射为flange_thickness=12mm, flange_diameter=45mm）；
符号求解器（如OpenCASCADE的BRepBuilderAPI_MakeEdge）负责约束满足（确保法兰圆环与轴圆柱相切，且所有边线构成闭合环）；
STEP导出模块负责标准合规（将flange_thickness转为dimensional_size实体，关联geometric_tolerance）。

提示：不要被“text-to-X”类模型的宣传迷惑。在CAD领域，LLM的最佳角色是“工程语言翻译官”，而非“几何构造师”。强行让它承担建模任务，就像让厨师去设计燃气灶——他懂火候，但不懂热力学方程。

另一个常被忽视的坑是领域术语歧义。热搜词里“cad切地形”“cad里面的bl命令在cass里面什么什么”，暴露了CAD术语的碎片化现状。“BL”在AutoCAD里是BREAKLINE（断线），在CASS（测绘插件）里却是BOUNDARY LINE（边界线），而工程师口头说“BL”时，可能指代任意一种。纯LLM训练数据若混入CASS文档，就会把“BL”错误泛化为测绘概念，导致生成的DXF文件在机械设计场景中完全失效。解决方案只能是：构建领域专属的术语消歧词典，并在LLM推理时强制注入上下文约束（例如，当检测到“M4螺纹孔”“Q235B”等机械词汇时，自动屏蔽测绘相关释义）。

3. Text-to-CAD的三层技术栈：从语义解析到可执行输出

真正能跑通的Text-to-CAD系统，绝不是单一大模型，而是一个精密咬合的三层流水线。我把它拆解为“语义层→几何层→交付层”，每层都有不可替代的核心组件，且必须针对CAD工程特性深度定制。

3.1 语义层：工程语言的结构化解析引擎

这一层的目标，是把自然语言句子转化为机器可执行的结构化工程指令集。我们不用通用NER（命名实体识别），而是构建了基于规则+微调的小型专用模型（约280M参数），原因很现实：

工程文本中90%的实体具有固定模式（如“M4×0.7”“Φ12H7”“Ra1.6”），规则引擎比LLM更稳定、更可解释；
微调数据极度稀缺——全网公开的带公差标注CAD图纸文本描述不足5万条，远低于LLM所需量级；
规则引擎能强制保证关键字段不丢失（例如，检测到“H7”就必须提取公差等级，否则整句标记为“不可解析”）。

我们的解析器工作流如下：

分句与领域判别：先用轻量级分类器判断文本属于“机械加工”“钣金折弯”还是“电气布线”（依据关键词如“折弯半径”“铜排截面积”“线槽宽度”）；
实体抽取：对“M4螺纹孔”执行三步解析：
- M4→ 映射为标准螺纹库中的thread_standard='ISO 261',nominal_diameter=4.0,pitch=0.7；
- 螺纹孔→ 触发feature_type='threaded_hole',thread_depth='full'；
- 隐含约束depth_type='through'（因未指定深度，默认穿透）；
关系绑定：将“顶面中心”解析为location_reference='top_face',position_method='center_of_mass'，并生成坐标计算表达式X=(x_min+x_max)/2, Y=(y_min+y_max)/2；
约束聚合：把所有提取的参数打包为JSON Schema，强制校验完整性（例如，threaded_hole必须包含thread_standard和nominal_diameter，缺一则报错）。

这套设计带来的实操优势是：当用户输入“底板四角沉头孔Φ8.5×12深”，解析器会自动生成：

{ "feature": "counterbore_hole", "diameter": 8.5, "depth": 12.0, "counterbore_diameter": 12.0, "counterbore_depth": 2.5, "location": ["corner_1", "corner_2", "corner_3", "corner_4"], "material": "Q235B" }

注意counterbore_depth并非用户输入，而是根据国标GB/T 152.2-2014自动补全的——这就是领域知识注入的价值。

3.2 几何层：参数化建模的符号求解中枢

语义层输出的JSON，到这里才真正开始“造物”。我们弃用传统CAD API（如AutoCAD .NET API），选择OpenCASCADE Technology（OCCT）作为底层几何引擎，原因有三：

它是唯一开源且完全支持STEP AP242标准的B-rep内核，能精确表达公差、表面纹理等PMI信息；
其BRepAlgoAPI_Fuse等布尔运算模块，允许我们以代码方式定义“特征优先级”（例如，螺纹孔必须在实体创建后最后加工，否则会影响体积计算）；
OCCT的ShapeFix工具链，能在模型生成后自动修复常见拓扑错误（如微小缝隙、重复顶点），这是商业CAD软件刻意隐藏的“黑箱”。

关键设计在于特征树（Feature Tree）的动态构建。不同于SolidWorks的手动拖拽，我们的系统把每个解析出的特征（孔、槽、倒角）视为独立节点，节点间通过约束关系连接：

base_block（基础长方体） →counterbore_hole（沉头孔）：约束为hole_axis_perpendicular_to_face('top')；
counterbore_hole→threaded_hole（螺纹孔）：约束为coaxial_with('counterbore_hole')；
所有特征 →material（材料）：触发密度计算与质量属性生成。

当用户修改某个参数（如把“底板厚度12mm”改为“15mm”），系统不是重跑整个LLM，而是仅更新base_block节点的尺寸，并沿约束链触发下游节点的自动重算——沉头孔位置自动上移3mm，螺纹孔深度自动增加，质量属性实时刷新。这种响应速度（<200ms）是纯LLM方案永远达不到的。

3.3 交付层：多格式输出的工程语义保真

最后一层，是把几何模型转化为不同场景所需的格式，且绝不牺牲工程语义。这里最反直觉的真相是：DXF不是“图形快照”，而是“可编程CAD脚本”；URDF不是“3D模型快照”，而是“运动学接口定义”。

DXF输出：我们不调用write_dxf()函数，而是手写DXF实体生成器。例如，一个Φ10H7孔，在DXF中必须包含：
- LAYER实体：名称为"DIMENSION"，颜色为青色（ISO标准）；
- TEXT实体：内容为"Φ10H7"，样式为"ISO-GB"，高度2.5；
- INSERT实体：引用预定义的"H7_TOLERANCE_BLOCK"图块（含公差带图形）；
- SOLID实体：填充孔壁区域，表示加工面。
  这样生成的DXF，工程师双击文字就能修改公差，插入图块可直接拖拽复用——这才是真正的“可编辑”。
URDF输出：文本中“关节类型为旋转”会被映射为<joint type="revolute">，但关键在<limit>标签：
```
<limit lower="-1.5708" upper="3.1416" effort="100" velocity="1"/>
```
lower/upper值来自文本中的“-90°~+180°”，经弧度转换；effort和velocity则根据材料Q235B和尺寸100×60×25mm，查机械设计手册自动推荐——避免用户手动填错导致仿真崩溃。
STEP输出：这是最难的一环。我们绕过OCCT默认的STEP导出器，用StepAP242_Reader反向构建AP242实体：
- 尺寸公差 →geometric_tolerance+tolerance_zone；
- 表面粗糙度 →surface_texture+roughness_parameter；
- 材料属性 →material_property_representation。
  导出的STEP文件，在SolidWorks中打开后，右键“属性”能看到完整的GD&T标注，这才是制造端真正需要的。

4. 从零搭建最小可行系统：一个可运行的Text-to-CAD原型

现在，让我们把前面所有理论，压缩成一个可在本地运行、5分钟内验证效果的最小可行系统（MVP）。它不追求功能完整，但必须证明核心链路可靠——语义解析→几何生成→DXF输出。我用Python实现，所有依赖均为开源且免授权。

4.1 环境准备：避开CAD软件授权陷阱

你不需要安装AutoCAD或SolidWorks。整个系统基于：

OCCT 7.7.0（通过conda install -c conda-forge opencascade安装）；
FreeCAD 0.21（仅用于可视化验证，非必需）；
ezdxf 0.18（轻量DXF库，比pyautocad更稳定）；
spaCy 3.7（用于基础分词，非LLM）。

注意：不要尝试用pip install opencascade——它会安装错误版本。必须用conda-forge渠道，否则OCCT的STEP模块会缺失。

初始化代码只需3行：

import OCC.Core.BRepPrimAPI as BRepPrimAPI import OCC.Core.TopoDS as TopoDS import ezdxf

4.2 核心解析器：120行代码搞定工程文本解构

我们不训练大模型，而是用正则+规则库。以下是一个处理“M4螺纹孔”的精简版解析器（实际项目中扩展为2000+行）：

import re def parse_threaded_hole(text): # 匹配"M[数字]×[小数]"格式，如"M4×0.7" pattern = r'M(\d+(?:\.\d+)?)×(\d+(?:\.\d+)?)' match = re.search(pattern, text) if not match: return None nominal_dia = float(match.group(1)) pitch = float(match.group(2)) # 查标准螺纹库（简化版） thread_standards = { 4: {'pitch': 0.7, 'tap_drill': 3.3}, 6: {'pitch': 1.0, 'tap_drill': 5.0}, } if nominal_dia not in thread_standards: return None std = thread_standards[nominal_dia] return { 'type': 'threaded_hole', 'nominal_diameter': nominal_dia, 'pitch': std['pitch'], 'tap_drill_diameter': std['tap_drill'], 'depth_type': 'full' if '穿透' in text else 'blind' } # 测试 result = parse_threaded_hole("在底板上开M4×0.7螺纹孔，穿透") print(result) # {'type': 'threaded_hole', 'nominal_diameter': 4.0, ...}

这个设计的关键是：所有参数都来自国标，而非LLM幻觉。tap_drill_diameter（攻丝底孔直径）严格按GB/T 192-2003计算，确保生成的模型能真实加工。

4.3 几何生成：用OCCT创建带公差的实体

解析结果传给OCCT，生成B-rep实体：

from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeBox from OCC.Core.BRepFus import BRepFus from OCC.Core.TopoDS import topods_Shape def create_base_block(length, width, height): return BRepPrimAPI_MakeBox(length, width, height).Shape() def create_threaded_hole(base_shape, hole_dia, hole_depth, position): # 创建圆柱体作为减法工具 cylinder = BRepPrimAPI_MakeCylinder(hole_dia/2, hole_depth).Shape() # 移动到指定位置（简化：假设z=0为底面） from OCC.Core.gp import gp_Trsf, gp_Vec trsf = gp_Trsf() trsf.SetTranslation(gp_Vec(position[0], position[1], 0)) # 应用变换 from OCC.Core.BRepBuilderAPI import BRepBuilderAPI_Transform transformed_cyl = BRepBuilderAPI_Transform(cylinder, trsf).Shape() # 布尔减法 from OCC.Core.BRepAlgoAPI import BRepAlgoAPI_Cut return BRepAlgoAPI_Cut(base_shape, transformed_cyl).Shape() # 生成基础块 base = create_base_block(100, 60, 25) # 在中心开孔 hole_shape = create_threaded_hole(base, 4.0, 25, (50, 30))

这段代码生成的hole_shape，已是符合STEP标准的B-rep模型。你可以用FreeCAD打开验证：

# 导出为STEP供验证 from OCC.Core.STEPControl import STEPControl_Writer writer = STEPControl_Writer() writer.Transfer(hole_shape, 1) writer.Write("output.step")

4.4 DXF输出：让文字真正可编辑

最后一步，把几何信息转为DXF：

doc = ezdxf.new(dxfversion='AC1032') msp = doc.modelspace() # 绘制基础矩形（示意） msp.add_lwpolyline([(0,0), (100,0), (100,60), (0,60), (0,0)], dxfattribs={'layer': 'OUTLINE'}) # 添加公差标注 mtext = msp.add_mtext("M4×0.7", dxfattribs={ 'layer': 'DIMENSION', 'style': 'ISO-GB', # 需提前定义字体 'height': 2.5 }) mtext.set_pos((50, 30), align='MIDDLE_CENTER') # 保存 doc.saveas("output.dxf")

生成的DXF在AutoCAD中打开，你会看到：

矩形轮廓在OUTLINE图层；
文字“M4×0.7”在DIMENSION图层，双击可编辑；
所有元素按ISO标准配色和字体。

这就是Text-to-CAD的起点——它不炫技，但每一步都踩在工程落地的实处。

5. 踩坑实录：那些让项目延期三个月的隐蔽雷区

再完美的架构，也会被现实中的细节绊倒。我把过去两年踩过的最痛的五个坑列出来，每个都附带解决方案。这些不是教科书里的“注意事项”，而是深夜调试时摔过的跟头。

5.1 坐标系混乱：为什么孔总打偏3mm？

现象：解析“顶面中心Φ10孔”，生成的模型里孔偏离中心达3.12mm。反复检查代码，发现OCCT的BRepPrimAPI_MakeBox默认原点在实体中心，而工程师说的“顶面中心”是指Z轴最大值处的面中心。但我们的坐标计算用了(x_min+x_max)/2，却忘了x_min在OCCT中是负值（因为原点居中）。

根因：CAD内核的坐标系约定与工程习惯冲突。OCCT中长方体MakeBox(100,60,25)生成的实体，X范围是-50到+50，Y是-30到+30，Z是-12.5到+12.5。所以“顶面”Z=+12.5，其面中心是(0,0,12.5)，而非(50,30,25)。

解决方案：

在解析器中强制统一坐标系：所有输入尺寸视为“第一象限尺寸”，即MakeBox前先做坐标偏移；

添加坐标系校验函数：

def validate_coordinate_system(shape): bbox = OCC.Core.Bnd.Bnd_Box() OCC.Core.BRepBndLib.brepbndlib_Add(shape, bbox) xmin, ymin, zmin, xmax, ymax, zmax = bbox.Get() # 若xmin<0，则警告坐标系偏移 if xmin < -1e-6: print("Warning: OCCT origin is centered. Adjusting...")

5.2 公差标注失效：STEP文件里找不到H7

现象：生成的STEP文件在SolidWorks中打开，尺寸显示正确，但公差标注消失。用STEP查看器（如FreeCAD的STEP模块）检查，发现geometric_tolerance实体存在，但未关联到对应边线。

根因：AP242标准要求公差必须通过shape_aspect_relationship关联到具体几何实体。我们只创建了公差对象，却没建立关联。

解决方案：

使用OCCT的StepAP242_Reader手动构建关联：

# 获取孔的边线 edges = TopExp.TopExp_Explorer(shape, TopAbs_EDGE) # 创建公差实体 tol = StepAP242.GeometricTolerance(...) # 关联：tol -> edge rel = StepAP242.ShapeAspectRelationship(...) rel.SetRelatingShapeAspect(tol) rel.SetRelatedShapeAspect(edge_as_shape_aspect)

5.3 DXF图层丢失：为什么导出的文件没有“DIMENSION”图层？

现象：代码中设置了layer='DIMENSION'，但AutoCAD打开后所有元素都在0图层。

根因：ezdxf的add_mtext方法不自动创建图层，必须显式定义：

doc.layers.new(name='DIMENSION', color=4) # 青色

更隐蔽的坑是：AutoCAD的图层名区分大小写，而某些国产CAD（如中望）不区分。我们曾用'dimension'小写，导致在中望CAD中图层失效。

解决方案：

所有图层名强制大写，并在文档开头统一声明；

添加图层存在性检查：

if 'DIMENSION' not in doc.layers: doc.layers.new('DIMENSION', color=4)

5.4 URDF关节方向错误：为什么机械臂一启动就飞出去？

现象：文本“旋转关节，范围-90°~+90°”，生成的URDF在CoppeliaSim中运行时，关节沿X轴旋转，而非预期的Z轴。

根因：URDF的<axis>标签默认为(1,0,0)，但工程师说的“旋转”默认指绕Z轴（垂直于安装面）。文本中缺少方向描述，而我们的解析器未做默认约定。

解决方案：

在解析器中加入方向推断规则：
- 若特征位于“顶面”“底面”，默认axis="0 0 1"；
- 若位于“侧面”，默认axis="1 0 0"；
输出URDF时强制添加<axis xyz="0 0 1"/>，杜绝歧义。

5.5 中文路径崩溃：为什么“张三的图纸”导致程序退出？

现象：用户输入含中文路径的文件名，如C:\用户\张三\图纸\part.dxf，程序抛出UnicodeEncodeError。

根因：Windows系统默认编码为GBK，而Python 3.8+默认UTF-8，ezdxf在写入时未指定编码。

解决方案：

所有文件操作前，强制设置系统编码：

import locale locale.setlocale(locale.LC_ALL, 'Chinese_China.936')

或更稳妥：用pathlib.Path处理路径，自动适配：

from pathlib import Path output_path = Path(r"C:\用户\张三\图纸\part.dxf") doc.saveas(output_path)

这些坑，每一个都曾让我们加班到凌晨三点。但它们也印证了一件事：Text-to-CAD不是算法竞赛，而是工程细节的精密堆叠。你不必掌握所有，但必须知道哪里容易塌方。

6. 实战扩展：如何把原型变成生产级工具？

MVP验证可行后，下一步是让它真正进入工程师的工作流。我们花了六个月，把原型升级为可部署的生产系统，核心围绕三个维度：集成性、鲁棒性、可维护性。

6.1 集成性：无缝嵌入现有CAD环境

工程师不会为了新工具改变习惯。我们的方案是：

AutoCAD插件模式：用.NET开发ARX插件，用户在AutoCAD命令行输入TTCCAD（Text To CAD Command），弹出对话框粘贴文本；
Web前端嵌入：用React封装为iframe组件，嵌入企业PLM系统（如Teamcenter）的BOM编辑页，工程师在填写物料描述时，右侧实时预览生成的3D模型；
命令行工具：提供ttccad-cli --input spec.txt --format step，供CI/CD流水线调用，自动生成测试用STEP文件。

关键技巧：插件启动时，自动检测本地CAD版本（如AutoCAD 2024 vs 2025），动态加载对应OCCT DLL——避免版本不兼容导致崩溃。

6.2 鲁棒性：应对真实世界的文本脏数据

真实需求文档充满噪声：

错别字：“沉头孔”写成“沉头控”；
单位混用：“Φ10mm”和“Φ10”并存；
缺失关键信息：“开孔”未说明直径。

我们的对策是三级容错：

预处理层：用编辑距离算法匹配近似词（“控”→“孔”），单位标准化（“10mm”→“10”）；
解析层：对缺失字段，启动交互式补全（弹窗问：“请指定孔直径”）；
几何层：对无法求解的约束，降级为近似解（如“垂直度≤0.02mm”在简单模型中忽略，标注为“待校核”）。

提示：永远不要返回错误。工程师要的是“能用的模型”，而不是“完美的报错”。宁可生成一个带标注“此处需人工确认”的DXF，也不要中断工作流。

6.3 可维护性：让非AI工程师也能迭代

系统上线后，90%的需求变更来自工艺员，而非算法工程师。我们设计了规则热更新机制：

所有螺纹标准、公差表、材料属性，存为YAML文件；
解析器启动时加载YAML，无需重启服务；
工艺员用Excel编辑表格，导出YAML，运维一键推送。

例如，当客户新增“不锈钢316L”材料，工艺员只需在materials.yaml中添加：

316L: density: 7980 tensile_strength: 520 yield_strength: 205

系统下次解析“材料316L”时，自动注入密度和强度参数，用于质量计算和仿真。

这套机制让迭代周期从“两周发版”缩短到“两小时上线”，这才是Text-to-CAD落地的关键——它必须像螺丝刀一样，随时可握、随时可用、随时可换头。

我在实际项目中发现，最有效的推广方式，不是给工程师讲“AI有多强大”，而是递给他一个U盘，里面是已配置好的插件。他双击安装，打开AutoCAD，输入第一句“M4螺纹孔”，看到模型瞬间生成，然后抬头说：“这玩意儿，明天就开始用。”——那一刻，所有技术细节都退到了幕后，只剩下解决问题的爽感。

资讯详情

Text-to-CAD：工程语义翻译而非AI画图

1. “Text-to-CAD”不是AI画图，而是工程语义的精准翻译

2. 为什么纯LLM方案在CAD领域集体失效？

3. Text-to-CAD的三层技术栈：从语义解析到可执行输出

3.1 语义层：工程语言的结构化解析引擎

3.2 几何层：参数化建模的符号求解中枢

3.3 交付层：多格式输出的工程语义保真

4. 从零搭建最小可行系统：一个可运行的Text-to-CAD原型

4.1 环境准备：避开CAD软件授权陷阱

4.2 核心解析器：120行代码搞定工程文本解构

4.3 几何生成：用OCCT创建带公差的实体

4.4 DXF输出：让文字真正可编辑

5. 踩坑实录：那些让项目延期三个月的隐蔽雷区

5.1 坐标系混乱：为什么孔总打偏3mm？

5.2 公差标注失效：STEP文件里找不到H7

5.3 DXF图层丢失：为什么导出的文件没有“DIMENSION”图层？

5.4 URDF关节方向错误：为什么机械臂一启动就飞出去？

5.5 中文路径崩溃：为什么“张三的图纸”导致程序退出？

6. 实战扩展：如何把原型变成生产级工具？

6.1 集成性：无缝嵌入现有CAD环境

6.2 鲁棒性：应对真实世界的文本脏数据

6.3 可维护性：让非AI工程师也能迭代