Обзор Eraser AI: схемы и диаграммы из описания строятся на одном холсте, где текст описания превращается в редактируемую диаграмму. Документация проекта описывает три способа правки: промпты ИИ, исходный код diagram-as-code и графический интерфейс. Ниже — разбор режимов, полный учебный вход ERD и проверка результата.
Холст, текст и диаграмма: роли трёх слоёв
На странице продукта eraser.io/ai заявлена генерация диаграмм на бесконечном холсте: облачная архитектура, схемы баз данных и другое создаются по описанию или вставленному коду. Там же перечислены три действия: создать диаграмму, итерировать правки с ИИ, оформить конспект технического документа. Документация quickstart уточняет порядок: вставьте меню через /, выберите пункт, опишите систему обычным языком, нажмите генерацию. Пример из quickstart — веб-приложение за API-шлюзом, где Lambda пишет в Postgres и публикует события в очередь, которую читают три воркера.
В нашем упражнении текст задаёт users, courses и enrollments, а ручной DSL фиксирует их имена и связи. Холст при фактическом открытии покажет схему; результат рендера в этой статье не наблюдался.
Практический вывод: описание задаёт структуру, холст даёт быструю правку расположения, а исходный код фиксирует точные имена сущностей и связей. В учебном примере ниже генерация и рендер не запускались; код и ожидаемая структура заданы редакцией вручную. Для проверяемой схемы данных важнее всего третий слой, поскольку он читается построчно.
Тип диаграммы и формат правки: два разных выбора
Документация ai-diagrams перечисляет доступные типы: sequence, entity relationship, cloud architecture и flow chart. Тип можно выбрать вручную, а при пропуске Eraser AI подберёт подходящий по входу. Этот выбор отвечает на вопрос «что изображено».
Формат правки отвечает на другой вопрос — «чем я это меняю». Документация ai-diagrams прямо разделяет: архитектурные диаграммы и блок-схемы относятся к freeform, если формат диаграммы команды не выставлен в Code (DSL); остальные типы относятся к diagram-as-code. То есть один и тот же flowchart может существовать в двух режимах, и от режима зависит, получите вы текстовый исходник или свободную композицию.
| Вопрос | Что выбирает | Где задаётся |
|---|---|---|
| Что изображено | Тип диаграммы | Меню типа при генерации |
| Чем править | Формат: freeform или Code (DSL) | Настройки формата команды |
| Как хранить | Исходный код или картинка | Решение читателя при экспорте |
Для нашего упражнения выбран ERD. Дальше проверяем текстовый код по исходной схеме, без предположений о результате конкретного вызова генератора.
Freeform и Code (DSL) для flowchart и architecture
Перед началом работы определите, какой артефакт нужно передать коллеге: редактируемый холст, текстовый код или изображение. Для примера ниже выбран ERD с исходным DSL; сравнивать версии будем по тексту сущностей и связей.
Для нашей версии схемы сохраните отдельный текст до добавления started_at. Тогда сравнение покажет одну новую строку внутри enrollments. Переименование users или новая связь означали бы дополнительное изменение, которое нужно разобрать.
Доступность DSL для flowchart и architecture проверяйте по формату команды. Наш ручной ERD-код приведён ниже целиком.
Полный вход ERD и ручной редактируемый код
Учебный вход описывает схему записи на курсы. Сущность users: id — первичный ключ, name — имя. Сущность courses: id — первичный ключ, title — название. Сущность enrollments: id — первичный ключ, user_id — ссылка на users.id, course_id — ссылка на courses.id. Каждая запись enrollments относится ровно к одному пользователю и одному курсу; пользователь и курс могут встречаться в нескольких записях. Полей оплаты, оценок и электронной почты нет.
Промпт для генерации:
Исходная схема: users содержит id (первичный ключ) и name; courses содержит id (первичный ключ) и title; enrollments содержит id (первичный ключ), user_id (ссылка на users.id) и course_id (ссылка на courses.id). Каждая запись enrollments относится ровно к одному пользователю и одному курсу. Пользователь и курс могут иметь несколько записей. Полей оплаты, оценок и электронной почты нет.
Построй Entity Relationship Diagram в Eraser DSL строго по этой схеме. Сохрани три сущности, семь перечисленных атрибутов и две связи на уровне атрибутов many-to-one. Не добавляй поля и таблицы по догадке. Покажи редактируемый код. Подписи pk и fk служат метаданными диаграммы; исполнение ограничений базы данных в этой задаче не происходит.
Ручной эталон в синтаксисе Eraser DSL:
users {
id string pk
name string
}
courses {
id string pk
title string
}
enrollments {
id string pk
user_id string fk
course_id string fk
}
enrollments.user_id > users.id
enrollments.course_id > courses.id
Документация erd-syntax объясняет устройство этого текста: сущности соответствуют таблицам и содержат атрибуты, имя сущности уникально, определение состоит из имени и фигурных скобок. Атрибут задаётся именем, необязательным типом и необязательными метаданными через пробел. Связи показывают отношения на уровне атрибутов, а запись вида users.teamId > teams.id читается как ссылка атрибута на атрибут другой сущности.
Имена атрибутов и направления двух связей
Проверка начинается с имён. В эталоне семь атрибутов: users.id, users.name, courses.id, courses.title, enrollments.id, enrollments.user_id, enrollments.course_id. Каждое имя встречается в исходном описании. Ссылочные атрибуты названы по целевой сущности: user_id ведёт к users, course_id ведёт к courses.
Направление связи задаётся знаком. Документация erd-syntax приводит таблицу соединителей: < означает one-to-many, > означает many-to-one, - означает one-to-one, <> означает many-to-many. В эталоне обе строки используют >: enrollments.user_id > users.id и enrollments.course_id > courses.id. Читается это так: много записей enrollments ссылаются на одну запись users и на одну запись courses.
| Строка связи | Знак | Кардинальность | Смысл |
|---|---|---|---|
| enrollments.user_id > users.id | > |
many-to-one | Много записей на одного пользователя |
| enrollments.course_id > courses.id | > |
many-to-one | Много записей на один курс |
Ошибка направления ломает модель: запись users.id > enrollments.user_id описывает обратное отношение и меняет кардинальность. Документация erd-syntax предупреждает и о другом: имя, не определённое ранее как сущность или атрибут, приводит к созданию новой сущности или атрибута с этим именем. Опечатка в имени цели порождает лишний объект.
Кардинальность на двух учебных строках
Учебные данные: users — одна строка U1 с именем Оля. courses — две строки, C1 «Зима» и C2 «Лето». enrollments — две строки: E1 связывает U1 с C1, E2 связывает U1 с C2.
Из этих строк видно, почему связь не one-to-one. Один пользователь U1 встречается в двух записях enrollments, значит со стороны users отношение «один ко многим». Со стороны enrollments каждая запись ссылается ровно на одного пользователя, значит many-to-one. Знак > в эталоне описывает именно это направление.
Второй вывод касается курса. Курс C1 встречается в записи E1, курс C2 — в записи E2. Один курс может собирать несколько записей, и структура это допускает. Проверка заданной структуры показывает соответствие входу; качество нормализации конкретной базы она не доказывает.
Третий вывод — про отсутствующие поля. В описании нет оплаты, оценок и электронной почты, и в эталоне их нет. Если генерация добавила такие атрибуты, модель разошлась с входом.
Одна ручная правка и новый эталон
Правка: добавить started_at string только в сущность enrollments. Новый эталон — три сущности, восемь атрибутов, те же две связи. Остальные сущности не меняются, новые связи не появляются.
Порядок действий после правки:
- Внесите строку
started_at stringвнутрь блока enrollments. - Пересчитайте атрибуты: было семь, стало восемь.
- Проверьте, что обе строки связей сохранили знак
>и имена целей. - Убедитесь, что число сущностей осталось равным трём.
- Сохраните исходный код отдельно от экспортированной картинки.
Последний пункт важен по существу. Исходный код и картинка — разные артефакты: код можно править и сравнивать, изображение фиксирует один снимок состояния. Документация erd-syntax добавляет деталь про метаданные: всё после типа показывается как написано, включая pk, fk и unique not null. Эти подписи остаются метаданными диаграммы и не исполняют ограничения базы данных.
Отрицательные пробы и проверка результата
Отрицательные пробы показывают, что модель разошлась с входом.
Первая: связь enrollments.id > users.id вместо enrollments.user_id > users.id. Картинка может выглядеть аккуратно, а ссылка ведёт не тем атрибутом. Проверка — сверка имени атрибута в строке связи с описанием.
Вторая: добавленные сущности payments или атрибуты email. Вход их не содержит, значит модель расширена по догадке. Проверка — пересчёт сущностей и атрибутов против исходного списка.
Третья: опечатка userss.id. Документация erd-syntax допускает автоматическое создание неописанной сущности из связи, поэтому четвёртая сущность в результате означает отказ в проверке. Итоговый чек-лист: три сущности, семь атрибутов до правки, восемь после, две связи со знаком >, имена целей совпадают с описанием, лишних полей нет.
Частые вопросы
Что такое Eraser AI и для чего он нужен?
Это среда для технических диаграмм и документации. В нашем упражнении она используется для схемы записи на курсы с тремя сущностями и двумя связями.
Чем freeform отличается от Code (DSL)?
Freeform редактируют на холсте, Code (DSL) предоставляет текстовый исходник. Для flowchart и architecture формат зависит от настройки команды.
Как получить редактируемый код для блок-схемы?
Проверьте формат команды: для текстового исходника нужен Code (DSL). Сохраните исходник отдельно от изображения.
Как проверить кардинальность связи в ERD?
В нашем примере enrollments.user_id > users.id. Две записи E1/E2 принадлежат U1, а каждая запись ссылается на одного пользователя. Проверьте знак и оба имени атрибутов.
Что делать, если генерация добавила лишние сущности?
Сверьте имена с исходной схемой. В нашем примере userss нужно исправить на users, а добавленную payments удалить. После правки пересчитайте сущности, атрибуты и связи.