Как писать промпты для нейросети: инструкция с проверяемым результатом
Промпт — не заклинание и не набор секретных слов. Это рабочее задание, в котором человеку понятно, что считать готовым результатом. Если написать «сделай хороший текст», модель будет угадывать аудиторию, объём и тон. Если описать цель, исходные данные и ограничения, ответ легче принять, сравнить и повторить в другой модели.
Начните с результата
Сформулируйте действие одним глаголом: классифицируй, сократи, сравни, извлеки, перепиши или объясни. Затем добавьте объект и критерий. «Сократи отчёт до пяти тезисов, сохрани все числа и укажи страницы» точнее, чем «сделай кратко». Если результат нельзя проверить за минуту, разделите задачу на этапы.
Пять обязательных блоков
Хорошая инструкция обычно содержит:
- Роль и границы. Например, редактор службы поддержки, который не меняет условия договора.
- Задачу. Что именно нужно сделать и в каком порядке.
- Контекст. Кто читатель, для чего используется результат, какие данные уже известны.
- Ограничения. Объём, тон, запрещённые действия, язык, формат и срок.
- Критерий готовности. Что проверить перед выдачей ответа и когда остановиться.
Роль полезна, когда задаёт область ответственности, а не обещает «экспертность во всём». Для делового письма укажите адресата и цель. Для кода назовите язык, версию библиотек и ожидаемое поведение. Для таблицы перечислите колонки и правила обработки пустых значений.
Контекст перед командой
Разделяйте инструкцию и исходные данные заметными заголовками. Длинный текст обрамляйте тройными кавычками или блоком Markdown, чтобы модель не приняла фразу из документа за новую команду. В начале укажите, какие сведения считать авторитетными, а в конце попросите перечислить пропуски.
Удалите персональные данные, пароли и внутренние ссылки. Если имя важно для структуры, замените его меткой [КЛИЕНТ]. Такой приём одновременно снижает риск утечки и показывает модели, какие части нельзя изменять.
Формат, который можно проверить
Опишите форму ответа до мелочей: количество пунктов, порядок полей, допустимые значения и способ обозначить неизвестное. Для JSON попросите вернуть только валидный JSON без пояснений. Для статьи задайте заголовки и пример абзаца. Для сравнения потребуйте таблицу, а затем короткий вывод для конкретного сценария.
Один пример «вход → выход» часто полезнее длинного описания. Это особенно заметно в классификации обращений и редактуре. Добавляйте два примера, если есть пограничный случай. Не используйте пример с настоящими клиентскими данными.
Декомпозиция и уточнения
Сложную работу разделите на независимые шаги: сначала план, затем черновик, затем проверка фактов. Между этапами сохраняйте результат и меняйте только одну инструкцию. Добавьте правило: «Если не хватает сведений, задай до трёх вопросов и не выдумывай ответ». Это лучше, чем заставлять модель угадывать.
Для длинного документа сначала попросите список разделов и терминов, потом работайте по частям. Для кода сначала получите гипотезу причины ошибки, затем минимальный патч и тест. Если сразу требовать всё, источник ошибки будет неясен.
Модель влияет на подачу
Один и тот же промпт по-разному ведёт себя в разных моделях. Для длинного контекста и аккуратной редакторской работы можно посмотреть карточку Claude Sonnet, для русскоязычного рабочего черновика — карточку YandexGPT, а для задач, где важна большая инструкция и несколько форматов, — карточку Gemini 3.1 Pro. Ссылки не заменяют тест: прогоните одну выборку и сравните число правок.
Собрать структуру запроса поможет генератор промптов, но поля всё равно нужно заполнить конкретными данными. Не переносите шаблон между задачами без пересмотра критериев.
Цикл проверки
После ответа проверьте факты, формат и тон отдельными запросами. Попросите модель найти собственные сомнительные места, но не считайте это независимой экспертизой. Важные числа сверяйте с исходником, код запускайте на тестах, а письмо сначала отправляйте коллеге.
Сохраняйте версию промпта, дату, модель, вход и финальный результат. Если добавили ограничение, запишите причину. Через неделю повторите запуск на новом примере: так видно, улучшила ли инструкция процесс или просто помогла одному случаю.
Что обычно ломает запрос
Противоречивые требования, расплывчатые слова («красиво», «максимально», «срочно»), слишком длинный ввод без структуры и просьба выполнить пять ролей одновременно. Исправляйте их по одному: уберите конфликт, замените оценочное слово измеримым критерием, разделите документ и назначьте последовательность действий.
Хороший промпт — это короткий договор между человеком и моделью. В нём видны цель, данные, границы и способ проверки. Чем легче другой человек повторит этот договор, тем меньше случайности в результате.
Перед передачей в работу перечитайте запрос глазами коллеги, который не знает вашей ситуации. Если ему непонятно, откуда взять данные или кто отвечает за финальную проверку, промпт ещё рано считать готовым.
Тест на переносимость
Проверьте инструкцию на трёх разных входах: обычном, неполном и намеренно двусмысленном. На обычном ответ должен соответствовать формату. На неполном — явно перечислить, каких данных не хватает. На двусмысленном — задать уточняющий вопрос, а не выбрать удобную трактовку. Запишите результат рядом с версией промпта и моделью. Если две версии дают разные решения, меняйте одно правило за раз и повторяйте тот же тест.
Такой подход быстро показывает, какие требования действительно управляют ответом. Он также помогает не превращать удачный единичный запрос в универсальный шаблон, который ломается при первом новом документе.