24 июля 2026, в день выхода Claude Opus 5, инженер Anthropic из команды Claude Code Thariq Shihipar опубликовал пост с неожиданным заявлением. Они удалили больше 80% системного промпта Claude Code для Opus 5 и Fable 5 — и качество на кодинг-оценках не упало. Оно стало лучше.
Главный вывод простой и контринтуитивный: инструкции, написанные для Claude 3 и 4, теперь мешают Claude 5. Модель стала умнее — а правила остались для более слабой версии. Конфликты между правилами, лишние ограничения, примеры вместо схем — всё это тратит reasoning-токены модели не на вашу задачу, а на разрешение внутренних противоречий.
Это не просто апдейт документации. Это новая философия работы с умными моделями.
Официальный пост Anthropic от Thariq Shihipar (Claude Code team): «Мы были over-constraining Claude Code — и это мешало, а не помогало». 6 мифов старого промптинга и 6 новых правил для Claude 5. В статье: что удалить из CLAUDE.md, как писать skills, как работает /doctor, 6-шаговый чеклист аудита.
Ссылки:
- claude.com/blog: The New Rules of Context Engineering — официальный пост Anthropic
- code.claude.com: Skills Documentation — документация по skills
- Simon Willison: интервью с Cat Wu и Thariq Shihipar — детали про /doctor и оговорки
Сначала — для тех, кто не шарит в промптинге
Когда вы пишете Claude в чате, он видит не только ваше сообщение. Он видит целый «пакет» из нескольких слоёв:
- Системный промпт — скрытые инструкции от разработчика (в Claude Code — от Anthropic)
- CLAUDE.md — файл с правилами для вашего конкретного проекта
- Skills — заготовленные инструкции для повторяющихся задач
- Описания инструментов — объяснения для каждого доступного инструмента
- Автоматическая память — то, что Claude запомнил из прошлых разговоров
- Ваш вопрос — только маленькая часть из всего этого
Всё вместе — это контекст. Контекст-инжиниринг — это наука о том, что именно класть в каждый из этих слоёв.
Раньше логика была простая: чем больше инструкций — тем лучше контроль над поведением модели. Для слабых моделей это работало. Для Claude 5 — нет. Умная модель сама умеет читать контекст и делать выводы. Лишние инструкции создают конфликты.
Пример реального конфликта из промпта Claude Code, который существовал:
- Из skills: «оставляй документацию там, где уместно»
- Из системного промпта: «НЕ пиши комментарии»
- Из запроса пользователя: «добавь документацию»
Что делала модель? Тратила reasoning-токены — время и деньги — на то, чтобы разобраться с противоречием, вместо того чтобы просто написать код.
Промпт-инжиниринг vs контекст-инжиниринг — в чём разница
Промпт-инжиниринг — это один вопрос. «Как мне написать этот конкретный запрос чтобы получить хороший ответ?» Одноразово, для одной задачи.
Контекст-инжиниринг — это архитектура. «Что модель будет видеть на тысячах запросов?» Это то, что определяет поведение агента в масштабе.
Когда вы пишете CLAUDE.md или системный промпт — вы занимаетесь контекст-инжинирингом. И правила здесь кардинально изменились с выходом Claude 5.
6 мифов, которые нужно выбросить
Миф 1: «Давай Claude больше правил»
Как было для Claude 3/4:
In code: default to writing no comments. Never write multi-paragraph
docstrings or multi-line comment blocks — one short line max. Don't
create planning, decision, or analysis documents unless the user asks.Жёсткий запрет на комментарии. Максимальная длина — одна строка. Логика: без правила модель лепила комментарии куда попало.
Как стало для Claude 5:
Write code that reads like the surrounding code: match its comment
density, naming, and idiom.Одно предложение вместо абзаца. Почему? Claude 5 умеет читать кодовую базу и адаптироваться. Он видит что в проекте принято, как пишут остальные, и следует этому паттерну. Жёсткое правило превратилось в контекстное суждение.
Что это значит для вас: grep'ните свой CLAUDE.md на слова NEVER, ALWAYS, DO NOT, любые ALL-CAPS запреты. Для каждого спросите: это жёсткое продуктовое/юридическое ограничение — или просто «вкус», который модель уже умеет воспроизводить?
Вкус → удалить. Ограничение → оставить.
Миф 2: «Давай Claude примеры»
Правило номер один старого промпт-инжиниринга: дай few-shot примеры. Покажи модели «вот как надо». Для слабых моделей это было спасением.
Для Claude 5 — это ловушка.
Примеры сужают пространство решений. Модель начинает воспроизводить паттерн примера вместо того чтобы найти оптимальное решение. Thariq пишет: «Модель более изобретательна, чем примеры, которые мы ей даём».
Вместо примеров — дизайн интерфейса.
Допустим, у вас есть инструмент для трекинга задач. Раньше: параграф с примерами вызова. Теперь:
{
"status": {
"type": "enum",
"values": ["pending", "in_progress", "completed"]
},
"constraint": "only one task can be in_progress at a time"
}Схема с enum и одним правилом. Модель читает интерфейс, понимает ограничения и работает в них — без примеров.
Что делать: Замените worked examples на выразительные схемы, enum'ы, validation errors. Если примеры остаются — переносите их в описание инструмента, не в системный промпт.
Миф 3: «Пиши всё сразу в системный промпт»
Старый Claude Code: в системном промпте были детальные инструкции по code review И по верификации PR AND по обработке ошибок. Загружались каждый раз. Нужны были примерно в 20% случаев.
Сейчас: Верификация и code review вынесены в отдельные skills. Claude Code загружает их только когда задача требует верификации.
Это называется progressive disclosure — прогрессивное раскрытие. Не давай всё сразу. Давай столько, сколько нужно прямо сейчас.
Принципы:
- Если в CLAUDE.md есть 200-строчная секция «как мы делаем code review» — вынесите в skill, оставьте однострочный указатель
- Если skill разросся до 600 строк — разбейте на дерево файлов
- Некоторые инструменты используют deferred loading: модель находит их через ToolSearch только когда они нужны
Миф 4: «Повторяй важные правила в нескольких местах»
В старых моделях было замечено: правила в конце контекстного окна иногда выполнялись лучше, чем в начале. Решение — дублировать. Правило в системном промпте И в описании инструмента AND ещё раз в CLAUDE.md.
Claude 5 не нуждается в повторах. Каждая копия правила — потенциальный конфликт. Если версии чуть отличаются (а они всегда чуть отличаются) — модель тратит reasoning на выяснение, какая из них «правильная».
Правило — один раз, в авторитетном месте. Для правил использования инструмента — в описании инструмента. Для правил проекта — в CLAUDE.md. Нигде больше.
Миф 5: «CLAUDE.md — это место для памяти»
В старых версиях Claude Code был хоткей # — нажал, и информация сохранялась в CLAUDE.md. Пользователей поощряли туда всё складывать: важные решения, контекст проекта, что угодно.
Теперь Claude сам управляет памятью. Auto-memory автоматически сохраняет релевантное без ваших указаний.
CLAUDE.md — это не дневник. Это место для hand-curated gotchas: вещей, которые нестандартны, неочевидны и важны. Не для всего подряд.
Уберите из CLAUDE.md инструкции «сохрани это в память». Доверьтесь auto-memory.
Миф 6: «Markdown-описание — достаточная спецификация»
Раньше: написал план в markdown → Claude Code следует.
Теперь Claude 5 обрабатывает более богатые форматы:
- HTML-артефакты — макеты интерфейсов
- Тестовые наборы как спецификации поведения
- Функции из другой кодовой базы как образец
- Рубрики для verifier-агентов
Thariq прямо пишет: «HTML-макет дизайна даст лучший результат, чем описание дизайна или скриншот».
Что делать: Там где можно — специфицируйте через код, тесты, HTML. Markdown-проза — когда другого варианта нет.
Scaffolding vs Non-derivable — главный фильтр
Это ключевая концепция всего гайда. Разделите каждую инструкцию в вашем контексте на два типа.
Scaffolding — удалять
Это всё, что существует потому что модель раньше была слабее:
- Workaround для ошибки, которую Claude 3 делал регулярно
- Жёсткий формат вывода, потому что без него была каша
- Забор, который поставили после плохого ответа год назад
- Правило, продублированное в трёх файлах «на всякий случай»
Если модель теперь умеет делать это правильно сама — инструкция стала балластом.
Тест для каждой инструкции:
- Может ли Claude вывести это, прочитав кодовую базу / проект?
- Будет ли ошибка поймана автоматически — компилятором, тестами, линтером?
Оба «да» → scaffolding → удалять.
Non-derivable — оставлять всегда
Это всё, что модель не может вывести ни из какого контекста:
- Голос — как звучит ваш бренд или команда
- Money rules — минимальные суммы, кто может давать скидки, что требует второй подписи
- Конфиденциальность — какая информация пересекает какие границы
- Sign-off — кто принимает решение и на каком этапе
- Definitions of done — что именно считается готовым результатом
Это не выводится из кода, структуры папок или README. Это нужно говорить явно — и это остаётся.
Лиза: «Вот такие пироги. Я посмотрела на наш CLAUDE.md для VibeCoderz — там было 180 строк. Прогнала тест "scaffolding vs non-derivable", удалила две трети. Агент стал работать предсказуемее. Самое странное — я убрала инструкцию "не пиши длинные описания", и описания стали короче.»
Что конкретно делать с CLAUDE.md
Новая карта того, что куда
| ✅ Оставить в CLAUDE.md | ❌ Удалить из CLAUDE.md |
|---|---|
| Один абзац — что за проект | Структуру папок (Claude читает ls сам) |
| Gotchas — монолитный types-файл, нестандартный деплой | «Пиши чистый код» (встроено в модель) |
| Указатели на skills | Полные процедуры верификации (→ skill) |
| Жёсткие ограничения: compliance, never-touch paths | Конфликтующие запреты на комментарии |
| Неочевидные архитектурные решения | «Это TypeScript-проект» (видно по tsconfig.json) |
| Кто принимает финальные решения | Инструкции для памяти («сохрани это») |
Жёсткое ограничение на размер
Frontier-модели надёжно следуют примерно 150-200 инструкциям. Системный промпт Claude Code занимает ~50 слотов из этого числа.
Каждая строка вашего CLAUDE.md конкурирует с операционными инструкциями. 200-строчный CLAUDE.md — это не 200 инструкций. Это перегрузка, где часть инструкций просто игнорируется.
Что делать со Skills
Thin entry, fat folder. SKILL.md — короткий: имя, описание, указатели. Глубина — в подпапках references/, scripts/.
Почему это важно технически: при 20 установленных skills Claude Code видит name + description каждого (~20-50 токенов). Итого idle overhead — ~1000 токенов, а не 20 × полных тел. При совпадении с задачей — загружает нужный skill полностью.
| ✅ Что кодировать в skills | ❌ Что не нужно |
|---|---|
| Review чеклисты вашей команды | Копию системного промпта Anthropic |
| Domain vocabulary проекта | Правила, которые уже в модели |
| Release rituals | 600-строчный монолит (разбить!) |
| Нестандартные процедуры тестирования | Примеры вместо схем |
Если skill разросся — разбейте. Прогрессивный disclosure внутри skill: пусть модель загружает только нужную секцию.
Инструмент /doctor
Anthropic выпустила claude doctor (команда в терминале) и /doctor (внутри Claude Code).
Что делает:
- Дедуплицирует локальный CLAUDE.md против checked-in версии
- Находит инструкции, которые модель может вывести из кодовой базы
- Предлагает перенос в skills и nested CLAUDE.md
- Флажит конфликтующие правила
- Предлагает конкретные упрощения и удаления
Как использовать:
# В терминале
claude doctor
# Внутри Claude Code
/doctorВажно: не принимайте все предложения вслепую. Если /doctor предлагает удалить compliance-правило — оставьте. Но добавьте комментарий, почему оно здесь и зачем.
После чистки обязательно прогоните несколько реальных задач и сравните поведение.
Бенчмарки: сравнение с GPT-5.6 — один и тот же вывод
Интересный факт: OpenAI сделали те же выводы независимо от Anthropic.
Официальный гайд по GPT-5.6 Sol: leaner system prompts улучшили eval scores на ~10-15%, сократили токены на 41-66%, стоимость на 33-67%.
Два разных AI-лаба. Два разных флагмана. Один и тот же вывод: более умной модели нужно меньше инструкций.
Это не совпадение. Это системное свойство frontier-моделей.
6-шаговый чеклист аудита вашего контекста
Вот конкретный план действий:
Шаг 1 — Conflict pass
Выпишите все абсолютные правила (NEVER, ALWAYS, DO NOT, ALL-CAPS). Найдите дубликаты. Найдите противоречия. Удалите лишние, разрешите конфликты.
Шаг 2 — Obvious pass
Пройдитесь по оставшимся инструкциям. Для каждой: «может ли Claude вывести это, прочитав дерево файлов и код?» Если да — удалить.
Шаг 3 — Skill extraction
Найдите многошаговые процедуры в CLAUDE.md. Вынесите их в отдельные skills. В CLAUDE.md — только указатель в одну строку.
Шаг 4 — Example pass
Найдите все few-shot примеры. Замените на schema + правило в описании инструмента. Если пример остаётся — он в tool description, не в системном промпте.
Шаг 5 — Doctor pass
claude doctorПрочитайте каждое предложение. Принимайте осмысленно. Compliance-правила — оставляйте с комментарием.
Шаг 6 — Eval pass
Прогоните свои реальные задачи. Не ориентируйтесь только на заявление Anthropic «no measurable loss» — это их evals, ваши могут отличаться.
Важные оговорки — честно
Работает только для Opus 5 и Fable 5
Cat Wu из команды Claude Code уточнила: сокращение на 80% применялось только к frontier-моделям. Sonnet 5 и Haiku 4.5 всё ещё используют полный системный промпт — им нужно больше явных инструкций.
Если вы используете Sonnet 5 — применяйте эти принципы осторожно и тестируйте на своих задачах.
«80%» — это частично реструктуризация
Независимый замер (GitHub, phuryn) показал: часть «удалённого» на самом деле перемещена. Memory-блок теперь загружается условно. Verification и code review ушли в навыки. Реальное сокращение поведенческого ядра — около 73-69%, не 80%.
Это не делает принцип неверным. Но точность важна.
«Без потерь» — на их оценках
Anthropic не опубликовала тестовый набор, baseline или детали методологии. «No measurable loss» — внутреннее утверждение, не независимый аудит. Прогоняйте свои задачи.
Hard constraints остаются
В критических областях — деньги, PII, продакшен-деплой — Anthropic рекомендует сохранять overconstraint даже для Claude 5. Это не отменяется.
Быстрый старт — прямо сейчас
Три действия, которые можно сделать за 15 минут:
# 1. Найти все абсолютные запреты
grep -n "NEVER\|ALWAYS\|DO NOT" CLAUDE.md
# 2. Для каждого совпадения задать вопрос:
# Это compliance-ограничение или «вкус»?
# Вкус → удалить. Compliance → оставить с комментарием ПОЧЕМУ.
# 3. Запустить /doctor
claude doctor
# Читать каждое предложение, не принимать вслепую.После этого — запустить пару реальных задач и сравнить поведение агента до/после.
FAQ
Применимо ли это к использованию Claude через веб-интерфейс, а не только через API?
CLAUDE.md и skills — это инструменты Claude Code (desktop app). Для веб-чата на claude.ai эти принципы применимы к системным промптам при построении собственных агентов через API. В обычном чате через claude.ai — промпт-инжиниринг, не контекст-инжиниринг.
Если у меня нет CLAUDE.md — нужно ли что-то делать?
Если только начинаете — создайте минималистичный CLAUDE.md сразу. Одна секция: что за проект. Одна секция: gotchas (нестандартные вещи которые нельзя угадать). Всё остальное — только по мере обнаружения реальных проблем.
Как понять, что я удалил слишком много?
Прогоните eval после каждой итерации чистки. Если качество упало — верните последнее удалённое правило и добавьте комментарий, почему оно нужно.
Можно ли сделать одну большую чистку, а не поэтапно?
Технически можно, но тогда непонятно что именно изменило поведение. Поэтапная чистка с тестами после каждого шага — единственный способ знать, что происходит.
Non-derivable правила одинаковы для всех проектов?
Нет. Для каждой команды и продукта — свои. Если в вашем CLAUDE.md написано «менеджер по продукту принимает финальное решение о features» — это non-derivable специфично для вас. Список выше — примеры категорий, не готовые правила.
Официальный пост Anthropic — claude.com/blog: The New Rules of Context Engineering. Документация по skills — code.claude.com/docs/en/skills. Разбор от Simon Willison — simonwillison.net.
Смотрите страницу Claude на VibeCoderz — там все обновления и гайды по Claude Code.
Вопросы по оптимизации CLAUDE.md и контекст-инжинирингу — к Максиму.
Обновлено: октябрь 2026. Источники: Anthropic Blog, Thariq Shihipar (Anthropic, Claude Code team), Simon Willison, Cat Wu (Claude Code team), независимый замер phuryn (GitHub), AI Weekly, Developers Digest.
