30 практичних технік формулювання запитів до Claude з реального щоденного використання

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

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

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

Їх класифікують на чотири групи за тим, що саме досягає кожна техніка на практиці, а не за тим, наскільки складною вона звучить на папері:

Part 1 — Say What You Mean          (clarity & structure)
Part 2 — Put Up Guardrails          (constraints & format control)
Part 3 — Make It Reason Out Loud    (thinking & iteration)
Part 4 — Build a System, Not a Prompt (workflows & long context)

Частина 1 — Формулюйте чітко

1. Будьте конкретні, а не розпливчасті

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

Корисне правило: якщо на написання запиту йде менше 10 секунд, він, ймовірно, недостатньо конкретний.

2. Використовуйте структурні теги для розділення частин вашого запиту

Теги у стилі XML варто використовувати постійно — не через твердження, що це „рідна мова“ Claude (таке твердження важко перевірити, і його слід сприймати з скепсисом, якщо воно висловлюється з абсолютною впевненістю), а тому що теги вирішують реальну, практичну проблему: коли інструкції, контекст та приклади змішуються в одному блоку тексту, моделі доводиться здогадуватися, де починається та закінчується кожен розділ. Теги повністю усувають цю необхідність у здогадках.

<instructions>
Summarize the risks section only. Ignore financial projections.
</instructions>
<context>
[pasted document]
</context>
<output_format>
3 bullet points, no more than 15 words each
</output_format>

3. Спочатку контекст, потім запитання

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

[long document]
---
Based on everything above, what's the single biggest
risk to the Q3 timeline?

4. Покажіть, а не просто описуйте (приклади з кількома варіантами)

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

5. Пояснюйте причину, а не лише правило

Це один із найбільш несподіваних методів у цьому списку. Технічно працює запит до Claude на кшталт „збережи це до 280 символів“. Але запит у форматі „цей текст потрапить безпосередньо у твіт, і все, що перевищує 280 символів, буде обрізано посеред речення“ призводить до значно уважнішого результату. Здається, що наведення причини змушує модель враховувати це обмеження протягом усього відповіді, а не лише підраховувати символи наприкінці.

6. Прямо дозволити варіант „Я не знаю“

Одну рядок варто додати майже до кожного запиту на дослідження чи аналіз:

If the available information isn't enough to draw a
conclusion, say so directly instead of guessing.

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

7. Вказуйте формат вихідних даних, не припускайте його

Існує суттєва різниця між проханням «таблицю» та проханням «таблицю у простому текстовому форматі, яка буде коректно вставлятися у блок коду, адже Medium зазвичай порушує форматування таблиць у Markdown». Чітке описання саме такого формату бажаної відповіді повністю усуває таку невідповідність.

8. Визначте, як виглядає «завершене» завдання, а не лише саме завдання

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

I need a competitor comparison so my co-founder can
pick a pricing tier in under 5 minutes without asking
me follow-up questions.

Це одне речення має більшу вагу, ніж три абзаци правил форматування.

Частина 2 — Встановлення обмежень

9. Негативні обмеження — вкажіть, що система не повинна робити

Іноді швидше визначити ціль, виключивши те, чого не хочеться, ніж намагатися точно визначити те, чого саме хочеться:

Do not sound like: a LinkedIn thought-leader post.
Do not include: "in today's fast-paced world," filler
caveats, or a summary that repeats the intro.

10. Запит системи у стилі „контракту“

Для всього, що планується використовувати знову, напишіть запит системи у вигляді короткого юридичного контракту, а не опису персонажа:

Role: technical editor for a solo dev's blog
Goal: tighten prose without changing meaning
Constraints:
 - keep first-person voice
 - no invented statistics
 - flag anything that sounds AI-generated
If unsure: ask one clarifying question, don't guess
Output: plain markdown, no headers added

11. Уникайте сценарію „діяти як старший експерт“

Це метод, який варто відмовитися від нього. Наказувати Claude „діяти як інженер з 20-річним досвідом“ майже не змінює ситуацію, якщо ваші інструкції вже точні. Використання певного образу має значно менше значення, ніж фактичні обмеження, які ви встановлюєте. Спроба компенсувати брак конкретики за допомогою ролі зазвичай є ознакою того, що самі інструкції потребують уточнення.

12. Самооцінка за шкалою

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

Score your draft 1-10 on: technical accuracy, whether
a beginner could follow it, and whether it sounds
like a real person wrote it. Then revise based on
your own score. Show only the revised version.

Цей підхід неодноразово допомагав виявити справжні помилки в поясненнях коду та узагальненнях даних.

13. Сортуйте довгі документи, а не кидайте все разом

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

Step 1: extract the 5 passages most relevant to
[my question], quoting them exactly.
Step 2: analyze only those passages.

14. Позначте кілька документів під час порівняння джерел

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

<document index="1" name="Q3_report.pdf">...</document>
<document index="2" name="Q2_report.pdf">...</document>

15. Чіткі межі для структурованого виводу

Коли потрібен суворий формат JSON або певна схема, необхідно прямо це зазначити та перелічити точні ключі, замість того щоб описувати структуру у загальних рисах та сподіватися, що модель правильно її зрозуміє:

Return only a JSON object with keys: title, summary,
confidence (0-1), open_questions (array of strings).
No text before or after the JSON.

Частина 3 — Змусіть модель пояснювати вголос

16. Прохайте про поетапне обґрунтування для будь-яких складних завдань

Додавання рядка, який просить модель розв’язувати проблему поетапно перед наданням кінцевої відповіді та вказувати на всі межові випадки, потребує більше зусиль, ніж може здатися. Цей підхід варто застосовувати до всього, що пов’язано з математикою, багатокроковою логікою чи рішеннями, які передбачають компроміси. Його ігнорування у завданнях, які здаються „очевидно простими“, саме тоді, коли щось зазвичай йде не так.

17. Використання ланцюга запитів замість одного великого запиту

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

[1] extract key facts
      |
      v
[2] turn facts into a 3-paragraph summary
      |
      v
[3] turn summary into 5 short takeaways

18. Зворотне брейнштормінг для рішень, що застрягли

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

Brainstorm 10 ways this launch could fail. For each
one, invert it into a concrete thing we'd do
differently. Flag the 3 inversions that are the least
obvious.

Цей підхід виявляє сліпі зони, які часто залишаються непоміченими при прямому запиті „надайте стратегію“.

19. Дебати з кількома персонажами для рішень із справжніми компромісами

Це, можливо, найефективніша техніка з усього списку. Для прийняття рішень, пов’язаних із суперечливими стимулами, попросіть Claude обґрунтувати свою думку з кількох різних точок зору, перш ніж узагальнити все в рекомендацію:

Optimist            Skeptic           End user
      "ship faster"      "watch runway"    "don't care
           |                   |            about our
           v                   v             problems"
            \                 |                /
             \                |               /
              \               |              /
               v              v             v
                    synthesized recommendation

Запит типу „Просто дайте мені вашу рекомендацію“ зазвичай призводить до вибору тієї відповіді, яка звучить найбільш прийнятно. Якщо спочатку змусити систему провести внутрішню дискусію, результат буде більш чітким та обґрунтованим.

20. Самокритика та корекція в одному кроці

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

Draft 1 -> list 3 weaknesses in Draft 1 -> Draft 2

21. Дозвольте системі поставити уточнювальні запитання перед виконанням роботи

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

22. Метапромптинг — змусіть його покращити ваш промпт

Цей метод рідко використовується. Коли промпт продовжує генерувати посередні результати, замість того щоб переписувати його самостійно, запитайте безпосередньо:

Here's the prompt I've been using: [paste]. Here's the
output it produces: [paste]. What's wrong with the
prompt, and rewrite it.

Це часто виявляє нечіткі формулювання, яких ви самі не могли помітити, переважно тому, що ви вже знаєте, що мали на увазі, та пропускаєте неоднозначності.

23. Ставтеся до цього як до розмови, а не до єдиного ідеального промпта

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

Частина 4 — Створіть систему, а не запит

24. Використовуйте файли з постійними правилами замість повторення одного й того ж

Це, можливо, найцінніша зміна звички серед усіх. Замість того, щоб заново вводити тон, аудиторію та обмеження в кожен новий запит, зберігайте їх у окремому файлі rules.md:

# Writing rules
- tone: direct, no fluff
- audience: builders, not consumers
- never use: "leverage", "in today's world"
- always: specific numbers, source links, one action item
- format: short paragraphs, 3 sentences max

Потім на початку кожної сесії вказуйте на нього: «Уважно прочитайте rules.md перед початком. Якщо ви збираєтесь порушити одне з цих правил, зупиніться та скажіть мені про це».

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

25. Чітко сформулюйте цикл планування, дії, перевірки та ітерацій

У випадку агентської роботи — багатоетапних завдань, де Claude використовує інструменти, редагує файли чи виконує команди — не припускайте, що модель сама організує процес. Описайте цей цикл прямо:

 ┌─────────┐    ┌────────┐    ┌────────┐    ┌────────┐
 │  PLAN   │ -> │  ACT   │ -> │ VERIFY │ -> │ ITERATE│
 │ max 5   │    │ use    │    │ against│    │  or    │
 │ steps   │    │ tools  │    │criteria│    │ done   │
 └─────────┘    └────────┘    └────────┘    └────────┘
                                  |  fail
                                  v
                             back to ACT

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

26. Ґрунтуйте твердження у отриманих фактах, а не у пам’яті

Для будь-якої фактичної інформації чітко накажіть моделі черпати дані з матеріалу перед нею, а не згадувати їх з процесу навчання. Запит на те, щоб вона „навела конкретний рядок чи розділ, звідки це взято“, перетворює правдоподібну відповідь на таку, яку можна дійсно перевірити. Якщо вона не може вказати джерело, сприйміть це як сигнал зупинитися та перевірити все вручну.

27. Встановлюйте людські контрольні точки перед незворотними діями

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

28. Розпізнавайте, коли величезний запит — це не правильний підхід

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

29. Керуйте версіями своїх запитів так само, як керуєте версіями коду

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

30. Виконуйте робочий процес локально, якщо хочете уникнути витрат за кожен токен або не передавати дані на зовнішні сервери

Жодна з цих технік не вимагає обов’язково API на хостингу. Для всього, що потребує багаторазових ітерацій — тестування шкали самооцінки чи описаного вище циклу планування/дії/перевірки — часто має сенс спочатку створити прототип за допомогою локальної моделі Ollama, а потім перенести готовий запит до Claude для фінальної обробки. Таким чином ітерації коштують дешевше, і поки ви ще формуєте запит, нічого не залишається поза вашим пристроєм.

Версія на хостингу для швидкого тестування з API Claude:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 500,
    "messages": [{"role": "user", "content": "Score this draft 1-10 on clarity, then revise it: [paste draft]"}]
  }'

Локальна, самохостована альтернатива з використанням Ollama, без ключа API та без оплати за кожен токен:

# one-time setup
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama pull llama3.1
# same self-evaluation prompt, run locally
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1",
  "prompt": "Score this draft 1-10 on clarity, then revise it: [paste draft]",
  "stream": false
}'

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

Швидкий огляд: зусилля проти результату

Ось приблизний рейтинг, заснований на тому, які методи дійсно покращують якість результату, а які лише звучать вражаюче:

TECHNIQUE                             EFFORT TO ADOPT   PAYOFF
----------------------------------    ----------------  --------
Rules/context file (#24)              low                very high
Multi-persona debate (#19)            low                high
Plan-act-verify loop (#25)            medium             high
Prompt chaining (#17)                 low                high
Permission to say "I don't know"(#6)  trivial            high
Explain the "why" (#5)                trivial            high
Reverse brainstorming (#18)           low                medium-high
Contract system prompt (#10)          medium             medium
"Act as an expert" persona (#11)      trivial            low

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

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