Как пользоваться Claude Code: настройка и первые шаги
После установки Claude Code запускается одной командой в терминале. Ниже — как настроить, запустить и начать работать с реальным проектом.
Первый запуск
# Перейдите в папку с проектом
cd /path/to/your/project
# Запустите Claude Code
claude
Claude Code прочитает структуру директории и будет готов к работе. Первый вопрос — любая задача на русском или английском:
> Добавь валидацию email в форму регистрации
> Объясни, что делает функция processPayment()
> Напиши тесты для класса UserRepository
> Найди все места где используется deprecated API
Файл CLAUDE.md — контекст проекта
Создайте файл CLAUDE.md в корне проекта — Claude Code читает его при каждом запуске. Это ключевой механизм для задания контекста:
# Project: MyApp
## Stack
- PHP 8.3, custom MVC framework
- MariaDB, Redis
- Docker Compose
## Code conventions
- PSR-12 coding style
- All public methods must have docblocks
- Tests in /tests, PHPUnit 10
## Architecture notes
- Controllers are thin, logic in Services
- Repositories handle all DB queries
## Commands
- `docker compose up -d` — start services
- `php scripts/migrate.php` — run migrations
Основные режимы работы
Обычный диалог: задаёте задачу, Claude выполняет, подтверждаете каждый шаг.
Claude сначала составляет план, вы согласовываете, потом он выполняет.
Полная автономия без запросов подтверждения. Только в изолированной среде.
Запуск нескольких субагентов параллельно для сложных многоэтапных задач.
Полезные команды
# Запустить в конкретной директории
claude --dir /path/to/project
# Одноразовая задача без интерактива
claude -p "Сгенерируй README.md для этого проекта"
# Выбрать модель
claude --model claude-opus-4-6
# Plan Mode (сначала план, потом выполнение)
claude --plan
# Посмотреть usage
claude usage
Типичный рабочий процесс
Best practices
- Создайте CLAUDE.md — без него Claude не знает стек, соглашения и команды проекта
- Используйте Plan Mode для сложных задач — не позволяйте сразу менять файлы
- Делайте чекпоинты через Git — commit перед каждой крупной задачей, можно откатиться
- Давайте конкретный контекст — «в файле src/Auth.php функция login()» лучше, чем «в коде авторизации»
- YOLO только в изоляции — Auto Mode без подтверждений только в Docker или песочнице
Горячие клавиши
| Клавиша | Действие |
|---|---|
Ctrl+C | Прервать текущую задачу |
Ctrl+D | Выйти из Claude Code |
| ↑ / ↓ | История команд |
/clear | Очистить контекст разговора |
/help | Показать доступные команды |
← Claude Code — главная · → MCP, Skills и Agents
Режимы мышления: think, ultrathink
Claude Code поддерживает специальные ключевые слова, которые переводят модель в режим глубокого анализа:
| Команда в промпте | Токены на обдумывание | Когда использовать |
|---|---|---|
think | ~5 000 | Неочевидные баги, рефакторинг |
think harder | ~10 000 | Архитектурные решения |
ultrathink | до 31 999 | Сложнейший дебаггинг, дизайн системы |
# Пример использования
ultrathink: почему этот алгоритм даёт неверный результат при n > 10000?
think harder: как лучше всего разбить этот монолит на микросервисы?
Запись в CLAUDE.md через #
Если вы часто повторяете одни и те же инструкции — добавьте их в CLAUDE.md одной командой:
# Просто начните сообщение с символа #
# Всегда пиши тесты на pytest, не на unittest
# Не используй async/await в этом проекте
# Коммиты только на английском языке
Claude автоматически добавит эти правила в CLAUDE.md проекта. Они будут работать во всех последующих сессиях.
Параллельные экземпляры
Один из мощнейших рабочих процессов — запуск нескольких Claude Code одновременно в разных терминалах:
# Терминал 1: фронтенд
cd ~/project && claude
# "Перепиши компонент Dashboard, используй React Query"
# Терминал 2: бэкенд (параллельно)
cd ~/project && claude
# "Напиши API эндпоинты для Dashboard"
# Терминал 3: тесты (параллельно)
cd ~/project && claude
# "Покрой тестами всё что в PR #142"
Каждый экземпляр независим и имеет свой контекст. Итого — в 3 раза больше работы за то же время.
Прерывание и возврат назад
- Escape — прерывает текущее выполнение. Можно дать новую инструкцию.
- Escape × 2 — возвращается на шаг назад в истории разговора и отменяет изменения.
- Plan Mode (Shift+Tab) — Claude сначала составляет план и ждёт подтверждения, прежде чем что-то менять. Используйте для рискованных операций.
Отладка с полным контекстом
Разница между плохим и хорошим запросом при дебаггинге:
# Плохо — слишком мало контекста
"Авторизация не работает"
# Хорошо — Claude сразу видит суть проблемы
"Логин падает с 401.
Ожидаемое поведение: редирект на /dashboard после входа.
Фактическое: остаётся на странице логина.
Стек ошибки: [вставьте трейс]
Код middleware: @src/middleware/auth.ts
Последнее изменение: добавил JWT refresh логику вчера."
Двенадцать минут вместо трёх часов
В 2025 году Anthropic провела внутреннее исследование среди своих инженеров. Задача, которая раньше занимала в среднем 3 часа 48 минут, с Claude Code стала выполняться за 14,8 минут. Это не маркетинговая цифра — это медиана по десяткам реальных задач.
Но вот что интересно: ускорение произошло не потому, что Claude "пишет код быстрее". Оно произошло потому, что изменился сам процесс. Разработчик перестал быть исполнителем и стал ревьюером.
«Сдвиг между 2025 и 2026 годом можно описать одной фразой: разработчик переключился с управления контекстом на формулирование результата.»
— из анализа рабочих процессов сообщества Claude Code
На практике это выглядит так: вместо того чтобы самому залезать в файл, искать нужную функцию, держать в голове зависимости и писать код — вы описываете, что должно получиться, а Claude разбирается с деталями. Звучит просто, но психологически это требует перестройки: многие разработчики поначалу инстинктивно начинают сами решать задачу, а Claude используют как продвинутый автокомплит.
Один из самых показательных эпизодов — встреча разработчиков в Сиэтле в январе 2026-го. Principal-инженер из Google публично сказал, что Claude за один час воспроизвёл архитектурную работу, которую его команда делала год. После этого Hacker News несколько дней обсуждал, что это вообще значит для профессии.
CLAUDE.md: что туда реально писать
Файл CLAUDE.md — самый мощный инструмент кастомизации Claude Code. И самый плохо используемый. Большинство начинают туда сваливать всё подряд: соглашения, стиль кода, ссылки на документацию. Через месяц файл раздувается до 500 строк, и Claude начинает его игнорировать.
Правило от сообщества, которое реально работает: для каждой строки спросите себя — если её убрать, Claude сделает ошибку? Если нет — убирайте. Идеальный CLAUDE.md: до 200 строк, только то, чего Claude не может вывести из кода сам.
Что туда должно войти:
- Доменные термины (что значит "сессия" в вашем продукте)
- Архитектурные решения и их причины
- Нестандартные команды и скрипты
- Чего никогда не делать (и почему)
- Связь между модулями, неочевидная из кода
- Стиль кода (Claude видит его сам)
- Документацию библиотек (используйте Context7 MCP)
- Очевидные вещи ("код должен работать")
- Длинные объяснения без конкретики
- Устаревшую информацию, которую забыли удалить
Быстрый старт — команда /init внутри Claude Code. Она анализирует вашу файловую структуру и генерирует стартовый CLAUDE.md с правильными секциями. Потом редактируете под себя.
Продвинутая техника: CLAUDE.md поддерживает импорт файлов через синтаксис @путь/к/файлу. Это позволяет держать документацию отдельно и подключать нужные части:
# CLAUDE.md
@docs/architecture.md
@docs/api-contracts.md
## Commands
- `make test` — запуск тестов
- `make migrate` — применить миграции
## Never do
- Не изменяй schema.sql напрямую, только через миграции
- Не используй прямые SQL-запросы в контроллерах
Hooks: когда CLAUDE.md недостаточно
Есть важный нюанс, который мало кто знает на старте: CLAUDE.md — это рекомендации. Claude следует им примерно в 80% случаев. Для вещей, которые должны происходить всегда — есть hooks.
Hooks — это детерминированные скрипты, которые запускаются на определённые события (до/после редактирования файлов, до/после выполнения команд). Они не зависят от модели — они просто выполняются.
# .claude/hooks/pre-edit.sh
# Запускается ПЕРЕД каждым редактированием файла
#!/bin/bash
# Проверяем что не редактируем production-конфиги
if [[ "$1" == *"config/production"* ]]; then
echo "BLOCKED: production config is read-only"
exit 1
fi
Практическое применение hooks: автоматический запуск линтера после каждого изменения файла, запрет редактирования определённых файлов, автокоммит после успешных тестов, отправка уведомления в Slack когда задача завершена.
Параллельная работа: как это выглядит в практике
Один из самых мощных паттернов, который описывают опытные пользователи — запуск нескольких Claude Code одновременно на разных аспектах одной задачи. Это не просто "открыть второй терминал". Это другой способ думать о работе.
Реальный пример из сообщества: разработчик добавлял новый модуль в монорепо. Три терминала, три Claude:
- Первый: пишет бизнес-логику модуля и тесты
- Второй: обновляет API-контракты и генерирует документацию
- Третий: настраивает CI-пайплайн и Dockerfile для нового сервиса
Все три работают параллельно. Ни один не знает о другом. Разработчик периодически переключается между ними, ревьюит диффы, направляет. Итог: задача на два рабочих дня — сделана за четыре часа.
Репозиторий claude-code-best-practice собрал 84 практики от реальных пользователей. Самые неочевидные из них:
- «Git-checkpoint» перед каждой крупной задачей — коммит до начала работы, чтобы можно было откатиться через
git reset --hard - Давайте задачу целиком — не "добавь функцию X", а "добавь функцию X, покрой тестами, обнови документацию, создай PR"
- Используйте
/compactвместо/clear— сжатие контекста сохраняет важные выводы сессии, тогда как /clear стирает всё - Попросите Claude объяснить план перед выполнением — это раскрывает неверные допущения до того, как они стали изменениями в коде
- Специфичные файлы через @ —
@src/auth/login.ts explain the flow hereдешевле по токенам и точнее, чем "посмотри авторизацию"
Когда Claude Code не помогает
Честный разговор: есть задачи, где Claude Code хуже, чем делать самому. Важно это знать, чтобы не разочаровываться и не тратить токены впустую.
Плохо работает: задачи с неоднозначными требованиями ("сделай лучше"), дизайн на основе субъективных предпочтений ("придумай красивый UI"), отладка в закрытых системах без доступа к логам, задачи где результат сложно проверить автоматически.
Отлично работает: задачи с чёткими критериями успеха (тесты проходят / не проходят), рефакторинг по конкретным правилам, генерация boilerplate по образцу, анализ и объяснение существующего кода, написание тестов для уже написанного кода.
Практическое следствие: перед любой задачей спросите себя, можете ли вы сформулировать, как вы поймёте что задача выполнена правильно. Если да — Claude Code справится. Если нет — сначала нужно это сформулировать.