Как сохранить стиль сайта в design.md и передать его ИИ

Практикум Романа Ботана · Автомато

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

Результат работы: Документ стиля с проверяемыми значениями.

Материал рассчитан на последовательную работу. Откройте исходники рядом со статьёй, выполняйте запросы по одному и сверяйте промежуточный результат. Содержание поможет вернуться к нужному этапу.

Какую задачу решает разбор дизайна

Представьте рабочую ситуацию. У компании уже есть сайт, а сейчас нужно добавить страницу услуги, личный кабинет или форму заявки. Один подрядчик делает большие круглые кнопки, второй использует другие оттенки, третий выбирает похожий шрифт. Каждый экран по отдельности выглядит приемлемо, но вместе они создают ощущение нескольких разных продуктов. Руководителю приходится согласовывать одни и те же мелочи, хотя основные решения когда-то уже были приняты.

DESIGN.md помогает собрать эти решения в одном текстовом файле. В нём описывают цвета, шрифты, отступы, формы, состояния элементов и правила компоновки. Такой документ удобно передавать дизайнеру, разработчику или ИИ-агенту перед созданием следующего экрана. Он становится рабочим источником договорённостей: какой цвет отвечает за главное действие, как выглядит второстепенная кнопка, какой ширины текстовая колонка.

Что будет на выходе

В этом практикуме мы разберём процесс получения двух материалов: файла DESIGN.md с правилами и страницы design-preview.html с их наглядным применением. Текст позволяет понять логику, а превью позволяет увидеть, как правила работают вместе. Для бизнеса полезны оба результата: в документе проще согласовать ограничения, на странице проще заметить ошибки.

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

Мы будем рассматривать два учебных примера: восстановление правил собственного сайта сервисной компании и подготовку нового раздела интернет-магазина. Числа в примерах иллюстрируют метод. Они не являются измерениями реального сайта или обещанием результата. После прохождения руководства у вас будет понятный порядок действий, критерии качества и промпты для самостоятельного запуска.

Как устроен путь от страницы до документа

В исходном подходе Design MD Extractor агент получает адрес сайта, изучает доступные стили и формирует описание визуальной системы. Это полезная механика, если разделить её на несколько проверяемых этапов. Сначала определяют границы исследования, затем собирают наблюдения, после этого группируют повторяющиеся решения и только потом записывают правила.

Последовательность действий: Страницы и состояния → Наблюдения и измерения → Правила DESIGN.md → Проверенное превью.

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

Второй этап связан с доказательствами. Агент может увидеть значение в CSS, получить вычисленный стиль элемента в браузере или оценить размер по изображению. Эти способы дают разную уверенность. Цвет из вычисленного стиля конкретной кнопки надёжнее приблизительной оценки по скриншоту. При этом даже точное значение ещё надо связать с назначением: синий оттенок может относиться к ссылке, декоративной иллюстрации или временному баннеру.

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

Четвёртый этап проверяет систему на реальном содержании. Если заголовок на русском языке занимает четыре строки, а карточка начинает разваливаться, надо исправлять правило или область его применения. Хорошая документация выдерживает длинные названия, короткие описания, ошибку ввода и узкий экран. Именно это делает её пригодной для следующего проекта.

Подготовка: что дать агенту до анализа

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

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

Минимальный комплект исходных данных

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

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

Подготовь разбор дизайна для новой страницы услуги. Исследуй эти страницы: [ссылки]. Сначала сообщи, какие страницы и состояния доступны твоим инструментам. Собери подтверждённые значения, отдельно отметь оценки по изображению и вопросы. Используй приложенный бренд-гайд как приоритетный источник. Пока ничего не меняй на сайте. Результат: проект DESIGN.md и перечень элементов для design-preview.html. Сфокусируйся на цветах, типографике, отступах, кнопках, карточках и форме заявки.

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

Как собирать значения и отмечать уверенность

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

CSS-переменная — именованное значение, которое удобно использовать в нескольких местах. Например, --color-action может задавать цвет основного действия. Имя помогает понять замысел, однако итоговый цвет конкретного элемента зависит от применённых правил. При проверке важно видеть и исходное имя, и фактическое значение в выбранном состоянии. Механика переменных описана в документации MDN.

Для каждого значимого наблюдения полезно сохранять короткую запись: элемент, страница, состояние, значение, способ получения. Например: «Основная кнопка; страница услуги; обычное состояние; фон #225E4A; вычисленный стиль браузера». Такая запись позволяет вернуться к источнику, если дизайнер обнаружит расхождение.

Три уровня уверенности

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

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

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

Цвета: назначение важнее размера палитры

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

В исходном материале предлагается набор примерно из тридцати пяти токенов в духе Material Design. Такой набор может быть полезен как схема организации, однако конкретному сайту может понадобиться другое количество. Если в проекте нет третьего акцентного цвета или отдельной инверсной поверхности, создавать их ради заполнения шаблона бессмысленно. Каждому токену нужна роль и наблюдаемый пример применения.

Как назвать цвет

Название primary удобно только при понятном определении. В одном проекте оно означает фирменный цвет, в другом — фон основной кнопки. Лучше прямо записать: «Основное действие: запись на консультацию и подтверждение формы». Для текста поверх такого фона выделяют отдельную роль, например on-primary. Это помогает рассматривать сочетание целиком.

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

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

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

После такого запроса владелец проекта получает набор решений с понятными назначениями цветов. Каждое решение можно проверить и принять перед реализацией.

Типографика: как сохранить характер и читаемость

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

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

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

Почему важны русский текст и запасной шрифт

Шрифт может не содержать нужных кириллических символов. Тогда браузер подставит другой, и слово будет выглядеть иначе. Проверяйте именно будущий язык сайта: длинное название услуги, цифры цены, знак рубля, короткую подпись кнопки. Латинский пример способен скрыть проблему.

Уточните условия использования шрифта. Факт присутствия файла на чужом сайте не даёт основания переносить его в новый продукт. Для собственного проекта используйте разрешённый шрифт и предусмотрите запасное семейство. Если превью должно работать без интернета, удалённое подключение Google Fonts создаёт зависимость: на другом компьютере шрифт может не загрузиться.

В документе полезно разделить две вещи: подтверждённое семейство в исходном сайте и согласованное семейство для реализации. Если лицензию или файл пока не удалось получить, честно обозначьте временную замену. Так команда понимает, почему превью немного отличается, и не принимает временный вариант за окончательный.

Попросите агента показать один и тот же текст всеми уровнями. По такому образцу быстро видно, есть ли различие между заголовком раздела и карточки, достаточно ли воздуха и сохраняется ли читабельность при длинном содержании.

Отступы, сетка, формы и глубина

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

Сначала измерьте несколько повторяющихся расстояний: внутри кнопки, внутри карточки, между карточками, между заголовком и текстом, между секциями. Затем проверьте, можно ли свести их к небольшой шкале. Например, встречаются 8, 16, 24 и 32 пикселя. Это основание предложить кратный шаг, но одиночное расстояние 22 пикселя не следует автоматически округлять: оно может быть осмысленным исключением.

Ширина контейнера и колонок относится к правилам макета. Опишите максимальную ширину основного содержимого, боковые поля на узком экране, число колонок карточек и момент перехода к одной колонке. Если точные пороги недоступны, укажите наблюдаемые размеры окна и результат. Формулировка «на проверенной ширине 390 пикселей карточки стоят в одну колонку» точнее универсального обещания об адаптивности.

Скругления и тени

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

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

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

Компоненты и состояния: собираем рабочий язык интерфейса

Токены описывают отдельные значения, а компоненты связывают их в повторяемые элементы. Для небольшой страницы достаточно документировать кнопки, ссылки, карточки, поля ввода, уведомления и бейджи. Каждому компоненту нужны назначение, структура, допустимые варианты и состояния.

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

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

Пример описания карточки

«Карточка услуги содержит название, короткое пояснение, цену при наличии утверждённой цены и ссылку на подробности. Внутренний отступ одинаковый со всех сторон. Заголовок может занимать несколько строк. Изображение добавляется только для услуг, где оно помогает выбору. Основная кнопка остаётся на уровне всей страницы». Это описание уже задаёт поведение макета, хотя в нём мало технических терминов.

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

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

Структура DESIGN.md: машинные значения и человеческие объяснения

В начале файла удобно разместить служебный блок YAML. Он хранит название проекта, дату проверки и ключевые значения в предсказуемом виде. После него идут обычные текстовые разделы. Такой формат подходит для совместной работы человека и инструмента, если заранее согласовано, как именно инструмент читает этот файл.

Учебный фрагмент может выглядеть так:

---
name: Учебный сервис
status: draft
colors:
  action: '#225e4a'
  on-action: '#ffffff'
  background: '#f7f6f2'
typography:
  body:
    family: system-ui
    size: 16px
    line-height: 1.5
spacing:
  small: 8px
  medium: 16px
  large: 24px
---

Сам по себе YAML не превращается автоматически в настройки любого конструктора. У принимающего инструмента должна быть понятная схема или инструкция преобразования. Поэтому сначала проверьте короткий фрагмент на одном компоненте, затем переносите всю систему. Это особенно полезно при работе с CSS-переменными, конфигурацией стилизации или библиотекой компонентов.

Семь основных содержательных разделов

После служебного блока опишите характер бренда, цвета, типографику, макет и расстояния, глубину, формы и компоненты. В каждом разделе соединяйте правило с примером. Фраза «интерфейс современный и чистый» слишком мало помогает исполнителю. Фраза «широкие светлые поля, один акцент на главном действии, короткие карточки с заметными заголовками» уже объясняет наблюдаемую структуру.

Добавьте область применимости: какие страницы исследованы, какие размеры экрана проверены, какие состояния доступны. Там же перечислите открытые вопросы. Документ с явно обозначенными пробелами легче развивать, чем текст с уверенными формулировками обо всём продукте.

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

Как собрать и проверить design-preview.html

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

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

Если страница заявлена как автономная, проверяйте все зависимости. Изображение, встроенное в файл, доступно без сети, но удалённый шрифт или библиотека могут оставаться внешними. Слово «автономный» должно описывать проверенное поведение. Для внутреннего просмотра иногда достаточно системных шрифтов и простого HTML с CSS.

Последовательность действий: Токены и компоненты → Реальные длины текста → Узкий и широкий экран → Исправленные правила.

Собери design-preview.html по согласованному DESIGN.md. Покажи палитру, шкалу текста, кнопки, карточки, поля и экран новой услуги. Используй длинные русские названия и пример ошибки формы. Укажи все внешние зависимости. Если возможно в текущей среде, сделай файл автономным и проверь его без сети. Отдельно сообщи, какие размеры окна и состояния действительно проверены. Новые дизайнерские решения перечисли для согласования.

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

Учебный бизнес-пример: страница сервисной компании

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

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

Пошаговая работа

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

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

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

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

Учебный бизнес-пример: новый раздел магазина

Во втором примере интернет-магазин добавляет категорию товаров с длинными техническими названиями. На главной всё выглядит аккуратно, однако в каталоге встречаются три вида карточек и разные подписи наличия. Команда хочет привести новый раздел к понятной структуре и использовать удачные существующие решения.

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

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

Образец решения

«В карточке название допускает три строки. Цена и единица продажи показываются рядом. Отсутствие товара сопровождается ясной подписью. Основное действие зависит от доступного сценария заказа. Фильтры сохраняют читаемые названия на узком экране. Цвет наличия сопровождается текстом». Это описание связывает визуальную систему с торговыми данными.

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

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

Результат передают разработчику вместе с требованиями к данным. Тогда визуальная проверка и проверка каталога поддерживают друг друга: команда знает и внешний вид, и то, какие значения компонент должен корректно принимать.

Частые ошибки и порядок исправления

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

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

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

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

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

Как давать обратную связь

Формулируйте замечание через наблюдение и ожидаемое поведение: «При ширине 390 пикселей кнопка выходит за карточку; она должна помещаться вместе с длинной подписью». Это лучше направляет исправление, чем общая оценка «выглядит странно». После правки проверяйте конкретный сценарий и близкий к нему пример, чтобы убедиться, что изменение выдерживает разные данные.

Упражнение, ответ и следующий запуск

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

Попросите агента сначала показать наблюдения. Затем согласуйте четыре цветовые роли, три текстовые роли, шкалу отступов и два компонента. Соберите превью с длинным названием услуги и ошибкой поля. Проверьте широкий и узкий экран. Если инструменты не позволяют измерить стили, явно обозначьте визуальные оценки и ограничьте выводы.

Образец ответа

Успешное выполнение выглядит так: «Исследованы две страницы. Цвет основной кнопки подтверждён вычисленным стилем. Шрифт кириллицы проверен. Радиус карточки измерен. Состояние успешной отправки недоступно и осталось открытым вопросом. В превью длинный заголовок переносится без обрезания, ошибка формы читается, кнопка помещается на узком экране. Для переноса в проект требуется сопоставить имена токенов с используемыми компонентами».

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

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

Передача правил следующему исполнителю

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

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

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

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

Как оценить пользу процесса

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

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

Источники и границы материала

Методическая основа: предоставленный исходник «DESIGN.md Extractor: разбираем дизайн любого сайта с Claude». Сохранены извлечение визуальных токенов, YAML-блок, семь описательных разделов, HTML-превью и передача правил в дальнейшую сборку. Уточнены ограничения доступа, полноты извлечения и автономности. Техническая справка: CSS custom properties, MDN. Проверка источника выполнена 20 сентября 2026 года. Учебные примеры разработаны для этого руководства.

Продолжить практику

• Markdown для работы с ИИ: инструкции, контекст и шаблоны
• Как превратить вопросы клиентов в полезный пост-карусель

Автор — Роман Ботан, Автомато. Практикумы и обучение · Новые разборы в канале @aibotan47.