Як написати промпт для ШІ, який можна використовувати повторно

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

Коли такий промпт підходить, а коли ні

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

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

Коли підходить	Коли краще інший підхід
Та сама робоча задача повторюється з новими фактами	Кожен випадок потребує іншої логіки й окремого рішення
Результат має зрозумілу структуру	Не можна наперед визначити, що вважати прийнятним результатом
Вхідні дані можна явно передати моделі	Потрібні закриті або актуальні дані, до яких модель не має доступу
Помилки можна знайти перевіркою	Результат не можна надійно перевірити до використання
Людина або система контролює фінальну дію	Модель має самостійно ухвалити незворотне чи високоризикове рішення

Офіційні рекомендації OpenAI, Anthropic і Google сходяться в базовому принципі: інструкція має бути чіткою, конкретною, містити потрібний контекст і пояснювати очікуваний результат; для складніших задач корисні структура, приклади та ітеративне тестування. Це не гарантує правильності відповіді, але робить поведінку моделі керованішою.

Що робить промпт повторюваним

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

Проблема з'являється під час копіювання. Людина замінює ім'я й тему, але залишає стару дату, заборону або обіцянку. Або видаляє речення, яке здавалося другорядним, хоча воно визначало формат відповіді.

Повторюваний промпт має чотири окремі частини:

1. Стабільна інструкція — що саме треба зробити й для кого.
2. Змінні вхідні дані — факти конкретного випадку.
3. Межі та формат — що не можна вигадувати і як має виглядати результат.
4. Критерії приймання — як перевірити, що відповідь придатна до роботи.

Кількість змінних не є правилом. У прикладі нижче їх три, бо цього достатньо для конкретної задачі. Для іншої задачі полів може бути два, п'ять або більше.

Крок 1. Виберіть одну повторювану задачу

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

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

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

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

Крок 2. Зафіксуйте разовий запит

Уявімо синтетичну ситуацію з персонажами Patterneo. Менеджер з продажу ТОВ «Ромашка» Олег ПЕТРЕНКО пише директорці ТОВ «Волошка» Марині БОНДАРЕНКО.

Разовий запит може виглядати так:

Напиши українською короткий лист Марині Бондаренко про те, що ми не завершимо
оновлення аналітичного звіту в погоджену п'ятницю. Під час звірки даних знайшли
дублікати в імпорті, тому потрібні ще два робочі дні. Не перекладай провину на
контрагента і не використовуй фрази «не хвилюйтеся» та «форс-мажор».

Спочатку прямо повідом про перенесення, потім одним реченням поясни причину,
скажи, що вже зроблено, і запропонуй короткий дзвінок у понеділок о 10:00.

Новий строк — вівторок до 18:00. Тон спокійний і відповідальний. До 120 слів.
Не вигадуй компенсацію, додаткові роботи або інші строки.

Для одного випадку це нормальна інструкція. Але як шаблон вона незручна: ім'я, причина, п'ятниця, понеділок, вівторок і конкретна дія заховані в різних місцях тексту.

Крок 3. Розділіть правила і змінні дані

У нашому прикладі достатньо трьох груп змінних:

• {СИТУАЦІЯ} — кому пишемо, що змінилося і чому;
• {МЕЖІ} — підтверджений строк і те, чого не можна обіцяти;
• {НАСТУПНИЙ_КРОК} — конкретна дія після повідомлення.

Усе інше лишається стабільним: мова, порядок листа, довжина, тон, заборона на домисли та правила перевірки.

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

Крок 4. Побудуйте шаблон промпту

Ось версія, яку вже можна тестувати повторно:

Завдання:
Підготуй короткий робочий лист контрагенту про зміну раніше погодженого строку.

Вхідні дані:
{СИТУАЦІЯ}

Підтверджені межі:
{МЕЖІ}

Наступний крок:
{НАСТУПНИЙ_КРОК}

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

Критерії приймання:
1. Усі дати й обіцянки мають походити з вхідних даних.
2. Новий строк не суперечить наступному кроку.
3. У першому реченні є сама новина, а не вступ.
4. Немає непідтверджених компенсацій чи гарантій.
5. Текст не перевищує 120 слів.

Поверни лише готовий лист і, якщо потрібно, рядок «Потрібно уточнити: ...».

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

Крок 5. Запустіть шаблон на першій ситуації

Вхідні дані

{СИТУАЦІЯ}
Олег ПЕТРЕНКО пише Марині БОНДАРЕНКО. Оновлений аналітичний звіт не буде
готовий у погоджену п'ятницю: під час звірки даних команда виявила дублікати
в імпорті. Дублікати вже видаляють і повторно перевіряють підсумкові рядки.

{МЕЖІ}
Підтверджений новий строк — вівторок до 18:00.
Не обіцяти компенсацію або додаткові роботи.

{НАСТУПНИЙ_КРОК}
Запропонувати короткий дзвінок у понеділок о 10:00 і показати статус перевірки.

Результат реального тестового запуску

Тест виконано в Codex на моделі GPT-5.6 Sol 19.09.2026. Інша модель або повторний запуск можуть сформулювати лист інакше.

Марино, ми переносимо передачу оновленого аналітичного звіту з п'ятниці на вівторок до 18:00. Під час звірки даних команда виявила дублікати в імпорті, які потрібно прибрати до фінальної перевірки. Зараз дублікати видаляємо та повторно звіряємо підсумкові рядки. Пропоную в понеділок о 10:00 коротко зідзвонитися й показати поточний статус перевірки.

Перевірка

Результат проходить усі п'ять критеріїв:

• новий строк є в першому реченні;
• причина взята зі вхідних даних;
• немає компенсації або нової гарантії;
• наступний крок не перетворено на обіцянку завершити роботу раніше;
• лист коротший за 120 слів.

Це ще не доводить повторюваність. Потрібен другий запуск на іншій ситуації.

Крок 6. Не змінюючи шаблон, дайте інші дані

Другий тест навмисно змінює предмет, причину й наступну дію, але не сам промпт.

Вхідні дані

{СИТУАЦІЯ}
Олег ПЕТРЕНКО пише Марині БОНДАРЕНКО. Оновлену комерційну пропозицію не
надішлють у погоджену середу, тому що два прайси постачальників надійшли з
різними умовами доставки. Команда вже отримала уточнення від одного
постачальника й очікує письмове підтвердження від другого.

{МЕЖІ}
Підтверджений новий строк — п'ятниця до 16:00.
Не називати остаточну ціну до завершення звірки й не обіцяти дострокову відправку.

{НАСТУПНИЙ_КРОК}
У четвер до 12:00 надіслати короткий статус із переліком уже підтверджених умов.

Результат другого реального тестового запуску

Марино, ми переносимо надсилання оновленої комерційної пропозиції із середи на п'ятницю до 16:00. Під час звірки з'ясувалося, що два прайси постачальників містять різні умови доставки, тому їх потрібно підтвердити до фінального розрахунку. Від одного постачальника уточнення вже отримали, від другого очікуємо письмове підтвердження. У четвер до 12:00 надішлемо короткий статус із переліком умов, які вже підтверджені.

Що показав другий запуск

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

Це і є практичний тест повторюваності: міняються вхідні дані, але не основна інструкція й не критерії якості.

Два вдалі запуски не доводять, що шаблон ніколи не помилиться. Вони лише показують, що він пережив першу перевірку на перенесення між двома різними ситуаціями.

Як перевіряти промпт, а не красу відповіді

Найслабша перевірка — запитати модель: «Все правильно?». Модель може погодитися з власною помилкою.

Краще мати критерії, які можна звірити незалежно:

Що перевіряємо	Як перевірити
Факти	Порівняти імена, дати, суми й причини з вхідними даними
Межі	Переконатися, що модель не додала нову обіцянку, строк або компенсацію
Формат	Перевірити структуру, кількість пунктів, таблицю, JSON або інший заданий вихід
Повноту	Звірити обов'язкові елементи за чеклістом
Повторюваність	Дати інший коректний вхід без переписування правил
Невизначеність	Прибрати критичний факт і перевірити, чи модель просить уточнення замість домислу

Для важливих робочих задач частину перевірок можна автоматизувати: довжину тексту, наявність потрібних полів, формат JSON, обов'язкові ключі або заборонені фрази. Фактичність і доречність часто все одно потребують людини або окремого джерела істини.

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

Приклад бажаного результату корисний, якщо словесної інструкції недостатньо для стабільного формату, стилю або класифікації. Anthropic називає приклади одним із надійних способів керувати форматом і структурою; Google також рекомендує few-shot examples для багатьох задач.

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

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

Коли створювати нову версію промпту

Не дописуйте до одного шаблону всі винятки, які трапляються в роботі.

Нова версія потрібна, якщо:

• змінилася сама мета результату;
• інший канал вимагає іншого формату;
• з'явився новий клас ризику або обов'язкова перевірка;
• змінні поля перестали однозначно описувати допустимі випадки;
• повторювана помилка показала, що чинного правила бракує.

Практичний журнал може бути простим:

delay-message-v1
- базовий лист про перенесення строку;

delay-message-v2
- додано окремий критерій: не перетворювати наступну дію на гарантований результат.

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

Типові помилки

Писати «ти найкращий експерт» замість конкретного завдання

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

Ховати змінні факти в середині інструкції

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

Просити «зроби професійно»

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

Давати лише заборони

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

Перевіряти лише один приклад

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

Намагатися зробити шаблон універсальним

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

FAQ

Чи існує універсальна формула хорошого промпту?

Ні. Офіційні рекомендації різних провайдерів дають схожі принципи — чіткість, контекст, формат, приклади за потреби, ітеративне тестування — але не одну обов'язкову формулу для всіх задач. Структура має відповідати конкретному результату, який ви хочете отримати.

Чи потрібно завжди вказувати роль на кшталт «ти — експерт»?

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

Скільки змінних має бути в шаблоні?

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

Чи працюватиме той самий промпт у ChatGPT, Claude та Gemini?

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

Чи може хороший промпт гарантувати правильну відповідь?

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

Що робити далі

Візьміть один запит, який ви вже копіювали й редагували вручну. Винесіть змінні факти в окремі поля, додайте 3–5 критеріїв приймання й запустіть той самий шаблон на іншій коректній ситуації.

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

Готового перевіреного промпт-пакета цього класу в каталозі Patterneo поки немає. Якщо ви створюєте й перевіряєте такі рішення, прочитайте правила для авторів. Коли пакет з'явиться, стаття має вести до нього лише після окремого тестування самого продукту.

Як перевіряли шаблон

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

Власний висновок Patterneo: для повторюваної робочої задачі корисно відокремлювати стабільні правила від змінних даних і перевіряти шаблон другим запуском за наперед визначеними критеріями.

Навчальний приклад: ТОВ «Ромашка», ТОВ «Волошка», Олег ПЕТРЕНКО і Марина БОНДАРЕНКО — синтетичні персонажі стандарту Patterneo.