Як сформулювати задачу, щоб не перепитували
Версія: 26.08.2026
Головне правило документації звучить так:
«Уявіть Claude блискучим, але новим працівником, який не знає ваших звичаїв і порядків».
Новий працівник розумний. Він просто не знає, що у вас вважається нормою. Тому «зроби добре» він виконати не може – він не знає, що у вас «добре».
Золоте правило перевірки
Дослівно з документації:
«Покажіть свій запит колезі, який мало знає про задачу, і попросіть його виконати. Якщо він розгубиться – розгубиться і Claude».
Це перевірка на тридцять секунд. Вона економить годину переписок.
Чотири речі, яких майже завжди бракує
1. Що саме на виході. Не «напиши про доставку», а «п'ять пунктів, кожен до двох рядків, для сторінки товару».
2. Для кого. Текст для бухгалтера і текст для покупця – це різні тексти.
3. Обмеження. Обсяг, тон, чого не можна писати, які слова не вживати.
4. Чому. Про це окремо нижче – це найнедооціненіше.
Скажіть, чому
Документація дає цей приклад дослівно.
Слабко:
НІКОЛИ не вживай три крапки.
Сильно:
Твою відповідь читатиме синтезатор мовлення, тому ніколи не вживай три крапки – він не знає, як їх вимовити.
І висновок там же: «Claude достатньо розумний, щоб узагальнити з пояснення».
Різниця в тому, що в першому випадку він виконує заборону. У другому – розуміє мету і сам відловить схожі випадки, про які ви не подумали.
Просіть більше, ніж мінімум
Ще один приклад з документації.
Слабко: «Створи панель аналітики».
Сильно: «Створи панель аналітики. Додай якомога більше доречних можливостей і взаємодій. Вийди за межі базового і зроби повноцінну реалізацію».
Пояснення там же: якщо вам потрібна робота «понад норму», просіть про неї прямо. Не сподівайтеся, що модель здогадається з розпливчастого запиту.
Кроки – нумерованим списком
Документація радить давати інструкції послідовними кроками, коли важливий порядок або повнота.
Абзац з трьома вимогами всередині читається гірше за три пронумеровані рядки. Це справедливо і для людей, і для моделі.
Дайте приклад
Цитата: приклади – «один з найнадійніших способів задати формат, тон і структуру».
Рекомендація документації: від трьох до п'яти прикладів. Вони мають бути близькі до вашого реального випадку і достатньо різні, щоб модель не вхопила випадкову закономірність.
Один зразок «ось так має виглядати» працює краще за абзац опису формату.
Дайте роль
Одне речення про те, ким Claude має бути, вже змінює відповідь. Так каже документація: навіть одне речення дає різницю.
Але не плутайте роль з фокусом. Про це – наступна сторінка, і вона важливіша за цю.
Проста заготовка
Задача: [що зробити]
Для кого: [хто читатиме]
Чому це важливо: [навіщо]
На виході: [формат, обсяг]
Чого не робити: [обмеження]
Ось зразок того, що я вважаю добрим: [приклад]
Це не магічний шаблон. Це просто перелік того, що ви й так знаєте, а модель – ні.
Найчастіша помилка
Питати «як краще?» замість «зроби, обери один варіант і поясни вибір».
На перше питання ви отримаєте перелік варіантів з плюсами й мінусами. На друге – позицію, з якою можна працювати.
Джерела
- Усі цитати й приклади: platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices – звірено 25.08.2026