Почему ИИ-автокоррекция UI не работает и как это исправить

@Lonely__MH
УПРОЩЁННЫЙ КИТАЙСКИЙ13 сент. 2026 г.
185K
241
36
58
483

Суть

Автор исследует причины деградации интерфейсов при использовании ИИ-автокоррекции и предлагает рабочий процесс, включающий визуальное сравнение (diff), структурированную диагностику и сохранение лучших исторических версий для стабилизации результатов.

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

Наверняка вы тоже сталкивались с этим.

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

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

Поэтому я подумал: а что если объединить рендеринг, создание скриншотов, сравнение и исправление в единый воркфлоу, позволяя модели самой находить ошибки и чинить их? Звучало логично.

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

Давайте сразу к делу.

Как заставить модель исправлять себя саму

Процесс несложный:

text
1Целевой скриншот ──▶ Модель пишет HTML ──▶ Браузер делает скриншот 1:1 ──▶ Генерация попиксельного diff
2
3Сохранение лучшего результата ◀── Повторный рендер ◀── Диагностика и правка кода моделью ◀── Оригинал + Рендер + Diff

Diff не исправляет страницу за модель. Он лишь превращает смутное «выглядит не совсем так» в визуальную карту конкретных отклонений, которая затем передается модели для принятия решений о дальнейших действиях.

Чтобы модель не гадала вслепую, опираясь только на Diff, перед каждым изменением я требую ответить на три вопроса:

  1. Где самая большая проблема?
  2. Какой элемент или CSS-свойство, вероятно, вызвали её?
  3. Как именно планируется это исправить?

Только после ответов мы трогаем код.

Для теста я использовал Ling-3.0-flash-VL и выбрал две карточки для простой демонстрации: одна желтая с ярким фоном, толстой черной рамкой и жесткой тенью; другая — темная карточка тарифов SaaS с градиентными кнопками, тегами и списками функций.

Я считаю карточки идеальным примером. Элементов немного, но ширина, отступы, направление кнопок и тени — стоит чему-то одному пойти не так, и это сразу бросается в глаза.

Первый запуск

Начнем с желтой карточки.

После первой версии общий результат был довольно хорошим.

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

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

Затем я передал исходное изображение, результат первого раунда и Diff обратно в Ling, попросив найти эти мелкие недочеты.

Из диагностики видно, что она не просто говорит «недостаточно похоже». Она указывает на конкретные проблемы с размером карточки, шрифтами и кнопками, а затем корректирует соответствующий CSS.

Lonely - inline image

Сравнение трех раундов для желтой карточки: во втором раунде стало лучше, в третьем — хуже, поэтому мы оставили второй раунд как лучший исторический результат.

Однако хороший первый раунд не гарантирует постоянного улучшения.

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

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

Подробности того, как работает этот процесс, смотрите в записи экрана ниже.

Lonely - inline image

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

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

Сравнивая обе записи, можно увидеть разные тренды:

Lonely - inline image

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

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

На что это реально способно?

Судя по результатам, первая версия — это стандартный подход «Скриншот в Код». Интересен тот факт, что, увидев отрендеренный вывод, модель может указать на проблемы до конкретных элементов и CSS-свойств, вместо того чтобы просто говорить «сделай более похожим».

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

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

Еще один практический момент: этот воркфлоу требует многократных вызовов модели, поэтому скорость важна. По моим замерам, генерация полного HTML одной страницы занимала около 7 секунд. Публичные данные показывают, что у Ling-3.0-flash-VL всего 124 млрд параметров, активируется 5,5 млрд на инференс, плюс добавлены возможности визуального понимания и Visual Agent.

Цифра в 7 секунд основана на моем конкретном интерфейсе и настройках. Я не проводил горизонтальных сравнений и не буду делать выводы о скорости/стоимости исключительно на основе количества активных параметров.

Где кроются подводные камни?

Главная трата времени была не в подключении модели, а в получении точной обратной связи. Сначала я думал, что колебания результатов означают нестабильность модели. Но проверив Diff’ы по одному, я понял, что часть проблемы заключалась в моей петле обратной связи.

1. Первый подводный камень: Размер

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

Для попиксельного сравнения глобальное смещение даже на несколько пикселей создает гигантские зоны ошибок.

2. Второй подводный камень: Анимация

Однажды модель добавила эффекты появления (fade-in) к спискам функций. Скриншоты, сделанные в середине анимации, фиксировали прозрачный контент.

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

Причина: Прозрачный контент открывал фон, из-за чего алгоритмы попиксельного сравнения считали, что он «выглядит более похожим».

3. Третий подводный камень: Версионирование

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

Короче говоря, Diff — это инструмент, а не судья.

Если обратная связь неверна, модель этого не заметит. Она будет усердно исправлять не то направление, опираясь на ошибочные входные данные.

Заключение

Я свел правила к трем пунктам:

  1. Используйте идентичные размеры для оригинала и скриншотов браузера; никакого вторичного масштабирования.
  2. Фиксируйте viewport, шрифты, состояния анимаций и время создания скриншота.
  3. Продолжайте работу от лучшей исторической версии каждый раунд; не патчьте деградировавший код.

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

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

Модель открыта для использования и бесплатна в течение 2 недель. Чтобы запустить ее самостоятельно, используйте эти ссылки 👇🏻:

P.S.: Эта статья была продиктована и отредактирована ИИ, так что в ней есть душа ✌🏻

Сохранение в один клик

Используйте YouMind для глубокого чтения вирусных статей с помощью ИИ

Сохраняйте источники, задавайте точные вопросы, обобщайте аргументы и превращайте вирусные статьи в полезные заметки в одном рабочем пространстве ИИ.

Исследовать YouMind
Для авторов

Превратите ваш Markdown в аккуратную статью для 𝕏

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

Попробовать Markdown для 𝕏

Другие паттерны для анализа

Недавние виральные статьи

Смотреть другие виральные статьи