Как писать промпты: гид по prompt engineering для ChatGPT, Claude и Gemini

Когда ответ вроде нормальный, но не тот

Представьте простую задачу: нужно описание курса по моушн-дизайну. Запрос «напиши описание курса» не содержит ошибки. Просто в нём почти нет решения, которое требуется именно вам.

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

Тот же запрос становится рабочим, если добавить полезную информацию:

Напиши короткое описание курса по моушн-дизайну для начинающих специалистов. Они уже умеют работать в редакторе, но теряются в композиции, цвете и ритме. Покажи, что курс построен вокруг практики и итогового проекта. Тон дружелюбный, без рекламных штампов. Сначала один абзац о результате, затем три конкретных навыка и спокойный призыв посмотреть программу.

Здесь нет секретной формулы. Появились аудитория, исходные факты, цель, ограничения и структура. Модели осталось меньше угадывать.

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

Эта логика работает в ChatGPT, Claude, Gemini и других LLM. Интерфейсы и отдельные возможности меняются, а ясная задача, полезный контекст и проверяемый результат остаются общей основой.

Промпт — это постановка задачи

Удобно думать о модели как о новом коллеге, который быстро читает и пишет, но не знаком с вашим проектом. Коллега не угадает внутренние сокращения, историю клиента и критерии готовности. Модель тоже.

Отсюда простой принцип: в промпт попадает не вся известная информация, а та, которая меняет ответ.

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

Хорошая инструкция снижает неоднозначность, но не гарантирует истину. Модель всё ещё может ошибиться, неправильно понять данные или уверенно дополнить пробел. Поэтому у полезного промпта есть не только задача, но и способ проверить результат.

Шесть блоков, из которых собирается запрос

Не каждый промпт требует всех блоков. Это скорее набор деталей на столе: берутся только те, которые помогают конкретной работе.

1. Задача

Что должно появиться в конце? Не тема, а действие и результат.

Размыто: «Расскажи про хуки в React».

Точнее: «Объясни различие между двумя основными хуками разработчику с опытом во фронтенде, но без практики в React. Добавь по одному небольшому примеру и типичную ошибку».

Активный глагол сразу задаёт направление: сравнить, извлечь, переписать, классифицировать, проверить, предложить варианты.

2. Контекст и аудитория

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

Контекст не обязан быть биографией проекта. Если факт не влияет на ответ, он только прячет важные инструкции.

3. Материалы и границы знания

Если модель должна опираться на документ, таблицу, код или расшифровку, материал лучше отделить от инструкции и прямо назвать источником.

Используй только данные из блока «Материалы». Если ответа там нет, напиши «в материалах не найдено». Не дополняй числа по памяти.

Такая формулировка особенно полезна для внутренних документов и аналитики. Она не делает ошибку невозможной, но задаёт наблюдаемое правило.

4. Критерии результата

Критерии объясняют, что означает «хорошо». Например:

• каждый вывод подтверждён строкой или числом из данных;
• текст понятен читателю без отраслевого опыта;
• функция обрабатывает пустой ввод;
• варианты заметно отличаются друг от друга;
• важные предположения перечислены отдельно.

Критерий легче проверить, чем прилагательное «качественный». Чем ближе запрос к реальной работе, тем полезнее этот блок.

5. Ограничения

Ограничения задают длину, тон, допустимые источники, техническую среду и то, чего следует избегать. Они должны быть совместимыми. Пара «ответь одной строкой» и «объясни все нюансы» заставляет модель выбирать, какой частью инструкции пожертвовать.

Лучше описывать желаемое поведение положительно. Вместо длинного перечня запретов можно написать: «используй спокойный литературный русский, короткие абзацы и конкретные глаголы». Отдельный стоп-лист остаётся полезным, когда нежелательные слова действительно повторяются.

6. Формат

Формат — это форма готового результата: связный текст, таблица, список, diff, схема полей или несколько вариантов с короткой оценкой. Если ответ продолжит обрабатываться программой, одного пожелания «верни JSON» мало: нужен механизм структурированного вывода и последующая валидация.

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

Универсальный шаблон

Шаблон удобно держать коротким и расширять только при необходимости:

Задача
<что нужно получить>

Контекст
<где используется результат, кто аудитория>

Материалы
<текст, данные, код или ссылки>

Критерии
<как проверить качество>

Ограничения
<длина, тон, источники, техническая среда>

Формат ответа
<структура готового результата>

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

Markdown, XML-теги и другие разделители решают одну и ту же задачу. Выбирать стоит тот формат, который удобно читать и поддерживать. Смешивать несколько систем без причины не нужно.

Примеры вместо длинных объяснений

Few-shot prompting — это несколько пар «вход → хороший выход» внутри запроса. Примеры особенно полезны, когда результат трудно описать словами: тон бренда, классификация спорных случаев, редкий формат, редакторская манера.

Допустим, нужно превращать внутренние заметки в короткие статусы:

Пример входа: «Макеты готовы, клиент ещё не посмотрел, срок может сдвинуться».

Пример выхода: «Макеты готовы и ждут согласования. Срок уточним после обратной связи клиента».

Теперь обработай: «Тесты прошли, кроме оплаты, там падает старый сценарий».

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

Важно, чтобы сами примеры не противоречили правилам. Модель замечает форму, лексику и даже нежелательные привычки. Если показать три многословных ответа, а затем попросить краткость, демонстрация будет спорить с инструкцией.

Сложную работу лучше раскладывать

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

Прозрачнее разделить процесс:

1. извлечь факты и неизвестные;
2. согласовать план или критерии;
3. выполнить основную работу;
4. проверить ответ по короткому чек-листу;
5. отформатировать финальную версию.

Разделение особенно помогает, когда ранняя ошибка портит все последующие шаги. Если модель неверно поняла данные, красивый финальный отчёт только спрячёт проблему.

Необязательно открывать отдельный чат на каждый этап. Важно, чтобы у шага был один понятный результат, который можно осмотреть перед продолжением.

Как просить о рассуждении

Совет «покажи всю цепочку мыслей» плохо подходит как универсальная инструкция. Современные модели могут использовать внутреннее рассуждение, не выдавая его дословно, а длинный поток мыслей не равен правильной проверке.

Для рабочей задачи полезнее запросить наблюдаемые артефакты:

• короткий план до выполнения;
• список допущений;
• расчёт с промежуточными числами;
• ссылки на строки исходных данных;
• два альтернативных решения и критерий выбора;
• финальную самопроверку по заданному чек-листу;
• краткое объяснение ключевых причин без скрытого внутреннего монолога.

Так ответ остаётся проверяемым. Для арифметики, кода и поиска свежих фактов надёжнее подключать соответствующий инструмент, а не надеяться, что более длинное рассуждение исправит нехватку данных.

Постоянные инструкции и system prompt

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

Постоянные инструкции хорошо подходят для стабильных правил:

• язык и тон;
• допустимые источники;
• порядок работы с неопределённостью;
• политика использования инструментов;
• формат ответа по умолчанию.

Конкретная задача, документы и временные детали остаются в пользовательском запросе. Если положить всё в постоянную инструкцию, она быстро разрастается, начинает противоречить новым задачам и становится трудной для проверки.

Иерархия инструкций не является защитой от всех атак. Текст из сайта, письма или PDF может содержать чужую команду. В приложениях внешние материалы следует считать недоверенными данными, отделять от инструкций и ограничивать права инструментов. Подробнее об этом — в разборе prompt injection.

Формат для программной обработки

Таблица или JSON в обычном чате удобны человеку, но приложение нуждается в более строгом контракте. API многих платформ поддерживают структурированный вывод по схеме. Он помогает получить нужные поля и типы, однако не гарантирует правдивость значений.

Если схема требует поле «дата», модель может вернуть синтаксически правильную, но выдуманную дату. Поэтому остаются три уровня проверки:

1. схема проверяет форму;
2. код проверяет допустимые значения и бизнес-правила;
3. источники или человек проверяют смысл там, где цена ошибки высока.

JSON mode и Structured Output также не одно и то же. Первый обычно следит за валидностью JSON, второй связывает ответ с заданной схемой в пределах возможностей конкретного API. Поддерживаемый синтаксис и параметры лучше сверять с документацией используемой платформы.

Промпты для разных задач

Одна структура работает везде, но акцент меняется.

Текст

Нужны аудитория, цель, факты, тон и признаки живого результата. Вместо «напиши красиво» полезнее приложить небольшой образец и описать, чего должен добиться текст.

Перепиши заметку для читателя без технического опыта. Сохрани все факты и ссылки. Начни с ответа на главный вопрос, затем объясни два термина на примерах. Спокойный русский без рекламных обещаний. В конце перечисли места, где исходных данных не хватило.

Код

Здесь важны репозиторий, язык и версия, интерфейсы, ограничения, ожидаемое поведение и способ проверки.

Найди причину падения теста в приложенном фрагменте. Сначала назови наблюдаемую причину и файл. Затем предложи минимальную правку. Не меняй публичный интерфейс. Добавь тест на случай пустого ввода.

Модель лучше работает с реальным кодом и ошибкой, чем с пересказом «у меня что-то не запускается».

Данные

В запросе фиксируются таблица, смысл полей, единицы измерения, период, обработка пропусков и метрика.

По приложенной таблице сравни выручку категорий. Не считай пустые значения нулями. Для каждого вывода укажи строки и промежуточные суммы. Если периодов недостаточно для сезонности, так и напиши.

Для расчётов предпочтителен инструмент исполнения кода. Языковая модель хорошо формулирует выводы, но арифметику стоит перепроверять вычислением.

Идеи

Креативной задаче нужна свобода, но не туман. Полезны территория бренда, аудитория, уже использованные ходы и критерии разнообразия.

Предложи восемь концепций. Разнеси их по разным механикам: история, демонстрация, контраст, эксперимент. Для каждой дай одну фразу идеи и один визуальный образ. Не повторяй одну мысль разными словами.

Перевод и адаптация

Указываются аудитория, вариант языка, степень буквальности, термины, которые нельзя менять, и примеры желаемого тона. Стилистику лучше описывать признаками, а не одной ссылкой на известного автора или издание.

Объяснение

Важны исходные знания читателя, глубина и проверка понимания.

Объясни латентное пространство дизайнеру, который не изучал машинное обучение. Сначала дай прямое определение, затем одну точную метафору и пример из генерации изображений. Отдельно укажи, где метафора перестаёт работать.

Как улучшать промпт без хаоса

Промпт редко становится устойчивым после одного удачного ответа. Случай может быть простым, а следующий вход — совсем другим.

Рабочая итерация выглядит спокойно:

1. сохранить исходный запрос и несколько типичных примеров входа;
2. назвать конкретный сбой: потерян факт, нарушен формат, смешаны аудитории;
3. изменить одну часть инструкции;
4. снова прогнать тот же небольшой набор примеров;
5. сравнить по заранее выбранным критериям.

Это уже маленький eval, а не спор со вкусом. Для повторяющейся задачи полезно хранить не только шаблон, но и несколько сложных тестовых случаев. После смены модели или крупного обновления они покажут, сохранилось ли нужное поведение.

Самопроверка модели может найти очевидное нарушение, но не является независимой экспертизой. Для фактов нужны источники, для кода — тесты, для расчётов — вычисление, для юридических и медицинских решений — квалифицированная проверка.

Что часто мешает

Слишком мало контекста. Модель заполняет пробелы правдоподобными догадками. Лечится не длиной, а нужными фактами.

Противоречия. «Коротко и исчерпывающе», «дословно и естественно» — это два разных приоритета. Один из них стоит сделать главным.

Тридцать правил без иерархии. Критичные требования теряются среди косметических. Их лучше поставить раньше и отделить от пожеланий.

Только запреты. Пустое пространство модель всё равно чем-то заполнит. Вместе с «не делай» полезно показать «делай вот так».

Один красивый тест. Он ничего не говорит о сложных входах. Нужны обычный, крайний и заведомо неудобный пример.

Просьба подтвердить желаемый вывод. Модель легко подстроит объяснение. Аналитический запрос лучше формулировать нейтрально и заранее определить критерии.

Доверие выдуманным ссылкам. Просьба «приведи источники» не создаёт доступ к ним. Для актуальных фактов нужен поиск или предоставленные документы, а ссылки открываются и проверяются.

Частые вопросы

Сколько слов должно быть в промпте?

Столько, сколько нужно для задачи. Простая команда помещается в строку. Сложная работа требует данных, критериев и примеров. Полезность блока важнее его объёма.

Нужно ли писать по-английски?

Нет, если модель хорошо работает с русским и результат нужен на русском. Английский может понадобиться для документации или материалов, но сам промпт лучше писать на языке, на котором проще точно сформулировать задачу.

Помогает ли роль?

Иногда. Конкретная роль задаёт перспективу и лексику. Она не заменяет данные, критерии и профессиональную проверку.

Нужно ли просить «думать по шагам»?

Не как универсальную мантру. Лучше попросить план, допущения, промежуточные вычисления или краткое обоснование — то, что можно проверить.

Можно ли полностью убрать галлюцинации?

Нет. Их риск снижают предоставленные источники, строгие границы знания, поиск, RAG, инструменты вычисления и внешняя проверка. Один текст промпта не превращает вероятностную модель в базу фактов.

Почему модель игнорирует инструкцию?

Причина может быть в конфликте правил, перегруженном контексте, неясном формате, ограничениях самой модели или более приоритетной инструкции. Сначала полезно сократить задачу до минимального воспроизводимого примера и найти место, где поведение меняется.

Даст ли один промпт одинаковый ответ каждый раз?

Не обязательно. Генерация может быть вариативной, а настройки воспроизводимости отличаются между платформами. Для рабочей системы важнее тестировать диапазон допустимых ответов, чем рассчитывать на дословное повторение.

Источники

• Google: Prompt design strategies — ясные инструкции, разделители, примеры и итерация.
• Anthropic: Prompt engineering overview — конкретные инструкции, контекст и согласованность примеров.
• OpenAI API: Prompt engineering — инструкции, сообщения, примеры и работа с контекстом.
• OpenAI API: Structured Outputs — вывод по JSON Schema и ограничения схемы.
• Zero-shot и few-shot в словаре Neurosaver — короткая справка о запросах с примерами и без них.

Главное

Промпт — не заклинание и не экзамен на красноречие. Это постановка задачи для системы, которая не знает ваш контекст, пока вы его не дали.

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

И самое важное: хороший промпт уменьшает неопределённость, но не отменяет проверку. Чем дороже ошибка, тем меньше надежды на формулировку и тем больше опоры на источники, инструменты и независимый контроль.