Промпт як специфікація задачі, не як заклинання

Промпт як специфікація задачі, не як заклинання

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

Коротко

• Промпт описує задачу так само, як ви описуєте її живому підряднику: роль, мета, аудиторія, обмеження, формат і те, що вважати помилкою.
• Фраза "напиши клієнту про знижку" без політики компанії задачею ще не є; модель заповнює порожнє місце вигаданим відсотком і тоном масової розсилки.
• Універсальні "суперпромпти" з інтернету нічого не знають про ваш прайс, ваш кабінет Нової Пошти і манеру спілкування у вашому Telegram.
• Обмеження і критерій помилки рятують від інцидентів сильніше за гарну роль у першому рядку.
• Команди, які виграють, тримають короткі специфікації поруч з Excel і SOP; ті, що відстають, шукають секретну формулу на дві сторінки.

Коли менеджер відділу продажів вставляє в ChatGPT три слова про знижку і отримує текст із відсотком, якого немає в жодній політиці, керівник зазвичай робить висновок про "поганий ШІ". Я за вісімнадцять років на ринках бачив таку саму реакцію на будь-який новий інструмент: винна система, а не постановка задачі. У Learn to Earn Global на кейс-днях ми розбираємо такі інциденти як дірку в технічному завданні, і після цього розмова про "містику моделі" зазвичай закінчується. Нижче каркас, яким я сам користуюся, коли переходжу від "напиши красиво" до робочого промпта для ФОП.

Сцена зі знижкою, якої не було в політиці

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

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

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

Промпт як технічне завдання

Правильна робота з промптом починається з визнання: перед вами технічне завдання. У звичайному житті ви не скажете підряднику "зроби мені сайт гарно" і не чекатимете ідеальної здачі. Від моделі чомусь чекають саме цього.

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

Магія у щоденній операційці закінчується на першому вигаданому відсотку знижки або на першому фантомному треку Нової Пошти. Далі лишається тільки ТЗ.

Роль, мета й аудиторія

Роль задає кут зору, але фактів вона не додає. Формулювання "ти досвідчений менеджер українського інтернет-магазину" допомагає з тоном і структурою. Прайсу з вашого Excel воно не бачить і кабінету Нової Пошти не відкриває.

Мету треба вимірювати в артефакті. "Чернетка відповіді до 700 знаків без нової знижки" сильніша за розмите "допоможи продати". Аудиторія змінює словник: клієнт у Telegram читає інакше, ніж бухгалтер, який чекає рахунок, а той інакше, ніж партнер, якому ви пишете про зміну умов постачання.

У AISync Global на пілотах ми регулярно бачимо гарну роль у першому рядку і порожню мету далі. Інтерфейс виглядає сучасно, контроль виходу ще не спроєктований. Тому на будь-якому демо я дивлюся не на "корисного асистента", а на те, чи є в промпті обмеження, формат і критерій помилки.

Обмеження і формат економлять інциденти

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

Обмеження перетворюють модель з імпровізатора на виконавця в межах рамки. Без них ви отримуєте креатив там, де потрібна дисципліна каси і складу.

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

Поле "що є помилкою" робить промпт дорослим

Приклади помилок варто проговорити вголос на нараді. З'явилася ціна поза блоком даних. З'явилася обіцянка відправки сьогодні без підтвердження логіста. Тон став фамільярним або, навпаки, канцелярським. Відповідь довша за ліміт. Модель пише так, ніби вже бачила оплату в monobank.

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

Чому універсальні промпти у вашій операційці мовчать

Вони або надто загальні, або заточені під іншу галузь, іншу мову бренду й іншу юридичну рамку. Скопійований "суперпромпт на дві сторінки" займає пів вікна контексту правилами, які вам не потрібні, і витісняє ваш прайс та SOP. Коротка специфікація під ваш процес завжди сильніша за чужий роман.

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

Як ставити задачу ChatGPT на щоденній операційці

Відкрийте новий чат під одну справу. Вставте блок ролі й мети на кілька рядків. Вставте дані з Excel або короткі цитати з листування. Вставте два-три обмеження. Вставте формат. Додайте один короткий приклад "добре" і один "так не писати". Проженіть запит. Прочитайте вихід очима по числах і обіцянках. Якщо треба, поверніть критикою.

Спочатку цей ритуал здається довшим за "напиши красиво". Через тиждень він виявляється коротшим за вечірній розбір клієнтських інцидентів.

Окремий приклад із сервісу. Клієнт питає про повернення. Поганий промпт: "Поясни політику повернення гарно". Нормальна специфікація: роль співробітника підтримки; мета - чернетка відповіді; аудиторія - роздрібний клієнт у Telegram; дані - три речення з вашого FAQ; обмеження - жодних строків повернення коштів, яких немає в FAQ, і жодних звинувачень клієнта; формат - до восьми рядків; помилка - нові строки й умови, яких не було у фрагменті FAQ. Різницю у виході бачить навіть новачок.

Бібліотека специфікацій поруч із джерелом істини

Керівник може зібрати невелику бібліотеку промптів: відповідь на заперечення ціни, запит уточнень для ТТН, ввічлива відмова в знижці, пояснення рядка виписки для внутрішнього обліку, follow-up після відправки. Кожна специфікація живе поруч із джерелом істини: прайсом, SOP, шаблоном. Оновлення прайсу тягне за собою швидкий перегляд пов'язаних промптів. Так промпт лишається живою специфікацією процесу, а не ритуальним текстом у закладках "на всяк випадок".

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

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

Що змінюється за тиждень дисципліни

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

У Learn to Earn Global ми просимо команду зберегти два скріни: запит із трьох слів і той самий запит після специфікації. Контраст переконує швидше за лекцію. Люди бачать, що модель за ніч кращою не стала. Кращим став вхід.

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

Типові дірки, які я бачу в українських ФОП

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

Четверта дірка - відсутність критерію помилки, через що команда сперечається смаками і витрачає час керівника. П'ята - кілька справ в одному чаті: і відповідь клієнту, і пост у канал, і розбір маржі з Excel. Вікно контексту засмічується, жанри змішуються, вихід стає нічийним.

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

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

Візьміть один свіжий запит менеджера з трьох слів і перепишіть його в специфікацію: роль, мета, аудиторія, обмеження, формат, що є помилкою. Додайте в промпт два рядки про знижки й наявність: лише з політики або Excel; якщо даних немає, питання людині. Збережіть у Saved Messages Telegram один робочий шаблон під відповідь клієнту й один під сервіс повернення. На нараді розберіть один інцидент тижня як дірку в ТЗ, а не як випадок, коли "модель підвела". На демо вендора спитайте, де в їхньому промпті стоять обмеження і критерій помилки.

Про цей матеріал

Це текст треку "Мова ШІ" про промпт як специфікацію задачі. Мета - дати команді спільну мову перед розмовою про шаблон чотирьох полів і про читання відповіді моделі перед клієнтом, без колекціонування заклинань із чужих каналів. Матеріал освітній і не є індивідуальною порадою.