Разработка плагинов для Revit с AI: от задачи до релиза

Что меняется, когда в процессе появляется AI

Раньше узким местом был код: инженер знал задачу, но не знал C# и Revit API. Сегодня модель пишет каркас команды, подсказывает нужный класс и объясняет ошибку компиляции. Узким местом стало другое — постановка задачи и проверка результата. Именно там теперь проходит граница между «сделал инструмент» и «сгенерировал что-то похожее».

Поэтому маршрут ниже устроен не вокруг промптов, а вокруг артефактов: что должно появиться на каждом шаге, чтобы следующий имел смысл. Промпт без артефакта — это разговор; артефакт можно проверить, передать и воспроизвести.

Стек и границы

• C# и Revit API — основная реализация инструментов.
• MCP-сервер — связка Revit с AI-клиентами: Claude Code, Kilo, Cursor, Codex.
• AI-агенты — план, генерация, ревью и тесты; человек ставит задачу, проверяет результат и принимает решение о релизе.
• Git, тесты и сборка — то, что превращает набор команд в поддерживаемый инструмент.
• Репозиторий с готовой архитектурой и образцами — то, что снимает «первый месяц» работы: хост, контракты, версии Revit и сборка уже сделаны.

Если вы только начинаете, сначала пройдите базовый маршрут первого плагина: там манифест, команда, транзакция и типовые ошибки. Этот материал — следующий уровень: как довести инструмент до состояния, которое не стыдно передать в отдел.

Шаг 1. Настроить связку

Цель шага — не «установить AI», а получить проверяемый цикл: вы пишете задачу, агент видит проект и модель, результат возвращается в Revit. Артефакт шага — рабочий вызов одного read-only инструмента на тестовой модели.

1. Установить Revit поддерживаемой версии и убедиться, что плагин загружается.
2. Подключить AI-клиент к MCP-серверу и проверить список инструментов.
3. Выполнить безопасный запрос: «покажи количество помещений по уровням».
4. Сверить ответ с тем, что показывает Revit вручную.

Пока ответ не сверен, переходить к изменениям нельзя: вы не знаете, работает ли связка или модель уверенно выдумывает. Подробности подключения — в статье «Claude Code и MCP для Revit».

Шаг 2. Поставить задачу так, чтобы её можно было проверить

Формулировка «сделай проверку модели» звучит понятно человеку и бесполезна для агента. Рабочая постановка содержит пять частей.

• Вход. Какие элементы, на каком виде, в каком документе. «Помещения на активном виде» — вход, «все помещения проекта» — другой вход.
• Правило. Что считается нарушением. «Имя пустое» и «имя не соответствует шаблону» — разные правила.
• Выход. Список Id, таблица, отчёт, подсветка. Формат важен: по нему проверяется результат.
• Границы. Только чтение или запись; какие категории не трогать; что делать при неоднозначности.
• Критерий приёмки. Наблюдаемое поведение, которое можно проверить на реальной модели.

Пример краткого брифа: «На активном виде найди помещения, у которых пустой параметр „Номер“. Верни таблицу: Id, уровень, имя. Ничего не меняй. Критерий: на тестовой модели находится 12 помещений, и список совпадает с ручной выборкой». Такой бриф можно дать агенту, а результат — проверить.

Шаг 3. Код, тесты и границы изменения

AI пишет код быстрее человека, но и ошибается быстрее. Поэтому работа идёт короткими шагами: выборка → проверка → изменение → проверка. После каждого шага — коммит или хотя бы зафиксированное состояние, к которому можно вернуться.

• Сначала read-only. Убедитесь, что выборка находит ровно те элементы, которые вы ожидаете. Ошибка в фильтре дешевле ошибки в записи.
• Потом транзакция. Изменения — только внутри транзакции, с откатом при исключении и понятным сообщением.
• Расчёт — отдельно. Логику, которая не требует Revit API, выносите в библиотеку без зависимости от Revit: её можно покрыть обычными unit-тестами.
• Тест-кейсы до кода. Для правил и граничных случаев тесты пишутся раньше реализации — иначе агент «подгонит» поведение под пример.
• Ревью агентом — не замена ревью человеком.Модель хорошо ловит пропущенные null и неиспользуемые ветки, но не знает норм и контекста вашего отдела.

Отдельно про многопоточность: Revit API однопоточный, обращения к модели должны идти на UI-потоке. Если агент предлагает «ускорить» выборку через Task.Run, это повод остановиться и проверить, что именно он собирается делать в фоне.

Кто что делает

Шаг 4. Собрать и выпустить

«Работает у меня в отладке» — не релиз. Артефакты выпуска: сборка под нужные версии Revit, манифест, инструкция установки на один экран и описание того, что инструмент не делает.

• Сборка и тесты проходят на поддерживаемых версиях, а не на одной.
• Версия и changelog зафиксированы; пользователь понимает, что изменилось.
• Инструкция проверена на «чистой» машине, а не на машине разработчика.
• Есть канал обратной связи: куда писать, если инструмент повёл себя не так.

В проекте RevitAiTools эти шаги уже автоматизированы: конфигурации сборки, скрипты раскладки и матрица версий. Вы не начинаете с пустого решения и не изобретаете структуру — берёте ближайший образец и добавляете свою логику. Что именно лежит в репозитории, описано на странице RevitAiTools.

Где AI не помогает

• Понимание норм и ответственности. Модель не отвечает за пожарную безопасность и не подписывает раздел.
• Знание вашего процесса. Почему в отделе принято именовать помещения именно так, знает человек.
• Проверка на реальной модели. Никакой отчёт агента не заменяет взгляд на то, что произошло в документе.
• Долгосрочная поддержка. Через полгода разбираться в коде будет человек; поэтому архитектура и тесты важнее скорости генерации.

Что входит в доступ

Первоначальный платёж открывает приватный GitHub-репозиторий RevitAiTools, обучающий курс, MCP-инструменты и сообщество инженеров. Снимок репозитория остаётся у вас; доступ к актуальной версии, обновлениям и сообществу — 30 дней с продлением. Актуальная цена и состав — на главной странице, условия использования кода — в публичной оферте.