Когда ты пишешь Claude сообщение, сам текст запроса — это лишь верхушка айсберга. Под водой скрывается системный промпт, файлы CLAUDE.md, подключённые skills, память о прошлых сессиях и другие куски контекста, которые собираются вместе перед тем, как модель вообще увидит твой вопрос. Anthropic называет это «контекстной инженерией» — и именно она сильнее всего влияет на то, каким получится результат в Claude Code или в твоём собственном агенте.
Разница между промптом и контекстом простая: промпт — это конкретная просьба здесь и сейчас, а контекст работает на множестве разных запросов подряд, поэтому не может быть таким же точным. Проблема в том, что правила, которые отлично подходили для одной версии модели, могут внезапно начать мешать следующей. Именно это и произошло с новым поколением моделей Claude — Opus 5 и Fable 5.
Главное открытие: минус 80% системного промпта
Инженеры Anthropic заметили, что для новых моделей потребовалось резко изменить подход к промптингу. Они убрали больше 80% системного промпта Claude Code — и при этом не потеряли ни капли качества на своих же бенчмарках по написанию кода. Иначе говоря: три четверти инструкций, которые казались необходимыми, оказались просто избыточными.
Причина в том, что старая версия Claude Code была буквально перегружена правилами. Когда команда читала логи собственного внутреннего использования инструмента, она видела, как в одном запросе сталкиваются противоречивые указания — например, «оставляй документацию, где это уместно» из одного skill и «НЕ добавляй комментарии» из системного промпта. Claude в целом умеет угадывать, что имел в виду пользователь, но ему приходится тратить лишние «мысли» на то, чтобы разобраться, какое из противоречащих друг другу правил важнее в конкретной ситуации.
Заметка
Anthropic выпустила команду claude doctor (запускается как /doctor в Claude Code) — она автоматически анализирует твои skills и CLAUDE.md и подсказывает, что можно упростить или убрать.
От жёстких правил — к доверию
Раньше в системном промпте буквально было написано: «по умолчанию не пиши комментарии в коде», «никогда не пиши многострочные docstring», «не создавай документы с планами, если пользователь не просил». Эти правила защищали от катастрофических сценариев на слабых моделях — но были неправильными в целом ряде случаев: у пользователя могли быть свои предпочтения по документации, а сложный код иногда действительно нуждается в развёрнутом комментарии.
Для старых моделей это был вынужденный компромисс — без жёстких рамок они слишком часто ошибались. Новые модели справляются с такими решениями сами, без явных правил. Новая формулировка в системном промпте звучит иначе: «пиши код, который читается как окружающий его код: подстраивайся под плотность комментариев, именование и идиомы». Один короткий принцип вместо списка запретов.
От примеров — к дизайну интерфейсов
Долгое время золотым правилом было: если хочешь, чтобы Claude правильно пользовался инструментом, дай ему примеры использования. Оказалось, что для новых моделей примеры работают наоборот — они сужают пространство для собственных решений модели и заставляют её копировать паттерн, даже если ситуация немного другая.
Вместо примеров теперь стоит думать о дизайне самих инструментов, скриптов и файлов: какие параметры доступны Claude и насколько они выразительны? Хороший пример — инструмент Todo в Claude Code. Просто указав, что статус задачи может быть pending, in_progress или completed, разработчики подсказывают модели логику работы без единого примера. А инструкция «держи только один пункт в статусе in_progress» задаёт нужное поведение через структуру, а не через демонстрацию.
От «всё и сразу» — к постепенной загрузке
Раньше системный промпт Claude Code включал подробные инструкции о том, как делать code review и верификацию — эта информация не всегда была нужна, но когда была нужна, оказывалась критичной. Проблема в том, что она занимала контекст в каждом запросе, даже когда речь шла о простой правке одной строки.
Новые модели гораздо лучше справляются с «progressive disclosure» — постепенной подгрузкой нужного контекста именно тогда, когда он требуется. Верификацию и код-ревью в Claude Code перенесли в отдельные skills, которые модель подключает по необходимости. То же самое применили и к инструментам: часть из них теперь помечена как «отложенная загрузка» — агент должен сначала найти их полное описание через поиск инструментов (ToolSearch), и только потом использовать. Это позволяет держать намного больше инструментов доступными, не занимая ими контекст заранее.
Тот же принцип применим к твоим собственным CLAUDE.md и файлам skills. Частый миф — что CLAUDE.md должен быть центральным хранилищем абсолютно всех практик, потому что иначе Claude их «не найдёт». На самом деле лучше выстроить дерево файлов, которые подгружаются именно в нужный момент, а не сваливать всё в один длинный файл. Если тебе интересно разобраться с азами такой структуры проекта, у нас есть отдельный гид для старта в Claude Code.
От повторов — к простым описаниям инструментов
Более ранние модели Claude иногда нуждались в повторении инструкций или лучше запоминали то, что было в конце контекстного окна, а не в начале. Из-за этого в системном промпте часто дублировались упоминания одних и тех же инструментов, а инструкции по их использованию повторялись и в системном промпте, и в описании самого инструмента.
Для новых моделей эти повторы оказались лишним весом. Команда убрала дублирующиеся примеры и перенесла инструкции по использованию инструментов туда, где им и положено быть — в описание самого инструмента, а не в общий системный промпт.
Память, спеки и «богатые» референсы
Раньше пользователям советовали сохранять важные заметки в память Claude через горячую клавишу «#», которая дописывала информацию прямо в CLAUDE.md. Сейчас Claude сам автоматически сохраняет то, что относится к работе и к тебе — без ручного вмешательства.
Похожая история со спеками и планами. В режиме планирования Claude Code долгое время опирался на простые markdown-файлы с описанием плана — и это правда помогало возвращаться к плану позже. Но новые модели способны работать со значительно более сложными референсами: HTML-артефактами, тестовыми наборами кода, функциями из другого проекта, которые нужно портировать. Ещё один интересный формат — рубрики (rubrics): они позволяют Claude проверять соответствие результата твоему вкусу в конкретной области — например, что вообще считается хорошим дизайном API — запуская для этого отдельных агентов-верификаторов с этой рубрикой на входе.
Файлы лучше картинок
Если нужно передать Claude референс дизайна, HTML-макет почти всегда даёт результат лучше, чем текстовое описание или скриншот — потому что код это язык, который модель понимает очень хорошо и однозначно.
Как собрать свой контекст с учётом новых правил
Собирая всё вместе, вот из чего должен состоять грамотно выстроенный контекст для агента:
| Элемент | Что это и как с ним работать |
|---|---|
| Системный промпт | Задаёт продукт и роль Claude. В Claude Code его менять не нужно, но если строишь свой агент — сюда стоит вложить основное внимание |
| CLAUDE.md | Держи легким: короткое описание репозитория плюс реальные «подводные камни» кода, а не очевидные вещи, которые видны из файловой структуры |
| Skills | Лёгкие гайды с твоими конкретными знаниями и договорённостями команды — не превращай их в свод жёстких правил |
| References | Файлы, макеты, спеки, куски кода, которые подключаются через @ — предпочитай код тексту и картинкам |
Для системного промпта своего агента полезно вспомнить принцип из поста «Роль и тон: назначь Claude нужного эксперта» — чёткая роль часто важнее длинного списка правил. А если хочешь глубже разобраться с самими skills и тем, как строить проверяемые циклы работы, посмотри материал про циклы верификации в Claude Code.
Для длинных skills тоже стоит применять progressive disclosure — разбивай их на несколько файлов и выноси детали в отдельные разделы, которые подгружаются по запросу, а не читаются целиком при каждом обращении. Если ты только начинаешь разбираться в терминологии вроде CLAUDE.md, skills и системного промпта — весь этот словарь новичка собран в отдельном разборе базовых терминов, который поможет сориентироваться быстрее, чем читать документацию с нуля.
Зачем всё это упрощать самому
Главный вывод простой: если ты писал промпты и инструкции для Claude ещё год-два назад, есть шанс, что часть твоих жёстких правил уже мешает новым моделям, а не помогает им. Команда claude doctor в Claude Code создана именно для такой ревизии — она проходит по твоим skills и CLAUDE.md и подсказывает, что можно сократить.
Если ты пока вообще не пробовал работать с системными промптами и файлами конфигурации Claude Code, бесплатный курс zero2claude — хороший способ на практике увидеть, как выглядит нормальный, не перегруженный контекст, прежде чем усложнять его самому.
Частые вопросы
Что такое контекстная инженерия и чем она отличается от промптинга?
Промпт — это конкретный запрос, который ты пишешь Claude здесь и сейчас. Контекст — это всё остальное, что подгружается вместе с ним: системный промпт, файлы CLAUDE.md, подключённые skills, память о прошлых сессиях. Контекстная инженерия — это работа над тем, как собрать этот общий фон так, чтобы он помогал модели в разных ситуациях, а не только в одной конкретной.
Почему Anthropic убрала 80% системного промпта Claude Code?
Потому что многие жёсткие правила были нужны для более слабых моделей, которые без прямых указаний часто ошибались в спорных ситуациях — например, в вопросе комментариев в коде. Новые модели поколения Claude 5 обладают лучшим суждением и справляются с такими решениями сами, если дать им контекст и свободу, а не набор запретов.
Что такое progressive disclosure на практике?
Это принцип постепенной подгрузки нужной информации только тогда, когда она действительно требуется, а не всегда сразу. Например, инструкции по код-ревью вынесены в отдельный skill, который Claude Code подключает только когда нужна проверка кода, а не держит в контексте каждого запроса.
Нужно ли теперь давать Claude меньше примеров при работе с инструментами?
Да, судя по опыту Anthropic — примеры часто сужают пространство решений модели вместо того, чтобы его расширять. Лучше вложиться в понятный дизайн самого инструмента: ясные параметры, понятные названия статусов и полей, а не набор образцов использования.
Главный урок этой истории для любого, кто пишет промпты, CLAUDE.md или skills: не пытайся предугадать каждую ситуацию жёстким правилом. Дай Claude ясный контекст, хороший дизайн инструментов и доверие — а строгие ограничения оставь только для по-настоящему критичных мест, где ошибка недопустима.
Если хочешь попробовать всё это руками — начни с бесплатного курса «Claude Code и терминал: с 0».
Источник
По мотивам статьи Anthropic «The new rules of context engineering for Claude 5 generation models». Пересказали по-русски для новичков.