Этап 6 — System Prompt как архитектура

System prompt — это не просто «текст сверху», а архитектурный слой поведения.

Темы этапа

• Как писать system prompt
• Инструкции поведения
• Ограничения модели
• Персистентные правила

Что такое system prompt в архитектуре

System prompt задаёт:

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

Это должен быть стабильный контракт, а не хаотичный набор пожеланий.

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

Хорошая структура:

1. Роль и область ответственности.
2. Разрешённые/запрещённые действия.
3. Форматы ответа.
4. Правила безопасности.
5. Поведение при неопределенности.

Персистентные правила

Персистентные правила — это условия, которые действуют всегда:

• не выдавать секреты,
• не выполнять небезопасные операции,
• соблюдать формат.

Они не должны зависеть от конкретной user-задачи.

Ограничения модели

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

• backend-проверки,
• авторизацию,
• валидацию вывода.

System prompt как операционный контракт

System prompt стоит писать как policy-документ, который runtime может косвенно проверять. Он должен определить ответственность, границы и обработку конфликтов до того, как придёт конкретная пользовательская задача. Если system prompt говорит «будь полезным», но не описывает запрещённые действия, модель может выдать небезопасную помощь. Если он говорит «будь кратким», но workflow требует audit evidence, краткость может конфликтовать с compliance.

Полезная модель мышления — иерархия уровней. System rules задают внешнюю границу. Developer instructions задают правила workflow. User messages передают конкретную задачу и данные. Retrieved documents дают доказательства, но не authority. Эту иерархию нужно делать явной, потому что production-ошибки часто возникают из-за того, что весь текст воспринимается как одинаково важный.

Вывод этапа

Сильный system prompt = управляемое поведение на уровне архитектуры, а не «удачный текст».

Объяснение для новичка

Роль в prompt-е нужна не для красоты. Она задаёт, какую ответственность должна взять модель. «Ты помощник» почти ничего не говорит. «Ты technical editor для учебной статьи, объясняешь новичку без жаргона и не пропускаешь определения терминов» задаёт уже полезное поведение. Хорошая роль включает область ответственности, уровень аудитории и критерий качества.

Контекст — это факты, на которых модель должна работать. Это может быть статья, лог ошибки, требования продукта, список полей API. Если контекст не передан, модель достраивает ответ по вероятностям. Если контекст слишком широкий, фокус теряется. Поэтому контекст должен быть отобранным и подписанным: что это за источник, можно ли ему доверять, как его использовать.

Ограничения говорят, что нельзя делать или что обязательно. Например: «не выдумывай API methods», «если данных нет, скажи об этом», «верни только JSON». Ограничения должны быть проверяемыми. Фраза «сделай хорошо» не проверяется, а «верни 5 вопросов, у каждого 4 варианта и один correct=true» проверяется.

Мини-сценарии из практики

• Команда добавляет много правил в system prompt, но поведение всё равно плавает: правила противоречат друг другу.
• Хорошо работает на одном кейсе, но ломается на соседнем: ограничения не описывают границы применения.
• Разные разработчики по-разному интерпретируют «стиль ассистента»: нет операциональных критериев поведения.

Быстрые правила принятия решений

• Пиши системные правила как проверяемые инструкции, а не как общие пожелания.
• У каждого ограничения должна быть цель: качество, безопасность или предсказуемость.
• Регулярно ревизуй system prompt и удаляй устаревшие/конфликтующие правила.

Вопросы для самопроверки

1. Чем хороший system prompt отличается от длинного списка пожеланий?
2. Как выявлять конфликтующие инструкции внутри системных правил?
3. Какие правила должны быть персистентными, а какие — контекстными?