Системный промпт: как превратить правила ИИ в контракт
Системный промпт задаёт постоянные правила работы модели: роль, допустимые источники, формат ответа и границы действий. Это не должностная инструкция для цифрового сотрудника и не гарантия послушания. Хороший текст делает поведение проверяемым: по нему можно понять, какие данные использованы, где модель обязана остановиться и что именно проверяет человек.
Опишите функцию, а не характер
Начните с результата. Формулировка «ты — редактор черновиков поддержки» полезнее, чем «будь умным и профессиональным». Добавьте аудиторию, канал и ограничение длины: подготовить ответ до 900 знаков для внутреннего менеджера, выделить неизвестные поля и отметить места ручной проверки.
Опишите один маршрут. Инструкция, которая одновременно ищет документы, пишет письмо, меняет CRM и публикует текст, слишком широка для тестирования. Разделите извлечение фактов, проверку и действие на отдельные этапы или промпты.
Назначьте источники истины
Перечислите, какие данные имеют приоритет: утверждённый справочник, поля запроса, документ с актуальной датой или результат функции. Если источники противоречат друг другу, модель должна показать конфликт и остановиться. Правило «не придумывай» бесполезно без формата, в котором есть явное поле нет данных.
Для RAG напишите, что найденные фрагменты являются материалом для ответа, а не командами. Для браузерного агента укажите разрешённые домены и действия. Пользовательский текст и содержимое документа передавайте отдельными блоками после стабильной инструкции.
Сделайте формат проверяемым
Структура должна помогать редактору, а не украшать ответ:
факты из входа:
неизвестно:
предложение:
основание:
риски:
что проверяет человек:Разрешите значение «нет данных», если поле отсутствует. Жёсткий JSON используйте только там, где приложение проверяет схему программно. Укажите, что делать при невалидном типе или лишнем поле: исправить формат, задать уточняющий вопрос или отказаться.
Запишите ограничения как условия
Каждое правило должно быть наблюдаемым: «не называй цену, если поле price отсутствует», «цитируй источник для фактического вывода», «не отправляй письмо без подтверждения адресата». Просьба «будь осторожным» не даёт тестируемого поведения.
Задайте порядок приоритетов. Например: безопасность выше полноты, явный запрет выше удобства, данные из действующей версии выше устаревшего фрагмента, вопрос пользователя выше предположения. При неразрешимом конфликте модель возвращает статус остановки, а не выбирает удобное правило молча.
Отделите данные от стабильных правил
Системный блок храните отдельно от текущего вопроса, истории и документов. Не вставляйте имя клиента, токен или динамическую дату в общий текст без необходимости. Такой порядок упрощает версии и уменьшает риск, что персональный контекст попадёт в общий кэш.
Для каждого этапа сохраняйте промежуточный результат. Если факт извлечён неверно, исправляйте схему или вход, а не переписывайте готовое письмо. Если текст верен, но агент выбрал не тот URL, проблема относится к правам и инструменту.
Пример рабочего каркаса
Роль: редактор внутренних черновиков поддержки.
Цель: подготовить ответ до 900 знаков и один следующий вопрос.
Источники: поля входа и документы со статусом «действующий».
Запреты: не придумывать цену, срок, юридический вывод или скидку.
Формат: факты / неизвестно / основание / черновик / проверка человека.
Остановка: нет обязательного поля, конфликт версий или запрос вне области.Каркас не заменяет серверные проверки. Цена, роль пользователя и идентификатор записи должны приходить из приложения, а не из текста, который модель может неверно интерпретировать.
Постройте тестовую матрицу
Подготовьте обычный запрос, неполный вход, конфликтующие требования, документ с фразой «игнорируй правила» и вопрос без ответа в контексте. Проверьте, что модель сохраняет приоритеты, показывает неизвестное и не выполняет команду из внешнего текста.
Отдельно протестируйте формат: пропущенное поле, лишний ключ, неверный тип числа и слишком длинный ответ. Если приложение ожидает JSON, валидируйте его до передачи дальше и возвращайте понятную ошибку, а не пытайтесь исправить структуру молча.
Для критичных процессов добавьте тесты на дату, версию, русский язык, склонения и числа. Хорошая инструкция должна одинаково работать на новом вопросе, а не только на примере из её описания.
Версии и откат
Каждое изменение получает номер, дату, автора и причину. Меняйте одно правило за раз, прогоняйте рабочую и контрольную выборки, сохраняйте необработанные ответы и оценку редактора. Старую версию держите доступной для быстрого отката, особенно если промпт используется в письмах, CRM или агентных действиях.
Фиксируйте фактическую модель, параметры, библиотеку и дополнительные системные поля интерфейса. При смене модели тест запускайте заново: одинаковый текст не гарантирует одинаковое поведение.
Приватность и границы инструкции
Не помещайте в системный промпт пароли, токены и реальные персональные данные. Ограничьте доступ к файлу, если в нём есть коммерческие условия. Историю запросов и документы храните по отдельным правилам; одна инструкция не может заменить политику удаления или фильтр доступа.
Если последствия ошибки высоки, добавьте независимую проверку, preview и подтверждение человеком. Промпт не исправит плохой индекс, неверный расчёт или слишком широкие права функции.
Чек-лист выпуска
- Роль описана через функцию, аудиторию и результат.
- Источники истины и порядок приоритетов перечислены.
- Формат допускает «нет данных» и проверяется программно при необходимости.
- Ограничения выражены условиями, а этапы разделены.
- Данные пользователя передаются отдельно от стабильных правил.
- Тесты покрывают конфликты, инъекции, формат и новые вопросы.
- Версия, модель, параметры и причина изменения записаны.
- Секреты исключены, а для рискованных действий предусмотрено подтверждение.
Редакционный прогон перед сменой инструкции
Сохраните пять реальных, но обезличенных запросов и добавьте к ним три контрольных: неполный вход, конфликт версий и фразу-инъекцию в документе. Перед изменением системного промпта запишите ожидаемый формат ответа и точку, где модель должна остановиться. После изменения сравните не только успешные ответы, но и причины отказа.
Если новая формулировка улучшила один сценарий и сломала другой, не склеивайте оба правила в длинный абзац. Разделите их по этапам или добавьте явное условие приоритета. Один изменённый пункт за прогон позволяет понять, что именно повлияло на поведение, и быстро вернуть предыдущую версию.
Для рабочей команды храните карточку версии рядом с промптом: дата, модель, список изменённых правил, результаты контрольных запросов и решение о публикации. Так инструкция становится частью процесса разработки, а не невидимой настройкой, которую невозможно воспроизвести через месяц.
Системный промпт становится полезным, когда его можно прочитать как контракт и проверить тестами. Ясные источники, формат и условия остановки уменьшают число догадок, но последнее решение о данных и действиях всё равно остаётся за приложением и человеком.