Как сделать блок-схему бизнес-процесса с ИИ в Mermaid

Учебная иллюстрация развилки процесса; не интерфейс продукта и не клиентский кейс.

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

Mermaid — текстовый язык описания диаграмм: фигуры и связи задаются кодом, а программа строит изображение. Код удобно править вместе с инструкцией. Встроенный ИИ для этого не обязателен: модель помогает подготовить текст схемы, Mermaid его отображает. Описание Mermaid.

Инструкция предназначена руководителям подразделений, аналитикам и сотрудникам, которые описывают внутреннюю процедуру. Результат — черновик простой блок-схемы для обсуждения с исполнителем. Это не модель исполняемого бизнес-процесса и не полноценная BPMN-схема с событиями и правилами движка.

Документация проверена 29 октября 2026 года. Промпты и ситуация ниже — предлагаемые учебные примеры, не ответы протестированной нейросети и не клиентский кейс. Операции в браузерном редакторе описаны по документации; их выполнение в аккаунте пользователя не проверялось.

Шаг 1. Подготовить описание

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

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

Скопируйте этот вымышленный исходник в разрешённый рабочий чат:

Процесс: обработка внутренней заявки на оборудование.
R1. Процесс начинается, когда заявка получена.
R2. Координатор проверяет, указаны ли модель и количество.
R3. Если сведений не хватает, координатор запрашивает уточнение.
    После ответа сотрудника он снова проверяет полноту заявки.
R4. Если сведения полные, кладовщик проверяет, достаточно ли
    нужного оборудования на складе.
R5. Если достаточно, кладовщик выдаёт оборудование.
    В этой ветке процесс заканчивается завершённой выдачей.
R6. Если недостаточно, заявку передают закупщику.
    В этой ветке процесс заканчивается статусом «В очереди закупки».
Не определено: срок ожидания уточнения и порядок отмены заявки.
Закупка у поставщика находится за границами этой схемы.

Идентификаторы R1–R6 нужны для сверки с текстом. Это предложенный приём работы, а не обязательный синтаксис Mermaid. Срок ожидания специально оставлен неизвестным: нейросеть не должна превращать пробел в придуманное правило «закрыть через сутки».

Результат этапа: описание с двумя разными завершениями и отдельным списком нерешённых вопросов. Если вам ещё предстоит выяснить, что сотрудники делают на самом деле, сначала нужен аудит бизнес-процесса, а уже затем рисунок.

Шаг 2. Выделить действия и вопросы

Не просите сразу «нарисовать красивую схему». Сначала предложите модели разобрать исходник:

Разбери описание R1–R6. Верни таблицу:
правило | роль | действие или вопрос | следующий шаг | условие перехода.
Сохрани оба завершения процесса. Отдельно перечисли неизвестные
правила. Не добавляй сроки, согласования и автоматические действия.
Если правило допускает разные трактовки, задай уточняющий вопрос.
Пока не создавай код диаграммы.

Сверьте ответ с исходником. Вопрос «модель и количество указаны?» проверяет полноту заявки; вопрос «достаточно ли оборудования?» проверяет склад. Их нельзя объединить в один ромб «заявка согласована»: тогда исчезнет причина возврата к сотруднику.

Элемент учебного процесса	Что должно остаться в схеме	Что нельзя достраивать без решения владельца
Неполные сведения	Запрос уточнения и возврат после ответа	Автоматический отказ по таймеру
Наличие оборудования	Отдельная проверка количества нужной модели	Проверка бюджета вместо склада
Оборудования недостаточно	Передача закупщику и очередь закупки	Готовый заказ поставщику
Оборудование выдано	Завершённая выдача	Общий финал «выполнено» для обеих веток

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

Шаг 3. Получить код Mermaid

После исправления таблицы отправьте второй запрос:

На основе согласованной таблицы создай flowchart TD в Mermaid.
Используй короткие латинские ID и русские подписи в двойных кавычках.
Действия покажи прямоугольниками, вопросы — ромбами.
Подпиши исходящие ветви вопросов «Да» и «Нет».
Возврат от уточнения к проверке подпиши «Ответ получен».
Выдача и очередь закупки должны иметь разные конечные блоки.
Не включай закупку у поставщика и неизвестный срок ожидания.
Не добавляй оформление, ссылки, HTML или настройки.
Верни только код, начиная с flowchart TD.

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

flowchart TD
    START["Заявка получена"] --> FULL{"Указаны модель и количество?"}
    FULL -->|Нет| ASK["Координатор запрашивает уточнение"]
    ASK -->|Ответ получен| FULL
    FULL -->|Да| STOCK{"Достаточно нужного оборудования на складе?"}
    STOCK -->|Да| ISSUE["Кладовщик выдаёт оборудование"]
    ISSUE --> DONE["Выдача завершена"]
    STOCK -->|Нет| BUY["Передать заявку закупщику"]
    BUY --> QUEUE["Заявка в очереди закупки"]

В этом коде TD задаёт направление сверху вниз. ID вроде FULL позволяют ссылаться на узел, а текст в кавычках становится видимой подписью. Квадратные скобки задают прямоугольник, фигурные — ромб; --> задаёт стрелку. Правила формы, подписей и Unicode описаны в документации flowchart.

Код — текст для редактора диаграмм: его не нужно запускать в командной строке. В рабочий редактор копируйте строки от flowchart TD, без ограждающих тройных обратных кавычек и слова mermaid.

Результат этапа: исходник диаграммы, который можно открыть, исправлять и хранить отдельно от ответа ИИ.

Шаг 4. Открыть и исправить схему

Для несекретного учебного примера откройте Mermaid Live Editor. По официальному руководству исходник вводится в панель Code, а изображение появляется в Preview. Замените демонстрационный текст своим кодом. Сначала добейтесь отображения блоков, затем меняйте подписи и направление. Руководство пользователя.

Если появляется ошибка разбора, вернитесь к минимальному коду. Проверьте парные скобки, обычные двойные кавычки и отсутствие пояснений модели внутри блока. В flowchart слово end в нижнем регистре может ломать разбор; для конечной точки используйте, например, ID DONE. Сложные подписи заключайте в кавычки. Эти особенности отмечены в документации синтаксиса.

Попросить исправление можно точечно:

Исправь только синтаксис Mermaid в приложенном коде.
Не меняй названия действий, направление стрелок, условия и финалы.
После кода перечисли изменённые строки и причину каждой правки.
Текст ошибки редактора: [вставьте фактическое сообщение].

Сравните исправление с предыдущей версией. Если модель вместе со скобкой убрала возврат к проверке, она изменила процесс. Верните связь вручную или повторите запрос с указанием конкретных ID.

У Mermaid есть отдельная функция проверки синтаксиса без построения рисунка — mermaid.parse. Она подтверждает соответствие языка, а не правильность складских правил или читаемость изображения. Описание API проверки.

Результат этапа: редактор отображает схему без сообщения об ошибке. Проверка содержания ещё впереди.

Шаг 5. Проверить маршруты

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

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

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

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

Для небольшой последовательной процедуры flowchart обычно достаточно как рабочего эскиза. Если необходимо описывать сообщения между участниками, параллельные ветки, события по таймеру и исполнение в процессной системе, выбирайте соответствующую нотацию и моделирование с аналитиком. Не выдавайте простой Mermaid flowchart за готовую спецификацию автоматизации.

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

Шаг 6. Сохранить редактируемую версию

Сохраните исходный код в обычном UTF-8-файле, например equipment-request-v1.mmd, и положите рядом описание R1–R6. Имя — предложенный пример. Допишите дату и владельца процедуры в сопроводительную заметку, чтобы было понятно, к кому обращаться при изменении правил.

В Live Editor раздел Actions позволяет экспортировать PNG, SVG и Markdown. PNG удобно вставлять как картинку, SVG сохраняет векторное изображение, а код нужен для дальнейших содержательных правок. История редактора хранится в браузере; не используйте её как единственную копию рабочей схемы. Это документированные возможности, без гарантии доступности конкретной кнопки в вашей сборке редактора.

Для изменения отдельных фигур можно перенести код в draw.io: Arrange → Insert → Mermaid, вставить текст и выбрать Diagram. Текущая документация описывает контейнер с исходником, который можно открыть для правки. При повторной генерации стили и подписи сохраняются, а ручная геометрия пересчитывается; после Ungroup исходник контейнера удаляется. Поэтому храните .mmd отдельно и делайте содержательные правки до окончательной компоновки. Вставка и редактирование Mermaid в draw.io.

Для внутренних схем используйте одобренную среду. README Live Editor указывает настраиваемые внешние сервисы рендеринга, включая Mermaid Ink и Kroki. Это не позволяет считать любую операцию публичного редактора обработкой исключительно внутри браузера. Учебный текст выше вымышленный; рабочие маршруты и данные выбирайте с учётом своей политики. README проекта.

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

Частые вопросы

Нужно ли уметь программировать?

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

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

Если схему предстоит менять, исходник с ID и стрелками позволяет явно управлять переходами. Картинка подходит для просмотра; для изменения логики полезнее хранить текстовую структуру. Это критерий выбора формата, а не сравнение качества всех генераторов изображений.

Можно ли загрузить большой регламент целиком?

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

Как AIrassvet помогает перейти от схемы к автоматизации

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

уточнить исходные правила и границы одной процедуры;
описать необходимые данные и передачи между сотрудниками и системами;
подготовить требования к автоматизации и проверке результата.

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

Вывод

Начните с описания реального порядка действий, выделите вопросы и разные финалы, затем получите и откройте код Mermaid. Пройдите по веткам на конкретных ситуациях и сохраните исходник. Для учебного примера ключевая разница — между «оборудование выдано» и «заявка передана закупщику»: схема полезна, когда сохраняет эту разницу и не скрывает неизвестные правила.