Новые правила контекст-инжиниринга для моделей Claude 5
Промпт пользователя — лишь малая часть того, что реально попадает в контекст модели. Основной объём формируется из системного промпта, файлов Skills, CLAUDE.md, памяти и других источников — этот процесс сборки называют context engineering, и именно он во многом определяет качество результата при работе с Claude Code или при создании собственных агентов на базе Claude.
В отличие от точечного промпта, контекст работает «на все случаи» — он применяется ко множеству разных запросов сразу, поэтому не может быть таким же конкретным. Задача усложняется тем, что возможности моделей со временем растут, и то, что было нужно старым моделям, может мешать новым.
Anthropic убрала более 80% системного промпта Claude Code при переходе на новое поколение моделей (Claude Opus 5, Claude Fable 5) — и это не привело к измеримому падению качества на кодовых бенчмарках.
Разбор внутренних логов показал, что старые формулировки часто буквально противоречили друг другу — например, системный промпт мог требовать «оставляй документацию, где уместно», а через пару абзацев — «НЕ добавляй комментарии». Модель в целом справляется с такими противоречиями, опираясь на намерение пользователя, но ей приходится тратить дополнительные усилия на то, чтобы разобраться, чему следовать.
Раньше такие жёсткие ограничения были нужны, чтобы застраховаться от катастрофических сценариев (например, удаления файлов). Теперь часть из них можно убрать, доверившись контексту и суждению модели. Кроме того, у Claude Code появилось гораздо больше инструментов — память, артефакты, скиллы, — которые берут на себя часть функций, раньше закрытых одним CLAUDE.md.
Что изменилось: старые практики против новых
Жёсткие правила → доверие суждению модели
На старте Claude Code в системный промпт закладывали категоричные формулировки — например, требование никогда не писать многострочные комментарии и не создавать промежуточные файлы-планы без явного запроса. Для части запросов это было прямо неверно: пользователь мог хотеть документацию, а сложный участок кода — действительно нуждаться в развёрнутом комментарии.
Раньше без жёсткого правила старые модели ошибались слишком часто, и с этим приходилось мириться. Новые модели справляются с таким выбором самостоятельно, поэтому формулировка стала мягче: писать код, который стилистически сливается с окружающим — по плотности комментариев, неймингу и идиомам.
Примеры использования инструментов → продуманный дизайн самих инструментов
Раньше считалось обязательным давать модели примеры того, как пользоваться тем или иным инструментом. Оказалось, что для новых моделей примеры, наоборот, сужают пространство возможных решений и подталкивают к шаблонному поведению.
Более эффективный путь — вкладываться в дизайн параметров инструмента: например, если статус задачи задан через понятный enum (pending / in_progress / completed) с пояснением про правило «одна задача в работе одновременно», сама структура интерфейса подсказывает модели правильное поведение — без отдельных инструкций.
Всё содержимое в системном промпте → прогрессивное раскрытие
Детальные инструкции по код-ревью и верификации, которые нужны не всегда, но критичны в нужный момент, вынесли из системного промпта в отдельные скиллы, которые Claude вызывает по мере необходимости.
Тот же принцип применили к инструментам: часть из них помечена как «отложенная загрузка» — их полные описания подгружаются через поиск (ToolSearch) только тогда, когда реально нужны, что позволяет держать намного больше инструментов, не раздувая контекст постоянно.
Тот же подход стоит применять и к собственным файлам CLAUDE.md и Skill.md: не стоит превращать их в единый исчерпывающий сборник всех возможных практик — лучше выстроить дерево файлов, которые подгружаются по ситуации.
Повторение инструкций → простые описания инструментов
Более ранние модели были склонны лучше реагировать на инструкции в конце контекстного окна, чем в начале, поэтому упоминания одних и тех же инструментов дублировались — и в системном промпте, и в описании самого инструмента. Для новых моделей такое дублирование избыточно: достаточно один раз чётко описать использование инструмента прямо в его описании.
Память в CLAUDE.md → автоматическая память
Раньше пользователей учили вручную фиксировать важные факты в CLAUDE.md через специальную горячую клавишу. Теперь Claude сам сохраняет релевантные наблюдения о работе и о пользователе в память — без ручного вмешательства.
Простые спецификации → богатые референсы
В режиме планирования раньше опирались в основном на markdown-файлы с планами и текстовые спецификации в кодовой базе. Новые модели способны работать со значительно более сложными формами референсов: HTML-артефактами, созданными через функцию Artifacts, подробными тест-сьютами, кодом из других проектов для портирования, а также «рубриками» — критериями оценки качества (например, что считается хорошим API-дизайном), по которым можно запускать отдельных агентов-верификаторов через динамические workflow.
Как собирать контекст на практике
- Системный промпт сильно привязан к конкретному продукту — определяет, в каком окружении работает модель и что она делает. В самом Claude Code его менять почти никогда не приходится, но если вы строите свой агентский харнесс — именно сюда стоит вкладывать основное внимание.
- CLAUDE.md стоит держать лёгким: коротко описать назначение репозитория, а основной объём — под специфические «подводные камни» проекта (например, нестандартная организация типов в одном файле). Не нужно расписывать очевидные вещи, которые модель и так увидит по структуре файлов. Для деталей — использовать прогрессивное раскрытие: например, вынести правила верификации в отдельный скилл и сослаться на него из CLAUDE.md.
- Skills лучше воспринимать как лёгкие гайды, которые Claude находит по мере надобности, а не исчерпывающие своды правил. Длинные скиллы стоит разбивать на несколько файлов с прогрессивным раскрытием. Лучше всего скиллы работают, когда фиксируют специфичные для команды или продукта мнения, знания и практики.
- Референсы (файлы, подключаемые через @-упоминание) дают модели доступ к развёрнутой информации по текущей задаче — спецификациям, макетам, целым кодовым базам. Предпочтение стоит отдавать файлам в виде кода — они дают модели точные, высокоточные инструкции на языке, который она хорошо понимает: например, HTML-макет дизайна обычно даёт лучший результат, чем текстовое описание того же дизайна или скриншот.
В завершение упоминянем новую команду claude doctor (/doctor в Claude Code), которая помогает автоматически «привести в порядок» и упростить скиллы и CLAUDE.md-файлы — по тем же принципам, которые описаны в статье.
Источник: The new rules of context engineering for Claude 5 models.
