Как заставить LLM писать скрипты для Revit и Dynamo

Практика: языковая модель пишет код под Revit API за минуты, но уверенно выдумывает методы. Разбираем, что она делает хорошо, где врёт и как проверять результат, не сломав модель.

Просишь модель: «напиши скрипт, который переименует все листы по шаблону». Через двадцать секунд приходит аккуратный код на Python с комментариями, обработкой ошибок и красивой структурой. Запускаешь в pyRevit, получаешь ошибку: метода, который она вызвала, в Revit API не существует.

Это не повод бросать. Просто нужно понимать, что языковая модель делает хорошо, а что не делает совсем. За полгода использования у нас сложился набор правил, который экономит часы, а не создаёт новые.

Что модель делает хорошо

Каркас скрипта. Импорты, транзакция, сбор элементов через FilteredElementCollector, вывод результата. Эта часть повторяется в каждом скрипте, и модель её знает.

Логику обработки данных. Отфильтровать, сгруппировать, посчитать, отсортировать, собрать словарь. Обычный Python, где Revit ни при чём. Здесь ошибок практически нет.

Регулярные выражения и парсинг строк. Разобрать марку вида «КЖ-1.3-205» на составляющие, собрать имя листа по шаблону, вытащить число из текста. Задача, на которой человек тратит полчаса и три опечатки.

Объяснение чужого кода. Прислали скрипт от предыдущего подрядчика, никто не понимает, что он делает. Модель разбирает построчно, и это честно экономит день.

Перевод между API. Есть рабочий код на C# из плагина, нужен аналог на Python для Dynamo. Структурно задача механическая, модель справляется.

Где она врёт

Главная проблема одна: модель не знает точную сигнатуру методов Revit API вашей версии и на месте пробела уверенно придумывает правдоподобное.

Типичные выдумки, которые встречаются раз через раз:

• метод, которого нет вовсе, но название звучит логично: element.SetParameterValue("Марка", "КЖ-1");
• перепутанные версии: код для Revit 2019 в проекте на 2024, где перечисления единиц измерения переехали в UnitTypeId;
• забытая транзакция: код меняет модель без Transaction, и Revit отвечает исключением;
• неверный порядок аргументов там, где их четыре и три из них похожи;
• обращение к параметру по русскому имени, когда в проекте он называется иначе.

Отдельная категория это единицы измерения. Модель бодро складывает миллиметры с внутренними футами Revit, потому что в коде это просто числа. Ошибка тихая: скрипт отработает, а размеры в модели уедут. Про это у нас есть отдельный разбор про числа и единицы в Dynamo, там же и цена вопроса.

Как просить, чтобы получалось

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

Указывайте версию. «Revit 2024, pyRevit, IronPython 3» в первой строке запроса убирает половину ошибок с несовместимостью.

Давайте образец рабочего кода. Свой скрипт, который точно работает в вашей среде, приложенный к запросу, задаёт модели стиль и правильные вызовы. Это сильнее любых объяснений: она подстраивается под пример.

Просите минимальную версию. «Без обработки ошибок, без логирования, только суть». Короткий код проще проверить. Красивую обвязку добавите потом, когда логика подтвердится.

Требуйте вывод, а не действие. Первая версия скрипта должна не менять модель, а печатать, что бы она изменила: список элементов, старое значение, новое значение. Смотрите на список, и только потом разрешаете запись.

Спрашивайте про допущения. Прямой вопрос «какие места здесь могут не работать в моей версии» заставляет модель самой указать на слабые точки. Она их обычно знает, просто не говорит, пока не спросят.

Порядок проверки, который спасает модель

Правило простое: скрипт от языковой модели не запускается на рабочем файле. Никогда, даже если выглядит очевидным.

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

Звучит долго, занимает пятнадцать минут. Восстановление модели после скрипта, который переименовал шесть тысяч элементов по неправильному шаблону, занимает день.

Что это даёт по времени

Честные цифры из практики.

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

При этом задачи, где нужна тонкая работа с API (свои классы, обработка событий, расширения интерфейса), почти не ускорились. Там модель помогает как справочник, но пишет всё равно человек.

Средняя экономия по нашим задачам вышла процентов сорок. Не десятикратно, как обещают в роликах, но заметно.

Кому это подходит

Здесь важная оговорка.

Языковая модель ускоряет того, кто может проверить результат. Если вы читаете код и понимаете, что делает FilteredElementCollector, вы получите готовый скрипт за минуты вместо часа.

Если код читать не умеете, вы получите красивый текст, который непонятно почему не работает, и потратите на разбирательство больше, чем на изучение основ. Начинать в таком случае надо не с промптов, а с первого скрипта в Dynamo и понимания, как вообще устроен доступ к элементам.

Отдельный случай: скрипты нужны регулярно и всей командой. Тогда разумнее не раздавать всем доступ к чату, а собрать проверенную библиотеку скриптов с кнопками, чтобы люди пользовались готовым, а не генерировали каждый своё. Про то, как это устроено у нас, есть страница разработки Dynamo-скриптов и плагинов.

Короткий чек-лист

Перед тем как просить код:

1. Назовите версию Revit и среду запуска.
2. Приложите образец своего рабочего скрипта.
3. Попросите сначала версию «только вывод, без записи».
4. Проверьте пять позиций из вывода глазами.
5. Запускайте на копии, потом на рабочем файле после синхронизации.

Пункт четвёртый пропускают чаще всего. Именно он ловит выдуманные методы и уехавшие единицы до того, как они попадут в модель.