design.md vs Дизайн-токены для AI UI рабочих процессов

Меня зовут Дора. Большую часть недели я провожу внутри агентов программирования и AI-инструментов для UI — Cursor, Claude Code, Stitch и прочего стандартного набора — строю и перестраиваю интерфейсы быстрее, чем успеваю их документировать. Около месяца назад я начала замечать один и тот же файл в каждом втором репозитории, к которому прикасалась: DESIGN.md. Одинаковое название, одинаковая структура — YAML сверху, проза снизу. К третьему проекту я поняла, что это не случайность. Это то, что заменяет tokens.json, который большинство из нас раньше поставляло.

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

design.md против традиционных дизайн-токенов

Под что оптимизирован каждый формат

Дизайн-токены в классическом понимании — это методология. Термин был введён в Salesforce примерно в 2014 году для решения очень конкретной проблемы масштабирования: как синхронизировать цветовое решение между вебом, iOS, Android и четырьмя кодовыми базами, не заводя четыре тикета? Ответом стала независимая от платформы пара «имя — значение», хранящаяся в JSON или YAML и преобразуемая во время сборки в то, что нужно каждой платформе. Эта методология теперь кодифицирована Сообществом дизайн-токенов при W3C, и к концу 2025 года формат DTCG получил стабильную спецификацию v1.

Токены оптимизированы под детерминированное распространение. Hex-код поступает на вход и выходит тем же hex-кодом на каждой платформе, при каждой сборке, всегда. Никакой двусмысленности. Но и никакого нарратива — файл токенов скажет вам primary: #1A1C1E, но не объяснит, почему этот цвет существует и когда его не следует использовать.

DESIGN.md, опубликованный Google Labs с открытым исходным кодом в апреле 2026 года, оптимизирован под другое: предоставить агенту программирования достаточно контекста для принятия решений, которые не охвачены токен-файлом. Это единый markdown-файл с YAML-преамбулой для токенов и прозой ниже для обоснования. Один файл, две аудитории — детерминированная часть для парсеров, нарративная часть для любого LLM, читающего репозиторий.

Вот в чём реальное разделение. Не «старое против нового». Не «JSON против Markdown». Это значения против значений плюс обоснование в одном файле.

Почему AI-агенты создают новые требования

Когда человек реализует дизайн, разрыв между «токен говорит #1A1C1E» и «этому пустому состоянию нужен определённый тон» заполняет сам человек. Он видел файл в Figma. Он присутствовал на брендинговом воркшопе. Он знает, что вторичная кнопка должна ощущаться сдержанной, а не настойчивой.

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

Именно это и решает DESIGN.md. Официальная спецификация на GitHub прямо об этом говорит — токены дают агентам точные значения, проза объясняет им, почему эти значения существуют и как их применять. Формат предполагает обе половины.

Где design.md добавляет ценность

Постоянный нарративный контекст

Что я заметила в первые 48 часов тестирования: один и тот же агент, получив одно и то же задание, генерирует заметно разный результат при наличии прозаического контекста. Не «чуть лучше подобранные цвета». Другие решения о макете, другой регистр текста, другая плотность компонентов. Значения токенов в обоих запусках были идентичны — изменилось то, был ли у агента абзац, говорящий «голос бренда сдержанный и редакционный; предпочитай пространство украшениям».

Это та часть, которую традиционный токен-пайплайн не переносит. DTCG JSON-файл может точно описать --color-primary, но не может сообщить агенту, что этот основной цвет следует использовать экономно. DESIGN.md переносит это суждение в каждый проход генерации — постоянно, без необходимости каждый раз вводить его заново в промпт.

Это работает.

Лучшая согласованность между экранами в рабочих процессах генерации

Во втором тесте я за два дня сгенерировала восемь экранов для одного приложения. С контекстом только из токенов экраны 5–8 начали дрейфовать — та же палитра, но язык макета стал рыхлее. С DESIGN.md дрейф был значительно меньше. Не нулевым. Меньшим.

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

Здесь же DESIGN.md хорошо сочетается с более широким стеком инструкций для агентов — большинство конфигураций теперь ссылаются на него из AGENTS.md вместе с файлами SKILL.md, так что дизайн-система находится в том же контекстном слое, что и остальные постоянные инструкции агента.

Где традиционные токены по-прежнему выигрывают

Два сценария, оба реальных.

Кросс-платформенное распространение за пределами веба. Если вы поставляете одну и ту же дизайн-систему в iOS, Android, React Native-приложение и маркетинговый сайт, пайплайн DTCG через Style Dictionary или Terrazzo по-прежнему остаётся путём наименьшего сопротивления. YAML из DESIGN.md может экспортироваться в DTCG JSON через официальный CLI @google/design.md, но вопрос об источнике истины по-прежнему важен — если ваш граф токенов большой, многотемный и используется не-AI инструментами, хранить DTCG как канонический формат — более чистое решение.

Зрелые дизайн-системы с устоявшимся управлением. Токены — это не просто формат файла. Это методология с десятилетием накопленной практики — примитивные слои, семантические слои, алиасинг, темизация, вся таксономия, которую Натан Кёртис изложил в Tokens in Design Systems. Если ваша команда уже работает таким образом, DESIGN.md не заменяет это. Он располагается поверх или рядом как контекстный слой для агентов. Токены остаются каноническим источником; markdown становится переводом для AI.

Ошибкой было бы воспринимать DESIGN.md как замену токен-пайплайну. Это не так. Это другой слой с другим потребителем.

Система принятия решений для команд, создающих AI UI пайплайны

Когда я решаю, что положить в репозиторий, я снова и снова возвращаюсь к четырём вопросам:

1. Кто читает этот файл? Если основной потребитель — это пайплайн сборки, выдающий CSS, Swift и Kotlin, вам нужны токены в каноническом формате. Если основной потребитель — агент программирования, генерирующий UI по требованию, вам нужен DESIGN.md. Если оба — вы держите оба, позволяя YAML в markdown-файле отражать подмножество токенов.
2. Как часто ваш UI-слой перегенерируется? Команды с низкой частотой (стабильный продукт, редкие новые экраны) получают большую часть ценности от токенов. Команды с высокой частотой (быстрое прототипирование, итерации с агентами, новые экраны каждую неделю) остро ощущают разрыв отсутствующего контекста. Чем выше частота перегенерации, тем больше прозаический слой себя оправдывает.
3. Сколько платформ? Только веб или веб-приоритет с генерацией через агента — DESIGN.md является более простым стеком. Три и более платформы с серьёзным нативным присутствием — сначала токены, DESIGN.md как вторичный артефакт.
4. Задокументировано ли обоснование уже где-то? Если ваши брендинговые гайдлайны, документ о голосе и философия компонентов живут на странице в Notion, которую ни один агент никогда не прочитает, DESIGN.md — это наиболее эффективный шаг, который вы можете сделать в этом квартале. Вы не создаёте новую документацию — вы перемещаете существующую документацию в файл, который агент действительно открывает.

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

Часто задаваемые вопросы

Является ли design.md заменой дизайн-токенов?

Нет. DESIGN.md — это обёртка, содержащая дизайн-токены (в YAML-преамбуле) плюс обоснование вокруг них (в markdown-прозе). Токены внутри него всё ещё являются дизайн-токенами в обычном смысле. Если у вас уже есть токен-файл в формате DTCG, DESIGN.md не заменяет его — он существует как параллельный артефакт для AI-агентов, или вы можете настроить экспорт DTCG JSON из markdown при необходимости.

Почему AI-агентам нужно больше, чем числовые токены?

Потому что большинство запросов на генерацию UI не полностью специфицированы токен-графом. «Сгенерируй страницу с ценами» требует сотен микрорешений — иерархия, плотность, тон, что выделять — которые ни один токен-файл не покрывает. Без нарративного контекста агент заполняет эти пробелы тем, что видел в обучающих данных, что и производит тот универсальный вид, которым делятся большинство AI-сгенерированных UI. Проза в DESIGN.md — это то, что закрывает этот разрыв.

Какие рабочие процессы выигрывают больше всего от design.md?

Три паттерна, которые я видела наиболее окупаемыми:

• Одиночные разработчики и небольшие команды, использующие Cursor, Claude Code или Stitch для создания UI быстрее, чем они успевают его написать вручную.
• Команды дизайн-систем, поддерживающие несколько внутренних продуктов, где согласованность AI-сгенерированных экранов становится реальной проблемой.
• Агентства и контрактные команды, которым нужен единый файл-вставка, кодирующий дизайн-язык клиента для любого агента программирования.

Если ваш рабочий процесс в основном написан вручную с редкой помощью AI, предельная ценность падает.

Когда классической инфраструктуры дизайн-токенов по-прежнему достаточно?

Когда вы не генерируете UI с агентами или когда охват вашей платформы далеко выходит за пределы веба. Тяжёлый нативный мобайл, мультитемные white-label продукты, зрелые практики дизайн-опс — всё это по-прежнему получает больше от экосистемы DTCG, чем от markdown-файла. Они не взаимоисключают друг друга, но если нужно выбрать одно для инвестирования, ответ зависит от того, где реально находится ваше трение генерации.

Заключение

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

Я два месяца использую DESIGN.md в каждом AI-генерационном проекте, который веду. Он остался в рабочем процессе, а это единственный тест, которому я доверяю. Токен-файлы тоже никуда не делись — они по-прежнему делают то, что всегда делали, просто теперь с файлом-сиблингом для аудитории, которой нужно больше, чем просто числа.

Попробуйте сами на каком-нибудь проекте. Два дня расскажут вам больше, чем эта статья.

Предыдущие статьи：

• GitHub Copilot vs Private Coding Assistants
• Claude Code vs Cursor 2026
• MCP in Production: Model Context Protocol Workflows
• Agentic Workflow Tool Wiring Patterns & Pitfalls
• Claude Code Agent Harness Architecture