«Ты опытный маркетолог. Напиши хороший текст» — не рабочая спецификация. Модель не знает, для кого текст, какое действие должен совершить читатель, какие факты разрешено использовать и что для вас означает «хороший».
Промпт-инжиниринг — это практика постановки задач языковой модели. Для разового диалога достаточно понятного вопроса. Для рабочего процесса нужен более строгий контракт: что дано, что требуется, какие ограничения действуют и как проверить результат. Это совпадает с общей логикой официальных руководств OpenAI, Google и Anthropic: ясные инструкции, отделённый контекст, примеры и заданная структура ответа полезнее декоративной роли «гения с двадцатилетним опытом».
Начните с результата
Опишите, какое решение должен принять человек или система после ответа модели. «Проанализируй документ» слишком широко. «Выдели обязательства сторон, сроки и штрафы в таблицу, укажи номер раздела для каждого пункта» — уже проверяемая задача.
Я начинаю не с формулировки запроса, а с вопроса: что произойдёт после ответа? Если результат никто не использует, длинный промпт не спасёт задачу. Если результат передаётся в CRM, таблицу или письмо клиенту, формат и контроль можно определить заранее.
Дайте необходимый контекст
Модели полезно знать аудиторию, ситуацию, терминологию и правила компании. Не перегружайте запрос сведениями, которые не влияют на результат: лишний контекст может отвлекать так же, как и его отсутствие.
Контекст должен отвечать на три вопроса: что уже известно, чему можно доверять и чего модель не должна додумывать. Для разбора договора передайте сам договор и правила проверки. Для ответа клиенту — историю обращения, доступные условия и тон коммуникации. Не просите модель вспоминать внутренние правила компании из воздуха.
Отделяйте инструкции от данных
Явно обозначьте, где правила задачи, а где письмо клиента, документ или выгрузка. Это повышает читаемость запроса и снижает вероятность того, что текст внутри данных будет воспринят как новая инструкция.
Подойдут обычные заголовки или явные блоки:
ЗАДАЧА
Составь черновик ответа клиенту.
ПРАВИЛА
Используй только сведения из блока «Данные».
Если тарифа нет в данных, напиши «нужно уточнить».
ДАННЫЕ
...
ФОРМАТ
Тема письма, затем текст до 900 знаков.Разметка не является магией. Она просто делает границы видимыми человеку и модели, а затем упрощает поддержку промпта.
Задайте формат
Если результат будет читать человек, укажите структуру, объём и уровень подробности. Если ответ передаётся в программу, используйте строгую схему и проверяйте её после генерации.
Для интеграции фраза «ответь JSON» недостаточна. Опишите поля, типы, допустимые значения и поведение при нехватке данных. После ответа всё равно запустите программную валидацию. Модель генерирует текст; схема и бизнес-правила должны проверяться кодом.
Определите границы
Скажите, на каких источниках можно основываться, когда нужно задавать уточняющий вопрос и в каких случаях следует отказаться от вывода. Для рискованных задач отдельно перечислите то, что модель не должна решать самостоятельно.
Граница особенно важна в агентном сценарии. Подготовить черновик счёта и отправить счёт — разные уровни полномочий. Суммаризировать медицинский документ и поставить диагноз — тоже. Промпт описывает намерение, но реальные права должны ограничиваться самой системой: доступными инструментами, подтверждениями и журналом действий.
Добавьте критерии качества
Критерии превращают субъективное «сделай хорошо» в проверяемый результат. Например: каждый вывод должен иметь ссылку на раздел документа; неизвестные значения помечаются не найдено; сумма процентов должна быть равна ста.
Разделите критерии на машинные и смысловые. Код может проверить наличие полей, длину, формат даты и сумму. Человек или отдельная оценка проверят корректность вывода, тон и соответствие источнику. Чем больше требований можно проверить автоматически, тем меньше результат зависит от настроения ревьюера.
Используйте примеры осмысленно
Один или два хороших примера показывают модели нужную структуру и уровень детализации. Но пример может случайно закрепить ненужные особенности, поэтому он должен отражать правило, а не единичный красивый ответ.
Показывайте не только идеальный случай. Если процесс должен корректно отказываться, добавьте пример с недостаточными данными. Если бывают конфликтующие документы — пример с выбором актуальной версии. Пример работает как часть спецификации, поэтому случайная ошибка в нём размножается особенно убедительно.
Шаблон промпта-контракта
Для большинства бизнес-задач хватает семи блоков:
ЦЕЛЬ
Какой полезный результат нужен и кто его использует.
ВХОДНЫЕ ДАННЫЕ
Что передано модели и откуда это получено.
КОНТЕКСТ
Аудитория, ситуация, термины и приоритет источников.
ИНСТРУКЦИИ
Последовательность обработки задачи.
ОГРАНИЧЕНИЯ
Что запрещено, когда нужно уточнение или отказ.
ФОРМАТ РЕЗУЛЬТАТА
Структура, поля, объём и допустимые значения.
ПРОВЕРКА
Критерии качества и момент передачи человеку.Не каждый блок обязан быть длинным. Хороший контракт может занимать десять строк, если задача узкая. Важнее, чтобы в нём не было скрытых ожиданий.
Тестируйте как часть продукта
Для регулярного использования храните версии промпта и набор примеров. После изменения модели, контекста или интеграции прогоняйте тесты заново. Так промпт перестаёт быть личным трюком сотрудника и становится управляемым компонентом системы.
Начните с 15–30 реальных примеров: обычных, пограничных и явно недопустимых. Для каждого сохраните ожидаемые свойства результата. Не обязательно заранее писать единственный «идеальный ответ» — часто достаточно критериев: верный источник, обязательные поля, отсутствие выдуманных данных, корректная передача человеку.
Меняйте за один раз одну существенную часть: инструкцию, набор примеров, источник контекста или модель. Иначе вы увидите новый результат, но не поймёте, что его улучшило или испортило. Версия промпта должна сохраняться рядом с версией модели и набором тестов.
Почему хороший промпт всё равно ошибается
Даже точная инструкция не добавит отсутствующий факт и не исправит плохой поиск по документам. LLM остаётся вероятностной системой. Если ошибка дорогая, нужны разрешённые источники, структурированный ответ, автоматические ограничения и человеческое подтверждение.
О причинах уверенных выдумок читайте в разборе галлюцинаций нейросетей, а для практической проверки используйте алгоритм фактчекинга ответа. Базовое различие между моделью, агентом и управляющей обвязкой я объясняю в статье что такое LLM.
С чего начать в команде
Возьмите одну повторяемую задачу, где результат можно проверить и откатить: классификацию обращения, извлечение полей из документа или черновик ответа. Запишите текущий процесс, соберите примеры, заполните шаблон контракта и согласуйте недопустимые действия. Затем проведите слепую проверку: ревьюер не должен знать, какая версия промпта создала каждый ответ.
Только после стабильного результата подключайте промпт к автоматизации. Красивый ответ в чате — демонстрация. Управляемый результат на реальных примерах — рабочий компонент.
Главное
Сильный промпт начинается с ясной бизнес-задачи. Цель, контекст, входные данные, ограничения, формат и проверка важнее длинных списков «секретных слов».