Оптимизация CLAUDE.md под Opus 5: удаление и проверка инструкций

Почему ваши инструкции перестали работать

Недавно Борис Черный, создатель Claude Code, заявил: «Удалите ваш CLAUDE.md, удалите навыки и хуки». Это шокирует, но за этим стоит важная идея: новые модели умнее и не нуждаются в старых подпорках. В этой статье вы узнаете, как проверить свои инструкции и что удалить, чтобы получить выгоду от Opus 5, а не регресс.

Что изменилось в Opus 5

Opus 5 стал умнее, но это создает проблемы для ваших старых инструкций. Три механизма меняют поведение:

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

В результате файл, который работал на 4.x, теперь может мешать. Удаление файла убирает шум, поэтому совет «просто удалите» работает.

Борис прав на 73%

Совет удалять лишнее верен, потому что большая часть ваших инструкций — не инструкции. Анализ 30 000 репозиториев показал: только 27% файла выполняют то, что вы задумали, остальное — каркас. Исследование ETH Zürich подтверждает: описательные разделы не улучшают результат, но добавляют 20% к стоимости. Борис сократил системный промпт Claude Code на 80%, и вам стоит сделать то же самое.

Но будьте осторожны: 89,9% конфигураций содержат инструкции, которые не называют конкретных действий. Такие правила, как «поддерживайте чистоту кода», ничего не связывают в модели.

Удаление — грубый инструмент

Что он не видит

Метод удаления и наблюдения не выявляет скрытые проблемы. Низкая специфичность и конфликты правил не проявляются явно, поэтому вы рискуете вернуть их обратно. Кроме того, хуки — это детерминированные ограничения, которые не должны зависеть от модели. Удаляйте только прозу, а не защитные механизмы.

Стоимость подхода

Повторное обучение на ошибках — дорого. Для обычного разработчика это часы простоя. Статический анализ дешевле и безопаснее.

Как правильно подойти к задаче

Вместо удаления проведите аудит: исправьте ошибки, сделайте инструкции конкретными, проверьте конфликты. Вот что искать:

• Длинные ответы — добавьте инструкции о краткости для каждого типа вывода.
• Выход за рамки задачи — укажите область действия в одной строке.
• Чрезмерное подчинение ограничениям — уберите «будьте консервативны», просите полный отчет.
• Навязчивая самопроверка — удалите «проверьте ответ», модель делает это сама.
• Конфликты правил — найдите и устраните противоречия.
• Неопределенные правила — назовите конкретный объект или ограничьте путь.
• Чрезмерное использование субагентов — ограничьте делегирование.
• Уверенные ошибки — требуйте указывать допущения и проверяйте результат.
• Уровень усилий — настройте параметр effort под Opus 5.

Пишите правила, которые работают

Чем меньше интерпретации, тем лучше. Используйте императивные формулировки и точные термины. Например, «Форматируйте с помощью ruff format перед коммитом» эффективнее, чем «поддерживайте чистоту кода».

# Пример хорошего правила
# Плохо: keep the code clean
# Хорошо: запустите ruff format перед коммитом
# 
# Для проверки конфликтов:
# Найдите пары правил, которые не могут выполняться одновременно

Практический вывод

Не удаляйте файл вслепую. Проведите аудит: найдите размытые и конфликтующие правила, исправьте их. Протестируйте на нескольких задачах. Это займет час, но сэкономит дни. Начните с удаления строк «проверьте ответ» и «будьте консервативны» — они точно вредят на Opus 5.