Prompty pro Claude na debugging, refaktoring a revize architektury

Čtyři zásady, díky kterým fungují všechny prompty níže

Než se pustíme do promptů, tady jsou pravidla, která mají všechny společná. Jejich doplnění do libovolného promptu na programování zlepší výstup víc než změna modelu.

Uveďte svou verzi. Trénovací data se přiklánějí k té hlavní verzi, o které se toho napsalo nejvíc, a to často není verze, kterou používáte. Používáme [framework] [verze], [jazyk] [verze] zabrání většině zastaralých odpovědí.

Omezte rozsah změn (diff). Když požádáte o opravu, často dostanete refaktoring. Změň co nejméně, zachovej stávající strukturu a názvy a u každého upraveného řádku uveď jednořádkový důvod je nejužitečnější věta v celém tomto dokumentu.

Žádejte hypotézy před řešeními. Model, kterého se zeptáte, co je špatně, vám dá odhad podaný jako závěr. Model, kterého poprosíte o seřazené příčiny a levné kontroly, vám dá plán na debugging.

Vyžadujte popis možného dopadu. Co by to mohlo rozbít a řeší to příčinu, nebo jen příznak? zachytí nejnákladnější typ pomoci od AI: změnu, po které příznak zmizí, ale chyba zůstane.

Debugging

1. Seřazené hypotézy

Tady je chyba, relevantní kód a to, co jsem už vyloučil. Ještě mi nedávej opravu. Vypiš čtyři nejpravděpodobnější příčiny seřazené podle pravděpodobnosti a u každé nejlevnější kontrolu, která by ji potvrdila nebo vyloučila. Chyba: [vlož]. Kód: [vlož]. Už vyloučeno: [seznam]. Stack: [jazyk, framework, verze].

2. Přerušovaná chyba

Tohle selhává nepravidelně, přibližně [frekvence], za podmínek [podmínky]. Vypiš kategorie přerušovaných chyb, které by mohly způsobit tento konkrétní příznak: časování, pořadí, vyčerpání zdrojů, externí závislost, stav prosakující mezi běhy, hodiny nebo časová zóna, cachování. U každé napiš, co v kódu podporuje nebo vyvrací tuto možnost, a co přesně bych měl logovat, abych je odlišil. Kód: [vlož].

3. Lokálně to funguje

Tohle funguje lokálně a selhává v [prostředí]. Vypiš všechny kategorie rozdílů prostředí, které by mohly způsobit tento konkrétní příznak: konfigurace, proměnné prostředí, verze, souborový systém a citlivost na velikost písmen, časová zóna a lokalizace, síť a DNS, oprávnění, limity zdrojů a rozdíly v buildu nebo bundlování. Seřaď podle pravděpodobnosti vzhledem k příznaku a u každé mi dej diagnostický příkaz.

4. Vysvětli opravu, než ji použiju

Vysvětli, proč tato oprava funguje, co neopravuje a co by mohla rozbít. Pokud je skutečná příčina jinde a jde jen o záplatu na příznak, řekni to přímo.

Code review

5. Zkontroluj diff

Zkontroluj tento diff jako náročný reviewer. Kategorie v pořadí podle priority: chyby ve správnosti, bezpečnostní problémy, neošetřené selhání, race conditions a pak styl. U každého nálezu uveď závažnost, konkrétní řádek a proč je to důležité v tomto konkrétním kódu, ne obecně. Nekomentuj formátování. Pokud je diff v pořádku, řekni to, místo abys vymýšlel nálezy. Konvence: [popis]. Diff: [vlož].

6. Bezpečnostní kontrola

Zkontroluj tento kód konkrétně na bezpečnostní problémy: injection, mezery v autentizaci a autorizaci, nebezpečnou deserializaci, tajné klíče v kódu nebo logách, nevalidovaný vstup, který se dostane k citlivé operaci, a rizika závislostí. U každého uveď konkrétní útočnou cestu, ne jen název kategorie. Jasně napiš, co nejsi schopen posoudit bez [nasazení, vrstva autentizace, citlivost dat].

7. Audit možných selhání

U každého externího volání v tomto kódu popiš, co se stane, když je pomalé, když selže, když vrátí neočekávaná data a když uspěje jen částečně. Které z toho je aktuálně neošetřené a které by proběhlo tiše?

Ten poslední najde víc reálných problémů z produkce než obecná revize, protože se ptá na cesty, na které nikdo nenapsal test.

Refaktoring a architektura

8. Plán refaktoringu

Navrhni postupný plán, jak refaktorovat [popis]. Omezení: veřejné API [x] se nemůže změnit, nasazujeme kontinuálně, takže každý krok musí být samostatně nasaditelný, a po každém kroku musí testy procházet. U každého kroku uveď změnu, riziko, jak ji ověřit a jak ji vrátit zpět. Seřaď podle rizika, od nejnižšího. Kód ještě nepiš.

9. Obhaj druhou stranu

Vybírám [přístup A] před [přístup B] pro [kontext a omezení]. Předlož nejsilnější argumenty pro B. Co by musela splňovat naše omezení, aby bylo B správně, a platí u nás něco z toho? Nedocházej k závěru, že jsou obě varianty stejně dobré.

10. Pochop, co jsi zdědil

Tady jsou hlavní zdrojové soubory. Vytvoř: vstupní body, tok dat od požadavku k odpovědi, stav, který je sdílený, a kde se mění, externí závislosti a co se stane, když každá z nich není dostupná, a tři oblasti, kde nejpravděpodobněji jsou chyby na základě složitosti a provázanosti. Výslovně napiš, co nejsi schopen určit z toho, co jsem poskytl.

Ta poslední instrukce je důležitá. Modely popíšou chování souboru, který jste nevložili, jen odhadem z jeho názvu. Vynucený výslovný seznam nejasností vám řekne, co si máte přečíst.

Testy

11. Testy, které byste nenapsali

Napiš testovací případy pro tuto funkci se zaměřením na vstupy, které jsem pravděpodobně nezvážil: hraniční hodnoty, prázdné a null hodnoty, unicode, velmi velké hodnoty, souběžná volání a jakékoli implicitní předpoklady v implementaci. U každého testu napiš, jaký předpoklad ověřuje. Funkce: [vlož].

12. Prověř testovací sadu

Tady je funkce a její stávající testy. Jaké chování není pokryté? Konkrétně: chybové cesty, hraniční hodnoty, interakce mezi parametry a cokoli, co implementace dělá, ale žádný test to neověřuje. Stávající testy nepřepisuj.

Ten druhý prompt má vyšší hodnotu, a přitom se používá zřídka. Procenta pokrytí vám řeknou, které řádky se vykonaly, ne které chování je skutečně ošetřené, a přesně v tomto rozdílu žijí regrese.

Postup druhého názoru

Nejúčinnější zvyk z celého tohoto balíčku, a jediný, který vyžaduje víc než jeden model.

Získejte odpověď od jednoho modelu. Pak přepněte a předejte ji dál:

Jiný vývojář navrhl toto řešení tohoto problému. Najdi, co na něm je špatně: správnost v hraničních případech, souběžnost, zpracování chyb, výkon při [rozsah], nebo jednodušší přístup, který byl přehlédnut. Pokud je opravdu v pořádku, řekni to jasně, místo abys vymýšlel výhrady. Problém: [vlož]. Navrhované řešení: [vlož].

Existují dva výsledky a oba jsou užitečné. Buď druhý model najde skutečnou trhlinu, o které teď víte ještě před sloučením, nebo souhlasí i přesto, že byl vyzván k nesouhlasu, což je smysluplné potvrzení. Iterování se stejným modelem vám nedá ani jedno, protože model, který posuzuje svůj vlastní výstup, s ním většinou souhlasí.

Použijte to na rozhodnutí, u kterých by byla chyba nákladná: změna schématu, oprava souběžnosti, cokoli, co se týká autentizace nebo peněz. Ne na běžnou práci. Celý postup na jednom místě najdete v porovnání modelů vedle sebe, přepínání modelů uprostřed konverzace a psaní a debugování kódu s více modely.

Na co si dát pozor

Vymyšlená API. Sebevědomě znějící názvy metod, parametrů a konfiguračních klíčů, které neexistují, obzvlášť u knihoven, které se nedávno změnily. Signatura bude vypadat správně. Než na něčem neznámém začnete stavět, ověřte to v reálné dokumentaci.

Žádný signál jistoty. Správná oprava a jemně chybná oprava přijdou se stejnou jistotou v tónu. Tón vám nic neřekne.

Tichý rozšiřující se rozsah. Přesně na to existuje druhá zásada.

Bezpečnostní divadlo. Vyjmenování kategorií zranitelností ve vašem kódu je užitečný první průchod. Není to audit, a model nezná váš model hrozeb, nasazení ani citlivost dat.

Prompty, které používáte každý týden, mějte uložené někde, odkud je můžete zkopírovat, a trvalá omezení vložte do instrukcí projektu, aby platila automaticky pro každý chat v tomto projektu.