CAD 这个领域过去几十年一直是人操作软件的模式——打开客户端、画草图、拉伸、倒角一步步手动完成。但最近一两年一个明显的变化正在发生用自然语言直接描述一个零件让 AI 把这段描述翻译成可编辑的 CAD 模型文件。Text to CAD 这条路线从论文走向了开源工具链配合 Codex、OpenClaw 这类能读写本地文件、执行命令的智能体整个流程已经能跑通到说一句话生成一个能打开、能改参数的模型。这篇内容面向三类人一是做机械设计、想用 AI 提效的工程师二是搞自动化、想把 CAD 生成接进自己流水线的开发者三是刚接触这块、想搞清楚 Text to CAD 到底能干什么、怎么落地的新手。我会把从环境搭建、模型生成、参数化改造到踩坑排查的完整链路讲清楚重点放在为什么这么选、为什么这么配上而不是丢一堆命令让你自己猜。文中涉及的工具选型、参数配置都基于常见工程实践你可以直接照着复现。1. Text to CAD 到底在解决什么问题1.1 传统 CAD 建模的瓶颈在哪先说清楚痛点不然容易把 Text to CAD 当成玩具。传统参数化建模比如用主流三维 CAD 软件的核心工作流是脑子里先有一个几何形状然后通过草图约束、特征操作把它翻译成软件能理解的指令序列。这个翻译过程高度依赖人的空间想象力和软件熟练度。一个中等复杂度的支架熟练工程师可能要画两三个小时其中大量时间花在重复的约束标注、尺寸对齐上。更麻烦的是改需求。客户说这个孔位往左挪 5 毫米顺便把壁厚从 3 加到 4你得回到特征树里找到对应草图改约束、重建、检查有没有报错。参数化本来是为了解决这个问题但前提是模型建得规范特征树干净。现实中很多模型是能出图就行改起来照样痛苦。Text to CAD 想解决的正是从意图到几何这一段。你用自然语言描述形状、尺寸、特征AI 负责生成对应的建模脚本或模型文件。它的价值不在于替代工程师而在于把描述需求和得到初版模型之间的时间从小时级压到分钟级让人把精力放在校验和优化上。1.2 为什么是代码生成而不是直接出模型这里有个关键的技术路线选择值得展开讲。Text to CAD 目前主流有两条路一条是直接生成网格或边界表示B-rep数据另一条是生成建模脚本代码比如 CadQuery、OpenSCAD 这类基于代码的建模语言再由脚本执行出模型。直接生成几何数据的路线优点是端到端缺点是不可编辑——生成出来是一坨死几何想改参数得重新生成。而生成代码的路线本质是把自然语言翻译成参数化脚本脚本里尺寸、特征都是显式变量改一个数字就能重建。这就是为什么 Codex、OpenClaw 这类能写代码、能执行代码的智能体特别适合这条路线它们天生就是处理代码的。我实测下来的结论是代码生成路线在工程可用性上明显更强。因为 CAD 建模语言本身就是参数化的AI 生成的脚本天然带参数后续改型、批量生成变体都很方便。而且脚本是纯文本能进版本管理能 diff能 review这对工程团队来说是刚需。1.3 Codex 和 OpenClaw 在链路里各扮演什么角色很多人把这两个东西混为一谈其实定位不同。Codex 类工具的核心能力是理解自然语言 生成/修改代码它负责把一个 80x60x10 的底板四角各一个直径 6 的通孔孔中心距边缘 10 毫米这种描述翻译成一段 CadQuery 或 OpenSCAD 脚本。OpenClaw 这类智能体框架的核心能力是操作本地环境——读写文件、执行命令、调用工具、管理多步任务。它负责把 Codex 生成的脚本落地写到文件里、调用 Python 解释器执行、捕获报错、把错误信息回传给模型让它自我修正最后把生成的模型文件放到指定目录。简单说Codex 管写什么OpenClaw 管怎么跑起来。两者配合才能形成描述→脚本→执行→模型→校验→修正的闭环。单独用任何一个链路都是断的。2. 环境搭建从零把链路跑通2.1 基础依赖的安装顺序与理由环境这块顺序很重要装错了后面全是坑。推荐顺序是先装 Node.js 运行时再装 Python 环境然后装 CAD 建模库最后配智能体。Node.js 是很多智能体工具的运行基础官网下载 LTS 版本即可别追最新版稳定优先。装完用node -v和npm -v验证。Python 建议用 3.10 或 3.11太新的版本有些 CAD 库还没适配。装 Python 时记得勾选添加到 PATHWindows 上这一步漏了后面调用解释器会找不到。CAD 建模库这块CadQuery 是目前代码建模里生态最成熟的之一基于 OpenCASCADE 内核能导出 STEP、STL 等格式。安装用 pippip install cadquery如果装的时候报编译错误多半是缺 C 构建工具。Windows 上装 Visual Studio Build ToolsLinux 上装 build-essential。这个坑很常见CadQuery 依赖的 OCP 库需要编译。2.2 智能体工具的配置要点智能体工具Codex 类、OpenClaw 类的配置核心是两件事模型接入和工具权限。模型接入方面你需要一个能稳定调用的大模型接口。配置时注意把 API 地址、密钥、模型名写对。有些工具支持接入本地模型比如通过 Ollama 部署的模型好处是数据不出本地适合对数据敏感的团队坏处是本地模型在代码生成质量上通常不如云端大模型复杂脚本容易出错。我的建议是原型阶段用云端模型快速验证生产环境再评估本地化方案。工具权限方面智能体要能执行命令、读写文件这涉及安全边界。配置时把工作目录限制在项目文件夹内别给它整个磁盘的权限。OpenClaw 这类框架一般有配置文件指定允许的操作范围务必设好。{ workspace: ./cad_workspace, allowed_commands: [python, pip], max_file_size_mb: 50 }上面是一个权限配置的示意实际字段名以你用的工具文档为准。核心思路是最小权限原则只开必要的口子。2.3 验证链路是否打通的最小测试环境装完别急着上复杂模型先用一个最小例子验证链路。让智能体生成一个最简单的立方体脚本import cadquery as cq result cq.Workplane(XY).box(20, 20, 20) cq.exporters.export(result, test_cube.step)执行后如果目录里出现了test_cube.step说明生成脚本→执行→导出模型这条链路是通的。这一步能帮你快速定位问题如果脚本生成了但文件没出来是执行环节的问题如果脚本都没生成是模型接入的问题。分而治之排查效率高很多。提示第一次跑通后立刻用 CAD 软件打开导出的 STEP 文件确认几何正确。有些时候脚本没报错但生成的几何是空的或者尺寸不对光看文件存在是不够的。3. 从一句话到可编辑模型完整生成流程3.1 怎么描述需求才能让 AI 少犯错自然语言描述的质量直接决定生成结果的质量。我总结了一个四要素描述法基准、尺寸、特征、约束。基准是模型的参考坐标系和起始面比如以 XY 平面为底面。尺寸是所有关键数值尽量给全别让 AI 猜。特征是孔、槽、倒角、圆角这些具体操作。约束是位置关系比如孔中心距边缘 10 毫米两孔同心。对比一下两种描述差的描述做一个带孔的板子。——AI 只能瞎猜尺寸和孔位。好的描述以 XY 平面为底面做一个 100x80x8 的长方体底板。四个角各有一个直径 6 的通孔孔中心距相邻两边均为 12 毫米。所有外边缘倒 R2 圆角。后者生成出来的脚本基本一次就能用。描述里每个数字都要有明确归属这是减少返工的关键。3.2 生成脚本的结构拆解AI 生成的 CadQuery 脚本结构通常是这样几段导入库、定义参数、构建几何、导出文件。看一个实际生成的例子import cadquery as cq # 参数区 length 100.0 width 80.0 thickness 8.0 hole_dia 6.0 hole_offset 12.0 fillet_r 2.0 # 构建几何 result ( cq.Workplane(XY) .box(length, width, thickness) .faces(Z) .workplane() .rect(length - 2*hole_offset, width - 2*hole_offset, forConstructionTrue) .vertices() .hole(hole_dia) .edges(|Z) .fillet(fillet_r) ) cq.exporters.export(result, base_plate.step)这段脚本值得逐段理解。参数区把所有尺寸抽成变量这是后续改型的基础。构建几何用的是链式调用box建主体faces(Z)选中顶面作为工作平面rect画一个辅助矩形vertices()取矩形四个角点hole在这些点上打孔。最后edges(|Z)选中所有平行于 Z 轴的边倒圆角。为什么要用辅助矩形取孔位而不是直接算四个角的坐标因为辅助矩形的方式更直观改尺寸时只需要改hole_offset一个参数四个孔自动跟着走。这是参数化建模的典型思路用几何关系代替硬编码坐标。3.3 执行、校验与自动修正脚本生成后OpenClaw 这类智能体负责执行。执行时要注意捕获两类错误语法错误和几何错误。语法错误好办Python 解释器会直接报行号。几何错误更隐蔽比如布尔运算失败、圆角半径过大导致自相交这些往往在执行时才暴露。一个实用的做法是让智能体在脚本里加校验逻辑import cadquery as cq result cq.Workplane(XY).box(100, 80, 8) # ... 建模操作 ... # 校验检查体积是否合理 volume result.val().Volume() expected 100 * 80 * 8 if volume 0 or volume expected: raise ValueError(f几何异常体积为 {volume}) cq.exporters.export(result, base_plate.step)体积校验是个简单有效的兜底。如果生成的几何是空的体积会是 0 或者异常值直接抛错智能体捕获后可以把错误信息回传给模型让它重新生成。这就是自我修正闭环的雏形。注意自动修正不要无限循环。设一个最大重试次数比如 3 次超过就人工介入。我见过智能体陷入生成→报错→重生成→同样报错的死循环白白烧 token。4. 参数化改造让生成的模型真正能用4.1 为什么要把硬编码改成参数AI 第一次生成的脚本经常有硬编码的数值散落在各处。比如孔位直接写成(38, 28)这样的坐标而不是用变量表达。这种脚本能跑但改起来痛苦——你想把板子加宽 20 毫米得手动重算所有坐标。参数化改造的目标是把所有会变的量抽成变量并且让变量之间有正确的依赖关系。比如孔位应该由板宽和边距推导出来而不是写死。改造后的脚本改一个width孔位自动跟着调整。这个改造过程可以让智能体来做。给它指令把脚本里所有硬编码的尺寸抽成参数孔位用板尺寸和边距表达不要写死坐标。模型通常能理解并重构。4.2 参数依赖关系的设计参数化不是简单地把数字换成变量关键是依赖关系要合理。看一个反面例子length 100 width 80 hole_x 38 # 硬编码和 length 没关联 hole_y 28 # 硬编码和 width 没关联这样改length时hole_x不会变孔位就偏了。正确做法是length 100 width 80 hole_offset 12 hole_x length/2 - hole_offset hole_y width/2 - hole_offset现在hole_x由length和hole_offset推导改板长孔位自动跟随。判断参数化是否合格的标准是改任何一个基础尺寸模型是否仍然几何合理。如果改完出现孔跑到板外、圆角自相交说明依赖关系没设计好。4.3 批量生成变体的实操参数化到位后批量生成变体就是水到渠成的事。比如你要生成一系列不同长度的底板写个循环import cadquery as cq def make_plate(length, width80, thickness8, hole_offset12, hole_dia6): return ( cq.Workplane(XY) .box(length, width, thickness) .faces(Z).workplane() .rect(length - 2*hole_offset, width - 2*hole_offset, forConstructionTrue) .vertices().hole(hole_dia) .edges(|Z).fillet(2) ) for L in [80, 100, 120, 140]: plate make_plate(L) cq.exporters.export(plate, fplate_{L}.step)这段代码一次生成四个不同长度的底板。把建模逻辑封装成函数是批量生成的关键。函数参数就是设计变量调用时传不同值即可。这种模式在需要做设计探索、参数扫描时特别有用——你可以快速生成几十个变体导入仿真软件批量分析。5. 踩坑排查那些文档里不会写的问题5.1 环境层面的典型故障环境问题占了实际踩坑的一大半。几个高频故障Python 解释器找不到。智能体执行脚本时报python 不是内部或外部命令多半是 PATH 没配好或者智能体用的是另一个 Python 环境。解决办法是显式指定解释器全路径别依赖 PATH。依赖库版本冲突。CadQuery 依赖的 OCP 库对版本敏感和某些科学计算库可能冲突。建议用虚拟环境隔离python -m venv cad_env # Windows cad_env\Scripts\activate # Linux/Mac source cad_env/bin/activate pip install cadquery虚拟环境能避免 90% 的版本冲突问题。每个项目一个环境别图省事全局装。权限问题。智能体读写文件被拒检查工作目录权限以及配置文件里的路径是不是写对了。Windows 上还要注意路径分隔符反斜杠在 JSON 里要转义。5.2 模型生成层面的常见错误几何层面的错误更考验排查能力。几个典型场景布尔运算失败。两个实体做差集时如果面重合或者有微小间隙运算可能失败。解决办法是给操作加容差或者调整几何让它们明确相交。圆角失败。圆角半径大于相邻边长度时会自相交。比如 8 毫米厚的板子倒 R5 圆角如果某条边只有 6 毫米长就倒了。要么减小圆角半径要么先改几何。导出文件为空。脚本没报错但 STEP 文件是空的通常是建模链最后返回了空对象。检查链式调用的每一步确认result变量确实持有几何。加个体积校验就能提前发现。排查这类问题的通用思路是把复杂模型拆成简单步骤逐步执行每步都校验。别一次性跑完整个脚本那样报错信息会淹没在中间过程里。5.3 智能体行为异常的应对智能体有时候会跑偏。比如反复生成同样的错误脚本或者执行了不该执行的命令。应对策略一是限制重试次数前面提过防止死循环。二是明确工作边界配置文件里限定它能操作的目录和命令。三是保留执行日志出问题时能回溯它到底干了什么。还有个小技巧给智能体的指令里加上如果连续两次生成失败停下来输出你的分析不要继续尝试。这能强制它从盲目重试切换到分析问题往往更有效。6. 把 Text to CAD 接进实际工作流6.1 和现有 CAD 软件的衔接生成的 STEP 文件是通用格式主流三维 CAD 软件都能导入。导入后你可以继续做细节修改、出工程图、做装配。这里的关键认知是Text to CAD 生成的是初版模型不是最终交付物。它帮你跳过从零建模的重复劳动但工程校验、公差标注、工艺性检查这些还是得人来。实际用法上我建议把 AI 生成的模型当作设计草稿。拿到后先检查几何是否符合意图再在此基础上细化。这样既享受了 AI 的速度又保证了工程严谨性。6.2 版本管理与团队协作脚本是纯文本天然适合 Git 管理。每次生成或修改都提交能清楚看到模型是怎么演变的。团队协作时脚本可以 review可以提 PR比二进制模型文件友好太多。建议的目录结构project/ scripts/ # 建模脚本 base_plate.py bracket.py models/ # 导出的模型文件 base_plate.step params/ # 参数配置 config.json README.md脚本和模型分开存参数单独抽出来。这样改参数不用动脚本改脚本不影响已有模型职责清晰。6.3 什么场景适合用什么场景别硬上Text to CAD 不是万能的。适合的场景标准化零件、参数化系列件、快速原型、设计探索。这些场景几何规则明确描述起来清晰。不适合的场景复杂自由曲面、高度依赖工程经验的细节设计、需要大量人工判断的场合。比如汽车外形设计曲面美学和空气动力学耦合自然语言描述根本表达不清楚还是得靠专业工具和设计师。判断标准很简单如果你能用一段话把几何讲清楚就适合如果讲不清楚说明这个任务本身就不适合自然语言驱动。7. 关于工具选型和长期演进的一些个人判断工具这块我的建议是别追新追稳。Codex 类工具更新很快但核心能力是代码生成选一个接口稳定、文档齐全的就行。OpenClaw 类智能体框架重点看它的工具调用能力和错误处理机制这决定了链路能不能稳定跑。模型选择上代码生成质量是硬指标。同一个描述不同模型生成的脚本质量差距可能很大。建议拿几个典型零件做基准测试选生成质量最好的那个。别只看价格返工成本比 token 成本高得多。从长期看Text to CAD 这条路线会越来越成熟但短期内它更像是高级助手而不是替代方案。真正用好它的人是那些既懂 CAD 建模原理、又懂怎么和 AI 协作的人。纯靠 AI 生成、自己不懂几何的出了问题根本不知道怎么修。我在实际项目里的体会是把 AI 当成一个手很快但经验不足的初级工程师。它能快速产出初稿但你需要有能力判断对错、指出问题、引导它修正。你的 CAD 功底越扎实用 AI 的效率提升越明显。反过来功底不扎实的话AI 生成的东西你连对错都判断不了反而容易埋雷。最后分享一个实用习惯每次让 AI 生成脚本后别急着执行先自己扫一眼参数区和几何构建逻辑。很多时候问题在生成阶段就能看出来省得执行报错再回头查。这个习惯能帮你省下大量排查时间。