1. 从一句话到三维实体text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑敲一行字屏幕上就自动长出一个三维零件。这个直觉方向没错但真正动手做过的人都知道从自然语言到可用的 CAD 模型之间横着一条比想象中宽得多的沟。我最初接触这个方向时也天真地以为只要把文字丢给一个大模型让它吐出几行代码再跑一遍就完事了。结果第一版原型跑出来的东西要么尺寸离谱要么拓扑破面要么干脆连 STEP 文件都导不出来。所以先把话说清楚text-to-cad 不是一个单一工具而是一整条从自然语言描述到结构化几何数据的转换链路。它的核心价值在于把原本需要人工在 CAD 软件里一步步拉伸、旋转、布尔运算才能完成的工作压缩成一段可读、可改、可版本管理的文本描述。这条链路最终要落地的产物通常是三类格式STEP用于通用三维交换和后续加工、URDF用于机器人仿真与运动学建模、以及G-code用于数控加工或 3D 打印的实际执行指令。这三类输出对应的是完全不同的下游场景。STEP 是设计态的通用语言任何主流 CAD 软件都能读URDF 是仿真态的描述它不只关心形状还关心关节、连杆、坐标系这些运动学信息G-code 则是制造态的最终指令直接驱动机床或打印机。很多人做 text-to-cad 时只盯着生成一个模型这个目标却忽略了输出格式决定了整条技术路线的选型这是最容易在项目中期翻车的地方。这篇文章适合三类人看一是想给自己的设计流程加一层自动化能力的工程师二是做机器人仿真、需要批量生成 URDF 的研究者三是纯粹对用代码造物这件事好奇、想动手跑通一个最小可用原型的开发者。我会把整条链路拆开讲包括每一步为什么这么选、参数怎么定、哪些坑我亲自踩过。文中涉及的具体工具和参数一部分来自公开的常见实践一部分是我自己在项目里验证过的方案我会明确区分哪些是通用做法、哪些是我的个人取舍。需要提前说明的是text-to-cad 目前还远没到输入一句话就得到完美零件的程度。它更像是一个高效的初稿生成器 参数化模板引擎能帮你把 70% 的重复劳动干掉剩下 30% 的精细调整仍然需要人的判断。理解这个定位后面的所有技术选择就都顺理成章了。2. 拆解 text-to-cad 的技术链路从语义到几何的四层转换2.1 第一层自然语言到结构化参数的语义解析整条链路的第一道关卡是把一个直径 50 毫米、高 80 毫米、顶部带 M8 螺纹孔的圆柱这种描述变成机器能处理的参数集合。这一步看起来简单实际上是最容易出问题的地方。自然语言里充满了隐含信息和行业默认约定比如标准法兰到底指哪个标准倒角默认多大壁厚在什么场景下取多少这些在人类工程师之间靠默契传递的信息机器完全接不住。我的做法是先定义一套受控的参数字典而不是让模型自由发挥。具体来说我会把常见的几何基元圆柱、长方体、孔、槽、圆角、倒角和它们的必填参数列成一张表然后让语言模型只负责从文本里抽取这些参数而不是直接生成几何代码。这样做的好处是即使模型抽错了某个值错误也被限制在一个明确的字段里容易定位和修正。几何基元必填参数常见默认值易错点圆柱直径、高度、轴向轴向默认 Z直径与半径混淆长方体长、宽、高、定位点定位点默认原点长宽高顺序通孔直径、深度、位置深度默认贯穿位置坐标系螺纹孔公称直径、螺距、深度按标准查表底孔与公称径混淆圆角半径、边选择无默认必须指定半径超过相邻边这张表是我在实际项目里反复迭代出来的。最开始我试图让模型直接输出 OpenSCAD 或 CadQuery 代码结果发现模型经常把参数写进代码里但语义完全对不上调试成本极高。改成先抽参数、再套模板之后稳定性提升非常明显。这里的关键认知是语言模型擅长的是语义理解和意图识别不擅长精确的数值计算和拓扑推理把这两件事分开各用各的强项才是正路。2.2 第二层参数到几何内核的建模指令拿到结构化参数之后下一步是把它翻译成几何内核能执行的建模指令。目前主流的开源几何内核有 OpenCASCADE简称 OCCT商业的有 Parasolid 和 ACIS。text-to-cad 项目里用得最多的是 OCCT因为它开源、功能全、对 STEP 格式支持好。围绕 OCCT 封装的高层建模库最常用的是CadQuery和build123d前者基于 Python 的链式调用风格后者更接近传统的 CAD 操作逻辑。我选 CadQuery 的原因是它的代码可读性强生成的脚本本身就是一份可读的设计文档。比如一个带孔的板子CadQuery 写出来大概是这样import cadquery as cq result ( cq.Workplane(XY) .box(100, 60, 10) .faces(Z).workplane() .hole(8) .edges(|Z).fillet(2) ) result.val().exportStep(plate.step)这段代码的每一行都对应一个明确的几何操作改起来直观。但要注意CadQuery 的链式调用对操作顺序非常敏感先打孔再倒角和先倒角再打孔结果可能完全不同。我在做带孔阵列的零件时就因为顺序问题导致倒角把孔边缘切坏了排查了半天才发现是操作序列的问题。经验是先做减材孔、槽再做修饰圆角、倒角最后做阵列这个顺序能避开绝大多数拓扑冲突。2.3 第三层几何到 STEP 的格式导出与校验STEP 是 text-to-cad 最核心的输出格式因为它是设计态到制造态之间的通用桥梁。但导出 STEP 不是调一个函数就完事里面有几个必须处理的细节。首先是单位OCCT 内部默认单位是毫米但有些库在导出时会带上单位标记如果下游软件读取时单位解释不一致模型尺寸会差 25.4 倍英寸与毫米的换算。我踩过一次这个坑导出的零件在另一个软件里变成了指甲盖大小查了半天才发现是单位标记的问题。其次是实体有效性校验。几何内核在布尔运算后偶尔会产生破面或非流形边这种模型在视觉上看不出问题但导入下游软件时会报错。我的做法是在导出前强制跑一遍有效性检查from OCP.BRepCheck import BRepCheck_Analyzer shape result.val().wrapped analyzer BRepCheck_Analyzer(shape) if not analyzer.IsValid(): raise ValueError(几何体无效需要修复)这一步看起来多余但能帮你把问题拦截在导出之前而不是等到下游软件报错再回头找。STEP 文件一旦导出修复成本远高于在建模阶段修复这是血泪教训。2.4 第四层面向仿真与制造的格式转换如果下游是机器人仿真就需要把几何模型转成 URDF。URDF 的本质是一棵描述连杆和关节的树几何只是其中一个属性。从 STEP 到 URDF 的转换核心工作是把整体模型拆分成有运动学意义的连杆并定义关节的旋转轴和限位。这一步目前没有全自动的可靠方案因为哪里该断开是一个工程判断不是几何问题。我的做法是让 text-to-cad 在生成阶段就带上运动学标注比如在文本描述里明确底座固定、大臂绕 Y 轴旋转、小臂绕 Y 轴旋转然后在建模时按这些标注把模型拆成独立实体最后用脚本组装成 URDF。这样虽然前期描述麻烦一点但省掉了后期手工拆模型的巨大工作量。至于 G-code它通常不直接从 STEP 生成而是经过切片软件3D 打印或 CAM 软件数控加工中转。text-to-cad 在这一环能做的是保证几何模型的朝向和基准面符合加工习惯比如让零件的底面落在 Z0 平面上这样切片或 CAM 时不用再手动摆正。这个细节很小但能省掉每次加工前的手动调整。3. 环境搭建与工具选型为什么我最终选了这套组合3.1 几何内核与建模库的取舍逻辑搭建 text-to-cad 环境第一个决策是选几何内核。商业内核Parasolid、ACIS精度高、稳定性好但授权费用高不适合个人项目和小团队快速迭代。开源方案里OCCT 是事实标准Python 生态里的 CadQuery、build123d、pythonocc 都基于它。我最终选CadQuery OCCT的组合理由有三条一是 Python 生态成熟和语言模型、数据处理库的衔接顺畅二是 CadQuery 的抽象层次合适既不用直接操作 OCCT 的底层 API又能精细控制几何操作三是社区活跃遇到问题能搜到答案。如果你更习惯传统的 CAD 操作逻辑build123d 也值得考虑它的 API 设计更接近 SolidWorks 那种选面、选边、操作的思路。但要注意build123d 相对年轻某些边界情况的处理不如 CadQuery 成熟我在做复杂曲面时遇到过它生成失败的情况换回 CadQuery 就正常了。所以我的建议是主力用 CadQuery遇到它不好表达的操作再考虑其他库补充。3.2 Python 环境与依赖的安装细节环境搭建本身不复杂但有几个细节不注意会浪费大量时间。首先是 Python 版本CadQuery 对 3.9 到 3.11 支持最好3.12 在某些依赖上还有兼容问题。我建议用 conda 建一个独立环境避免和系统 Python 冲突conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge cadquery用 conda 而不是 pip 装 CadQuery是因为它依赖的 OCCT 二进制包在 conda-forge 上有预编译版本pip 装的话经常要自己编译在 Windows 上尤其痛苦。这一点我在三台不同系统的机器上都验证过conda 的安装成功率明显更高。装完之后一定要跑一个最小验证确认几何内核能正常工作import cadquery as cq box cq.Workplane(XY).box(10, 10, 10) box.val().exportStep(test.step) print(几何内核工作正常)如果这一步报错多半是 OCCT 的动态库没找到检查一下环境变量里的库路径。不要跳过这个验证直接开始写业务代码否则后面出了问题你分不清是环境问题还是代码问题。3.3 语言模型接入的两种模式对比text-to-cad 里的语言模型接入有两种典型模式一种是在线 API 调用一种是本地部署。在线 API 的优点是模型能力强、无需维护缺点是数据要出本地、有调用成本、网络不稳定时影响使用。本地部署的优点是数据可控、无调用费用缺点是对硬件有要求、模型能力通常弱于在线版本。我的实际选择是混合模式语义解析这种需要强理解能力的环节用在线 API参数校验和模板填充这种确定性任务用本地规则引擎。这样既保证了理解质量又降低了对外部服务的依赖。具体实现上我会把在线 API 的调用封装成一个带重试和降级的函数网络异常时自动切换到本地的小模型或规则匹配保证整个流程不会因为一次网络抖动就中断。接入模式适用环节优势劣势在线 API语义解析、意图识别理解能力强依赖网络、有成本本地模型参数补全、格式转换数据可控、免费能力有限、需硬件规则引擎参数校验、模板填充确定性高、快覆盖场景有限这张表是我在多个项目里总结出来的分工原则。核心思路是把不确定的任务交给强模型把确定的任务交给规则不要让模型去做它不擅长的精确计算。3.4 版本管理与可复现性设计text-to-cad 项目有一个容易被忽视但极其重要的点可复现性。同一个文本描述今天生成的模型和一个月后生成的模型应该完全一致否则整个流程就没法用于正式生产。要做到这一点需要固定三样东西几何内核版本、建模脚本版本、以及语言模型的输出或者干脆把模型输出缓存下来。我的做法是把每次生成的中间产物都存下来原始文本、解析出的参数 JSON、生成的建模脚本、导出的 STEP 文件全部按时间戳归档。这样即使模型升级导致输出变化我也能追溯到具体是哪一步变了。不要依赖重新跑一遍就能得到一样的结果这种假设在涉及模型和随机性的系统里这个假设几乎总是错的。4. 实战从一段文字到一个可用的 STEP 零件4.1 需求描述的结构化写法要让 text-to-cad 稳定工作输入的文本描述本身需要有一定的结构。完全自由的自然语言虽然理论上可行但实际稳定性很差。我总结了一套半结构化描述的写法既保留自然语言的灵活性又给机器足够的确定性。一个合格的描述应该包含四个部分总体形状、关键尺寸、特征细节、基准与朝向。举个例子一个矩形底板长 120 毫米宽 80 毫米厚 8 毫米。四个角各有一个直径 6 毫米的安装通孔孔中心距边缘 10 毫米。底板中心有一个直径 30 毫米、深 4 毫米的沉台。底面为基准面位于 Z0。这段描述里总体形状是矩形底板关键尺寸是长宽厚特征细节是四个安装孔和中心沉台基准与朝向是底面在 Z0。有了这四要素解析和建模的歧义就小得多。我实测下来结构化程度越高的描述一次生成成功率越高从最初的不到 50% 提升到了 85% 以上。4.2 参数解析与模板匹配的完整代码下面是我实际使用的一段解析加建模代码做了简化但保留了核心逻辑。它接收一段结构化描述先解析出参数再套用模板生成模型import re import json import cadquery as cq def parse_description(text): params {} # 提取长宽厚 dims re.search(r长\s*(\d).*?宽\s*(\d).*?厚\s*(\d), text) if dims: params[length] float(dims.group(1)) params[width] float(dims.group(2)) params[thickness] float(dims.group(3)) # 提取安装孔 hole re.search(r直径\s*(\d).*?通孔.*?距边缘\s*(\d), text) if hole: params[hole_dia] float(hole.group(1)) params[hole_margin] float(hole.group(2)) # 提取沉台 pocket re.search(r直径\s*(\d).*?深\s*(\d).*?沉台, text) if pocket: params[pocket_dia] float(pocket.group(1)) params[pocket_depth] float(pocket.group(2)) return params def build_plate(params): L, W, T params[length], params[width], params[thickness] m params[hole_margin] hd params[hole_dia] result cq.Workplane(XY).box(L, W, T) # 四角安装孔 result ( result.faces(Z).workplane() .rect(L - 2*m, W - 2*m, forConstructionTrue) .vertices().hole(hd) ) # 中心沉台 result ( result.faces(Z).workplane() .circle(params[pocket_dia] / 2) .cutBlind(-params[pocket_depth]) ) return result text 一个矩形底板长120毫米宽80毫米厚8毫米。四个角各有一个直径6毫米的安装通孔孔中心距边缘10毫米。底板中心有一个直径30毫米、深4毫米的沉台。 params parse_description(text) model build_plate(params) model.val().exportStep(base_plate.step) print(json.dumps(params, ensure_asciiFalse, indent2))这段代码的关键设计是解析和建模分离。解析函数只负责从文本里抽数字建模函数只负责用数字造形状。这样当解析出错时我可以单独测试解析逻辑当建模出错时我可以用手工填的参数单独测试建模逻辑。把两个不确定性来源隔离开是调试这类系统的核心技巧。4.3 导出 STEP 时的单位与精度设置导出 STEP 时有两个参数必须显式设置单位和精度。CadQuery 的exportStep默认用毫米但为了保险我会在导出前确认工作平面的单位。精度方面STEP 支持不同的表示精度精度太高文件会很大太低曲面会显得粗糙。对于一般的机械零件我用的经验值是线性精度 0.01 毫米、角度精度 0.1 度这个精度下文件大小和视觉质量比较平衡。from OCP.Interface import Interface_Static Interface_Static.SetCVal(write.step.unit, MM) Interface_Static.SetRVal(write.step.linear, 0.01) Interface_Static.SetRVal(write.step.angle, 0.1)这几行设置看起来不起眼但能避免很多下游软件读取时的兼容问题。特别是单位设置如果你的 STEP 文件要在多个软件之间流转显式设置单位是必须的不要依赖默认值。4.4 生成结果的验证与常见失败模式生成完模型后我有一套固定的验证流程。第一步是几何有效性检查前面提过的BRepCheck_Analyzer。第二步是包围盒尺寸核对确认生成模型的整体尺寸和描述一致bb model.val().BoundingBox() print(f包围盒: {bb.xlen:.2f} x {bb.ylen:.2f} x {bb.zlen:.2f})第三步是特征数量核对比如描述里说四个孔就数一下模型里的圆柱面数量。这三步走下来大部分低级错误都能拦住。常见的失败模式我遇到过几种一是孔的位置算错通常是坐标系理解偏差比如把距边缘 10 毫米理解成了孔中心到边缘的距离还是孔边到边缘的距离二是布尔运算失败通常是两个特征重叠或者相切几何内核处理不了三是倒角半径过大超过了相邻边的长度。这些问题的共同点是它们在几何上都是边界情况而边界情况恰恰是自动化流程最容易忽略的地方。我的应对策略是在参数校验阶段就加上范围检查比如倒角半径不能超过最短边的一半孔间距不能小于孔径等。5. 从 STEP 到 URDF机器人仿真场景的转换要点5.1 URDF 与 STEP 的本质差异很多人以为 URDF 就是带关节的 STEP这个理解不准确。STEP 描述的是静态几何它关心的是形状本身URDF 描述的是运动学结构它关心的是各个部件之间怎么相对运动。一个 URDF 模型里几何只是连杆的一个属性更重要的是关节的类型旋转、平移、固定、旋转轴、运动限位、以及各个连杆之间的父子关系。这个差异决定了从 STEP 到 URDF 的转换不是简单的格式转换而是一次语义重构。你需要决定哪些部分应该合并成一个连杆哪些部分应该拆开用关节连接每个关节的旋转轴指向哪里。这些决策没有唯一正确答案取决于你的仿真目的。比如做抓取仿真时机械臂的每个关节都要独立做整体运动规划时可能只需要几个主要关节。5.2 连杆拆分与关节轴定义的实操方法我的做法是在 text-to-cad 的描述阶段就加入运动学标注。比如描述一个两连杆机械臂时我会这样写底座为固定连杆尺寸 100x100x20。大臂为旋转连杆绕 Y 轴旋转旋转中心在底座顶面中心臂长 200截面 40x40。小臂为旋转连杆绕 Y 轴旋转旋转中心在大臂末端臂长 150截面 30x30。有了这些标注建模脚本就能按连杆分别生成几何体并记录每个关节的旋转中心和轴向。生成 URDF 时几何体导出为 STL 或 DAEURDF 常用的两种网格格式关节信息写入 XML。这里要注意URDF 里的关节旋转中心必须和几何体的实际位置对应否则仿真时会出现部件飘移的现象。我踩过一次这个坑大臂旋转时整个臂绕着一个错误的点转看起来像脱臼了一样排查后发现是旋转中心的坐标算错了。5.3 导入仿真环境时的坐标系对齐URDF 导入仿真环境比如 CoppeliaSim、Gazebo时最常见的坑是坐标系对齐。URDF 用的是右手坐标系Z 轴向上但有些仿真环境默认的坐标系朝向不同导入后模型可能是躺着的或者倒着的。解决办法是在 URDF 的根连杆里显式定义一个基准坐标系或者在导入时手动调整。另一个常见问题是网格文件的路径。URDF 里引用 STL 或 DAE 文件时用的是相对路径如果文件移动了位置导入就会失败。我的做法是把所有网格文件和 URDF 放在同一个目录下用相对路径引用这样整个文件夹可以整体移动而不会断链。这个细节很小但在团队协作时能省掉大量为什么你的模型我打不开的沟通成本。5.4 仿真验证确认模型能正确运动生成 URDF 后一定要在仿真环境里实际跑一遍确认每个关节都能按预期运动。我会做三个检查一是零位检查所有关节在零位时模型应该和设计姿态一致二是限位检查把每个关节推到极限位置确认没有穿模或异常三是运动学检查手动拖动关节确认旋转轴和预期一致。这三步检查能发现大部分 URDF 定义错误。特别是运动学检查很多错误在静态时看不出来一动就暴露了。我建议在正式使用前至少花十分钟做这套验证比后面在仿真里调试半天要划算得多。6. 面向制造的 G-code 生成text-to-cad 的最后一公里6.1 从几何模型到加工指令的中间环节G-code 不是 text-to-cad 直接生成的中间要经过切片3D 打印或 CAM 编程数控加工。text-to-cad 在这一环能做的是为下游加工准备好几何模型包括正确的朝向、合理的基准面、以及必要的加工余量标注。很多人忽略这一点生成的模型虽然形状对但朝向乱七八糟每次加工前都要手动摆正自动化就失去了意义。我的做法是在建模阶段就约定所有零件的底面落在 Z0 平面主要加工面朝上。这个约定写进模板里生成的模型天然符合加工习惯。对于需要多面加工的零件我会在描述里标注每个加工面的朝向生成时按加工顺序排列。6.2 3D 打印场景的切片参数衔接3D 打印场景下text-to-cad 生成的 STEP 或 STL 会导入切片软件。这里的关键是壁厚和最小特征尺寸要和打印工艺匹配。比如 FDM 打印的喷嘴直径通常是 0.4 毫米那么模型里的最小壁厚不应该小于 0.8 毫米两倍喷嘴直径否则打印出来会缺料。我在参数校验阶段会加上这条规则如果描述里的壁厚小于阈值就给出警告。MIN_WALL 0.8 # FDM 最小壁厚 if params.get(wall_thickness, 999) MIN_WALL: print(f警告壁厚 {params[wall_thickness]} 小于建议值 {MIN_WALL})这个检查看起来简单但能避免很多设计出来打不出来的尴尬。text-to-cad 的价值不只是生成形状还包括在生成阶段就规避制造约束这是它比手工建模更有优势的地方。6.3 数控加工场景的基准与余量考虑数控加工对模型的要求更高除了朝向还要考虑装夹基准和加工余量。装夹基准是指零件在机床上的定位面通常需要是一个平整的大面加工余量是指留给后续精加工的材料厚度。text-to-cad 可以在生成模型时自动加上余量标注或者生成一个带余量的毛坯模型。我的做法是生成两个版本一个是净尺寸模型用于最终检验一个是毛坯模型在净尺寸基础上加上 0.5 到 1 毫米的余量用于 CAM 编程。两个模型用同一套参数生成保证一致性。这样 CAM 工程师拿到毛坯模型就能直接编程不用自己再放余量。6.4 加工前的模型自检清单在把模型交给加工之前我会跑一遍自检清单确认几个关键点检查项检查方法不合格处理几何有效性BRepCheck_Analyzer修复破面最小壁厚测量最薄处加厚或改工艺最小孔径对比刀具库换刀或改设计基准面朝向检查包围盒旋转模型单位一致性检查 STEP 头重设单位文件完整性重新导入验证重新导出这份清单是我从多次加工出来才发现问题的教训里总结的。每一个检查项背后都对应一次真实的返工所以不要嫌麻烦跑一遍清单花不了几分钟但能省掉几天的返工时间。7. 踩过的坑与稳定性优化经验7.1 几何内核崩溃的典型触发条件OCCT 虽然成熟但在某些边界情况下会直接崩溃而不是返回错误。我遇到过几次崩溃触发条件包括布尔运算的两个实体完全共面、倒角半径恰好等于相邻边长度、极小的几何特征小于 0.001 毫米。这些情况在手工建模时人会本能地避开但自动化流程不会所以必须在代码里加防护。我的做法是在执行布尔运算和倒角之前先做一轮几何检查把可能触发崩溃的情况拦截掉。比如倒角前检查半径是否小于相邻边长度的一半布尔运算前检查两个实体是否有重叠体积。这些检查会增加一点代码量但能把崩溃率降到接近零。7.2 参数解析歧义的消解策略自然语言里的歧义是另一个大坑。比如直径 10 的孔深 20这个深 20是孔的深度还是孔中心到某个面的距离四个孔均匀分布是圆周均布还是矩形均布这些歧义在人类看来靠上下文能猜但机器不行。我的策略是在描述规范里强制消歧所有尺寸必须带明确的主语所有分布方式必须明确说明。如果描述里出现歧义解析器不猜而是报错并要求补充。这个策略一开始会让描述变得啰嗦但长期来看明确的描述比模糊的描述效率高得多因为省掉了反复确认和返工的时间。7.3 批量生成时的性能与缓存优化当需要批量生成几十上百个模型时性能就成了问题。几何运算本身很耗时一个复杂零件可能要几秒到几十秒。我的优化手段有三个一是缓存解析结果同一段描述不重复解析二是并行生成用多进程把不同模型的生成任务分散到多个核三是增量导出只导出发生变化的模型。并行生成时要注意OCCT 不是完全线程安全的多线程共享几何内核可能出问题。我的做法是用多进程而不是多线程每个进程独立初始化几何内核这样虽然内存占用高一些但稳定性好。在稳定性和性能之间我永远优先选稳定性因为一次崩溃导致的返工成本远高于多占的那点内存。7.4 输出文件的版本管理与追溯最后说一个容易被忽视但很重要的点输出文件的版本管理。text-to-cad 生成的模型会随着描述和代码的变化而变化如果没有版本管理你根本分不清哪个 STEP 文件对应哪个版本的描述。我的做法是给每个输出文件生成一个哈希值哈希值由描述文本、代码版本、参数三者共同计算文件名里带上这个哈希。这样任何时候都能从文件名追溯到生成它的输入。import hashlib def make_hash(text, code_version, params): content text code_version json.dumps(params, sort_keysTrue) return hashlib.md5(content.encode()).hexdigest()[:8]这个哈希值还可以写进 STEP 文件的元数据里这样即使文件被重命名也能从内部追溯来源。在多人协作的项目里这个机制能省掉大量这个文件是哪来的的扯皮。8. 我对 text-to-cad 落地边界的几点判断做了几个 text-to-cad 项目之后我对它的能力边界有了比较清晰的认识。它最适合的场景是参数化程度高、结构相对规整的零件比如法兰、支架、底板、简单的机械臂连杆。这类零件的特征是可以用有限的参数描述清楚几何操作也是标准的拉伸、打孔、倒角组合。在这类场景下text-to-cad 能把设计效率提升好几倍。它不太适合的场景是自由曲面、复杂拓扑优化结构、以及高度依赖工程判断的设计。这些场景下参数化描述本身就很难而且设计决策往往需要反复权衡不是一段文字能说清的。硬要用 text-to-cad 做这类东西投入产出比很低。还有一个现实问题是验证成本。自动生成的模型你必须验证它确实符合需求而验证一个复杂模型的时间可能不比手工建模少。所以 text-to-cad 真正省时间的场景是批量生成相似结构的零件这时候验证一次模板后面几十个零件都能复用这个验证逻辑规模效应才体现得出来。我个人在实际操作中的体会是text-to-cad 目前最务实的定位是参数化模板的快速实例化工具而不是通用设计自动化。把它的能力用在这个定位上它能发挥出很大的价值指望它替代工程师做设计决策那还差得远。这个判断可能会随着模型能力和几何内核的进步而改变但至少现在这是我踩过足够多坑之后得出的结论。