Чому автоматичне виправлення UI за допомогою ШІ не працює та як це виправити

@Lonely__MH
СПРОЩЕНА КИТАЙСЬКА13 вер. 2026 р.
185K
241
36
58
483

Коротко

Автор досліджує причини деградації результатів при автоматичному виправленні UI засобами ШІ та пропонує робочий процес, що включає візуальні порівняння (visual diffs), структурну діагностику та збереження найкращих попередніх версій для стабілізації якості.

У цій статті я зафіксував деякі підводні камені, з якими зіткнувся нещодавно, коли використовував ШІ для відтворення вебсторінок. Згодом я побудував робочий процес для вирішення цих проблем і систематизував весь процес для подальшого використання.

Напевно, ви теж стикалися з подібним.

Іноді ви надсилаєте скріншот ШІ й просите створити сторінку на його основі. Перша версія виглядає приблизно правильно, але при ближчому розгляді щось «не те»: картки трохи ширші, шрифти менші, тіні неправильні — дрібниці, але вони є.

Потім доводиться словесно описувати, що саме потрібно виправити і як це зробити. Ітерації займають чимало часу.

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

Але на практиці все пішло не за планом. Іноді після виправлень у другому раунді третій скасовував зміни; результати коливалися, а сторінка могла ставати навіть гіршою з кожною ітерацією.

Давайте одразу до суті.

Як забезпечити самовиправлення

Процес нескладний:

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

Порівняння трьох раундів для жовтої картки: Раунд 2 покращив результат, Раунд 3 регресував, тому ми залишили Раунд 2 як історично найкращий.

Однак хороший перший раунд не гарантує постійного покращення.

Це відео фіксує проблему: Раунд 2 був ближчим до оригіналу, але Раунд 3 трохи відстав назад. На щастя, робочий процес не прийняв останній раунд як остаточну відповідь автоматично, а зберіг історично найкращий результат із Раунду 2.

Отже, повернення Diff не означає, що модель раптово стає розумнішою. Вона може виявляти багато деталей і прив'язувати судження до конкретного CSS, але іноді все одно плутається.

Деталі того, як працює робочий процес, дивіться у записі екрана нижче.

Lonely - inline image

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

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

Порівняння обох записів показує різні тенденції:

Lonely - inline image

Жовта картка покращилася до Раунду 2, але регресувала в Раунді 3; темна картка демонструвала стабільні невеликі покращення протягом усіх трьох раундів. Хоча два записи не доводять статистичних закономірностей, вони показують, що той самий робочий процес не завжди дає кращий результат у кожному раунді.

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

Що вона реально вміє?

З цих результатів видно, що перша версія — це стандартний Screenshot-to-Code. Цікаво те, що після перегляду відрендереного виводу модель може вказати на проблеми до конкретних елементів і CSS-властивостей, замість того щоб просто казати «зроби більш схожим».

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

Багато візуальних проблем не викликають помилок. Якщо модель бачить фактично відрендерену браузером сторінку, у неї є шанс продовжити самовиправлення.

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

Показник у 7 секунд базується на моєму конкретному інтерфейсі та налаштуваннях. Я не проводив горизонтальних порівнянь і не буду робити висновків щодо швидкості/вартості лише на основі активних параметрів.

Де криються підводні камені?

Справжня витрата часу була не в підключенні моделі, а в отриманні точного зворотного зв'язку. Спочатку я думав, що коливання означали нестабільність моделі. Після перевірки Diff по одному я зрозумів, що частина проблеми полягала в моєму циклі зворотного зв'язку.

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

Якщо цільове зображення було масштабовано, а браузер робив скріншот у іншому розмірі, зображення ніколи не збігалися з самого початку. Навіть за правильної відповіді Diff показував великі розбіжності.

Для попиксельних diff глобальне зміщення на кілька пікселів створює масивні зони помилки.

2. Другий підводний камінь: Анімація

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

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

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

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

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

Коротко кажучи, Diff — це інструмент, а не суддя.

Якщо зворотний зв'язок хибний, модель цього не помітить. Вона старанно виправлятиме невірний напрям, спираючись на дефектні вхідні дані.

Висновок

Я дистиллював правила до трьох пунктів:

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

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

Тому я більше не припускаю, що більше раундів означає кращі результати. Спершу виправте очевидні проблеми, зупиніться, коли покращення виходять на плато — для мене цього достатньо.

Модель є відкритою та безкоштовною протягом 2 тижнів. Щоб запустити її самостійно, скористайтеся цими посиланнями 👇🏻:

P.S.: Ця стаття була надиктована та відшліфована ШІ, тому в ній є душа ✌🏻

Збереження в один клік

Використовуйте YouMind для AI-глибокого читання віральних статей

Зберігайте джерела, ставте цілеспрямовані запитання, підсумовуйте аргументи та перетворюйте віральні статті на корисні нотатки в одному AI-робочому просторі.

Дослідити YouMind
Для авторів

Перетворіть свій Markdown на охайну статтю для 𝕏

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

Спробувати Markdown для 𝕏

Більше патернів для аналізу

Останні віральні статті

Переглянути більше віральних статей