У постійних правилах асистента мають бути шість блоків, і кожен займає кілька рядків: мета ролі, джерела, тон, заборони, формат відповіді і момент, коли ескалювати людині. Разом це приблизно сторінка тексту, яка діє в кожній розмові. Все, що змінюється щотижня, від свіжих цифр до чернеток і нотаток із дзвінків, живе окремо, у файлі або в самому запиті. Короткий контракт на роль, а робочий матеріал поруч. Асистент плутає задачі тоді, коли в одному полі лежить уся ваша wiki, і модель мусить щоразу вгадувати, яка її частина стосується сьогоднішнього запиту.
До цієї відповіді я дійшов на власній помилці. У проєкті Mpatsan я збирав асистента для повторюваної роботи: статті для сайту, дописи для Telegram, підготовка матеріалів під тиждень. Першу версію правил я написав так, як пишуть більшість підприємців: скопіював у поле все, що мав. Тижневий контекст із темами і дедлайнами, voice locks із зафіксованим голосом, BAN-список заборонених слів і конструкцій, нотатки з розмов із клієнтами, два приклади вдалих статей, формат допису і гейт "так" перед публікацією: жоден текст не йде на сайт, поки я особисто не напишу це слово. Вийшло кілька сторінок, і першого ж дня я запустив тест. Попросив статтю на тему з тижневого плану. Асистент видав текст, у якому посередині стояв абзац у ритмі Telegram-допису, наприкінці висіли тези з нотаток про чужий проєкт, а сам матеріал закінчувався закликом підписатися на канал. Кожен шматок окремо був правильним, бо все це лежало в правилах. Разом вийшла суміш трьох задач. Я цей тест відхилив і сів переписувати правила.
Коротко
- Постійні правила асистента працюють як контракт на роль: шість блоків на одну сторінку, які діють у кожній розмові.
- Шість блоків: мета ролі, джерела, тон, заборони, формат, коли ескалювати людині.
- Разовий промпт описує сьогоднішню задачу, постійні правила описують, ким асистент є завжди.
- Змінне тримайте у файлі або в запиті: тижневий контекст, свіжі цифри, чернетки, нотатки.
- Вся wiki в одному полі змушує модель вгадувати, що з цього стосується поточної задачі, і вона починає змішувати ролі.
Разовий промпт і постійні правила: у чому різниця
Промпт буває двох видів. Разовий ви пишете в чаті під конкретну задачу: "підготуй відповідь клієнту на цей лист", "зведи продажі за тиждень". Він живе одну розмову і зникає разом із нею. Постійні правила, які в англомовних інструкціях називають standing rules, ви пишете один раз, і вони підмішуються до кожного запиту в межах проєкту. У ChatGPT це поле інструкцій проєкту або custom GPT, власної версії асистента під вашу роботу. В іншому популярному асистенті те саме називається Gem. Назви різні, механіка однакова: текст, який модель читає перед кожним вашим повідомленням.
Звідси проста межа. Все, що лежить у постійних правилах, модель сприймає як завжди актуальне. Якщо туди потрапили нотатки про конкретного клієнта, асистент згадуватиме їх у листах іншим клієнтам. Якщо там лежать тижневі дедлайни, через місяць він нагадуватиме про дедлайни, які давно минули. Постійні правила мають містити тільки те, що правдиве в понеділок, у пʼятницю і через пів року.
Мені ця логіка знайома з фінансових ринків. За вісімнадцять років я бачив сотні інвестиційних декларацій, документів, які клієнт і менеджер підписують на старті співпраці. У декларації записані мета, горизонт, допустимий ризик, заборонені інструменти і випадки, коли менеджер зобовʼязаний подзвонити клієнту. Новин ринку, котирувань і думок про поточний квартал там немає, вони живуть у щотижневих звітах. Декларація тримає рамку роками, а звіти змінюються щотижня. Правила асистента влаштовані так само.
Шість блоків, які тримають роль
Мета ролі. Два-три речення про те, для чого існує цей асистент і для кого він працює. "Ти готуєш статті для розділу Думки на сайті Михайла Пацана. Читачі: власники малого бізнесу і менеджери, які тільки починають працювати з ШІ та інвестиціями." Цей блок відповідає на питання, яке модель ставить собі першим: що я тут роблю. Коли роль описана одним реченням, асистенту легше відмовитися від чужої задачі.
Джерела. Звідки асистент бере факти і в якому порядку їм довіряє. "Спирайся на прикріплені файли проєкту і на матеріал, який я даю в запиті. Якщо факту немає в джерелах, пиши, що його немає." Тут же назвіть, які файли за що відповідають: окремий файл зі стилем, окремий із прикладами, окремий із поточним тижнем.
Тон. Коли власники питають мене про тон бренду в асистенті, вони мають на увазі саме цей блок: як звучить компанія, коли говорить із клієнтом. У мене це перша особа, жива літературна українська, підрядні речення замість телеграфних фраз, іронія без знаків оклику. Для інтернет-магазину це може бути "звертаємося на ви, тепло, без канцеляриту, коротко". Три-чотири рядки з ознаками і один короткий приклад дають моделі більше, ніж абзац прикметників. Приклад краще брати з реального листа, який вам сподобався, бо модель підхоплює ритм і довжину речень точніше, ніж будь-який опис. Якщо в компанії кілька каналів, де тон різний, зробіть кількох асистентів, а не вписуйте в одні правила три манери одночасно.
Заборони. Сюди потрапляє BAN-список: слова, конструкції, знаки, теми. Заборони працюють найкраще, коли кожна сформульована одним рядком і, де можливо, з заміною: замість довгого тире дефіс, замість одного слова інше. Список на пів сторінки з пояснення, чому кожне слово погане, модель читає гірше, ніж короткий перелік.
Формат. Як виглядає результат: структура, обсяг, заголовки, куди ставити посилання, у якому вигляді віддавати файл. Для статті це послідовність розділів і діапазон слів, для відповіді клієнту це "до пʼяти речень, в кінці пропозиція наступного кроку".
Коли ескалювати людині. Ескалювати означає передати питання тому, хто має право вирішити, так само як у магазині кличуть старшого зміни, коли покупець просить знижку, яку касир дати не може. У правилах це кілька умов: "якщо запит стосується грошей, повернення або скарги, підготуй чернетку і познач її для мене"; "перед публікацією чекай мого слова так". У мене тут живе гейт публікації. Асистент має знати заздалегідь, коли зупинятися, а не вирішувати це в моменті.
Змінне у файлі або в запиті, wiki поза полем
Після того тесту я розклав матеріал на три шари. Постійні правила скоротилися до сторінки з шістьма блоками. Voice locks і BAN-список переїхали в окремі файли проєкту, а в правилах лишилося одне речення: "стиль бери з файлу style-rules, заборони з файлу ban-list". Тижневий контекст я тепер даю в запиті або окремим файлом, який замінюю щопонеділка. Нотатки з клієнтських розмов у проєкт статей більше не потрапляють узагалі, для них є інший асистент з іншою роллю.
Хаос нікуди не зник, він переїхав туди, де йому місце. Сирі думки, голосові розшифровки, уривки листів я вкидаю в чат, і асистент працює з ними в межах однієї задачі. Короткий контракт у правилах тримає роль, тому з того самого хаосу виходить стаття, а не допис і не протокол зустрічі.
Для тих, хто шукає, як написати інструкцію для custom GPT, я формулюю це так. Wiki компанії це довідник, асистент це співробітник на конкретній посаді. Співробітнику в перший день дають посадову, доступ до папок і людину, до якої йти з питаннями. Весь довідник йому на стіл не кладуть, бо тоді він читатиме все підряд і відповідатиме з першого розділу, що трапиться. Модель поводиться так само, тільки швидше.
Як я тестую правила перед роботою
Правила асистента я випробовую на трьох запитах, перш ніж довіряти йому щоденну роботу. Перший запит типовий, заради якого асистент існує. Другий на межі ролі: для асистента статей це прохання написати допис для Telegram. Правильна реакція тут така: асистент або уточнює, або нагадує, що допис готує інша роль. Третій запит вимагає ескалації: у мене це прохання опублікувати текст одразу. Асистент з правильними правилами готує чернетку і чекає мого "так".
Перша версія моїх правил провалила всі три запити, і тест, який я відхилив, був лише найпомітнішим. Друга версія пройшла всі три з першої спроби, хоча модель була та сама. Змінився контракт. Відтоді я повторюю ці три запити щоразу, коли щось додаю в правила, бо кожен новий рядок здатен зсунути роль, і помітити це найлегше саме на межі.
Що робити далі
- Відкрийте постійні правила свого асистента і позначте все, що змінюється частіше, ніж раз на місяць: цифри, дедлайни, нотатки, чернетки. Винесіть це у файл або в запит.
- Перепишіть те, що лишилося, у шість блоків: мета ролі, джерела, тон, заборони, формат, коли ескалювати людині. Тримайте загальний обсяг у межах сторінки.
- Великі довідкові матеріали, як-от стиль, заборони і приклади, покладіть окремими файлами проєкту і пошліться на них у правилах одним реченням.
- Запишіть у шостий блок дві-три умови, за яких асистент готує чернетку і чекає вашого рішення, зокрема все, що стосується грошей, клієнтів і публікації.
- Проженіть три тестові запити: типовий, на межі ролі і такий, що вимагає ескалації. Відхиляйте кожну відповідь, де асистент змішав задачі, і правте правила, а не запит.
Про цей матеріал
Це освітній матеріал про налаштування ШІ-асистентів для малого бізнесу. Приклади з власної роботи автора подані узагальнено, назви інтерфейсів і полів у різних сервісах можуть змінюватися з часом. Матеріал не є інвестиційною, юридичною чи іншою професійною порадою.