Для повторяющейся задачи попробуй авторский шаблон из трёх частей: постоянные правила, вход текущего запуска и критерии приёмки. Это удобный способ хранить собственные запросы, а не обязательное свойство или настройка каждой модели. Если смешать слои, старые детали могут незаметно перейти в новую задачу.
Разложи запрос на три блока
Постоянное: «отвечай по-русски; не меняй числа; отмечай неизвестные сведения». Это стоит повторно использовать, пока правило действительно актуально.
Вход текущей задачи: текст письма, таблица, вопрос и желаемая аудитория. Этот материал нужно заменить при следующем запуске.
Критерии готовности: «не более 150 слов; три даты сверены; в конце список открытых вопросов». Это позволяет не оценивать ответ только по ощущению «звучит хорошо».
Пример шаблона:
Постоянные правила:
- Используй только предоставленные факты.
- Если данных не хватает, явно перечисли пробелы.
- Не придумывай сроки и обещания.
Задача сегодня:
[вставь текущий материал и действие]
Результат должен:
- содержать [формат/объём];
- сохранить [критичные поля];
- пройти проверку [конкретные критерии].
Когда достаточно шаблона
Если инструкция нужна только для одного типа запроса и её легко вставить вручную, держи её в заметке или сниппете. Не нужно искать встроенную функцию «памяти» для простой копируемой структуры.
Когда помогает постоянная инструкция или проект
Если продукт предлагает пользовательские инструкции или пространство с файлами, они могут сократить повторение правил и дать общий контекст серии задач. Например, справка ChatGPT описывает пользовательские инструкции и настройки их применения в аккаунте (Custom Instructions). Но возможности, пределы и настройки отличаются между сервисами и меняются. Перед тем как полагаться на них, проверь актуальную документацию выбранного продукта. Не считай, что постоянная инструкция включена во всех диалогах, что она имеет приоритет над системными ограничениями или что она делает файлы проекта безусловно доступными модели.
Признаки, что инструкция пора обновить
- Она ссылается на старый тариф, интерфейс или процесс.
- Для нового запроса приходится писать «в этот раз игнорируй правило…».
- Несколько пунктов говорят друг другу противоположное.
- В ней накопились примеры, не похожие на реальные задачи.
- Ты добавил правило после единичной ошибки, но не проверил, исправляет ли оно проблему.
Проведи ревизию по короткой таблице:
| Поле | Вопрос |
|---|---|
| Цель | Для каких повторяющихся задач это нужно? |
| Постоянные правила | Какие требования действительно одинаковы каждый раз? |
| Переменные поля | Что обязано обновляться перед запуском? |
| Проверка | Как заметить ошибку до использования ответа? |
| Дата | Когда эту инструкцию последний раз сверяли? |
Если ответ зависит от нового прайса или политики, вынеси его в датированный источник, а не храни как вечное знание модели. Для важных решений передавай ссылку на актуальный документ.
Проверяй шаблон на контрпримере
Возьми два входа: типичный и такой, где одного важного поля нет. Хорошая инструкция должна дать приемлемый черновик в первом случае и задать уточнение во втором. Это ручная проверка двух случаев, а не формальное доказательство качества.
Не помещай секреты, пароли и токены в пользовательские инструкции. Не копируй персональные данные в постоянный контекст, если они не нужны для каждой задачи. Сокращай шаблон до минимального набора правил, который помогает повторять процесс.
Добавь короткое поле «не использовать для». Например, шаблон подготовки ответа клиенту не должен автоматически формировать юридическое уведомление, обещать дату релиза или отвечать на жалобу без проверки менеджера. Такие границы лучше явно написать, чем надеяться, что модель сама догадается о контексте.
Если задача выполняется несколькими людьми, шаблон должен быть понятен без устной легенды. Укажи ожидаемый вход, формат результата, критичные ограничения и кто утверждает итог. Сохрани один маленький пример корректного результата, если он снимает неоднозначность, но избегай добавлять реальные персональные данные.
Для контроля изменений полезно хранить дату и автора последней правки, а также тестовые входы. После обновления правила прогони типичный случай и один случай-исключение. Старую версию лучше не оставлять включённой одновременно с новой: противоречащие инструкции дадут непредсказуемое поведение.
Как обновлять шаблон после ошибки
Не добавляй правило «никогда не ошибайся». Опиши конкретный режим сбоя: «Если в исходнике два разных срока, выведи оба с цитатой и не выбирай один». Сохрани короткий тестовый пример, где старый вариант ошибался, и проверь, что новая инструкция улучшает именно его, не ломая обычный случай. Это не гарантирует результат на всех входах, но делает изменение понятным и повторяемым.
Для API-приложений OpenAI рекомендует выносить постоянные правила отдельно от деталей текущей задачи и хранить production prompts в версионируемых модулях; изменения стоит покрывать тестовыми входами (официальное руководство по prompting). Это конкретная рекомендация для API-проектов, а не требование переносить личные инструкции в код. Если ты работаешь только в пользовательском интерфейсе, достаточно актуальной заметки и небольшой ручной проверки.
Для выбора инструмента под проверяемую задачу смотри сравнение нейросетей на одинаковом тесте.
Разделяй человека, который пишет шаблон, и того, кто его запускает
В команде шаблон должен объяснять, куда вставлять материал, какие поля обязательны и кто проверяет готовый результат. Не проси людей менять постоянные правила каждый раз вручную: пусть они меняют только входные переменные. Отдельно опиши, как сообщать о проблеме и как обновляется утверждённая версия.
Передай шаблон коллеге без дополнительных пояснений и попроси выполнить задачу на безопасных данных. Если он не может понять, что вставлять, добавь пример входа. Если шаблон приводит к сомнительным утверждениям, добавь проверку и сценарий «данных недостаточно»; не увеличивай инструкцию бесконечным перечнем предупреждений.