Как написать системный промпт: структура и ошибки

Системный промпт — отдельное сообщение с ролью system, которое задаёт модели роль, правила и формат. Пользователь его не видит, а модель учитывает при каждом ответе. Отсюда обе его особенности: он определяет поведение всего диалога и оплачивается при каждом обращении как входные токены. Плохой системный промпт узнаётся по двум признакам — он написан как должностная инструкция и в нём нет ни одного примера. Разбираем структуру, которая работает, ошибки, которые повторяются чаще всего, и цену лишней длины.

Что туда кладут и что не кладут

Начнём с разделения, потому что половина проблем именно здесь.

Кладут: роль и предметную область, правила поведения, формат ответа, границы применимости, тон, примеры хороших ответов.

Не кладут: конкретную задачу пользователя (для неё есть обычное сообщение), данные, которые меняются от запроса к запросу, и секреты.

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

Структура, которая работает

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

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

2. Что делать нельзя. Границы формулируются явно и коротко. «Не обсуждаешь темы вне заказов. Не называешь сроки, которых нет в данных. Не обещаешь скидок».

3. Как отвечать. Формат, длина, тон. «Отвечаешь двумя-тремя предложениями, без списков, обращение на вы».

4. Что делать в неоднозначных случаях. Самый пропускаемый блок и самый полезный. «Если данных для ответа нет — так и говоришь и предлагаешь связаться с оператором. Не догадываешься».

5. Пример. Один-два коротких образца «запрос → ответ». Пример действует сильнее, чем абзац описания: модель хорошо копирует то, что видит.

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

Ошибки, которые повторяются

Шесть штук, отсортированных по тому, как часто встречаются.

Написан как должностная инструкция. Три экрана правил, из которых модель удержит верхнюю часть и нижнюю. Длина не равна точности: после определённого объёма добавление правил начинает вредить.

Только запреты, ни одного примера. «Не пиши длинно, не используй канцелярит, не будь навязчивым» — три отрицания, из которых непонятно, как надо. Один пример хорошего ответа заменяет все три.

Противоречивые требования. «Отвечай подробно» и «отвечай одним предложением» в разных частях текста. Модель выберет одно из двух, и не всегда то же самое.

Задача пользователя внутри системного промпта. Если там написано «переведи текст ниже», то системным он быть перестал. Постоянные правила — в системное сообщение, меняющаяся задача — в пользовательское.

Просьбы вместо ограничений. «Пожалуйста, всегда возвращай корректный JSON» — это надежда, а не гарантия. Формат гарантируется механизмом, а не вежливостью: как получить строгий JSON.

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

Сколько это стоит

Раздел, который меняет отношение к длине.

Системный промпт уходит в модель при каждом обращении. Не один раз в начале диалога, а с каждым запросом заново, вместе со всей историей. Значит лишние пятьсот токенов правил — это пятьсот входных токенов на каждом вызове.

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

Отдельная тонкость: у всех текстовых позиций нашего каталога кэш промптов не поддерживается. То есть скидки за то, что системная часть не меняется, здесь нет — она считается полностью каждый раз. У провайдеров, где кэш есть, экономика другая, и это стоит учитывать при сравнении прайсов.

Практический вывод простой: перечитайте свой системный промпт и вычеркните то, что ни разу не пригодилось. Обычно вычёркивается треть.

Как понять, что промпт плохой

Три проверки, каждая занимает полчаса.

Проверка на человеке. Дайте текст коллеге, не знакомому с задачей, и попросите ответить на пару запросов по этим правилам. Если он переспрашивает — переспрашивать будет и модель, только молча и неправильно.

Проверка на противоречия. Выпишите все требования списком. Дважды перечитайте. Противоречия обнаруживаются именно так, а не при чтении сплошного текста.

Проверка на выбрасывание. Уберите абзац и прогоните двадцать типичных запросов. Если разницы нет — абзац не работал, а деньги стоил.

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

Промпт и выбор модели

Короткое замечание, снимающее лишнюю работу.

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

И наоборот: часть проблем, которые пытаются лечить сменой модели, решается одним примером в системном промпте. Порядок действий разумный такой — сначала пример, потом переписывание, и только потом смена модели, как сравнивать их по делу.

Как промпт меняется со временем

Отдельно о том, что происходит с системным промптом на дистанции, — потому что происходит это со всеми одинаково.

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

Три привычки, которые это лечат.

Датируйте добавления. Комментарий вида «добавлено после случая с возвратами» рядом с правилом позволяет через полгода понять, зачем оно вообще там. Без этого вычёркивать страшно, и текст растёт бесконечно.

Раз в квартал проходите проверкой на выбрасывание. Убрать блок, прогнать выборку, посмотреть на разницу. Работающие правила остаются, остальные уходят.

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

И последнее, что стоит завести сразу: версии. Промпт — это код, влияющий на поведение продукта, и он заслуживает того же обращения. Когда качество ответов вдруг ухудшится, первый вопрос будет «что мы поменяли», и на него должен быть ответ.

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

Чего мы не утверждаем

Не даём готового промпта. Он пишется под задачу, и чужой переносится плохо.

Не обещаем, что промпт удержит модель. Инструкции — не ограничение доступа: то, что модель может сделать, определяется инструментами, которые вы ей дали, а не текстом правил.

Не сравниваем следование инструкциям между моделями. Своих замеров мы не делали.

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

Что держать в голове

Системный промпт — это роль, границы, формат и хотя бы один пример. Пример весит больше, чем абзац описания; запреты без образца работают плохо.

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить свой промпт на нескольких моделях по одному ключу: keydealer.ru/login.