Как писать промпты для рабочих задач: контекст, формат и проверка
Практическое руководство по рабочему промпту: цель, исходные факты, ограничения, формат ответа, пример и проверка на сложных случаях без магических формул.
Промпт не обязан звучать умно. Хороший запрос даёт модели достаточно контекста, чтобы выполнить одну задачу, и достаточно ограничений, чтобы не додумывать отсутствующие факты. Вместо поиска универсальной формулы возьмите конкретную работу: например, написать черновик ответа клиенту по утверждённой инструкции. На ней быстро видно, чего не хватает в задании.
Опишите выход, а не настроение
Начните с глагола и результата: «сгруппируй обращения по теме и покажи примеры» или «составь черновик ответа по правилу ниже». Просьба «будь креативным экспертом» почти не говорит, как оценивать ответ. Укажите аудиторию и место использования: внутренняя заметка и публичное письмо требуют разной осторожности.
Одна задача на запрос облегчает проверку. Если вы одновременно просите классифицировать документ, оценить риск и отправить письмо, ошибка в раннем шаге перескочит в действие. Для сложного маршрута удобнее разнести этапы и проверить промежуточный результат.
Дайте только нужный контекст
Включите действующие факты, определения терминов и ограничения. Укажите, что модель должна делать при противоречии или недостатке сведений. Не загружайте большой архив «на всякий случай»: там легко окажутся устаревшие правила, личные данные и текст, который пытается изменить инструкцию.
Разделите собственное задание и цитируемый материал. Письмо клиента, страница сайта или вложение остаётся данными, даже если внутри написано «игнорируй предыдущие правила». Для действий с последствиями одной аккуратной формулировки недостаточно: права и проверки должны жить в приложении.
Зафиксируйте проверяемый формат
Если результат читает человек, попросите короткий вывод, основания и список неизвестного. Если результат передаётся программе, задайте ограниченный набор полей и проверяйте его кодом после ответа. Формат помогает заметить пропуск, но не гарантирует правдивость значения внутри поля.
Не перегружайте запрос десятками конфликтующих требований. Расставьте приоритеты: точность фактов, запрет на домыслы, нужный формат, стиль. Когда формат нарушен, поймите причину: неверное задание, недостаточный вход или ограничения модели. Простое добавление слова «строго» редко решает системную проблему.
Разберите учебный промпт
Учебная задача: написать ответ о сроке доставки по внутренней статье. Запрос сообщает роль оператора, вставляет разрешённый фрагмент инструкции и требует: «используй только этот фрагмент, не придумывай дату, если срок зависит от города, задай уточняющий вопрос». Формат ответа содержит текст клиенту и строку с источником правила.
Проверка включает три случая: город указан, город отсутствует, в письме клиент требует гарантировать доставку завтра. Хороший ответ меняется по данным и не поддаётся давлению из письма. Пример показывает структуру задания, а не обещает безошибочности любой модели.
Исправляйте по ошибкам
Сохраните несколько входов и ожидаемые критерии. После изменения одной части запроса прогоните те же случаи и добавьте новый проблемный. Если ответ стал красивее, но потерял важное ограничение, правка ухудшила задачу. Оценивайте целый результат, а не отдельную удачную фразу.
Для командной работы помечайте версию запроса и владельца. Храните утверждённые факты отдельно от инструкции, чтобы можно было обновить правило доставки без переписывания всей логики. Если модель часто ошибается на одном типе входа, возможно, нужен новый источник данных или ручной маршрут.
Помните о границах
Модель может уверенно выдумать источник или выполнить текстовую инструкцию из недоверенного документа. Проверка фактов остаётся обязательной, особенно перед внешней отправкой. Для денежных и юридически значимых решений используйте отдельные процедуры и ответственных специалистов. Не превращайте промпт в замену полномочий.
В библиотеке /prompts можно искать идеи формулировок, но каждый шаблон нужно приспособить к своим данным и проверить. Рабочий промпт хорош не длиной, а ясным контрактом результата и понятным способом увидеть ошибку.
Устройте проверку без подсказок автору
Автор запроса знает, чего хотел добиться, и невольно прощает модели недосказанность. Дайте новый промпт коллеге вместе с допустимым входом, но без устного объяснения. Пусть он попробует выполнить задачу и оценить ответ по рубрике. Если приходится уточнять, что «вообще-то это означает не отправлять письмо», граница должна появиться в инструкции и в техническом процессе.
Разберите ошибки по причине. Неверный факт может идти из старого источника, а не из плохого порядка слов. Пропуск важного поля может возникать из неполного входа. Плохой стиль лечится иначе, чем раскрытие чужих данных. Одна универсальная правка «будь внимательнее» не поможет всем трём случаям и усложнит запрос без пользы.
У промпта есть срок жизни. Когда меняются правила компании, формат данных или модель, старые примеры нужно прогнать заново. Храните рядом короткое описание назначения и проверочный набор. В рабочем процессе ценен не остроумный текст команды, а воспроизводимое поведение на ситуациях, которые действительно возникают у людей.
Если разные коллеги по-разному оценивают один и тот же ответ, уточните критерий до новой попытки с моделью. Такой спор часто показывает не проблему генерации, а неоднозначность самой рабочей задачи.
Отдельно попросите коллегу проверить самый короткий допустимый вход. Авторы обычно готовят богатый пример, где уже есть все ответы. В работе приходят обрывки фраз и противоречивые документы. Хороший запрос помогает обнаружить этот пробел до того, как модель заполнит его догадкой.
- У результата есть проверяемый критерий.
- При нехватке фактов допустим честный отказ.
- Новая версия проверена на старых сложных примерах.