Я знайшов одне речення, яке кардинально покращило якість моїх результатів від ШІ. Перш ніж я розповім, що це за речення, погляньте на ці два сайти, згенеровані майже ідентичними промптами.
Припускаю, дизайн Marginalia сподобався вам більше, ніж Folio. Ось промпти, які я використав для кожного з них:
Створи адаптивний додаток для списку читання. Користувачі можуть додавати книги, позначати їх як прочитані та фільтрувати список на прочитані й непрочитані. Зберігай список між оновленнями сторінки. Додаток має працювати на десктопі та мобільних пристроях.
Ти найкращий UX/UI-дизайнер у світі.
Створи адаптивний додаток для списку читання. Користувачі можуть додавати книги, позначати їх як прочитані та фільтрувати список на прочитані й непрочитані. Зберігай список між оновленнями сторінки. Додаток має працювати на десктопі та мобільних пристроях.
Просте додавання одного речення, яке каже моделі, що вона найкраща у світі в чомусь, дало величезну різницю. Ви можете побачити зміни у виборі шрифтів, макеті сторінки, використанні кольорів, відступах між секціями та ієрархії в UX.
В обох випадках використовувалася GPT-6 Astra Ultra, у порожніх папках, збірки створювалися одночасно без жодної інформації одна про одну. Я перевірив логи міркувань (reasoning traces), щоб переконатися у відсутності перехресного впливу. Деякі дрібні дизайнерські рішення змінювалися під час повторних запусків, але додаткове речення перемагало щоразу.
Останнім часом я роблю це для більшості своїх промптів. Я кажу Claude або Chat, що він — найкращий дизайнер у світі, експертний архітектор програмного забезпечення, найвідоміший письменник планети, найрозумніший інвестор тощо. І я помітив значне покращення якості коду, кількості виявлених багів та ясності написаного тексту.
Тому я вирішив це автоматизувати
Мені завжди здавалося нудним додавати це вручну, тому я вирішив створити скіл (skill), щоб зекономити кілька натискань клавіш і менше няньчитися з моделлю. Скіл — це просто набір інструкцій, який ваш агент може використовувати повторно. Ви можете знайти його на GitHub, а інструкцію зі встановлення я додав у кінці. Як виявилося, створення цього скілу було значно складнішим, ніж я очікував.
Для першої спроби я попросив Astra згенерувати скіл, який би стабільно відтворював ту саму різницю, яку я побачив між Folio та Marginalia. Я сказав йому позиціонувати модель як найкращу у світі в тій сфері, якої вимагає поточне завдання. Я дав йому обидва промпти й дозволив діяти. Він провалився.
Astra вирішила створити епічно складний набір інструкцій, і потрібний мені промпт просто загубився серед них. Я переглянув лог міркувань: через усю цю надмірну складність інструкції були повністю проігноровані.
Але мені було ліньки писати скіл самостійно. Тому я дав Astra ще один шанс, цього разу наказавши не зупиняти ітерації, доки вона не зможе продемонструвати відчутне покращення від використання скілу. Мене справді вразив цикл, який вона створила: там було кілька субагентів для редагування скілу, його тестування та перевірки результатів кожного промпту. Вона створила окремі контейнери для запуску кожного тесту. Я скептично ставився до алгоритму «сходження на пагорб» (hill climbing) для такого простого завдання з промптингу, але вирішив не втручатися. Через 20 хвилин я отримав сповіщення, що вершину досягнуто, а результат тесту був ідеальним.
Однак була одна проблема: глибоко в скілі заховався промпт, заточений саме під цей конкретний приклад. Ось що відповів Chat, коли я поставив його перед фактом: «Ви маєте рацію — я перенавчив універсальний скіл під наш тестовий кейс для UI». Тож ми прибрали специфічні для завдання формулювання, і скіл знову став марним.
На що саме звертала увагу модель?
У мене було дві здогадки, чому спрацювала моя рамка «найкращий у світі»:
- Вищий стандарт змусив модель виконати більше ітерацій
- Роль UI/UX-дизайнера підкреслила важливість правильного дизайну
Я повернувся до логів міркувань із тих запусків, що дали кращі результати, і знайшов підтвердження обох гіпотез. Було додано етап дизайну, і загалом витрачено більше ресурсів на міркування. Скіл, який я створив, вирішив назвати роль «фронтенд-інженер», тому додатковий час пішов на надійність додатку та крайні випадки (edge cases), які могли спричинити баги. Обидві ролі були важливими, але ШІ вирішував зосередитися на технічній коректності та точному виконанні початкових вимог промптів. Як можна було посунути його далі?
Тому я вирішив поставити два запитання:
Якщо всі буквальні вимоги виконано, чому результат все одно може не впоратися зі своїм призначенням?
Що змусить аудиторію обрати один однаково правильний результат замість іншого?
Що змусило це працювати
Результатом став наступний процес із чотирьох кроків, який визначає конкретні ролі для ШІ, а потім штовхає його до вищого стандарту результату:
- Визначте відмінні сильні сторони до початку роботи. Що зробить результат видатним? LLM потребують фокусу на чомусь конкретному, щоб видати найкращий результат. Просте «зроби найкращий сайт» не спрацює так добре, як «спроєктуй найкращий UX для цього сайту, зверни увагу на відступи, шрифти та кольори в UI, і протестуй його так, як це зробив би користувач, щоб мінімізувати будь-яке тертя». Писати останній промпт вручну нудно, але промпт, який змушує LLM зробити метаоцінку необхідних ролей перед початком роботи, дає схожі результати. Людина-працівник діяла б так само: навчання того, на що звертати увагу і як структурувати думки, робить людину продуктивнішою. Нам потрібно визначити призму, крізь яку ШІ дивитиметься на завдання, але щоб скіл був універсальним, ми маємо дозволити ШІ самому вирішити, якою буде ця призма. Передаючи цю відповідальність ШІ (який може не до кінця розуміти точні наміри користувача), ми неминуче втратимо частину ефективності, але мої тести скілу поки що показують, що ми наближаємося до ідеалу досить близько.
- Калібруйте стандарт за допомогою референсу. Знайдіть сильний, релевантний приклад або створіть невелику конкретну альтернативу. Це дає поняттю «відмінно» щось відчутне для порівняння. Після досягнення ідеального результату тесту ШІ шукає відповідний референс або створює альтернативу. Для сайту це може бути спроба нового макета. Коли є з чим порівнювати, фраза «зроби це відмінним» означає набагато більше.
- Оцінюйте майстерність окремо від коректності. Запитайте: «Де це лише "прийнятно", і яке конкретне вдосконалення найбільше покращить досвід аудиторії?» Оцініть композицію загалом і те, як її частини працюють разом. Це робить результати більш цілісними, чи то структура есе, чи загальна тема сайту.
- Вдосконалюйте та зберігайте сильніший результат. Більше правок не означає автоматично кращу роботу. Скіл зберігає попередню версію, порівнює суттєві зміни та залишає сильніший варіант. Якщо правка робить гірше, відбувається відкат. Інакше всі ці зайві зусилля залишать після себе лише безлад.
Фінальний результат гарно використовує кольори та шрифти з візуально привабливими відступами. Він прибрав частину тієї «перевантаженості», яка мені не подобалася в Marginalia (я перевірив у логах міркувань, що це була навмисна правка), але краще за Folio впорався з використанням кольору та дизайном елементів у бічній панелі й селекторах.
Чому це ще не вбудовано в інструменти?
Кожен оркестратор, як-от Codex і Claude Code, мусить балансувати між якістю, швидкістю та вартістю. У певний момент агент має вирішити, що робота вже достатньо хороша.
Але «достатньо хороша» все одно залишає багато простору для покращень. Незалежно від того, який інструмент я використовую, усі вони зупиняються раніше, ніж мені хотілося б. Я б краще витратив додаткові токени на отримання якіснішого результату. І, що важливо, поняття «краще» потребує чогось конкретного. Як виглядає сильний результат? Яка його частина все ще лише «прийнятна»? І чи справді остання зміна щось покращила?
Спробуйте самі
Я упакував увесь цей процес у Prompt Lab.
Завантажити Prompt Lab на GitHub
Щоб установити його, вставте це в Codex:
1$skill-installer Install the skill from https://github.com/coltonconley/prompt-lab/tree/main/skills/prompt-lab
Якщо скіл не з'явився після встановлення, перезапустіть Codex. Потім додайте його перед вашим звичайним завданням:
1$prompt-lab2[Ваше завдання, обмеження, аудиторія та бажаний результат]
Вам не потрібно обирати ролі експертів чи прописувати процес перевірки. Додайте контекст та обмеження, які ви зазвичай додаєте, особливо все важливе про те, для кого призначений результат. А далі дозвольте йому працювати.
Моя порада: спробуйте це на завданні, яке ви вже просили ШІ виконати, але результатом були незадоволені. Запустіть те саме завдання в нових чатах, зі скілом і без нього, використовуючи однакову модель та налаштування. Порівняйте реальні результати та оцініть, чи вартувало покращення витраченого часу.
Мене особливо цікавлять приклади за межами вебдизайну. Тексти, код, аналітика — усе, для чого ви реально використовуєте ШІ. Якщо це спрацювало для вас (або якщо ні), поділіться у відповідь своїм промптом і результатами «до» та «після». Чим більше прикладів я матиму, тим кращим стане цей скіл.
