Промпт-інжиніринг: структура запиту

Задай роль і мету

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

• Роль — «Ти досвідчений редактор», «Ти аналітик даних», «Ти ментор з програмування».
• Мета — навіщо це потрібно: «щоб відправити клієнту», «щоб розібратись самостійно», «для публічного посту».

Без ролі й мети модель відповідає «в середньому» — універсально й безпечно, але не точно під задачу.

Ти досвідчений редактор ділових текстів. Мета — зробити лист клієнту коротшим і впевненішим перед відправкою, без втрати ключових деталей.

Порада Роль обирай під навичку, яка потрібна («редактор», «критик», «аналітик»), а не під загальний титул на кшталт «експерт у всьому».

Дай контекст

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

• Аудиторія — для кого результат (початківці, колеги, клієнти).
• Фон — що вже відбулось, що важливо знати перед відповіддю.
• Приклади свого стилю — фрагмент тексту, який уже подобається, як орієнтир тону.

Чим конкретніший контекст, тим менше модель добудовує здогадками.

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

Сформулюй задачу й обмеження

Задача — одна чітка дія, а не список із п'яти побажань одразу. Обмеження задають межі: обсяг, тон, чого точно не робити.

• Одна дія за раз: «перепиши», «проаналізуй», «запропонуй три варіанти» — не все одразу.
• Обсяг: скільки речень, абзаців, пунктів.
• Заборони: «без канцеляриту», «без вигаданих фактів», «не змінюй структуру».

Чим точніші межі, тим менше версій доведеться переробляти.

РОЛЬ: Ти редактор ділових текстів.
КОНТЕКСТ: Лист клієнту про перенесення дедлайну на тиждень через технічну проблему на нашому боці.
ЗАДАЧА: Скороти лист до 4-5 речень, збережи вибачення й нову дату, прибери зайві ввічливі звороти.
ОБМЕЖЕННЯ: Без канцеляриту, тон впевнений, без виправдань.

Порада Якщо в задачі є слово «і» між двома різними діями — це, ймовірно, дві задачі. Розділи на кроки або окремі запити.

Опиши формат виводу

Це найсильніший важіль контролю над результатом. Точний опис структури відповіді — список, таблиця, покроковий план, JSON — визначає, наскільки результат одразу придатний до використання.

• Список — коли потрібні окремі пункти для швидкого сканування.
• Таблиця — коли є кілька варіантів для порівняння за критеріями.
• Покрокова інструкція — коли результат — це послідовність дій.
• JSON чи фіксована структура — коли результат піде далі в код чи іншу систему.

Без вказаного формату модель обирає структуру сама — і вона рідко збігається з тим, що потрібно.

РОЛЬ: Ти аналітик, що порівнює інструменти.
КОНТЕКСТ: Обираю CRM для команди з 5 людей, важливі ціна та інтеграція з поштою.
ЗАДАЧА: Порівняй три варіанти CRM за критеріями ціна/інтеграції/простота.
ФОРМАТ: Таблиця з колонками «Інструмент | Ціна | Інтеграція з поштою | Простота (1-5) | Висновок», без додаткового тексту після таблиці.

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

Додай приклади (few-shot)

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

Коли варто додавати приклади:

• Потрібен специфічний стиль чи формат, який важко описати словами.
• Задача повторюється (обробка списку однотипних елементів) — приклад задає шаблон для всіх наступних.
• Попередня відповідь була «майже правильною», але не в тому тоні чи структурі.

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

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

Доводь результат ітерацією

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

• «Залиш структуру, скороти другий пункт удвічі» — точніше, ніж «зроби ще раз».
• «Тон занадто формальний, зроби простіше, решту не чіпай» — краще, ніж новий довгий запит.
• Коли результат влучний — збережи цей запит як шаблон (нотатка, проєкт у Claude, власна папка промптів) і використовуй повторно для схожих задач.

Ітерація діалогом швидша й точніша, ніж повторний запуск з описом «наче краще».

Порада Перед тим як переписувати запит з нуля, спитай себе: чи можна виправити одним уточненням поверх того, що вже є?