Как правильно писать промты для ИИ: практическое руководство которое работает в 2026 году

Есть простая проверка: если твой промт выглядит как поисковый запрос — ты оставляешь на столе 80% возможностей модели.

«Напиши мне письмо партнёру» даёт один результат. «Ты опытный B2B-менеджер. Напиши письмо CEO небольшой IT-компании с предложением о партнёрстве. Тон: профессиональный, без лести. Длина: до 150 слов. Цель: получить 30-минутный звонок на следующей неделе» — совершенно другой.

Разница не в магии. В структуре и контексте.

Принцип первый: говори модели кто она

Ролевые инструкции работают потому что они активируют определённые паттерны поведения модели — стиль, уровень детализации, отношение к аудитории.

Слабо:

Объясни мне как работает TCP/IP

Сильно:

Ты senior network engineer с 15 годами опыта.
Объясни TCP/IP разработчику который понимает HTTP 
но никогда не работал с протоколами на низком уровне.
Используй аналогии, избегай аббревиатур без расшифровки.

Ключевое — роль должна соответствовать задаче. «Ты эксперт» без уточнения не даёт почти ничего. «Ты технический писатель специализирующийся на документации для API» — уже другая история.

Принцип второй: объясняй зачем, а не только что

Современные модели умеют рассуждать о целях. Если ты объяснишь почему что-то важно, модель примет лучшие решения в местах где инструкция неполная — а она всегда неполная.

Слабо:

Не используй маркированные списки

Сильно:

Не используй маркированные списки — 
мне нужен текст для потокового чтения вслух,
списки разрушают ритм произношения

Anthropic в своей документации прямо указывает: объяснение причины позволяет модели делать лучшие смежные решения — например правильно интерпретировать пограничные случаи которые ты не предусмотрел.

Принцип третий: структурируй через XML-теги (для Claude)

Claude специально обучался работать с XML-структурой в промтах. Когда у тебя сложный промт с несколькими частями — разделяй их тегами:

<role>
Ты редактор технического блога
</role>
 
<context>
Статья для разработчиков средней квалификации.
Блог — рус. язык, неформальный но профессиональный тон.
</context>
 
<task>
Перепиши следующий абзац: он слишком сухой и академичный.
Сохрани смысл, добавь живости.
</task>
 
<content>
[вставь абзац]
</content>
 
<constraints>
- Длина: ±10% от оригинала
- Без клише типа "в современном мире"
- Одно конкретное улучшение — не переписывай стиль полностью
</constraints>

Это не обязательная форма — это способ помочь модели не смешивать инструкции с контентом. Особенно важно когда твой контент сам содержит инструкции или технический текст.

Принцип четвёртый: Few-Shot — покажи пример желаемого

Объяснить что ты хочешь словами сложно. Показать — часто проще и точнее. Few-Shot prompting означает что ты даёшь 2–5 примеров нужного результата перед тем как задать реальную задачу.

Перефразируй следующие технические предложения в человеческий язык.
 
Примеры:
Вход: "Функция выполняет итерацию по массиву объектов и применяет callback"
Выход: "Функция проходит по списку и делает что-то с каждым элементом"
 
Вход: "Метод возвращает Promise который резолвится с данными пользователя"
Выход: "Метод обещает дать тебе данные пользователя — чуть позже"
 
Теперь перефразируй:
"Компонент подписывается на стор и рендерится при каждом изменении состояния"

Модель видит паттерн «что ты делаешь с языком» и повторяет его точнее чем если бы ты описывал его словами. Lakera в своём руководстве 2026 года называет Few-Shot «одной из самых надёжных техник для контроля стиля и тона».

Принцип пятый: Chain-of-Thought для сложных задач

Chain-of-Thought (CoT) — это когда ты просишь модель рассуждать пошагово, а не прыгать сразу к ответу. Работает потому что модели чаще ошибаются когда пропускают промежуточные шаги — они «не видят» своих логических скачков.

Простой вариант — просто добавить в конец:

Думай пошагово перед ответом.

Более управляемый вариант — задать шаги явно:

Прежде чем ответить:
1. Определи какую проблему реально решает пользователь
2. Перечисли возможные подходы
3. Выбери лучший с объяснением
4. Только потом дай финальный ответ

Для задач где важна точность — анализ, принятие решений, отладка — CoT даёт заметно лучшие результаты чем прямой вопрос.

Принцип шестой: системный промт vs пользовательский — разные роли

Если ты работаешь через API или строишь инструмент поверх AI, разделение на system prompt и user message принципиально важно.

System prompt — это контракт. Он задаёт роль, ограничения, формат вывода, поведение в неопределённых ситуациях. Он должен быть конкретным и стабильным:

Ты ассистент для анализа кода.
Успех: найти реальные проблемы, объяснить почему это проблема, предложить исправление.
Ограничения:
- Не предлагай изменения которые не попросили
- Если неуверен — скажи прямо, не угадывай
- Формат: для каждой проблемы: [Уровень] Описание → Причина → Исправление
Если задача не про анализ кода — вежливо скажи об этом.

User message — конкретная задача в рамках этого контракта.

Хорошая система промтов читается как договор: понятно что обещает исполнитель, что считается успехом и как он ведёт себя в крайних случаях.

Принцип седьмой: итерация — это не баг, это процесс

Самая распространённая ошибка — ожидать идеального результата с первого промта и разочаровываться когда его нет. Prompt engineering — итерационный процесс.

Рабочий цикл:

1. Напиши промт, получи результат
2. Определи что именно не так — тон? детализация? структура? неверный факт?
3. Измени одну переменную — не переписывай промт целиком
4. Сравни результаты
5. Зафиксируй что сработало

Разница между посредственным промтом и хорошим — не магия. Это три–четыре итерации с конкретным пониманием что менять.

Полезный трюк: попроси модель оценить собственный вывод. «Проверь свой ответ на соответствие этим критериям: [список]». Модели часто замечают свои ошибки когда их явно просят посмотреть критически.

Что работает по-разному в Claude vs GPT vs Gemini

Модели реагируют на промты по-разному:

Claude — хорошо реагирует на XML-структуру, declarative-стиль («напиши статью которая...» лучше чем «напиши статью о...»), и объяснение причин ограничений. Склонен к подробности — если нужно кратко, укажи явно.

GPT — хорошо воспринимает markdown-форматирование в промте, числовые ограничения («ровно 3 пункта», «до 50 слов»). Адаптируется к anchored prompts — шаблонам с заполненными примерами.

Gemini — лучше работает когда структура задана в самом начале промта. Силён в длинных структурированных документах, но без жёстких ограничений может «перебегать» заданный объём.

Prompt engineering не станет менее важным по мере улучшения моделей — он станет другим. Модели лучше понимают неоднозначные инструкции, но зазор между плохо и хорошо сформулированной задачей не исчезает. Он просто смещается с синтаксиса на смысл.

Умение точно формулировать что ты хочешь и зачем — это не AI-навык. Это фундаментальный навык коммуникации, который AI просто сделал более видимым.