你的智能体可以递给你一个 STEP 文件：text-to-cad 和"代码即几何"这一招

那段从来就不是文字的部分

编程智能体能写软件，因为软件就是文字。这一件事几乎解释了它们擅长的一切。它也解释了为什么它们在机械领域一直没用：一个支架不是文字，一个壁厚不是文字，而一个 STEP 文件当然也不是文字，尽管从技术上讲它确实是。

text-to-cad 是 earthtojake 做的一个 MIT 许可插件，这个月一直挂在 GitHub 趋势榜上，大约 18,600 stars。它用一个老办法解开了这个矛盾：如果这东西不是文字，那就给这东西造一个文字表示。在这里，就是一个参数化 Python 脚本。

智能体的工作不是去想象一个 3D 模型，而是写出几何内核能跑的代码。这个区别就是整个产品。

这个循环实际怎么跑

底下那层引擎是 cadgen，一个 PyPI 上的 Python 包，建在 build123d 之上，build123d 又驱动 Open CASCADE——正经 CAD 工具用的就是这一系几何内核。模型就是一个普通 Python 脚本：一个用 step 定义装饰、返回一个 shape 的函数。

假设你想要一个 3mm 壁厚、两个 M3 孔的相机支架。你用文字描述它。智能体写出带参数的脚本，参数有壁厚、孔径、孔间距。cadgen 跑一遍，写出 STEP；你要的话还能出 STL、3MF 或 GLB。想改孔位，改一个数字，再跑一遍。模型源码就留在仓库里，跟你的其他代码挨着，也就是说它可以被 diff、被 review、被回滚，跟别的东西一样。

这就是精确几何和"看着像"的网格之间的区别。网格生成器产出的是一个看起来像支架的表面。实体建模器产出的是一个壁厚已知的支架，而加工厂会收 STEP 文件，同时会礼貌地拒掉你那个由 4,000 个三角面拼成的曲面 STL。

插件还管那些决定设计能不能落地的无聊活。它跑面向制造的设计检查和面向增材制造的设计检查——壁厚、悬垂、拔模角、倒扣——而且每条结论都会给出背后的规则，不是甩一句干巴巴的警告。它能出带尺寸的工程图 PDF，有视图、隐藏线、孔标注和图框。它能写激光切割用的 DXF 轮廓，通过 OrcaSlicer 切片出 G-code，把打印任务发到 Bambu Lab 机器上，给 SendCutSend 跑上传前检查，也能写 URDF、SRDF 和 SDF 文件，用于机器人描述和仿真世界。

还有个本地查看器。在支持的 app 里，模型会以卡片形式出现在聊天里；别的地方就给你一个 localhost 链接。

为什么这东西能推广

CAD 这个用例很具体，但这个模式不具体。任何具备两个属性的领域，都能交给编程智能体：一是产物的代码表示，二是一个能判断产物有没有效的检查器。

机械零件两样都有。脚本是表示，可制造性检查是验证器。网页两样都有：HTML 和浏览器。基础设施两样都有：配置和 plan。视频直到不久前两样都没有——至少没有智能体能执行的形式，而这正是 HyperFrames 这类项目在填的坑。

一个领域要是缺检查器，智能体就会满怀信心地产出垃圾。这就是 "AI for 3D" 一直卡在预览阶段的原因：在"看起来像把椅子"和"能造出来"之间，没有验证器。

这个模式的另一半是本地执行。cadgen 跑在你自己的机器上，对着一个真的几何内核。几何这一步，没有任何东西是被神经网络近似出来的。智能体出参数化的意图，内核出真相。

采用成本，这些是真的

有两件事会咬人，而且两件都写在仓库里，不是让人踩坑踩出来的——这点得给作者记一功。

Windows 11 有个专门的坑。 CAD 内核的 Python 绑定带了一个未签名的原生模块，而 Windows 11 的 Smart App Control 在全新安装时默认开着，会把它拦下来。然后每条命令都以 DLL 加载错误失败。没有针对单个应用的例外。你的选择是关掉 Smart App Control（有些系统上只能靠重装 Windows 才恢复），或者把 CAD 技能放到 WSL 下跑。有个 doctor 命令能识别这种情况，所以你至少能很快知道。

遥测默认开启。 README 把它写得异常详细，这个直觉是对的。发出去的是：版本、安装来源、操作系统、你用哪个智能体 app，还有一些计数，比如每个工具被调用了多少次、建了多少模型，以及从固定列表里选的失败原因，而不是错误文本。崩溃报告包含错误类型和代码里失败的位置。所有东西都打上一个随机安装 ID，存在 PostHog；服务器从 IP 推断你的国家，但不保留地址。永远不发的是：文件名、路径、文件内容、prompt。一条命令就能关掉，关掉时也会把已经发出去的删掉，而且 CI 里和开发版安装都不发。

这两件事对一个年轻项目来说都正常，也都影响采用。商业 CAD 厂商两样都不会做。

它不适合拿来做什么

有机形状。角色、手办、雕塑形态——任何形状本身是目的、不是功能的东西，那是网格生成的地盘，基于网格的 image-to-3D 模型是更好的工具。想用参数描述一条龙，会是一个很糟的下午。

它也不能替代工程签核。DFM 技能是一次引导式审查，不是认证。如果一个零件要承载人的体重，还是得有人类工程师在图纸上签字。这个循环的终点是有人去付一张发票，而人类大概就该待在这个位置上。

仓库本身很年轻，跑得很快：2026 年 4 月创建，超过 1,400 commits，一个 PyPI 包发了几十个版本，十月初两天里连发了三个版本。这个速度，你要是喜欢新技能就是优点，你要是需要稳定就是风险。

README 里那句话，才是重点

描述里埋了一个很容易被跳过的说法：这个插件给你的智能体一套真正的 CAD 工作流。不是 demo，不是 prompt 包装，而是一套有表示、有执行器、有验证器、还能把活交给加工方的工作流。

这就是那种能让智能体在软件之外也有用的东西的形态。不是一个懂支架的模型，而是一个循环：模型写出可执行的东西，另一个东西去检查它，输出是另一个系统能接受的文件。智能体不需要擅长 CAD，它需要擅长代码，而这个领域需要有编译器。

机械工程先走到这一步，是因为它的编译器已经五十岁了，而它的验证器是一套制造规则。其他任何领域只要凑齐这两块，一年之内看起来都会是这个样子。