我是在某个技术社区的首页上看到 text-to-cad 冲上热门榜的。第一反应是怀疑——直接输入一句“一个能放手机和耳机的小盒子”就能拿到能打印的 3D 模型点进去之后发现它输出的是 OpenSCAD 格式的参数化源码当时就动手试了一晚上。给我的直观感受是这玩意儿不是那种营销号吹出来的“一句话生成视频”的噱头它真的把“自然语言 → 可编辑参数化模型”这条链路跑通了而且跑得相当稳。简单介绍一下text-to-cad 是一个开源项目核心思路是用大语言模型生成结构化的 OpenSCAD 代码步骤然后放入本地执行环境反复验证最终得到可渲染、可导出的 3D 模型。它解决的问题很明确——传统 CAD 软件的学习曲线太陡Fusion 360、SolidWorks 这类工具功能强大但对只想快速做一个打印件的人来说光是把草图约束搞明白就得花掉一个周末。text-to-cad 把门槛压到了“你会说人话就行”。这篇文章适合三类人一是创客和 3D 打印玩家想快速把脑子里的想法变成 STL二是对 AI 编程助手感兴趣的开发者想看看“生成代码 执行反馈 视觉验证”这个闭环是怎么搭起来的三是被 CAD 软件劝退过、但手里攒了一堆“如果有一个 XX 零件就好了”念头的普通人。我会把我实际跑通的案例、失败的折腾过程、以及总结出来的提示词技巧全部写出来尽量做到你照着操作也能复现。1. text-to-cad 的庐山真面目它到底是怎么工作的1.1 它输出的不是模型文件而是 OpenSCAD 代码很多人第一次用 text-to-cad 会困惑我不是要 3D 模型吗怎么给我一堆代码这正是它最关键的架构决策。text-to-cad 不直接生成 STL 或 OBJ 这类二进制网格文件而是生成 OpenSCAD 的.scad源码。OpenSCAD 是一种“程序员向”的 CAD 工具它用代码来描述几何体——立方体就是cube([60, 25, 4])圆柱就是cylinder(h10, r5)两个形状叠加就是union()挖洞就是difference()。为什么选 OpenSCAD 而不直接输出网格因为二进制文件对 AI 来说几乎是不可操作的——你没法让模型去 diff 两个 STL 文件也没法在上下文窗口里贴一段网格数据让它修改。但代码就不一样文本格式天然适合语言模型处理可以做模块化、可以 diff、可以精确调整参数。本质上text-to-cad 是把“建模”这件事转换成了“写代码”然后借用大模型最擅长的方式——生成文本、迭代文本——来解决几何问题。1.2 三步闭环计划、执行、反馈text-to-cad 的工作流拆解下来其实就三步但这个三步闭环是精髓所在。第一步模型接收到你的自然语言描述后不急着写最终代码而是先生成一个结构化的文本计划。这个计划里通常包含一系列标好名字的步骤比如“Step 1: 生成底座模块形状为带圆角的长方体尺寸 60×25×4mm”“Step 2: 生成后挡板模块使用 cube 图元高度 20mm”“Step 3: 合并所有模块并挖出线槽”。每个步骤都带有模块名、图元类型、关键参数相当于先画施工图再动工。第二步这些步骤被翻译成实际的 OpenSCAD 代码片段放到本地执行环境里运行。这一步我看到项目介绍时眼前一亮——很多 AI 生成代码的工具是“生成完就交差”代码能不能跑完全看运气。text-to-cad 不一样它真的会把代码跑一遍根据执行结果和报错信息让模型自我修正。语法错误、未定义模块、布尔运算失败这些在真实执行面前全部原形毕露。第三步执行成功不代表几何体正确。工具会把模型渲染成图像再把图像反馈给模型看让模型用视觉判断“底座的厚度看起来对不对”“线槽的开口是否在正确的位置”“两个部件有没有重叠或分离”。这一步相当于给模型装了一双眼睛让它从“盲写代码”变成“看着成品修改”。这个闭环用一句话概括语言模型负责构思执行环境负责验证渲染图像负责纠偏。它把生成式 AI 最致命的“幻觉”问题用工程手段基本摁住了——你可以幻但跑一遍、看一眼幻出来的错就会被自动发现并修正。1.3 为什么这个架构比“一步到位生成代码”聪明得多我在试过几轮之后才真正理解这个设计的分量。如果你让模型直接一次性生成一个复杂零件的完整代码它会在第 30 行左右开始混乱——函数依赖记混、参数张冠李戴、几何关系错位。这不是模型笨而是上下文窗口有限复杂模型的信息量很容易超出模型的能力边界。text-to-cad 的解法非常像工程里的“分而治之”先规划模块再逐个实现最后组合验证。每个模块占用的上下文都很小模型有足够的“注意力”把每个形状做到位。就像你不会让一个厨师直接做出一整桌宴席而是先让他列菜单、再一道菜一道菜地做、最后整合摆盘——每一步的复杂度都在可控范围内。2. 从零到一跑通环境准备与首个真实案例2.1 环境准备五分钟搭好本地运行环境想复现 text-to-cad 的工作流你不需要很重的依赖。核心就三样东西第一OpenSCAD 本体。去官网下载对应系统的安装包装完就完事。OpenSCAD 自带命令行接口text-to-cad 就是通过命令行调用它来执行代码和渲染图像的。第二大模型 API。项目支持接入主流的语言模型服务包括 OpenAI 的 GPT 系列以及 Anthropic 的 Claude 系列。如果你更在意隐私或者有本地部署需求也可以配置本地模型只要能通过 API 调用并且有基本的代码生成能力即可。这是最简单的方式因为不用处理流式接口和工具调用协议的差异开箱即用。第三Python 环境。text-to-cad 本身是 Python 项目克隆仓库后装几个依赖包就能跑。我是在 Python 3.10 环境里跑的目前没遇到什么兼容性问题。装完之后用一条命令就能启动交互界面然后直接在对话框里输入你要设计的物品描述。它会在后台完成“生成计划 → 执行代码 → 渲染反馈”的循环最终把.scad文件写好。这时候如果你装了 OpenSCAD可以直接点开预览也可以导出成 STL 送去切片打印。2.2 案例一USB-C 集线器支架我第一个正经做的东西是一个 USB-C 集线器支架。为什么选这个因为我桌面上那个集线器老是滑来滑去我想给它一个带线槽、带挡边的底座。我输入的描述是这样的设计一个 USB-C 集线器支架。底座长 60mm、宽 25mm、厚 4mm。底座后方有一个高 20mm 的挡板防止集线器滑落。左右两侧有高 10mm 的挡边。底座前面留一个宽 10mm 的线槽方便走线。所有壁厚不低于 2mm。text-to-cad 生成的代码经过执行、渲染、迭代之后最终给了我一个大致长这样的 OpenSCAD 文件$fn 50; module hub_base() { cube([60, 25, 4]); } module back_stop() { translate([0, -3, 0]) cube([60, 3, 20]); } module side_rails() { translate([0, 0, 0]) cube([4, 25, 10]); translate([56, 0, 0]) cube([4, 25, 10]); } module cable_slot() { translate([25, 3, 4]) cube([10, 20, 8]); } module hub_stand() { difference() { union() { hub_base(); back_stop(); side_rails(); } cable_slot(); } } hub_stand();我盯着这个代码看了半天它比我预想中“懂”很多——挡板做在后沿用了负坐标偏移两侧挡边避开了底座前方位置最聪明的是线槽不是简单地抠一个洞而是把槽体放在底座上方并超出上表面这样既形成了穿线通道又不会破坏底座底部结构。渲染图像里的模型也确实可用集线器放上去刚好卡在挡板和两侧挡边之间线从前面预留的槽口穿出。整个从输入到拿到可打印模型大约花了两分钟。2.3 案例二参数化齿轮——代码的威力开始显现如果说支架是“拼积木”那齿轮就是真正让 OpenSCAD 代码价值凸显的例子。我给 text-to-cad 的描述是生成一个 12 齿直齿轮节圆直径 20mm厚度 4mm中心孔直径 5mm。使用 linear_extrude 从 2D 轮廓拉伸生成。它生成的代码大致长这样$fn 100; module gear_2d(teeth12, pitch_diameter20, tooth_depth2) { pitch_radius pitch_diameter / 2; outer_radius pitch_radius tooth_depth / 2; difference() { union() { circle(r pitch_radius); for (i [0 : teeth - 1]) { rotate([0, 0, i * 360 / teeth]) translate([pitch_radius, -tooth_depth / 2]) square([tooth_depth, tooth_depth]); } } circle(r pitch_radius - tooth_depth / 2); } } module gear(teeth12, pitch_diameter20, thickness4, hole_diameter5) { difference() { linear_extrude(height thickness) gear_2d(teeth, pitch_diameter); cylinder(h thickness 2, r hole_diameter / 2, center true); } } gear();说实话这个齿轮的齿形是简化版的方形齿不是机械设计里标准的渐开线齿形。但对于验证概念、展示“参数化”这项工作来说完全够用——我只要改一下gear()调用里的参数就能瞬间得到不同齿数和中心孔径的齿轮这对快速出原型是非常大的效率提升。这也让我理解了为什么 text-to-cad 选择 OpenSCAD 作为输出格式模型的可编辑性比模型的绝对精度值钱得多。传统生成式三维模型你拿到手基本就是死的网格没法改参数而 OpenSCAD 代码是一个活的结构尺寸可以随时调整。2.4 从单一部件到多部件组合跑通两个简单案例之后我开始试多部件组合——这同样是 text-to-cad 和玩具级生成器的分水岭。我让它做一个手机支架要求是“由一个底板、一个倾斜背板、两个侧翼和一个前挡沿组成背板和底板夹角 70 度”。这次描述明显触发了更复杂的分步规划。text-to-cad 输出里先定义了base_plate、back_plate、side_flap、front_lip四个模块然后在顶层的phone_stand()模块里用rotate()把背板旋转 70 度再用translate()把各部件拼到一起。虽然最终模型因为角度计算有几次渲染出来部件之间有微小间隙但它通过渲染图像的反馈自己发现了问题并在下一轮迭代里自动把部件位置“粘合”到了正确的位置。我个人的经验是多部件组合描述越接近“施工说明书”格式越容易一次成功。比如“先做底板再做背板把背板沿底板后沿旋转 70 度侧翼垂直贴合背板两侧”这样的结构化描述效果远好于“做一个好看点的手机支架”。3. 折腾一周后的失败模式与提示词优化技巧3.1 我实际踩过的五种坑用了大概一周text-to-cad 给我留下的印象已经从“神奇”变成“强但有脾气”。我梳理了五种最常见的失败模式每一种都有对应的解决思路尺寸数字幻觉。我曾让它做一个 60mm 宽的底座第一次渲染出来肉眼看着完全正常但导入切片软件一量——宽度变成了 250mm。这种数字出错很难一眼看出来因为渲染图像里比例是正确的只是整体被放大。后来我会在描述里加一句强制约束“所有尺寸严格按 mm 为单位基准点设为坐标原点不要缩放。”布尔运算挖穿模型。想让一个盒子里留出凹槽我用“挖一个 10mm 深的槽”来描述结果它用difference()减去了一个完全穿透的立方体模型底部直接露出一个大洞。原因是生成代码时没有考虑到底座的厚度和壁厚约束。对策是描述里明确给出“壁厚不低于 2mm槽深不超过底座厚度的一半”。依赖未定义模块。有一次它生成的代码里调用了rubber_feet()模块但我搜遍了整个文件——根本没定义这个模块。这是模型在“自由发挥”时最典型的症状它觉得设计里应该有防滑脚垫就写了调用代码但忘了把实现也写进去。text-to-cad 的执行环境会报“未定义模块”错误并能通过迭代自动补上但会多花几轮时间。人工盯着点一旦发现这种情况直接回复“补全所有未定义模块的实现”是最快的。渲染出空白模型。有一次执行成功、渲染结果却是一片黑——所有部件被放在了不相干的位置导致视野里啥也没有。这通常是坐标系错乱的锅多个部件被 translate 到离谱的坐标。最简单的方法是整体 reset让它把所有模块的坐标系对齐到原点附近。越改越乱的“放飞模式”。迭代到第 8、9 轮时模型可能开始重写自己之前生成的代码把原本正确的模块结构替换成乱七八糟的版本。我后来发现一个有效的止损办法每轮迭代前手动把当前版本的代码存成一个文件做基线一旦发现模型开始瞎改就回滚到上一版并且提醒它“只修改我需要调整的参数不要重构整体结构”。3.2 让 text-to-cad 听话的提示词写法总结下来我用着最顺的提示词格式长这样开头给出整体定位“这是一个 X用途是 Y结构由以下部分组成”每个部件一行写明图元类型、核心尺寸、相对位置“底座用 cube 生成长 60、宽 25、高 4放在原点”明确物理约束“所有壁厚大于等于 2mm中心孔直径 5mm注意单位是 mm”组合关系说明白“背板沿底边旋转 70 度侧翼垂直于背板放在左右两侧”给一个参考坐标系减少位置混乱“以底座左下角为原点X 轴向右Y 轴向前Z 轴向上”这与其说是在和 AI 对话不如说是在写一份简短的 PRD。模型对结构化输入的理解能力远超散文式描述——你把需求说清楚它就能把代码写对。你用模糊的句子它就用模糊的代码回报你。3.3 我推荐的迭代工作流用 text-to-cad 的正确姿势不是“一句话生成最终成品”而是“快速拿到草稿再逐步精修”。我现在的标准流程是五步先用结构化描述生成第一版拿到能渲染的模型。自己看一眼渲染图找出视觉上明显的问题部件错位、方向不对、比例失调。一次只提一条修改意见比如“把底座宽度从 60 改到 75”避免多条指令混合导致它改错地方。修改成功后把该模块的代码复制到单独的备份文件防止后续迭代破坏。重复 2-4 步直到满意为止。这个流程的核心思想是把迭代控制在小步快跑的状态——每次只让模型做一个小改动确认无误后再进下一步。你如果一次性丢给它十个修改要求它大概率改着改着就“人格分裂”了。4. 边界和适合人群哪些工作别指望它4.1 能做的和不能做的text-to-cad 很强但不是万能钥匙。我用一张边界表来说明工作类型效果原因功能性外壳、支架、底座优秀主要由标准几何体拼合布尔运算足够参数化小工具齿轮、法兰、开孔板良好能生成带参数的代码方便批量调整概念验证草模良好几分钟能出可看的模型用于讨论足够复杂装配体多部件运动机构差缺乏配合间隙和约束关系建模能力自由曲面、有机形态鼠标外壳、手柄差OpenSCAD 本身就不擅长曲面建模高精度机械件需要公差配合不建议代码生成无法保证微米级精度行业标准件螺纹、渐开线齿轮不建议需要专门的数学计算和标准库支持我试过让它生成一个符合 ISO 标准的外螺纹——结果它直接给我画了个螺旋线形状的装饰品完全不能用于实际装配。这种需要专业标准支撑的东西目前阶段还是得靠传统 CAD 和专业工具。4.2 它和传统 CAD 是互补关系不是替代关系折腾这一周我对这个工具的心态已经从“卧槽这要取代 CAD 了”变成了“这正好补上 CAD 最缺的那一环”。传统 CAD 软件的强项是精确建模、装配仿真、工程图输出这些 text-to-cad 望尘莫及但传统 CAD 的致命短板是“从灵感的第一版草稿”太慢了——你想画一个手机支架光画草图、加约束、拉伸就要十分钟然后发现角度不对再改又十分钟。text-to-cad 最适合扮演的角色是**“创意速写本”**你把想法用大白话告诉它它当场给你拉出一个能看的 3D 草稿。如果这个草稿靠谱你再考虑要不要用专业软件精修如果不符合预期你什么成本都没损失换个说法再来一次就行。在“想法 → 形状”这个距离最遥远的环节它直接把距离压缩到了接近零。5. 实战手记几个值得记住的小细节5.1 用 CLI 就能做批量渲染text-to-cad 生成完成后我习惯用命令行直接批量处理。比如生成了一堆齿轮变体的.scad文件可以用一条命令全部导出成 STLopenscad -o gear_12t.stl gear_12t.scad openscad -o gear_16t.stl gear_16t.scad配合脚本写一个循环把文件名扫一遍批量导出也就几秒钟的事。这意味着你完全可以建一个“参数化零件库”——每个零件一个 scad 文件需要什么尺寸就改参数重新导出再也不用为了打印不同尺寸的零件反复手动建模。5.2 把它接进自动化长流程里说到批量text-to-cad 的架构让我看到了一个更有趣的玩法把生成代码这一步完全编进自动化流程。比如你在做一个项目需要 20 个不同尺寸的线缆固定夹——你只需要写好一个模板描述再用脚本循环调用 text-to-cad 的接口每次传入不同的尺寸参数它就能批量产出 20 个对应的 STL 文件。这对于小批量定制、创客小工坊来说几乎就是把“设计”这个环节整个自动化掉了。我实际尝试过用 CSV 文件驱动这个流程第一列是零件名第二列是宽度第三列是高度。脚本逐行读取每行调一次 text-to-cad生成对应的 scad 文件并导出 STL。跑完后目录里整整齐齐摆了 20 个不同尺寸的零件全程只需要十分钟。5.3 隐私和数据安全的补充说明如果你用的是在线模型 API你的设计描述理论上会发送到模型服务商那里。对于不涉及产品机密的个人创客项目这完全没问题但如果你要给公司做内部零件的原型验证我建议优先考虑本地部署模型的方式。text-to-cad 的架构其实对本地运行是友好的——因为 OpenSCAD 执行和渲染都在本地完成只有“生成代码”这一环需要大模型而这一步恰好可以通过本地模型完成。这样整条链路全在本地跑设计和数据都不会出你的电脑。5.4 别指望第一版完美但你会喜欢上这个试错速度我把这句话写在最后是因为它是我这一周最大的体感收获。用 text-to-cad 的过程本质上是一个“快速试错”的循环——提示词写得不够好没关系换一种说法再跑一次三分钟后又有一个新版本。传统 CAD 里一次错误操作可能要你五分钟去撤销重做在 text-to-cad 里推翻重来只是一句话的功夫。这种低成本的试错会改变你的工作习惯。以前我设计一个零件脑子里的想法是“我要尽量一次做对”因为改起来太麻烦了现在我会先把我能想到的、哪怕是极其粗糙的描述丢给它看着模型长出来再基于这个可视化的形状调整自己的需求——视觉反馈反过来修正了我脑中的需求描述。这个循环跑顺之后很多原本觉得“做个原型很累”的点子现在都会顺手生成一个模型看看效果再说。