Документ 'Полезные промпты', в который каждый сотрудник добавляет свою находку, за полгода превращается в список из полусотни строк, половина из которых уже не работает с текущей версией модели и никто не знает, кто их писал и зачем. После этого материала вы соберёте библиотеку, которой команда реально будет пользоваться, а не просто открывать раз в квартал для уборки.
Рабочая библиотека промптов держится на трёх вещах, которых обычно нет в стихийном списке: владелец у каждого промпта (кто отвечает, если он перестал работать), дата последней проверки (промпт, не проверенный полгода, может использовать устаревшие названия функций или тариф), и явная категория по задаче, а не по отделу. Структура записи: название задачи, сам промпт, пример входа и ожидаемого выхода, дата и модель последней проверки, владелец. Регулярный аудит - не добавление новых промптов, а вопрос по каждому существующему: работает ли он ещё, и если никто не может ответить - удалить, а не оставлять на всякий случай.
Почему стихийный список промптов перестаёт работать
Общий документ, куда каждый добавляет находку, решает задачу сбора, но не задачу использования. Через несколько месяцев в нём накапливаются промпты без контекста (непонятно, для какой именно задачи они писались), без владельца (никто не может сказать, работают ли они ещё), и дубли с разной формулировкой одной и той же задачи. Найти нужный промпт в таком списке часто дольше, чем написать его заново - и библиотека перестаёт снижать разбросанность работы, ради которой создавалась.
Структура записи, которая делает библиотеку рабочей
Название задачи - конкретное действие, не тема ('ответ клиенту на жалобу о задержке', не 'работа с клиентами').
Сам промпт - с явными полями для заполнения, не готовый текст под одну конкретную ситуацию.
Пример входа и ожидаемого выхода - показывает, как заполнять поля и что считать хорошим результатом, без этого шаблон сложно применить правильно с первого раза.
Дата и модель последней проверки - промпт, не проверенный полгода, может ссылаться на устаревшее название функции, тариф или формат, который сервис уже изменил.
Владелец - конкретный человек, к которому можно обратиться, если промпт перестал давать нужный результат, а не общая формулировка 'команда маркетинга'.
Категории по задаче, не по отделу
Деление по отделам ('промпты маркетинга', 'промпты поддержки') создаёт дубли - похожая задача 'написать ответ клиенту' нужна и продажам, и поддержке, и попадёт в библиотеку дважды под разными названиями. Деление по типу задачи (ответы клиентам, анализ документов, черновики текстов, обработка данных) позволяет разным отделам находить и переиспользовать уже существующий рабочий промпт, а не писать свой с нуля.
Шаблон записи для библиотеки промптов:
Задача: [конкретное действие, не тема]
Категория: [тип задачи, не отдел]
Промпт: [текст с явными полями для заполнения]
Пример входа: [конкретный образец]
Пример ожидаемого выхода: [как должен выглядеть хороший результат]
Проверено: [дата] на [название модели/сервиса]
Владелец: [конкретный человек]
Аудит - не добавление, а вопрос к каждому промпту
Регулярный аудит библиотеки - это не про пополнение новыми находками, а про проверку уже существующих записей: работает ли этот промпт ещё с текущей версией сервиса, актуален ли пример, жив ли указанный владелец в команде. Если ответить нельзя - промпт нужно удалить или обновить, а не оставлять 'на всякий случай': нерабочая запись в библиотеке хуже отсутствующей, потому что её используют, получают плохой результат и теряют доверие ко всей библиотеке.
Частота аудита зависит от того, как часто меняется сам сервис, для которого написаны промпты - при значимом обновлении интерфейса или модели стоит внепланово проверить хотя бы промпты из самых используемых категорий, не дожидаясь планового цикла.
Частые вопросы
Чем рабочая библиотека промптов отличается от общего документа, куда все добавляют находки?
У каждой записи есть владелец, дата последней проверки и явная категория по типу задачи - это позволяет понять, актуален ли ещё промпт и к кому обратиться, если он перестал работать. Стихийный список без этих полей превращается в свалку неизвестной актуальности.
Как лучше категоризировать промпты - по отделам или по типу задачи?
По типу задачи (ответы клиентам, анализ документов, черновики текстов). Деление по отделам создаёт дубли, потому что похожая задача часто нужна нескольким командам одновременно, и каждая пишет свой вариант вместо переиспользования существующего.
Что делать с промптом, для которого не можем найти владельца?
Такой промпт стоит удалить или явно переназначить владельца, а не оставлять в библиотеке - запись без ответственного человека никто не обновит, когда она перестанет работать, и со временем создаст ложное доверие к устаревшей формулировке.
Как часто нужно проверять промпты в библиотеке?
Регулярно по плану, и дополнительно внепланово при значимом обновлении сервиса или модели, для которых промпты написаны - обновление интерфейса или функций может сделать формулировку неактуальной раньше следующего планового цикла.
Нужен ли пример входа и выхода для каждого промпта в библиотеке?
Да, без конкретного примера сложно правильно заполнить поля шаблона с первого раза и понять, что считать хорошим результатом - голый шаблон без примера чаще используется неправильно.
Почему нерабочий промпт в библиотеке хуже, чем его отсутствие?
Потому что его используют, получают плохой результат и теряют доверие ко всей библиотеке в целом, а не только к этой записи - отсутствующий промпт просто заставит человека написать свой, не разочаровав в системе.