Дизайн-система словами

Первый экран агент сделал синим со скруглёнными кнопками. Второй, через день, — фиолетовым и с острыми углами. Третий — вообще другим шрифтом. Каждый по отдельности нормальный, вместе — солянка. Причина не в том, что агент плохой, а в том, что стиль ты каждый раз объяснял заново, по памяти и по-разному. Лечится это одним файлом: описываешь свой дизайн-язык словами — цвета, шрифты, отступы, тон — один раз, и агент читает его перед каждой задачей. В этой статье разберём, как собрать такой файл-контракт и почему он убирает основную массу разъезжающегося стиля.

Короткий ответ

Держи один текстовый файл, который словами описывает твой дизайн: палитру, шрифты, шкалу отступов, радиусы, тон. Агент читает его и применяет везде — как читает CLAUDE.md с правилами проекта. Вместо того чтобы каждый раз заново пересказывать стиль (и каждый раз чуть иначе), ты один раз фиксируешь его как контракт. Новый экран агент делает уже по этому контракту, а не по свежей фантазии. Файл можно назвать DESIGN.md, а можно положить токены прямо в CLAUDE.md проекта или в CSS-переменные :root — суть одна.

Проблема: каждый экран разъезжается по стилю

Без единого источника стиля агент опирается на то, что ты сказал в этой конкретной сессии. А говоришь ты каждый раз немного по-разному: сегодня «сделай современно», завтра «в спокойных тонах», послезавтра вообще забыл упомянуть шрифт. Агент честно заполняет пробелы — своим дефолтом. Отсюда и результат: двадцать экранов в двадцати оттенках одной идеи.

Проблема усугубляется с масштабом. Один экран — не беда, поправишь руками. Но когда страниц становится много, ручная синхронизация стиля превращается в отдельную работу: тут кнопка другого цвета, там заголовок другого размера, здесь отступы шире. Ты тратишь время не на дизайн, а на то, чтобы всё выглядело как одно целое.

Решение: один файл-контракт

Идея простая. Стиль — это не то, что нужно держать в голове и пересказывать, а то, что нужно записать один раз. Ты заводишь один текстовый файл, где своим словами описан дизайн-язык проекта. Это и есть контракт: агент, прежде чем что-то рисовать, читает его и делает по нему.

Дальше ты не объясняешь стиль на каждой задаче — ты ссылаешься на файл. «Сделай карточку» превращается для агента в «сделай карточку по нашему дизайну», где «наш дизайн» — это конкретные цвета, шрифты и отступы из файла, а не догадка. Один источник правды вместо двадцати импровизаций.

Ключевая мысль: дизайн-система словами — это не код и не жёсткая рамка, которую агент не может нарушить. Это контракт. Ты всё равно смотришь результат и правишь, но основная масса разъезда — «почему эта страница другого стиля» — исчезает, потому что агент больше не выдумывает стиль каждый раз заново.

Что в него положить

Файл должен называть, а не намекать. Не «спокойные цвета», а конкретные значения. По пунктам:

• Палитра. Акцентный цвет, фон, цвета текста (основной и приглушённый), цвет границ. Конкретными значениями, а не словами «синеватый».
• Шрифты. Один для заголовков, один для текста. Больше двух семейств на старте обычно лишнее. Назови их прямо.
• Отступы. Шкала — набор допустимых значений (например, шаг в 4 или 8 пикселей и кратные ему), чтобы отступы не были случайными.
• Радиусы. Одно-два значения скругления углов. Это то, что задаёт «характер» интерфейса — острый он или мягкий.
• Тон. Как звучат тексты интерфейса — сдержанно или живо, на «вы» или на «ты», строго или с юмором. Дизайн — это не только цвета.

Правило: если параметр можно назвать числом или конкретным значением — называй. Чем меньше агенту приходится додумывать, тем меньше разъезд.

Как агент его применяет

Механика ровно та же, что у CLAUDE.md с правилами проекта. Агент читает файл в начале работы и держит его как контекст. Когда ты просишь новый элемент, он опирается не на общий вкус «как обычно делают», а на твои значения: берёт акцент из палитры, заголовок ставит нужным шрифтом, отступы — из шкалы, углы скругляет заданным радиусом.

Поэтому и файл удобно держать там же, где живут правила проекта, — либо отдельным DESIGN.md, на который ты ссылаешься, либо прямо в CLAUDE.md, либо в виде CSS-переменных :root, которые агент переиспользует в каждой странице. Форма вторична; важно, что источник один и агент его видит.

Пример токенов

Как это выглядит на практике — маленький блок дизайн-токенов, описанный как переменные, которые агент переиспользует везде:

/* Тёмная тема */
:root {
  --bg:          #0F1115;
  --surface:     #171A21;
  --text:        #E6E9EF;
  --muted:       #9AA3B2;
  --accent:      #4F8CFF;
  --border:      #242A33;
  --font-head:   "Inter Tight", system-ui, sans-serif;
  --font-body:   "Inter", system-ui, sans-serif;
  --radius:      12px;
  --max-width:   720px;
}

/* Светлая тема */
:root[data-theme="light"] {
  --bg:          #FFFFFF;
  --surface:     #F6F7F9;
  --text:        #0F1115;
  --muted:       #5B6472;
  --accent:      #2563EB;
  --border:      #E4E7EC;
}

Именно так тематизированный сайт держит два десятка страниц визуально одинаковыми: цвета, шрифт, радиус и ширина заданы один раз, а каждая новая страница просто ссылается на эти переменные. Меняешь акцент в одном месте — он меняется на всех страницах разом. Это и есть контракт в действии: не «покрась кнопку в синий», а «кнопка использует --accent».

Связь со Stitch и DESIGN.md

Это не самодельный трюк — так работают и специализированные инструменты. Например, Google Stitch автоматически генерирует файл DESIGN.md как единый источник правды: складывает туда цвета, типографику, общий вид (look & feel) и потом скармливает этот файл обратно как контекст, чтобы новые элементы оставались согласованными со стилем. То есть тот же принцип — один файл описывает дизайн-язык, и всё новое сверяется с ним.

Идея легко обобщается за пределы Stitch: тебе не нужен отдельный инструмент, чтобы завести такой файл руками. DESIGN.md, блок в CLAUDE.md или набор CSS-переменных — механика одна: один текст, названные значения, агент читает и применяет.

Где предел

Честно про границы. Дизайн-система словами — это контракт, а не рельсы. Агент может от него отойти: неверно понять формулировку, применить значение не туда, придумать что-то сверх описанного. Поэтому файл не отменяет ревью — ты всё равно смотришь результат глазами. Но он снимает основную боль: без него разъезжается почти каждый экран, с ним — разве что мелочи на краях. Контракт снимает основную массу дрейфа, остатки ловишь ты. Это огромная разница по сравнению с тем, чтобы объяснять стиль заново на каждой задаче.

FAQ

Это то же самое, что дизайн-система у больших компаний?

По духу — да, по масштабу — нет. Большие дизайн-системы — это библиотеки компонентов, токенов и правил на сотни страниц. Здесь речь о минимальном варианте: один текстовый файл с палитрой, шрифтами, отступами и тоном. Этого достаточно, чтобы твои экраны перестали разъезжаться.

DESIGN.md или прямо в CLAUDE.md?

Как удобнее. Отдельный DESIGN.md чище, если дизайн-правил много и хочется держать их отдельно от прочих инструкций. Блок прямо в CLAUDE.md проще, если правил немного. Агент читает и то, и другое — важно, чтобы источник был один и он на него ссылался.

А если стиль со временем меняется?

Правишь файл — и всё новое едет уже по обновлённым значениям. В этом и смысл единого источника: поменял акцентный цвет в одном месте, а не искал его по двадцати страницам. Старое, если нужно, перегенерируешь по новому контракту.

Обязательно писать CSS-переменные, или можно словами?

Можно словами — «акцент такой-то, заголовки таким-то шрифтом, отступы кратны восьми». CSS-переменные удобны тем, что агент их напрямую переиспользует в верстке, но сам контракт может быть и чисто текстовым описанием. Главное — конкретика вместо намёков.

Итог

Один файл, который словами описывает твой дизайн-язык — палитру, шрифты, отступы, радиусы, тон, — превращает разрозненные экраны в единый стиль. Агент читает его как CLAUDE.md и применяет везде, вместо того чтобы выдумывать стиль заново на каждой задаче. Форма свободная: отдельный DESIGN.md, блок в CLAUDE.md или CSS-переменные :root. Именно так инструменты вроде Google Stitch держат согласованность — через автогенерируемый DESIGN.md как единый источник правды, и ту же идею ты собираешь руками за пять минут. Это контракт, а не рельсы: ревью он не отменяет, но основную массу разъезда убирает.

Как устроен главный файл-правил, в который удобно положить и дизайн-токены, — в гайде CLAUDE.md — правила и память.