Как написать DESIGN.md, чтобы ИИ сделал сайт в вашем стиле

Вы просите ИИ сделать спокойный сайт для небольшой студии. На первом экране появляются градиенты, крупные карточки и случайный шрифт. После нескольких правок главная страница нравится вам, но следующая снова выглядит иначе. Агенту не хватает записанных решений, на которые можно опереться при каждой новой задаче.

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

В самом простом случае это Markdown-файл с правилами оформления проекта. У Google Labs есть открытая спецификация DESIGN.md: она соединяет машиночитаемые токены в YAML в начале файла с объяснениями в Markdown. Спецификация имеет статус alpha и может меняться. Актуальные правила опубликованы в репозитории проекта.

Токен задаёт значение, например цвет основного действия. Текст объясняет, где этот цвет использовать и когда от него отказаться. Одного списка HEX-кодов недостаточно: одинаковая палитра допускает десятки разных композиций.

YAML-блок полезен для проверки и экспорта токенов. Он не нужен для того, чтобы человек или агент прочитал обычный Markdown. Если вы выбираете формат Google и его CLI, следуйте его текущей схеме. Произвольный список пожеланий с названием DESIGN.md не становится совместимым со всеми инструментами автоматически.

Файл также не заменяет задание на продукт. В задании остаются аудитория, смысл страницы и действия пользователя. В DESIGN.md фиксируются правила визуального языка и поведения элементов.

Начните с экрана, где пользователь принимает главное решение: например, выбирает услугу и отправляет заявку. Запишите, кому он нужен и что человек должен понять прежде, чем нажать кнопку. Без этого легко обсуждать оттенки и забыть о назначении страницы.

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

Пример заметки: «Из первого референса берём широкие поля и спокойный фон. Из второго берём понятное выделение выбранной услуги. Не переносим фотографии, тексты, логотип и анимацию». Это описание приёмов, а не разрешение использовать чужие материалы.

Если проекта ещё нет, сначала определите его минимальный результат. Для общего понимания последовательности работы можно открыть базу статей «Человека 2.0» и выбрать материал под текущую задачу.

Вместо «дорого и минималистично» запишите решения, которые можно увидеть и проверить.

• Побольше воздуха: Между основными разделами 64 px на широком экране; на узком 32 px
• Выделить важное: Основное действие использует синий фон и белый текст; второстепенное выглядит спокойнее
• Сделать читабельно: Основной текст 16 px; длинный абзац ограничен по ширине; текст не помещается внутрь изображения
• Сделать удобно на телефоне: Блоки переходят в одну колонку; меню и форма доступны с клавиатуры; горизонтального прокручивания страницы нет

Эти числа являются примером для учебного проекта, а не универсальной нормой. Меняйте их после проверки реального текста и экранов. Для цветовых пар ориентируйтесь на WCAG 2.2, критерий контраста текста: обычно требуется 4,5:1, для крупного текста действует порог 3:1. Одного успешного расчёта контраста недостаточно для полной оценки доступности.

Схематический пример: пожелание «больше воздуха» превращается в проверяемое расстояние между элементами. Значение 32 px выбрано для учебного проекта, а рисунок выполнен не в масштабе. Это не снимок интерфейса инструмента.

Создайте файл DESIGN.md в папке проекта через текстовый редактор. Если файл уже есть, сначала сохраните его копию и сравните новые правила со старыми. Ниже учебный пример для сайта студии. Скопируйте два блока ниже в один файл: сначала YAML вместе со строками ---, затем Markdown.

---
version: alpha
name: Studio Example
colors:
  primary: "#2C44F5"
  ink: "#2C2C2C"
  surface: "#FFFFFF"
typography:
  body:
    fontFamily: Arial
    fontSize: 1rem
    lineHeight: 1.5
spacing:
  sm: 8px
  md: 16px
  lg: 32px
rounded:
  sm: 8px
components:
  button-primary:
    backgroundColor: "{colors.primary}"
    textColor: "{colors.surface}"
    rounded: "{rounded.sm}"
    padding: 12px
  body:
    backgroundColor: "{colors.surface}"
    textColor: "{colors.ink}"
    typography: "{typography.body}"
---

После закрывающей строки --- добавьте обычный Markdown:

## Overview
Сайт небольшой студии. Главная задача: выбрать услугу и отправить заявку.
Оформление спокойное; фотографии работ важнее декоративных эффектов.

## Colors
Синий выделяет основное действие. Основной текст тёмный на белом фоне.
Не используйте цвет как единственный способ сообщить об ошибке.

## Typography
Основной текст 16 px при базовом размере браузера 16 px.
Сохраняйте возможность увеличения текста пользователем.

## Layout
Ширина содержимого не более 1120 px. На узком экране одна колонка.
Поля на телефоне 16 px. Между разделами 32 px, на широком экране 64 px.

## Components
Кнопка имеет обычное состояние, наведение, видимый фокус и блокировку.
У поля ввода есть подпись, понятная ошибка и сохранённое введённое значение.

## Do's and Don'ts
Используйте реальные фотографии с разрешением на использование.
Не добавляйте вымышленные отзывы, показатели и логотипы клиентов.
Не меняйте палитру и шрифт на каждой странице.

Для известных разделов спецификация задаёт порядок: Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Do's and Don'ts. Ненужные разделы можно пропустить. Состояния компонентов в YAML при необходимости описывают отдельными записями, например button-primary-hover, а не вложенным объектом hover.

В примере указан Arial; его наличие зависит от операционной системы. Для сайта задайте проверенный запасной sans-serif и проверьте отображение в целевых браузерах. Для фирменного шрифта отдельно проверьте лицензию, наличие кириллицы, нужных начертаний и фактическую загрузку в браузере. Название шрифта в документе само по себе его не подключает.

Укажите файл явно. Не рассчитывайте, что любой инструмент автоматически обнаружит DESIGN.md.

Прочитай DESIGN.md в корне проекта. Сначала перечисли правила, которые применишь к главному экрану, и сообщи о противоречиях. Затем реализуй только этот экран. Не меняй палитру, шрифты и смысл текста без согласования. Покажи результат на широком и узком экране, а найденные отклонения перечисли отдельно.

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

Для этого раздела нужны установленный Node.js и npm. Команды выполняются в папке с учебным DESIGN.md. npx загружает и запускает сторонний пакет, поэтому проверяйте его имя и не выполняйте команды из случайных сообщений в рабочем проекте. Для воспроизводимости здесь закреплена версия 0.4.0, проверенная 18 сентября 2026 года. Показанные команды воспроизведены в Unix-оболочке на Linux; для PowerShell на Windows запуск и пути проверьте отдельно, одинаковый результат там не подтверждён.

npx -y @google/design.md@0.4.0 lint DESIGN.md

Ожидайте JSON с результатами проверки. Код завершения 0 означает отсутствие ошибок, но предупреждения при этом возможны. В нашем примере получен результат без ошибок. Изучайте конкретные findings, а не только код завершения. CLI проверяет файл и некоторые отношения токенов; он не видит вашу страницу, не оценивает смысл текста и не заменяет проверку браузера.

Для передачи токенов в другой инструмент можно выполнить экспорт:

npx -y @google/design.md@0.4.0 export --format dtcg DESIGN.md

Команда выводит JSON в терминал. Она сама не внедряет токены в сайт. Сохранение результата и подключение к сборке зависят от проекта. Чтобы сравнить две версии файла, используйте:

npx -y @google/design.md@0.4.0 diff DESIGN.md DESIGN-v2.md

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

Если появляется сообщение о ненайденном файле, проверьте папку запуска и точное имя. Если пакет не загружается, проверьте доступ к npm и настройки используемого реестра. Не отключайте проверки TLS и не подставляйте неизвестный зеркальный адрес ради запуска.

Схематическое сравнение двух проверок: lint анализирует файл DESIGN.md, а страницу нужно отдельно открыть в браузере. Успешный lint не подтверждает внешний вид и удобство страницы. Это иллюстрация, а не снимок интерфейса CLI.

Откройте страницу хотя бы при ширине 360, 768 и 1440 CSS-пикселей. Это контрольные размеры для примера, а не полный список устройств. Проверьте, что основной текст читается, кнопки не перекрываются, изображение не скрывает важную часть, а строка меню не выталкивает страницу за край.

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

Сравните результат с каждым правилом DESIGN.md. Если правило неверно для задачи, измените документ и код вместе. Если правило полезно, но агент его проигнорировал, исправьте реализацию. Не переписывайте документ только ради того, чтобы объявить случайный результат правильным.

Достаточно ли одного DESIGN.md для красивого сайта?

Нет. Он хранит решения, но качество зависит от содержания, выбранных референсов, реализации и проверки. Файл полезен, когда команда действительно обращается к нему и обновляет вместе с интерфейсом.

Можно ли написать весь документ по-русски?

Объяснения и правила можно написать по-русски. Для совместимости со спецификацией сохраните поддерживаемые имена YAML-полей и известных разделов. Проверяйте итог конкретной версией инструмента.

Нужно ли описывать все компоненты заранее?

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

У вас есть сохранённый DESIGN.md, понятные результаты lint, один реализованный экран и список проверок в браузере. Все найденные отклонения исправлены либо явно записаны как оставшаяся работа. На следующем экране агент использует те же решения, а вы можете объяснить, почему они подходят задаче.

Следующий шаг: заполните пример под свой проект и проверьте один экран. Если хотите посмотреть, как устроена практическая работа с ИИ в «Человеке 2.0», откройте страницу среды. Содержание и условия смотрите на самой странице; этот гайд не обещает отдельного скачивания или доступа по переходу.

Проверено 18 сентября 2026 года. Технические команды стоит пересмотреть через 30 дней и при смене версии CLI.

• Репозиторий DESIGN.md и руководство CLI.
• Полная спецификация.
• Обзор DESIGN.md в Stitch.
• WCAG 2.2: минимальный контраст.
• WCAG 2.2: reflow.