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