你让 LLM 用 build123d 写个法兰，它能给你两百行 Python；跑完导出的 STL 塞进切片软件，报 non-manifold。你让它生成一份 URDF，关节树对不上，MoveIt 起不来。生成这一段 LLM 已经能干了，剩下的活——几何有效性、STEP 实体规范、G-code 合法性、能不能真正进下游——一直没人担保。

earthtojake/text-to-cad 就是冲这段「最后一公里」来的。它不是又一个文本生成 CAD 的模型，而是一套面向 CAD、机器人、硬件设计 Agent 的 skills 库：把参数化建模、隐式建模、2D 图纸、机器人描述文件、切片 G-code、外部加工与采购，拆成一个个可被 AI Agent 直接装载调用的独立技能，再配一个浏览器 CAD Viewer 做可视化验收。

先说证据边界：本仓库 README 可见部分被截断；下文所有架构与模块描述均来自 CodeWiki 的自动解析（非读源码结论），DeepWiki 素材实际返回的是 Vercel 安全校验页，无法作为第二来源交叉验证。

先看数字：star 多，贡献者少

仓库创建于 2026 年 4 月 22 日，最后一次推送是 2026 年 10 月 4 日——历史不到半年。截至元数据快照：16715 star、1730 fork，但贡献者只有 18 人，open issues 30 个。另外 watchers 与 stars 同为 16715，这个数字本身也不宜过度解读。

它是什么：技能单元，不是模型

据 CodeWiki 解析，结构分四块：skills/、packages/、浏览器端 CAD Viewer、plugin bundles 加 benchmarks。

skills/ 是产品主体，已出现的技能包括 skills/cad（参数化建模）、skills/implicit-cad、skills/dxf、skills/urdf、skills/srdf、skills/sdf、skills/gcode、skills/bambu-labs、skills/step-parts、skills/sendcut。

关键约束是：技能之间禁止直接 import，也禁止从仓库根目录 import。这是为了强制模块化，让每一块都能被单独塞进不同的 Agent 宿主。共性能力则下沉到 packages/——CAD 模型处理、显式与隐式模型渲染、元数据管理，技能引用共享包实现复用。

技术栈上有一处值得注意的分歧：仓库元数据标注主语言为 JavaScript，而 README 徽章是 Python 3.11+（链接指向 skills/cad/requirements.txt）。合理推断是 Web 侧用 JS、几何与技能侧用 Python 的双栈，但官方未对此说明。

架构与数据流

下面这张图（依据 CodeWiki 自动解析整理）就是它声称的完整链路：

Agent / 自然语言请求

→ 对应 skill（以 Python 程序化生成为主）

→ 产出几何或描述文件

→ 校验（几何、格式、完整性）

→ CAD Viewer 预览 / 人工确认

→ 导出目标格式

→ 下游：切片软件 / 机器人仿真 / 按需制造

机器人相关可对接 MoveIt2 做运动规划。开发与发布流程据 CodeWiki 描述，包含 symlink 本地开发、生产打包、自动化语义化版本与 GitHub Release 的 CI/CD。

怎么装：暂时说不清

README 可见部分只有 Docs（cadskills.xyz）、Demo（demo.cadskills.xyz）、Discord、MIT 协议、X 账号 @earthtojake、Python 3.11+ 与 STEP Export 徽章，外加一张演示 GIF，没有可复制的安装命令。

据 CodeWiki 解析有两条路径：本地开发用 symlink 挂载 skills，生产使用 plugin bundle 打包后供外部 Agent 宿主装载。具体命令需以官方文档为准，本文不给不确定的步骤。

怎么用：以技能为单位被装载

用法不是传统 import 一个库，而是 Agent 装载对应 skill bundle 后，按自然语言请求产出并校验产物。素材中确认的产物格式覆盖 STEP/STP、STL、3MF、GLB、DXF，机器人侧 URDF/SRDF/SDF，3D 打印侧 G-code；CAD Viewer 用于产出后的可视化检查与交互式交接。

需要明确的是：API 签名、CLI 参数、skill 调用协议在现有素材里都没有出现，无法判断，此处不做臆测。

生态与依赖：已经碰到实体链路

仓库 topics 共 17 个，指向 build123d、OpenCASCADE（几何内核），以及 3MF/DXF/GLB/STEP/STL/STP 格式族和 robotics 相关标准。据 CodeWiki，它还集成了 MoveIt2（运动规划）、Bambu Lab（打印机控制）、SendCutSend（钣金切割预检）、step.parts（零件采购）。上游是开源几何内核与格式标准，下游是切片软件、机器人仿真栈与按需制造服务。

门槛押在生成之后，也正卡在生成之后

多数 text-to-CAD 项目拼的是生成效果，一张 GIF 就够传播了。text-to-cad 押的是另一头：校验保证产物完整，Viewer 作为多技能共用的人工与 Agent 交接点，benchmark 定义几何要求与测试用例。这让 STEP、URDF、G-code 有可能变成 Agent 的一等 IO。

但反差也在这里——它最核心的卖点是验证，而验证恰恰是它最没被证明的一环：benchmark 的具体评测结果，现有素材中完全没有出现，也没有第三方复现记录。

风险与成熟度

• 几何正确性与「生成—校验」链路的实际可靠性，目前无从判断；

• 强依赖 LLM 与多家外部服务，任意一环变更都会影响可用性；

• 18 位贡献者、单一发起人主导，bus factor 低；

• 技能规范与特定 Agent Skills 生态绑定，存在平台风险；

• MIT 只覆盖本仓库代码，第三方几何内核与加工服务条款需另行确认；

• JS 与 Python 混排，跨语言维护成本不低。

接下来盯两件事

一是 benchmark 结果是否公开、是否被第三方复现——这决定了它是可用的工程交付链路，还是又一轮演示驱动的热度。二是 SendCutSend、step.parts、Bambu Lab 这些已经被接通的接口，会不会从「技能里的一个调用」演化为正式商业合作或收费层（此路径属推断，非事实）。在那之前，更审慎的结论是：star 数证明了这个叙事有多好传播，还没证明这套东西有多可靠。

带走一句：已有 build123d／OpenCASCADE 管线、想给 Agent 加一层「产出后质检 + 人工交接」的团队，可以先小范围试；要交付级几何可靠性、或指望它替代专业 CAD 建模出图的场合，现阶段别依赖它。