Рабочие контуры
2Figma и кодКейс № 05 · R&D · Design systems · 2026
Изменение в дизайн-системе не проходит молча.
Figma и код живут как две версии правды. Слой фиксирует изменение в Figma и проводит его по единому проверяемому маршруту до кода и остальных поверхностей.
Когда меняется токен, разработчик часто узнаёт об этом только после визуального расхождения. Я собрал слой, который фиксирует изменение, требует явного подтверждения и публикует результат в код, документацию и чат.
Кейс за минуту
Подробнее о результате ↓- Моя роль
- Соло R&D: спроектировал состояния документа, правила ревью, артефакты и собрал систему.
- Ключевое решение
- Факты извлекает код; модель пишет только прозу; документ становится актуальным только после проверки человека.
- Результат
- После синхронизации документ помечается устаревшим, а подтверждение относится к конкретному изменению.
design-docs / sync живой прогон
python -m docgen sync --fixture fixtures/demo-token-change.json
extract: слепок Figma → 55 variables, 12 text styles
normalize: имена токенов совпадают с источником
diff: найдено 1 изменение
color/success #237804 → #15803d
помечаю stale → tokens.md
notify:telegram отправлено
ожидаю проверку человека...
CHANGE#237804 → #15803d STATEactual → stale → actual GATEпроверка человека
01 TL;DR — что изменилось
Изменение проходит единый проверяемый маршрут от Figma до кода.
Слепок Figma
1состояние на момент синхронизацииПоверхности
4Notion, CSS, Storybook, чатГейт
1проверка человекаСистема связывает каждое изменение в Figma с кодом и зависимыми поверхностями, показывает, что оно затрагивает, и требует подтверждения именно этого изменения.
Честный статус: рабочий пилот на моей дизайн-системе, ещё не командное внедрение. Поэтому кейс показывает механику и артефакты, а не придумывает бизнес-метрики.
02 Проблема
Figma и код живут отдельно, а у изменения нет общего маршрута и подтверждения.
Два рабочих контура
Дизайнер меняет систему в Figma, разработчик работает со Storybook и кодом. Между ними нет механизма, который гарантирует доставку каждого изменения. Меняется токен — его приходится переносить вручную.
Третья копия не спасает
Отдельная витрина документации быстро устаревает и теряет доверие. Просто сгенерировать ещё один текст недостаточно: нужно зафиксировать само изменение и потребовать его явного подтверждения.
03 Доказательства · от правки до проверки
Одна синхронизация превращает правку в проверяемый пакет изменений.
Прогон A — минимальная петля одного изменения токена. Отдельно ниже показан прогон B: крупное изменение, где сравнение перечисляет весь объём затронутой дизайн-системы.
01Источник
Дизайнер меняет токен в Figma как обычно.
Никаких новых действий ради документации: правка живёт в том же месте, где команда работает каждый день.
02Факт
Система фиксирует одно изменение токена.
В прогоне A система детерминированно фиксирует изменение color/success. Модель не участвует в фиксации факта и не может изменить результат сравнения.
03Код
Изменение доезжает до tokens.css и Storybook.
Тот же слепок обновляет CSS-переменные и живой справочник состояний. Разработчик получает изменение в коде, а не узнаёт о нём из отдельной копии документации.
04Сигнал
Устаревший документ становится видимым до чтения таблицы.
Статус «устарело» — не ошибка в консоли, а часть интерфейса документа. Каждый читатель видит, что факты требуют проверки.
05Ревью
Проверка привязана к конкретному изменению.
В сообщении видны ID перехода между слепками и точный состав изменений. Если до подтверждения приходит новая правка, подтверждение старого пакета не может закрыть новую правку.
06Результат
После проверки документ снова становится актуальным.
Актуальность — это не дата последней правки. Это состояние, которое можно проверить и объяснить.
Прогон B · крупное изменение
Одна синхронизация показывает, что происходит, когда дизайн-система растёт.
В отдельном демонстрационном сравнении система нашла 18 изменений в 9 документах — среди них 8 новых компонентов и 9 новых использований. Это другой сценарий, не продолжение петли с токеном выше.
Ошибка, которая не дошла до читателя
Модель назвала Page Button — кнопку пагинации — «компонентом для CTA».
Ошибка попала в черновик введения, но не в опубликованный документ: заготовка родилась со статусом «устарело» и не могла попасть к читателю без проверки человеком. Именно так система превращает уверенную галлюцинацию в локальную редакторскую правку.
04 Архитектура
Модель получает список изменений, но не решает, что стало истиной.
При каждой синхронизации система сохраняет JSON-слепок — состояние Figma в этот момент. Из него формируются выходы для кода, Storybook, документации и чата; таблицы токенов и статусы не зависят от того, насколько убедительно модель сформулировала ответ.
извлечь→
собрать→
опубликовать→
сравнениеСлепок изменился со времени прошлой синхронизации?затронутые документы помечаются «устарело» · изменения уходят в CHANGELOG
Код
извлекает и рендерит факты детерминированно
Модель
пишет changelog и черновики новых спек
Человек
единственный, кто снимает статус «устарело»
Дисциплина сигнала
Нет изменений — нет сообщения.
Система не создаёт шум ради ощущения активности: при чистом прогоне статус «устарело» не ставится, дайджест не уходит, публикация остаётся атомарной.
Гейт точного изменения
Проверка подтверждает конкретный переход между слепками.
Пакет изменений связывает две версии слепка, список затронутых документов и решение человека. Поэтому система может отклонить старую кнопку, если источник успел измениться ещё раз.
18изменений в большом сравнении
9документов в составе
2ID слепка
1проверка человека
05 Проба моделей · 3 наблюдения
Один промпт показывает три разных ограничения моделей.
Проба нужна не для выбора «лучшей модели», а для определения границы доверия — и объясняет, почему факты остаются за кодом. В системе две задачи: записать changelog по отчёту об изменениях и написать введение к спеке. Инструкция просит «1–2 предложения, без воды»; в пробе участвовали Gemma 4, Qwen 3.6 и Claude.
Входные изменения
color/success: #237804 → #2d8f06 · новый Status Tag · Button Primary/HoverGemma 4
9,6 ГБ · локально · режим черновика
Changelog
Факты верные, но вместо 1–2 предложений модель выдала пост с заголовками и эмодзи.
Введение к спеке
7 с · пригодно для черновика, но с лёгкой водой.
Что важно
Домыслила мотивацию: «обеспечит лучшую контрастность» — этого не было во входных данных.
Qwen 3.6
23 ГБ · локально · рабочая станция
Changelog
llama-server не смог выделить дополнительные 9,9 ГБ CUDA_Host buffer.
Введение к спеке
До второй задачи не дошла: модель не запустилась.
Что важно
После выгрузки Gemma 4 модель всё равно не поднялась: рабочей станции не хватило памяти.
Claude
облако · режим проверки
Changelog
Соблюла формат и заметила: смена Button hover с primary-hover на primary-bg похожа на ошибку биндинга.
Введение к спеке
Короче и точнее; сама упомянула различимость при дальтонизме.
Что важно
Единственная модель в пробе, которая посмотрела не только на текст, но и на смысл изменения.
Gemma 4 достаточно для черновика.
Редактура всё равно обязательна. Зато проверяемые факты не «улучшаются» моделью — они приходят из сравнения данных.
Облачная модель заметила смысловую ошибку.
Claude единственная в этой пробе указала на подозрительную привязку. Ради таких замечаний существует отдельный режим проверки.
Выбор класса модели упирается в железо.
Qwen 3.6 не поместилась в память рабочей станции. Независимость от модели на практике означает ещё и выбор модели, которую позволяет запустить доступное железо.
Отдельная находка: модели с режимом рассуждения в Ollama могут вернуть пустой ответ, если весь лимит токенов ушёл на этап рассуждений. Это исправляется запасом токенов в шлюзе, но без проверки выглядит как случайный сбой.
06 Артефакты · форма документации — тоже дизайн
Один слепок Figma формирует код и документацию.
Из одного слепка собираются tokens.css для кода, Storybook для проверки состояний, Notion как человекочитаемая витрина и чат для сигнала команде.
07 Команда
Изменение доезжает до кода, а ответственность остаётся у команды.
Автоматика распределяет сигнал по рабочим поверхностям, но не прячет ответственность внутри модели: у каждого участника команды свой следующий шаг.
Дизайнер
Работает как раньше: компоненты, токены, стили. После фиксации запускает одну команду синхронизации и руками пишет только поведение и правила.
Разработчик
Получает изменение в коде через tokens.css из того же слепка. Расхождение макета и кода больше не требует ручной сверки и переписки.
Лид
Получает changelog и дайджест изменений. Тишина в канале означает, что система стабильна; решение остаётся у человека.
08 Ограничения и рефлексия
Пилот подтвердил работоспособность механики, но не командный эффект.
Что уже работает
Извлечение из Figma, структурированное сравнение, пакет изменений, статусы «актуально» и «устарело», генерация артефактов, Telegram-дайджест и проверка на пилоте.
Что ещё нужно проверить
Воспроизводимый API-прогон с фиксированными версиями моделей, полевая проверка с участием разработчика, экспорт изображений в документы и командное внедрение на одном разделе.
Figma Variables нельзя регулярно получать через REST.
Полное извлечение идёт через плагин Figma; REST остаётся только для проверки версии файла.
Notion переписывает Markdown при записи.
Обновление нужно сопоставлять с фактическим состоянием страницы, иначе точечная замена молча не сработает.
Проверка зависит от канала.
Telegram поддерживает long-polling, а Slack и Mattermost требуют публичный callback URL для интерактивных кнопок.
Периметр, не экономия
При объёме пилота около 10 синхронизаций в день облачная модель — это примерно 0,5–1,5 млн токенов в месяц, то есть единицы долларов. Локальная модель нужна не ради экономии, а чтобы данные дизайн-системы не покидали рабочую станцию.
Вывод
Система ценна не тем, что пишет документацию, а тем, что проводит изменение из Figma до кода и остальных поверхностей, сохраняя явное подтверждение человека.
Факты фиксирует код, интерпретацию предлагает модель, а решение об актуальности остаётся у человека.
Следующий шаг — пилот на одном разделе дизайн-системы с двумя измерениями: сколько вопросов «как правильно» приходит в личку и сколько времени новичку нужно, чтобы собрать компонент по спеке.
