这几天顺手查了一下，现在有没有比较流行、实际能用的项目，可以让 AutoCAD 或 Revit 接入大模型，做自动化设计、建模或软件操作。

结论比较平实：方向已经很明确，但离“随便说一句话就稳定完成复杂建模和出图”还有距离。

目前真正能落地的，大多不是让大模型自由控制 CAD，而是给它一组受限工具：画线、建图层、查对象、执行命令、跑 Revit API、导出数据等。可靠性主要来自这些工具边界，而不是模型本身已经完全理解 DWG 或 RVT。

一、AutoCAD：开源项目以 MCP 和本地插件为主

AutoCAD 这边，开源项目的主线比较清楚：Claude、Cursor、Cline 这类客户端通过 MCP 调用本地服务，本地服务再通过 AutoLISP、COM、pywin32、.NET 插件等方式操作 AutoCAD。

1. puran-water/autocad-mcp

这是这轮检索里 AutoCAD 方向信号比较强的开源项目，GitHub stars 约 219。它的特点是支持 MCP stdio，本地 Python 服务可以通过 AutoLISP / Win32 文件通信方式驱动 AutoCAD，也提供 ezdxf 的 headless DXF 后端。

它更像一个“把 AutoCAD 能力包装成大模型可调用工具”的项目。适合做绘图原语、图层、块、文字等受限操作。限制也很明确：真实 AutoCAD 操作仍依赖 Windows、本地 Python 和已安装的 AutoCAD；AutoCAD LT 需要 2024 以后才支持 AutoLISP。

2. Easy-MCP-AutoCad

这个项目 stars 约 152，是比较早被传播的 AutoCAD MCP demo。它使用 Python COM 连接 AutoCAD，并通过 MCP 暴露给 Claude 等客户端。项目有演示视频，能说明“聊天窗口调用 AutoCAD”这件事确实能跑通。

但 README 也明确说明目前不活跃维护，所以它更适合作为早期样例，而不是生产环境的首选。

3. multiCAD-mcp

multiCAD-mcp stars 约 28，热度不算高，但工程化看起来比较认真。它的目标不是只接 AutoCAD，而是通过 COM 支持 AutoCAD、ZWCAD、中望、浩辰、BricsCAD 等多个 CAD 软件。文档里提到统一工具、CAD commands 和测试用例。

这类项目的意义在于：如果以后大模型接 CAD 变成常态，真正有价值的可能不是某一个命令，而是能不能把不同 CAD 的操作抽象成一套稳定工具层。

4. .NET 插件路线

还有一些项目走 AutoCAD .NET 插件路线，例如 crambon/AutoCadMcp 和 Autodesk ADN DevTech 的 adn-mcp-autocad。前者展示了通过 .NET 项目启动 MCP 服务的方式，后者更像 Autodesk 技术样例，重点放在 XData、扩展字典、XRecords 等图元元数据操作。

AutoCadMcp 项目中的 MCP 启动配置截图，主要说明 .NET 插件路线的接入方式。

二、Revit：MCP + Revit API 是最清晰的开源路线

Revit 这边，最值得关注的是 mcp-servers-for-revit 这一组项目。它的基本思路是：MCP 客户端发出请求，本地 MCP server 接收，再通过 Revit 插件或 pyRevit Routes 调用 Revit API。

1. mcp-servers-for-revit

原始的 mcp-servers-for-revit/revit-mcp 项目 stars 约 401，是这类项目里热度最高的一批。现在项目方推荐使用新的 mono-repo：mcp-servers-for-revit/mcp-servers-for-revit，stars 约 128，支持 Revit 2020–2026，有 Release ZIP 和 npm MCP server。

这个方向的价值在于，它不是只做一个聊天窗口，而是试图把 Revit API 能力包装成 MCP 工具，让 Claude、Cline 等客户端调用。它可以用于读取模型信息、执行命令、尝试生成和运行 C# 代码等。

Revit MCP 项目 README 中的 Claude 端连接示意图。它更多说明工具入口，不代表复杂建模能力已经完全成熟。

2.Python / pyRevit 路线

另一个方向是 Python 和 pyRevit。mcp-server-for-revit-python stars 约 114，使用 Python FastMCP 和 pyRevit Routes，把 Revit 内部能力暴露给 MCP 客户端。oakplank/RevitMCP 也走类似路线，并提供 Web UI 和 Claude Desktop 接入方式。

这一路线更适合快速原型和二次开发。限制是 pyRevit Routes 本身仍偏开发者工具，鉴权、安全、部署稳定性都需要团队自己处理。

3. Zexus 这类插件内动态执行路线

Zexus 是一个较新的 Revit 插件，支持 Revit 2022–2026。它的思路是让大模型生成 C#，再在 Revit 插件内通过 Roslyn 动态编译执行。这个方向很强，但风险也更高：模型生成代码进入 Revit 进程执行，必须考虑安全、回滚和权限边界。

4.数据管线不是直接操作，但也有实用价值

datadrivenconstruction/cad2data-Revit-IFC-DWG-DGN stars 约 345，热度很高，也有较多演示材料。它更偏“把 Revit、IFC、DWG、DGN 数据导出成表格、HTML、IFC 等，再交给 LLM 或自动化流程分析”，不是实时控制 Revit 建模。

这种路线对工程业务反而很实用：做清单、审查、模型检查、批量报表，比直接让模型修改模型更容易稳定。 

三、商业软件：更多是局部自动化，不是通用聊天建模

商业软件这边，需要把几类东西分开看。

Autodesk 自己的 AI 方向包括 Autodesk AI、AutoCAD 的 Markup Assist、Smart Blocks，以及 Revit 里的 Generative Design、Dynamo 相关优化流程。它们是官方路线，可信度高，但目前公开资料里更偏辅助、推荐、标记识别、生成设计和流程自动化，不宜理解成“通用 LLM 直接控制 Revit / AutoCAD”。

EvolveLAB Veras是比较成熟的 AI 可视化插件，能在 Revit、SketchUp、Rhino 等设计工具语境里用提示词生成效果图。它实际可用，但核心是 AI 渲染，不是修改 BIM 构件。

EvolveLAB Glyph更偏 Revit 出图自动化，可以自动创建视图、图纸、标注、尺寸等。它不一定是 LLM 产品，但对 Revit 用户的日常生产价值很直接。

Forma、Hypar、TestFit、Finch、Snaptrude这类平台，则更偏前期方案、强排、指标分析、云端协同和 BIM 相邻工作流。它们可以和 Revit/BIM 流程连接，但通常不是在 Revit 里直接用聊天命令建模。

四、实际效果怎么判断

如果只看演示视频，容易觉得“CAD 已经可以完全聊天控制”。但实际使用时，要看三个问题：

第一，工具集是否受限。越是把操作拆成明确工具，例如创建墙、查图层、插入块、导出视图、读取元素参数，越容易稳定。

第二，是否有人确认。让模型直接在 Revit 里执行 C# 或 Python 很强，但安全风险也高。比较稳的做法是先生成命令或脚本，再由人确认执行。

第三，是否依赖本地软件环境。多数 AutoCAD/Revit 接入项目仍要求 Windows、本地授权软件、插件安装、API key 和本地端口。它不是纯云端开箱即用。

现在 AutoCAD 和 Revit 接入大模型，已经不是概念阶段。开源 MCP 项目能跑，商业插件也有实际产品，Autodesk 官方也在持续把 AI 放进产品线。

但目前最可靠的用法，仍然是“大模型 + 受限工具 + 人工确认”。它适合做重复操作、批量修改、数据提取、自动出图、效果图生成、简单建模和规则化检查。

至于让它完全理解一个复杂工程模型，然后自由完成专业设计判断和施工图生产，现在还为时尚早。

更现实的变化可能是：以前很多 CAD/BIM 软件的操作门槛，来自菜单、命令、插件、学习资料和经验积累。大模型接入以后，这些门槛会被重新分配。软件还是要有强 API、强数据结构和稳定执行环境，但“会不会点按钮”这件事本身，重要性会下降。

主要参考：puran-water/autocad-mcp、zh19980811/Easy-MCP-AutoCad、AnCode666/multiCAD-mcp、crambon/AutoCadMcp、ADN-DevTech/adn-mcp-autocad、mcp-servers-for-revit 系列项目、mcp-server-for-revit-python、oakplank/RevitMCP、datadrivenconstruction/cad2data-Revit-IFC-DWG-DGN、Autodesk AI / Forma / Revit Generative Design、EvolveLAB Veras / Glyph、Hypar、TestFit、Finch、Snaptrude。