摘要：Adam-CAD 开源项目 CADAM、Onshape 与 Claude Opus 的联动案例，以及近期兴起的 text-to-CAD 工作流，正在揭示一个非常明确的趋势，大模型对工业软件的改造重点，不只是自动生成几何体，而是直接绕开传统 CAD 那套层层菜单、命令树和参数面板，把复杂界面压缩成可对话、可验证、可回溯的设计意图层。
工业软件这几年一直有一个很奇怪的现象。
一方面，大家都承认 CAD、CAE、PLM、MES 这些系统是制造业数字化的核心基础设施。另一方面，真正天天用这些软件的人，也都知道它们有多“反人类”，复杂菜单、层级面板、命令树、历史特征、草图约束、装配配合、导出格式、插件兼容，每一个环节都像是为了训练工程师忍耐力而设计的。
所以，当我看到 Adam-CAD 的开源项目 CADAM，看到最近那个 Claude Opus 与 Onshape 联动生成 CAD 模型 的视频，再结合一位开发者公开分享的 用 Codex 直接生成和修改 3D 模型工作流，第一反应不是“又一个 text-to-CAD demo”，而是：工业软件真正要被颠覆的，可能不是底层几何内核，而是它最外面那层几十年没变过的交互壳。
这件事非常值得认真研究，因为它触碰到的是工业软件最核心、也最容易被低估的一条线，大模型正在把“会不会点界面”这件事，从工程能力里剥离出去。
一、先看 CADAM，它本质上不是一个“画图网站”，而是一个意图翻译器
从 CADAM 的公开说明来看，它是一个开源的 text-to-CAD web application。其核心能力包括：自然语言和图像输入生成 3D 模型、参数化控制、实时预览、导出 STL 与 SCAD，以及基于浏览器运行的 OpenSCAD WebAssembly 流程。技术栈非常清晰：React、TypeScript、Three.js、Supabase、OpenSCAD WebAssembly，加上 Anthropic Claude API。
表面看，它像是典型的“AI 生成 3D”项目。但再往下看一层，你会发现它和很多花哨但不实用的 AI 建模 demo 不一样。
它并不是直接输出一坨不可编辑的网格，而是强调：
- 参数化控制，可以通过滑块调整尺寸
- 导出标准格式，面向后续制造与编辑
- 利用 OpenSCAD / BOSL / BOSL2 / MCAD 生态
- 实时预览与快速迭代
- 图像和自然语言都能作为设计输入
- 参数提取与智能更新，避免每次改一点都整模型重生成
这背后其实说明了一件很关键的事：CADAM 的真正目标，不是让 AI 替代 CAD，而是把“设计意图”先翻译成参数化几何描述。
这非常重要。因为工业设计里最贵的，从来不是“画出一个形状”，而是把模糊需求变成可以反复修改、可验证、可下游流转的结构化模型。
换句话说，CADAM 干的不是“帮你画一个看起来像支架的东西”，而是试图搭一层新接口，让工程师用自然语言先说清楚自己想要什么，再把这个意图落进参数化 CAD 世界里。
二、Onshape + Claude 真正惊人的地方，不是会建模，而是它开始绕开 GUI
最近那个 Onshape 和 Claude 联动的视频，在圈子里传得很快。很多人关注的是结果，比如它可以根据描述生成零件、修改结构、驱动建模流程，看起来像是“AI 在替人操作 CAD”。
但真正值得重视的，不是“AI 会不会点按钮”，而是它已经在证明，复杂工业软件的主交互层未必还需要以 GUI 为中心。
传统 CAD 软件的交互逻辑，本质上是一套历史遗留产物。
在键盘、鼠标和二维屏幕主导的时代，工程师必须通过菜单、命令栏、特征树、属性面板，一步一步把设计意图拆解成软件能理解的离散操作。这个过程不是因为工程师喜欢，而是因为过去没有更好的中间层。
现在大模型来了，情况开始变了。
当 Claude 这类模型可以：
- 理解“给我做一个带四孔安装位的 L 型支架，厚度 4mm，适配 2020 铝型材”
- 自动拆解成约束、特征、尺寸和草图操作
- 知道应该先建草图、再拉伸、再打孔、再做圆角
- 在用户继续补充条件时进行迭代修改
- 通过 API 或插件直接驱动 Onshape 这类云 CAD 平台
那么 GUI 就不再是唯一入口，而变成了一种“可视化 debug 层”。
未来 CAD 的界面可能还会存在，但它的角色会变。它不再是设计动作的唯一入口，而更像一个结果校验、细节微调和工程审查界面。
三、Codex 路线更说明问题，未来可能不是“直接生成 STEP”，而是“生成可编辑的 CAD 源码”
这次用户转来的另一个案例也很有意思。一位开发者分享了自己用 Codex 做 text-to-CAD 的实践，里面有几条经验非常关键。
他不是让模型直接硬生成 STEP 文件，而是采用了这样一套工作流：
- 为每个 STEP 文件生成对应的 Python 脚本源
- 用 build123d 或 cadquery 这类程序化 CAD 框架来表达零件
- 通过引用具体面、边和局部结构，让模型做精确修改
- 维护 markdown 文档，记录零件的重要特征和上下文
- 用截图与几何约束做结果校验
这其实很像软件工程里的一个成熟思想：不要让模型直接改二进制产物，而要让它修改源代码和中间表示。
放到 CAD 里，道理完全一样。
STEP、STL 这种文件更像“编译结果”，它们适合交换和制造，但不适合高频语义编辑。反过来，build123d、cadquery、OpenSCAD 这种程序化 CAD 表达，才更像“源代码层”。
所以我认为，未来真正高效的 AI CAD 路线，很可能不是单一路径，而是三条路线并行：
- 自然语言 → OpenSCAD / 参数化脚本
- 自然语言 → Onshape / 云 CAD API 操作序列
- 自然语言 → Python CAD 源码（build123d / cadquery）
不管用哪条路，核心都一样：把设计意图编译到可编辑的中间层，而不是直接砸向最终几何文件。
四、大模型与工业软件结合，真正的关键不是会聊天，而是“意图到特征”的编译能力
很多人一提“AI + 工业软件”，第一反应还是聊天机器人加个侧边栏，或者在菜单旁边挂一个 Copilot 按钮。这种理解太浅了。
对于工业软件来说，大模型最有价值的能力，不是“陪你聊天”，而是把模糊意图编译成结构化工程动作。
以 CAD 为例，这个链条至少要经过几层：
- 语义理解层，识别用户说的是零件、装配件、夹具、壳体、支架还是工装。
- 工程约束层，提取尺寸、配合关系、材料倾向、打印/加工约束。
- 参数化建模层，把需求映射到草图、拉伸、切除、阵列、倒角、圆角、布尔运算等特征序列。
- 验证反馈层，检查是否自相交、是否违反制造常识、是否存在不可打印、不可装配问题。
- 交互迭代层，允许工程师继续说“孔再往上移 5 毫米”，“厚度改成 6 毫米”，“改成适配 M4 螺丝”，系统做增量更新。
这不是一个简单的 prompt 工程问题，而是一套新的工业软件编译栈。
CADAM 之所以值得看，就在于它已经把这个方向摸得很清楚了。它选的是 OpenSCAD 这种“程序化几何表达”路线，本质上是在告诉我们：自然语言不该直接生成最终模型，而该优先生成一种可计算、可编辑、可约束的中间表示。
Codex + build123d 那套路线，其实是同一个思想的另一种实现。Onshape + Claude 则是在 API 驱动的商业 CAD 平台里做这件事。
五、为什么说它会颠覆复杂界面，而不只是给老软件贴一层 AI 皮肤
工业软件厂商过去几十年形成了一种默认假设：功能越强，界面就越复杂，学习成本就越高，这是没办法的事。
我一直觉得这只是技术时代局限下的妥协，不是什么天经地义的规律。
大模型出现后，我们第一次有机会把这种妥协翻掉。
因为对很多工程任务来说，用户真正关心的从来不是“我要点哪个按钮”，而是：
- 我要一个什么结构
- 它满足什么约束
- 它为什么这样设计
- 改一个参数之后会影响哪里
- 它能不能生产、装配、仿真、打印、报价
过去这些问题必须先穿过复杂界面才能表达。现在，模型有机会把界面反过来压缩，让用户直接表达目标，再由系统决定动作路径。
这就像从命令行进入图形界面，又从图形界面进入意图界面。
所以，未来工业软件最大的变化，可能不是“每个软件里都多一个 AI 按钮”，而是原本作为软件主体的界面，开始退化成一个辅助层。
这非常颠覆。因为一旦交互主入口不再是 GUI，而是意图层，那么工业软件的竞争逻辑都会变：
- 谁的模型更懂工程语言
- 谁的中间表示更稳定
- 谁的 API 更容易驱动外部 agent
- 谁的验证闭环更完整
- 谁能把 CAD、CAE、BOM、工艺、报价串起来
到那时，传统厂商最引以为傲的“复杂功能堆叠”和“深菜单体系”，反而可能变成负资产。
六、这对工业软件意味着什么，远不止 CAD 一个领域
如果这条路跑通，受影响的绝不会只有 CAD。
CAE 里最折磨人的前处理、网格划分、边界条件设置，本质上也是“意图翻译”问题。
CAM 里的刀路策略、加工参数、工序规划，也完全可以被大模型重构。
PLM / PDM 里的数据检索、版本关联、变更解释、BOM 映射，同样适合交给语义层做入口。
MES / SCADA 甚至连组态页面和点位配置，本质上也都是陈旧 GUI 时代留下来的操作负担。
所以我更愿意把 CADAM、Onshape + Claude、Codex + build123d 这些案例看作一个信号，而不是一个单点产品现象。
这个信号是：工业软件可能将第一次迎来“界面去中心化”。
过去十几年，企业软件的 AI 化大多停留在推荐、搜索、报表摘要这些外围能力上。但工业软件不一样，它一旦被模型真正打通，就不是帮你“更快找到菜单”，而是帮你直接跳过菜单。
七、当然，别急着神化，它离真正进入生产环节还有几道硬坎
说到这里，也不能太浪漫。
像 CADAM 和 Onshape Agent 这类方向虽然让人兴奋，但离工业级大规模落地，至少还有几道非常硬的门槛。
1. 几何正确不等于工程正确
模型能生成一个外形合理的零件，不代表它真的满足强度、配合、公差、工艺、材料、散热、成本等现实约束。工业设计不是“长得像”就行。
2. 需要严肃的验证闭环
如果 AI 改了一处尺寸，引起装配干涉、打印失败或加工不可达，系统必须能及时发现并解释。工业软件里的 AI 绝不能停在生成层，必须延伸到验证层。
3. 参数历史和可追溯性非常关键
工程现场不能接受“这个形状是 AI 想出来的，但我不知道它怎么来的”。每一步修改都必须能回溯，最好还能解释对应的设计意图与约束变化。
4. 大模型要学会尊重专业边界
真正的工程师不会只说“帮我建个模型”，还会说“这个孔位必须保留”，“这个面不能动，因为要配合密封件”，“这里必须满足注塑拔模角”。模型必须从“会生成”升级到“懂禁区”。
所以，这条路线最后能不能成，关键不在于 demo 多惊艳，而在于它能不能建立一个从自然语言 → 参数化结构 → 验证闭环 → 工程交付 的完整链条。
八、写在最后，工业软件最先被替代的也许不是核心算法，而是那套交互壳
很多人谈工业软件颠覆，总盯着几何内核、求解器、仿真精度、数据库架构，这当然重要。但从最近 CADAM、Onshape + Claude、Codex 生成 CAD 这些信号来看，我越来越觉得，最先松动的可能是外层交互结构。
也就是那层让工程师花几年时间去适应、记忆、点击、排错、反复训练的复杂壳。
过去，复杂界面被当成专业门槛的一部分。未来，它很可能被证明只是旧时代输入设备和软件设计范式的副产品。
一旦大模型真的把工程意图理解、参数化建模、修改追踪和验证反馈打通，工业软件的主入口就会从“你该点哪里”，变成“你到底想造什么”。
这不是小修小补，而是一次交互范式替换。
如果说上一代工业软件革命的关键词是参数化、特征树和数字线程，那么这一代很可能是：意图驱动、代理执行、界面退居二线。
而一旦这件事发生，最先被颠覆的，不是 CAD 的数学内核，而是那些复杂到令人窒息、却又被我们忍了二三十年的软件界面。
参考资料：
- Adam-CAD / CADAM GitHub 仓库公开说明
- Adam 官网公开页面《Adam for Engineers》与 CADAM 页面
- Onshape 与 Claude 联动相关公开视频和社区讨论
- 开发者公开分享的 Codex / build123d / cadquery text-to-CAD 工作流经验