Как составить рабочий промпт: задача, контекст, формат и проверка

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

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

1. Начните с результата, а не с роли

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

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

2. Дайте только необходимый контекст

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

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

3. Задайте форму ответа

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

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

4. Встройте проверку

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

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

Шаблон рабочего запроса

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

Перед сохранением задайте четыре вопроса. Поймёт ли новый сотрудник ожидаемый результат? Видно ли, какие данные являются источником? Можно ли объективно проверить ответ? Разрешено ли модели остановиться при неопределённости? Если хотя бы один ответ отрицательный, инструкция ещё не готова к повторному использованию.

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

Расплывчатая версия звучит так: «Сделай хороший протокол встречи». В ней нет назначения, аудитории, обязательных полей и источника истины. Модель может написать аккуратный текст, но сотрудник всё равно будет заново искать решения, ответственных и сроки в расшифровке.

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

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

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

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

Короткий вывод

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