Модель отримує один довгий текст. У ньому: системний промт сервісу, твої постійні інструкції, файли проєкту, історія розмови - і десь наприкінці твоє повідомлення. Модель не відрізняє "промт" від "решти": для неї це один суцільний вхід.
Звідси перший висновок. Шліфувати одне речення в кінці довгого входу - слабкий важіль. Сильні важелі - решта входу: що лежить в інструкціях, які файли додані, що накопичилося в історії. Питання "як сформулювати запит" насправді звучить "що модель знає про мою задачу".
Порівняй два входи. Перший: "перевір договір" плюс файл. Другий: той самий файл плюс політика компанії щодо договорів, перелік типових ризиків цієї категорії, приклад попереднього висновку і згадка, для кого висновок пишеться. Модель та сама, формулювання однакове - результати непорівнянні.
Механізм простий: модель добудовує те, чого не сказано, з найзагальніших закономірностей. Без контексту вона вгадує, що тобі треба, - і вгадує "середню по інтернету" відповідь. З контекстом вгадувати нема чого. Тому найкраща інвестиція часу перед запитом - не переписування речення, а збирання матеріалу: документи, приклади, обмеження.
Другий сильний важіль - чіткий образ доброго результату. Формат: таблиця, меморандум, лист. Обсяг: сторінка чи десять. Критерії: що обовʼязково має бути всередині, чого бути не повинно. Найсильніший варіант - приклад: "ось висновок, який нас влаштував минулого разу, зроби в цьому форматі".
Розписувати процес крок за кроком здебільшого не треба: шлях модель обере сама, і часто кращий за продиктований. Виняток - коли процес і є вимогою: методика розрахунку, порядок перевірки, регламент. Тоді процес - це частина опису результату.
Коли результат не той - не переписуй запит з нуля і не додавай "будь уважнішим". Скажи, що саме не так, як у правці колезі: "розділ два поверхневий, розгорни аргументацію по строках". Це додає контекст. Загальні заклинання не додають нічого.
Частину задач не витягне жодне формулювання, бо їм бракує не слів, а можливостей. Розрахунок стає надійним, коли модель пише код або формули, а не передбачає цифри. Питання про свіже стає точним, коли увімкнений пошук. Робота з документами - коли файли передані, а не переказані.
Тому коли результат слабкий, спершу перевір не формулювання, а оснащення: чи має асистент доступ до того, з чим працює? Приріст від правильно підключеного інструмента зазвичай більший, ніж від будь-якої правки тексту запиту.
Разовий вдалий запит зникає разом з чатом. Робочий шлях - накопичення: вдале формулювання переїжджає в постійні інструкції, повторювана задача - у проєкт з файлами і шаблонами, регулярний процес - у збережений конвеєр, який запускається однією командою.
З кожним кроком запити стають коротшими: контекст уже вбудований, критерії вже записані. Досвідчений користувач пише "зроби апдейт по справі" - і отримує результат кращий, ніж новачок з ретельно виписаним запитом на пів сторінки. Різниця не в таланті формулювання, а в накопиченому сетапі.
І головна звичка: коригуй сетап, а не слова. Кожна помилка моделі - це питання "чого їй бракувало?" Відповідь іде в інструкції або файли проєкту - і помилка не повторюється. Так "метод тику" перетворюється на систему, яка щотижня працює трохи краще.