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