Fits Calc
ИИ для инженера · Основы · часть 7/10
AD-073

MCP для CAD: ИИ, КОМПАС-3D и SOLIDWORKS

MCP задаёт обмен между ИИ-клиентом и инструментами. В CAD-помощнике это позволяет выбранной модели обращаться к КОМПАС-3D или SOLIDWORKS через соответствующий локальный адаптер. Выбор CAD, права изменения документа и проверка результата остаются явными.

Короткий ответ

MCP задаёт обмен между ИИ-клиентом и инструментами. В CAD-помощнике это позволяет выбранной модели обращаться к КОМПАС-3D или SOLIDWORKS через соответствующий локальный адаптер. Выбор CAD, права изменения документа и проверка результата остаются явными.

Как это устроено в Fits Calc CAD Assistant

В помощнике доступны отдельные режимы КОМПАС-3D и SOLIDWORKS. Пользователь выбирает программу для диалога; модель получает инструменты и инструкции выбранной CAD. Общие инженерные правила дополняются сведениями о конкретном API и документе. Журналы позволяют различать действия в программах.

Мультимодальность относится к исходным данным: тексту, изображениям и распознанной речи. MCP относится к вызову инструментов. Модель может понять изображение, но для создания редактируемой детали ей всё равно нужен доступный CAD-инструмент и подходящие параметры операции.

Каталог API показывает доступные записи и сигнатуры. Он не означает, что все вызовы одинаково поддержаны адаптером или прошли инженерную проверку. Для изменения модели нужны контроль документа, журнал вызова и измерение результата; неизвестный итог нельзя автоматически повторять.

Модели и тарифы меняются. GPT/ChatGPT, Gemini, Claude/Claude Code, локальные модели через Ollama и другие продукты приведены как примеры классов инструментов, а не как рейтинг. Функции, контекст, tools, лимиты, стоимость и доступность зависят от модели, плана, региона и даты. Для ответственного процесса фиксируйте конфигурацию и проверяйте официальную документацию.
Инженерный принципКод полезен тем, что его можно запустить, протестировать, сравнить diff и откатить.

Что это меняет в реальной работе

MCP/коннекторы/tools расширяют модель реальными данными и действиями. Каждый tool должен иметь узкую схему входа, least privilege, понятные ошибки и audit log. Особенно опасны универсальные shell/database tools без ограничения workspace и типов операций.

Ключевое требование к инженерному использованию ИИ — оставить границу между данными, вычислением, интерпретацией и решением наблюдаемой. Если модель получила право искать, выполнять код или менять файлы, это право рассматривается как отдельный tool-контракт с журналом и проверкой результата.

Практический инженерный сценарий

Базовый пример для этой части: генерируйте маленький patch с тестами и контрольным примером вместо переписывания модуля целиком. Модель получает только те данные, которые действительно известны, и явное правило: не подставлять неизвестные значения без разрешения. Если данных не хватает, ожидаемый результат — список вопросов и объяснение, какой вывод блокирует каждый пропуск.

Затем ответ переводится из свободного текста в форму, удобную для проверки: таблица исходных данных, список преобразований, допущения, непроверенные утверждения и действия инженера. Такой формат позволяет повторить процедуру на другой модели или после смены тарифа и увидеть, где результаты расходятся.

Технические границы и критерии качества

Код — один из самых проверяемых выходов LLM, если его не запускать вслепую. Минимальный инженерный workflow: маленький patch, фиксированная версия среды, тестовые входы, ожидаемые выходы, diff, sandbox, backup и rollback. Расчётный код дополнительно проверяют аналитическим контрольным примером и размерностями. Скрипты CAD запускают на копии модели и измеряют геометрию после выполнения. API-интеграции требуют contract validation, timeout, retry, идемпотентность и безопасное хранение секретов. «Код компилируется» не означает «расчёт верен».

Контроль именно для этой темыЧто фиксировать
MCP для CAD: ИИ, КОМПАС-3D и SOLIDWORKStool permissions, состояние, approval gate и audit log важнее красивого автономного поведения
Evidenceпервичный источник, измерение, расчётный модуль или исполняемый тест
Regressionэталонный пример, на котором видно изменение после смены модели/режима
Stop conditionостановить вывод, если критический вход отсутствует или источник не подтверждается

Практическая специфика темы

Для темы «MCP для CAD: ИИ, КОМПАС-3D и SOLIDWORKS» полезно рассматривать не абстрактный диалог с нейросетью, а конкретный проверяемый кейс. MCP/коннекторы/tools расширяют модель реальными данными и действиями. Каждый tool должен иметь узкую схему входа, least privilege, понятные ошибки и audit log. Особенно опасны универсальные shell/database tools без ограничения workspace и типов операций.

Перед запуском сформулируйте критерий остановки: если отсутствует критический вход, первичный источник, разрешение на действие или профильный способ проверки, модель должна вернуть статус «недостаточно данных/требуется review», а не закрывать пробел правдоподобным текстом. После ответа проверяется не только вывод, но и сохранность входов, единиц и ограничений.

КонтрольЧто должно быть в результате
Средаверсия runtime/API/dependencies
Изменениемалый diff и ограниченный scope
Проверкаtests + control case + rollback

Как принять решение по этой теме

Для темы «MCP для CAD: ИИ, КОМПАС-3D и SOLIDWORKS» полезно применять три последовательных теста. Первый — достаточность входа: можно ли восстановить каждое критическое значение и его источник. Второй — наблюдаемость преобразования: видно ли, что именно сделал ИИ, tool или внешний API, и можно ли повторить этот шаг без догадок. Третий — независимая проверка: существует ли профильный способ подтвердить итог — расчётом, измерением, CAD/CAE, первичным документом или тестом кода. Если хотя бы один тест не пройден, ответ остаётся draft, а не инженерным решением.

Практически это означает: tool permissions, состояние, approval gate и audit log важнее красивого автономного поведения. Для повторяемого применения сохраните один корректный, один граничный и один намеренно неполный пример. После смены модели, тарифа, системной инструкции или набора tools прогоните эти примеры снова. Так различие между «модель отвечает красиво» и «workflow устойчиво решает задачу» становится измеримым.

Рекомендуемый workflow

Зафиксировать вход. Параметры, единицы, источник, версия и статус достоверности.
Ограничить роль ИИ. Объяснить, структурировать, написать код или найти противоречия — но не менять факты.
Получить структурированный output. Отдельно факты, вычисления, интерпретации и сомнения.
Проверить профильным средством. Калькулятор, CAD/CAE, измерение, первичный стандарт, unit-test.
Сохранить traceability. Модель/режим, дата, инструменты, исходный prompt, исправления инженера.

Что сохранить в инженерной записи

По теме «MCP для CAD: ИИ, КОМПАС-3D и SOLIDWORKS» в рабочей записи достаточно сохранить компактный, но проверяемый набор: идентификатор задачи; исходные файлы или значения с единицами; точную конфигурацию ИИ; разрешённые tools; исходный prompt; полученный output; список исправлений; способ независимой проверки и фамилию/роль утвердившего результат. Такая запись нужна не ради бюрократии: она позволяет воспроизвести решение после обновления модели, понять причину расхождения и не переносить неподтверждённый вывод в следующую стадию проекта. Если задача повторяется, эта же запись становится основой eval-case.

Типичные ошибки

  • просить «сделай правильно» без входной схемы и критерия готовности;
  • считать уверенный стиль ответа признаком истинности;
  • разрешать модели незаметно заменять отсутствующие числа «типичными»;
  • смешивать факт из источника и предположение модели в одной таблице без статуса;
  • переносить workflow на новую модель/версию без контрольного eval-набора;
  • автоматизировать publish, запись в PDM/CAD или production раньше, чем есть rollback и approval gate.

Чек-лист перед использованием результата

ВходыВсе критические поля имеют единицы и provenance.
ОграниченияМодель знает, что ей запрещено додумывать.
ПроверкаЕсть независимый способ подтвердить числа/код/геометрию.
ВерсияЗафиксированы модель, режим, tools и дата.

Навигация по серии

Источники и документация

  1. OpenAI — Prompt engineering
  2. Google AI — Prompt design strategies
  3. Anthropic — Prompt engineering
  4. NIST — AI Risk Management Framework
Проверено: 02.10.2026Инженерная проверка обязательнаМодели и тарифы меняются

Продолжить чтение

Tools для агента: проектирование безопасного интерфейсаУзкая операция с валидируемой схемой конкретизирует безопасный tool вместо универсального shell.MCP и корпоративные инструменты: как подключать агент к системам без бесконтрольного доступаMCP-сервер публикует tools, но остаётся доверенным компонентом с allowlist и собственной проверкой.Промпт: Безопасное действие агентаPrompt ограниченного действия проверяет preconditions и postcondition отдельного tool call.Tool calling для инженера: типизированные контракты вместо «сделай что-нибудь»Типы, единицы, диапазоны и серверные ошибки формируют проверяемый контракт агентного инструмента.