Промпт-инжиниринг для Claude: что реально работает

Год назад я скептически относился к самой формулировке «промпт-инжиниринг». Казалось, это надувательство для людей, которые любят красивые термины. После года работы с Claude в проде моя позиция изменилась: промпт — это код, и от его качества качество ответов отличается на порядок. Расскажу, что я понял.

Главное наблюдение

На современных моделях не работают магические заклинания типа «think step by step» или «you are an expert in X». Они и так это делают. Работают:

• Чёткая постановка задачи.
• Контекст без шума.
• Структура ввода и желаемого вывода.
• Примеры (few-shot) для нетривиальных форматов.

Структура промпта

Anthropic в документации советует и я подтверждаю: разделять system-промпт на чёткие блоки. У меня типичная структура такая:

<role>
Ты — ассистент-инженер, который помогает пользователям техподдержки.
</role>

<context>
Продукт — SaaS для управления складом.
Клиенты — небольшие интернет-магазины 5–50 заказов в день.
</context>

<task>
Когда пользователь задаёт вопрос:
1. Если вопрос про API — посмотри в документации (использовать tool docs_search).
2. Если вопрос про настройки — спроси номер аккаунта и используй tool get_account_settings.
3. Если вопрос общий — отвечай по знаниям, добавляй ссылку на доку.
</task>

<style>
Короткие предложения, без воды. Используй markdown для списков.
Первая фраза — суть ответа.
</style>

XML-теги — рабочий способ структурировать. Claude хорошо распознаёт role, context, task, style как разные блоки. Это не магия — просто человек так лучше пишет, и модели легче парсить.

Чёткие инструкции

Замените «отвечай дружелюбно» на «начинай ответ с приветствия, обращайся к пользователю на ты, в конце предлагай задать ещё вопрос». Замените «не выдумывай» на «если в данных нет информации для ответа — пиши “В моей базе этого нет, обратись к менеджеру”. Никогда не пиши, что ты не знаешь точного ответа, если знаешь приблизительный — напиши приблизительный с пометкой».

Конкретика убирает интерпретации.

Few-shot

Где есть формат, дай примеры. Не надо описывать формат словами — покажи 2–3 эталона.

Пример 1:
Инпут: "У меня не приходят оплаты с Тинькоффа"
Категория: payments
Приоритет: high
Комментарий: "проверить webhook от платёжного провайдера"

Пример 2:
Инпут: "Хочу узнать тарифы"
Категория: sales
Приоритет: low
Комментарий: null

Пример 3:
Инпут: "Спасибо за помощь!"
Категория: feedback
Приоритет: low
Комментарий: null

3–5 примеров обычно достаточно. Больше — раздуваешь промпт без пользы. Меньше — модель цепляется не за то.

Структурированный вывод

Если тебе нужен JSON — попроси JSON и покажи структуру. И, что важно, попроси его в специальном теге, чтобы парсить было проще:

Ответь в формате:
<analysis>
краткий разбор задачи в 2–3 предложениях
</analysis>
<result>
{"category": "...", "priority": "...", "comment": "..."}
</result>

Затем парсишь через regex или lightweight парсер. Для ещё большей надёжности — используй tool use с inputSchema, тогда модель строго следует схеме.

Положительные инструкции, не отрицательные

«Не пиши длинно» — слабо. «Каждый ответ — максимум 3 предложения» — сильно. Чем конкретнее формулировка, тем стабильнее результат.

«Не используй сленг» — слабо. «Используй формальный деловой стиль, без жаргонизмов и сокращений» — сильно.

Управление длиной

max_tokens — твой первый рычаг. Не оставляй default 4096 на простую классификацию. Поставь 50 — модель не уйдёт в простыни. И сэкономишь.

В сам промпт добавь явное указание: «Ответ — одно слово из списка [...]» или «Не более 200 символов». Модели слушаются, если просьба чёткая.

Проверка на длинном контексте

Когда у тебя в контексте 50к токенов документа, простая инструкция в начале может «потеряться». Я помещаю критичные инструкции в самом конце системного промпта, прямо перед messages. Anthropic это рекомендует и для русского, и для английского — последние инструкции вес больше.

Также имеет смысл «обрамить» документ:

Ниже идёт документ. Прочти его и ответь на вопрос пользователя.

<document>
{ВЕСЬ_ДОКУМЕНТ}
</document>

Инструкции:
1. Отвечай только по информации из документа.
2. Если ответа нет — пиши "в документе не указано".
3. Цитируй точные фразы из документа в кавычках.

Чего не делать

• Не пиши «ты должен». Пиши «ответь так-то». Императивы воспринимаются хуже, чем описательные инструкции.
• Не клянчи «пожалуйста, очень важно, я отдам тебе чаевые». Не работает на современных моделях.
• Не пиши «не делай Y» без явной альтернативы. Лучше «вместо Y делай X».
• Не используй «think before answering» в системе. Anthropic-модели и так делают reasoning, явное напоминание не улучшает.

Тестирование

Промпт — это код. Заведи в проекте папку prompts/ с .md или .txt файлами. Каждый раз, когда меняешь промпт, прогоняй на тестовых кейсах. У меня 30 тестовых пар «инпут — ожидаемый формат», и я смотрю, как меняется метрика после каждой правки.

Без тестов промпт-инжиниринг — это «вроде стало лучше, кажется». С тестами — измеряемое улучшение.

Что в итоге

Промпт-инжиниринг для Claude в 2026 году — это не про магию, а про инженерию: чёткая структура (XML-теги или markdown-разделы), конкретные инструкции, few-shot примеры, явный формат вывода, контроль длины. Не скатывайся в заклинания, не клянчи, проверяй на тестах. И помни — промпт меняется вместе с моделями, что сегодня хорошо, завтра может быть лучше с подкруткой. Веди changelog, как для кода.