Tutorial Claude Code 4: Care sunt scenariile de utilizare ale Claude Code?

Scenarii tipice de utilizare

Împart scenariile de utilizare în patru categorii, ordonate de la cel mai frecvent la cel mai puțin frecvent.

Prima categorie: Înțelegerea codului

Aceasta este probabil cea mai folosită categorie. Când preiei proiectul altcuiva, te uiți la un modul vechi sau deschizi un depozit fără documentație, întrebi direct.

Cum se procedează:

claude "Cu ce se ocupă acest proiect? Unde este punctul de intrare?" – va citi package.json, structura directoarelor, fișierele cheie și va oferi un rezumat.
Deschide o funcție și cere-i să explice logica, să deseneze un flux (descris în text).
Roagă-l să urmărească traseul complet al unei cereri API, de la front-end la baza de date.

Ceea ce face aici este, în esență, să se ocupe de „munca murdară” a citirii codului. Nu mai trebuie să cauți manual cu grep și să asamblezi mental piesele. El pregătește traseul, iar tu iei deciziile.

Alternativa pentru acest scenariu este: căutarea manuală în depozitul de cod, luarea de note și trasarea diagramelor de apeluri.

A doua categorie: Scrierea și modificarea codului

Aceasta este cea mai discutată categorie, dar nu este cea mai frecventă. Scenariile de scriere a codului arată de obicei astfel:

Generarea de funcționalități noi: „Adaugă un endpoint pentru modificarea emailului în modulul user, verifică formatul emailului și scrie teste unitare.”
Refactorizare cross-file: „Înlocuiește toate apelurile moment() din aceste trei fișiere cu dayjs(), fără a modifica altă logică.”
Migrare și actualizare: „Transformă această componentă Vue 2 în sintaxa Composition API din Vue 3.”

Codul generat poate să nu fie corect din prima, dar poate face toate modificările cross-file dintr-o dată, iar tu poți verifica fișier cu fișier, acceptând sau respingând modificările.

Alternativa pentru acest scenariu este: scrierea manuală a codului repetitiv și înlocuirea manuală a referințelor cross-file.

A treia categorie: Debugging și reparare

Când apare un bug, fluxul obișnuit este: vezi eroarea, identifici fișierul, ghicești cauza, încerci o modificare, dacă nu funcționează, revii. Claude Code poate primi direct întregul stack de erori și, împreună cu codul proiectului, se poate localiza singur.

Exemple tipice:

Îi trimiți output-ul unui test eșuat, el citește codul relevant, oferă o soluție, iar după modificare rulează din nou testul pentru a verifica.
Când CI dă erori, lipsești log-urile, el repară, iar apoi rulezi git diff pentru a confirma modificările.

Aici, rolul său este mai mult de „prim investigator”. Tu petreci timpul gândindu-te la problemă, dar el se ocupă de navigarea prin fișiere, compararea diferențelor și executarea comenzilor de verificare.

Alternativa pentru acest scenariu este: rularea repetată a testelor, citirea logurilor de erori și compararea manuală a diferențelor de cod.

A patra categorie: Automatizări diverse

Aceste scenarii sunt cele mai puțin vizibile, dar împreună economisesc cel mai mult timp.

Exemple:

Scrierea mesajelor de commit Git: claude "Pe baza diferențelor git actuale, scrie un mesaj de commit în format Conventional Commits"
Generarea descrierii PR: Cere-i să compare diferențele dintre branch-ul curent și main și să genereze un rezumat al modificărilor și instrucțiuni de testare.
Scrierea notelor de lansare: Roagă Claude Code să citească istoricul commit-urilor din ultima săptămână și să genereze CHANGELOG.
Rezolvarea problemelor de mediu: „Am o eroare la instalarea acestei dependențe, uită-te la output-ul terminalului și găsește cauza.”

Aceste sarcini au în comun faptul că nu sunt complexe, dar sunt mărunte. Dacă le faci singur, trebuie să schimbi ferestre și să scrii mult. Încredințate lui, se rezolvă în câteva secunde.

Alternativa pentru acest scenariu este: editarea manuală a textului, scrierea documentației normative și căutarea configurărilor de mediu.

O „hartă”

Integrând aceste patru categorii în fluxul zilnic de lucru, obținem aproximativ această hartă:

Primirea unui proiect necunoscut
    │
    ▼
[Înțelegerea codului] ─── Înțelegi structura, punctul de intrare, logica cheie
    │
    ▼
Începi să scrii o funcționalitate nouă sau să modifici un modul
    │
    ▼
[Scrierea/Modificarea codului] ─── Generezi implementarea, refactorizezi cross-file
    │
    ▼
Rulezi testele, apare un bug
    │
    ▼
[Debugging și reparare] ─── Analizezi eroarea, localizezi, repari, rulezi din nou
    │
    ▼
Pregătești commit-ul
    │
    ▼
[Automatizări diverse] ─── Scrii mesajul de commit, descrierea PR, notele de lansare
    │
    ▼
Commit, gata

Nu trebuie să folosești toate cele patru cadrane. Unele echipe îl folosesc doar pentru înțelegerea codului, altele doar pentru scris teste și PR-uri. Alege scenariul care te deranjează cel mai mult și începe de acolo.

Două criterii utile

Dacă nu ești sigur dacă o sarcină ar trebui încredințată lui Claude Code, pune-ți două întrebări:

1. Este această sarcină mai degrabă „mecanică” decât „creativă”?

Modificarea a o sută de referințe, formatarea output-ului, generarea de cod șablon – toate acestea, făcute manual, consumă mult timp, dar tu ai deja soluția în minte. Sunt potrivite pentru el.

2. Este „costul de verificare” al acestei sarcini ridicat?

Dacă o modificare necesită navigare repetată, rularea testelor și citirea logurilor pentru a fi confirmată, atunci încercarea manuală este lentă. Claude Code poate realiza singur ciclul „modifică-rulează-verifică-modifică din nou”, iar tu vei fi mult mai ușurat.