Системные промпты для AI-агентов презентаций: Руководство разработчика (2026)

Системные промпты для AI-агентов презентаций отличаются от пользовательских промптов — они кодируют роль агента, ограничения и контракт вывода, а не конкретную задачу. Грамотно составленный системный промпт превращает общую LLM в надежного агента генерации слайдов: последовательный голос, предсказуемая структура и вызываемое использование инструментов. Это руководство для разработчиков охватывает шаблон системного промпта из 7 разделов, используемый в продакшене собственным агентским пайплайном 2Slides, готовый к вставке системный промпт для создания слайд-агента с Claude, GPT-4o или DeepSeek, три антипаттерна, которые производят ненадежный вывод, и как интегрировать системный промпт с API 2Slides V1 (generate, create-pdf-slides, create-like-this, generate-narration, jobs/:id, themes/search). Руководство завершается тремя проработанными примерами: питч-дек агент, который преобразует заметки основателя в инвесторские презентации, борд-дек агент, который форматирует квартальные метрики для аудитории топ-менеджмента, и агент инжеста, который конвертирует PDF в презентации.

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

Системные промпты vs пользовательские промпты: в чём реальная разница?

Пользовательский промпт — это задача. Системный промпт — это инструкция по эксплуатации.

Когда продакт-менеджер пишет «сделай мне 10 слайдов о выручке за Q3», это пользовательский промпт. Когда ваш агент стабильно возвращает валидный JSON, никогда не превышает лимит слайдов, всегда указывает источники в заметках докладчика и вызывает эндпоинт

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

В API OpenAI, Anthropic и Google системный промпт — это отдельное поле (

в Anthropic, роль в chat completions OpenAI, в Gemini). Модели обучены придавать ему больший вес по сравнению с репликами пользователя и считать его неизменяемым последующими сообщениями. Это делает его правильным местом для:

• Определения роли — какой это тип агента
• Контрактов вывода — JSON-схема, markdown-формат или структура вызова инструментов
• Жёстких ограничений — лимиты по словам, правила тона, запрещённый контент
• Инвентаря инструментов/API — какие функции можно вызывать и когда
• Правил эскалации — когда отказать, попросить уточнений или передать управление

Пользовательские промпты, пытающиеся закодировать всё это, ломаются в момент, когда текст задачи пользователя становится длинным. Системные промпты сохраняются на протяжении всей сессии.

Шаблон системного промпта из 7 разделов

Каждый надежный агент для генерации слайдов, который мы запустили или проверили в 2Slides, использует тот или иной вариант этой структуры из семи разделов. Порядок имеет значение — LLM придают большее значение первым инструкциям, поэтому роль и контракт идут в начале, а примеры работы — в конце.

1. Идентичность и роль — описание в один абзац того, кто этот агент и что он делает
2. Контракт вывода — точная схема или формат, который агент должен вернуть
3. Жёсткие ограничения — нерушимые правила (длина, тон, запрещённые паттерны)
4. Инвентарь инструментов — каждый доступный API или функция с указанием, когда её вызывать
5. Политика рассуждения — как агент должен думать (цепочка размышлений, самопроверка, эскалация)
6. Обработка ошибок — что делать, когда входные данные неоднозначны, неверно оформлены или не по теме
7. Рабочие примеры — от двух до четырёх полных пар вход/выход, демонстрирующих правильное поведение

Шаблон намеренно опирается на конкретные принципы. Когда мы проверяем агентов, которые ведут себя неправильно в продакшене, причина почти всегда в отсутствующем разделе, а не в плохом. Агенты без инвентаря инструментов галлюцинируют endpoint'ы. Агенты без раздела обработки ошибок выдумывают данные, когда входные данные скудны. Агенты без рабочих примеров теряют тон в длинных разговорах.

Идентификация и роль

Вы — SlideAgent, ассистент по созданию презентаций. Ваша задача — принимать неструктурированные данные от пользователя (заметки, транскрипты, PDF-файлы, сырые данные) и возвращать структурированную спецификацию слайд-дека, которая может быть обработана 2Slides V1 API. Вы не универсальный чат-бот. Вы не отвечаете на викторины, не пишете код и не ведёте долгие беседы. Вы создаёте слайд-деки, затем останавливаетесь.

Выходной контракт

Для каждого сообщения пользователя, описывающего дек для создания, вы ДОЛЖНЫ вывести один JSON-объект, соответствующий этой схеме:

{ "title": string, // 3-10 слов, заглавные буквы в начале слов "audience": string, // например, "инвесторы раунда A", "руководство" "tone": "formal" | "conversational" | "technical", "slide_count": integer, // 5 <= n <= 40 "language": string, // код ISO 639-1, по умолчанию "en" "theme_hint": string, // произвольный текст, будет передан в themes/search "slides": [ { "layout": "title" | "content" | "two-column" | "quote" | "chart" | "image", "heading": string, // <= 12 слов "bullets": string[], // 0-5 элементов, каждый <= 18 слов "speaker_notes": string, // 30-80 слов, полные предложения "image_prompt": string?, // опционально, для макетов с изображениями "chart_data": object? // опционально, для макетов с графиками } ], "api_call": { "endpoint": "generate" | "create-pdf-slides" | "create-like-this", "reasoning": string // одно предложение: почему этот эндпоинт } }

Никакого текста до или после JSON. Никаких markdown-блоков вокруг JSON. Если пользователь задаёт вопрос, не связанный с созданием дека, верните:

{ "error": "not_a_deck_request", "suggestion": string }

Жёсткие ограничения

• Никогда не превышайте 40 слайдов. Если пользователь просит больше, ограничьте до 40 и отметьте это в speaker_notes первого слайда.
• Каждый слайд должен иметь speaker_notes. Пустые speaker_notes — это ошибка.
• Буллеты должны быть грамматически параллельны (все начинаются с глагола или все являются именными фразами — никогда не смешивайте).
• Не выдумывайте статистику. Если пользователь не предоставил число, не пишите его. Используйте "[требуется источник]" в качестве заполнителя.
• Не включайте контактную информацию, телефонные номера или адреса электронной почты, если только пользователь явно не предоставил их.
• Заголовки с заглавными буквами в начале слов. Буллеты с заглавной буквы в начале предложения. Никаких ЗАГЛАВНЫХ БУКВ.
• Отказывайтесь создавать контент, который является клеветническим или содержит медицинские, юридические или финансовые утверждения, не подкреплённые источниками пользователя.

Инвентарь инструментов (2Slides V1 API)

Вы можете указать вызывающему коду использовать эти эндпоинты. Вы не вызываете их самостоятельно; вы указываете их в поле "api_call".

• generate — По умолчанию. Текст на входе, дек на выходе. Используйте для большинства запросов.
• create-pdf-slides — Когда пользователь загрузил или вставил URL PDF-файла. Передайте URL PDF в промпт пользователя.
• create-like-this — Когда пользователь сказал "как мой последний дек" или предоставил URL референсного дека. Повторно использует тему + структуру.
• generate-narration — После создания дека, для добавления TTS-озвучивания к каждому слайду. Вызывайте только когда пользователь явно просит видео или озвучивание.
• download-slides-pages-voices — Пакетная загрузка отрендеренных страниц и аудио. Вызывайте в конце видео-процесса.
• jobs/:id — Опрос статуса асинхронной задачи. Вызывающий код обрабатывает опрос; вы этого не делаете.
• themes/search — Поиск темы по ключевому слову. Ваше поле "theme_hint" будет передано сюда вызывающим кодом.

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

Перед выводом JSON подумайте пошагово внутри тегов :

1. Разберите ввод пользователя. О чём на самом деле дек?
2. Определите аудиторию. Инвесторы? Инженеры? Совет директоров? Отдел продаж?
3. Выберите slide_count на основе плотности контента, а не лести пользователя.
4. Выберите эндпоинт: generate (по умолчанию) | create-pdf-slides | create-like-this.
5. Создайте структуру, затем самопроверка: параллельны ли буллеты? Есть ли источники для чисел?

После выведите JSON-объект. Не включайте рассуждения в финальный вывод — вызывающий код удаляет блоки перед рендерингом.

Обработка ошибок

• Неоднозначная тема: задайте ОДИН уточняющий вопрос в поле "suggestion" ошибочного ответа. Не задавайте несколько вопросов.
• Неправильно сформированный ввод (пользователь вставил бессмыслицу): верните { "error": "unintelligible_input", "suggestion": "..." }.
• Противоречивые инструкции (пользователь хочет 50 слайдов за 5 минут): соблюдайте жёсткое ограничение (макс. 40) и отметьте конфликт в speaker_notes первого слайда.
• URL PDF-файла выглядит недействительным: всё равно выведите JSON с api_call = create-pdf-slides; бэкенд вернёт чёткую ошибку, если URL не может быть получен.

Рабочие примеры

Пример 1: Минимальный запрос

Пользователь: "сделай мне презентацию о нашей выручке за 3 квартал, мы достигли $4.2M, рост 30% год к году, аудитория — совет директоров"

Аудитория — совет директоров -> формальный тон. Презентация по выручке -> стандартно 8-12 слайдов. Цифры из достоверного источника (предоставлены пользователем). Endpoint: generate. { "title": "Обзор выручки за 3 квартал", "audience": "совет директоров", "tone": "formal", "slide_count": 10, "language": "ru", "theme_hint": "minimal corporate finance", "slides": [ { "layout": "title", "heading": "Обзор выручки за 3 квартал", "bullets": [], "speaker_notes": "Титульный слайд. ..." }, ... ], "api_call": { "endpoint": "generate", "reasoning": "Текстовый запрос, без эталонной презентации или PDF." } }

Пример 2: Загрузка PDF

Пользователь: "преобразуй этот технический документ в краткую презентацию на 12 слайдов для инженеров: https://example.com/whitepaper.pdf"

Присутствует URL PDF -> create-pdf-slides. Аудитория — инженеры -> технический тон. Пользователь указал 12 слайдов -> соблюдаем требование. { "title": "Краткое изложение технического документа", "audience": "инженеры-программисты", "tone": "technical", "slide_count": 12, "language": "ru", "theme_hint": "technical documentation dark", "slides": [ ... ], "api_call": { "endpoint": "create-pdf-slides", "reasoning": "Пользователь предоставил URL PDF-файла." } }

Пример 3: Не запрос на создание презентации

Пользователь: "какая столица Франции?"

{ "error": "not_a_deck_request", "suggestion": "Я создаю презентации. Попробуйте: 'создай презентацию на 5 слайдов о Франции'." }

Промпт выше составляет примерно 1 800 токенов. Это рекомендуемый максимум — всё, что длиннее, начинает вытеснять фактический ввод пользователя на моделях с контекстным окном 8k или 16k. Для моделей с контекстом 200k вы можете безопасно расширить примеры, чтобы охватить больше граничных случаев.

## Интеграция с API 2Slides V1

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

- **`POST /api/v1/slides/generate`** — Основной рабочий эндпоинт. Принимает текстовый промпт плюс необязательные структурированные подсказки (количество слайдов, язык, ID темы) и возвращает ID задачи. Девяносто процентов трафика агентов приходится на этот эндпоинт.
- **`POST /api/v1/slides/create-pdf-slides`** — Принимает URL PDF-файла и конвертирует его в презентацию. Используйте, когда пользователь загружает документ. Выполняет извлечение, разбивку на части и суммаризацию на стороне сервера, поэтому вашему агенту не нужен парсер PDF.
- **`POST /api/v1/slides/create-like-this`** — Принимает URL или ID эталонной презентации и новую тему. Повторно использует визуальную тему и структурный ритм эталона. Используйте для рабочих процессов вроде «сделай похожим на нашу последнюю презентацию для совета директоров».
- **`POST /api/v1/slides/generate-narration`** — Добавляет голосовое озвучивание TTS к существующей презентации. Возвращает URL-адреса аудио для каждого слайда. Используйте после `generate`, когда конечный результат — видео.
- **`GET /api/v1/slides/download-slides-pages-voices`** — Пакетный эндпоинт, который возвращает отрендеренные изображения страниц и аудио озвучивания в одном ответе. Используйте на финальном этапе конвейера экспорта видео.
- **`GET /api/v1/jobs/:id`** — Эндпоинт для опроса статуса. Ваш агент не вызывает его напрямую; это делает вызывающий код. Возвращает `pending`, `processing`, `success` или `failed` плюс финальный URL презентации при завершении.
- **`GET /api/v1/themes/search?q=...`** — Поиск по ключевым словам в публичной библиотеке тем. Передайте поле `theme_hint` из вывода системного промпта сюда, чтобы преобразовать его в конкретный ID темы перед вызовом `generate`.

Полный цикл работы агента выглядит так в псевдокоде:

```ts
const completion = await llm.messages.create({
  system: SYSTEM_PROMPT,           // шаблон из 7 секций выше
  messages: [{ role: "user", content: userInput }],
});

const spec = JSON.parse(stripThinking(completion.content));
if (spec.error) return handleError(spec);

const theme = await fetch(`/api/v1/themes/search?q=${spec.theme_hint}`);
const job = await fetch(`/api/v1/slides/${spec.api_call.endpoint}`, {
  method: "POST",
  body: JSON.stringify({ ...spec, themeId: theme.id }),
});

const result = await pollJob(job.id); // обращается к /api/v1/jobs/:id
return result.deckUrl;

Если вы новичок в структуре API, руководство разработчика по созданию AI-агента для презентаций подробно описывает весь процесс с рабочим TypeScript-кодом. Для архитектуры более высокого уровня на основе навыков — где системный промпт является лишь одним из нескольких навыков — смотрите обзор навыков AI-агента для слайдов.

3 анти-паттерна, которые ломают агентов для презентаций

После анализа десятков продакшн-агентов — от внутренних инструментов аналитики до публичных sales-копилотов — одни и те же три режима отказа появляются снова и снова.

Анти-паттерн 1: Неограниченный выходной контракт

Симптом: Агент иногда возвращает JSON, иногда markdown, иногда вежливый абзац. Ваш парсер выдает

один раз на каждые 50 запросов.

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

Решение: Напишите схему в системном промпте. Скажите явно: "Никакого текста до или после JSON. Никаких markdown-ограждений вокруг JSON." Затем пропускайте каждый вывод через валидатор (Zod, Pydantic, io-ts) и повторяйте попытку при ошибке. Рассматривайте соответствие схеме как жесткое требование продукта, а не приятное дополнение.

Анти-паттерн 2: Дрейф инвентаря инструментов

Симптом: Агент уверенно говорит пользователю "Я вызову эндпоинт

" — эндпоинт, которого не существует. Презентация пользователя так и не приходит.

Причина: Системный промпт упоминает инструменты в прозе, а не в структурированном инвентаре, поэтому модель галлюцинирует вариации. Или инвентарь устарел после того, как вы выпустили новые эндпоинты.

Решение: Поддерживайте единый канонический инвентарь инструментов в системном промпте, обновляемый каждый раз при изменении API. Если в вашем API 7 эндпоинтов, перечислите ровно 7, каждый с одной строкой, описывающей, когда его вызывать. Запретите модели называть что-либо ещё — "Если ни один из эндпоинтов выше не подходит, верни

и эскалируй."

Анти-паттерн 3: Галлюцинации статистики

Симптом: Пользователь говорит "сделай презентацию о наших показателях за Q3" без предоставления цифр. Агент радостно пишет "Выручка выросла на 47,3% до $8,2M." Финансовый директор в ярости.

Причина: Нет жесткого ограничения, запрещающего придумывать данные. Модель по умолчанию генерирует правдоподобно звучащую выдумку, потому что это то, что делает большинство LLM при недостаточной спецификации.

Решение: Добавьте явное правило: "Не придумывай статистику. Если пользователь не предоставил число, используй

в качестве заполнителя." Затем сканируйте выводы с помощью регулярного выражения или отдельной LLM-проверки на подозрительную конкретность. Это одно правило выявило больше багов уровня эскалации клиентов в нашем анализе, чем любое другое.

Практический пример 1: Агент для питч-деков

Агент для питч-деков преобразует заметки основателя в презентацию для инвесторов из 10 слайдов. Добавьте эти строки к базовому системному промпту:

# Специализация: Режим питч-дека
При создании питч-дека используйте точно такую структуру:
1. Титульный слайд
2. Проблема
3. Решение
4. Объём рынка (TAM/SAM/SOM)
5. Демонстрация продукта / скриншот
6. Метрики роста
7. Бизнес-модель
8. Конкуренты
9. Команда
10. Запрос (сумма финансирования + использование средств)

Принудительно slide_count = 10. Принудительно tone = "conversational but confident."
Если пользователь не предоставил цифры по объёму рынка, метрикам роста или запросу,
используйте "[source needed]" — не придумывайте данные.

Пример входных данных: "B2B SaaS для стоматологических клиник, помогаем автоматизировать страховые претензии, есть 12 платящих клиентов, привлекаем $1.5M посевного раунда."

Пример результата (сокращённо): JSON из десяти слайдов с фиксированной структурой,

, , и слайд с метриками роста, показывающий вместо выдуманных цифр.

Практический пример 2: Агент для презентаций совету директоров

Презентации для совета директоров имеют другой формат: формальный тон, плотные таблицы, никаких эмодзи, определенный порядок слайдов, который ожидают финансовые директора. Добавьте:

# Специализация: Режим презентации для совета директоров
Используйте точно эту структуру для заседаний совета директоров:
1. Краткое резюме (3 пункта)
2. Финансы (выручка, маржа, runway)
3. Таблица KPI (табличная компоновка)
4. Стратегические инициативы (статус + риски)
5. План найма
6. Риски и меры по их снижению
7. Запросы к совету директоров

Установить тон = "formal." Установить язык в соответствии с локалью пользователя.
Каждая цифра должна иметь источник в speaker_notes.
Никаких слайдов с изображениями — презентации для совета директоров состоят из текста и таблиц.

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

, когда совет уже видел предыдущие квартальные презентации. Передайте URL предыдущей презентации; новая презентация унаследует тему и темп.

Практический Пример 3: Агент Обработки PDF-в-Презентацию

Этот агент преобразует технические документы клиентов, исследовательские PDF-файлы или RFP в понятные сводные презентации. Его проще всего создать, потому что конечная точка

от 2Slides выполняет большую часть работы.

# Специализация: Режим Обработки PDF
Триггер: пользователь предоставляет URL, заканчивающийся на .pdf ИЛИ явно говорит
"преобразуй этот PDF/технический документ/отчёт в слайды."

Всегда устанавливайте api_call.endpoint = "create-pdf-slides".
Устанавливайте slide_count в зависимости от длины PDF:
  - < 5 страниц -> 5 слайдов
  - 5-20 страниц -> 8-12 слайдов
  - 20-50 страниц -> 15-20 слайдов
  - > 50 страниц -> 25-30 слайдов (максимум 30)

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

Для агентов, работающих внутри Claude Desktop или аналогичного MCP-хоста, поток обработки PDF можно настроить менее чем за час — смотрите как использовать Claude MCP для создания презентаций для полного руководства.

Часто задаваемые вопросы

Следует ли размещать системный промпт в коде или в базе данных?

Для production-агентов размещайте его в системе контроля версий (в виде

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

Какой должна быть длина системного промпта?

Для агентов, генерирующих слайды, оптимальный диапазон — от 1 500 до 2 500 токенов. Более короткие промпты упускают ограничения и дают сбои на граничных случаях. Более длинные промпты вытесняют фактический ввод пользователя на моделях с меньшим контекстом и часто повторяются. Если у вас более 3 000 токенов, проверьте на избыточность — возможно, одно и то же правило сформулировано дважды.

Нужны ли мне разные системные промпты для Claude, GPT-4o и DeepSeek?

Нужны лишь незначительные корректировки. Шаблон из 7 секций работает для всех трёх моделей. Claude хорошо реагирует на структурирование с XML-тегами (

, ). GPT-4o предпочитает чистый markdown с пронумерованными правилами. DeepSeek работает с обоими форматами, но выигрывает от более явных примеров. Напишите один базовый промпт, затем проведите A/B-тестирование небольших вариаций формата для каждой модели.

Могу ли я обновлять системный промпт без повторного развёртывания?

Да — и у вас должна быть такая возможность для быстрой итерации. Храните промпт в переменной окружения или сервисе feature-flags, чтобы SRE могли откатить неудачный промпт за секунды. Относитесь к неудачному промпту как к неудачному деплою: это production-инцидент, и он требует тех же мер по контролю масштаба воздействия.

Как тестировать системный промпт?

Создайте регрессионный набор из 50–200 пар ввода/вывода, покрывающих реальное распределение пользователей: стандартные презентации, adversarial-входы, попытки некорректного JSON, нерелевантные запросы. Прогоняйте весь набор при каждом изменении промпта и оценивайте соответствие схеме плюс экспертную оценку качества. Это инвестиция в разработку с наивысшей отдачей для надёжности агента.

Вывод

Системный промт — это инфраструктура, а не текст. Это то, что превращает универсальную LLM в надежного агента для создания слайдов с известным контрактом вывода, фиксированным набором инструментов и предсказуемыми режимами отказа. Разработчики, которые относятся к системному промту как к продуктовому артефакту — версионируют его, тестируют, мониторят — создают агентов, которые выдерживают столкновение с реальными пользователями. Разработчики, которые относятся к нему как к разовому упражнению по prompt-инженерии, создают демо.

Шаблон из 7 разделов и готовый к продакшену пример в этом руководстве — это отправная точка, а не конечная цель. Форкните их, адаптируйте под ваш случай использования, интегрируйте с 2Slides V1 API и — что самое важное — постройте регрессионную систему тестирования до релиза. Агенты, которые победят в 2026 году — это те, чьи промты спроектированы с той же строгостью, что и их код.

Запустите своего агента для слайдов в продакшен — получите API-ключ 2Slides или изучите MCP-сервер.