Источник изменений
1правки приходят из FigmaКейс № 05 · R&D · Design systems · 2026
Живая дизайн-документация. Документ не может устареть молча.
Я спроектировал систему, которая ловит изменения в 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 документ получает статус и владельца решения.
Документы
14живых страниц в пилотеПоверхности
4Notion, CSS, Storybook, чатГейт
1проверка человекаСистема связывает изменение в Figma с конкретными страницами, показывает их статус и оставляет решение тому, кто отвечает за дизайн.
Честный статус: рабочий пилот на моей дизайн-системе, ещё не командное внедрение. Поэтому кейс показывает механику и артефакты, а не придумывает бизнес-метрики.
02 Проблема
После передачи в разработку у спеки нет встроенного сигнала «ей можно верить».
После нескольких изменений
Дизайн уезжает вперёд, а спека продолжает выглядеть правдоподобно. Разработчик ловит расхождение раз, второй — и начинает писать автору напрямую.
Генерация текста не создаёт статус
Модель может уверенно дописать мотивацию, которой не было в исходных данных. Проблема не в скорости письма, а в том, что документу нечем показать: «сейчас мне можно верить».
03 Доказательства · от правки до проверки
Одна синхронизация превращает правку в проверяемый пакет изменений.
Прогон A — минимальная петля одного изменения токена. Отдельно ниже показан прогон B: крупное изменение, где сравнение перечисляет весь объём затронутой дизайн-системы.
01Источник
Дизайнер меняет токен в Figma как обычно.
Никаких новых действий ради документации: правка живёт в том же месте, где команда работает каждый день.
02Факт
Система фиксирует одно изменение токена.
В прогоне A система детерминированно фиксирует изменение color/success. Модель не участвует в подсчёте и не получает права переписать факт.
03Сигнал
Устаревший документ становится видимым до чтения таблицы.
Статус «устарело» — не ошибка в консоли, а часть интерфейса документа. Каждый читатель видит, что факты требуют проверки.
04Ревью
Проверка привязана к конкретному изменению.
В сообщении видны ID перехода между слепками и точный состав изменений. Если между проверкой и подтверждением приходит новая правка, старая кнопка не должна закрыть её.
05Результат
После проверки документ снова становится актуальным.
Актуальность — это не дата последней правки. Это состояние, которое можно проверить и объяснить.
Прогон B · крупное изменение
Одна синхронизация показывает, что происходит, когда дизайн-система растёт.
В отдельном демонстрационном сравнении система нашла 18 изменений в 9 документах — среди них 8 новых компонентов и 9 новых использований. Это другой сценарий, не продолжение петли с токеном выше.
Ошибка, которая не дошла до читателя
Модель назвала Page Button «компонентом для CTA».
Ошибка попала в черновик введения, но не в опубликованный документ: заготовка родилась со статусом «устарело» и не могла попасть к читателю без проверки человеком. Именно так система превращает уверенную галлюцинацию в локальную редакторскую правку.
04 Архитектура
Модель получает список изменений, но не решает, что стало истиной.
Код извлекает факты, модель пишет прозу, а источником правды остаётся Markdown в git. Таблицы токенов и статусы не зависят от того, насколько убедительно модель сформулировала ответ.
извлечь→
собрать→
опубликовать→
сравнениеСлепок изменился со времени прошлой синхронизации?затронутые документы помечаются «устарело» · изменения уходят в CHANGELOG
Код
извлекает и рендерит факты детерминированно
Модель
пишет changelog и черновики новых спек
Человек
единственный, кто снимает статус «устарело»
Дисциплина сигнала
Нет изменений — нет сообщения.
Система не создаёт шум ради ощущения активности: при чистом прогоне статус «устарело» не ставится, дайджест не уходит, публикация остаётся атомарной.
Гейт точного изменения
Проверка подтверждает конкретный переход между слепками.
Пакет изменений связывает две версии слепка, список затронутых документов и решение человека. Поэтому система может отклонить старую кнопку, если источник успел измениться ещё раз.
18изменений в большом сравнении
9документов в составе
2ID слепка
1проверка человека
05 Проба моделей · 3 наблюдения
Один промпт показывает три разных ограничения моделей.
Проба нужна не чтобы выбрать «лучшую модель», а чтобы увидеть, где проходит граница доверия к любой из них — и почему факты остаются за кодом. В системе две задачи: записать changelog по отчёту об изменениях и написать введение к спеке. Инструкция просит «1–2 предложения, без воды»; в пробе участвовали gemma4, qwen3.6 и Claude.
Входные изменения
color/success: #237804 → #2d8f06 · новый Status Tag · Button Primary/Hovergemma4
9,6 ГБ · локально · режим черновика
Changelog
Факты верные, но вместо 1–2 предложений модель выдала пост с заголовками и эмодзи.
Введение к спеке
7 с · пригодно для черновика, но с лёгкой водой.
Что важно
Домыслила мотивацию: «обеспечит лучшую контрастность» — этого не было во входных данных.
qwen3.6
23 ГБ · локально · рабочая станция
Changelog
llama-server не смог выделить дополнительные 9,9 ГБ CUDA_Host buffer.
Введение к спеке
До второй задачи не дошла: модель не запустилась.
Что важно
После выгрузки gemma4 модель всё равно не поднялась: рабочей станции не хватило памяти.
Claude
облако · режим проверки
Changelog
Соблюла формат и заметила: смена Button hover с primary-hover на primary-bg похожа на ошибку биндинга.
Введение к спеке
Короче и точнее; сама упомянула различимость при дальтонизме.
Что важно
Единственная модель в пробе, которая посмотрела не только на текст, но и на смысл изменения.
Gemma4 достаточно для черновика.
Редактура всё равно обязательна. Зато проверяемые факты не «улучшаются» моделью — они приходят из сравнения данных.
Облачная модель заметила смысловую ошибку.
Claude единственная в этой пробе указала на подозрительную привязку. Ради таких замечаний существует отдельный режим проверки.
Выбор тира упирается в железо.
Qwen3.6 не влезла в рабочую станцию. Model-agnostic на практике — это ещё и выбор модели, которая помещается в память.
Отдельная находка: reasoning-модели в Ollama могут вернуть пустой ответ, если весь лимит токенов ушёл на размышление. Это лечится запасом токенов в шлюзе, но без проверки выглядит как случайный сбой.
06 Артефакты · форма документации — тоже дизайн
Один слепок становится несколькими рабочими поверхностями.
Из одного слепка собираются Notion для чтения, tokens.css для кода, Storybook для проверки состояний и чат для сигнала команде.
07 Команда
Дизайнер запускает синхронизацию, разработчик читает статус, лид принимает решение.
Автоматика распределяет сигнал по рабочим поверхностям, но не прячет ответственность внутри модели: у каждого участника команды свой следующий шаг.
Дизайнер
Работает как раньше: компоненты, токены, стили. После фиксации запускает одну команду синхронизации и руками пишет только поведение и правила.
Разработчик
Видит статус спеки до чтения и получает tokens.css из того же источника. Расхождение макета и документа перестаёт быть расследованием в личке.
Лид
Получает changelog и дайджест изменений. Тишина в канале означает, что система стабильна; решение остаётся у человека.
08 Ограничения и рефлексия
Пилот доказал механику, но не командный эффект.
Что уже работает
Извлечение из Figma, структурированное сравнение, пакет изменений, статусы «актуально» и «устарело», генерация артефактов, Telegram-дайджест и проверка на пилоте.
Что ещё нужно проверить
Воспроизводимый API-прогон с фиксированными версиями моделей, полевая проверка на разработчике, экспорт изображений в документы и командное внедрение на одном разделе.
Variables не живут в дешёвом REST-поллинге.
Полное извлечение идёт через plugin-канал Figma; REST остаётся только для проверки версии файла.
Notion переписывает Markdown при записи.
Апдейт должен матчиться по фактическому состоянию страницы, иначе точечная замена молча не сработает.
Проверка зависит от канала.
Telegram поддерживает long-polling, а Slack и Mattermost требуют публичный callback URL для интерактивных кнопок.
Периметр, не экономия
При объёме пилота около 10 синхронизаций в день облачная модель — это примерно 0,5–1,5 млн токенов в месяц, то есть единицы долларов. Локальная модель нужна не ради экономии, а чтобы данные дизайн-системы не покидали рабочую станцию.
Вывод
Система ценна не генерацией текста, а тем, что отделяет факт от интерпретации.
Следующий шаг — пилот на одном разделе дизайн-системы с двумя измерениями: сколько вопросов «как правильно» приходит в личку и сколько времени новичку нужно, чтобы собрать компонент по спеке.
