Интеграция LLM с T-FLEX CAD: как избежать галлюцинаций и стабильно генерировать C#-код

В 2026 году уже смешно спрашивать, умеют ли LLM писать код. Вопрос в другом: умеют ли они писать код, который не сломает чертёж, не воткнёт размер в космос и не вызовет StackOverflowException на пустом месте. Особенно когда речь идёт о T-FLEX CAD — системе, где цена ошибки не просто потеря времени, а брак на производстве.

Интеграция LLM с T-FLEX CAD — задача не про «вжух и готово». Модели, обученные на GitHub и Stack Overflow, понятия не имеют, что такое T-FLEX.Document, и уж тем более не знают, какие параметры нужны для CreateLine. Они видят в документации int someParam и, не моргнув глазом, придумывают значение, которое не существует. Итог — галлюцинация. И пользователь получает вместо рабочего скрипта сборник ошибок.

Я покажу, как заставить LLM не врать. Как разделить зоны ответственности между Python (обвязка, валидация, контекст) и C# (реальный код для T-FLEX CAD). И главное — как построить систему самопроверки, которая отсекает галлюцинации ещё до того, как скрипт тронет чертёж.

Почему LLM врут про T-FLEX CAD — три причины, о которых молчат вендоры

1. Документация — зона отчуждения. Официальная документация T-FLEX CAD — это PDF на 2000+ страниц с перекрёстными ссылками. Ни одна LLM не умеет корректно индексировать такие объёмы. Она хватает куски, но не видит контекст.
2. Имена методов нелогичны для моделей. AddSegment может означать добавление отрезка. А может — элемента массива. Для LLM это чёрный ящик.
3. Перегрузка методов. В T-FLEX CAD один метод может иметь 12 перегрузок. LLM выбирает первую попавшуюся, даже если она не подходит.

Звучит как приговор? Нет. Это челлендж. И решается он не магическим промптом, а архитектурой.

Архитектура с разделением зон: Python — судья, C# — исполнитель

Ключевая идея, которую я позаимствовал из подхода ИИ-агента внутри T-FLEX CAD: не надо заставлять LLM писать C# код напрямую. Пусть модель пишет на Python — обвязку, которая проверяет и вызывает C# код. C# код генерируется отдельно, но проходит валидацию на стороне Python.

Почему это работает? Потому что Python-среда контроля:

• Может статически проанализировать C# код (через Roslyn или ручные парсеры).
• Может запустить C# код в песочнице (изолированный AppDomain, Docker).
• Может проверить, что сгенерированные вызовы соответствуют схеме API (контекстуализированные правила).

Вот как выглядит типичный цикл:

1 LLM получает промпт с описанием задачи (например, «нарисуй фланец с 6 отверстиями»)

Модель не генерирует C#. Она генерирует JSON-схему, в которой перечислены объекты T-FLEX CAD (Line, Circle, Dimension) и их параметры. Это её «родной» язык — JSON, в котором LLM ошибается реже.

2 Python-валидатор проверяет JSON-схему

Здесь у нас есть два списка: разрешённые типы объектов и их допустимые атрибуты. Если LLM пытается использовать несуществующий объект, валидатор режет. Если передаёт невалидный параметр — тоже режет. Схема не отправляется на выполнение, пока не пройдёт проверку.

3 Python генерирует C# код на основе проверенной схемы

Тут уже нет места галлюцинациям: каждый вызов — шаблонный код, который лежит в репозитории. Например, если в схеме указан Circle(centerX, centerY, radius), Python берёт готовый C#-шаблон и подставляет значения. LLM участвует только в определении параметров, а не в синтаксисе.

Самопроверка: заставьте LLM доказывать, что она права

Хитрый трюк, который я подсмотрел в разработке CausaNova: пусть модель сама обосновывает каждое решение. Не «нарисуй линию», а «нарисуй линию от (0,0) до (100,0), потому что это нижняя грань фланца, и толщина стенки по ГОСТ 12345 — 10 мм».

Промпт выглядит так:

{
  "task": "Построить фланец с 6 отверстиями",
  "requirements": "ГОСТ 12820-80, материал Ст3",
  "output_format": "json",
  "self_validation": true,
  "explain": "Для каждого элемента укажи, почему он именно такой"
}

Модель возвращает JSON с полем rationale для каждого объекта. Дальше мы парсим эти обоснования и сверяем с нормативной базой. Если обоснование ссылается на несуществующий ГОСТ — галлюцинация. Если обоснование логически противоречит (например, отверстие диаметром 100 мм на фланце толщиной 5 мм) — режем.

Этот же принцип использует техника LoopCoder — повторяющиеся слои самопроверки: модель генерирует, проверяет, перегенерирует. Я описал это в статье про LoopCoder — там детально разобрана архитектура.

Как НЕ надо делать: типичные ошибки (и их цена)

# Упрощённая схема работы Python-агента
import json

# 1. Получить JSON от LLM
raw_response = llm.generate(prompt)  # dict

# 2. Валидация схемы
validator = TFlexSchemaValidator()
if not validator.validate(raw_response):
    llm.request_fix(validator.errors)
    # повторный запрос с указанием ошибок

# 3. Генерация C# из шаблонов
code_generator = CSharpCodeGenerator()
csharp_code = code_generator.generate(raw_response)

# 4. Компиляция и проверка
result = compile_and_run_in_sandbox(csharp_code)
if result.errors:
    log_errors(result.errors)
    # возможно, вернуться к шагу 1 с контекстом ошибок
    
# 5. Выдача готового файла
save_file(csharp_code, "gear.cs")