AI 3D建模工具： Tripo 3D | Meshy AI
问一个 text-to-CAD 工具要个垫圈，你会得到一个长得像垫圈的东西：内孔往往没跟外缘约束成同心，尺寸也没有一个是参数驱动的。第一次有人改螺栓规格，模型就散架。
这不是"再训练一代模型"能解决的问题，而是交付物选错了：工程师要的是能改、能版本化、能发布、能送去制造的东西，而一次性的几何恰恰都不是。PTC Onshape 和 SimScale 给出的答案很干脆——别让 AI 画模型，让 AI 写造模型的工具。
本文完整编译 SimScale 博客，2026-10-30（更新 11-02），Peter Selmeczy《Text to CAD: Have AI Write Your CAD Tools》。原文基于 SimScale 的 Agentic Unlocks 线上活动，立场是两家厂商的联合演示，我们未参与、也未复现，边界写在文末。
一、三条路线，只有两条能交给制造工程师
原文把 text-to-CAD 拆成三类，这个分法比任何工具横评都有用：
| 路线 | 模型输出什么 | 快不快 | 能不能改 |
|---|---|---|---|
| 直接生成几何 | mesh 或实体（STL、OBJ，有时 STEP） | 最快 | 没有特征历史，改不了 |
| 生成代码 | 一段脚本（CadQuery、OpenSCAD 或 CAD 系统自己的语言），由脚本建出几何 | 慢一点 | 改一个变量，零件就更新 |
| 调 API 建模 | AI 一步步驱动 CAD 系统的 API，建原生特征 | 中等 | 能改，但一个坏引用会拖垮下游 |
只有第二、第三条路产出的是"制造工程师还能接着干"的东西。原文的判断也是这个意思：有用的版本正在往那边走。
二、为什么它还没进制造：两个例子说清了根因
PTC Onshape 的 Darren Henry 在活动上把话说得很直接：text-to-CAD 一直在进步，但还没准备好用于制造。他给了两个样本：
- 垫圈：生成出来的几何"看着对"，但缺了设计师会手工设的同心约束和草图参数。
- 办公椅：拿去当游戏资产没问题，做生产图纸毫无用处——因为里面没有任何东西承载设计意图。
根因是空间推理：LLM 擅长查资料、非常擅长写代码，但对草图、约束、特征之间如何相互依赖，仍然吃力。
外部证据也指向同一处：Xometry 测了 7 个 text-to-CAD 工具，结论是简单零件能处理，24 齿的齿轮和歧管块就开始吃力，而且工具之间的"可编辑性"差异非常大。
于是真正的工程问题变成了：怎么拿到 AI 的速度，同时不失去对模型的控制权。
三、Onshape 用来判断任何 AI-CAD 流程的三条规则
Dan Kaine（Onshape 合作与市场发展总监）列了三条，我建议直接抄进自己的选型表：
- 人留在环里。 工程师必须能核实 AI 生成的东西，并做有意义的修改。
- 结果确定。 同一个提示词应当给出同一个结果、且保留工程意图。原文那句原话很值得记："一个飘在虚空里、不可编辑、每次跑同一个提示词都不一样的 STEP 文件，对真实工程流程没什么价值。"
- 产出落在工程师干活的地方。 模型要进团队已经在用的 CAD 与 PDM，才能流向图纸、发布和仿真。
AI 写的 FeatureScript 三条全中。
四、FeatureScript MCP：把"稳定引用"变成代码问题
FeatureScript 是 Onshape 自家建模特征背后的语言——草图、拉伸、圆角都是它写的，位置在几何内核与设计环境之间。源码开放，所以你能读到 Onshape 的圆角是怎么实现的，也能写出一个和内置特征一样的东西：参数化、在特征树里可编辑、能在公司内共享。
写 FeatureScript 过去是专家活。PTC 通过 Onshape Labs 在 2026-08-13 发布的 FeatureScript MCP server 改变了这点：它用 MCP 把 Claude、ChatGPT、Gemini 这类会写代码的 LLM 接到 FeatureScript 上，你描述需要什么特征，AI 在 Onshape 里写、调、验。
为什么这次能成？原文的解释切中要害：一个经得起改的参数化模型，依赖对面、边、顶点的稳定引用。光靠提示词很难搞对，但这些引用在代码里是可查询的，而写代码正是 LLM 最擅长的事。Darren 的原话是"AI 很爱这门语言"。
他给的例子（都是现场演示）：
- 从厂商 PDF 目录做出一个法兰衬套工具，约 34 分钟；
- 一个半调网孔（halftone vent）图案和一个叶序（phyllotaxis）图案，都由参数驱动；
- 一个线网货架工具，顺带输出自己的下料清单；
- 一个管壳式换热器工具，接近 600 个零件，约 一天的提示词迭代，对比手工估算的 150 小时。
演示里最终跑出的最优解：15 mm 蜡烛的设计（SimScale 公开项目截图）。
五、经济账：AI 只付一次，工具用一辈子
这是原文里最被低估的一段。Darren 的原话："我用 AI token 生成这个工具，但工具建好之后我就不再用 AI 了，我在用 Onshape。"
意思是：做好的特征运行时不调用 LLM、不产生持续 token 成本，团队用多少次都一样。而每个工具同时固化了你公司"怎么设计这类零件"的做法——它成了一种新的工程 IP，和模型、图纸并列，还能几次点击就在公司内共享。
对比一下"直接生成几何"的账：每次都要重新生成、每次结果都可能不同、每次都要人来判断这次能不能用。
六、再从模型走到"验证过的设计"：SimScale agent
AI 现在能生成的变体数量，已经超过任何团队手工检查的能力——这反而让仿真变得更关键，因为总得有人告诉你哪个变体真的行。
SimScale Engineering AI agent 以 App Store 应用的形式跑在 Onshape 里：你用自然语言问一个设计问题，它自己搭仿真、在 SimScale 云平台上跑、解读结果、报回来，全程不用离开 CAD 窗口。它和在 SimScale 里用的是同一个 agent，聊天记录在两边镜像，中途可以来回切。
两半之间的连接件是 configurations：你在 Onshape 里暴露的参数，就是 agent 的设计空间。把几何参数和仿真参数（材料、热载荷等）合在一起，agent 就能自己扫、自己搜。
七、完整实例：一个 AI 设计的南瓜灯
活动在 10 月 28 日，所以测试用例是季节性的：一个雕好的南瓜灯。但工程问题很严肃——蜡烛多高、用什么蜡，才能让南瓜盖整夜保持在 100 °C 以下、不烧穿？ 物理是共轭传热（CHT）：热从火焰经空气传到南瓜壁。
第 1 步：从提示词生成参数化几何。 Steven Laine（SimScale 解决方案工程总监）让接在 FeatureScript MCP 上的代码生成工具"写一个参数化万圣节南瓜灯 FeatureScript"。结果是一个带配置的完整南瓜：南瓜直径、蜡烛高度、火焰高度，另外还有牙齿数、鼻子大小、嘴巴开度。把蜡烛高度改成 100 mm，几何立刻更新。
Dan 在这里补了一句关键的：你在提示词里点出了"感兴趣的参数"，才有下一步可扫的空间。
第 2 步：让 agent 做参数化研究。 从 Onshape 里的 SimScale 面板，让他建项目并扫三个维度：蜡烛高度、蜡的种类（石蜡、蜂蜡、大豆蜡，火焰功率随蜡调整）、火焰高度。还要求它用自己的材料库、最小化盖子温度、用他在 SimScale 里存好的视角出一份 PDF 报告。
第 3 步：agent 补齐空缺，并先要预算。 他没给每种蜡的热功率，agent 自己估了代表性火焰功率。在跑任何东西之前，它先请他确认 16 次仿真的预算——这一下把算力控制权留在了人手里。
第 4 步：分批 + 贝叶斯搜索。 先跑 8 个设计摸清设计空间（蜡烛高度 15–100 mm），读结果，再决定下一批。总共 16 个设计、3 轮贝叶斯优化，全部作为可追溯的研究留在 SimScale 项目里。
第 5 步：读报告。 最短的蜡烛配最凉的蜡赢了（Steven 自己承认这个结果猜也能猜到）。真正有价值的是过程：agent 自己走到答案，并记录了怎么走的——目标、设计空间、假设、盖子温度历史，以及每次运行都套用了保存的视角。他的原话："我早上把任务发下去，中间两个小时忙别的没看，打开的时候最终报告已经好了。"
第 6 步：版本化，然后分支。 回到 Onshape，把配置设成 15 mm 蜡烛，PDF 报告导入文档，存一个以结果命名的版本——这个版本承载的是设计决策的证据。然后开分支单独研究雕花。
追加的问题更有用：整夜不超过 100 °C 的前提下，蜡烛最高能多高？ 第二次研究给了答案：
- 55 mm 的大豆蜡是满足限制的最高方案；
- 这个高度上大豆蜡和蜂蜡都达标，石蜡不达标；
- 整个研究 42 分钟，单次运行 15–35 分钟。
八、我们的整理：谁该负责什么
演示最容易被误读成"agent 会做仿真了"。按原文的细节拆开，责任切分其实很清楚：
| 环节 | 谁做 | 判据 |
|---|---|---|
| 目标（盖子 < 100 °C） | 人 | 物理约束来自需求，不来自模型 |
| 参数暴露（哪些变量可扫） | 人（在提示词里点名） | 原文明确："点出感兴趣的参数"才有空间 |
| 缺失输入的补齐（每种蜡的火焰功率） | agent，但需人复核 | 它给的是"代表性值"，不是标定值 |
| 算力预算 | 人（agent 主动请求确认） | 16 次仿真是人点头的 |
| 网格收敛 / 批量扫描 / 出报告 | agent | 重复劳动，正是该交出去的 |
| 结论是否可信 | 人 | 报告是证据，不是结论 |
一句能被复述的话：这条流水线把"设计意图"留给人，把"重复的判断"交给机器，并且要求每一步都留下可追溯的痕迹。
落地前值得先问五个问题，都是这次演示暴露出来的：
- 工具建好之后真的零 token 吗？ 是——但要确认它在你团队的版本里能共享、能进 PDM。
- 参数化几何从哪来？ FeatureScript 只是其中一种；agent 读的是 Onshape configurations，任何做好配置的模型都能扫。原文明确：变量表（variable tables）目前还不被 agent 支持。
- 能不能反过来从 SimScale 起步？ 能：在 SimScale 里打开 agent，给它 Onshape 文档，它会把 CAD 拉进来、改参数、跑研究。
- 只有热学吗？ 不是，FEA、CFD、热学、电磁都走同一套。
- 再往前一步是什么？ 原文列了三件：无头流程（两边都有完整 API，多 agent 并行跑研究 + 面板监控）、Physics AI（用历史仿真数据训代理模型，小时级变分钟级）、以及把同一套接到其他物理场。
九、给 CAD/BIM 团队的三条读法
- 把它当"工具工厂"，不是"建模助手"。 真正可复用的资产是那个参数化特征（法兰衬套、换热器），而不是某一次生成出来的 STEP。
- 可编辑性要用代码保证，不能用提示词祈祷。 稳定引用是代码里可查询的对象——这是整篇文章最硬的技术判断。
- 验证要跟着模型走。 把 PDF 报告导进 CAD 文档、存成版本，这个动作比"agent 会跑仿真"重要：它让"为什么这么设计"变成了版本库里的一等公民。
做完设计想快速核对交付物——STEP/IGES 的实体是否完整、单位对不对，用在线 CAD 查看器打开；如果拿到的是网格（STL/OBJ/GLB/PLY），用在线 3D 查看器更快看出破面。
边界
- 这是一篇厂商博客：作者是 SimScale 的高级工程营销，内容基于 SimScale 与 PTC Onshape 的联合线上活动，所有案例（垫圈、办公椅、换热器、南瓜灯）均由厂商在自己的产品里演示。我们未复现任何一项，原文也没有给出第三个独立团队的验证。
- 唯一独立数据点是 Xometry 对 7 个 text-to-CAD 工具的测试（原文转述，我们未核原始报告全文）——结论是简单件可用、齿轮与歧管块吃力、可编辑性差异大。
- 时间是关键变量：FeatureScript MCP 发布于 2026-08-13，agent 能力与配额会变，具体许可、价格、API 配额请以 Onshape / SimScale 官网为准。
- 文中"150 小时 → 一天"是 Darren 的估算，不是计时实验；"34 分钟"、"42 分钟"、"16 次仿真"是演示现场的数字，含演示环境加成。
- 我们没有验证南瓜灯公开项目里的每一次运行，图与数据均引自源文。
Sources
- 主源文：Peter Selmeczy《Text to CAD: Have AI Write Your CAD Tools》，SimScale Blog，2026-10-30（2026-11-02 更新）https://www.simscale.com/blog/text-to-cad/
- 相关产品页：Onshape FeatureScript MCP server（Onshape Labs，2026-08-13）、SimScale Engineering AI agent（Onshape App Store）
- 独立对照：Xometry 对 7 个 text-to-CAD 工具的测试（原文转述）
- 公开项目：SimScale「Pumpkin - Halloween study」共轭传热研究
同主题阅读
本文属于「CAD / 制造 / G-Code」专题。BimAnt 编译整理，转载请注明出处。文中流程与数据均来自厂商演示，我们未复现，立场已在文内披露。
