Eraser для создания чертежей и схем
Создает архитектурные схемы, sequence diagram, ERD, блок-схемы и BPMN по описанию или фрагменту кода. Результат хранится как редактируемая diagram-as-code схема.
Как устроен процесс
Сильные стороны
- Диаграмма остается редактируемой как код
- Поддерживает несколько технических нотаций
- Можно уточнять результат последующими запросами
Ограничения
- Связи и направления нужно сверять с реальной системой
- AI может добавить неподтвержденный компонент
- Схема не заменяет архитектурное решение специалиста
Сценарий: архитектурная схема из реального списка компонентов
Eraser полезен не тогда, когда нужно получить абстрактную картинку про облако, а когда у команды уже есть перечень сервисов, хранилищ, очередей и внешних систем. Перед генерацией зафиксируйте границы: какие компоненты существуют сейчас, какие только планируются и какие находятся у подрядчиков. ИИ может быстро разложить связи, но не знает фактические протоколы, направления вызовов и зоны доверия. Поэтому исходным документом должен быть короткий реестр компонентов с владельцами, интерфейсами и уровнем подтверждения.
Одна схема отвечает на один архитектурный вопрос
Не пытайтесь показать на одном полотне инфраструктуру, бизнес-процесс и последовательность запроса. Для обзора системы достаточно контейнеров и основных зависимостей. Для разбора авторизации создайте отдельную sequence diagram, где видны участник, клиент, API, сервис идентификации и база. Для данных подготовьте ERD только с теми сущностями, которые относятся к обсуждаемой функции. Такое разделение упрощает проверку: разработчик подтверждает вызовы, инженер эксплуатации проверяет контуры, а владелец продукта понимает границу без чтения кода.
Как получить проверяемую diagram-as-code схему
Соберите инвентаризацию
Запишите точные названия компонентов, назначение, владельца, входящие и исходящие интерфейсы. Для каждой связи укажите протокол и направление. Неподтвержденные сведения пометьте словом гипотеза, чтобы генератор не превратил их в установленный факт.
Ограничьте первый запрос
Назовите тип диаграммы, уровень детализации и разрешенные элементы. Например: показать только путь создания заказа, не добавлять мониторинг и не выдумывать промежуточные сервисы. Чем жестче рамка, тем проще найти расхождение.
Сверьте текстовое представление
После генерации прочитайте diagram-as-code как технический список. Проверьте каждую вершину и ребро, исправьте двусмысленные подписи, удалите догадки и только после этого оценивайте композицию.
Разделите перегруженную схему
Если подписи приходится уменьшать, а линии пересекаются, вынесите подробности в дочерний документ. На обзорной схеме оставьте ссылку и дату актуальности, а не уменьшенную копию всех деталей.
Что подтвердить до включения в документацию
- Каждый компонент существует или явно обозначен как планируемый.
- Стрелка показывает реальное направление вызова или передачи данных.
- Протоколы, очереди и хранилища названы так же, как в конфигурации команды.
- Внешние системы и границы доверия визуально отделены от внутреннего контура.
- У схемы указаны владелец, дата проверки и ссылка на исходные требования.
Цвет не должен хранить единственный смысл
Легенда нужна даже для знакомой команде палитры. Различайте внутренние и внешние элементы не только цветом, но также рамкой или подписью. Это сохраняет смысл при черно-белой печати и помогает людям с особенностями восприятия цвета. Если красный означает ошибку, не используйте тот же оттенок для важного, но штатного сервиса.
Версионирование рядом с решением
Сохраните исходный текст схемы рядом с архитектурной записью или техническим заданием. В запросе на изменение перечислите не только визуальные правки, но и причину: новый сервис, измененный протокол, удаленная зависимость. Рецензент должен видеть разницу исходника, а не сравнивать два изображения глазами. Экспорт PNG или SVG подходит для презентации, но редактируемый файл остается основным источником. Назначьте владельца и условие обновления, например при изменении публичного API или маршрута данных.
Частые вопросы по сценарию
Можно ли строить схему прямо по репозиторию?
Фрагмент кода помогает найти сущности, но не раскрывает все рабочие зависимости и договоренности. Сначала определите область анализа, затем подтвердите результат у владельцев компонентов.
Когда нужна sequence diagram вместо общей архитектуры?
Когда вопрос относится к порядку вызовов, ожиданиям, повторным попыткам или ошибкам одного сценария. Общая схема для этого обычно слишком статична.
Официальные страницы
Как подойти к работе с Eraser
Создает архитектурные схемы, sequence diagram, ERD, блок-схемы и BPMN по описанию или фрагменту кода. Результат хранится как редактируемая diagram-as-code схема. Карточка помогает заранее понять подходящий сценарий, подготовить исходные материалы и проверить результат до оплаты подписки или использования его в рабочем проекте.
Сформулируйте конкретный результат
Описание системы, компоненты, связи, код или текущая документация. Чем точнее исходные условия, тем проще сравнить результат с первоначальной задачей.
Проверьте рабочий процесс
Веб-редактор с текстовым синтаксисом, визуальной правкой и AI-чатом. Ожидаемый результат: Редактируемая архитектурная, последовательностная, ERD, BPMN или блок-схема.
Оцените результат вручную
Сильная сторона сервиса: Диаграмма остается редактируемой как код. При этом важно учитывать: Связи и направления нужно сверять с реальной системой.
Когда имеет смысл выбирать этот сервис
Eraser в первую очередь подходит для сценария: Архитектура системы и техническая документация, которую удобно править текстом.
Бесплатный доступ: Бесплатный план включает 3 файла и 3 AI-диаграммы. Платный доступ: Платные планы добавляют приватные файлы, больше AI-диаграмм, историю и интеграции.
