Jak dosáhnout lepších výsledků s Claude Code

Lepších výsledků s Claude Code dosáhnete, když s každým požadavkem zacházíte jako s technickým zadáním: dejte mu relevantní kontext, požádejte ho o průzkum před změnou kódu, omezte řešení a vyžadujte důkaz, že výsledek funguje. Stejný přístup zlepšuje opravy chyb, refaktoring, testy i dokumentaci.

Aktuální dokumentace Claude Code zahrnuje pracovní postupy pro průzkum kódových základen, ladění, refaktoring, testování a plánování před úpravami. Tyto možnosti používejte ke snížení nejistoty, ne k přeskočení úvah, které by potřeboval spolupracovník.

„Nahraďte tento hook globálním storem“ je prompt, který začíná implementací. Předvolí řešení dříve, než asistent prozkoumá vlastnictví a režim selhání.

Začněte takto:

Problém: Indikátor dokončení lekce po navigaci někdy zmizí.

Pozorované: Událost dokončení se zaznamená, ale další obrazovka začne bez
stavu oslavy.
Očekávané: Událost dokončení zůstane dostupná během následné navigace,
pak se vymaže na vhodné hranici.

Rozsah: Prozkoumejte store lekce, obsluhu dokončení a přechod na další
obrazovku. Neměňte nesouvisející kód postupu dashboardu.

Před úpravou sledujte událost od zápisu až po vykreslení. Uveďte aktuálního vlastníka
příznaku, pravděpodobné body resetu a důkazy pro každou hypotézu.

Požadavek žádá model stávajícího chování dříve, než žádá změnu.

Pro cílený úkol zahrňte:

• selhávající příkaz, test, snímek obrazovky nebo chybu;
• soubory či subsystém, které se mají prozkoumat jako první;
• relevantní pravidla projektu nebo architektonická omezení;
• nedávné změny, které mohly zavést regresi;
• chování, které musí zůstat nezměněné.

Nevkládejte do promptu celý repozitář. Pokud bude nezbytný další kontext, požádejte asistenta, aby pojmenoval další soubor nebo hranici, kterou potřebuje, a proč.

U práce s nezřejmým rizikem požádejte před implementací o analýzu pouze pro čtení:

Před úpravou prozkoumejte aktuální tok subscription gatingu a odpovězte na tyto
otázky:

1. Kde se rozhoduje o přístupu?
2. Který stav načítání brání předčasnému přesměrování?
3. Které routy a místa volání CTA používají toto rozhodnutí?
4. Který regresní test prokáže, že placený uživatel není odeslán na pricing?

Zatím nepište kód. Oddělte pozorované chování od předpokladů.

Kontrolní bod analýzy je cenný pro oprávnění, platby, migrace dat, navigaci a sdílený stav. Dává vám také malý dokument k revizi předtím, než vznikne rozsáhlý diff.

Asistent nedokáže spolehlivě odvodit každý kontrakt z blízkého kódu. Uveďte ty důležité:

Omezení:
- zachovejte kompatibilitu aplikace se statickým exportem;
- zachovejte aktivní locale v interní navigaci;
- nepřidávejte runtime chování pouze na serveru;
- ponechte stávajícího klientského zapisovače jako jediný zdroj pravdy;
- neměňte veřejné názvy rout ani událostí;
- bez vysvětlení proč nerozšiřujte změnu mimo tuto funkci.

Konkrétní omezení zpřesňují revizi, protože navrženou změnu lze porovnat s psanou hranicí.

Rozdělte rizikový refaktoring na malé, testovatelné kroky:

Krok 1: Určete duplicitní přechod stavu a vysvětlete aktuální testy.
Krok 2: Vyčleňte pouze sdílený přechod za stejné veřejné API.
Krok 3: Spusťte cílené testy a ukažte změněné chování.
Krok 4: Navrhněte, ale neimplementujte, širší úklid.

Přírůstková práce vás chrání před patchem, který současně mění vykreslování, vlastnictví stavu a testy. Pokud krok 2 selže, příčinu lze snáze izolovat.

Použijte řetězec důkazů:

Důkazy: [logy, stack trace, selhávající test, výstup příkazu nebo kroky uživatele]
Hypotézy: Uveďte nejmenší pravděpodobné příčiny podle priority.
Ověření: Uveďte pozorování, které každou příčinu potvrdí nebo vyloučí.
Oprava: Navrhněte nejmenší změnu podloženou důkazy.
Validace: Kde je potřeba, přidejte regresní test a ruční kontrolu.

Nežádejte asistenta, aby opravoval produkční chování na základě neurčitého příznaku. Oprava, která vypadá sebejistě, není důkaz.

Kritéria přijetí:
- nahlášené selhání pokrývá cílený regresní test;
- úspěšný stávající pracovní postup stále prochází;
- prochází kontrola typů a relevantní příkaz testu;
- diff zůstává ve sjednaném rozsahu;
- závěrečné vysvětlení pojmenuje chování, které nešlo ověřit místně.

To pomáhá Claude Code skončit u výsledku, který lze zrevidovat, namísto toho, aby kompilaci považoval za jediný signál správnosti.

Širší rámec promptu najdete v článku jak psát lepší prompty pro AI. Pro vzory zaměřené na úkol použijte prompt engineering pro vývojáře a šablony promptů pro ladění produkčních problémů.

Pokud úkol mění skript nebo pracovní postup založený na příkazech, před žádostí o opravu zreprodukujte relevantní vstup a výstup. Procvičujte pracovní postupy v terminálu v prohlížeči, aby bylo ověření konkrétní.