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

За полгода работы с Claude и GPT у меня скопилось около 200 сохранённых промтов для нейросети: для ревью кода, для черновиков писем клиентам, для разбора логов бота на aiogram. Каждый раз лезть в историю чатов и искать «тот самый» текст запроса - это 5-10 минут, которые за месяц складываются в несколько часов. Ниже показываю, как я собрал личную библиотеку промтов: с категориями, шаблонами и подключением к рабочим инструментам.

Зачем нужна личная база промптов для нейросети

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

Я считаю библиотеку промтов такой же рабочей базой, как сниппеты кода в IDE. У программиста есть готовые куски на частые задачи, у меня - готовые формулировки на частые типы запросов: разбор ошибки в логах, генерация текста для карточки товара, объяснение непонятного куска чужого кода. Отдельно держу промты под конкретные проекты: для интеграции с T‑Bank эквайрингом одни формулировки, для скриптов на Tilda - другие, потому что контекст и терминология разные.

Есть и денежная сторона. Когда делаю клиенту чат-бота с базой знаний, часть стоимости проекта - это именно подбор и тестирование системных промтов под конкретный бизнес. Если у меня уже есть библиотека проверенных заготовок под типовые сценарии (обработка возражений, вежливый отказ, эскалация на оператора), тестирование занимает не неделю, а два-три дня.

Категории и теги: структура библиотеки промптов

Плоский список из 200 файлов бесполезен - в нём не найти ничего быстрее, чем в истории чатов. Я делю промты на три уровня.

• Домен - разработка, копирайтинг, аналитика, поддержка клиентов, личные задачи. Это папки верхнего уровня.
• Тип задачи внутри домена - для разработки это ревью кода, объяснение ошибки, генерация тестов, рефакторинг. Для копирайтинга - карточка товара, email-рассылка, ответ на негативный отзыв.
• Теги поперёк структуры - модель (claude, gpt), формат вывода (json, markdown, обычный текст), проект (если промт написан под конкретного клиента и переносить его на другие задачи бессмысленно).

Теги решают проблему, которую не решают папки: один и тот же промт может относиться сразу к двум доменам. Например, промт «разбери переписку с клиентом и вытащи из неё требования к ТЗ» - это одновременно поддержка и разработка. В папку его кладу в «поддержку», а тегом отмечаю «требования» и «claude», чтобы находить и через поиск по тегу.

Отдельный тег завожу для статуса: «черновик», «проверено», «устарело». Модели меняются, и промт, написанный под старую версию GPT, через полгода может работать хуже или вообще игнорировать часть инструкции. Без пометки о статусе в библиотеке накапливается мусор, который выдаёт себя за рабочие заготовки.

Где хранить шаблоны запросов: Obsidian, Notion, markdown

Перебрал три варианта, прежде чем осесть на одном. Разница в основном в том, насколько удобно версионировать изменения и работать без интернета.

Я храню библиотеку как папку markdown-файлов в приватном git-репозитории и открываю её через Obsidian ради удобной навигации по тегам и ссылкам между заметками. Плюс такого подхода в том, что каждый промт - это просто текстовый файл, который можно скопировать в любой чат без форматирования, и при этом вся история правок видна в git log: когда именно я поменял формулировку и почему предыдущая версия перестала работать.

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

Как оформить карточку промпта с переменными

Промт, вписанный сплошным текстом, плохо переиспользуется - каждый раз приходится вручную менять детали внутри абзаца. Я оформляю карточку по фиксированной структуре: роль модели, задача, ограничения, формат вывода, пример. Переменные части помечаю плейсхолдерами вроде {{ТЕКСТ}} или {{ЯЗЫК}}, чтобы при вставке в чат заменить их одним движением.

Пример карточки для ревью кода:

• Роль: «Ты опытный бэкенд-разработчик, специализируешься на {{ЯЗЫК}}».
• Задача: «Проверь код ниже на баги, проблемы безопасности и избыточную сложность».
• Ограничения: «Не переписывай код целиком, указывай только конкретные строки и что в них не так».
• Формат вывода: «Список из пунктов: файл, строка, проблема, предложенное исправление».
• Код: {{КОД}}

Такая структура переносится между моделями почти без изменений: под Claude и под GPT работает одинаково, разве что для Claude системную роль выношу в system-промт отдельно, а не в начало сообщения. В названии файла указываю домен, тип задачи и модель, под которую промт оттестирован, например «dev-code-review-claude.md» - по имени сразу понятно, что внутри, без открытия файла.

Промпт-инжиниринг на практике: примеры и подключение к ботам

Библиотека приносит пользу не только в ручных чатах, но и когда промты нужно встраивать в рабочие процессы. У меня в базе отдельная папка под системные промты для продакшена: тексты, которые зашиты в код Telegram-бота на aiogram или в ноду n8n, а не вводятся вручную.

Примеры из практики:

• Для бота поддержки на aiogram - промт с жёстким ограничением по формату ответа (не больше 3 предложений, без markdown), потому что Telegram обрезает длинные сообщения и ломает вёрстку.
• Для сценария в n8n, который разбирает заявки с сайта на Tilda и определяет их приоритет - промт с примерами трёх категорий заявок и требованием вернуть строго JSON с полем «приоритет», иначе следующая нода workflow падает с ошибкой парсинга.
• Для скрипта, который сверяет статус доставки СДЭК с текстом уведомления клиенту - промт, который переводит технический статус трекинга в человеческую формулировку без канцелярита.
• Для карточек товаров в WooCommerce - промт с примером «хорошего» и «плохого» описания, потому что без образца модель скатывается в общие фразы про «качественный товар».

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

Если библиотека промтов уже наработана, интеграция с ботом или CRM через AI-интеграции на Claude API занимает меньше времени - основная часть работы над формулировками уже сделана, остаётся адаптировать под конкретный сценарий и протестировать граничные случаи.

Частые вопросы

Сколько промтов стоит хранить, чтобы не запутаться в библиотеке

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

Нужна ли отдельная программа для хранения промптов или хватит заметок

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

Как обновлять промты при смене версии модели

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

Можно ли использовать чужие подборки промтов из интернета

Как отправную точку - да, но копировать один в один в рабочую библиотеку не советую. Чужой промт обычно написан под другой контекст и другую модель, и без адаптации под свою задачу он либо не сработает, либо даст расплывчатый результат. Беру структуру идеи, а формулировку и ограничения переписываю под конкретный кейс и обязательно тестирую перед тем, как класть в свою базу.