Промпт-інженерія для HR: блоки промта та фреймворк PAIR

Я вже кілька років навчаю HR-фахівців працювати зі штучним інтелектом. За цей час я побачив одну закономірність, що повторюється майже у всіх. Людина відкриває ІІ, пише туди завдання звичайними словами, отримує середню відповідь, засмучується і робить висновок: "Ну, ця штука не для моєї роботи". А потім та сама людина бачить, як його колега тим самим інструментом за десять хвилин збирає те, на що раніше йшов день. Різниця між ними не підписується і не в моделі. Різниця в тому, як поставлене завдання.

Є цифра, яка мене водночас тішить і бентежить. За останні два роки частка HR, які використовують штучний інтелект, зросла з 26 до 53% — фактично подвоїлася. Це чудова динаміка. Але зворотний бік цієї ж цифри: майже половина HR-фахівців, 47%, все ще не використовують ІІ взагалі. І ще більшість із тих, хто використовує, залишається на найпримітивнішому рівні — «напиши текст вакансії», «зроби шаблон офферу». Результат передбачуваний: примітивний запит – примітивна відповідь.

Найприкріше в поточній ситуації те, що проблема не в незнанні інструменту. Користуватися ІІ вміє багато хто. Не виходить інше – отримувати стабільний результат.

Без готової системи роботи з промтами відбувається ось що:

• на один запит йде до десяти ітерацій , ви переписуєте одне й те саме знову і знову;

• щоразу ви отримуєте новий результат, навіть якщо завдання одне й те саме;

• годинник йде на переписування та доведення;

це неможливо передати команді - ваш спосіб живе тільки у вашій голові;

•на виході все одно текст, який соромно показувати.

Я перевіряю всі домашні завдання особисто. Через півроку після появи публічного ChatGPT я помітив, що багато студентів почали робити домашні роботи з ІІ. Спершу я був проти, потім змінив підхід і дозволив – але осмислено. І сьогодні я бачу дві крайнощі. Перша: приходять дуже примітивні відповіді, де одразу зрозуміло, що запит був в один рядок, якість ніхто не перевіряв, а результат так собі. Друга: приходить робота, за обсягом, оформленням і подачею якої видно, що людина робив її разом з ІІ, але настільки класно, настільки вдумливо він вклався в цю взаємодію, що це заслуговує і на повагу, і заліку. Різниця між цими двома роботами — та система, про яку цей матеріал.

Відсутність архітектури промту дає три передбачувані проблеми.

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

Модель, навколо якої я зібрав курс, називається PAIR . Назва говорить сама за себе: ви працюєте зі штучним інтелектом у парі, а не віддаєте йому завдання через стіну. Кожна літера – це окремий шар навички.

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

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

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

Рівень 2. Prompt User. Людина йде далі: шукає та копіює готові промти з добірок, збирає свою колекцію. Це вже працює на типових задачах. До речі, наші перші курси в академії були саме про це — через пару місяців після того, як ChatGPT став загальнодоступним, я записав курс «ChatGPT для HR», потім «ChatGPT для рекрутерів», і там були хороші готові промти з підказками, які можна було копіювати.

3. Промпт-інженер. Ви збираєте промт із семи блоків під будь-яке завдання, отримуєте стабільну якість і можете масштабувати: робити великі обсяги роботи без втрати якості.

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

Чому роль така важлива? Нам здається, що ІІ це супергеній, який може все. Знань у нього справді дуже багато. Але він не знає, ким йому зараз бути. Одне й те завдання різні люди виконають по-різному: HR зробить по-своєму, маркетолог по-своєму, розробник по-своєму. Усередині моделі – мільйони можливих ролей, і коли ви звертаєтесь до неї без вказівки, вона вгадує. Іноді вгадує правильно, частіше – ні.

Контекст – друга половина цих 70%. Без вашого контексту – про вас, про вашу компанію, про вашу специфіку – модель відповідає за середню компанію. А у вас компанія не середня.

Ось та схема, яку я розумію на першому занятті. Це не магічні слова, а інженерна конструкція.

Найчастіше люди пишуть лише третій блок — що робити. А це приблизно 10–20% конструкції.

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

Слабко: Напиши job description для backend-розробника. Це наче попросити про те саме випадкового журналіста чи офіс-менеджера.

Сильно:

Ти сеньйор-техрекрутер із 8-річним досвідом найму бекенд-інженерів

у продуктовій компанії. Ти пишеш job description, які проходять

технічну перевірку в CTO без правок.

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

Розкажу, як це робив я. Тривалий час я користувався ChatGPT, потім спробував Claude і зрозумів, що далі працюватиму в ньому. Але була проблема: ChatGPT за час спілкування знав про мене багато, а Claude не знав нічого. І перші кілька днів я буквально переносив себе.

Що я робив:

1.На прогулянках вмикав диктофон і наговорював: хто я, чим займаюся, що для мене важливо, чого я хочу. Ми просто знайомилися.

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

3.Попросив ChatGPT сформувати мій цифровий профіль на основі всього, що він про мене знав, і завантажив цей профіль у Claude.

4.Завантажив усі свої резюме та свої статті, які знайшов на Lifehacker.

5.По академії завантажив 20 перших презентацій курсів, усі презентації одного окремого курсу, список усіх курсів, статистику й аналітику.

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

Формулюйте завдання як KPI: що на виході, якої якості, для якої аудиторії. Слово «напиши» — це не завдання. Напиши job description на 280–320 слів для senior backend Go-розробника — це завдання. Тут чудово працює логіка постановки цілей за SMART: що конкретніше й детальніше, то кращий результат.

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

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

Коли я вчив Claude готувати інструменти для моїх курсів, я завантажив до 200 прикладів тих інструментів, які мені подобаються, — зроблених мною або знайдених, — і сказав: «Ось, я хочу так». Модель видобула з них принципи, і тепер я використовую це для створення нових інструментів.

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

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

Заборонено: корпоративні кліше, фрази «сімейна атмосфера»,

«багатозадачність».

Обов'язково: компенсаційна вилка, політика щодо віддаленої роботи.

У мене теж є набір постійних правил. Наприклад, на певному етапі я помітив, що модель вигадує посилання — на курси академії, на мене, на щось іще. Я прописав прямо: ніколи не вигадуй посилань, завжди питай у мене. Потім додав: ніколи не вигадуй фактів і цифр, завжди шукай в інтернеті. Багато хто також просить не використовувати довге тире як ознаку машинного тексту. Особисто я не вважаю, що це погано; просто треба вміти користуватися.

Формат задає рівно ту форму, яка вам потрібна на виході: markdown, JSON, таблиця, лист. «Зроби презентацію» — невідомо, що ви отримаєте. «Зроби презентацію в PowerPoint» — отримаєте PowerPoint. «Зроби таблицю» — незрозуміло. «Зроби таблицю в Excel із шістьма вкладками, зведеними таблицями та графіками» — отримаєте рівно те, що просили.

Приклад із моєї практики: я використовую Claude для повідомлень у наш Telegram-канал і завжди прошу застосовувати формат розмітки Telegram — там є виділення жирним, цитати в окремому блоці та інші елементи. У підсумку я отримую готове повідомлення, копіюю його, і воно одразу гарно виглядає.

Це крок самоперевірки. Навіть хороша модель під час генерації може «піти вбік», і ви отримаєте трохи не те, що хотіли.

Класичний приклад: у повідомлення при додаванні в контакти в LinkedIn є ліміт у 300 символів. Навіть якщо ви прямо написали «до 300 символів», ви цілком можете отримати 310. А якщо ви додасте: Перед видачею перевір, що повідомлення справді вкладається в 300 символів, — модель сформує текст, перевірить себе, скаже «справді, більше» й перепише. Просити її про це абсолютно нормально.

Промпт-інженерія як напрям з’явилася приблизно два роки тому: про неї почали писати, з’явилися вакансії, з’явилися готові фреймворки. По суті це ті самі сім блоків, лише різні автори по-різному їх стиснули й по-різному назвали. Показово, що роль є всюди: у RISEN це Role, у CRISP — Personality, у RTF — Role, у CREATE — Character.

RISEN — для процесів

RISEN веде модель по етапах. Приклад:
Role: ти recruitment lead, вибудовуєш воронку найму Senior Backend Go.
Input: вакансія відкрита 3 тижні, потік 8 резюме на тиждень,
конверсія в офер — 0%.
Steps: 1) діагностика причин низької конверсії; 2) п'ять гіпотез
із метриками; 3) план експерименту на 2 тижні.
Expectation: діагностичний звіт із пріоритизацією гіпотез
за impact/effort.
Narrowing: не пропонуй рішень поза межами повноважень рекрутера.

CRISP — для стратегічних текстів

CRISP змушує модель зайняти точку зору, а не залишитися нейтральною.
Capacity: ти people officer із 15-річним досвідом у скейлапах,
які росли зі 100 до 1000 людей.
Insight: більшість HR-стратегій 2026 року копіюють 2022 рік,
ігноруючи зсув, спричинений ШІ.
Statement: сформулюй три принципи HR-стратегії 2026 року,
без яких компанія програє ринок праці.
Personality: прямий, конкретний, із цифрами, без евфемізмів
і корпоративних кліше.
Experiment: дай три версії — радикальну, збалансовану,
еволюційну — і покажи вигоди та витрати кожної.

CREATE — для контентних артефактів

Найпродуманіший із чотирьох, бо включає і приклади, і тип результату.
Character: сеньйор-техрекрутер, 8 років у продуктових компаніях.
Request: JD для senior backend Go, 280–320 слів.
Examples: стиль «ми будуємо систему, де...», дієслова замість
абстракцій.
Adjust: якщо стек вузький — додай порівняння з альтернативами
на ринку.
Type: markdown із розміткою заголовків, три розділи,
чек-лист вимог.
Extras: компенсаційна вилка, тривалість процесу — 10 днів.

RTF — для швидких операцій

Мінімальний формат. Приклад: Role: senior-рекрутер. Task: переказати резюме кандидата в п'ятисекундний тизер для наймаючого менеджера. Format: три булети — досвід релевантний / релевантний із застереженнями / червоні прапорці. За 30 секунд ви отримуєте те, що менеджер прочитає на ходу. Ідеально для скринінгу.

Який фреймворк під яке HR-завдання

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

1.Зафіксувати роль і аудиторію. Вузька роль, рівень експертизи, хто читатиме результат, тон голосу. Від аудиторії напряму залежить формат тексту.

2.Завантажити контекст. Бажано мати контексти заздалегідь підготовленими. Я, наприклад, зібрав разом із Claude набір MD-файлів: в одному моя біографія, в іншому інформація про академію, у третьому мій формат написання статей, десь фірмові кольори. Під різні завдання я підвантажую потрібний.

3.Сформулювати завдання як KPI. Довжина, аудиторія, термін, пріоритет.

4.Додати приклади. Обов’язково прямо вказати: «ось це — приклад».

5.Прописати перевірки та обмеження. Можна чек-листом або булетами. Окреме корисне правило — просити модель ставити уточнювальні питання щоразу, коли вона сумнівається.

•«Допоможи мені із цим завданням» — без ролі та без контексту.

•Один довгий абзац без структури.

•Повна відсутність прикладів.

•«Зроби коротше» в кінці замість нормального блоку формату.

•Відсутність правил перевірки — у підсумку ви ловите помилки очима.

Кожна з цих помилок усувається додаванням одного із семи блоків.

Раз уже ми в HR любимо метрики, ось метрики для промтів — з орієнтирами.

Рахувати їх «по-бухгалтерськи» не обов’язково, але звертати увагу варто. Я, наприклад, дивлюся на час: якщо завдання зайняло підозріло багато, я прямо пишу моделі: «Давай зробимо ретроспективу. Чому на це пішло стільки часу? Що завадило?» Із цим вона працює добре, і я виношу уроки на майбутнє.

Я ставлю Claude на перше місце — це мій свідомий вибір за досвідом. У мене є підписки на ChatGPT, Grok, Gemini і Claude, тобто це не питання доступу. Просто я бачу, що Claude працює краще. Крім них є Perplexity і вузьконішеві альтернативи на кшталт Mistral.

Важливий момент про кросплатформність: сервіси конкурують і впроваджують схожі речі, називаючи їх по-різному.

1.Визначте свій поточний рівень: користувач, prompt user чи промпт-інженер.

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

3.Зберіть свої контекстні файли: про компанію, про команду, про ваш стиль. Тримайте їх напоготові.

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

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

6.Завжди додавайте блок валідації в завданнях, де є жорсткі ліміти.

7.Вимірюйте п’ять метрик хоча б на око й порівнюйте з орієнтирами.