Учебник по Claude Code 4: Какие сценарии использования у Claude Code?

Типичные сценарии использования

Я разделяю сценарии использования на четыре категории, упорядоченные по частоте от высокой к низкой.

Первая категория: Понимание кода

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

Конкретные действия:

claude "Что это за проект? Где входная точка?" — он прочитает package.json, структуру каталогов, ключевые файлы и выдаст краткое описание.
Откройте функцию и попросите объяснить логику, описать поток (текстом).
Попросите проследить полный путь API-запроса от фронтенда до базы данных.

Здесь его работа, по сути, — выполнять за вас "черновую работу по чтению кода". Вам не нужно часами искать в grep и собирать пазл в голове. Он выстраивает путь, а вы принимаете решения.

Альтернатива этому сценарию: ручной поиск по кодовой базе, ведение заметок, построение диаграмм вызовов.

Вторая категория: Написание и изменение кода

Это самая обсуждаемая категория, но на самом деле она не самая часто используемая. Сценарии написания кода обычно таковы:

Создание новой функциональности: "Добавь в модуль user интерфейс для изменения email, с проверкой формата email и модульными тестами."
Рефакторинг между файлами: "Замени все moment() на dayjs() в этих трёх файлах, не меняя другую логику."
Миграция и обновление: "Перепиши этот компонент Vue 2 на Composition API Vue 3."

Сгенерированный код не всегда идеален с первого раза, но он может сразу выполнить изменения во всех файлах, и вы можете просматривать diff по файлам, принимая или отклоняя изменения.

Альтернатива этому сценарию: ручное написание повторяющегося кода, ручной поиск и замена межфайловых ссылок.

Третья категория: Отладка и исправление

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

Типичные примеры:

Передайте ему вывод неудачного теста — он прочитает соответствующий код, предложит исправление, а затем снова запустит тест, чтобы проверить.
При ошибке CI вставьте лог, пусть он исправит, а затем выполните git diff, чтобы подтвердить изменения.

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

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

Четвертая категория: Разная автоматизация

Эта категория наименее заметна, но в сумме экономит больше всего времени.

Примеры:

Написание сообщений коммита Git: claude "Напиши сообщение коммита в формате Conventional Commits на основе текущего git diff"
Создание описания PR: попросите его сравнить текущую ветку с main и сгенерировать сводку изменений и инструкции по тестированию.
Написание заметок о релизе: попросите Claude Code прочитать историю коммитов за последнюю неделю и сгенерировать CHANGELOG.
Решение проблем с окружением: "При установке этой зависимости возникла ошибка, посмотри вывод терминала и найди причину."

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

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

"Карта"

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

Получен незнакомый проект
    │
    ▼
[Понимание кода] ─── Разобраться в структуре, входной точке, ключевой логике
    │
    ▼
Начало написания новой функции или изменения модуля
    │
    ▼
[Написание/изменение кода] ─── Генерация реализации, межфайловый рефакторинг
    │
    ▼
Запуск тестов, появление бага
    │
    ▼
[Отладка и исправление] ─── Анализ ошибки, локализация, исправление, повторный запуск
    │
    ▼
Подготовка к коммиту
    │
    ▼
[Разная автоматизация] ─── Написание коммита, описания PR, заметок о релизе
    │
    ▼
Коммит, готово

Вам не обязательно использовать его во всех четырёх квадрантах. Некоторые команды применяют его только для понимания кода, другие — только для написания тестов и отправки PR. Начните с того сценария, который доставляет вам больше всего хлопот.

Два полезных критерия

Если вы не уверены, стоит ли поручить задачу Claude Code, задайте себе два вопроса:

1. Является ли эта задача скорее "механической", чем "творческой"?

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

2. Высоки ли "затраты на проверку" этой задачи?

Если для подтверждения изменения требуется многократно переключаться, запускать тесты, читать логи, то личные попытки будут медленными. Claude Code может сам выполнить цикл "изменить-запустить-проверить-изменить снова", и вам станет намного легче.