Каждая картинка ниже получена из текста, который лежит рядом под словом «исходник». Оформление переключается сверху и меняет сразу все образцы — кроме тех, где цвет задан внутри самой схемы и в том и смысл.
Первое слово схемы решает, что именно рисуется. Дальше язык у каждого вида свой, но принцип один: пишете текстом, получаете картинку.
Самый ходовой вид: шаги, решения, ветки. Обратите внимание на подписи прямо на стрелках.
flowchart TD
A([Заявка поступила]) --> B{Документы полные?}
B -->|да| C[Проверка платежа]
B -->|нет| D[/Запрос документов/]
D --> E[(Ожидание клиента)]
E -.напоминание.-> D
C --> F{Оплачено?}
F -->|да| G([Заказ в работе])
F -->|нет| H[Счёт повторно]
H --> C
Кто кому и в каком порядке. Пунктир — ответ, рамка — примечание, блок alt — развилка.
sequenceDiagram
actor Клиент
participant Бот
participant Склад
Клиент->>Бот: где мой заказ?
Бот->>Склад: статус 4821
activate Склад
Склад-->>Бот: отгружен вчера
deactivate Склад
alt есть трек-номер
Бот-->>Клиент: отгружен, трек 123
else трека нет
Бот-->>Клиент: отгружен, трек будет к вечеру
end
Note over Клиент,Бот: ответ за 2 секунды
Что во что переходит и по какому событию. Годится для заказов, заявок, любых жизненных циклов.
stateDiagram-v2
[*] --> Черновик
Черновик --> НаПроверке: отправить
НаПроверке --> Черновик: вернули
НаПроверке --> Одобрен: принять
Одобрен --> Исполнен: выполнить
Исполнен --> [*]
НаПроверке --> Отклонён: отказать
Отклонён --> [*]
Что с чем связано и сколько к скольким. Классическая схема базы данных.
erDiagram
КЛИЕНТ ||--o{ ЗАКАЗ : оформляет
ЗАКАЗ ||--|{ СТРОКА : содержит
ТОВАР ||--o{ СТРОКА : указан
КЛИЕНТ {
int id
string имя
string телефон
}
ЗАКАЗ {
int номер
date создан
}
План по дням с зависимостями. Отмечает сегодняшний день сам.
gantt
title План запуска
dateFormat YYYY-MM-DD
axisFormat %d.%m
section Подготовка
Сбор требований :done, t1, 2026-08-01, 7d
Проект :active, t2, after t1, 10d
section Работа
Сборка : t3, after t2, 14d
Проверка :crit, t4, after t3, 5d
Круговая диаграмма — там, где важна не связь, а соотношение.
pie showData title Откуда приходят заявки
"Сайт" : 45
"Телефон" : 25
"Телеграм" : 20
"Почта" : 10
Разбор темы на ветки. Удобно для набросков и планов.
mindmap
root((Служба схем))
Агенту
адрес у схемы
правки по тексту
разбор ошибок
Человеку
картинка
история версий
выбор оформления
Группы, службы и связи между ними — вид, появившийся в движке недавно. Подписи здесь только латиницей: русские буквы этот вид пока не рисует.
architecture-beta
group perimeter(cloud)[Our perimeter]
service agent(server)[Agent] in perimeter
service store(database)[Diagram store] in perimeter
service renderer(server)[Renderer] in perimeter
agent:R --> L:store
store:R --> L:renderer
Что и когда происходило. Годится для истории проекта.
timeline
title Как жила служба
26 февраля : первые ссылки на схемы
24 августа : служба поднята заново
25 августа : адрес у схемы, правки, разбор ошибок
Колонки со статусами — самый молодой вид в движке.
kanban
Сделать
[Памятка для агентов]
[Карточка в Телеграме]
В работе
[Витрина возможностей]
Готово
[Правки по тексту]
[Разбор ошибок]
Схема пишется не только на mermaid. Одиннадцать языков, и у каждого своя сила: один рисует нарядно, другой знает UML целиком, третий строит график по данным. Язык называется один раз, при создании схемы; правки и адреса от него не зависят.
Самый нарядный из всех. Умеет рисовать так, будто набросано на салфетке, — годится для черновика, который ещё обсуждают. Картинку для переписки служба делает сама: сам он отдаёт только вектор.
заявка: Заявка -> проверка: Проверка документов
проверка -> решение: Решение
решение -> выдача: Выдача {
style.stroke-dash: 3
}
Другой класс задач целиком: не связи между сущностями, а ЧИСЛА. Столбцы, линии, точки — то, чего mermaid почти не умеет. Данные пишутся прямо в схему.
{
"$schema": "https://vega.github.io/schema/vega-lite/v5.json",
"data": {
"values": [
{
"месяц": "май",
"сделок": 12
},
{
"месяц": "июнь",
"сделок": 19
},
{
"месяц": "июль",
"сделок": 31
},
{
"месяц": "август",
"сделок": 27
}
]
},
"mark": {
"type": "bar",
"cornerRadiusEnd": 4
},
"encoding": {
"x": {
"field": "месяц",
"type": "nominal",
"sort": null,
"axis": {
"labelAngle": 0
}
},
"y": {
"field": "сделок",
"type": "quantitative"
},
"color": {
"value": "#6366f1"
}
}
}
Самый широкий по видам язык: UML целиком, C4, классы, состояния. Здесь — тот же разговор во времени, что умеет и mermaid, но с оформлением самого движка.
@startuml actor Клиент participant "Служба схем" as S database Хранилище Клиент -> S: присылает схему S -> Хранилище: сохраняет проверенной Хранилище --> S: короткий адрес S --> Клиент: ссылка на картинку @enduml
Когда узлов много и важно, чтобы они легли аккуратно. Единственный из всех, кто отдаёт сразу все форматы картинок.
digraph G {
rankdir=LR;
node [shape=box style="rounded,filled" fillcolor="#eef2ff" color="#6366f1" fontname="DejaVu Sans"];
edge [color="#6366f1" fontname="DejaVu Sans"];
"Заявка" -> "Проверка" -> "Решение";
"Проверка" -> "Отказ" [label="не хватает" style=dashed];
}
Таблицы, поля и связи между ними — так, как их обычно и описывают. 🔴 Имена здесь только латиницей: замерено 26.08.2026, кириллица в имени таблицы или поля не принимается. По-русски пишутся пояснения.
Table clients {
id int [pk, note: 'Номер клиента']
name varchar [note: 'Имя']
created_at timestamp
}
Table orders {
id int [pk]
client_id int [ref: > clients.id]
total decimal [note: 'Сумма заказа']
}
Люди, системы и связи между ними — тот самый взгляд «с высоты», с которого начинают разбор архитектуры. 🔴 Имена только латиницей, как и в DBML; подписи в кавычках — по-русски. И обязателен хотя бы один вид: без него схема считается пустой.
workspace "Схемы" {
model {
agent = person "Агент"
store = softwareSystem "Хранилище схем" {
api = container "Служба" "Bun + Hono"
renderer = container "Рисовальщик"
}
agent -> api "присылает схему"
api -> renderer "просит картинку"
}
views {
container store {
include *
autolayout lr
}
}
}
Рисуется обычными знаками — плюсами, чёрточками, стрелками, — и превращается в аккуратную картинку. Удобно тем, что исходник читается и без рисования.
+---------+ +----------+
| Заявка +----->+ Проверка |
+---------+ +----+-----+
|
v
+----------+
| Готово |
+----------+
Совсем другая задача: что происходит на каждом такте. Нужна редко, но заменить её нечем.
{
"signal": [
{
"name": "такт",
"wave": "p......"
},
{
"name": "запрос",
"wave": "0.1..0."
},
{
"name": "ответ",
"wave": "0...1.0"
}
]
}
Узлы бывают не только острыми прямоугольниками. Форма задаётся скобками вокруг подписи — или новой записью «@{ shape: … }», которая понимает три десятка форм.
Старый способ: какая скобка — такая форма. Читается прямо в исходнике.
flowchart LR
A[Прямоугольник] --> B(Скруглённый)
B --> C([Стадион])
C --> D[[Подпрограмма]]
D --> E[(База данных)]
E --> F((Круг))
F --> G{Ромб}
G --> H[/Параллелограмм/]
H --> I[\Трапеция\]
Способ поновее: форма называется словом. Так их доступно около тридцати.
flowchart LR
A@{ shape: manual-input, label: "Ввод руками" } --> B@{ shape: cyl, label: "Хранилище" }
B --> C@{ shape: doc, label: "Документ" }
C --> D@{ shape: docs, label: "Пачка документов" }
D --> E@{ shape: hex, label: "Подготовка" }
E --> F@{ shape: das, label: "Очередь" }
F --> G@{ shape: bow-rect, label: "Хранимые данные" }
В узел можно положить значок — так схема читается быстрее, чем по подписям.
flowchart LR
A@{ icon: "fa:user", form: "circle", label: "Клиент" } --> B@{ icon: "fa:gears", form: "square", label: "Обработка" }
B --> C@{ icon: "fa:database", form: "rounded", label: "Запись" }
Стрелка тоже говорит: сплошная или пунктир, тонкая или жирная, с подписью или без, и даже с бегущей анимацией.
Сплошная, пунктирная, жирная, без стрелки, в обе стороны, с крестиком и кружком на конце.
flowchart LR
A --> B
B -.-> C
C ==> D
D --- E
E <--> F
F --x G
G --o H
Два способа написать на стрелке: через палочки и прямо внутри стрелки.
flowchart TD
A[Заявка] -->|проверена| B[Оплата]
B -- не прошла --> C[Отказ]
B -- прошла --> D[Отгрузка]
D -.через день.-> E[Доставлено]
Стрелку можно оживить — движение видно в векторе и на странице, в PNG остаётся статичной.
flowchart LR
A[Источник] e1@--> B[Обработка]
B e2@--> C[Получатель]
e1@{ animate: true }
e2@{ animate: true }
Готового набора мало? Цвет задаётся прямо в схеме, и делается это тремя способами — от точечного до общего.
Так и выглядят те самые «каскадные стили»: объявляете класс через classDef и вешаете его на нужные узлы. Меняете класс — меняются все узлы разом.
flowchart TD
A[Заявка] --> B{Проверка}
B -->|прошла| C[Оплата]
B -->|нет| D[Отказ]
C --> E[Отгрузка]
classDef хорошо fill:#dcfce7,stroke:#16a34a,stroke-width:2px,rx:8,ry:8
classDef плохо fill:#fee2e2,stroke:#dc2626,stroke-width:2px,rx:8,ry:8
classDef важно fill:#dbeafe,stroke:#2563eb,stroke-width:3px,rx:12,ry:12
class C,E хорошо
class D плохо
class B важно
Когда класс заводить не хочется: style на конкретный узел. Скругление задаётся через rx и ry.
flowchart LR
A[Обычный] --> B[Особенный] --> C[Тоже обычный]
style B fill:#fef08a,stroke:#ca8a04,stroke-width:3px,rx:14,ry:14,color:#713f12
Самый общий способ: строка настройки в начале схемы задаёт палитру целиком. Ровно это и делают наши готовые наборы, только им не надо ничего писать.
%%{init: {"look": "neo", "theme": "base", "themeVariables": {
"primaryColor": "#fef3c7",
"primaryTextColor": "#78350f",
"primaryBorderColor": "#f59e0b",
"lineColor": "#b45309",
"fontFamily": "Inter, system-ui, sans-serif"
}}}%%
flowchart LR
A[Приём] --> B{Решение}
B -->|да| C[Работа]
B -->|нет| D[Архив]
Подграф собирает узлы в рамку с заголовком — так видно, где чья зона ответственности.
flowchart TB
subgraph агент[Сторона агента]
A[Написал схему] --> B[Проверил]
B --> C[Поправил по тексту]
end
subgraph служба[Сторона службы]
D[(Хранилище)] --> E[Рисовальщик]
end
C --> D
E --> F([Человек видит картинку])