使用AI构建自定义DraftSight插件：无需从代码开始

如果编写代码不再是第一道门槛，你会为DraftSight构建什么？也许你的团队需要反复执行图纸检查，或者有一个涉及数百个文件的重复性流程，又或者你希望有一个工具能处理你们公司独有的工作流。也许有一些信息被困在另一个系统里，你更想直接把它们带入CAD工作流。

多年来，API（应用程序编程接口）一直在帮助解决这类问题。挑战在于如何从一个想法走到可用的软件。你需要理解API、编写和编译代码、排查错误，然后才能得到一个能工作的东西。如果没有编程经验或找不到开发者，一个有用的想法可能就止步于此。AI正在开始改变这一环节。

在按需网络研讨会《使用AI构建自定义DraftSight插件》中，DraftSight技术销售经理Brian Vanasse探讨了这样一个场景：一个懂DraftSight、知道自己想改进什么工作流的人，如何利用AI来辅助完成软件开发过程。Brian不是专业的软件开发者，他懂DraftSight，懂二维CAD，最重要的是，他知道自己想让软件做什么。他的专业知识始终是网络研讨会中每个示例的核心。

API是入口

要理解AI在其中扮演什么角色，先得了解是什么让这些自定义成为可能：DraftSight API。应用程序编程接口（API）提供了一种结构化的方式，让软件与其他软件进行交互。在DraftSight中，API提供了开发者可以用来自动化任务、创建自定义功能、以及将DraftSight连接到其他应用程序和业务系统的能力。

想象一个重复性的CAD任务。也许数百张图纸需要被打开、检查、修改、打印或导出。如果这个工作流遵循可预测的规则，而API又提供了所需的功能，那么一个应用程序就可以自动执行这些操作，而不需要有人手动处理每一张图纸。

自定义化开启了另一组可能性。一家公司可能有特定的图层标准、必需的图块、标题栏规范，或者发布前必须完成的图纸检查。使用DraftSight API，开发者可以围绕这些工作流构建插件，并将它们集成到DraftSight的用户体验中。

同样的原则也适用于集成。图号、版本、材料、属性、零件号和项目信息可能需要在CAD和其他系统之间流转。API提供了一种让软件交换这些信息的机制，而不是完全依赖手动传递。

这些都不是因为AI出现才有的新东西。DraftSight API已经提供了底层能力。正在改变的是人们使用这些能力的方式。

AI可以弥合想法与API之间的差距

传统的API开发要求开发者将需求转化为一系列技术决策：使用哪些API对象和方法、它们期望什么参数、如何组织代码。在网络研讨会中，Brian使用Claude Co-work来辅助这个过程。他不是从代码开始，而是从一个问题或想法开始。AI帮助他查阅DraftSight API文档、生成代码，并在他构建可用插件的过程中排查错误。

AI并没有移除开发中的人的部分。Brian定义他想完成什么，决定用户体验应该是什么样的，在DraftSight中测试AI生成的东西。当某个东西失败时，他报告发生了什么，然后继续迭代。这个过程不是一条提示词 followed by 一个完美的应用程序，而是一个围绕领域知识、测试、反馈和 refinement 建立的协作过程。

网络研讨会通过几个截然不同的DraftSight插件展示了这个过程的样子。

将AI助手引入DraftSight

Brian的第一个想法听起来很简单：与其不断在DraftSight和浏览器之间切换来使用AI助手，为什么不把AI体验直接放在图纸旁边呢？结果是一个带有可停靠AI聊天面板的自定义DraftSight插件。这个面板让用户在继续使用DraftSight工作的同时，可以访问不同的AI提供商。在演示中，Brian询问关于DraftSight工作流的问题，并使用AI进行设计指导，所有这些都在CAD环境内完成。

这个例子有一个重要的边界。AI助手不会通过这个插件直接读取或修改图纸。它是作为正在工作的人的一个资源存在的。在思考AI在设计中的角色时，这个边界很有用。AI不会取代设计师的判断，也不会接管设计过程。它可以通过让信息、指导和故障排除帮助更容易获得来增强正在工作的人，而这个人仍然对图纸和背后的决策负责。

完成的面板很有趣，但它背后的开发故事可以说更重要。Brian不知道如何架构这个插件、编写其C++和C#组件、构建浏览器集成、正确注册应用程序，或者打包安装。通过与Claude Co-work合作，他经历了架构、编码和测试，然后才部署。当早期版本产生错误时，他把它发回给Claude。当插件没有出现在DraftSight中时，他报告结果并继续排查。最终，插件成功加载，并通过简化的安装过程打包。

更大胆的实验

第一个架构跑通之后，Brian开始测试他还能构建什么。一个实验解决了文件互操作性问题：通过自定义插件将Rhino 3DM文件中的几何图形带入DraftSight。这个例子也展示了为什么理解API的局限性很重要。最终的工具并不是一个完美的3DM导入器。在开发过程中，Claude检查了DraftSight API能支持什么。当团队探索实体和曲面的原生导入时，可用的API没有提供创建所需BREP几何图形所需的路径。最终的插件在DraftSight内创建了受支持几何图形的可用表示，你可以查看、引用、浏览并将其纳入图纸工作流。

这是一个在将AI用于技术工作时变得重要的例子：目标不仅仅是生成一个答案。结果仍然需要对照底层软件和API能做什么来检查。

重新思考现有的G代码工作流

并非每个AI辅助开发项目都需要从零开始。在另一个例子中，Brian拿了一个现有的DraftSight G代码生成器插件，请Claude帮助重新设计它。目标部分是视觉上的，但远不止改变界面。工作流被重新组织为更清晰的导出、导入和配置文件部分。项目还添加了多个G代码配置文件、DraftSight内的彩色刀具路径可视化，以及将现有G代码导入图纸进行可视化和故障排除的能力。

在演示中，你可以选择DraftSight几何图形并将其转换为加工操作，然后生成G代码。反过来，用户可以导入现有G代码并将其重建为DraftSight几何图形，提供代码所描述内容的可视化表示。这个例子也包含未完成的工作。刀具路径可视化还没有完全按照Brian想要的方式显示。AI辅助开发仍然涉及迭代。测试它，找出问题所在，描述问题，然后修改。再测试一次。

小想法也能解决真问题

最后一个例子从文件转换和制造工作流转向了更熟悉的东西：学习如何使用CAD命令。Brian创建了一个Command Advisor（命令顾问），当选择支持的功能区命令时，它会在可停靠的DraftSight面板中显示信息。面板在用户启动命令并返回图纸之前，提供命令语法、可用的选项键和实用提示。该库涵盖了九个功能区选项卡中的大约80个命令。

与转换3DM几何图形或生成G代码相比，这是一个简单的想法，但这正是它有用的原因。自定义开发并不总是必须解决一个大的工程问题。有时它只是可以消除日常任务中的摩擦。

从问题开始，而不是从代码开始

在所有四个例子中，起点都是对工作的理解。你今天在重复做什么？哪里有人在手动传递本可以自动移动的信息？这些是CAD用户、设计师、工程师或组织可能比AI系统更有能力回答的问题。

AI还可以辅助过程的另一部分：查阅API文档、生成代码和诊断错误。DraftSight API提供了与应用程序交互的机制。人提供问题、上下文、测试、判断和对有用结果的定义。网络研讨会通过演示将这些部分结合在一起，包括需要排查故障的部分和API施加限制的地方。

如果你曾经看着一个重复性的DraftSight工作流想过，"应该有更好的方法来做这件事"，那么这个按需课程值得一看。这些例子提供了一个实用的视角，展示了想法如何从CAD用户的经验转化为自定义的DraftSight功能，借助AI的帮助。

观看按需网络研讨会《使用AI构建自定义DraftSight插件》，看看这些插件的实际效果，并跟随它们背后的开发过程。免费试用DraftSight 30天。

来源：SOLIDWORKS官方博客，作者：SOLIDWORKS团队，发布日期：2026年10月6日