Я сделал ИИ‑агента для КОМПАС-3D: он живёт прямо в окне программы, принимает запрос текстом или фотографией и строит параметрическую деталь — не мёртвую геометрию в step, а дерево построения с переменными, которое пригодно для редактирования.
Агент пишет код и сам смотрит на то, что построил, — анализирует рендеры «глазами» через VLM.
В статье: как хорошо агент справляется с моделированием по тексту и чертежам уже сейчас, почему один блок кода лучше десяти tool'ов и почему агенту мало просто «видеть» результат.
Введение
За последние несколько лет ИИ‑агенты научились на высоком уровне писать код, собирать отчёты в Word, Excel и других офисных программах — там, где результат работы легко описать текстом и командами. Работа с CAD‑программами, вроде КОМПАС-3D, устроена принципиально иначе. Из инструментов для работы через код есть только COM API, с которым и человеку не всегда легко, что уж говорить про ИИ.
В добавок, пространственное мышление до сих пор остаётся слабым местом VLM/LLM моделей — и это критично для проектирования.
Отдельно стоит отметить статьи ИИ управляет КОМПАС-3D... и Запрещаем AI выдумывать методы КОМПАС-3D...: там рассмотрено подключение через КОМПАС через MCP, а проблему угадывания методов COM API решили дообучением небольшой модели для семантического поиска по документации.
В этой статье покажу свой подход: агент, встроенный прямо в КОМПАС, с глубокой интеграцией в программу — свой Python поверх голого COM API и визуальный фидбек, который замыкает цикл «построил → посмотрел → поправил», компенсируя слабое пространственное мышление модели.
Дальше — демо как это работает, разбор архитектуры, метрики на реальных задачах и выводы по ним.
Как это выглядит в работе
Агент открывается боковой панелью прямо в окне КОМПАСа — не отдельным приложением. Он работает с тем документом, который у вас сейчас открыт: видит дерево построения, переменные и текущее состояние модели. На вход принимает текст и изображения — можно скинуть фотографию эскиза с листа или скан чертежа.
Кейс 1. Зубчатое колесо по текстовому описанию
Всё, что получил агент:
Построй зубчатое колесо: модуль 5, 50 зубьев, ширина венца 60, вал диаметр 50 со шпонкой
В запросе заданы четыре числа, а у детали параметров сильно больше. Всё остальное — ступицу, обод, диск, шпоночный паз — агент достроил сам, по стандартным соотношениям, не переспрашивая. И на выходе получилась не импортированная мёртвая геометрия из STEP, а обычная деталь КОМПАСа с деревом построения, которое можно открыть и править руками.
И главное — агент сам завёл переменные с человеческими именами и комментариями. Чтобы поменять посадочное отверстие с ⌀50 на ⌀80, не нужен ни агент, ни перестроение в эскизах: правится одна ячейка, модель пересобирается успешно.
▶ ссылка видео демонстрация, без монтажа
Кейс 2. Деталь по скану чертежа
Здесь агент получил только картинку с чертежом и просьбу построить по ней деталь — без подсказок по размерам и без описания.
Интереснее самой геометрии две другие вещи, которые показывает этот кейс:
Агент сам проверил себя. Он не остановился на «код выполнился без ошибок», а посмотрел на деталь с разных ракурсов и сверил с чертежом параметры. Это тот самый визуальный контроль, которому дальше посвящён отдельный раздел.
Заполнил не только геометрию. Деталь — это ещё и свойства. Агент прочитал основную надпись, проставил наименование, обозначение и материал, а заодно сам проанализировал расхождение по массе:
Теперь задам свойства детали — материал, обозначение, наименование и плотность картона (по ГОСТ 9347–74 картон А-2,00 имеет плотность около 0.65–0.7 г/см³; текущая масса модели в стали 122 г далека от заявленных 0,01 кг = 10 г для картона — но это ожидаемо, так как плотность стали завышает массу; проставлю реальную плотность картона).
▶ ссылка Видео демонстрация, без монтажа
Как это устроено: свой агент, код вместо кнопок и визуальный контроль
ИИ агент
Внутри ИИ агент, основанный на ReAct цикле, где LLM/VLM модель на каждом шаге принимает решение о вызове инструмента и получает обратную связь
Модель обязательно VLM — она должна принимать изображения на вход. Без этого не работает визуальная обратная связь, а на ней в этой системе держится качество: цифры будут ниже.
В этой системе реализован свой ИИ агент, а не просто обвязка для готовых кодинг агентов типа claude code, codex или opencode.
преимущества такого подхода:
независимость от поставщика моделей, можно использовать и локальные
возможность перекроить сам граф работы агента под конкретный сценарий — а иногда это единственный способ получить рабочую версию. Дальше по замерам будет видно, что восстановление модели по чертежу как раз такой случай: универсальный цикл там не справляется, и нужен отдельный пайплайн
глубокая интеграция с компас 3д, например подстановка состояния дерева прямо в промпт
Как агент общается с КОМПАСом
Есть ряд устоявшихся практик по подключению программ к ИИ агентам, но в случае с КОМПАСом оба варианта оказались проигрышными — я объединил их сильные стороны в одном решении
Первая попытка: свой tool на каждое действие — extrude, hole и так далее, модель выбирает нужный из списка. Проблема простая: каждый вызов — это как нажать одну кнопку в КОМПАСе руками. Ни переменных, ни циклов, ни функций — только атомарные команды одна за другой, и это очень медленно. Моделирование — это работа с объектами, а не просто последовательность команд.
Попытка вторая: пустить модель прямо в COM API. Раз проблема в том, что не хватает кода — дадим модели писать код. КОМПАС имеет COM‑интерфейс, пусть модель его и использует напрямую.
Здесь выяснилось, что COM API писался для программистов, а не для языковых моделей. Одна осмысленная операция разворачивается в десяток служебных шагов (фрагмент‑пример ниже), половина параметров передаётся числовыми константами, которые надо помнить или искать в документации, и на каждом шаге модель имеет шанс перепутать интерфейс.
Вдобавок это просто небезопасно: неудачный вызов роняет не скрипт, а сам КОМПАС вместе с несохранённой работой пользователя.
Код на COM API
import pythoncom import win32com.client from win32com.client import gencache kc3d = gencache.EnsureModule("{2CAF168C-7961-4B90-9DA2-701419BEEFE3}", 0, 1, 0).constants pythoncom.CoInitialize() app = win32com.client.GetActiveObject("Kompas.Application.7") app.Visible = True doc = app.Documents.Add(4, True) # 4 = ksDocumentPart doc3d = win32com.client.CastTo(app.ActiveDocument, "IKompasDocument3D") part = doc3d.TopPart part.Name = "Втулка" part.Update() container = win32com.client.CastTo(part, "IModelContainer") # --- эскиз Ø60 --- sketch1 = win32com.client.CastTo(container.Sketchs.Add(), "ISketch") sketch1.Plane = part.DefaultObject(kc3d.o3d_planeXOY) sketch1.Update() # рисование идёт ВНУТРИ эскиза: пока открыт BeginEdit, активным документом # КОМПАСа считается его фрагмент, а не деталь. EndEdit обязателен fragment1 = sketch1.BeginEdit() view1 = fragment1.ViewsAndLayersManager.Views.View(0) drawing1 = win32com.client.CastTo(view1, "IDrawingContainer") circle1 = win32com.client.CastTo(drawing1.Circles.Add(), "ICircle") circle1.Xc, circle1.Yc = 0.0, 0.0 circle1.Radius = 30.0 circle1.Style = 1 # основная линия; иначе контур не сработает circle1.Update() sketch1.EndEdit() sketch1.Update() # --- выдавить на 80 --- boss = win32com.client.CastTo( container.Extrusions.Add(kc3d.o3d_bossExtrusion), "IExtrusion") boss.Sketch = sketch1 boss.Direction = kc3d.dtNormal boss.SetSideParameters(True, kc3d.etBlind, 80.0, 0.0, False, None) if not boss.Update(): # Update возвращает False молча raise RuntimeError("выдавливание не построилось") # --- эскиз Ø30 --- sketch2 = win32com.client.CastTo(container.Sketchs.Add(), "ISketch") sketch2.Plane = part.DefaultObject(kc3d.o3d_planeXOY) sketch2.Update() fragment2 = sketch2.BeginEdit() view2 = fragment2.ViewsAndLayersManager.Views.View(0) drawing2 = win32com.client.CastTo(view2, "IDrawingContainer") circle2 = win32com.client.CastTo(drawing2.Circles.Add(), "ICircle") circle2.Xc, circle2.Yc = 0.0, 0.0 circle2.Radius = 15.0 circle2.Style = 1 circle2.Update() sketch2.EndEdit() sketch2.Update() # --- вырезать насквозь --- cut = win32com.client.CastTo( container.Extrusions.Add(kc3d.o3d_cutExtrusion), "IExtrusion") cut.Sketch = sketch2 cut.Direction = kc3d.dtBoth # эскиз на торце — режем в обе стороны cut.SetSideParameters(True, kc3d.etThroughAll, 0.0, 0.0, False, None) cut.SetSideParameters(False, kc3d.etThroughAll, 0.0, 0.0, False, None) if not cut.Update(): raise RuntimeError("вырез не построился")
Что заработало: библиотека‑обёртка. Я написал поверх COM API собственный слой, в терминах которого модель пишет код:
from kompas_core import new_part part = new_part("Втулка") part.extrude(part.sketch("xy").circle((0, 0), 30), 80) part.cut(part.sketch("xy").circle((0, 0), 15))
Это сочетание сильных сторон обоих подходов: краткий, безопасный и семантически понятный интерфейс, как у tools, — но при этом обычный Python с переменными, циклами и функциями, как в COM API. part — живой объект со своим состоянием, у которого просто дёргают методы, ничего не нужно протаскивать по идентификаторам. Вся грязная работа с COM и проверка аргументов остаётся внутри библиотеки: кривой вызов возвращает понятную ошибку, а не роняет программу.
И главное у подхода есть понятный путь масштабирования на другие задачи — сборки, чертежи, спецификации добавляются новыми методами библиотеки, без переделки агента.
Визуальная обратная связь
Агент никогда не может быть уверен, что код действительно сделал то, что задумано: эскиз мог построиться не на той плоскости, выдавливание уйти в другую сторону, фаска сесть не на ту грань — и всё это без единой ошибки выполнения.
Но и просто «посмотреть на деталь» здесь мало. Один рендер с дефолтного вида ошибку может не показать — она бывает не видна снаружи или спрятана внутри тела. Поэтому у агента есть инструмент, который рендерит текущее состояние модели и кладёт картинки обратно в контекст, а сам агент выбирает, с каких видов смотреть, и может гасить элементы в дереве построения, чтобы заглянуть внутрь детали или найти операцию, которая пошла не так.
Насколько это важно, видно по статистике прогонов.
Из каждой сотни блоков кода агент идёт смотреть на результат в 65 случаях, и только треть осмотров заканчивается «всё в порядке» — в остальных находит расхождение и правит его.
Итог: примерно 45 блоков из 100 уходят на переделку после того, как агент увидел результат своими глазами.
Первая цифра, 65% — это просто настройка: строкой в промпте или программным вызовом её можно уверенно двигать к 100%.
А вот доля осмотров 31% — это свойство самих моделей с двумя новостями, одной плохой и одной хорошей.
Плохая: LLM и VLM пока плохо держат трёхмерную геометрию в уме по одному коду — модель искренне считает, что построила нужное, и почти в половине случаев ошибается.
Хорошая: увидев рендер модель способна самостоятельно заметить расхождение
Метрики: что агент реально вытягивает, а что нет
Дальше — цифры, и сразу оговорка о том, чем они являются, а чем нет.
Это не бенчмарк и не строгая методика: 90 кейсов, по 10 на ячейку, один прогон на кейс. На такой выборке разница между 0.80 и 0.84 значит не много.
Значимо другое — разрывы. Там, где результат падает с 0.78 до 0.25, никакая статистическая строгость уже не нужна: сигнал видно невооружённым глазом. Ради этих разрывов и проведен замер, чтобы понять ограничения подхода в разных задачах
Задачи. Проверялись три сценария:
создание модели с нуля по текстовому описанию (text2model);
внесение правки в готовую модель по текстовому запросу (text2edit);
восстановление 3D‑модели по скану чертежа в полностью автономном режиме (drawing2model).
Условия. Модель — moonshotai/kimi-k2.7-code, по API через agentplatform.ru. Взял её сознательно: открытая в общем доступе и дешёвая. Оба эти критерия важны при промышленном использовании.
Эталоны. Мои собственные модели студенческого уровня: то, что делается в курсовых и на первой работе. Обычные машиностроительные детали: фланцы, прокладки, зубчатые колеса.
Уровни сложности
Каждая задача разбита на три уровня, логика везде одна:
простая — всё дано напрямую, проверяется, что агент вообще попадает в API;
средняя — появляется вычисление, размер или координату надо вывести, а не списать;
сложная — появляется структура: массивы вместо повторов, работа с деревом построения, связывание нескольких видов в одну форму.
простая |
средняя |
сложная |
|
|---|---|---|---|
text2model |
одно тело, размеры даны прямо, 1–2 операции |
несколько операций, часть координат вычисляется, проточки, фаски, эскиз на грани |
массивы, фаски и скругления по точкам, вращение, больше шести операций |
text2edit |
одна операция, место указано прямо |
несколько элементов или пересчёт координат, правка существующего размера |
надо разобраться в дереве и переделать построенное |
drawing2model |
форма читается с одного взгляда, размеры прямые |
одно изображение с разрезом или контуром, косвенные размеры |
несколько видов, дуги в профиле вращения, невидимые на главном виде элементы |
*Для правок уровень определяется самой правкой, а не исходной деталью: снять фаску на сложном корпусе — простая правка.
Метрики
IoU
Насколько объём построенной агентом детали совпадает с эталоном — от 0 (не пересеклись) до 1 (совпали идеально).
Подробная методика расчета
Обе модели — эталон и результат агента — выгружаются из КОМПАСа в STL и сравниваются вокселями, решётка устойчива к любой сетке.
Шаг решётки — наибольший габарит эталона, делённый на 110, но не мельче 0,05 мм. Внутренность заливается через scipy.ndimage.binary_fill_holes, поэтому сквозное отверстие честно остаётся пустым.
Ориентация детали не задаётся условием, поэтому перебираются 24 осевых поворота, обе детали центруются по габариту, берётся лучший IoU.
Для правок метрика другая: полный IoU бесполезен (если фаска снимает 5 г с детали весом 700 г, ничего не сделавший агент получит 0.99). Поэтому сравниваются не тела, а изменения — симметрическая разность «было → эталон» и «было → результат»:
expected = difference(was, should) # эталонное изменение actual = difference(was, got) # изменение агента common = len(np.intersect1d(expected, actual, assume_unique=True)) union = len(expected) + len(actual) - common
Совмещение по поворотам для правок выключено: система координат одна и та же, а сдвиг центра из‑за изменившегося габарита испортил бы верный результат.
Cost — среднее число вызовов инструментов на один кейс. Метрика простая, но показывает то, чего не видно по качеству: насколько задача трудоёмка и не ходит ли агент кругами.
Потолок — 60 вызовов. Если агент за них не пришёл к результату, кейс засчитывается как IoU = 0. На этом месте у него в документе лежит промежуточное построение, и брать его в зачёт было бы нечестно: результата нет — значит нет.
Результат: качество
Моделирование по тексту работает. 0.99 на простых, 1.00 на средних — то есть на деталях, которые составляют основную массу рутины, агент попадает в эталон практически точно. Проседание начинается только на сложных, 0.84, и это уже задачи с массивами, вращением и деревом больше шести операций.
Правки деградируют быстрее моделирования. 1.00 → 0.80 → 0.62. На простой правке разницы с моделированием нет, но дальше расхождение растёт, и причина у него одна и вполне конкретная: селекторы. Чтобы снять фаску, агенту мало понять, что нужна фаска, — надо выбрать правильную грань. Эта проблема связана и с трудностями в пространственном мышлении и отсутствием семантики при работе с селекторами.
А вот с чертежами не спад, а обрыв. 0.78 на простых — и 0.25 на средних. Всё, что сложнее чертежа из демо выше, агент фактически не понимает: когда видов становится несколько, он не связывает их в одну форму. Между средним и сложным уровнем разницы уже нет (0.25 и 0.24) по простой причине — ниже падать некуда.
Результат: цена
Текстовые задачи ожидаемо экономны: 2–4 вызова на простых и средних, рост до 10–15 на сложных, в основном за счёт правок после визуального осмотра.
Чертежи стоят дорого с самого начала — 5.6 вызовов там, где текстовая задача обходится двумя. А на сложных начинается то, ради чего эту метрику и стоило считать: половина кейсов упёрлась в потолок в 60 вызовов Агент не сдаётся и не признаёт поражение — он по десятому разу переделывает построенное, пока не кончится лимит.
Просадка на чертежах объяснима: это не одна задача, а комплекс — прочитать проекции, связать их между собой, восстановить объёмную форму, воспроизвести операциями.
Сквозной агент, который отлично тянет текстовое моделирование, здесь разваливается, хотя по отдельности нейросети такие подзадачи уже решают (распознавание видов, чтение текста на чертеже, классификация элементов).
Именно здесь окупается то, что агент свой: под чертежи можно достроить отдельный граф с нужными этапами — не только для этой задачи, но и для других узких сценариев в будущем.
Итог
ИИ агент способен моделировать по тексту.
Моделирование по описанию даёт IoU около единицы на рутинных деталях — втулках, фланцах, крышках — и оставляет параметрическую деталь, а не мёртвую геометрию. Слабые места конкретны: правки упираются в выбор грани, чертежи сложнее одноракурсных пока не тянутся. Это не ограничение нейросетей — сквозной цикл здесь просто не тот инструмент.
Дальше — не переписывать агента, а достраивать библиотеку:
сборки, чертежи, спецификации — новые методы обёртки, без переделки ядра;
чертежи — отдельный пайплайн с чтением проекций;
правки по грани — отдельная задача на распознавание геометрии, не общий цикл.
Развитие проекта.
Попытки скрестить ИИ и CAD пока чаще вызывают скепсис, чем доверие — и это понятно, обычно за красивым демо стоит то, что не выдержит реальную задачу. Но технологические ограничения, на мой взгляд, преувеличены: при должной проработке ИИ уже можно отдавать реальные операции, и в статье показано, что уже хорошо работает и как это дальше можно расширять под конкретные задачи.
Дальше хочу проверять подход не на демо‑кейсах, а на реальных задачах. Если у вас в компании есть КОМПАС и рутина, которая ест время инженеров, — расскажите, что это за задачи. Часть наверняка закроется тем, что уже есть в статье, часть — повод для отдельного пайплайна под конкретный сценарий.
Комментарии (51)
Amareis
20.08.2026 12:30Новое поколение моделей как будто отдельно затачивали под 3д - попробуйте для сравнения тот же кими к3, скорее всего будет сильно лучше.
SensDj
20.08.2026 12:30В реальной работе инженегры у нас помнят как выглядят сотни деталей и сборок которые были спроектированы нашим КБ за последние лет 40, у каждой из них есть свои нюансы, например в определённых местах толщина задана напрямую, хотя технологам удобнее от той поверхности, от которой будут фрезеровать, на это там есть причины. ИИ из статьи не знает всех тонкостей работы конкретного КБ, как этот опыт в него впихнуть ? это вопрос будущего, если будут двигать тему ИИ-инженеров в КБ
akardapolov
20.08.2026 12:30как этот опыт в него впихнуть ?
Оцифровать этот опыт.
это вопрос будущего,
Уже вот-вот - и будет настоящее.
Современные технологии позволяют реализовать подобное на весьма достойном уровне.
Только надо поэтапно двигаться, начинать с небольших задач - и далее по нарастающей.
bk_Andragon
20.08.2026 12:30Оцифровать этот опыт.
"Сова не тактик, сова стратег!"
Современные технологии позволяют реализовать подобное на весьма достойном уровне.
Не позволяют. Даже с обычной кодовой базой глубокое погружение в контекст не реализовано. Правки в русле бизнес-логики тоже из разряда фантастики. А ведь это всего лишь текст. А конструкторская документация, скажем на стойку шасси для Боинга, это сотни чертежей и схем, и я не представляю как нейронка что-то будет здесь делать
DanielBobrov
20.08.2026 12:30А как новоприбывший стажер узнает все это? Ему кто-то рассказывает? Ну так оформите все эти рассказы в скилы. Они ведь буквально для этого и созданы. Банально на каждую деталь по скилу. Не очень экономно мб, но работать будет
HelixA350 Автор
20.08.2026 12:30Хороший вопрос, это как раз то, о чём я писал в конце — не переписывать агента, а достраивать библиотеку под конкретику.
Часть таких правил можно оцифровать как RAG по внутренним стандартам, часть — зашить в саму обёртку как дефолты для класса деталей.
ИИ агенты для кодинга уже начали повсеместно применять в больших командах и им смогли переложить знания о стандартах
Мне было бы интересно узнать больше про такие нюансы — если есть желание, можете написать (контакты в профиле), было бы полезно для развития проекта.
SensDj
20.08.2026 12:30ну много я написать не могу, т.к. это оборонка, некоторые вещи называются технологичность конструкции (например если где-то может скапливаться влага от дождя и конденсата - то такие места надо проектировать такой формы, чтоб влага стекала, а не накапливалась), ещё бывает в сборку суют детали из разных металлов, которые при соприкосновении и присутствии влаги дают коррозию. Часто инженеры делают модернизацию старых приборов и изделий, или просто берут часть деталей от предыдущих разработок, поэтому форма новых деталей и сборок должна соответствовать по крепёжным и посадочным местам форме старых приборов, корпусов, шпангоутов и т.п. Нужно объёмное мышление, бывает просто в сборку накидываем имеющиеся приборы и думаем как их скомпоновать, какой формы будет корпус чтоб их объединить, саму сборку надо засунуть в более крупный узел - у него там свои габариты внутреннего объёма, часто сложной формы. В общем тут либо ИИ должен всему этому научиться, либо пока без него.
konst90
20.08.2026 12:30Технологичность - это, грубо говоря, простота изготовления изделия. Никакого отношения к стоку влаги она не имеет. Ко всяким "технологичным опциям", кстати, тоже.
И ТКонтр проверяет именно это - оптимально ли спроектировано изделие с точки зрения его изготовления, можно ли его упростить с допустимой потерей прочих характеристик.
Wesha
20.08.2026 12:30Один из тамошних инженеров-механиков постоянно пытался изобрести нечто новое, но все у него получалось как-то наперекосяк. Однажды он принес начальнику проект коробки передач, одна из ее шестерен была большой, дюймов восьми в поперечнике, и с шестью зубцами. Он очень волновался и все спрашивал:
— Ну, как, босс? Как она вам?
— Отлично, — отвечает босс. — Осталось только соорудить на каждом зубце пропускник для вала, иначе ваша шестерня вращаться не сможет.
У этого деятеля главная ось вращения проходила в аккурат между зубцами!
А потом босс сказал нам, что такая штука, как пропускник для оси, действительно существует (я решил было, что он шутит). Немцы изобрели ее во время Первой мировой войны, чтобы не позволить английским минным тральщикам зацеплять тросы, на которых держались подводные мины. Тросы с пропускниками проходили через английские тралы, как сквозь вращающуюся дверь. То есть, вообще-то, спроектировать это дело для каждого зубца шестерни было можно, однако босс решил, что тому инженеру с такой задачей лучше не связываться, и велел ему перепроектировать редуктор так, чтобы главная ось вращения проходила где-то в другом месте.
© «Вы, конечно, шутите, мистер Фейнман!»
woozle
20.08.2026 12:30А есть ли какое-нибудь рабочее решение для генерации чертежей из модели? Скажем, есть созданная человеком выверенная модель, и нужно по ней сделать набор чертежей для производства... Сейчас это отнимает у человека немало времени. Как оптимизировать?
dugalb
20.08.2026 12:30Решения есть - просто они в основном коммерческие и пока не идеальные. Полноценного "нажал кнопку и получил готовый производственный чертёж с умной размерностью и ГОСТ/ISO" в открытом коде почти нет. И сами чертежи бывают разными: строительные или машиностроительные, схемы, сборки, детали. Поэтому если смотреть строго на open-source - полноценных рабочих решений мало, если брать рынок в целом - они уже работают и активно внедряются.
Dron76
20.08.2026 12:30В компасе есть такая функция, с немалым участием человека правда или вы имеете ввиду что то другое?
akardapolov
20.08.2026 12:30А это проблема? Вроде же есть Autodesk Inventor и проч.?
Можно же не в 2D - а напрямую в 3D модель информацию загружать (допуски и проч) и отдавать ее уже готовую в ЧПУ?
konst90
20.08.2026 12:30Если модель существует в виде геометрии без каких-либо дополнительных данных, то задача в общем случае нерешаемая. Три вида раскидать не проблема, и даже выбору дополнительных видов, местных разрезов, выносных элементов и прочему нейронку (наверное) можно научить, если постараться.
А вот на этапе расстановки размеров уже начнутся проблемы. В чертеже ведь не номинальные размеры ставятся, а с допусками, а понять из геометрии, где какой допуск нужен, невозможно: так, какой-нибудь цилиндр может быть валом, от которого нужен точный диаметр и не важна длина (14 квалитета хватит), или проставкой, где диаметр не важен, а на длину нужен точный допуск. С допусками формы и расположения то же самое будет.
Wesha
20.08.2026 12:30валом, от которого нужен точный диаметр и не важна длина
Как это «не важна длина»??? От длины прогиб вала зависит!
konst90
20.08.2026 12:30Ну вот так - не важна. У меня такое регулярно бывает - диаметр вала по шестому квалитету, а длина по 14-му или ещё грубее. И изделие нормально работает.
Wesha
20.08.2026 12:30Вы ещё скажите, что шестерня посередине вала длиной 50 мм работает точно так же, как и шестерня посередине вала длиной 500 мм.
konst90
20.08.2026 12:30Скажу, что придуряться не надо. Слово "квалитет" вы не знаете или принципиально игнорируете? На длине 50 допуск по два раза упомянутому 14-му квалитету - меньше миллиметра. Самый грубый 18-й - меньше четырех.
Поэтому, если чертеж допускает 500 мм при номинале 50 - то допуск поставлен вручную, то есть автор чертежа выбрал его сознательно. Значит, его такая (не)точность устраивает.
Wesha
20.08.2026 12:30Скажу, что смотреть надо, что пишете — было сказано, что «не важна длина», а не допуск по длине.
konst90
20.08.2026 12:30было сказано, что «не важна длина»
И сразу после этого - уточнено, в каких пределах "не важна". Потому что любому инженеру (которому и нужна генерация чертежей) очевидно, что какой-то допуск на каждый размер быть обязан, иначе ему нормоконтроль чертёж не подпишет.
Но вы почему-то это уточнение то ли проигнорировали, то ли не поняли - и кинулись спорить. А 14-й квалитет - это уровень выпускника ПТУ на универсале, грубее просто нет смысла ставить, если это не литье. Поэтому допуск на сам размер в таком случае зачастую не ставится, а в ТТ приводятся неуказанные отклонения. И инженеру, которого интересует задача автоматизации чертежей (и для которого писался коммент) будет понятно, что имелось в виду - он "H14, h14, ±IT14/2" десятки раз видел.
HelixA350 Автор
20.08.2026 12:30Думаю задача модель→чертёж вполне решаема, и VLM тут отлично подходят — выбор видов, сечений и подобное это как раз их сильная сторона.
А проблему с допусками, которую подняли выше, можно решать не сквозным агентом, а поэтапной цепочкой с проверкой человеком после каждого шага: сначала выбор видов — оценили, потом автопростановка размеров — оценили, и так далее.
Мне хотелось бы интересно узнать про эту задачу больше нюансов для развития проекта — контакты в профиле, пишите.
fenixion
20.08.2026 12:30Интересно замечать что кто-то ещё работает над той же задачей.
VLM пока слабы в понимании пространственной геометрии и часто возвращают ложноположительный результат в задаче верификации детали.
Как только компетенции VLM усилят в этом аспекте, можно будет расчитывать на качественную обратную связь по визуалу и это существенно улучшит подобных агентов, выведя такую разработку в мейнстрим.
По сути, сейчас (на момент комментария) возможности агента опережают возможности VLM.
Модель по тексту во FreeCAD.GenCAD akardapolov
20.08.2026 12:30VLM пока слабы в понимании точной пространственной геометрии
Пока только переводить все в текст/координаты - и работать так.
Семантика у мощных моделей кстати уже на достойном уровне.
HelixA350 Автор
20.08.2026 12:30Это круто
А модель во freecad строится через cadquery скрипты или через api создается дерево операций?
Я изучал первый вариант, но как понимаю из cadquery экспортировать дерево для работы руками пока нельзя
fenixion
20.08.2026 12:30Используется генерация Python скрипта вызывающего методы стандартного API FreeCAD.
bladeser
20.08.2026 12:30Факт. Писал пайп для перевода ручных эскизов в 3д. Перепробовал кучу методов, но проблемы начинаются именно при построении. Пространственное мышление - это стопор пока для БЯМ
Dron76
20.08.2026 12:30Отлавливать ошибки даже в своих построениях бывает непросто, с продукцией ИИ это может быть гораздо веселее
HelixA350 Автор
20.08.2026 12:30Думаю для развития такой темы CAD программам не хватает механик быстрого просмотра параметров и изменений
Как например при заливе кода в гит можно видеть по строкам что исчезло, а что добавилось
genseq
20.08.2026 12:30Осталось дождаться такого же агента во FreeCAD. Или его можно перепарсить теми же ИИ в любую программу для CAD?
fenixion
20.08.2026 12:30Похожий там уже 4 месяца присутствует.
https://github.com/drfenixion/freecad.gencad
Но LLM пока только на пороге таких построений и более-менее приемлемый результат дают только топ тир модели, а текущее поколение VLM довольно слабо в проверке точной пространственной геометрии детали и часто выдаëт ложноположительный результат.
siberianlaika
20.08.2026 12:30Под применение с LLM хорошо вписался OpenSCAD, поскольку в нём вообще отсутствует визуальный UI редактирования, а есть только исходный код (текст) и в UI предоставлен просмотр готовой детали. То есть там схема изначально была подходящей для перерабатывающих текст нейросетей. Я не много работал с таким софтом, у меня это как хобби для 3D-печати, но сам концепт выглядит верным: 3D-модель как исходный код на некоем языке программирования. Вот здесь в Компасе автор пришел к этом же, задействовав язык COM API, а если изначально как в OpenSCAD и подобных сделать язык программирования основным методом построения модели, то проще будет увязать это с LLM.
HelixA350 Автор
20.08.2026 12:30Согласен, OpenSCAD решает главную проблему "закрытости" форматов у CAD программ, но для ии систем проектирования ОЧЕНЬ важно чтобы они внедрялись в Компас, Solid и другие уже используемые системы
Потому что сменить cad в масштабах предприятия это намного сложнее чем сменить редактор кода
Может быть конечно появится Cursor в мире CAD, но пока к сожалению не слышал о таком
yva45
20.08.2026 12:30А получилось завернуть визуальный фидбэк для модели? Опыт показывает, что если какие-то несложные вещи модель делает по описанию неплохо, то когда у неё референс - картинка, получается довольно криво, во всяком случае с первого раза.
HelixA350 Автор
20.08.2026 12:30Пока конкретных цифр назвать не могу, но на глаз модель хорошо подмечает различия между моделью и чертежом через визуальный фидбек
SpartakKovrigin
20.08.2026 12:30
На текущий момент ScanToNeutral ML v0.2.22 — это система автоматизированного анализа машиностроительных чертежей с подготовкой данных для последующего построения 3D-моделей и автоматической генерации CAD-документов.
Основные возможности:
1. Разметка и анализ чертежей
Загрузка и ведение базы чертежей с сохранением истории.
Работа с группами чертежей, DRW-ID и контроль уникальности.
Исключение ошибочно попавших документов (например, страниц спецификаций).
Поддержка массовой разметки новых партий чертежей.
2. Распознавание и классификация видов
Поддерживаются типы рабочих видов:
основной рабочий вид;
продольный вид;
продольный разрез;
поперечный разрез;
торцевой вид;
выносной элемент;
локальный разрез/сечение;
продольный профиль;
изометрический вид;
схемы строповки.
Для каждого вида хранится:
роль в построении 3D;
использование/неиспользование для 3D;
охват геометрии;
масштаб;
ось/центр;
связь с дополнительными обозначениями.
3. Анализ областей листа (Sheet Regions)
Автоматически и вручную размечаются:
основная надпись;
рамка чертежа;
технические требования;
общая шероховатость;
примечания;
печати и согласования;
дублирующее обозначение чертежа;
обозначения видов и разрезов.
Для обозначений видов добавлена связь:
А-А ↓WorkingView V5 ↓масштаб 2:1↓
WorkingView V5
↓
масштаб 2:1
4. Работа с масштабами по ЕСКД
Поддерживается стандартный ряд ГОСТ 2.302-68:
1:2 … 1:1000;
1:1;
2:1 … 100:1.
Есть режим:
«По масштабу листа»;
индивидуальный масштаб дополнительного вида.
Масштаб может автоматически связываться с конкретным видом.
5. Подготовка ML-датасета
Создана инфраструктура обучения:
COCO-совместимый экспорт;
разделение train/val/test;
контроль неизменности split;
визуальные контактные листы;
диагностика ошибок.
Текущие ML-модули:
WorkingView Detector;
Candidate Recall Diagnostic;
Proposal BBox Refiner;
Axial Extent Refiner;
Primary Working View Selector.
6. Аудиты качества разметки
Есть отдельные режимы:
Isometric Audit — поиск и исключение изометрии;
Rigging Scheme Audit — схемы строповки;
Longitudinal Profile Audit;
Detail / Local Section / Profile Audit;
View Designation Audit.
Они позволяют постепенно очищать старую базу без переразметки с нуля.
Если кому интересно то тоже готов пообщаться
HelixA350 Автор
20.08.2026 12:30Очень интересный и перспективный проект!
Это опенсорс или закрытая разработка?
Мне было бы интересно обсудить как это можно встроить в ИИ для CAD, как с Вами связаться?
akardapolov
20.08.2026 12:30с подготовкой данных для последующего построения 3D-моделей и автоматической генерации CAD-документов
Геометрию еще не делали?
SpartakKovrigin
20.08.2026 12:30на простых да, проверял (Компас и Inventor). Строится все
akardapolov
20.08.2026 12:30Из 2D в 3D сложная задача, там с геометрией много будет работы КМВ.
Тоже работаем в этом направлении по строительным чертежам:
Детекция полигонов помещений v0.0.1
Vindicar
20.08.2026 12:30Я, конечно, "не настоящий сварщик", но замечу: имена переменным агент выбирает осмысленные, а что насчёт имён операций, проекций и прочего? Повлияет ли это на качество работы?
HelixA350 Автор
20.08.2026 12:30Признаю, пока все что касается дерева построения не на высшем уровне, потому что сейчас первый приоритет — это получить точную геометрию
Vindicar
20.08.2026 12:30А вот про это и вопрос: может, агент будет меньше путаться в своей же работе, если будет всё называть по-человечески? Было бы интересно увидеть сравнение в следующей статье.
kerby2000
20.08.2026 12:30А кто-то пробовал библиотеку Build123d? Тут все дерево дерево построения хранится в коде, визуальная верификация через любой STEP file Viewer. А чертежи можно и в SolidWorks отправить через MCP.
Entity2059
ну не бывать конструктору вайб-конструктором)) далеко от этого, по крайней мере.
Но MCP в компасе это очень хорошо
PKav
Почему? Бывать. Вопрос что страшнее, когда вайб-код выдаёт ошибку, или когда вайб-деталь не подходит к конструкции. Особенно если уже произвели первую партию.