Claude Code серія уроків 4: Які сценарії використання Claude Code?

Типові сценарії використання

Я поділяю сценарії використання на чотири категорії, розташовані за частотою від високої до низької.

Перша категорія: Розуміння коду

Це, мабуть, найчастіше використовувана категорія. Коли ви беретеся за чужий проект, переглядаєте давній модуль або відкриваєте репозиторій без документації, просто запитайте про це.

Конкретні дії:

claude "Чим займається цей проект? Де вхідна точка?" — він прочитає package.json, структуру каталогів, ключові файли та надасть підсумок.
Відкрийте функцію, попросіть пояснити логіку, описати потік (текстом).
Попросіть відстежити повний шлях API-запиту від фронтенду до бази даних.

Тут він, по суті, виконує "брудну роботу з читання коду" за вас. Вам не потрібно години шукати вручну та складати пазл у голові. Він вибудовує шлях, а ви приймаєте рішення.

Замінник для цього сценарію: ручний пошук у коді, ведення нотаток, створення діаграм викликів.

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

Це найбільш обговорювана категорія, але вона не є найчастіше використовуваною. Сценарії написання коду зазвичай виглядають так:

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

Згенерований код не завжди ідеальний з першого разу, але він може виконати всі зміни між файлами за один раз, і ви можете переглядати diff файлів, приймаючи або відхиляючи їх.

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

Третя категорія: Налагодження та виправлення

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

Типове використання:

Скиньте йому вивід невдалого тесту, він прочитає відповідний код, запропонує виправлення, перезапустить тест і перевірить, чи він пройшов.
Зіткнувшись із помилкою CI, вставте логи, попросіть виправити, а потім запустіть git diff, щоб підтвердити зміни.

Тут він виступає більше як "перший дослідник". Ви витрачаєте час на обмірковування проблеми, а він — на перегляд файлів, порівняння відмінностей та виконання команд перевірки.

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

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

Ця категорія найменш помітна, але в сукупності економить найбільше часу.

Приклади:

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

Спільне в цих завданнях: вони не складні, але клопіткі. Робити їх самостійно означає перемикати вікна та багато друкувати. Доручивши їх йому, ви отримуєте результат за кілька секунд.

Замінник для цього сценарію: ручне редагування тексту, написання формальної документації, пошук проблем налаштування середовища.

"Мапа"

Якщо розмістити ці чотири категорії в щоденному робочому потоці, вийде приблизно така мапа:

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

Вам не обов'язково використовувати його в усіх чотирьох сферах. Деякі команди використовують його лише для розуміння коду, інші — лише для написання тестів і надсилання PR. Який етап найбільше вас турбує, з того й почніть.

Два корисні критерії

Якщо ви не впевнені, чи варто доручати завдання Claude Code, поставте собі два запитання:

1. Чи є це завдання більше "механічним", ніж "творчим"?

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

2. Чи є вартість "верифікації" високою?

Якщо зміна вимагає багаторазових переходів, запусків тестів, перегляду логів для підтвердження, то метод проб і помилок вручну буде повільним. Claude Code може самостійно виконати цикл "змінити-запустити-подивитися-змінити знову", що значно полегшить ваше життя.