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

Если вы хотите взять с этого списка только один совет, сосредоточьтесь на варианте с минимальными усилиями и максимальным эффектом: укажите причины своих ограничений и явно разрешите модели говорить, что она не знает ответа. Эти два простых шага уже помогли решить больше проблем с качеством вывода, чем любая сложная структурная схема.

Если вы не согласны с какой-либо частью этого рейтинга или обнаружили, что один из этих методов на самом деле вредит вашему конкретному случаю использования, такой противоположный пример гораздо полезнее, чем ещё одна общая статья вроде «Призывы, которые изменят вашу жизнь».