Системные промпты Claude: где взять и чему учат

Anthropic публикует системные промпты своих потребительских продуктов: веб-версии claude.ai и приложений для iOS и Android, с отдельными наборами для Haiku, Sonnet и Opus. Изменения выходят как примечания к выпускам, то есть видна не только текущая версия, но и история правок. Сразу оговорим главное, чтобы не создавать ложных ожиданий: к API это не относится. Когда вы отправляете запрос через API, системный промпт задаёте вы, и ничего из опубликованного к нему не добавляется. Но прочитать эти тексты стоит по другой причине — это редкая возможность посмотреть, как устроен промпт, который писали профессионально и переписывали десятки раз.

Что именно опубликовано

Разберём состав, потому что путаница здесь стоит неверных выводов.

Чего в публикации нет: промптов, применяемых к обращениям через API. Их и не может быть — в API системная инструкция целиком ваша.

Разница принципиальна для понимания того, почему одна и та же модель ведёт себя по-разному в приложении и через API. Это не разные модели и не разные версии: это одна модель с разными инструкциями на входе. Всё, что вы считали «характером Claude», в значительной степени и есть тот системный промпт.

Чему эти тексты учат

Самое ценное — не содержание, а приёмы. Четыре, которые видны сразу и переносятся на любой промпт.

Правила даются как поведение, а не как запреты. Вместо списка «нельзя» описывается, что делать в конкретной ситуации. Модель хуже выполняет отрицания, чем инструкции о действии, и профессиональный промпт это учитывает.

Конфликты решаются заранее. Хороший системный промпт содержит порядок приоритетов: что важнее, если инструкции противоречат друг другу. Без этого модель выбирает сама, и выбирает непредсказуемо.

Формат описывается явно. Не «отвечай понятно», а конкретно: когда список, когда абзац, когда код. Расплывчатые указания дают расплывчатый результат.

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

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

Почему прозрачность здесь важнее удобства

Небольшое наблюдение о том, зачем компании вообще публиковать такое.

Системный промпт — это описание того, как продукт будет себя вести. Пока он закрыт, пользователь видит поведение, но не видит правил, и любое неожиданное решение модели читается как её собственная воля. Открытый промпт превращает это в проверяемое утверждение: вот что модели велели, вот что она сделала.

Это ложится в общий ряд августовских сюжетов про доверие к ИИ. Глава Anthropic на этой же неделе назвал негативное отношение к ИИ кризисом доверия, а не проблемой коммуникации. Публикация промптов — один из немногих доступных вендору способов это доверие подкрепить чем-то проверяемым.

Что это значит для вашей интеграции

Практическая часть. Технически — ничего не меняется, но три вещи стоит сделать.

Проверьте, не полагаетесь ли вы на поведение из приложения. Если вы тестировали идею в веб-версии Claude, а потом перенесли в API и результат стал хуже — почти наверняка дело не в модели, а в отсутствующем системном промпте. Теперь можно посмотреть, чего именно не хватает.

Не копируйте промпт целиком. Он написан под потребительский продукт с его задачами: длинные диалоги, широкая аудитория, работа без разработчика посередине. Ваш случай другой, и лишние инструкции — это лишние токены в каждом запросе.

Посчитайте, во что промпт обходится. Системная инструкция уходит в модель при каждом обращении. Промпт на тысячу токенов при десяти тысячах запросов в день — это десять миллионов входных токенов в сутки. По текущей ставке Sonnet 5 в каталоге, 30 ₽ за миллион, получается 150 ₽ в день только на повторяющуюся часть. Откуда ещё берутся токены, которых вы не отправляли, разбирали в материале про служебный контекст маршрута.

Как держать промпты в порядке

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

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

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

Ещё хуже — база данных. Кто-то вписал текст через админку год назад, и что там сейчас, не знает никто.

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

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

Второе, что стоит завести вместе с версионированием, — небольшой набор проверочных запросов. Двадцать реальных примеров с ожидаемым поведением, которые прогоняются после каждой правки промпта. Это не полноценные тесты, но они ловят самое обидное: когда правка «на минуту» меняет поведение там, где вы не смотрели.

Что читать в опубликованных промптах в первую очередь

Если решите посмотреть, есть смысл читать не подряд, а выборочно — три места полезнее остальных.

Начало. Первые строки задают роль и рамку. Именно здесь видно, насколько конкретно формулируют профессионалы: не «ты полезный ассистент», а описание того, что модель делает и чего не делает.

Работа с неопределённостью. Как модели велено вести себя, когда данных не хватает или вопрос двусмысленный. Это самое сложное место в любом промпте, и большинство самодельных инструкций его просто не покрывают.

Отличия между наборами для разных моделей. Промпты для Haiku, Sonnet и Opus не совпадают, и разница показывает, что более слабой модели нужно объяснять подробнее. Полезный вывод: промпт, отлаженный на флагмане, не переносится на дешёвую модель без правок — а именно так его обычно и переносят, когда пытаются сэкономить.

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

Чего мы не утверждаем

Не проверяли полноту публикации. Опубликованное — то, что Anthropic решила опубликовать; убедиться, что это весь текст целиком, со стороны невозможно.

Не разбираем содержание построчно. Промпты — тексты Anthropic, мы описываем приёмы, а не воспроизводим формулировки.

Не утверждаем, что API-поведение полностью предсказуемо. Системный промпт вы задаёте сами, но у моделей остаются свои встроенные особенности. У Fable 5, например, adaptive thinking включён всегда и не отключается, а классификаторы безопасности могут отклонить запрос — и отказ придёт успешным ответом, а не ошибкой. Разбирали это, когда модель появилась в каталоге.

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

Что держать в голове

Anthropic выложила системные промпты своих потребительских продуктов с историей изменений. К API это не относится: там инструкция ваша, и никакие внешние правила к запросу не добавляются.

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

Как мы проверяем факты и почему у каждого стоит источник — на странице о проекте. Восемь моделей Claude по одному ключу, оба протокола открыты: keydealer.ru/login.