Нейросеть для схем: от описания процесса к диаграмме

Нейросеть для схем помогает превратить описание рабочего процесса в структуру: участников, шаги, развилки и связи. Но модель и редактор выполняют разные задачи. Модель предлагает содержание и исходный код, движок диаграмм рассчитывает расположение, человек проверяет смысл. Здесь разбираем рабочие блок-схемы и диаграммы — не электрические схемы, чертежи или схемы вязания.

Начните с вопроса, на который должна отвечать схема

«Нарисуй оформление заказа» звучит понятно, пока не нужно решить, что именно показывать. Путь клиента? Обмен запросами между сервисами? Состояния заказа? Таблицы базы данных? Это разные представления одного процесса. Если не выбрать вопрос, модель смешает экраны, действия пользователя и технические вызовы на одном полотне.

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

Плохой и хороший запрос

Слабый запрос: «Сделай схему заказа». Он не задаёт участников, исключения и границы. Минимальная последовательность «клиент — сервис — готово» может выглядеть аккуратно, но скрывает самое важное: что происходит при отказе оплаты.

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

Второй запрос лучше не из-за «магической» роли эксперта, а потому что фиксирует предмет, порядок, две ветки и запрет на догадки. Перед созданием полезно попросить краткий план: так неверное понимание обнаружится до отрисовки.

Доработка в три шага

1. Черновик. Проверяем участников и успешный путь. Не обсуждаем цвет, пока неверна логика.
2. Исключение. Добавляем отказ оплаты. Просим оставить только подтверждённые исходным текстом сообщения.
3. Проверка. Спрашиваем, что схема не определяет. Например, здесь не описаны таймауты, повторные уведомления и возвраты. Их нельзя молча дорисовать как согласованное поведение.

Этот учебный пример создан и проверен через MCP 5 октября 2026 года: исходная и уточнённая sequence-диаграммы существуют как отдельные объекты. Важнее красивого результата именно разница между ними: во втором явно виден отрицательный исход. Это не схема реальной платёжной системы и не готовая спецификация интеграции.

Какой тип диаграммы выбрать

• Sequence: кто кому отправляет сообщение и в каком порядке.
• State: в каком состоянии находится объект и какое событие его меняет.
• Class: структура классов и отношения между ними.
• ER: сущности данных, их атрибуты и кратности связей.
• Гант: задачи, даты и зависимости в плане.
• Блок-схема: шаги и решения; в Эсборд через MCP она собирается нативными фигурами и коннекторами.

Для первых пяти типов раскладку делает движок диаграмм; исходник можно изменить и заново отрисовать. Это не то же самое, что двигать каждый блок отдельно. В нативной блок-схеме фигуры и связи — самостоятельные объекты. Не обещаем весь UML, автоматическую BPMN-нотацию, архитектурные схемы или mindmap как отдельные поддерживаемые типы движка.

Почему не просто сгенерировать картинку

Картинка подходит для настроения и объясняющей иллюстрации, но неудобна как рабочая модель. Исправить подпись, проверить связь и обновить ветку в ней сложнее. В общей доске рядом остаются исходное описание, комментарии и следующая версия. Команда обсуждает не впечатление от изображения, а конкретные шаги процесса.

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

Где результат нужно перепроверить

Проверьте имена участников, направления стрелок, условия развилок и все связи, которых не было в описании. Для ER отдельно проверьте кратности: «клиент имеет заказы» не означает, что у каждого клиента обязательно уже есть заказ. Для Ганта уточните календарь и длительности, для state — допустимые переходы и конечные состояния.

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

Можно ли попробовать бесплатно

На облачном Бесплатном тарифе Эсборд владельцу организации доступны 100 вызовов MCP-инструментов в сутки. Это не 100 готовых схем: на одно задание могут понадобиться чтение, создание и проверка. Подписка или API внешней модели оплачиваются отдельно. Перед пилотом проверьте актуальные условия и ограничения своего ассистента.

На отдельном фрейме собери редактируемую блок-схему обработки заявки. Шаги: заявка получена, проверка данных, решение «Данные полные?». Если нет — запросить уточнение и вернуться к проверке. Если да — назначить исполнителя и завершить статусом «Принята в работу». Используй отдельные фигуры и связанные линии, подпиши ветви «Да» и «Нет». Не меняй остальные фреймы.

flowchart LR
 A["Заявка получена"] --> B["Проверить данные"]
 B --> C{"Данные полные?"}
 C -->|Да| D["Назначить исполнителя"]
 C -->|Нет| E["Запросить уточнение"]
 E --> B
 D --> F["Задача принята в работу"]