SpyBara
Go Premium

best-practices.md 2026-10-26 22:57 UTC to 2026-10-27 22:59 UTC

This page contains 416 additions and 354 deletions.

2026
Fri 2 22:59 Sun 4 23:58 Tue 6 23:59 Tue 20 23:00 Thu 22 22:58 Fri 23 22:59 Tue 27 22:59 Fri 30 23:01

Лучшие практики для Claude Code

Получайте больше от Claude Code: сообщайте Claude то, чего он не видит, давайте ему проверку для запуска и обеспечивайте соблюдение правил, не допускающих исключений.

Claude Code устроен так, что в большинстве случаев ваш первый простой промпт в новой сессии уже делает то, что нужно, без какой-либо настройки с вашей стороны.

Например:

  • Чтобы команды выполнялись безопасно без вашего подтверждения каждой из них, новые сессии в терминале и VS Code запускаются в авторежиме, где классификатор проверяет всё рискованное перед выполнением.
  • Чтобы ваш основной диалог оставался сфокусированным, пока независимая работа идёт параллельно, Claude делегирует задачи субагентам и обращается к вам только при необходимости.
  • Чтобы длинная сессия продолжалась без вашего управления, диалог автоматически сжимается до того, как заполнится контекстное окно.

На этой странице описано, что делать, когда значений по умолчанию недостаточно. Обычно это происходит, когда у вашего проекта есть знания, правила или ограничения, которые Claude не может увидеть из одного только кода:

  • Процесс деплоя, который существует только в чьей-то голове
  • Файл, который никогда нельзя читать
  • Проверка, которая должна пройти, прежде чем что-либо будет считаться выполненным
  • Бюджет, который нельзя превышать

Никакое значение по умолчанию не может знать этого о вашем проекте, поэтому именно здесь небольшая настройка с вашей стороны окупается.

Когда сессия идёт не так, как вы ожидали, почти всегда причина в одном из следующего:

  • Claude сделал не то, что вы имели в виду, или ему приходится заново выяснять один и тот же факт в начале каждой сессии. Ему не хватает информации, которую нельзя получить из чтения репозитория. См. Сообщите Claude то, чего он не видит.
  • Claude сказал, что закончил, но это было не совсем так, обычно потому, что у него не было способа проверить свою работу. См. Дайте Claude проверку для запуска.
  • Claude сделал то, чего никогда не должно происходить в этом репозитории, или пропустил шаг, который должен выполняться всегда. Один лишь промпт не может гарантировать ни того, ни другого. См. Обеспечьте соблюдение правил без исключений.
  • Claude всё сделал правильно, но это потребовало больше времени, токенов или запросов разрешений, чем стоила задача. См. Измените настройку по умолчанию.

Раздел Позвольте Claude работать без вас применяет те же четыре пункта к запускам без присмотра, а в разделе Что можно перестать делать перечислены советы, которые стали ненужными благодаря современным моделям.

[!NOTE]

Настройка для всей команды описана на отдельной странице: Настройка Claude Code для вашей организации.

Детерминированные и недетерминированные инструкции

Каждая инструкция, которую вы даёте Claude Code, относится к одному из двух видов:

  1. Недетерминированные: вы пишете инструкцию, а Claude (модель) её читает. Это может быть ваш промпт, CLAUDE.md или скилл. Затем модель решает, что делать с этой информацией. Обычно она следует вашим командам, и современные модели хорошо понимают ваше намерение без большого контекста, но нет гарантии, что она выполнит ваши инструкции. Она всё равно может решить чего-то не делать или сделать что-то другое.
  2. Детерминированные: вы настраиваете инструкцию, и Claude Code (среда выполнения) обязан её выполнить. Это может быть хук, правило deny или управляемая настройка. Claude Code применяет это каждый раз, независимо от того, что решила модель.

Большинство возможностей Claude Code существуют в обеих формах:

Недетерминированные (решает Claude) Детерминированные (обеспечивает Claude Code)
Что делать Ваш промпт, CLAUDE.md, скиллы, которые Claude подключает сам Хуки, а также скиллы, которые можете запустить только вы
К чему есть доступ Классификатор авторежима Правила deny, песочница в строгом режиме, управляемые настройки
Когда работа завершена Запрос доказательств, /goal, /code-review Тесты, проверка типов, хук Stop, CI
Сколько тратится Уровень effort, собственный темп Claude --max-turns или --max-budget-usd с -p, установленный вами лимит расходов
За кем последнее слово Сводка Claude о том, что он сделал Защита веток, человек, который одобряет слияние

В большинстве случаев вы хотите, чтобы решал Claude. Почти у каждого правила есть исключения, а современные модели хорошо читают код перед собой и оценивают, подходит ли правило к ситуации. Имея перед собой реальный код, Claude обычно способен принять такое решение лучше, чем правило, написанное вами заранее.

Детерминированный вид нужен, когда вы хотите быть уверены, что определённые вещи всегда происходят (или никогда не происходят), что бы ни решила модель. Это не обязательно что-то драматичное. Авторежим уже блокирует драматичные вещи, вроде деплоя в продакшен или force push поверх чужой работы. Обычно это что-то специфичное для вашего проекта, и оно может быть сколь угодно узким:

  • Никогда не редактировать сгенерированный клиент в src/gen/
  • Всегда запускать скрипт заголовков лицензии после создания файла

Любое из этих правил можно было бы записать строкой в CLAUDE.md или в промпте, и Claude следовал бы ему почти каждый раз. Но как бы настойчиво вы это ни формулировали, выполнит ли Claude эту строку на конкретном ходе, всё равно решает Claude.

[!TIP]

Если вы продолжаете добавлять акценты в строку CLAUDE.md, а Claude всё равно её пропускает, это признак того, что этой строке место в хуке. Верно и обратное: если у вас есть хуки для того, что является лишь предпочтениями, удалите их и позвольте Claude решать.

Сообщите Claude то, чего он не видит

[!TIP]

Записывайте только то, что Claude не может найти, читая репозиторий, или то, на повторное выяснение чего он иначе тратил бы время в каждой сессии.

Claude начинает каждую задачу с чтения вашего кода, и современные модели делают это очень хорошо. Они найдут структуру файлов, ваши соглашения, тестовый фреймворк и то, как устроены существующие компоненты, обычно быстрее, чем вы смогли бы это объяснить. Это значит, что Claude уже знает большую часть того, что вам, возможно, хотелось бы для него записать.

Чего он не может найти, так это информации, которой никогда не было в репозитории:

  • Решение, которое ваша команда приняла на встрече
  • Процесс деплоя, который существует только в голове одного человека
  • Переменная окружения, нужная вашим интеграционным тестам

Есть также информация, которая есть в репозитории, но на её поиск уходит несколько минут, и Claude приходится повторять эти поиски в начале каждой сессии.

Хорошая проверка, прежде чем что-то записывать для Claude:

  1. Может ли он найти это, читая код?
  2. Станет ли он действительно это искать?

Если на оба вопроса ответ «да», не записывайте это.

Пишите конкретный промпт

Конкретный промпт помогает по той же причине: он даёт Claude информацию, которой у него ещё нет. Если вы сразу назовёте файл, опишете симптом и скажете, как выглядит «исправлено», вы обычно избавите себя от лишнего круга исправлений позже.

То же касается предпочтения между двумя разумными подходами: Claude не может вычитать его из кода, поэтому если вам важно, какой из них он выберет, скажите об этом сразу.

Вместо Попробуйте
«исправить баг входа» «пользователи сообщают, что вход не работает после истечения сессии. посмотреть обновление токена в src/auth/, написать падающий тест, который это воспроизводит, затем исправить»
«добавить виджет календаря» «следовать паттерну из HotDogWidget.php и сделать виджет календаря, который позволяет выбрать месяц и листать годы. без новых библиотек»

Если у вас уже есть то, что нужно Claude, передайте это напрямую, а не описывайте:

  • Файл: введите @ и путь, чтобы включить содержимое файла в сообщение.
  • Изображение: вставьте скриншот макета или ошибки в промпт.
  • Вывод команды: передайте его из оболочки через cat error.log | claude -p "what's going on here".

Фразы вроде think step by step или be thorough — это обычный текст промпта, а не ключевые слова. Основной способ управлять тем, насколько усердно думает Claude, — уровень effort, о котором рассказывается в разделе Измените модель и effort. Такие формулировки всё ещё могут слегка подтолкнуть Claude в пределах его настройки effort, но не поднимут его выше неё.

Одна фраза, которая по-прежнему помогает, — be ambitious. Claude склонен понимать запрос консервативно и делать минимум, который его удовлетворяет, поскольку не видит, на какой объём вы рассчитывали. Когда вам нужна более полная версия, с обработанными граничными случаями и естественным продолжением, скажите об этом:

build the settings page from the mockup. be ambitious: empty and error states, the save flow wired up, keyboard navigation, not just the layout

Так вы сообщаете Claude об объёме работы, который знаете только вы, а не о том, насколько усердно думать.

А когда вы исследуете, а не исправляете что-то конкретное, расплывчатый промпт вроде what would you improve in this file? вполне подходит. По ходу дела вам придётся чуть больше поправлять, и это разумный компромисс.

Сначала проведите мозговой штурм с Claude

Когда вы ещё точно не знаете, чего хотите, не обязательно продумывать всё до промпта. Вместо этого попросите Claude взять у вас интервью:

I want to add rate limiting to the public API but haven't thought it through yet. Interview me until you could write the spec, then write it to SPEC.md.

Claude вернётся с вопросами с вариантами ответа о том, что вы ещё не определили: лимиты на пользователя или на ключ, что происходит с запросами сверх лимита, что выходит за рамки задачи. Он продолжает спрашивать, пока ответы не сложатся в спецификацию.

Когда SPEC.md готов, начните новую сессию, чтобы вести реализацию по нему, — так она начнётся с чистого контекста и письменного определения готовности. Это также файл, на который вы позже направите рецензента в разделе Дайте Claude проверку для запуска.

Держите CLAUDE.md коротким

Claude Code загружает CLAUDE.md в каждую сессию, а значит, каждая строка в нём забирает немного внимания Claude в каждой задаче, независимо от того, актуальна она или нет. Поэтому файл работает лучше всего, когда в нём только то, что Claude не смог бы вывести из самого кода:

  • Как проверить работу в этом репозитории: точные команды тестов, проверки типов и линтера, а также как запустить один тестовый файл
  • Места, где код вводит в заблуждение: старый паттерн, который встречается повсюду, но который новый код не должен копировать, или каталог, который выглядит неиспользуемым, но на самом деле используется
  • Решения, которых нет в репозитории: на каком хелпере ошибок остановилась команда, как устроены деплои, что требует ревью миграций
  • Всё, что вам уже дважды пришлось исправлять

CLAUDE.md, прошедший эту проверку, остаётся коротким:

# Commands
- Install: pnpm install
- Run one test file: pnpm vitest run path/to/file.test.ts
- Typecheck: pnpm tsc --noEmit

# Conventions
- Use the error helpers in src/lib/errors.ts, never throw raw strings
- src/legacy/ is still live but don't copy its patterns into new code

# Gotchas
- Integration tests need DATABASE_URL set, see .env.example

В сессии запустите /context, чтобы убедиться, что Claude загрузил файл.

Обратите внимание, что строка проверки типов — это только команда. Claude нужно знать команду, чтобы проверять свою работу по ходу дела. Если вы также хотите, чтобы Claude Code обеспечивал успешную проверку типов до того, как Claude закончит, это задача для хука Stop. Строка вроде Always typecheck before you finish в этом файле срабатывает в большинстве случаев, но не каждый раз.

Писать файл с нуля не обязательно:

  • /init генерирует начальную версию на основе вашей кодовой базы. Дальше работа в основном сводится к удалению строк. Руководство по памяти рекомендует не превышать 200.
  • /doctor предлагает сокращения для всего, что Claude может и так вывести из кода.
  • /doctor prompt-audit помечает инструкции, которые были написаны для старых моделей, ссылаются на несуществующие файлы или противоречат друг другу.

Ваши личные предпочтения помещаются в CLAUDE.local.md, а не в CLAUDE.md, и этот файл добавляется в .gitignore, чтобы он не попал в репозиторий.

[!NOTE]

Если Claude продолжает игнорировать строку, которая есть в CLAUDE.md, добавление IMPORTANT, скорее всего, не поможет. Либо файл стал настолько длинным, что строка теряется, либо эта строка — правило, не допускающее исключений, и тогда ей место в хуке.

Ограничьте правила одной частью кодовой базы

Если правило важно только в одной части кодовой базы, поместите его в .claude/rules/ с фильтром paths:, чтобы оно загружалось только тогда, когда Claude действительно работает там. Например, этот .claude/rules/api.md загружается для файлов TypeScript в src/api/:

---
paths:
  - "src/api/**/*.ts"
---
- Validate request bodies with the zod schemas in src/api/schemas/, don't hand-roll checks
- Every new endpoint needs an entry in openapi.yaml, CI fails without it

Помещайте командные процедуры в скиллы

Более способная модель больше знает об инженерии, но не то, как ваша команда делает релиз, что написано в вашем ранбуке инцидентов или как вы хотите писать документацию API. Такие знания помещаются в скилл: процедуру или фрагмент командных знаний, сохранённые в .claude/skills/<name>/SKILL.md.

Для таких вещей скиллы к тому же меньше нагружают контекст, чем CLAUDE.md. Для скилла, который Claude может запустить сам, в каждой сессии он видит название и описание, но читает полный файл, только когда этого требует задача. Длинная процедура релиза в скилле не отягощает ваше несвязанное исправление бага так, как это было бы в CLAUDE.md.

[!NOTE]

Правило CLAUDE.md относится и к скиллам: записывайте только то, что Claude не может найти сам.

Для рабочего процесса с побочными эффектами, например реального выпуска этого релиза, добавьте disable-model-invocation: true. Тогда Claude не сможет запустить скилл сам, и он будет выполняться, только когда вы сами введёте /release. Сохранённый как .claude/skills/release/SKILL.md, он может выглядеть так:

---
name: release
description: Cut a new release. Bumps the version, writes the changelog entry, tags it and pushes the tag so CI can publish.
disable-model-invocation: true
---
1. Make sure you're on main with a clean tree. If not, stop and ask.
2. Run `pnpm changeset version` and commit the result.
3. Summarize the PRs merged since the last tag into CHANGELOG.md, one line each, user-facing changes only.
4. Tag `v<new version>` and push the tag. CI publishes from there, never publish from your machine.

Подключите инструменты, которые нужны Claude

Часть того, чего не видит Claude, находится совсем в другой системе, например в трекере задач или панели ошибок. Если у этой системы есть CLI, это обычно самый простой путь. Например, если gh установлен и вы в нём авторизованы, Claude будет открывать pull request и читать комментарии ревью без каких-либо объяснений с вашей стороны. Для CLI, который он раньше не видел, достаточно указать ему на --help.

Для систем без CLI есть MCP. Сервер добавляется из оболочки:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Затем сервер появляется в /mcp внутри сессии. Подключённые серверы добавляют названия своих инструментов и инструкции в контекст, даже когда вы их не используете, поэтому стоит там же отключить ненужные.

А если вы работаете с типизированным языком, плагин code intelligence позволяет Claude сразу переходить к определению, вместо того чтобы читать множество файлов в его поисках.

Дайте Claude проверку для запуска

Claude останавливается, когда работа выглядит завершённой. Если у него нет ничего, что можно запустить и узнать, завершена ли работа на самом деле, ему остаётся ориентироваться только на «выглядит завершённой». На практике это делает набором тестов вас, и каждая ошибка ждёт, пока вы случайно её не заметите.

Если дать ему что-то, что возвращает «пройдено» или «не пройдено», Claude может замкнуть этот цикл сам. Он вносит изменение, запускает проверку и, если что-то сломалось, читает вывод и исправляет, прежде чем снова запустить проверку.

[!TIP]

Дайте Claude что-то, что он может запустить и что возвращает «пройдено» или «не пройдено». Когда это у него есть, он может продолжать сам, и вам не нужно наблюдать.

Проверкой может быть почти что угодно, лишь бы Claude мог прочитать результат:

  • Тестовый файл
  • Код выхода сборки
  • Линтер
  • Скрипт, сравнивающий вывод с фикстурой
  • Скриншот браузера рядом с макетом

Если в вашем репозитории уже есть что-то из этого, самая полезная строка в CLAUDE.md — команда, которая это запускает.

Насколько строгой сделать проверку, решать вам. Варианты простираются от решения самого Claude до обеспечения со стороны Claude Code:

  • В промпте: run the auth tests after, and keep going until they pass. Claude сам решает, когда результат его устраивает. Это работает для любой задачи уже сегодня и без настройки.
  • Как цель: /goal all tests in tests/auth pass and lint is clean задаёт условие, которое отдельная модель проверяет по диалогу после каждого хода, и Claude продолжает, пока оно не выполнено. Вам самим в сессии это нужно редко. Это важно для длинных фоновых запусков, где Claude иногда завершает ход сводкой о прогрессе, хотя пункты ещё не закрыты, и цель отправляет его обратно к работе.
  • Как хук Stop: хук Stop запускает ваш скрипт каждый раз, когда Claude пытается завершить ход, и возвращает Claude к работе, если скрипт завершается с кодом выхода 2. Это обеспечивается Claude Code (средой выполнения), поэтому ход не закончится, пока проверка типов не пройдёт или не будет достигнут лимит блокировок. Пример приведён ниже.
  • Тем, кто не писал код: в терминале /code-review проверяет diff в новом субагенте, который никогда не видел ваш диалог. На него не влияют рассуждения, которые привели к этому коду.

Какой бы вариант вы ни выбрали, просите у Claude доказательства: команду, которую он запустил, и её вывод, или скриншот. «Все тесты проходят» само по себе мало что говорит, а прочитать вывод быстрее, чем перезапускать проверку самостоятельно. Для сессии, за которой вы не наблюдали, это ещё и единственное доказательство, которое у вас есть.

[!TIP]

Когда Claude говорит, что закончил, вы также можете запустить в сессии /verify: Claude соберёт и запустит приложение и посмотрит на результат. Это выявляет проблемы, которые пропускают тесты и проверки типов.

Ревью на соответствие спецификации

Если вы хотите, чтобы ревью проверяло работу на соответствие вашему плану, а не искало ошибки в целом, напишите промпт для ревью сами:

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

[!NOTE]

Не убирайте из этого промпта часть skip style. Рецензент, которого попросили найти проблемы, всегда найдёт что-нибудь. Если исправлять каждое замечание, в итоге получатся лишние слои абстракции и тесты для невозможных случаев.

Обеспечьте проверку с помощью хука Stop

Версия правила проверки типов в виде хука Stop — это несколько строк в .claude/settings.json. Остановку блокирует код выхода 2. Всё, что команда выводит в stderr, возвращается Claude как причина, по которой он пока не может закончить, поэтому вывод компилятора перенаправляется туда:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Чтобы увидеть это в действии, попросите Claude внести изменение, которое ломает тип: вместо завершения он получит ошибки компилятора и продолжит работу, пока tsc не пройдёт. Если хук блокирует восемь остановок подряд без вызова инструмента между ними, Claude Code переопределяет следующую блокировку и завершает ход. Чтобы поднять этот предел, задайте CLAUDE_CODE_STOP_HOOK_BLOCK_CAP.

Обеспечьте соблюдение правил без исключений

[!TIP]

Если что-то должно происходить каждый раз, сделайте это хуком, правилом deny или управляемой настройкой. CLAUDE.md предназначен для рекомендаций, и Claude вправе решить, что рекомендация неприменима.

Возьмите три правила, которые у вас, возможно, сейчас есть в CLAUDE.md: Never read .env, Always run the formatter after editing, Don't touch the migrations folder. Claude будет соблюдать их почти каждый раз. Те немногие, для которых «почти» недостаточно, перенесите из CLAUDE.md в конфигурацию, которую Claude Code (среда выполнения) применяет сам. С этого момента результат не зависит от того, что модель помнит или решает.

Обеспечьте выполнение шагов с помощью хуков

Хуки запускают что-то ваше в фиксированных точках цикла Claude: до или после вызова инструмента, когда Claude пытается остановиться, при запуске сессии и так далее. Этим может быть:

  • Shell-команда (обычный случай)
  • POST-запрос к HTTP-эндпоинту
  • Вызов инструмента на одном из ваших MCP-серверов
  • Хук prompt или agent, который позволяет решать модели

Хук prompt или agent просит решить другую модель, поэтому он тоже не детерминирован. Для настоящего обеспечения используйте хук command или http и добавьте onFailure: "block", если действие должно быть остановлено и тогда, когда сам хук падает или превышает тайм-аут. Например, для хука, который сканирует коммиты на наличие секретов, лучше заблокировать коммит, чем пропустить его непросканированным, пока сканер не работает.

Вот правило форматирования в виде хука PostToolUse. Он запускается после каждого Edit или Write, и то, помнит ли Claude это правило, больше не важно, потому что запускает его не Claude:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write --ignore-unknown \"$(jq -r '.tool_input.file_path')\"" }
        ]
      }
    ]
  }
}

Чтобы проверить хук, попросите Claude добавить строку с неправильным отступом в файл, который форматирует Prettier. Сохранённый файл вернётся с исправленным отступом.

Правило миграций становится хуком PreToolUse, который завершается с кодом выхода 2 для любого пути в migrations/. Писать его самостоятельно не нужно: write a hook that blocks edits to the migrations folder работает как промпт, а /hooks показывает результат. Но не перестарайтесь: хук предназначен для правила с нулём исключений, а у Prefer named exports их множество, поэтому оно остаётся в CLAUDE.md.

Ограничьте доступ с помощью правил разрешений и песочницы

Правила разрешений определяют, что Claude разрешено запускать, читать и загружать. Правила deny действуют в любом режиме разрешений, включая auto и bypassPermissions, и именно поэтому правилу для .env место там:

{
  "permissions": {
    "allow": ["Bash(pnpm tsc --noEmit)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
  }
}

С сохранённой конфигурацией просьба к Claude показать содержимое .env завершится неудачей — как через инструмент Read, так и через cat .env.

Правила сопоставляются с вызовами инструментов, а не с намерениями, поэтому стоит знать, где проходят границы:

  • Правило Read действительно перехватывает cat .env, потому что Claude Code распознаёт распространённые команды чтения файлов.
  • Оно не перехватит скрипт, который открывает файл.
  • Правило deny для WebFetch на домен ничего не делает с curl к тому же домену, если не включена песочница.

Для ограничения доступа к файловой системе или сети на уровне ОС включите песочницу командой /sandbox в сессии. Она ограничивает shell-команды Claude в macOS, Linux и WSL2 и также учитывает ваши правила deny для Read и правила WebFetch(domain:...), поэтому для всего, что связано с безопасностью, нужно и то, и другое.

По умолчанию Claude всё ещё может попросить повторить заблокированную команду вне песочницы, и этот запрос проходит обычный процесс разрешений. Строгий режим песочницы на вкладке Overrides в /sandbox отключает такую повторную попытку.

[!WARNING]

Авторежим — это модель-классификатор, оценивающая каждое действие, а не жёсткое правило. Она хорошо с этим справляется, но, как любое суждение, может ошибаться. Кроме того, вы можете настраивать, что она считает рискованным, а ваша организация может полностью отключить авторежим, поэтому вашим правилам «никогда» место в правилах deny или хуках.

Выберите, к кому применяется правило

То, где находится правило, определяет, к кому оно применяется:

  • .claude/settings.local.json и ~/.claude/settings.json принадлежат только вам. Когда вы выбираете Yes, and don't ask again для команды, Claude Code сохраняет это правило в локальный файл.
  • .claude/settings.json и хуки в нём принадлежат репозиторию. После коммита они применяются ко всем, кто работает в репозитории. Его правила deny действуют сразу. Его правила allow ждут, пока каждый человек не примет диалоговое окно доверия для этой папки, а доверие к рабочему пространству также определяет, когда его хуки начнут выполняться на их машине.
  • Управляемые настройки принадлежат организации. Они поступают из консоли администратора, MDM или файла managed-settings.json, и никакой личный файл настроек не может их переопределить, что делает их единственным местом для политики команды безопасности. Если именно вы их задаёте, см. Настройка Claude Code для вашей организации.

Какой бы ни была область действия, держите набор принудительных правил небольшим. Каждый хук и каждое правило deny иногда срабатывает, когда не должно, и кому-то приходится поддерживать каждое из них. Если у вас их накопилось сорок, большинство из них, вероятно, предпочтения, которые Claude мог бы взвесить сам.

Измените настройку по умолчанию

[!TIP]

Значения по умолчанию достаточно хороши, чтобы их не трогать, пока задача не начнёт стоить больше времени, токенов или прерываний, чем следует. Когда это происходит, запустите /usage в сессии, чтобы увидеть, куда всё ушло.

Новая сессия уже принимает за вас несколько решений:

  • Интерактивные сессии в терминале и VS Code запускаются в авторежиме.
  • На большинстве тарифов и у большинства провайдеров используется Claude Opus 5.5 с effort medium.
  • Работа делегируется субагентам, когда для этого есть причина.
  • Диалог сжимается по мере роста.

Чаще всего вы об этом даже не задумываетесь. Когда задача всё же обходится дороже, чем следует, причина обычно в одном из этих четырёх пунктов.

Измените режим разрешений

У обоих концов диапазона разрешений есть своя цена:

  • Режим Manual: вы сами подтверждаете каждую правку и каждую команду, которая выходит за рамки чтения. Безопасно, но после десятого запроса вы начинаете подтверждать не читая, и ничего не движется, пока вас нет за клавиатурой.
  • bypassPermissions: подтверждает всё, что не покрыто вашими правилами deny и ask, что имеет смысл только в одноразовом контейнере.

Авторежим находится между ними, и именно в нём запускаются интерактивные сессии в терминале и VS Code. Claude работает, не останавливаясь ради рутинных подтверждений, а отдельная модель-классификатор проверяет действия в фиксированном порядке перед их выполнением. Он сосредоточен на том, что вы хотели бы, чтобы остановил человек:

  • curl | bash
  • Деплои и миграции в продакшене
  • Force push поверх чужой работы
  • Отправка конфиденциальных данных на внешние эндпоинты
  • Действия, которые выглядят так, будто ими управляет контент, прочитанный Claude, а не вы

Когда он всё же что-то блокирует, вы получаете уведомление, а действие появляется в разделе Recently denied в /permissions, где его можно повторить с ручным подтверждением. После трёх блокировок подряд (или двадцати в сумме) авторежим приостанавливается и снова начинает спрашивать вас.

Ничто из этого не заменяет ваши детерминированные механизмы, потому что классификатор работает после них. Правила deny и ask, а также хуки PreToolUse применяются до того, как классификатор что-либо увидит, поэтому правило deny блокирует в авторежиме точно так же, как и везде. Песочница по-прежнему ограничивает shell-команды, которые она оборачивает.

[!NOTE]

Вы также можете сказать в диалоге don't push until I've reviewed, и классификатор воспримет это как сигнал блокировки. Но это всё ещё модель, читающая транскрипт, и фраза может потеряться при сжатии диалога, поэтому всему важному место в правиле deny.

Обратная проблема — классификатор, который раз за разом останавливает то, что в вашей среде является рутиной. Вместо того чтобы каждый раз подтверждать вручную, добавьте это в autoMode.allow или опишите вашу доверенную инфраструктуру в конфигурации авторежима. Это обычный английский текст, а не шаблоны, и /auto-mode-setup может подготовить для вас раздел environment на основе вашего проекта и недавних сессий:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/example-org and every repo under it",
      "Trusted internal domains: *.internal.example.com"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is fine, it's isolated from production and resets nightly"
    ]
  }
}

[!WARNING]

Сохраняйте "$defaults" в каждом заданном вами списке, потому что без него ваши записи заменяют встроенные правила этого списка, а не дополняют их. Для environment и allow вы потеряете встроенный контекст и исключения, а список soft_deny без него лишается встроенных блокировок force push и деплоев в продакшен.

Блок autoMode также должен находиться в ~/.claude/settings.json, а не в проекте, потому что классификатор игнорирует autoMode в настройках проекта.

Если вы предпочитаете видеть каждую правку и команду до их выполнения, Shift+Tab в сессии переключает режимы разрешений, включая Manual, или можно запустить claude --permission-mode manual из оболочки. А если Manual затем спрашивает слишком часто, /fewer-permission-prompts просматривает ваши недавние транскрипты на предмет частых вызовов Bash и MCP только для чтения и добавляет их в список разрешённых в .claude/settings.json.

Измените модель и effort

Effort — основной способ управлять тем, как долго думает Claude, и он заменяет большую часть того, что раньше делали формулировками промпта. Claude Opus 5.5, Sonnet 5.5 и Haiku 5.5 по умолчанию используют medium, чего вполне достаточно для повседневной работы над функциями с понятным объёмом. Случаи, когда стоит его менять с помощью /effort в сессии:

  • Повысьте его через /effort high или /effort xhigh, когда правильный результат зависит от случаев, которые легко упустить. Например, баг в коде, который писали не вы, нестабильный тест или изменение схемы, при котором Claude должен найти всех, кто читает старую структуру. Тогда Claude проверяет больше граничных случаев и тщательнее перепроверяет свою работу перед ответом — на это и уходят дополнительное время и токены.
  • Понизьте его через /effort low, когда вы быстро обмениваетесь репликами и всё равно просматриваете каждый результат: мозговой штурм, первый набросок, переименование в нескольких файлах. Claude быстрее даст вам отправную точку, а поскольку вы направляете каждый шаг, дополнительные размышления почти ничего бы не изменили, кроме времени ожидания.
  • Оставьте max для сложной задачи, которую Claude должен проработать без вас, например поиска уязвимости. На обычных задачах он склонен размышлять избыточно, так что вы платите больше за ответ, который может оказаться не лучше, чем дал бы high.
  • Когда это нужно только для следующего сообщения, например для одного хитрого вопроса посреди в остальном рутинной работы, добавьте в этот промпт ultrathink, вместо того чтобы менять настройку.

Что касается самой модели, Opus 5.5 по умолчанию хорошо справляется с большинством задач программирования, а Sonnet стоит дешевле на рутинной работе. Claude Fable 5.1 доступна, когда вы явно выбираете её через /model fable, а Haiku хорошо подходит для субагентов, выполняющих простые задания. Полный список по тарифам и провайдерам — в разделе Конфигурация модели.

Знайте, во что обходятся субагенты

Claude сам делегирует работу субагентам:

  • Широкий поиск по кодовой базе передаётся встроенному агенту Explore.
  • Побочные задачи ответвляются, пока включён режим fork (по умолчанию).
  • Запускаемые им субагенты по умолчанию работают в фоне, поэтому ваш основной диалог продолжается.

Просить об этом вам придётся редко, но полезно знать, что вы получаете и сколько это стоит.

Субагенты окупаются в следующих ситуациях:

  • Одновременное выполнение независимых частей работы, чтобы вся задача завершилась быстрее
  • Вынос длинного вывода, например полного прогона тестов или широкого поиска, из основного диалога, где иначе он оставался бы до конца сессии
  • Получение рецензента, который не видел, как писался код
  • Предоставление задаче меньшего набора инструментов, чем у основной сессии, например рецензент, который может читать, но не редактировать

Обходятся они вам в основном в токены, поскольку каждый субагент отправляет собственные запросы, и они учитываются в том же объёме использования, что и основной диалог. Иногда это ещё и время: новому субагенту сначала нужно собрать контекст, который в вашем диалоге уже был, поэтому он может оказаться медленнее, чем выполнение задачи на месте.

И по умолчанию это та же модель (или меньшая) на той же задаче. Вы получаете параллелизм или свежий взгляд, но не более умный ответ.

Чтобы тратить на них меньше:

  • Задайте model: haiku в определении субагента, если его работа проста, например собрать файлы, импортирующие модуль, или проверить ссылки в документации. Такой работе не нужна большая модель, а Haiku стоит намного дешевле за запрос.
  • Просите возвращать короткие сводки, чтобы двадцать результатов всё равно не заполнили ваш контекст.
  • Смотрите /usage, чтобы увидеть, какую долю использования занимает каждый тип субагентов, и понять, какие из них оправдывают свою стоимость.
  • Дайте пользовательскому субагенту в .claude/agents/ только tools: Read, Grep, Glob. Теперь это рецензент, который ничего не может редактировать, и это ограничение обеспечивается Claude Code, а не запрашивается в промпте.

Такой рецензент — это один короткий файл, .claude/agents/reviewer.md:

---
name: reviewer
description: Reviews changed files against the spec they were built from. Use after implementing a feature, before opening the PR.
tools: Read, Grep, Glob
---
You're reviewing code you didn't write. Compare the changed files against the spec you're given,
check that every requirement is implemented and the listed edge cases have tests,
and report only the gaps that affect correctness. Skip style.

Попросите Claude have the reviewer compare the rate limiter against SPEC.md, и пробелы вернутся в вашу сессию, где Claude сможет их исправить.

Сокращайте расходы и контекст

При окне в 1M токенов у большинства современных моделей и сжатии вблизи его верхней границы контекст у вас будет заканчиваться редко. Но вы всё равно можете платить за контекст, который вам не нужен. Каждый запрос отправляет весь диалог, поэтому сессия, в которой накопились три несвязанные задачи, перечитывает все три на каждом ходу четвёртой. Это стоит дешевле, пока кэш тёплый, и по полной цене после его истечения.

/usage — первое место, куда стоит заглянуть. На Pro, Max, Team и Enterprise он разбивает ваше использование по скиллам, субагентам, плагинам и MCP-серверам. Он также помечает такие паттерны, как длинный контекст или частые промахи кэша, когда один из них превышает 10% вашего использования. Дальше — обычные способы исправления:

  • /clear между несвязанными задачами. Это ничего не стоит и означает, что следующая задача не продолжает платить за историю предыдущей. /clear oauth-migration даёт имя сессии, которую вы покидаете, чтобы позже к ней можно было вернуться.
  • /compact с фокусом, например /compact keep the API changes and the test commands. В длинной сессии /compact сам по себе является большим запросом, поскольку читает весь диалог, чтобы его обобщить, и тем более после истечения кэша.
  • Следите за фоновой работой: /loop, проверка цели после каждого хода и собственные субагенты Claude продолжают отправлять запросы, пока вы ничего не вводите.

[!NOTE]

Кэш промптов живёт около часа при подписке и пять минут при использовании API-ключа, облачного провайдера или кредитов использования. Субагенты получают пять минут, если вы это не измените.

При часовом кэше простаивающая сессия объёмом более примерно 200K токенов сжимается незадолго до истечения кэша, поэтому после обеда вы продолжите со сводки. Если история вам вообще не нужна, новая сессия всё равно обойдётся дешевле.

Управляйте сессией

[!TIP]

Следите за первой минутой, нажимайте Esc, как только Claude отклоняется от курса, а после двух неудачных исправлений запустите /clear и напишите промпт получше вместо третьего исправления.

Никакая конфигурация не заменит наблюдения за первой минутой и вмешательства, когда Claude направляется не туда, куда вы хотели. Для этого есть всего несколько средств управления, и их стоит знать наизусть:

  • Esc останавливает Claude посреди действия и сохраняет всё сделанное до этого момента, поэтому его можно перенаправить без потери работы.
  • /rewind или двойное нажатие Esc при пустом промпте открывает меню перемотки, где можно откатить код, диалог или и то, и другое к более раннему промпту. Благодаря этому можно с небольшим риском сначала попробовать более смелый подход и откатиться, если он не сработает. То же меню может обобщить часть диалога, если она устарела.
  • /clear начинает заново. Если вы дважды исправили одно и то же, а всё по-прежнему неправильно, третье исправление в основном лишь добавится к диалогу, который уже содержит две неудачные попытки, которые Claude продолжит перечитывать. /clear плюс один новый промпт, учитывающий то, что вы узнали, почти всегда работает лучше.

[!WARNING]

Чекпоинты охватывают файлы, которые Claude редактировал собственными инструментами работы с файлами в основном диалоге, поэтому файл, который затронула только команда Bash, не восстанавливается. Они работают вместе с git, а не заменяют его.

Ещё два средства поменьше: /btw отвечает на быстрый вопрос, ничего не добавляя в историю. А для работы, растянутой на несколько дней, /rename oauth-migration в сессии даёт ей имя, чтобы позже claude --resume oauth-migration из оболочки подхватил её снова, вместе с чекпоинтами. claude --continue возобновляет самую последнюю сессию.

Позвольте Claude работать без вас

[!TIP]

Прежде чем оставить запуск без присмотра, убедитесь, что он знает, как выглядит готовый результат, может проверить свою работу и имеет доступ только к тому, к чему должен. Задайте ему предел по ходам или расходам и сделайте так, чтобы в конце результат одобрил человек.

Всё на этой странице становится немного важнее, когда вас нет рядом, чтобы заметить ошибки. Пока вы наблюдаете, отсутствие у Claude какой-то части контекста не страшно: вы заметите это за одно-два сообщения и скажете ему. В запуске, который вы начали перед сном, никто ему ничего не скажет, и утром вы узнаете, что он всю ночь строил работу на неверном предположении.

Прежде чем оставить задачу выполняться самостоятельно, стоит пройтись по этим пяти вопросам применительно к конкретной задаче:

  1. Знает ли он, как выглядит готовый результат? Условие цели, файл спецификации или падающий тест, который он должен сделать зелёным.
  2. Может ли он проверить свою работу? Набор тестов, хук Stop, какой-либо этап ревью.
  3. К чему ему разрешено прикасаться? Правила разрешений, dontAsk, песочница, worktree, единственная ветка, в которую он может делать push.
  4. Что его остановит? --max-turns, --max-budget-usd, лимит расходов.
  5. Куда идёт результат и кто его утверждает? PR, комментарий или сводка, а затем человек, одобряющий слияние, деплой или что-либо ещё необратимое.

После запуска Claude сам доведёт длинную задачу до конца. За вами остаётся запустить её, решить, что «готово» означает на этот раз, и одобрить слияние в конце.

Запускайте Claude из скрипта

claude -p "prompt" выполняется один раз и завершается — именно так Claude Code оказывается в задачах CI, git-хуках и циклах оболочки.

В скрипте вам почти всегда понадобятся ещё несколько флагов:

  • --bare пропускает хуки, скиллы, плагины, MCP-серверы и файлы CLAUDE.md — как из репозитория, так и с машины, — поэтому запуск ведёт себя одинаково, где бы он ни выполнялся. Он также никогда не использует ваш вход в claude.ai: аутентификация берётся из ANTHROPIC_API_KEY, apiKeyHelper в файле, переданном через --settings, или из учётных данных вашего облачного провайдера.
  • --append-system-prompt, --mcp-config и --settings явно передают всё, что запуску действительно нужно.
  • --allowedTools заранее разрешает его инструменты, а --permission-mode dontAsk отклоняет всё остальное, что потребовало бы подтверждения.
  • --output-format json даёт единый объект результата для разбора, а stream-json с --verbose передаёт события по мере их возникновения.

Вместе это выглядит так:

for file in $(cat files.txt); do
  claude --bare -p "Migrate $file to the new logger API and commit. Reply OK or FAIL." \
    --allowedTools "Read,Edit,Bash(git add *),Bash(git commit *)" \
    --permission-mode dontAsk \
    --max-turns 20
done

Когда запуск завершается, Claude отвечает OK или FAIL, а запуск, достигший лимита ходов, вместо этого завершается с ошибкой. Сначала попробуйте на трёх файлах, посмотрите, что пошло не так, исправьте промпт, а затем запустите остальные.

Авторежим работает и с -p, если передать --permission-mode auto. В неинтерактивном запуске блокировка классификатором запрещает только это одно действие, и Claude продолжает работу, а повторные блокировки не приостанавливают запуск, как это происходит в терминале. Прочитайте, как там применяются пороговые значения, прежде чем полагаться на это.

Запускайте по расписанию или по событию

Когда запуск идёт, Claude может справиться с остальным сам. Единственное, чего он не может, — решить начать, поэтому это должно сделать что-то другое: вы, таймер или событие вроде упавшей проверки CI или нового PR.

Внутри открытой сессии это /loop, который повторяет промпт с заданным интервалом:

/loop 15m check CI on this branch, and if it's red pull the failing job's log, fix it and push

Каждый запуск — это ещё один ход в той же сессии, поэтому не оставляйте его работать в длинном диалоге. Для всего, что должно происходить, пока ваш ноутбук закрыт, /schedule настраивает облачную запланированную задачу, которая запускается по таймеру. Для неё нужен вход в claude.ai, а не API-ключ. Триггер по событию GitHub можно добавить, попросив об этом Claude, а API-триггер — на claude.ai/code/routines.

[!WARNING]

Прежде чем оставить облачную запланированную задачу работать, защитите main с помощью правила ветки GitHub, которое задача не может обойти. И понаблюдайте за первыми несколькими запусками чего-либо нового, прежде чем доверять ему работу без присмотра.

Запускайте сессии параллельно

Когда у вас одновременно идут отдельные части работы, дайте каждой собственную рабочую копию, чтобы правки не конфликтовали. claude -w feature-auth запускает сессию в новом worktree, десктопное приложение запускает несколько таких сессий рядом, а облачные сессии выполняют их в облаке, а не на вашей машине.

Worktree — это свежая рабочая копия, а значит, файлов из gitignore, таких как .env, там нет, и зависимости не установлены. Для первого перечислите нужные файлы из gitignore в .worktreeinclude в корне репозитория (синтаксис как у .gitignore), и Claude Code скопирует их в каждый создаваемый worktree:

.env
.env.local
config/dev-credentials.json

Ограничьтесь небольшими файлами: они копируются, а не связываются ссылками, поэтому node_modules там означал бы полную копию на каждый worktree. Для больших каталогов есть настройка worktree.symlinkDirectories; также можно держать команду установки в CLAUDE.md, чтобы Claude запускал её каждый раз, когда начинает работу в новой копии.

Убирать за всем этим самостоятельно вам придётся редко:

  • Когда вы выходите из безымянной сессии в worktree, Claude Code удаляет worktree, если в нём ничего нет. Для именованной сессии или сессии с изменениями он спрашивает, что делать.
  • Worktree субагентов исчезают, когда субагент завершает работу без изменений.
  • Оставшиеся worktree субагентов и фоновых сессий удаляются, когда они старше cleanupPeriodDays и не содержат работы.

[!NOTE]

За запуском claude -p --worktree придётся убирать самостоятельно, поскольку он завершается без вопросов. Удаляйте такие worktree с помощью git worktree remove <path>, а если git отказывает, потому что worktree заблокирован, сначала выполните git worktree unlock <path>.

Для одного большого механического изменения во многих файлах /batch migrate every handler to the v2 response helpers разбивает работу на 5–30 частей и показывает вам план. Затем он выполняет каждую часть в собственном worktree и открывает для неё PR. Из оболочки claude agents (пока research preview) даёт вам один экран для всего, что работает в фоне на вашей машине.

Вторая сессия — это также самый простой независимый рецензент, которого можно получить. Одна сессия пишет ограничитель частоты запросов, другая проверяет @src/middleware/rateLimiter.ts, не наблюдая за его написанием, а вы вставляете замечания обратно в первую. Та же идея, что и у /code-review, только сообщения переносите вы.

Что можно перестать делать

Каждый из этих советов был хорошим, когда его написали. Большинство были обходными путями для того, что модель тогда ещё не умела делать надёжно, и с тех пор модели это наверстали. Если некоторые из них всё ещё остаются у вас привычками, вот почему от них можно безопасно отказаться.

Старый совет Почему он устарел
Контекстное окно — ваше главное ограничение, управляйте им агрессивно У большинства современных моделей окно в 1M токенов, а сжатие происходит само, поэтому контекст заканчивается редко. /clear между задачами по-прежнему стоит делать, потому что сфокусированный контекст даёт лучшие ответы и стоит дешевле.
Добавляйте IMPORTANT или ВЕРХНИЙ РЕГИСТР к инструкциям, которые Claude продолжает пропускать Старым моделям иногда требовались акценты. Современные следуют просто сформулированной строке, а нагромождение акцентов в основном заставляет Claude применять правило чрезмерно. Если это правило, которое не может гнуться, превратите его в хук или правило deny. Если строка теряется в длинном файле, файл нужно сократить.
Используйте субагентов, чтобы защитить контекстное окно Нехватка контекста теперь редко бывает проблемой. Субагенты по-прежнему отлично подходят для параллельной работы, выноса шумного вывода и независимого ревью, но каждое из этого стоит дополнительных токенов.
Делегируйте субагенту, чтобы получить лучший ответ Передача той же задачи субагенту не делает ответ лучше. Свежий рецензент действительно помогает, потому что не видел ваших рассуждений, но это не то же самое, что делегирование.
think hard, think harder, be thorough в промпте Для этого есть effort. Эти фразы — обычный текст промпта, который слегка подталкивает Claude в пределах его настройки effort, а не ключевые слова, которые её повышают. ultrathink по-прежнему работает: он запрашивает более глубокие рассуждения на этом одном ходе, не меняя вашу настройку effort.
Говорите Claude продолжать, повторять до готовности, не лениться Современные модели обычно доводят согласованную задачу до конца без напоминаний, а такие строки скорее вызовут лишнюю работу, чем устранят остановку. Дать Claude проверку, которую нужно пройти, — это другое, и это по-прежнему стоит делать. Если запуск всё же останавливается раньше времени, скажите continue, а для запусков без присмотра это обеспечат /goal или хук Stop.
Описывайте архитектуру и структуру файлов в CLAUDE.md Claude сам читает репозиторий. Записывайте только то, чего там нет.

Если какой-либо другой совет на этой странице когда-нибудь начнёт казаться пустой тратой сил, это, вероятно, признак того, что ему тоже место в этой таблице.

Связанные ресурсы