Claude Code-handledningsserie 4: Vilka användningsscenarier har Claude Code?

Typiska användningsscenarier

Jag delar in användningsscenarierna i fyra kategorier, listade från mest till minst frekvent använda.

Första kategorin: Förstå kod

Detta är nog den mest använda kategorin. När du tar över någon annans projekt, tittar på en gammal modul eller öppnar ett arkiv utan dokumentation, fråga bara det.

Specifika tillvägagångssätt:

claude "Vad gör det här projektet? Var är startpunkten?" – Den läser package.json, katalogstruktur och nyckelfiler och ger en sammanfattning.
Öppna en funktion, låt den förklara logiken och beskriva flödet (med text).
Låt den spåra hela vägen för en API-förfrågan från frontend till databas.

Det den gör här är i grunden att utföra det "smutsiga arbetet med att läsa kod". Du behöver inte själv greppa i timmar och pussla ihop i huvudet. Den reder ut vägen, och du gör bedömningen.

Ersättningen för denna kategori är: manuellt söka i kodbasen, göra anteckningar och rita anropsgrafer.

Andra kategorin: Skriva och ändra kod

Detta är den mest diskuterade kategorin, men den används faktiskt inte mest. Scenarierna för att skriva kod är oftast så här:

Skapa ny funktion: "Lägg till ett gränssnitt för att ändra e-post i modulen user, validera e-postformatet och skriv enhetstester."
Refaktorering över flera filer: "Byt ut alla moment() i dessa tre filer mot dayjs(), ändra ingen annan logik."
Migrering och uppgradering: "Ändra denna Vue 2-komponent till Vue 3 Composition API-syntax."

Den genererade koden är inte alltid korrekt första gången, men den kan göra alla ändringar över flera filer på en gång, och du kan diffa fil för fil och acceptera eller avvisa.

Ersättningen för denna kategori är: manuellt skriva repetitiv kod, manuellt söka och ersätta referenser över flera filer.

Tredje kategorin: Felsökning och reparation

När en bugg uppstår är det vanliga arbetsflödet: titta på felmeddelandet, lokalisera filen, gissa orsaken, prova en ändring, om det inte fungerar, gå tillbaka. Claude Code kan direkt ta emot hela felstacken och kombinera den med projektkoden för att själv lokalisera problemet.

Typisk användning:

Ge den utdata från ett misslyckat test, den läser relevant kod, ger en lösning, kör testet igen och kontrollerar om det går igenom.
Vid CI-fel, klistra in loggen, låt den fixa, och kör sedan git diff för att bekräfta ändringarna.

Här fungerar det mer som en "första rundans utredare". Det är du som lägger tid på att tänka, men det är den som bläddrar i filer, jämför skillnader och kör verifieringskommandon.

Ersättningen för denna kategori är: att upprepade gånger köra tester, läsa felloggar och manuellt jämföra kodskillnader.

Fjärde kategorin: Diverse automatisering

Denna kategori är den minst framträdande, men sammantaget sparar den mest tid.

Exempel:

Skriv Git commit-meddelanden: claude "Skriv ett commit-meddelande i Conventional Commits-format baserat på aktuell git diff"
Generera PR-beskrivning: Låt den jämföra skillnaderna mellan nuvarande gren och main, och sammanfatta ändringarna samt testinstruktioner.
Skriv versionsinformation: Låt Claude Code läsa commit-historiken för den senaste veckan och generera en CHANGELOG.
Svara på miljöproblem: "Installationen av detta beroende misslyckades, hjälp mig att titta på terminalutdata och hitta orsaken."

Gemensamt för dessa saker är: de är inte komplicerade, men tråkiga. Att göra dem själv kräver att du byter fönster och skriver mycket text. Ge det till den, så är det klart på några sekunder.

Ersättningen för denna kategori är: manuell textredigering, skriva formella dokument, söka efter miljökonfigurationsproblem.

En "karta"

Om du sätter in dessa fyra kategorier i det dagliga arbetsflödet ser det ut ungefär så här:

Hämta ett obekant projekt
    │
    ▼
[Förstå kod] ─── Ta reda på struktur, startpunkt, nyckellogik
    │
    ▼
Börja skriva ny funktion eller ändra modul
    │
    ▼
[Skriva/ändra kod] ─── Generera implementation, refaktorera över filer
    │
    ▼
Kör tester, bugg uppstår
    │
    ▼
[Felsökning och reparation] ─── Analysera fel, lokalisera, fixa, kör igen
    │
    ▼
Förbered commit
    │
    ▼
[Diverse automatisering] ─── Skriv commit, PR-beskrivning, versionsinformation
    │
    ▼
Commit, klart

Du behöver inte använda det i alla fyra kvadranter. Vissa team använder det bara för att förstå kod, andra bara för att skriva tester och skicka PR. Börja med det scenario som stör dig mest.

Två användbara bedömningskriterier

Om du är osäker på om du ska överlåta något till Claude Code, kan du fråga dig själv två frågor:

1. Är uppgiften mer "mekanisk" än "kreativ"?

Att ändra hundra referenser, formatera utdata, generera mallkod – att göra dessa saker själv tar mycket tid, men du har redan tanken. Passar att överlåta till den.

2. Är "verifieringskostnaden" hög?

Om en ändring kräver upprepad växling, körning av tester och loggläsning för att bekräftas, då går det långsamt att prova själv. Claude Code kan själv slutföra cykeln "ändra-kör-titta-ändra igen", vilket gör det mycket lättare för dig.