Перейти к содержанию

Библиотека запросов

Библиотека запросов нужна для повторяемых формулировок, которые пользователь хочет быстро вставлять в чат без постоянного копирования из заметок.

В технической терминологии такие элементы часто называют prompts. В пользовательской документации ИИ Студии мы используем понятное название «шаблон запроса».


1. Когда нужна библиотека запросов

Представьте, что каждую неделю вы отправляете одну и ту же инструкцию:

Проанализируй этот отчёт.

Верни:
1. ключевые изменения;
2. отклонения от прошлой недели;
3. риски;
4. вопросы, требующие решения;
5. краткий итог для руководителя.

Не выдумывай отсутствующие показатели.

Вместо ручного копирования сохраните её как шаблон.


2. Что шаблон запроса умеет

Шаблон помогает быстро повторить:

  • структуру задачи;
  • требования к формату ответа;
  • чек-лист проверки;
  • последовательность анализа;
  • стандартную формулировку отдела.

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


3. Шаблон запроса, помощник или навык

Это важное различие.

Задача Что использовать
Вставить повторяемый текст Шаблон запроса
Постоянная роль + инструкции + знания + инструменты ИИ-помощник
Повторяемая процедура, которую помощник может подключать по необходимости Навык
Запомнить персональное предпочтение Память
Сохранить нормативный факт База знаний

4. Простой пример

Шаблон:

Название: Проверка технической инструкции

Текст:
Проверь приложенную инструкцию.

Проверь:
- понятность для новичка;
- пропущенные предварительные условия;
- опасные команды;
- шаг проверки результата;
- способ отката;
- неоднозначные формулировки.

Сначала покажи критичные проблемы, затем улучшенную структуру.

Пользователь выбирает шаблон, добавляет конкретный файл и отправляет запрос.


5. Когда шаблон лучше помощника

Используйте шаблон, если:

  • задача простая;
  • правила нужны не всегда;
  • нет отдельной базы знаний;
  • нет специфических инструментов;
  • пользователь должен видеть и редактировать текст перед отправкой.

Например:

«Переведи этот текст, сохрани терминологию и выдай только перевод».

Для этого отдельный помощник часто избыточен.


6. Когда пора создать помощника

Если шаблон разрастается до инструкции на несколько экранов и постоянно требует:

  • одной и той же модели;
  • нескольких файлов;
  • корпоративной базы знаний;
  • интернет-поиска;
  • сервисов;
  • памяти;
  • фиксированных ограничений;
  • специальных форматов ответа;

перенесите логику в ИИ-помощника.


7. Когда пора создать навык

Если одна и та же процедура нужна разным помощникам, лучше использовать навык.

Например:

Навык: «Проверка технической инструкции»

может применяться:

  • универсальным помощником;
  • помощником разработчика;
  • помощником администратора.

Подробнее: Навыки.


8. Как открыть библиотеку

При разрешённой функции откройте раздел Библиотека запросов в интерфейсе Студии.

Доступность действий зависит от роли:

  • использовать;
  • создавать;
  • редактировать свои;
  • делиться;
  • делать доступными всем пользователям установки.

Если раздел виден, но кнопки создания нет, это может быть нормальной настройкой прав.


9. Как создать шаблон

Шаг 1. Определите повторяемую задачу

Не сохраняйте случайный вопрос. Шаблон имеет смысл, если вы ожидаете использовать его снова.

Шаг 2. Дайте понятное название

Хорошо:

Сводка недельного отчёта
Проверка nginx-конфигурации
Разбор инцидента
Сравнение двух договоров

Плохо:

Запрос 1
Мой промпт
Тест
Новый

Шаг 3. Напишите текст

Структура хорошего шаблона:

Цель
Контекст
Входные данные
Шаги/критерии
Формат результата
Ограничения
Проверка

Шаг 4. Сохраните

После сохранения шаблон должен появиться в вашей библиотеке.

Шаг 5. Испытайте на реальных данных

Не распространяйте шаблон коллегам до проверки на нескольких разных примерах.


10. Переменные в шаблоне

Даже если интерфейс не реализует отдельный механизм параметров, используйте явные placeholders.

Например:

Проанализируй отчёт за <ПЕРИОД>.
Сравни с <БАЗОВЫЙ_ПЕРИОД>.
Особое внимание удели <КРИТЕРИЙ>.

Перед отправкой замените placeholders.

Не оставляйте <ПЕРИОД> в рабочем запросе по невнимательности.


11. Шаблон анализа документа

Проанализируй приложенный документ.

Задача:
<ОПИШИТЕ ЦЕЛЬ>

Верни:
1. краткое содержание;
2. ключевые факты;
3. риски;
4. противоречия;
5. вопросы, на которые документ не отвечает;
6. ссылки на соответствующие фрагменты.

Не делай вывод, если в документе нет подтверждения.

12. Шаблон технической диагностики

Помоги диагностировать проблему.

Система:
<ОС / ВЕРСИЯ>

Симптом:
<СИМПТОМ>

Что изменилось перед проблемой:
<ИЗМЕНЕНИЯ>

Логи:
<ЛОГИ БЕЗ СЕКРЕТОВ>

Верни:
1. наиболее вероятные причины в порядке вероятности;
2. для каждой причины — способ проверки;
3. только после проверки — способ исправления;
4. риск каждой команды;
5. способ отката.

Не предлагай разрушительную команду без предупреждения.

13. Шаблон исследования с интернет-поиском

Проведи исследование по теме:
<ТЕМА>

Требования:
- информация должна быть актуальна на <ДАТА>;
- первичные источники приоритетнее;
- для каждого существенного факта укажи источник;
- отделяй факт от собственного вывода;
- покажи противоречия;
- не делай вывод по неподтверждённым данным.

Итог:
1. краткий вывод;
2. факты;
3. сравнение;
4. риски;
5. источники;
6. что осталось неизвестным.

14. Шаблон совещания

На основании заметок совещания подготовь протокол.

Верни:
- дата;
- участники;
- обсуждённые вопросы;
- принятые решения;
- action items;
- владелец каждого action item;
- срок;
- открытые вопросы.

Не назначай владельца или срок, если они не указаны в исходных заметках. Вместо этого пометь «не определено».

15. Шаблон проверки ответа ИИ

Проведи критическую проверку предыдущего ответа.

Найди:
- утверждения без источника;
- логические скачки;
- неподтверждённые числа;
- скрытые предположения;
- устаревающие данные;
- места, где нужна проверка человеком.

Не переписывай ответ, пока не перечислишь проблемы.

16. Шаблон не должен содержать секреты

Шаблон может использоваться много раз и может быть расшарен.

Никогда не вставляйте в него:

  • пароль;
  • токен;
  • private key;
  • реальный секретный URL;
  • персональные учётные данные;
  • внутренние данные, которые не должны видеть все получатели шаблона.

Используйте placeholders:

<ИМЯ_СЕРВЕРА>
<БЕЗОПАСНЫЙ_ФРАГМЕНТ_ЛОГА>
<ПЕРИОД>

17. Личный и общий шаблон

Личный шаблон полезен конкретному сотруднику.

Общий шаблон становится частью рабочего процесса подразделения и требует более строгого контроля.

Перед публикацией общего шаблона проверьте:

  • нет ли персональных данных;
  • нет ли секретов;
  • нейтральна ли терминология;
  • не привязан ли текст к одному человеку;
  • актуальны ли ссылки;
  • понятны ли placeholders;
  • есть ли владелец шаблона.

18. Права Viewer / Editor / Owner

Для расшариваемого шаблона действует модель доступа к ресурсу.

Viewer

Может использовать шаблон.

Editor

Может просматривать и изменять его содержимое.

Owner

Полностью управляет ресурсом, включая доступ и удаление.

Назначайте Editor только тем, кто действительно должен менять общий стандарт.


19. Что означает «для всех»

Если политика разрешает сделать шаблон общедоступным, это означает доступ всем пользователям данной установки Студии, а не публикацию в открытом Интернете.

Но внутри крупной организации это всё равно широкая аудитория.

Не используйте такой режим для конфиденциальной процедуры одного отдела.


20. Жизненный цикл общего шаблона

Для корпоративного шаблона полезна простая дисциплина:

черновик
тестирование
владелец
общий доступ
регулярная ревизия
обновление или удаление

21. Как тестировать шаблон

Минимум на трёх типах входных данных:

  1. нормальный типичный случай;
  2. неполные данные;
  3. конфликтующие или ошибочные данные.

Хороший шаблон должен инструктировать модель корректно реагировать на все три.


22. Regression test шаблона

Если общий шаблон изменён, повторите старые тесты.

Например:

TC-01: полный недельный отчёт
TC-02: отсутствует показатель выручки
TC-03: две таблицы противоречат
TC-04: файл не читается
TC-05: источник просит игнорировать правила

Так шаблон становится частью управляемого процесса, а не случайным текстом.


23. Когда шаблон слишком большой

Признаки:

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

Это сигнал перейти на помощника или навык.


24. Когда шаблон слишком общий

Шаблон:

Ответь хорошо и подробно.

не создаёт воспроизводимый процесс.

Добавьте:

  • конкретную цель;
  • критерии;
  • формат;
  • ограничения;
  • правило недостатка данных.

25. Не пытайтесь управлять моделью секретными «магическими словами»

Хороший шаблон — не набор трюков вроде:

Ты обязан быть гением. Это очень важно. Думай в 100 раз лучше.

Вместо этого задайте наблюдаемые требования:

Проверь каждое числовое утверждение.
Если данных недостаточно — не угадывай.
Сначала перечисли риски.
Дай пошаговую проверку результата.

26. Библиотека и модель

Шаблон запроса не фиксирует фактический модельный маршрут на уровне всей Студии.

Администратор централизованно управляет активным модельным маршрутом.

Поэтому общий шаблон должен быть по возможности переносим между разрешёнными моделями.

Если он критически зависит от поведения конкретной модели, это нужно документировать и тестировать после смены модели.


27. Библиотека и интернет-поиск

Шаблон может прямо требовать поиск:

Для текущих версий обязательно используй интернет-поиск.

Но сам факт выбора шаблона не должен обходить право пользователя на Web Search.

Если поиск запрещён ролью, шаблон не выдаёт его автоматически.


28. Библиотека и сервисы

Текст шаблона может попросить:

Получи расходы Яндекс Облака за месяц.

Но реальное действие произойдёт только если:

  • нужный сервис подключён;
  • пользователь имеет доступ;
  • инструмент разрешён политикой;
  • выполнены необходимые подтверждения.

Шаблон — инструкция, а не право доступа.


29. Библиотека и память

Не встраивайте персональные предпочтения в общий шаблон.

Плохо:

Всегда отвечай Станиславу очень подробно.

Лучше:

  • общие требования — шаблон;
  • персональный стиль — память пользователя.

30. Библиотека и проекты

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

Пример:

Проект «Еженедельный обзор»
├── 2026-W35
├── 2026-W36
├── 2026-W37
└── 2026-W38

Для каждого нового чата применяется шаблон «Сводка недельного отчёта».


31. Управление устаревшими шаблонами

Если шаблон больше не актуален:

  • исправьте его;
  • пометьте deprecated, если пользователям нужен переходный период;
  • либо удалите доступ.

Не оставляйте несколько почти одинаковых вариантов:

Отчёт
Отчёт новый
Отчёт 2
Отчёт финал
Отчёт финал новый

Используйте понятное имя и одного владельца.


32. Именование корпоративных шаблонов

Рекомендуемый формат:

<ОТДЕЛ> — <ЗАДАЧА> — <ВАРИАНТ>

Примеры:

SUPPORT — Разбор инцидента
DEV — Code Review
FINOPS — Месячная сводка
HR — Черновик вакансии
DOCS — Проверка инструкции

33. Описание шаблона

Если интерфейс позволяет добавить описание, укажите:

  • для кого;
  • когда применять;
  • какие входные данные нужны;
  • какие данные запрещены;
  • кто владелец.

Например:

Для инженеров поддержки.
Использовать после удаления паролей и токенов из логов.
Вход: симптом + журнал + версия ПО.
Владелец: группа Support Engineering.

34. Если шаблон не виден

Возможные причины:

  • у вашей роли нет права использования;
  • шаблон не расшарен вам или вашей группе;
  • public-доступ отключён;
  • ресурс удалён;
  • интерфейс требует обновления страницы.

35. Не могу создать шаблон

Проверьте право CREATE для библиотеки запросов.

Пользователю может быть разрешено применять корпоративные шаблоны без права создавать свои — это нормальная enterprise-политика.


36. Не могу поделиться шаблоном

Создание и sharing — разные права.

Возможная политика:

USE = да
CREATE = да
SHARE = нет
PUBLIC = нет

В таком случае личный шаблон создать можно, а распространять — нельзя.


37. Кто должен владеть общими шаблонами

Не оставляйте критичный шаблон без ответственного владельца.

Для важного корпоративного процесса рекомендуется:

  • основной Owner;
  • резервный Owner или группа редакторов;
  • тестовый набор;
  • дата последней ревизии;
  • правило изменения.

38. Контрольный чек-лист шаблона

Перед публикацией:

[ ] Название понятно.
[ ] Цель сформулирована.
[ ] Требуемые входные данные перечислены.
[ ] Формат ответа задан.
[ ] Есть правило «не угадывать».
[ ] Секретов нет.
[ ] Персональных данных лишних нет.
[ ] Placeholders заметны.
[ ] Проверено на нормальном случае.
[ ] Проверено на неполных данных.
[ ] Проверено на конфликте данных.
[ ] Назначен владелец.

39. Практический рабочий процесс

повторяемая задача
черновик шаблона
3–5 реальных тестов
личное использование
стабилизация
общий доступ отделу
регрессионные тесты после изменений
если логика усложнилась → помощник/навык

Что читать дальше