Ранее я писал про утечку исходного кода Claude Code — 512 000 строк, KAIROS, упоминания нерелизнутых моделей Opus 4.7 и Sonnet 4.8. Так вот: в актуальной версии Claude Code уже есть Opus 4.7, ровно как и было в утекшем коде. Вместе с ней появился новый уровень /effort — xhigh. Это мы тоже разберём.
В первой части я показал, что умеет Claude Code «из коробки». Типовой сценарий после этого: «понял, установил, пользуюсь». И дальше — тот же потолок, что у всех. Claude работает быстро, но как-то странно: отвечает не то, повторяет одно и то же к концу сессии, просит разрешения на каждый чих, жрёт токены как не в себя.
Это решается настройками. Конкретными. Которые лежат в двух файлах — и до них никто не доходит.
Ниже — десять вещей, которые я настроил за полгода работы с Claude Code. Они сделали разницу между «работает» и «работает как целый отдел». С готовыми конфигами. Копируй, вставляй, меняй под себя.
1. CLAUDE.md на 30 строк вместо 300
CLAUDE.md — это «конституция» проекта. Claude читает его при каждом старте сессии и следует инструкциям. Большинство разработчиков превращают его в свалку: архитектура на 200 строк, правила стиля на 100, потом «а ещё этот API работает странно». К 500-й строке Claude уже не читает — он фоново терпит.
В документации Anthropic указан целевой размер — до 200 строк. На практике я держу корневой файл ещё жёстче: идеально — меньше 60. Есть золотой тест: для каждой строки спроси себя — «если убрать, Claude начнёт ошибаться?». Нет — удаляй.
Работает иерархия из четырёх уровней:
Claude читает CLAUDE.md по дереву директорий. Поэтому нет смысла пихать в проектный CLAUDE.md личные привычки — они уже в глобальном. И не нужно дублировать код-конвенции, которые и так навязывает язык.
Вот обезличенный вариант моего проектного CLAUDE.md с одного voice/agent-проекта. Не красивый пример из документации, а именно тот формат, который нормально переживает десятки сессий подряд.
Почему так лучше? Здесь нет «пиши чистый код» и «будь аккуратен». Зато есть то, что Claude реально не угадает: кто владеет audio lifecycle, где нельзя хранить ключи, почему нельзя пересоздавать resampler на каждом чанке, какой командой проверить слой. Это и есть нормальный CLAUDE.md.
Всё остальное — архитектурные паттерны, детали API, конвенции тестов — живёт в .claude/rules/ с path-specific правилами. В каждом файле frontmatter с glob-паттерном — такие правила загружаются только при работе с подходящими файлами. Контекст не засоряется.
Бонус: @-импорт прямо в CLAUDE.md. Пишешь See @README for project overview — Claude подгрузит файл при необходимости. Работают относительные и абсолютные пути, глубина до 5 хопов.
Находка. Раздутый CLAUDE.md хуже, чем его отсутствие. Claude начинает игнорировать реально важные инструкции — они тонут в болтовне. Золотое правило: если убрать строку, Claude начнёт делать ошибки? Нет — удаляй.
2. settings.json: минимальный безопасный конфиг
По умолчанию Claude спрашивает разрешение на каждую bash-команду. Это нормально для первых дней, потом бесит. Решение — .claude/settings.json с явными allow/deny/ask списками.
Главное правило из документации по permissions: deny всегда побеждает allow. Где бы вы ни разрешили команду — если она запрещена где-то, она запрещена. Это значит, что можно разрешить «почти всё» и точечно закрыть опасное.
Я разрешаю дешёвую навигацию и проверки: rg, git diff, компиляцию, тесты. Но всё, что меняет внешний мир — push, deploy, запуск живого приложения, kill/pkill, chmod — уходит в ask или deny. Так Claude не превращается в секретаря по кликам, но и не получает кнопку «разнести прод».
Wildcards работают через пробел — это важно. Bash(ls *) разрешит ls -la, но не lsof — не даст command injection через suffix-совпадение. А вот Bash(ls*) без пробела разрешит и lsof. Проверяйте.
Claude никогда не авто-одобрит запись в защищённые файлы вроде .gitconfig, .bashrc, .zshrc, .mcp.json, .claude.json — это вшитая защита, независимо от allow-списка. Чтение чувствительных файлов закрывайте отдельно через permissions.deny.
3. acceptEdits mode вместо default (Shift+Tab)
В Claude Code есть несколько permission-режимов. Переключение мгновенное — Shift+Tab циклит между default, acceptEdits и plan прямо в сессии.
Главный лайфхак: живите в acceptEdits. Claude пишет, сохраняет, пишет, сохраняет. Вы в это время смотрите diff'ы через git. Когда доходит до git push или bash-команд — всё ещё спрашивает. Экономит десять-пятнадцать часов в месяц, если работаете плотно.
Можно поставить дефолтом в settings.json:
Начинающим не советую — первую неделю сидите в default, привыкайте смотреть, что именно Claude пытается сделать. Потом переключайтесь.
4. Хуки как guardrails: блокировки, автоформат, логи
Хуки — это обработчики, которые Claude Code выполняет автоматически на событиях: перед bash-командой, после Edit, при старте сессии, перед компрессией и далее по lifecycle. Типов сейчас пять: command (shell), http (POST на URL), mcp_tool, prompt (one-shot запрос к модели), agent (субагент).
Самое полезное — PreToolUse и PostToolUse. Только я больше не пишу inline bash-простыни прямо в JSON. Так невозможно нормально дебажить. В settings — маршрутизация, логика — в скриптах.
Мой минимальный набор:
.claude/hooks/block-danger.sh:
.claude/hooks/format-touched.sh:
.claude/hooks/log-command.sh:
Exit code 2 = блокировка. stderr показывается Claude как объяснение отказа. Повторный вызов пойдёт уже по другому пути. async: true не блокирует основной workflow. Лог пишется в фоне — Claude не ждёт.
Эти три файла спасают больше нервов, чем любой «будь осторожен» в CLAUDE.md. Инструкция просит. Хук запрещает.
5. «Совещание ботиков»: Codex + Gemini как второе мнение
Про этот приём я кратко упоминал в первой части. Вот детали и готовый скрипт.
Claude застрял. Сделал три итерации, не понимает проблему, сейчас пойдёт в четвёртый круг ада. Вместо того чтобы снова объяснять — зову внешние модели. GPT-4 через OpenAI Codex CLI и Gemini через Google Gemini CLI. Обе видели другие куски кода и натренированы по-другому. У них может быть другой взгляд.
Важно: это не источник истины, а источник идей. Финальное решение — за Claude и за мной. Две другие модели иногда лажают не меньше. Но одна из трёх часто видит то, чего не видят остальные.
Делается через custom slash-команду. Создаём файл .claude/commands/council.md:
И сам скрипт .claude/commands/council.sh:
Использование в сессии: /council find why the WebSocket handler crashes every 30 seconds. Claude запускает скрипт, получает два мнения, синтезирует.
Второй юзкейс — fallback для WebFetch. Claude Code иногда упирается в auth или robots.txt. Тогда:
Gemini дёргает URL своим парсером, отдаёт текст. У меня это регулярно спасало, когда WebFetch упирался в auth, robots.txt или странную вёрстку документации.
Находка. Одна модель задаёт вопрос, сама же на него отвечает. Другая получает ответ и начинает новую серию рассуждений. В итоге получаются варианты, до которых ни одна из трёх в одиночку бы не дошла. Это работает как brainstorm, а не как ensemble.
6. /effort xhigh, max и adaptive reasoning
/effort — это ручка глубины мышления. Чем выше уровень, тем больше Claude готов думать над сложной задачей и тем дороже может стать сессия. Важно: max реально существует, но это не режим «поставил и забыл». Это аварийная передача, когда задача дорогая, а ошибка ещё дороже.
Сейчас шкала зависит от модели. На Opus 4.7 доступны low, medium, high, xhigh, max. На Opus 4.6 и Sonnet 4.6 нет xhigh — там остаются low, medium, high, max. Если поставить уровень, которого модель не поддерживает, Claude откатится к ближайшему ниже. Например, xhigh на Opus 4.6 станет high.
Поэтому читать эту настройку лучше не как таблицу точных токен-бюджетов, а как режим поведения. xhigh — нормальный дефолт для Opus 4.7. max — разовый форсаж без жёсткого ограничителя по расходу, поэтому глобально я бы его не ставил.
Моё практическое правило: low/medium для короткой рутины, high для обычного серьёзного кодинга, xhigh для Opus 4.7 на архитектуре и сложном дебаге, max — только разово, когда реально упёрся.
Для постоянной настройки сейчас правильная ручка — CLAUDE_CODE_EFFORT_LEVEL или effortLevel в settings:
MAX_THINKING_TOKENS — старая история для fixed thinking budget. По документации, Opus 4.7 всегда использует adaptive reasoning, и fixed-budget режим к нему не применяется. На Opus 4.6 и Sonnet 4.6 можно вернуть старый fixed-budget режим через CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1, и уже там ограничивать MAX_THINKING_TOKENS. Для обычной работы я бы это не трогал.
Соотношение стоимости моделей я показывал в первой части, но повторю — это важно. Если вы делаете ls и grep на Opus с высоким effort — вы платите за мышление там, где нужна просто навигация по файлам. Деньги улетают не драматично за один вызов, а тупо капают весь день.
7. Context Rot: почему Claude тупеет к середине сессии
Это не субъективное ощущение. Исследование Stanford «Lost in the Middle» зафиксировало падение производительности на 15–47% при длинном контексте. Даже на моделях с 1M окном — длина контекста сама по себе вредит reasoning. Явление называется context rot.
Симптомы, которые многие списывают на «ну, AI же»:
- Claude повторяет работу, которую уже делал в этой же сессии
- Его решения противоречат тому, что обсуждали двадцать сообщений назад
- Multi-step задача ломается посередине
- Claude задаёт вопрос, на который вы уже отвечали
- Код становится менее точным, хотя промпт не меняется
Проверить заполнение контекста — команда /context. Показывает текущий процент. У меня правило простое: до 50% работайте, на 60–65% делайте ручной /compact, после 75% уже не геройствуйте. Там качество начинает ехать.
Большинство ждут до зоны auto-compaction и получают сжатие низкого качества. Правильно — /compact делать на 60–65% вручную, с направлением:
Так вы контролируете, что остаётся в пересжатом контексте. Auto-compaction решит за вас и может выкинуть важное.
8. Правило двух коррекций: когда /clear, а не /compact
Прямо связанная с предыдущим пунктом штука, но про другое.
Claude сделал что-то не так. Вы объяснили, он исправил, но плохо. Вы объяснили ещё раз, стало хуже. Это — правило двух коррекций: если одну и ту же проблему пришлось объяснять дважды и не помогло, контекст засорён неудачными подходами. /compact это не починит — он сохранит эти же неудачные подходы в сжатом виде.
Но перед /clear я почти всегда делаю ещё один шаг: отправляю проблему на «совещание ботиков» из пункта 5. Codex и Gemini смотрят на тот же контекст под другим углом, и в моих задачах это примерно в 90% случаев даёт гипотезу, после которой /clear уже не нужен. Если и council не помог — тогда да, чистим контекст.
Решение после этого — /clear и новый промпт. С одной принципиальной разницей: новый промпт должен быть лучше первого. Не копия. Добавьте конкретики, примеров, верификации.
Типичный сценарий:
- Prompt: «Implement function X»
- Claude: делает Y
- Вы: «нет, должно быть Z»
- Claude: пытается Z, получается Z-кривое
- Вы: ещё раз объясняете про Z
- Claude: делает W, непонятно откуда
- STOP. Сначала /council. Если не помогло — /clear
- New prompt: «Implement function X. It must do Z. Test case: input A -> output B. Run the test after implementation.»
Разница на шаге 8 — верификация. Claude 4.x стал очень буквальным. Если дать ему способ проверить свою работу (тест, скриншот, validator), он использует этот способ, и результат будет точнее в разы.
Находка. «Дай Claude способ проверить свою работу» — это единственная самая мощная вещь, которую можно сделать в промпте. Важнее любых инструкций по стилю, чем любых примеров. Верификация > уговоры.
9. Sandbox mode: минус 84% permission-промптов
Sandbox — это не режим auto-approve. Это фильтр на уровне ОС, который ограничивает, что Claude физически может сделать — независимо от его намерений. macOS через Seatbelt, Linux через bubblewrap, на WSL2 работает. WSL1 не поддерживается.
Идея простая: если у Claude нет возможности что-то сломать, незачем спрашивать разрешение на каждое действие в этой зоне. По статистике Anthropic, настроенный sandbox снижает permission-промпты на 84%.
С таким конфигом Claude может писать в проектные директории свободно, но физически не залезет в /etc, не прочитает AWS-креды и не дёрнет произвольный домен. Спрашивать разрешение на safe-действия больше не нужно.
Комбинируется с режимом acceptEdits. acceptEdits экономит клики на Edit/Write, sandbox — на всём остальном.
10. .claude/skills/ для lazy-loading инструкций
Финальная настройка — куда девать инструкции, которые не влезли в тощий CLAUDE.md. Для этого у Claude Code есть skills.
Skills — это специализированные инструкции, которые загружаются только при вызове. Лежат в .claude/skills/, каждая в своей папке с файлом SKILL.md. Структура:
SKILL.md сам по себе обычный markdown, но с frontmatter:
Claude видит описания всех skills в начале сессии, но содержимое загружает только когда вы говорите что-то про аудио-дебаг, релиз, публикацию статьи или постмортем. По моим замерам в рабочих проектах это давало экономию до 150 000 токенов за сессию, когда раньше 200+ строк специализированных инструкций лежали прямо в CLAUDE.md.
У меня сейчас в одном проекте 8 skills по 30–50 строк каждый. Если бы это было в CLAUDE.md — файл вырос бы до 400 строк, и Claude перестал бы его нормально читать. Через skills — каждая инструкция загружается только когда нужна.
Что в итоге
Десять настроек, которые я накопил за полгода работы с Claude Code. Большинство делается за пять минут, эффект накапливается — недели экономии в месяц. Суммарно это разница между «Claude помогает писать код» и «Claude закрывает рутину, а я думаю над архитектурой».
Пройдитесь по списку ещё раз. Выберите два-три пункта и внедрите на реальном проекте, не на игрушечном репозитории. После первой большой задачи станет ясно, почему многие из нас говорят: человек стал узким местом разработки.