По иерархии такие инструкции имеют более высокий приоритет, чем обычный user prompt. Пользователь может попросить модель нарушить правила, но developer message должен удерживать поведение приложения в заданных рамках.
Developer message удобно воспринимать как "правила функции", а user message - как аргументы этой функции. Разработчик задает, что ассистент умеет и не умеет делать, а пользователь дает конкретную задачу внутри этих границ.
В AI-агентах developer message часто содержит правила: когда вызывать tool, когда просить подтверждение, как ссылаться на источники, что считать рискованным действием, как обрабатывать персональные данные и какой JSON возвращать.
Важно не складывать в developer message все подряд. Если инструкция слишком длинная, противоречивая или меняется на каждом шаге, модель хуже следует правилам. Лучше держать там стабильную логику приложения, а переменный контекст передавать отдельно.
Примеры
- Developer message говорит ассистенту отвечать только на основе базы знаний и явно писать, если источника не хватает.
- Для CRM-агента developer message запрещает создавать сделку без подтверждения пользователя.
- В агенте поддержки developer message задает тон ответа, правила handoff оператору и ограничения по персональным данным.
- В structured output developer message требует возвращать только JSON по заданной схеме без пояснений вокруг.
- Для tool calling developer message описывает, когда можно вызвать API, а когда нужно сначала уточнить данные.
- В safety-сценарии developer message запрещает обходить guardrails даже при прямой просьбе пользователя.
Где используется
- задание правил поведения AI-ассистента
- ограничение пользовательских запросов
- настройка tool calling
- контроль structured output
- guardrails и безопасные отказы
- единый tone of voice продукта
- правила работы с источниками и citations
- управление handoff к человеку
- защита от prompt injection
- стабилизация поведения AI-агента
Связанные термины
Частые вопросы
Developer message и system prompt - это одно и то же?
Они похожи по смыслу, но роли могут отличаться в конкретном API. В современных LLM-приложениях developer message обычно используют для инструкций разработчика приложения, которые важнее user prompt.
Чем developer message отличается от user prompt?
User prompt - это запрос конечного пользователя. Developer message - правила приложения, которые пользователь не должен переопределять обычной просьбой.
Что писать в developer message?
Стабильные правила: роль ассистента, формат ответа, ограничения, правила вызова tools, safety-поведение, источники, подтверждения и действия при нехватке данных.
Что не стоит писать в developer message?
Не стоит помещать туда длинные документы, переменный контекст, историю диалога и временные данные. Для этого лучше использовать RAG, память или отдельный контекст.
Может ли пользователь обойти developer message?
Пользователь может попытаться, но приложение должно проектироваться так, чтобы developer instructions имели приоритет, а опасные запросы блокировались guardrails и проверками.
Как проверять качество developer message?
Через evals: собрать набор сценариев, где пользователь просит нарушить правила, вызывает конфликт инструкций или требует неверный формат, и проверить стабильность поведения.
