Вы проверяете договоры по одной и той же схеме или каждый раз собираете коммерческое предложение из одинаковых блоков. Вместо того чтобы заново объяснять этот порядок в каждом чате, рабочую технологию можно оформить как системный промпт: постоянную инструкцию, которая задаёт контекст, алгоритм, ограничения и форму готового результата.
Ниже разберём, как устроен системный промпт, чем он отличается от обычного запроса и агентного скилла, как связать его с генерацией документов и как проверить инструкцию до передачи команде.
Системный промпт: короткий ответ
Системный промпт хранит постоянные правила ассистента: назначение, разрешённые источники, обязательные ограничения, критерии результата и точки остановки. Данные конкретной задачи передавайте отдельно, а саму инструкцию проверяйте на обычных, неполных, противоречивых и конфликтных входах.
- начните с конечного рабочего объекта и владельца процесса;
- добавьте только устойчивый контекст компании;
- отделите обязательный алгоритм от шагов, которые модель может выбрать сама;
- не храните в промпте секреты и быстро меняющиеся справочники;
- права доступа обеспечивайте приложением, а не текстовым запретом;
- храните версию инструкции и повторяйте тесты после изменений.
Что такое системный промпт и чем он отличается от обычного запроса
Системный промпт — это верхнеуровневая инструкция для модели. Она описывает не одну сегодняшнюю задачу, а устойчивый способ работы ассистента: что он делает, на каком контексте, по каким правилам и когда должен остановиться.
В интерфейсах и API название может различаться. Anthropic и Google используют термин system prompt или System Instruction. В актуальном API OpenAI постоянные правила приложения могут передаваться как инструкции разработчика с ролью developer; они имеют более высокий приоритет, чем пользовательский запрос. Для бизнеса важнее не название поля, а разделение двух уровней:
| Уровень | Что хранить | Пример |
|---|---|---|
| Системная инструкция | Постоянный контекст, технология работы, ограничения, критерии качества | «Сначала проверь комплектность договора, затем риски, затем подготовь таблицу замечаний» |
| Пользовательский промпт | Объект и цель текущего запуска | «Проверь приложенный договор поставки со стороны покупателя» |
| Рабочие материалы | Договор, шаблон КП, прайс, протокол встречи, таблица | Файлы и данные, относящиеся к конкретной задаче |
Системный промпт не обучает модель заново. Приложение добавляет инструкцию в контекст обращения. Поэтому ассистент «помнит компанию» только тогда, когда сервис сохраняет инструкцию и подставляет её в новые диалоги.
Если нужна инструкция для разовой задачи, системный уровень может быть избыточен. Обычного пользовательского промпта достаточно, чтобы один раз сократить документ или подготовить письмо. Системный промпт полезен, когда процесс повторяется, результат должен соответствовать единым правилам или одним ассистентом пользуются несколько сотрудников.
Почему роль — только один блок системного промпта
Формула «ты опытный юрист» задаёт перспективу и лексику, но не описывает работу. Два юриста могут проверить один договор по разным методикам и выдать несовместимые заключения. Чтобы перенести технологию, нужно зафиксировать последовательность действий и признаки готового результата.
Рабочий системный промпт отвечает минимум на шесть вопросов:
- В какой сфере и для какой компании работает ассистент?
- Какой конечный объект он готовит: таблицу рисков, КП, протокол или расчёт?
- Какие материалы разрешено использовать?
- По какому алгоритму он обрабатывает задачу?
- Какие ограничения и точки человеческого контроля обязательны?
- В каком виде вернуть результат и как проверить его полноту?
Например, технология проверки договора может выглядеть так: определить стороны и предмет, проверить существенные условия, сравнить сроки и суммы между разделами, найти односторонние обязательства, составить реестр рисков, предложить редакции спорных пунктов и отдельно перечислить вопросы, которые должен решить юрист. Это уже процесс, а не роль.
При этом инструкция не делает вывод юридически верным сама по себе. Она помогает не пропустить этап, но финальное заключение остаётся за специалистом. Такое же ограничение действует для финансовых расчётов, кадровых решений и публичных обещаний клиенту.
Где системный промпт полезен в работе
Лучшие кандидаты — повторяемые задачи, для которых в компании уже существует технология, шаблон или чек-лист.
| Ассистент | Постоянная технология | Что меняется в каждом чате | Контроль человека |
|---|---|---|---|
| Проверка договора | Этапы проверки, шкала риска, обязательные реквизиты заключения | Текст договора и позиция стороны | Юрист утверждает риски и формулировки |
| Подготовка КП | Структура предложения, правила работы с фактами, тон бренда | Клиент, интервью, состав решения и цена | Менеджер подтверждает обещания и цифры |
| Протокол встречи | Правила выделения решений, задач и открытых вопросов | Расшифровка конкретной встречи | Участник подтверждает ответственных и сроки |
| Аналитическая записка | Порядок проверки данных, форматы расчётов и выводов | Таблица и управленческий вопрос | Аналитик сверяет расчёты и причинные выводы |
Не стоит превращать в постоянную инструкцию всё подряд. Если процесс ещё меняется после каждого запуска, сначала проведите несколько задач вручную и запишите реальные решения. Быстро меняющиеся факты — прайс, сотрудники и лимиты — лучше получать из отдельного источника.
Как системные промпты оформляют сейчас
Актуальные рекомендации ключевых провайдеров сходятся в одном: длинная инструкция не является целью.
OpenAI рекомендует описывать ожидаемый результат, критерии успеха, ограничения, доступный контекст и правила остановки. Повторяющиеся указания лучше убрать, а изменения — проверять на репрезентативных задачах. Для современных моделей это полезнее, чем подробно диктовать каждый внутренний шаг там, где путь не важен бизнесу.
Anthropic советует писать ясно и прямо, давать контекст, использовать последовательные шаги, если важен порядок, и добавлять релевантные примеры. В сложных инструкциях блоки можно разделять XML-тегами, чтобы модель отличала правила, материалы и входные данные.
Google помещает критичные ограничения, роль и формат результата в System Instruction и рекомендует последовательно структурировать блоки с помощью заголовков или тегов. Для сложного процесса Google также допускает цепочку отдельных промптов, когда результат одного шага становится входом следующего.
Практический вывод: современный системный промпт похож на компактный регламент. Нужны однозначные правила, проверяемый результат и свобода там, где точный путь несущественен.
Из каких блоков собрать системный промпт
Универсальная структура состоит из восьми блоков. Каждый блок должен менять поведение.
Четыре опорных блока превращают описание роли в рабочую технологию: ассистент понимает среду, выполняет процесс и знает границы самостоятельности.
- Назначение и роль. Какую функцию выполняет ассистент и кому помогает.
- Контекст компании. Сфера, сегмент, продукт, аудитория, терминология и позиция компании.
- Ожидаемый результат. Какой рабочий объект должен появиться в конце.
- Разрешённые источники. Какие файлы, базы и справочники можно использовать; можно ли обращаться к интернету.
- Алгоритм. Последовательность обязательных этапов и условия ветвления.
- Ограничения. Что нельзя придумывать, публиковать или делать без согласования.
- Инструменты. Когда использовать поиск, расчёты или генерацию файла — если эти функции доступны в системе.
- Формат и контроль. Структура ответа, критерии проверки и условия остановки.
Контекст компании должен быть достаточно устойчивым. Полезно указать, что компания продаёт, кому, в каком тоне общается и какие термины использует. Не следует вставлять в инструкцию пароли, API-ключи, персональные данные или полный массив корпоративных документов. Системный промпт — не защищённое хранилище секретов.
Универсальный шаблон системного промпта
Ниже — каркас, который можно заполнить под свой процесс:
# Назначение
Ты — ассистент по [процессу] для [команда/роль пользователя].
Твой конечный результат — [проверяемый рабочий объект].
# Контекст компании
Компания работает в [сфера] и обслуживает [сегмент].
Продукт/услуга: [кратко].
Используй терминологию: [термины].
Не утверждай факты о компании, которых нет в предоставленных материалах.
# Входные данные
Используй: [список разрешённых источников].
Если обязательного материала нет, перечисли пробелы и задай вопросы.
# Алгоритм
1. Проверь комплектность входных данных.
2. Выполни [этап 1].
3. Выполни [этап 2].
4. Сверь результат с [критерии].
5. Подготовь [финальный объект].
# Ограничения и согласование
- Не придумывай цифры, сроки, факты и обязательства.
- Помечай допущения явно.
- Остановись перед [рискованное или необратимое действие] и запроси подтверждение.
- При конфликте правил сообщи о конфликте и следуй правилу с более высоким приоритетом.
# Инструменты
Используй [инструмент] только для [условие].
Если инструмент недоступен, не имитируй результат: верни содержимое и сообщи об ограничении.
# Формат ответа
[разделы, таблица, файл, объём].
Перед завершением проверь: [3–5 проверяемых критериев].Шаблон не нужно заполнять максимальным количеством текста. Если правило не влияет на решение, его можно удалить. Если модели нужен точный формат, добавьте один хороший пример результата, а не пять почти одинаковых.
Пример: системный промпт для коммерческого предложения
Допустим, менеджер готовит КП после интервью с клиентом. В компании уже есть технология: сначала подтвердить задачу, затем связать её с решением, отделить факты от гипотез, согласовать состав и только после этого сформировать документ.
Сокращённая системная инструкция может выглядеть так:
Ты помогаешь менеджерам B2B-компании готовить коммерческие предложения.
Контекст: мы внедряем ИИ-инструменты в рабочие процессы компаний. Пишем для руководителей без технической подготовки. Не обещаем экономический эффект без исходных данных и согласованной методики расчёта.
Цель: подготовить согласованный черновик КП, основанный только на интервью, карточке продукта и подтверждённом прайсе.
Алгоритм:
1. Извлеки задачу клиента, текущий процесс, ограничения и критерии решения.
2. Раздели подтверждённые факты, гипотезы и отсутствующие данные.
3. Задай вопросы, без которых нельзя определить состав предложения.
4. Предложи структуру: ситуация, решение, границы, этапы, роли сторон, цена, следующий шаг.
5. Остановись и дождись согласования структуры и состава.
6. После согласования подготовь полный текст и проверь все цифры по прайсу.
7. Если доступна генерация файлов, предложи сформировать DOCX. Создавай файл только после явного подтверждения пользователя.
Ограничения: не придумывай кейсы, сроки, скидки, интеграции и юридические обязательства. Любую неподтверждённую выгоду обозначай как гипотезу.
Формат: сначала краткое резюме и список пробелов; после согласования — готовое КП и таблица проверки фактов.Здесь роль занимает одну строку. Основная ценность находится в технологии: источниках, разделении фактов и гипотез, точке согласования и проверке цифр.
Для договора логика будет другой: сторона и тип документа, комплектность, существенные условия, противоречия, риски и только потом редакции. Алгоритм должен принадлежать владельцу процесса.
Как связать системный промпт с функциями и файлами
Инструкция может сказать модели, когда вызвать функцию, но не может добавить саму функцию. Чтобы ассистент создал DOCX, Excel или запись в CRM, приложение должно предоставить соответствующий инструмент и разрешить его вызов.
Поэтому фраза «в конце сформируй Excel» даст разные результаты:
- текстовый чат вернёт таблицу в сообщении;
- интерфейс с генерацией файлов сможет создать XLSX;
- агент с доступом к CRM подготовит изменение, но право записи задаётся отдельно.
Если интерфейс умеет формировать документы и таблицы, в системном промпте уместно прописать: какой файл создать, после какого согласования, из каких данных и какие проверки провести перед выдачей. Ограничения контекста, разбиение файлов и контроль результата разобраны в гайде по ИИ для документов и таблиц.
Хорошее правило инструмента содержит четыре части: условие вызова, необходимые входные данные, ожидаемый результат и границу подтверждения. Например: «После согласования структуры и цены предложи сформировать DOCX; не создавай финальный файл до явного “подтверждаю”; перед выдачей проверь заголовки, суммы и отсутствие внутренних комментариев».
Чем системный промпт отличается от агентного скилла
Системный промпт и скилл могут описывать одну рабочую технологию, но находятся на разных уровнях.
| Критерий | Системный промпт | Агентный скилл |
|---|---|---|
| Где работает | В чат-модели или приложении, которое поддерживает системные/developer-инструкции | В совместимой агентной среде с механизмом обнаружения и активации навыков |
| Что содержит | Постоянный текстовый контекст и правила поведения | SKILL.md, а при необходимости скрипты, справочники, шаблоны и другие ресурсы |
| Когда загружается | Обычно добавляется к каждому запросу или диалогу | Подключается агентом, когда задача соответствует описанию навыка |
| Может ли выполнять код | Нет, если приложение отдельно не дало инструмент | Может включать скрипты, но только если среда разрешает их запуск |
| Лучший сценарий | Один устойчивый ассистент: договоры, КП, протоколы | Переносимый специализированный процесс с файлами, проверками и инструментами |
Согласно открытой спецификации Agent Skills, скилл — это папка как минимум с файлом SKILL.md; дополнительно в неё можно положить скрипты, справочные материалы и шаблоны. Агент сначала видит название и описание навыка, а полную инструкцию загружает по необходимости.
Иными словами, системный промпт — постоянная операционная политика конкретного ассистента. Скилл — подключаемый пакет процедурных знаний для агента. Начинать часто разумно с системного промпта: если процесс требует исполняемого кода, большого набора шаблонов или повторного использования в разных агентных задачах, его можно вынести в скилл. Границы самостоятельности и контроля для таких сценариев подробнее описаны в гайде по ИИ-агентам для бизнеса.
Как переносить контекст между чатами
В системный промпт стоит вынести только тот контекст, который нужен почти всегда: сферу, целевую аудиторию, позиционирование, терминологию, общие ограничения и источники по умолчанию. Данные конкретного клиента, текущий прайс и содержание договора должны приходить в пользовательском запросе или из подключённого источника.
Перенос между чатами обеспечивает продукт: сохранённый ассистент, рабочее пространство, API-приложение или корпоративная настройка. Например, OpenAI отдельно указывает, что при продолжении работы через Responses API прежнее поле instructions не переносится автоматически вместе с previous_response_id. Разработчик должен снова передать нужную инструкцию. Это хороший принцип и для интерфейсных решений: проверяйте не обещание «постоянного контекста», а фактический механизм подстановки.
У системного промпта должны быть версия и владелец. При изменении продукта, регламента или источника инструкция обновляется централизованно.
Как тестировать системный промпт и какие ошибки встречаются
Не оценивайте системный промпт по длине или убедительному тону. Подготовьте небольшой набор тестов и после каждой существенной правки запускайте их на той же модели и одинаковых настройках.
Базовый регрессионный набор включает как минимум такие типы сценариев:
- Обычная задача с полными данными.
- Задача с пропущенным обязательным материалом.
- Данные с противоречием, например разные суммы в приложении и тексте договора.
- Пользовательская просьба нарушить постоянное правило: придумать кейс, пропустить согласование или раскрыть закрытые данные.
Для каждого теста заранее запишите ожидаемое поведение. Например: «ассистент должен остановиться и запросить прайс», «должен показать обе суммы и не выбирать одну сам», «не должен создавать финальный файл до подтверждения».
| Ошибка | Что происходит | Как исправить |
|---|---|---|
| Только роль без результата | Ответ звучит профессионально, но процесс нестабилен | Добавить объект, алгоритм и критерии готовности |
| Повторы и множество абсолютных требований | Правила конфликтуют, инструкция разрастается | Оставить каждое правило один раз и расставить приоритеты |
| Слишком жёсткий пошаговый сценарий | Модель механически выполняет лишние шаги даже в простом случае | Фиксировать обязательные контрольные точки, а не каждый мыслительный ход |
| Инструмент описан как существующий | Ассистент имитирует файл или действие | Указать проверку доступности и запасной текстовый результат |
| Нет тестов и версии | Ошибка обнаруживается уже на клиентском документе | Вести версию, владельца и регрессионный набор примеров |
Если новый блок не исправляет наблюдаемую ошибку и не отражает обязательное правило бизнеса, вероятно, он не нужен. Современные модели лучше работают с коротким непротиворечивым контрактом, чем с архивом всех формулировок, которые когда-либо помогали.
FAQ
Системный промпт видит пользователь?
Это зависит от интерфейса. В API его обычно задаёт разработчик приложения, а пользователь отправляет отдельные сообщения. В корпоративном конструкторе администратор может дать сотрудникам доступ к редактированию инструкции. Не считайте системный промпт надёжным местом для секретов независимо от видимости поля.
Может ли пользовательский запрос отменить системное правило?
В архитектуре чатов системные или developer-инструкции имеют более высокий приоритет, чем пользовательский ввод. Но модель всё равно нужно тестировать на конфликтах и попытках внедрить инструкции через документы. Критичные права доступа должны обеспечиваться приложением, а не только текстом промпта.
Какой длины должен быть системный промпт?
Минимальной, достаточной для устойчивого результата. Для простого ассистента хватит нескольких блоков. Для сложного процесса инструкция может быть большой, но каждое правило должно менять поведение и проходить тесты. Если нужны объёмные справочники и шаблоны, храните их отдельно.
Нужно ли описывать алгоритм всегда?
Нет. Алгоритм нужен, когда порядок отражает технологию бизнеса или снижает риск ошибки. Если важен только результат, лучше задать критерии успеха и дать современной модели выбрать путь.
Когда превращать системный промпт в скилл?
Когда процесс должен подключаться к разным задачам агента, использовать набор файлов, шаблонов или скриптов и загружаться по необходимости. Для постоянного помощника в обычном чате системной инструкции часто достаточно.
Вывод
Начните с одного повторяемого процесса, где у компании уже есть понятная технология. Запишите конечный объект, источники, обязательные этапы, ограничения и точку человеческого контроля. Затем проверьте системный промпт на обычном, неполном, противоречивом и конфликтном входе и только после этого передавайте его команде.
Если в процессе нужен DOCX или Excel, добавьте генерацию файла как последний шаг после проверки содержания и явного согласования пользователя. Для числовых файлов предусмотрите отдельную сверку формул, итогов и исходных диапазонов по правилам из гайда по ИИ для анализа данных.
Источники
- OpenAI: Model guidance
- OpenAI API Reference: Chat Completions
- OpenAI API Reference: Create a model response
- Anthropic: Prompting best practices
- Google AI for Developers: Prompt design strategies
- Google: Live API best practices
- Agent Skills: Overview and specification
Документация и адреса источников проверены 15 сентября 2026 года.
Больше материалов по теме — в разделе «Промпты».
