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

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

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

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

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

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

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

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

Эта логика работает в ChatGPT, Claude, Gemini и других LLM. Для каждого из этих сервисов полезно назвать задачу, приложить нужные материалы и объяснить, как вы будете оценивать ответ.

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

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

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

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

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

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

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

1. Задача

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Формат

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

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

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

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

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

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

Материалы
<текст, данные, код; ссылки — если у системы есть доступ к их содержимому>

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

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

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

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

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 — короткая справка о запросах с примерами и без них.

Главное

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

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

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