Я как технический руководитель создаю схемы каждый день, например:
- архитектурные схемы существующих и планируемых систем
- орг. структура
- диаграммы последовательности
Создание качественно схемы занимает огромный объём времени. Попытка сэкономить время и срезать углы при описании схем приводит к падению качества и фактически полной бесполезности самих схем. В попытках ускорить свою работу без потери качества я применил современные ИИ решения и кажется, что очень преуспел. Большие языковые модели (LLM) уже сегодня решают множество задач — от генерации кода до создания изображений по текстовому описанию. Поэтому вполне логичным шагом было применить их, в том числе и к “рисованию” схем. Однако есть определенные тонкости.
Давайте попробуем разобраться.
Почему LLM пока плохо подходят для создания готовых схем
На первый взгляд, идея кажется заманчивой: вы пишете запрос вроде «Нарисуй мне схему системы с балансировщиком, двумя веб-серверами и базой данных» — и получаете красивую картинку. Но на практике есть две серьезные проблемы:
- Качество итогового изображения. Нейросети, даже самые продвинутые, на текущий момент не способны стабильно выдавать аккуратные и логически выверенные архитектурные схемы. Часто элементы на таких схемах расположены хаотично, нет четкой структуры связей, отсутствуют подписи или нарушены базовые стандарты визуализации.
- Отсутствие редактируемости. Даже если сгенерированная картинка выглядит приемлемо, внести в нее правки почти невозможно. Нельзя просто «поменять один сервер на два» или «добавить стрелку». Приходится генерировать новую картинку с нуля, что приводит к непредсказуемому результату.
А ведь архитектурные и организационные схемы — это живые документы. Их нужно регулярно обновлять и поддерживать в актуальном состоянии.

Обратите внимание, что на изображении у нас обрезаны верх и низ. Это просто неприемлемо.
Как правильно использовать LLM для создания схем
Решение простое и элегантное: использовать языковую модель не для создания самой картинки, а для генерации описания схемы в текстовом формате. Существуют специальные инструменты, например, PlantUML, Graphviz, которые позволяют по текстовому описанию строить формальные схемы. Идея заключается в том, чтобы попросить LLM написать текст на языке описания схемы (DSL — Domain Specific Language), а затем уже этот текст превратить в визуальную диаграмму с помощью специализированного рендерера.
Плюсы подхода:
- Структурированность. Генерация идет на уровне текстовой структуры, что исключает хаос в расположении элементов.
- Редактируемость. Изменить схему можно просто поправив текст — это гораздо проще и быстрее, чем править изображение.
- Автоматизация. Возможность интеграции с CI/CD и генерации актуальных схем в процессе разработки.
Как это выглядит на практике
Вот пример короткого промпта для языковой модели:
Сгенерируй PlantUML-схему архитектуры: балансировщик нагрузки направляет трафик на два веб-сервера, которые подключаются к базе данных.
И пример кода на PlantUML (сам код вы можете дополнить или изменить):
@startuml ArchitectureDiagram
left to right direction
skinparam monochrome true
skinparam defaultFontName Arial
skinparam usecase {
BackgroundColor White
BorderColor Black
}
rectangle "Балансировщик нагрузки" as load_balancer {
component "Nginx/HAProxy" as lb
}
rectangle "Веб-серверы" as web_servers {
component "Веб-сервер 1" as ws1
component "Веб-сервер 2" as ws2
}
rectangle "База данных" as database {
component "PostgreSQL/MySQL" as db
}
lb --> ws1 : HTTP-запросы
lb --> ws2 : HTTP-запросы
ws1 --> db : SQL-запросы
ws2 --> db : SQL-запросы
note right of load_balancer
Распределяет входящий трафик
между веб-серверами
end note
note right of web_servers
Два идентичных сервера
для отказоустойчивости
end note
note right of database
Единый источник данных
для обоих серверов
end note
@enduml

Такой подход сочетает всё хорошее без всего плохого:
- удобство и скорость генерации с помощью LLM
- структурированность
- удобство редактирования
- git совместимость (благодаря тому что картинка это теперь просто текст)