Новые правила контекст-инжиниринга для моделей Claude 5
Перевод статьи Anthropic: как изменился контекст-инжиниринг с приходом Claude 5, почему из системных промптов убрали больше 80% правил и что ставить вместо них.
Я уже писал о том, как правильно промптить новое поколение моделей Claude 5 и как работать с ними итеративно, нащупывая то, что хотите построить.
Но когда вы отправляете сообщение Claude, промпт — лишь малая часть контекста, который он получает. Большая часть собирается из системного промпта, скиллов, файлов CLAUDE.md, памяти и других источников. Это мы и называем контекст-инжинирингом, и он сильно влияет на результат: и в Claude Code, и при сборке собственных агентов.
В отличие от промпта, контекст используется сразу для многих запросов, поэтому он не может быть таким же конкретным. Как собрать эти общие инструкции и подсказки для Claude, если вы заранее не знаете, каким будет запрос пользователя?
Это бывает неожиданно сложно, ведь возможности самого Claude растут. Недавно мы заметили большой скачок в том, как промптим новейшее поколение моделей. Мы убрали больше 80% системного промпта Claude Code для моделей вроде Claude Opus 5 и Claude Fable 5 — без заметной потери качества на наших оценках по коду.
Вот что мы поняли про работу с этим новым классом моделей и как использовать это, чтобы обновить свой контекст-инжиниринг. Мы собрали эти практики в claude doctor: команда /doctor в Claude Code помогает привести в порядок скиллы и файлы CLAUDE.md.
Снимаем с Claude лишние оковы
В целом мы обнаружили, что перегружали Claude Code ограничениями: и через системный промпт, и через CLAUDE.md со скиллами.
Например, читая расшифровки нашего же внутреннего использования Claude Code, мы видели противоречивые сообщения в одном запросе: «оставляй документацию по ситуации» и одновременно «НЕ добавляй комментарии». Системный промпт, скиллы и запрос пользователя конфликтовали друг с другом.
Обычно Claude способен считать намерение пользователя и прийти к верному ответу, но ему приходится тщательнее обдумывать эти пересекающиеся и конфликтующие сигналы, прежде чем решить, что делать.
Когда-то такие ограничения были нужны, чтобы избежать худших сценариев. Теперь мы поняли: многие из них можно удалить и дать модели опереться на окружающий контекст и собственное суждение.
Вдобавок у Claude Code теперь гораздо больше инструментов. Раньше Claude полагался на CLAUDE.md как на источник памяти, информации и подсказок. Теперь есть память, артефакты и скиллы, из которых Claude собирает новые способы загружать и передавать контекст между сессиями.
Было и стало
Накопился ряд прежних практик контекст-инжиниринга, которые превратились в мифы. Вот они.
Было: давать Claude правила. Стало: дать Claude судить самому
Когда мы только выпускали Claude Code, нам нужно было гарантировать, что Claude избежит худших сценариев, например не удалит файлы. Поэтому мы давали особенно жёсткие указания, которые не всегда были верны. Скажем, в системном промпте мы писали:
В коде: по умолчанию не пиши комментарии. Никогда не пиши многострочные docstring или многострочные блоки комментариев, максимум одна короткая строка. Не создавай документы с планами, решениями или анализом, если пользователь не просит, — работай из контекста разговора, а не из промежуточных файлов.
Но для части запросов это указание оказывалось неверным. В случае с документацией у пользователя могут быть свои предпочтения, а отдельным кускам очень сложного кода действительно нужны многострочные блоки комментариев.
Без таких ограждений старые модели во многих случаях писали неуместные комментарии, и нам приходилось мириться с этим компромиссом. Но новые модели лучше рассуждают и хорошо справляются с такими решениями без явных правил.
В новом системном промпте мы пишем: пиши код так, чтобы он читался как окружающий код, повторяй его плотность комментариев, именование и идиомы.
Было: давать Claude примеры. Стало: проектировать интерфейсы
Правилом номер один в работе с инструментами было давать Claude примеры их использования. С новейшими моделями мы выяснили, что примеры, наоборот, загоняют модель в узкое пространство поиска.
Вместо примеров думайте о дизайне ваших инструментов, скриптов и файлов: какие параметры есть у Claude и как сделать их выразительнее?
Например, в инструменте Todo простое перечисление статусов (pending, in_progress, completed) уже подсказывает Claude, как им пользоваться. А инструкция держать один пункт в статусе in_progress задаёт нужное нам поведение.
Было: выкладывать всё сразу. Стало: использовать прогрессивное раскрытие
Поскольку Claude Code был заточен под код, наш системный промпт включал подробную информацию о том, как делать ревью и верификацию. Она нужна была не всегда, но когда была нужна, оказывалась критичной.
С тех пор Claude Code хорошо освоил прогрессивное раскрытие: подгружает нужный контекст в нужный момент. Например, мы вынесли верификацию и ревью кода в отдельные скиллы, которые Claude Code вызывает выборочно.
Прогрессивное раскрытие полезно не только для скиллов, мы применяем его и к инструментам. Часть из них загружается отложенно: агент должен сначала найти их полное описание через ToolSearch, прежде чем использовать. Так у нас может быть больше инструментов (например, Task), которые не занимают контекст, пока не понадобятся.
То же самое применимо к вашим CLAUDE.md и Skill.md. Есть распространённый миф, что их надо превращать в центральное хранилище всех возможных практик, иначе Claude их не найдёт. Вместо этого подумайте о дереве файлов, которые подгружаются в нужный момент.
Было: повторяться. Стало: простые описания инструментов
Ранние модели Claude иногда требовали повторных инструкций или охотнее слушали указания в конце контекстного окна, чем в начале. Из-за этого в нашем системном промпте иногда были и упоминания инструментов, и инструкции в их описаниях.
Оказалось, что эти повторы можно удалить, а инструкции о том, как пользоваться инструментом, положить в его описание, а не в системный промпт.
Было: память в файлах CLAUDE.md. Стало: авто-память
Раньше мы советовали сохранять что-то в память Claude через хоткей #, который автоматически дописывал это в CLAUDE.md. Теперь Claude сам сохраняет то, что важно для работы и для вас.
Было: простые спеки. Стало: богатые референсы
В режиме планирования Claude Code сильно опирался на markdown-файлы с планами. Хранение таких файлов помогало Claude обращаться к ним по мере надобности. Похожей практикой было хранить спеки в кодовой базе, чтобы Claude сверялся с ними в долгих проектах.
Но мы выяснили, что Claude справляется со всё более сложными референсами. Вместо простых markdown-файлов он может опираться на HTML-артефакты, созданные новой функцией артефактов.
Референсы можно давать и в виде кода. Спекой может быть подробный набор тестов или функция из другой кодовой базы, которую Claude портирует.
Ещё одна форма референсов — рубрики. Они позволяют Claude сверяться с вашим вкусом в конкретной области (например, как выглядит хороший дизайн API) через динамические процессы и запуск агентов-верификаторов с этими рубриками.
Применяем это к вашему контексту
Соберём всё вместе. Как это выглядит, когда вы собираете свой контекст?
Системный промпт. Он жёстко привязан к продуктовому контексту: сообщает Claude, в каком продукте он работает и что делает. Для Claude Code вы, скорее всего, никогда не будете его менять, но если собираете собственную обвязку для агента, именно здесь стоит потратить много времени.
CLAUDE.md. Держите его лёгким и коротко описывайте, для чего ваш репозиторий, а основной объём тратьте на подводные камни внутри кодовой базы. Например, у вас все типы могут лежать в одном большом файле и нигде больше. Не описывайте «очевидное», что Claude и так увидит по файловой системе или репозиторию. Для деталей используйте прогрессивное раскрытие: если у вас несколько уникальных инструкций по верификации, вынесите их в отдельный скилл и сошлитесь на него из CLAUDE.md.
Скиллы. Думайте о них как о лёгких путеводителях, которые помогают Claude находить информацию по мере надобности. Не делайте их переусложнёнными, кроме особо важных областей. Длинные скиллы старайтесь дробить через прогрессивное раскрытие, делите на много файлов. Лучше всего скиллы работают, когда фиксируют мнения, знания и практики, характерные для вас, вашей команды или продукта.
Референсы. Через @ можно упоминать файлы, чтобы подключить их как референсы: они дают Claude доступ к подробностям текущего плана. Это могут быть спеки, макеты или целые кодовые базы. В целом лучше давать файлы в виде кода: он даёт чёткие, высокоточные инструкции на языке, который Claude отлично знает. Например, HTML-макет дизайна обычно даст лучший результат, чем словесное описание или скриншот.
Пробуйте упрощать
По всему стеку — системный промпт, скиллы, CLAUDE.md — вам, возможно, придётся упрощать, как это сделали мы. Мы выпустили команду claude doctor, которая поможет сделать это автоматически. Больше о промптинге более продвинутых моделей — в нашем гайде по Fable.
Оригинал: The new rules of context engineering for Claude 5 generation models — Thariq, блог Claude. Первоисточник — тред в X.
От меня: работает ли это в Codex и с моделями OpenAI
На мой взгляд — про поколение. Почти всё отсюда переносится на GPT-5.6 Sol и Codex один в один. OpenAI в своих рекомендациях по промптингу пишет то же самое: лёгкие системные промпты поднимают качество и режут расход токенов, абсолютные правила вроде ALWAYS и NEVER стоит оставлять только для настоящих инвариантов, а конфликтующие инструкции моделям класса GPT-5 мешают сильнее, чем нехватка деталей. Совет «давать примеры → проектировать интерфейсы» у них звучит как «убирайте примеры, которые не меняют поведение, и вкладывайте смысл в описания инструментов». А прогрессивное раскрытие — это ровно та двухуровневая схема, к которой я пришёл сам, когда сокращал свой AGENTS.md: короткое ядро плюс тематические файлы, которые подгружаются по необходимости.
Разница в том, что часть пунктов статьи — это фичи именно Claude Code. claude doctor, скиллы, артефакты и авто-память привязаны к экосистеме Anthropic. В Codex у них свои аналоги: CLAUDE.md — это мой AGENTS.md, скиллы — тематические инструкции и SESSION_NOTES, а роль /doctor выполняет ручная процедура миграции с проверочной матрицей. И есть целый слой, которого в этой статье нет вообще: уровни рассуждения, verbosity, программный вызов инструментов, границы автономии. Это уже чисто про настройку GPT-5.6.
Предостережение оставлю тем же, что и всегда: чужая статья, даже хорошая, — источник гипотез, а не разрешение переписывать свой рабочий контур. Я проверял это на своих прогонах, когда сокращал инструкции, и советую проверять у себя оценками, а не принимать на веру.