Почему сайты, созданные ИИ, выглядят одинаково и как убрать AI-slop
Практический разбор шаблонного ИИ-дизайна: как задать визуальную систему, проверить адаптивность и доступность и довести сайт до узнаваемого результата.
Человек 2.0Что забрать из статьи
- 1Явные правила и исходные материалы помогают уменьшить случайные решения в дизайне.
- 2Визуальная спецификация и реальные материалы уменьшают случайность лучше, чем просьба «сделать красивее».
- 3Финальный дизайн проверяют на мобильных ширинах, доступности, стабильности загрузки и реальном CTA.
Почему ИИ снова и снова выдаёт один и тот же сайт
Вы просите ИИ сделать современный лендинг; и через несколько минут получаете знакомую картину: крупный заголовок слева, сияющий объект справа, ряд одинаковых карточек, мягкий градиент и кнопка с общим призывом. Такой результат может быть аккуратным, но он почти ничего не говорит о компании и легко заменяется сайтом из другой ниши.
Одна из практических причин повторяемости: в задании не хватает решений о бренде, композиции и содержании. Агенту приходится выбирать их самому, и результат может оказаться похожим на привычные шаблоны. Это рабочая гипотеза для разбора конкретной страницы, а не доказательство того, как устроено обучение любой модели.
Начните с постановки задачи и проверки результата. Для каждого решения должно быть объяснение: сетка помогает прочитать предложение, цвет выделяет действие, иллюстрация показывает продукт. Градиент и карточки можно оставить, если они помогают этой задаче.
Как распознать AI-slop до публикации
Начните с простого теста: уберите логотип и название. Если страницу можно без потерь отдать салону, финтех-сервису или курсу, у неё нет собственной визуальной логики.
Частые признаки; взаимозаменяемая обложка, одинаковые скруглённые карточки, декоративные графики без данных, случайные светящиеся сферы, абстрактный робот, чрезмерный градиент, подписи-пустышки и анимация без функции. Сам по себе ни один приём не является ошибкой. Ошибка возникает, когда он не связан с задачей пользователя.
Второй тест; смысловой. Для каждого блока закончите фразу: «После этого блока человек сможет…». Если ответа нет, блок либо декоративный, либо не завершён. Уберите его, объедините с соседним или добавьте доказательство.
Шаг 1. Зафиксируйте визуальные правила
Фразы «сделай красиво» и «сделай премиально» оставляют модели слишком широкое поле. Вместо них зафиксируйте типографику, палитру, ритм отступов, радиусы, плотность, поведение кнопок, принцип иллюстраций и запреты. Такая спецификация может жить в DESIGN.md, дизайн-токенах или кратком брифе; важно, чтобы правила были явными и повторяемыми.
Хорошее правило проверяется. Например: один акцентный цвет; не более двух типов карточек; крупный заголовок занимает не больше заданной ширины; изображения имеют конкретную роль; основной CTA остаётся видимым на узком экране. Это лучше, чем набор эпитетов.
Если проект ведут несколько агентов, заранее договоритесь об их ролях. В статье «Человек 2.0» разобрана связка Codex и Hermes: https://human20.app/articles/codex-hermes-workflow. В каталоге также есть описание Ui Ux Pro Max Skill: https://human20.app/content/skill-ui-ux-pro-max-skill. Карточка знакомит с назначением инструмента, но не заменяет проверку вашего макета.
Формат DESIGN.md описан в открытом репозитории: https://github.com/google-labs-code/design.md. Он сочетает значения дизайн-токенов и текст с объяснением решений. Запишите, какие правила обязательны, а какие служат примером. Само наличие файла не доказывает, что агент прочитал его или что страница ему соответствует.
Шаг 2. Подкрепите правила реальными материалами
Референс нужен не для копирования. Он помогает показать пропорции, иерархию и уровень плотности. Возьмите несколько сильных примеров и подпишите, что именно переносится: масштаб заголовка, спокойный фон, способ показать товар, ритм между секциями. Отдельно перечислите, что переносить нельзя.
Дайте модели настоящие факты: фотографии продукта, интерфейс, данные, отзывы, схему процесса. Когда вместо доказательств остаются только абстрактные пиктограммы, страница быстро становится безликой. Реальный материал сужает пространство случайных решений.
Не просите модель рисовать вымышленные логотипы, метрики или интерфейсы как доказательство. Если точного источника нет, используйте нейтральную иллюстрацию и честно отделяйте её от факта.
Представим учебный пример: небольшая мастерская продаёт керамические чашки. В первом варианте агент поставил светящийся шар и три блока «Качество», «Забота», «Инновации». Покупатель по-прежнему не понимает, как выглядит чашка и что получит после заказа. Замените шар фотографией своего изделия, укажите подтверждённые материал, размер и условия заказа. Общие обещания сократите до тех, для которых есть доказательства.
Попросите агента: «Сохрани выбранные шрифты и цвета. На первом экране покажи нашу фотографию чашки и одно действие: оформить заказ. Не добавляй отзывы, числа продаж и свойства товара, которых нет в исходных материалах. Под карточкой объясни, какие данные пока нужно получить у владельца». Это пример задания, а не описание выполненного клиентского проекта. Иллюстрация ниже тоже учебная: чашка сгенерирована, поэтому для настоящего магазина её нужно заменить реальной фотографией.

Шаг 3. Сравните несколько концепций
Не принимайте первый экран как финал. Попросите несколько концепций, которые различаются не цветом кнопки, а логикой: редакционный плакат, предметная сцена, доказательство через реальный экран, компактная продуктовая страница. Сравните их по одной шкале: ясность обещания, соответствие бренду, доказательность и удобство.
После выбора дорабатывайте один вариант небольшими итерациями. За один проход меняйте один класс решений: сначала структуру, затем типографику, затем изображения, затем микровзаимодействия. Так проще понять, что действительно улучшило страницу.
В конце этого шага у вас должен быть выбранный макет и короткое обоснование: зачем нужен первый экран, почему блоки идут в таком порядке и как каждый помогает следующему действию.
Шаг 4. Проверьте страницу в работе
Красивый кадр на ноутбуке ничего не доказывает. Откройте страницу в адаптивном режиме DevTools и проверьте несколько ширин, включая узкую мобильную. W3C отдельно требует, чтобы контент мог перестраиваться при ширине, эквивалентной 320 CSS-пикселям, без необходимости прокручивать страницу в двух направлениях, кроме специально оговорённых случаев.
Пройдите страницу только клавиатурой. Фокус должен быть видимым на каждом интерактивном элементе. Проверьте контраст: WCAG 2.2 задаёт минимум 4,5:1 для обычного текста и 3:1 для крупного. Для анимаций предусмотрите реакцию на пользовательскую настройку prefers-reduced-motion.
Следите за смещениями во время загрузки. Google относит CLS к Core Web Vitals и рекомендует стремиться к значению 0,1 или меньше как минимум для 75% посещений. Частые причины; изображения без размеров, поздно появляющиеся блоки и веб-шрифты.
Наконец, выполните главное действие: заполните форму, откройте меню, перейдите по CTA, вызовите ошибку. Если путь не работает, визуальная оригинальность не спасает сайт.
Для проверки перестройки используйте ширины 320, 375 и 768 CSS-пикселей как рабочие тестовые точки, а не как полный список устройств. В WCAG 2.2 требование 320 CSS-пикселей относится к вертикально прокручиваемому содержимому; у таблиц, карт и других элементов, которым нужна двумерная компоновка, есть исключения. Подробности: https://www.w3.org/WAI/WCAG22/Understanding/reflow.
Порог контраста 3:1 применяют к крупному тексту: от 18 pt обычного начертания или от 14 pt полужирного. Для обычного текста ориентир 4,5:1. У логотипов, декоративного текста и неактивных элементов есть исключения. Проверьте конкретные пары цветов, а не общую яркость экрана: https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.
Нажимайте Tab и Shift+Tab: должно быть понятно, какой элемент выбран. Для кнопки проверьте Enter или пробел, для ссылки Enter; для меню проверьте предусмотренный в интерфейсе способ закрытия. Запишите найденные ошибки и повторите маршрут после исправления. Видимый фокус описан здесь: https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.
Включите уменьшение движения в системе и проверьте страницу снова. Настройку сообщает CSS-медиафункция prefers-reduced-motion; сама по себе она не переписывает анимацию, сайт должен обработать предпочтение: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion. Оценку CLS за один лабораторный запуск не выдавайте за показатель всех посетителей. Порог и причины смещений: https://web.dev/articles/optimize-cls.

Диагностика: что исправлять, если результат всё ещё шаблонный
Если все секции похожи друг на друга, уменьшите число типов блоков и усилите один главный приём. Если бренд не узнаётся, проверьте, есть ли в спецификации реальные цвета, шрифт, тон изображений и запреты; одного логотипа недостаточно.
Если страница выглядит эффектно, но непонятно, что делать, верните в начало задачу читателя и один главный CTA. Если интерфейс ломается на мобильном, не прячьте проблему уменьшением шрифта: перестройте сетку и порядок элементов.
Если модель снова добавляет декоративные карточки, попросите обосновать роль каждой. Всё, что не поддерживает решение, доказательство или действие, удаляется. Если анимация мешает чтению или не учитывает системные настройки, сократите её либо замените спокойным переходом.
Если после правок сайт всё ещё можно перепутать с десятком других, вернитесь к исходным материалам. Проверьте, достаточно ли на странице сведений о настоящем продукте, его ограничениях и примерах использования.
Короткий чек-лист перед запуском
У страницы есть один понятный результат для посетителя. Визуальные правила зафиксированы и не противоречат друг другу. Референсы разобраны по конкретным признакам, а не скопированы целиком. Каждый блок отвечает на вопрос читателя или подтверждает тезис. Все изображения имеют смысловую роль.
На узкой ширине нет потери содержания и лишней горизонтальной прокрутки. Контраст, клавиатурный фокус и уменьшение движения проверены. Изображения имеют размеры, а загрузка не сдвигает элементы. Главный CTA ведёт в существующий маршрут и реально работает.
Главный критерий готовности: страницу можно отличить от конкурентов без логотипа, но её польза остаётся понятной без дизайнерского объяснения.
Частые вопросы
Нужно ли запретить градиенты и карточки? Нет. Проверьте, какую задачу выполняет каждый элемент. Уместная карточка товара с реальными характеристиками помогает выбору; три одинаковых блока с общими обещаниями могут занимать место без пользы.
Достаточно ли написать DESIGN.md? Нет. Файл хранит правила, а соответствие им проверяется на готовой странице. После изменений сравните экран с правилами, пройдите клавиатурой и выполните главное действие.
Можно ли считать оригинальный экран готовым сайтом? Нет. Отличимый стиль не подтверждает работу формы, доступность и адаптивность. Сохраните скриншоты выбранных ширин и список проверенных действий, чтобы следующий проход можно было сравнить с предыдущим.
Что делать дальше
ИИ ускоряет сборку, но качество появляется из правил, реальных материалов и проверки. Сначала задайте характер страницы, затем дайте модели доказательства, выберите сильную концепцию и прогоните её через мобильный, доступность и рабочий сценарий.
Если хотите отработать этот подход на проекте вместе с агентом, посмотрите программу воркшопа Codex + Hermes: https://human20.app/launch/workshop. На странице описан практический путь от задачи к работающему проекту.