Рендер и проверка глазами

Есть соблазн думать, что агент, который пишет верстку, и дизайн делает хорошо. На деле он делает его вслепую: генерирует HTML и CSS, но сам страницу не видит — как человек, который рисует макет с закрытыми глазами и надеется, что попал. Отсюда кривые отступы, слипшийся текст, элементы, вылезающие за экран. Лечится это одним приёмом: агент должен открыть страницу в настоящем браузере, сделать скриншот, посмотреть на него и починить то, что уродливо. И повторить. Это не теория — это рабочая, обкатанная петля. В этой статье разберём, как она устроена.

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

Агент не должен проектировать вслепую. Правильный цикл: собрал страницу → открыл её в реальном браузере → снял скриншот → скриншот вернулся агенту, и тот его увидел → сам себя раскритиковал (отступы, иерархия, контраст, переполнение, адаптив) → починил → отрендерил заново. Минимум пара итераций, первый рендер никогда не финальный. Браузером агент рулит через настоящие инструменты — Playwright MCP от Microsoft или Chrome DevTools MCP от Google. Так закрывается разрыв между «сгенерировал интерфейс» и «убедился, что он не уродлив».

Почему «вслепую» — плохо

Модель генерирует верстку по тексту: она предсказывает разумный CSS, но не видит, что из него сложилось на экране. А визуальные баги живут именно там, где текст бессилен: отступ, который на словах «16 пикселей», а на глаз прижимает заголовок к картинке; цвет, который в коде «серый», а на фоне не читается; блок, который в разметке аккуратный, а в узком окне вылезает за край.

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

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

Петля: собрал → открыл → скриншот → посмотрел → починил

Вся техника — это цикл из нескольких шагов, который агент прокручивает, пока результат не станет чистым:

• Собрал. Агент пишет страницу — HTML, стили, всё что нужно.
• Открыл в браузере. Запускает headless-Chrome и переходит на страницу (navigate). Браузер настоящий, тот же движок, что у людей, — значит и картинка настоящая.
• Снял скриншот. Делает снимок отрендеренной страницы.
• Посмотрел. Ключевой шаг. Скриншот возвращается агенту, и, поскольку модель мультимодальная, она реально видит изображение — не описание, а картинку.
• Раскритиковал себя. Проверяет по чек-листу: отступы, иерархия, контраст, переполнение, адаптив. Находит уродство.
• Починил и повторил. Правит верстку и рендерит заново. Круг замыкается.

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

Инструменты: чем агент рулит браузером

Браузер агенту даёт MCP-сервер. Их два основных, оба настоящие:

• Playwright MCP — от Microsoft. Даёт агенту руки на управление браузером: открыть страницу, снять скриншот, покликать, проверить состояние. Рабочая лошадка под render-петлю.
• Chrome DevTools MCP — от Google. Даёт доступ к браузеру через DevTools-протокол: то же управление плюс отладочная сторона — консоль, сеть, производительность.

Оба подключаются как обычный MCP-сервер и дают агенту то, чего у него нет из коробки, — настоящий глаз на страницу. Какой брать, зависит от задачи, но принцип один: без такого сервера агент верстает, но не смотрит.

Подключить Playwright MCP — рабочую лошадку под эту петлю — можно одной командой:

claude mcp add playwright -- npx @playwright/mcp@latest

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

Что проверять на скриншоте

Одного снимка десктопа мало. Минимальный набор проверок:

• Два брейкпоинта. Десктоп и мобилка (узкая ширина). Верстка, идеальная на широком экране, на телефоне часто разъезжается — колонки наезжают, текст жмётся, кнопки уходят за край. Смотреть надо оба.
• Переполнение. Не вылезает ли что-то за границы экрана, нет ли горизонтальной прокрутки там, где её быть не должно, не обрезается ли контент.
• Консоль браузера. Открыть и прочитать: ошибки, битые ссылки, не подгрузившиеся картинки (404), предупреждения. Чистая консоль — часть определения «готово», а не приятный бонус.

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

Сколько итераций

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

Где предел

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

FAQ

Агент правда видит скриншот или делает вид?

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

Обязательно ли ставить браузерный MCP?

Для этой петли — да. Без сервера, который открывает страницу и снимает скриншот, агент остаётся при генерации вслепую. Playwright MCP или Chrome DevTools MCP — это как раз тот инструмент, который даёт агенту глаз.

Двух итераций всегда хватает?

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

Зачем проверять консоль, если картинка выглядит нормально?

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

Итог

Агент не должен проектировать с закрытыми глазами. Рабочая петля — собрал, открыл в настоящем браузере, снял скриншот, посмотрел на него, раскритиковал себя, починил, повторил. Браузер даёт настоящий MCP-сервер: Playwright от Microsoft или Chrome DevTools от Google. Проверять надо оба брейкпоинта, переполнение и консоль. Минимум две итерации — первый рендер всегда черновик. Петля убирает очевидное уродство; вкус на финальном решении остаётся за человеком. Главное, что она закрывает разрыв между «сгенерировал интерфейс» и «убедился, что он не уродлив» — доказательством становится скриншот, а не слово.

Про сам механизм, который даёт агенту браузер, — в гайде Браузер для агента.