КРАТКАЯ ИНФОРМАЦИЯ
| Сложность | Начальный уровень |
| Время | 15–20 минут |
| Что нужно знать | Базовое понимание компонентов (React, Vue или аналоги) |
| Инструменты | Claude (claude.ai или API), любой редактор кода |
Чему научитесь:
- Что такое диаграммы состояний и зачем они нужны при работе с ИИ-ассистентами
- Как попросить Claude сгенерировать диаграмму из готового компонента
- Как с помощью диаграмм ловить пропущенные краевые случаи до того, как они превратятся в баги
Диаграмма состояний показывает, как что-то переключается между разными условиями. Для выпадающего меню это значит: закрыто, открыто, загружается, ошибка, и что вызывает каждый переход. Когда вы просите Claude нарисовать такую диаграмму до или во время написания кода, модель вынуждена продумать каждый возможный путь компонента.
Зачем это нужно? ИИ-ассистенты хорошо справляются с основным сценарием, но пропускают краевые случаи. Форма логина может идеально работать, когда пароль верный, и ломаться, если сеть отвалилась посреди запроса. Диаграмма вытаскивает такие дыры на поверхность.
Что вообще такое диаграммы состояний
У конечного автомата три составляющих: состояния (в каких условиях может находиться объект), переходы (что вызывает движение между состояниями) и начальное состояние (откуда всё стартует).
Для кнопки-переключателя состояний всего два: «включено» и «выключено». Переход вызывается кликом. Для корзины покупок уже сложнее: пустая, есть товары, оформление заказа, обработка платежа, заказ оформлен, ошибка оплаты. Каждая стрелка между блоками означает действие пользователя или событие системы.
Нотация не жёсткая. Можно использовать формальные UML-диаграммы, синтаксис Mermaid (Claude с ним хорошо работает) или просто блоки и стрелки текстом. Главное, чтобы каждое возможное состояние было на диаграмме, а у каждого перехода был триггер.
Вот Mermaid-синтаксис для простого модального окна:
stateDiagram-v2
[*] --> Closed
Closed --> Open: пользователь кликает триггер
Open --> Closed: клик вне окна
Open --> Closed: нажатие Escape
Open --> Closed: клик по кнопке закрытия
Четыре состояния (если считать начальное), четыре перехода. Диаграмма заставляет задать вопрос: а что, если пользователь нажмёт Escape, пока модалка ещё анимируется? Claude может не додуматься обработать этот случай, если диаграмма не поставит вопрос ребром.
Почему это работает с ИИ-кодингом
Андрей Карпатый популяризировал в твиттере термин «вайб-кодинг». Суть: описываешь, что хочешь, ИИ генерирует реализацию. Для простых фич подход на удивление рабочий, но со сложным состоянием начинаются проблемы.
Языковые модели по умолчанию воспроизводят самые частые паттерны из обучающих данных. Если большинство форм логина в датасете не обрабатывают истечение сессии посреди отправки, Claude не додумается добавить этот случай без подсказки. Диаграммы состояний и есть структурированный способ такой подсказки.
Есть и второй плюс: верификация. Когда Claude выдаёт диаграмму вашего компонента, вы за секунды видите пропущенные переходы. Вычитывать 200 строк логики редьюсера дольше, и что-то обязательно пропустишь.
Как заставить Claude рисовать диаграммы
Начните с готового компонента. Вставьте код и попросите: «Создай диаграмму состояний этого компонента, покажи все возможные состояния и переходы».
Claude обычно отвечает синтаксисом Mermaid. Если нужен другой формат, уточните. «Покажи текстовую диаграмму с ASCII-стрелками» тоже сработает.
Пример промпта для готового компонента:
Вот мой компонент формы оформления заказа. Создай диаграмму состояний,
показывающую все возможные состояния и что вызывает переходы между ними.
Используй синтаксис Mermaid.
[вставьте код компонента]
Ожидаемый результат: Claude возвращает блок stateDiagram-v2 со состояниями вроде idle, validating, submitting, success, error и размеченными переходами между ними.
Диаграмма может быть неполной. В этом и смысл. Если в диаграмме Claude нет состояния загрузки, которое точно есть в коде, это несовпадение стоит проверить. Если диаграмма показывает переход, которого нет в реализации, вы нашли дыру.
Для новых компонентов
Когда строите что-то с нуля, сначала опишите фичу, потом попросите диаграмму до любой реализации:
Я делаю компонент загрузки файлов с drag-and-drop.
Прежде чем писать код, создай диаграмму состояний со всеми состояниями
и переходами, которые должен обрабатывать этот компонент.
Включи краевые случаи: сбой сети, отмена пользователем.
Проверьте диаграмму. Добавьте состояния, которые Claude пропустил («а что, если тип файла невалидный?»). Потом скажите Claude реализовать компонент строго по диаграмме.
Как читать и проверять диаграммы
Ищите три вещи:
Тупики: состояния без исходящих переходов (кроме финальных вроде «успех»). Если из состояния ошибки нет пути обратно к форме, пользователь застрянет.
Пропущенные триггеры: проверьте, что каждое действие пользователя и системное событие есть как метка перехода. Если «таймаут сети» нигде не фигурирует, Claude его скорее всего не обрабатывает.
Невозможные пути: иногда Claude придумывает переходы, которые на практике не могут случиться. Переход из «отправляется» сразу в «ожидание» может пропустить нужную логику очистки.
Когда находите проблемы, говорите Claude прямо: «Добавь переход из error обратно в idle по клику на "повторить". И добавь переход по таймауту из submitting в error».
Быстрый пример
Допустим, у вас выпадающий список, который подгружает опции по API. Можно начать так:
Создай диаграмму состояний для асинхронного выпадающего списка,
который загружает опции по API при открытии.
Claude может выдать:
stateDiagram-v2
[*] --> Closed
Closed --> Loading: пользователь открывает список
Loading --> Open: опции загружены
Loading --> Error: ошибка запроса
Open --> Closed: выбор опции
Open --> Closed: клик вне списка
Error --> Loading: повторная попытка
Error --> Closed: закрытие
Теперь можно спросить: а если пользователь закроет список, пока он ещё грузится? А если откроет снова до завершения первого запроса? Добавьте эти случаи в диаграмму, потом попросите Claude реализовать с обработкой гонки запросов.
Когда это лишнее
Простые компоненты с одним-двумя состояниями в диаграммах не нуждаются. Кнопка, переключающая булево значение, вас не удивит. Используйте эту технику для всего с асинхронными операциями, несколькими пользовательскими вводами или состояниями ошибок.
С другими инструментами для ИИ-кодинга я это толком не тестировал. У Copilot инлайн-подсказки работают достаточно иначе, чтобы воркфлоу напрямую не переносился. Cursor, возможно, справится похоже на Claude, потому что может использовать Claude как бэкенд, но не уверен.
Если что-то идёт не так
Диаграмма Claude не совпадает с кодом: обычно это значит, что в коде есть неявные состояния, которые Claude не распознал. Компонент, который одновременно ставит isLoading = true и isError = false, находится в отдельном состоянии, даже без именованной константы. Укажите на это и попросите обновить диаграмму.
Ошибки синтаксиса Mermaid: Claude иногда выдаёт невалидный Mermaid. Чаще всего проблема в неэкранированных спецсимволах в метках переходов. Попросите Claude исправить синтаксис или поправьте вручную. Содержание диаграммы важнее идеального рендеринга.
Слишком много состояний: сложные компоненты могут иметь десятки состояний. Попросите Claude сгруппировать связанные состояния или сфокусироваться на конкретном потоке: «Только диаграмма оплаты заказа, не весь жизненный цикл корзины».
ШАБЛОНЫ ПРОМПТОВ
Диаграмма готового компонента
Создай диаграмму состояний этого компонента, показывающую все возможные
состояния и что вызывает переходы между ними. Используй синтаксис Mermaid
stateDiagram-v2. Включи состояния ошибок и загрузки, если они применимы.
[вставьте код компонента]
Как адаптировать: добавьте конкретные состояния, которые хотите, чтобы Claude нашёл: «Убедись, что учтён случай провала валидации».
Проектирование до реализации
Я делаю [опишите фичу]. Прежде чем писать код, создай диаграмму состояний
со всеми состояниями и переходами, которые должна обрабатывать эта фича.
Включи краевые случаи: сбои сети, отмена пользователем.
Пример результата:
stateDiagram-v2
[*] --> Idle
Idle --> Validating: отправка формы
Validating --> Submitting: валидация пройдена
Validating --> Idle: валидация не пройдена
Submitting --> Success: сервер принял
Submitting --> Error: сервер отклонил
Submitting --> Error: таймаут сети
Error --> Idle: редактирование формы
Success --> [*]
ЧАСТЫЕ ВОПРОСЫ
В: Claude действительно пишет лучше код после генерации диаграммы? О: По моему опыту, да, но не радикально. Основная ценность в том, что проблемы всплывают раньше. Claude не начинает волшебным образом обрабатывать все краевые случаи. Диаграмму всё равно нужно проверять и указывать на пробелы.
В: Можно ли использовать это с TypeScript-библиотеками вроде XState? О: Да. Попросите Claude генерировать конфиги XState вместо диаграмм Mermaid. Результат можно сразу использовать как код.
В: Что если мой компонент не укладывается в модель конечного автомата? О: Некоторые компоненты лучше описываются как трансформации данных, а не конечные автоматы. Если компонент просто преобразует пропсы в рендер без внутреннего состояния, эту технику можно пропустить.
РЕСУРСЫ
- Документация Mermaid по диаграммам состояний: справочник по синтаксису, который обычно использует Claude
- Документация XState: если хотите превратить диаграммы в исполняемый код
- Оригинальный твит о промптинге через диаграммы состояний: источник техники
