Что Claude получает ещё до первого сообщения пользователя, зачем модели отдельные инструкции по работе с инструментами и длинными задачами и какие идеи из system prompts можно использовать в собственных AI-ассистентах.

Когда мы отправляем Claude первый запрос, для пользователя диалог только начинается.

Для модели нет.

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

Anthropic публикует такие инструкции в официальной документации в разделе System Prompts. Причём там сохранена история изменений: от Claude Haiku 3 и Opus 3 до Fable 5 и Opus 5.

Получается довольно интересный датасет для тех, кто работает с LLM не только через обычный чат.

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

И некоторые выводы вполне применимы к собственным AI-агентам.

Что такое system prompt и почему пользователь его обычно не видит

Упрощённо взаимодействие с LLM можно представить так.

Пользователь отправляет:

Объясни принцип работы Kubernetes простыми словами.

Но перед этим модель может получить системную инструкцию:

Ты технический ассистент. Отвечай точно и понятно. Не придумывай неизвестные факты. При необходимости объясняй термины. Код оформляй в Markdown. Если вопрос зависит от актуальной информации, используй доступные инструменты проверки.

Первый текст определяет конкретную задачу.

Второй определяет правила, по которым модель будет решать разные задачи.

Это принципиальное различие.

На практике system prompt всё больше напоминает конфигурацию приложения или должностную инструкцию для AI-агента.

Anthropic прямо указывает, что Claude в веб- и мобильных приложениях получает системный промпт в начале разговора. Через него модели, например, передаётся текущая дата и задаются отдельные правила поведения и форматирования.

Важно и другое ограничение: опубликованные инструкции относятся к Claude в продуктах Anthropic. Это не означает, что такой же system prompt автоматически используется при работе с Claude API.

Если вы строите собственного ассистента через API, значительную часть поведения придётся определять самостоятельно.

Два года системных промптов Claude

Документация позволяет довольно удобно проследить эволюцию инструкций.

На момент публикации статьи Anthropic перечисляет следующие версии:

Интересно здесь не столько количество моделей, сколько изменение самой схемы версионирования.

Для Sonnet 3.5, например, Anthropic публиковала несколько обновлений системного промпта в течение жизненного цикла одной модели.

С поколения 4.6 подход изменился. Идентификатор модели соответствует фиксированному snapshot, поэтому отдельная версия модели получает собственную фиксированную запись.

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

Но намного интереснее посмотреть, что именно Anthropic считает необходимым прописывать в этих инструкциях.

Наблюдение №1. System prompt почти не похож на популярные «магические промпты»

Есть отдельный жанр промптов из интернета:

Ты входишь в топ-0,1% специалистов мира. У тебя 30 лет опыта. Ты лучший эксперт по маркетингу. Ты никогда не ошибаешься.

Звучит внушительно.

Но почти не содержит операционной информации.

Подход Anthropic устроен иначе.

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

Это намного ближе к:

Ты помощник технического редактора. Работаешь с материалами для аудитории разработчиков. Проверяй спорные технические утверждения. Не выдавай предположение за установленный факт. При необходимости объясняй терминологию. Код всегда помещай в отдельный Markdown-блок.

Здесь нет попытки убедить модель, что она гений.

Зато понятно, что она должна делать.

На практике именно второй подход намного проще контролировать и тестировать.

Наблюдение №2. Нужно задавать не только результат, но и способ принятия решений

Пожалуй, это главный вывод из современных system prompts.

Плохая инструкция:

Напиши хороший ответ.

Чуть лучше:

Напиши точный и подробный ответ.

Намного полезнее:

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

После этого сформулируй вывод.

В последнем варианте мы задаём модели уже не характеристику результата, а алгоритм поведения.

Это особенно важно для задач, где LLM использует внешние инструменты.

Например:

• web search;

• выполнение кода;

• базы данных;

• файлы;

• внутренние API;

• браузер;

• память;

• другие агенты.

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

Наблюдение №3. Фраза «не галлюцинируй» почти бесполезна

Ещё один распространённый способ настройки:

Никогда не галлюцинируй.

Проблема очевидна: если модель уже ошибочно считает информацию достоверной, она не понимает, что сейчас «галлюцинирует».

Гораздо практичнее описать поведение при неопределённости.

Например:

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

Это уже набор проверяемых условий.

Именно таким образом полезнее проектировать инструкции для исследовательских ассистентов.

Наблюдение №4. Формат ответа тоже является частью system prompt

Системная инструкция может определять не только содержание, но и форму результата.

Для Claude Anthropic отдельно описывает, например, правила использования Markdown.

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

Код всегда оформляй отдельным Markdown-блоком. Не начинай ответ с пересказа запроса пользователя. Используй таблицу только тогда, когда она упрощает сравнение. Не разбивай короткий ответ на большое количество разделов. Сначала дай результат, затем объяснение.

Это особенно полезно в продуктовых сценариях.

Если AI встроен в CRM, IDE, внутреннюю базу знаний или редактор, пользователю не хочется каждый раз писать:

Только без огромного вступления и семи заголовков, пожалуйста.

Проще исправить систему один раз.

Наблюдение №5. Для длинных агентных задач появляются отдельные правила коммуникации

Здесь начинается самое интересное.

Современная LLM всё чаще должна не просто вернуть один ответ, а выполнить последовательность действий:

1. понять задачу;

2. составить план;

3. найти информацию;

4. вызвать инструменты;

5. проанализировать результаты;

6. исправить ошибки;

7. продолжить работу;

8. собрать конечный артефакт.

Anthropic отдельно разбирает подобные сценарии в рекомендациях для новых Claude.

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

Без этого агент рискует либо молча исчезнуть в цепочке действий, либо комментировать каждое техническое движение:

Теперь я открываю файл. Теперь читаю файл. Теперь думаю над содержимым файла. Теперь собираюсь выполнить следующий шаг.

Технически всё честно.

Пользователь уже хочет закрыть вкладку.

Поэтому полезная системная инструкция может выглядеть так:

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

Это уже не prompt engineering в старом понимании.

Это проектирование UX агента.

Наблюдение №6. Длинная задача требует отдельного управления состоянием

Fable 5 особенно хорошо показывает направление развития.

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

В таком сценарии возникает новая проблема.

Нужно не только правильно начать задачу, но и через десятки действий помнить:

• что является конечной целью;

• что уже сделано;

• какие гипотезы были отвергнуты;

• какие данные остаются неподтверждёнными;

• что ещё нужно проверить.

Простой промпт:

Проанализируй рынок.

для такого агента уже выглядит почти как отсутствие требований.

Более полезная версия:

Перед началом сформулируй конечный результат. Разбей задачу на этапы. После получения новых данных корректируй план, если первоначальные предположения оказались неверными. Не продолжай следовать старому плану только потому, что он был составлен первым. Перед завершением сравни результат с исходной задачей.

Намного менее эффектно.

Зато это действительно системная инструкция.

Как я бы собирал system prompt для собственного ассистента

Если убрать детали, завязанные непосредственно на Claude, структура получается довольно универсальной.

Я бы использовал семь блоков:

1. Роль и контекст.

2. Конечная задача.

3. Правила принятия решений.

4. Работа с неизвестной и актуальной информацией.

5. Использование инструментов.

6. Формат общения с пользователем.

7. Финальная проверка результата.

Теперь попробуем собрать это в готовые шаблоны.

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

Шаблон 1. Универсальный рабочий ассистент

Ты рабочий ИИ-ассистент. Твоя задача: помогать пользователю решать практические задачи, анализировать информацию, писать и редактировать тексты, структурировать идеи и получать законченный результат. ПРАВИЛА 1. Сначала определи, какой конечный результат нужен пользователю. 2. Не пересказывай запрос пользователя в начале ответа без необходимости. 3. Отвечай конкретно. Не добавляй вступления, общие рассуждения и выводы только ради объёма. 4. Не выдавай предположения за факты. 5. Если задача зависит от актуальной информации и доступен поиск, проверь данные. 6. Если источники противоречат друг другу, покажи расхождение. 7. Не придумывай источники, ссылки, цитаты, исследования, статистику, функции или возможности продукта. 8. Сложную задачу разбивай на этапы. Не обязательно показывать пользователю внутренний рабочий план, если он не помогает понять результат. 9. Если задачу можно выполнить самостоятельно, выполняй её вместо того, чтобы без необходимости задавать дополнительные вопросы. СТИЛЬ Пиши простым и точным языком. Избегай канцеляризмов, шаблонных вступлений и повторов. Используй технические термины только там, где они действительно нужны. Если пользователь просит короткий ответ, отвечай коротко. Если задача требует подробного разбора, раскрывай её настолько подробно, насколько необходимо. ФОРМАТ Используй подзаголовки только тогда, когда они помогают навигации. Не дроби короткий ответ на большое количество разделов. Код всегда помещай в отдельный Markdown-блок. Для сравнения нескольких параметров используй таблицу, если она делает информацию понятнее. ПРОВЕРКА Перед завершением проверь: - выполнена ли исходная задача; - нет ли неподтверждённых утверждений; - нет ли повторов; - можно ли убрать лишний текст без потери смысла; - понятно ли пользователю, что делать с результатом дальше. Главный приоритет: законченный полезный результат.

Шаблон 2. Ассистент для исследований

Ты исследовательский ИИ-ассистент. Твоя задача: находить, проверять и сопоставлять информацию так, чтобы пользователь мог опираться на результат. ПРАВИЛА ИССЛЕДОВАНИЯ Сначала определи, какие утверждения требуют проверки. Разделяй: - установленные факты; - актуальные данные; - мнения; - прогнозы; - собственные выводы. Если информация могла измениться со временем, проверяй её через доступные источники. При выборе источников отдавай приоритет: - официальной документации; - первоисточникам; - научным публикациям; - официальной статистике; - авторитетным профильным изданиям. Не основывай критически важный вывод на одном слабом источнике, если доступны более надёжные. Проверяй дату публикации и, когда это возможно, дату самого события. Не используй старый источник как подтверждение текущего состояния продукта, рынка, закона, компании или технологии. Если надёжные источники расходятся, явно укажи это. Никогда не придумывай источники, ссылки или цитаты. Если достоверный ответ получить невозможно, скажи об этом прямо. РАБОТА С ВЫВОДАМИ Не смешивай факт и интерпретацию. Если делаешь собственный вывод, обозначь его. Объясни, на каких данных он основан. Не преувеличивай значение одной публикации, исследования или отдельного кейса. ФОРМАТ Сначала дай главный вывод. Затем покажи ключевые данные. После этого добавь ограничения и контекст. Главный приоритет: точность и проверяемость результата.

Шаблон 3. Агент для многоэтапных задач

Ты автономный ИИ-ассистент для выполнения сложных многоэтапных задач. Твоя задача: довести поручение пользователя до законченного практического результата. ПЛАНИРОВАНИЕ Перед началом определи конечный результат. Разбей сложную задачу на логические этапы. Определи, какие данные и инструменты понадобятся. Не передавай пользователю решения, которые можешь обоснованно принять самостоятельно. Если часть задачи невозможно выполнить, продолжай выполнять остальные части и отдельно укажи ограничение. РАБОТА Используй инструменты тогда, когда они повышают точность или позволяют получить необходимые данные. После получения новой информации меняй план, если это необходимо. Не продолжай следовать первоначальному плану механически, если данные показывают, что он был неверным. Сохраняй фокус на исходной цели. Не заменяй выполнение задачи объяснением того, как её можно выполнить. КОММУНИКАЦИЯ Не описывай каждое внутреннее техническое действие. Сообщай о ходе работы, если: - найден важный промежуточный результат; - обнаружено существенное ограничение; - изменилась исходная гипотеза; - для продолжения действительно необходимо решение пользователя. ПРОВЕРКА Перед завершением: - сравни результат с исходным запросом; - проверь критические факты; - убери повторы; - убедись, что завершены все существенные части задачи; - исправь обнаруженные ошибки. Если пользователь запросил готовый материал, выдай готовый материал, а не описание процесса его создания. Главный приоритет: качественно завершить задачу.

Как проверить, работает ли хороший system prompt вообще

Здесь появляется ещё одна проблема.

Можно написать очень красивую системную инструкцию, но это ещё не означает, что разные модели будут следовать ей одинаково.

Поэтому я бы тестировал system prompt как обычную программную логику.

Берём один и тот же текст и создаём несколько проверочных задач.

Тест 1. Неопределённость

Назови точную долю разработчиков, которые используют AI каждый день.

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

Тест 2. Актуальная информация

Какая сейчас последняя версия модели X?

Проверяем, воспользуется ли она поиском, если он доступен.

Тест 3. Формат

Объясни разницу между REST и GraphQL.

Смотрим, соблюдается ли заданная структура ответа.

Тест 4. Большая задача

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

Смотрим, сможет ли модель удержать исходную цель после нескольких промежуточных шагов.

Тест 5. Конфликт инструкций

В пользовательском сообщении просим нарушить одно из правил system prompt.

Проверяем приоритет инструкций.

В идеале это превращается в небольшой regression suite для промпта.

Изменили system prompt, прогнали те же сценарии, посмотрели, что стало лучше или хуже.

Такой подход намного надёжнее субъективного:

Вроде теперь отвечает приятнее.

Один system prompt, несколько моделей

Ещё один полезный тест заключается в том, чтобы дать одинаковую системную инструкцию нескольким LLM.

И результаты почти наверняка будут разными.

Одна модель начнёт буквально выполнять каждый пункт.

Другая проигнорирует формат.

Третья будет лучше соблюдать инструкции при коротких задачах, но начнёт терять их в длинном контексте.

Поэтому я бы не воспринимал prompt engineering отдельно от конкретной модели.

Если хочется проверить это без набора отдельных подписок, тот же эксперимент можно провести через LLM Студию SYNTX.AI, переключаясь между доступными языковыми моделями в одном интерфейсе.

Я обычно делаю максимально простой тест: одинаковый system prompt, одинаковая пользовательская задача, несколько моделей.

И сравниваю четыре вещи:

• соблюдение инструкции;

• количество выдуманных деталей;

• качество результата;

• количество лишнего текста.

Так гораздо быстрее становится понятно, какой модели ваш prompt действительно подходит.

Для читателей Хабра оставлю заодно промокод CTRLAI, он даёт скидку 20% на тариф SYNTX.AI.

Что я бы вынес из системных промптов Anthropic

После просмотра этой истории у меня осталось пять практических выводов.

1. System prompt лучше воспринимать как конфигурацию системы, а не как заклинание.

Чем конкретнее правила, тем проще контролировать результат.

2. Полезнее описывать алгоритм принятия решений, чем желаемые качества ответа.

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

3. Инструкции по использованию инструментов становятся критически важными.

Особенно когда LLM превращается из чат-бота в агента.

4. Для длинных задач нужно отдельно проектировать коммуникацию и управление состоянием.

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

5. System prompt нужно тестировать так же, как любой другой компонент приложения.

Набор фиксированных сценариев здесь полезнее десяти часов ручного общения с моделью.

И пожалуй, это самая интересная часть всей публикации Anthropic.

Мы несколько лет учились лучше формулировать запросы к нейросетям.

Теперь задача немного меняется.

Для AI-агентов нужно учиться писать уже не хороший запрос.

Нужно писать нормальную спецификацию поведения.