Ранее я писал про утечку исходного кода Claude Code. 512 000 строк, KAIROS, упоминания нерелизнутых моделей Opus 4.7 и Sonnet 4.8. Так вот. В актуальном Claude Code уже есть Opus 4.7. Ровно как и было в leaked-коде. Вместе с ней появился новый уровень /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 проекта. Не красивый пример из документации, а ровно тот формат, который нормально переживает десятки сессий подряд:
# Realtime Voice Agent## Stack- Orchestrator: Elixir/Phoenix, OTP supervisors- Audio engine: Rust, PortAudio, Rubato resampling- Web UI: Flask + vanilla JS- AI: STT -> LLM -> TTS over WebSocket## Commands- Compile all: mix compile- Rust audio: cd native/audio_engine && cargo build --release- Web syntax: .venv/bin/python -m py_compile web/*.py- Run locally: ./run.sh## Architecture- Elixir owns orchestration and process lifecycle- Rust owns capture/playback/resampling, no business logic- Flask only exposes UI and session controls- Never put API keys, model names or devices inline## Gotchas- Log lines may start with "[ISO timestamp] ". Strip before parsing- Streaming resampler must keep state between chunks- For per-phrase TTS, reset resampler per phrase- If audio breaks, add logs at every hop before changing code## Compact InstructionsWhen compacting, preserve: goal, changed files, failing command,current hypothesis, test results, next exact command.
Почему так лучше? Тут нет «пиши чистый код» и «будь аккуратен». Зато есть вещи, которые Claude реально не угадает: кто владеет audio lifecycle, где нельзя хранить ключи, почему нельзя пересоздавать resampler на каждом чанке, какой командой проверить слой. Это и есть нормальный CLAUDE.md.
Всё остальное — архитектурные паттерны, детали API, конвенции тестов — живёт в .claude/rules/ с path-specific правилами. В каждом файле frontmatter с glob-паттерном — такие правила загружаются только когда Claude работает с matching файлами. Контекст не засоряется.
---paths: - "lib/voice/**/*" - "native/audio_engine/**/*" - "web/**/*"---# Audio Pipeline Rules- Do not change STT, LLM and TTS providers in one patch- For latency bugs, log timestamps at capture, STT done, LLM first token, TTS first byte, playback start- If changing WebSocket protocol, update browser parser in the same patch- Never swallow audio engine stderr; surface it in UI logs
Бонус: @-импорт прямо в 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. На каком бы уровне ты ни разрешил команду — если она запрещена где угодно, она запрещена. Это значит что ты можешь разрешить «почти всё» и точечно закрыть опасное.
{ "$schema": "https://json.schemastore.org/claude-code-settings.json", "permissions": { "allow": [ "Bash(git status)", "Bash(git diff *)", "Bash(git log *)", "Bash(rg *)", "Bash(find *)", "Bash(mix compile)", "Bash(cargo build *)", "Bash(cargo test *)", "Bash(.venv/bin/python -m py_compile *)", "Read" ], "ask": [ "Bash(git push *)", "Bash(git commit *)", "Bash(git tag *)", "Bash(./deploy.sh *)", "Bash(./run.sh *)", "Edit", "Write" ], "deny": [ "Bash(curl *)", "Bash(wget *)", "Bash(rm -rf *)", "Bash(git push --force *)", "Bash(git push -f *)", "Bash(sudo *)", "Bash(chmod 777 *)", "Bash(killall *)", "Bash(pkill *)", "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Read(./.ssh/**)", "Read(./data/*.sqlite)", "Read(./data/*.db)" ], "defaultMode": "acceptEdits" }}
Почему так? Я разрешаю дешёвую навигацию и проверки: 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 пишет, сохраняет, Claude пишет, сохраняет. Ты в это время смотришь diff’ы через git. Когда доходит до git push или bash-команды — всё ещё спрашивает. Часов десять-пятнадцать в месяц экономит, если работаешь плотно.
Поставить дефолтом в settings.json:
{ "permissions": { "defaultMode": "acceptEdits" }}
Начинающим отговариваю — в первую неделю сидите в 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 лежит маршрутизация, логика лежит в скриптах.
Мой минимальный набор:
{ "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [{ "type": "command", "command": ".claude/hooks/block-danger.sh" }] } ], "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [{ "type": "command", "command": ".claude/hooks/format-touched.sh" }] }, { "matcher": "Bash", "hooks": [{ "type": "command", "command": ".claude/hooks/log-command.sh", "async": true }] } ] }}
.claude/hooks/block-danger.sh:
#!/usr/bin/env bashset -euo pipefailINPUT="$(cat)"CMD="$(printf '%s' "$INPUT" | jq -r '.tool_input.command // ""')"if printf '%s' "$CMD" | grep -Eq 'rm[[:space:]]+-rf[[:space:]]+/|git[[:space:]]+push[[:space:]]+(-f|--force)|sudo|chmod[[:space:]]+777|DROP[[:space:]]+TABLE|curl.*[|].*sh'; then echo "BLOCKED: dangerous command: $CMD" >&2 exit 2fi
.claude/hooks/format-touched.sh:
#!/usr/bin/env bashset -euo pipefailFILE="$(jq -r '.tool_input.file_path // empty')"[ -z "$FILE" ] && exit 0[ ! -f "$FILE" ] && exit 0case "$FILE" in *.py) ruff format "$FILE" ;; *.ts|*.tsx|*.js|*.jsx) npx prettier --write "$FILE" ;; *.ex|*.exs) mix format "$FILE" ;; *.rs) cargo fmt -- "$FILE" ;;esac
.claude/hooks/log-command.sh:
#!/usr/bin/env bashset -euo pipefailmkdir -p .claude/logsjq -r '[now | todateiso8601, .tool_input.command] | @tsv' >> .claude/logs/commands.tsv
Exit code 2 = блокировка. stderr показывается Claude как объяснение отказа. Повторный вызов пойдёт уже по другому пути. async: true не блокирует основной workflow. Лог пишется в фоне, Claude не ждёт.
Эти три файла спасают больше нервов, чем любой «будь осторожен» в CLAUDE.md. Инструкция просит. Хук запрещает.
5. «Совещание ботиков»: Codex + Gemini как второе мнение
Про этот приём я кратко упомянул в первой части. Вот детали и готовый скрипт.
Claude застрял. Сделал три итерации, не понимает проблему, сейчас уйдёт в четвёртый круг ада. Вместо того чтобы ещё раз объяснять — зову внешние модели. GPT-5.4 через OpenAI Codex CLI и Gemini через Google Gemini CLI. Оба видели другие куски кода и натренированы по-другому. У них может быть другой взгляд.
Важно: это не источник истины, это источник идей. Финальное решение за Claude и за мной. Две другие модели иногда лажают не меньше. Но одна из трёх часто видит что-то, чего не видят остальные.
Делается через custom slash-команду. Создаём файл .claude/commands/council.md:
---description: Ask Codex and Gemini for a second opinionargument-hint: "brief task description"---Run the bot council script with the current task context:!bash .claude/commands/council.sh "$ARGUMENTS"Then read both outputs, compare approaches, and propose the final synthesis.Focus on what each model sees that the others miss.
И сам скрипт .claude/commands/council.sh:
#!/usr/bin/env bashset -euo pipefailQUESTION="$1"CONTEXT_DIR="$(pwd)"RECENT_GIT="$(git log --oneline -5 2>/dev/null || echo 'no git history')"CHANGED_FILES="$(git diff --name-only 2>/dev/null || true)"GIT_STATUS="$(git status --short 2>/dev/null || true)"TMPDIR="${TMPDIR:-/tmp}"OUTDIR="$TMPDIR/council-$(date +%Y%m%d-%H%M%S)"mkdir -p "$OUTDIR"# Prompts in English - external models perform better with EnglishPROMPT="Working directory: $CONTEXT_DIRRecent commits: $RECENT_GITChanged files:$CHANGED_FILESGit status:$GIT_STATUSTask: $QUESTIONGive a second opinion for a senior engineer.Return:1. Most likely root cause2. Files/functions to inspect first3. Concrete fix plan4. One thing Claude may be missingBe direct. No disclaimers. No generic advice."# Run Codex and Gemini in parallelcodex exec "$PROMPT" > "$OUTDIR/codex.out" 2>&1 &CODEX_PID=$!gemini -p "$PROMPT" > "$OUTDIR/gemini.out" 2>&1 &GEMINI_PID=$!wait $CODEX_PID 2>/dev/null || echo "codex failed" > "$OUTDIR/codex.out"wait $GEMINI_PID 2>/dev/null || echo "gemini failed" > "$OUTDIR/gemini.out"echo "===== CODEX (GPT-5.4) ====="cat "$OUTDIR/codex.out"echo ""echo "===== GEMINI ====="cat "$OUTDIR/gemini.out"echo ""echo "===== SAVED TO $OUTDIR ====="echo "===== END OF COUNCIL ====="
Использование в сессии: /council find why the WebSocket handler crashes every 30 seconds. Claude запускает скрипт, получает два мнения, синтезирует.
Второй юзкейс — fallback для WebFetch. Claude Code иногда упирается в auth или robots.txt. Тогда:
gemini -p "Read https://example.com/docs and return the key facts with source-relevant details."
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:
export CLAUDE_CODE_EFFORT_LEVEL=high
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% вручную, с направлением:
/compact preserve the handoff strictly in this format:Goal: one line describing the current task.Changed files: path -> what changed.Decisions: options rejected and why.Current failure: command, full error summary, hypothesis.Verification: commands already run and their results.Next step: one next command or one next file to inspect.Remove: style chatter, failed prompt drafts, generic reasoning.
Так ты контролируешь что остаётся в пересжатом контексте. 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%.
{ "sandbox": { "enabled": true, "filesystem": { "allowWrite": ["./src", "./tests", "/tmp/build"], "denyWrite": ["/etc", "/usr/local/bin", "~/.ssh"], "denyRead": ["~/.aws/credentials", "~/.kube/config"], "allowRead": ["."] }, "network": { "allowedDomains": ["github.com", "*.npmjs.org", "pypi.org"], "allowUnixSockets": ["/var/run/docker.sock"], "allowLocalBinding": true } }}
С таким конфигом Claude может писать в проектные директории свободно, но физически не залезет в /etc, не прочитает AWS-креды и не дёрнет произвольный домен. Спрашивать разрешение на safe-действия больше не нужно.
Комбинируется с acceptEdits режимом. acceptEdits экономит клики на Edit/Write, sandbox экономит на всём остальном.
10. .claude/skills/ для lazy-loading инструкций
Финальная настройка — про то, куда девать инструкции, которые не влезли в тощий CLAUDE.md. Для этого у Claude Code есть skills.
Skills — это специализированные инструкции, которые загружаются только при вызове. Лежат в .claude/skills/, каждая в своей папке с файлом SKILL.md. Структура:
.claude/ CLAUDE.md # 40 строк базовых правил skills/ debug-audio/ SKILL.md # STT -> LLM -> TTS latency/debug release-check/ SKILL.md # Перед релизом: тесты, env, changelog article-publish/ SKILL.md # Хабр/VC.ru/Medium workflow incident-postmortem/ SKILL.md # Разбор падения по логам и git diff
SKILL.md сам по себе обычный markdown, но с frontmatter:
---name: debug-audiodescription: Debug real-time voice latency, dropped chunks or broken playback---# Voice Pipeline Debug PlaybookBefore any fix patch:1. Locate the failing boundary: capture, STT, LLM, TTS, playback.2. Add timestamp logs at the input and output of each stage.3. Do not change more than one provider or protocol per patch.4. If touching resampling, verify streaming state is preserved.5. Finish with a before/after latency table.
Claude видит описание всех skills в начале сессии, но содержимое загружает только когда ты говоришь что-то про аудио-дебаг, релиз, публикацию статьи или постмортем. По моим замерам в рабочих проектах это давало экономию до 150 000 токенов за сессию, когда раньше 200+ строк специализированных инструкций лежали прямо в CLAUDE.md.
У меня сейчас в одном проекте 8 skills по 30-50 строк каждый. Если бы это было в CLAUDE.md — файл бы вырос до 400 строк и Claude перестал бы его нормально читать. Через skills — каждая инструкция загружается только когда нужна.
Что в итоге
Десять настроек, которые я накопил за полгода работы с Claude Code. Большинство делается за пять минут, эффект у меня набирается неделями экономии в месяц. Суммарно это разница между «Claude помогает писать код» и «Claude закрывает рутину, а я думаю над архитектурой».
Пройдись по списку ещё раз. Выбери два-три пункта и внедри на реальном проекте, не на игрушечном репозитории. После первой большой задачи станет видно почему многие из нас говорят что человек стал узким местом разработки.
В третьей части — 10 продвинутых приёмов. Собственные субагенты в
.claude/agents/. Параллельная работа через git worktrees без конфликтов. Claude Code в CI/CD (headless mode, GitHub Actions, Agent SDK). TDD на автопилоте. Техника Ralph — автономный цикл, который построил целый язык программирования за три месяца. И немного про то, куда всё это идёт в 2027.
Источники: Claude Code — часть 1 · Memory Management (CLAUDE.md) · Permissions · Hooks Reference · Skills Documentation · Model Configuration / Effort · Anthropic Sandboxing Engineering · Lost in the Middle (Stanford) · OpenAI Codex CLI · Google Gemini CLI
Об авторе: Кир, CTO и серийный предприниматель. Пишу про AI-инструменты, автоматизацию разработки и реальные интеграции в бизнесе без булшита: @ai_integr
ссылка на оригинал статьи https://habr.com/ru/articles/1028988/