ИИ рисует диаграммы: генерация BPMN, UML и ER из текста требований

Спринт горит, через два дня демо, а у вас на руках — текстовое описание бизнес-процесса на пятнадцать шагов с тремя ролями. И заказчик просит схему. BPMN. «Чтобы наглядно». Рисовать вручную — час, не меньше, и то после пятой стрелки глаз задёргается. Шесть лет назад я бы вздохнул и открыл draw.io. Сейчас открываю Claude.

LLM неплохо генерирует diagram-as-code. Не идеально. Но для стартового наброска — быстрее человека в разы. Вы даёте текст требований, нейросеть выдаёт Mermaid-код, вы закидываете в редактор — и через пять минут у вас готовая диаграмма. Потом можно поправить пару связей вручную, но 80% работы уже сделано.

Как это работает: pipeline от текста к диаграмме

Механика простая. Вы подаёте на вход LLM текстовое описание предметной области, требований или сценария. Модель генерирует код на Mermaid (или PlantUML — об этом ниже). Код рендерится в визуальную диаграмму. Аналитик делает ревью и либо принимает, либо уточняет промпт.

flowchart LR
  A["Текстовое описание
требований"] --> B["Промпт
с контекстом"]
  B --> C["LLM
(Claude/GPT/Gemini)"]
  C --> D["Сырой код
Mermaid/PlantUML"]
  D --> E{"Синтаксис
валиден?"}
  E -- "Ошибка" --> F["Автоисправление
через LLM"]
  F --> D
  E -- "OK" --> G["Рендеринг
диаграммы"]
  G --> H["Ревью
аналитиком"]
  H --> I{"Соответствует
требованиям?"}
  I -- "Нет" --> J["Уточнение
промпта"]
  J --> C
  I -- "Да" --> K["Готовая диаграмма
в документации"]

  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#f0a500,stroke:#c88400,color:#000
  style C fill:#7b68ee,stroke:#5a4db2,color:#fff
  style D fill:#7b68ee,stroke:#5a4db2,color:#fff
  style E fill:#f0a500,stroke:#c88400,color:#000
  style F fill:#e0e0e0,stroke:#999,color:#000
  style G fill:#50c878,stroke:#3a9a5c,color:#fff
  style H fill:#f0a500,stroke:#c88400,color:#000
  style I fill:#f0a500,stroke:#c88400,color:#000
  style J fill:#e0e0e0,stroke:#999,color:#000
  style K fill:#50c878,stroke:#3a9a5c,color:#fff

На диаграмме — полный поток. Синий — исходный артефакт (требования). Жёлтые — решения аналитика (сформулировать промпт, провести ревью, оценить результат). Фиолетовые — зона ответственности LLM. Зелёные — готовые результаты. Серые — итерации и правки. Ключевое: цикл «LLM → ревью → уточнение промпта» — это норма, а не признак плохого промпта. С первого раза редко получается то, что нужно.

Модель, кстати, не обязательно должна быть платной. GPT-4o-mini, Claude Haiku и Gemini Flash генерят валидный Mermaid почти всегда. Для PlantUML надёжнее брать модели помощнее — синтаксис сложнее, опенсорсные модели на нём спотыкаются.

Генерация BPMN: от словесного описания к схеме процесса

BPMN — самая благодарная нотация для генерации. Процесс описывается линейно, связи между шагами очевидны, шлюзы распознаются по условным словам («если», «иначе», «в случае отказа»). LLM парсит текст и превращает его в узлы и стрелки с минимальным количеством ошибок.

Базовый промпт выглядит так:

1
Сгенерируй BPMN-диаграмму в Mermaid (graph TD) для процесса
2
«Оплата заказа в интернет-магазине».
3

4
Участники: Клиент, Система, П платёжный шлюз.
5
Шаги:
6
1. Клиент выбирает товар и нажимает «Оплатить».
7
2. Система создаёт заказ и выставляет счёт.
8
3. Клиент вводит данные карты.
9
4. Система передаёт платёж в платёжный шлюз.
10
5. Если оплата успешна — Система меняет статус на «Оплачен»
11
   и запускает сборку.
12
6. Если оплата отклонена — Система уведомляет клиента
13
   и предлагает повторить.
14
7. Если платёж не получен за 24 часа — автоотмена заказа.
15

16
Используй разные формы узлов: скруглённые для событий,
17
прямоугольники для действий, ромбы для шлюзов.
18
Подписи — на русском. Цвета не нужны.

На выходе — код. Я специально не прошу расцветку в промпте: стилизацию проще добавить руками или вторым промптом. Первый проход — только структура.

Вот реальный пример того, что выдаёт LLM по похожему промпту (процесс обработки заказа, чуть проще — без платёжного шлюза, для наглядности):

graph TD
  Start(["Заказ создан"]) --> Validate["Проверить наличие
товара на складе"]
  Validate --> InStock{"Товар
в наличии?"}
  InStock -- "Да" --> Reserve["Зарезервировать
позиции"]
  InStock -- "Нет" --> NotifyClient["Уведомить клиента
об отсутствии"]
  NotifyClient --> Canceled(["Заказ отменён"])
  Reserve --> Payment["Выставить счёт
на оплату"]
  Payment --> WaitPay{"Оплата
получена?"}
  WaitPay -- "Да" --> Pack["Собрать заказ
на складе"]
  WaitPay -- "Нет, таймаут 24ч" --> AutoCancel(["Автоотмена
заказа"])
  Pack --> Ship(["Передать
в доставку"])

  style Start fill:#50c878,stroke:#3a9a5c,color:#fff
  style Canceled fill:#e0e0e0,stroke:#999,color:#333
  style AutoCancel fill:#e0e0e0,stroke:#999,color:#333
  style Ship fill:#50c878,stroke:#3a9a5c,color:#fff
  style Validate fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Reserve fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Payment fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Pack fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style NotifyClient fill:#f0a500,stroke:#c88400,color:#000
  style InStock fill:#f0a500,stroke:#c88400,color:#000
  style WaitPay fill:#f0a500,stroke:#c88400,color:#000

Синие прямоугольники — действия системы (проверка, резервирование, оплата, сборка). Жёлтые ромбы — шлюзы ветвления. Жёлтый прямоугольник «Уведомить клиента» — действие с особым статусом (клиентский контакт, а не системная операция). Зелёные — старт и успешный финиш. Серые — тупиковые ветки (отмена, автоотмена).

LLM сгенерировала эту структуру по описанию из пяти строк. Вы потратили минуту на промпт и три на раскраску. Ручное рисование того же самого — 20–30 минут.

Что важно проверять после генерации: не пропущены ли конечные события на альтернативных ветках, правильно ли расставлены шлюзы (XOR вместо AND — частая ошибка), не пересекает ли поток управления границы участников.

Если вы ещё не разобрались с нотациями, советую заглянуть в обзор UML, BPMN и ERD для новичка — там про то, когда какую нотацию брать.

UML: генерация диаграмм классов и sequence

UML чуть сложнее для генерации. Диаграмма классов требует строгой структуры: классы, атрибуты, методы, типы связей (наследование, агрегация, композиция). Sequence-диаграмма — порядка взаимодействия во времени с правильным синтаксисом стрелок (синхронные/асинхронные, возвраты).

Но промпт решает. Вот шаблон для диаграммы классов:

1
Сгенерируй UML-диаграмму классов в Mermaid для домена
2
«Управление заказами в интернет-магазине».
3

4
Сущности:
5
- Order: id, status, createdAt, totalAmount, customerId
6
- OrderItem: productId, quantity, price
7
- Customer: id, name, email
8
- Product: id, name, price, stockQuantity
9

10
Связи:
11
- Order 1 → * OrderItem (композиция)
12
- Order * → 1 Customer
13
- OrderItem * → 1 Product
14

15
Используй синтаксис classDiagram Mermaid.
16
Покажи только атрибуты, без методов.
17
Подписи на русском.

Модель выдаст что-то вроде:

1
classDiagram
2
    class Order {
3
        +int id
4
        +String status
5
        +DateTime createdAt
6
        +Decimal totalAmount
7
        +int customerId
8
    }
9
    class OrderItem {
10
        +int productId
11
        +int quantity
12
        +Decimal price
13
    }
14
    ...

Синтаксис валидный, связи корректные. Я проверял на GPT-4o, Claude Sonnet и Gemini Pro — все три справляются. С Haiku и Flash бывают промахи со стрелками наследования — путают направление, но это чинится за секунду.

С sequence-диаграммами та же история. Даёте список участников и шагов — получаете готовый код. Главная ловушка здесь — асинхронные вызовы. LLM склонна рисовать все стрелки синхронными (->>), игнорируя асинхронную природу событий. В промпт стоит явно добавить: «Асинхронные вызовы обозначай как --)». Без этой фразы получите синтаксически верную, но семантически неверную диаграмму.

Sequence-диаграммы — пожалуй, самый выигрышный кейс для генерации. Вручную расставлять 20 стрелок между 7 участниками — пытка. LLM делает это за 10 секунд. Я на проекте с микросервисной архитектурой генерировал sequence-диаграммы пачками по 5–7 штук за вечер. Ручное рисование заняло бы дня два.

Тем, кто только осваивает UML, пригодится базовый разбор диаграмм, которые реально используют — там про то, какие типы диаграмм закрывают какие вопросы.

ER-диаграммы: из списка сущностей к схеме БД

ER-диаграммы LLM щёлкает как семечки. Структура плоская, связи сводятся к one-to-many / many-to-many, никакой логики ветвления. Идеальный кандидат для автоматизации.

Промпт до безобразия прост:

1
Сгенерируй ER-диаграмму в Mermaid (erDiagram)
2
для системы учёта заказов.
3

4
Таблицы:
5
- customers (id, name, email, phone)
6
- orders (id, customer_id, status, total, created_at)
7
- order_items (id, order_id, product_id, quantity, price)
8
- products (id, name, price, stock_qty)
9
- payments (id, order_id, amount, method, paid_at)
10

11
Связи — сам определи по именам полей.

LLM сама выводит связи по foreign key-соглашению (customer_id → связь с customers). Это работает настолько стабильно, что я перестал рисовать ER-диаграммы вручную вообще. Сценарий: взял описание домена из Confluence, скормил LLM, получил диаграмму, поправил пару названий. Готово.

Граница применимости — когда foreign key зовут не по соглашению. Если в таблице sales поле buyer ссылается на clients, а recipient — туда же, LLM не догадается. Но такие случаи редки, и проще поправить одну связь рукой, чем рисовать всё с нуля.

Mermaid vs PlantUML: что просить у LLM

Выбор формата для генерации сводится к простому правилу:

Мой практический совет: начинайте всегда с Mermaid. Синтаксис проще — LLM ошибается реже. Если диаграмма выглядит бедно или не хватает выразительности (swimlanes, артефакты развёртывания) — вторым проходом просите перегнать в PlantUML.

Промпт для конвертации:

1
Сконвертируй эту Mermaid-диаграмму в PlantUML.
2
Сохрани ту же структуру и подписи.
3
Добавь swimlanes для участников.

Работает в 8 из 10 случаев. В оставшихся двух PlantUML-код содержит мелкие синтаксические ошибки — пропущенные кавычки, неверный порядок директив. Они локализуются быстро, если открыть PlantUML-рендерер и посмотреть на сообщение об ошибке.

С опенсорсными моделями (Llama, Qwen, DeepSeek) PlantUML лучше не просить. Я пробовал — получасовой марафон исправлений. Mermaid у них идёт нормально, PlantUML ломается на ровном месте.

Когда ИИ лажает: типичные проблемы и как их лечить

Перечислю то, с чем сталкивался сам:

Пропущенные шлюзы слияния. LLM охотно рисует раздвоение через XOR-шлюз, но забывает слить потоки обратно. Диаграмма становится синтаксически корректной (Mermaid это не считает ошибкой), но семантически — висящей в воздухе. Лечится добавлением в промпт: «Для каждого раздвоения нарисуй слияние».

Путаница с типами стрелок в sequence. Как уже говорил — всё синхронное, если не указать явно. Добавляйте в промпт: «Асинхронные вызовы — --), синхронные — ->>, возвраты — -->>».

Направление связей в classDiagram. LLM иногда рисует стрелку от родителя к потомку, хотя в Mermaid наследование обозначается стрелкой от потомка к родителю. Проверяйте классы, от которых наследуются — стрелка должна идти от них к базовому.

Масштаб диаграммы. Если процесс из 25 шагов — LLM сгенерирует его в одной диаграмме, и это будет нечитаемая каша. Решение: дробите промпт. Генерируйте диаграмму верхнего уровня с подпроцессами (в Mermaid — subgraph), затем отдельные диаграммы для каждого подпроцесса. Это ровно то, что вы делали бы вручную.

Галлюцинации в названиях. Иногда LLM «додумывает» элемент, которого нет в требованиях. Особенно этим грешит GPT-4o — вставляет стандартный «Payment Service» куда ни попадя. Решение: в промпте явно написать «Не добавляй сущности, не упомянутые в требованиях». Работает не на 100%, но снижает частоту.

Синтаксис, сломанный переводами строк. Если промпт длинный и вы вставляете многострочный текст требований — LLM может сломать Mermaid-синтаксис экранированием кавычек или переносов строк внутри узлов. Не вставляйте требования «как есть» — переформулируйте кратко в теле промпта.

Отдельная боль — Mermaid в MDX. Угловые скобки <> интерпретируются парсером как JSX-теги, если не обёрнуты в бэктики. LLM про это не знает. Поэтому сгенерированный код надо прогонять через простую проверку: все ли <...> внутри строк Mermaid обёрнуты?

Чек-лист для аналитика

Пять шагов, которые превращают сырой текст требований в готовые диаграммы:

• Сформулируйте промпт структурно. Не «нарисуй процесс», а «Сгенерируй BPMN в Mermaid graph TD. Участники: [список]. Шаги: [нумерованный перечень]. Шлюзы: [список условий]». Чем точнее структура, тем выше шанс получить рабочий код с первого раза.
• Первый проход — только структура. Без стилизации, без цветов. Проверьте логику процесса на чёрно-белой схеме. Раскрашивать будете вторым проходом — когда убедитесь, что связи корректны.
• Валидируйте синтаксис. Скопируйте сгенерированный код в Mermaid Live Editor или Kroki. Если рендер упал — скормите ошибку LLM и попросите исправить. Обычно хватает одной итерации.
• Добавьте стилизацию. Когда структура готова, пройдитесь по узлам: залейте цветами (из палитры: синий для действий, жёлтый для шлюзов, зелёный для старта/финиша, серый для тупиковых веток). Это превращает схему из черновика в документ, который не стыдно показать заказчику.
• Проведите ревью вручную. Пропущенные стрелки, неверные типы связей, галлюцинированные сущности — LLM пропускает их регулярно. Пять минут ручной проверки экономят часы переделок потом.

Главное правило — не пытайтесь получить идеальную диаграмму за один промпт. Два-три прохода: структура → синтаксис → стилизация. Итерация здесь не баг, а фича подхода.

Я на текущем проекте генерирую BPMN и ER-диаграммы только через LLM. Ручное рисование оставил для случаев, когда процесс настолько нестандартный, что проще нарисовать с нуля, чем объяснить нейросети. Таких случаев — примерно один из пятнадцати.