Claude coding prompts för felsökning, refaktorering och arkitekturgranskning

De fyra reglerna som gör varje prompt nedan användbar

Innan prompterna, reglerna de alla delar. Att lägga till dessa i en kodningsprompt förbättrar resultatet mer än att byta modell.

Ange din version. Träningsdata lutar mot vilken huvudversion som skrivits mest om, vilket ofta inte är den du använder. Vi kör [ramverk] [version], [språk] [version] förhindrar de flesta föråldrade svaren.

Begränsa diffen. Be om en fix och du får ofta en refaktorering. Ändra så lite som möjligt, behåll befintlig struktur och namngivning, och lista varje rad du ändrat med en rads motivering är den mest användbara meningen i hela dokumentet.

Be om hypoteser innan lösningar. En modell som får frågan vad som är fel ger dig en gissning framförd som en slutsats. En modell som ombeds ge rangordnade orsaker och billiga kontroller ger dig en felsökningsplan.

Kräv felläget. Vad kan detta gå sönder, och löser detta orsaken eller symptomet? fångar den dyraste formen av AI-hjälp, en ändring som får symptomet att försvinna medan defekten finns kvar.

Felsökning

1. Rangordnade hypoteser

Här är felet, den relevanta koden och vad jag redan uteslutit. Ge mig inte en fix ännu. Lista de fyra mest sannolika orsakerna rangordnade efter sannolikhet, och för varje den enklaste kontrollen som skulle bekräfta eller utesluta den. Fel: [klistra in]. Kod: [klistra in]. Redan uteslutet: [lista]. Stack: [språk, ramverk, versioner].

2. Den intermittenta buggen

Detta fallerar med jämna mellanrum, ungefär [frekvens], under [villkor]. Räkna upp kategorierna av intermittenta fel som kan ge just detta symptom: timing, ordning, resursutmattning, ett externt beroende, tillstånd som läcker mellan körningar, klocka eller tidszon, cachning. För varje, säg vad i koden som stödjer eller motsäger det, och exakt vad jag ska logga för att skilja dem åt. Kod: [klistra in].

3. Det funkar lokalt

Detta fungerar lokalt och fallerar i [miljö]. Lista varje kategori av miljöskillnad som kan orsaka just detta symptom: konfiguration, miljövariabler, versioner, filsystem och skiftlägeskänslighet, tidszon och språkinställning, nätverk och DNS, behörigheter, resursgränser och skillnader i bygg eller bundling. Rangordna efter sannolikhet givet symptomet, och ge mig diagnostikkommandot för varje.

4. Förklara fixen innan jag använder den

Förklara varför denna fix fungerar, vad den inte fixar och vad den kan gå sönder. Om den verkliga orsaken finns någon annanstans och detta är en symptomlappning, säg det rakt ut.

Kodgranskning

5. Granska en diff

Granska den här diffen som en krävande granskare. Kategorier i prioritetsordning: korrekthetsbuggar, säkerhetsproblem, ohanterade fellägen, race conditions, sedan stil. För varje fynd, ange allvarlighetsgrad, den specifika raden och varför det spelar roll i den här kodbasen snarare än i allmänhet. Kommentera inte formatering. Om diffen är sund, säg det istället för att uppfinna fynd. Konventioner: [beskriv]. Diff: [klistra in].

6. Säkerhetsgenomgången

Granska den här koden specifikt för säkerhetsproblem: injektion, luckor i autentisering och auktorisering, osäker deserialisering, hemligheter i kod eller loggar, ovaliderad indata som når en känslig operation, och beroenderisk. För varje, ge attackvägen konkret snarare än att bara namnge kategorin. Ange tydligt vad du inte kan bedöma utan att se [driftmiljö, autentiseringslager, datakänslighet].

7. Genomgången av fellägen

För varje extern anrop i den här koden, ange vad som händer när det är långsamt, när det misslyckas, när det returnerar oväntad data, och när det lyckas men delvis. Vilka av dessa är ohanterade just nu, och vilka skulle vara tysta?

Den sista hittar fler verkliga produktionsproblem än en allmän granskning gör, eftersom den frågar om de vägar ingen skrev ett test för.

Refaktorering och arkitektur

8. Refaktoreringsplanen

Föreslå en sekvenserad plan för att refaktorera [beskrivning]. Villkor: det publika API:et för [x] får inte ändras, vi driftsätter kontinuerligt så varje steg måste kunna levereras oberoende, och tester måste passera efter varje steg. För varje steg, ange ändringen, risken, hur man verifierar den och hur man rullar tillbaka den. Ordna efter risk, lägst först. Skriv inte koden ännu.

9. Argumentera för den andra sidan

Jag väljer [alternativ A] över [alternativ B] för [kontext och villkor]. Framför den starkaste möjliga sak för B. Vad skulle behöva vara sant om våra villkor för att B ska vara rätt, och är något av det sant här? Dra inte slutsatsen att båda är giltiga.

10. Förstå vad du ärvt

Här är huvudkällfilerna. Ta fram: ingångspunkterna, dataflödet från förfrågan till svar, tillståndet som delas och var det muteras, externa beroenden och vad som händer när varje inte är tillgängligt, och de tre områden som mest sannolikt innehåller buggar utifrån komplexitet och koppling. Ange explicit vad du inte kan avgöra från det jag gett dig.

Den sista instruktionen är viktig. Modeller kommer att beskriva beteendet hos en fil du inte klistrat in, härlett från dess namn. Att tvinga fram en explicit lista med okända ting talar om vad du ska läsa.

Tester

11. Testerna du inte skulle ha skrivit

Skriv testfall för den här funktionen, med fokus på indata jag förmodligen inte tänkt på: gränsvärden, tomt och null, unicode, mycket stora värden, samtidiga anrop, och alla implicita antaganden i implementationen. För varje test, ange antagandet det testar. Funktion: [klistra in].

12. Testa testsviten

Här är en funktion och dess befintliga tester. Vilket beteende täcks inte? Specifikt: felvägar, gränsvärden, interaktioner mellan parametrar, och allt implementationen gör som inget test kontrollerar. Skriv inte om de befintliga testerna.

Den andra är den mer värdefulla prompten och den körs sällan. Täckningsprocent visar vilka rader som exekverades, inte vilka beteenden som faktiskt är fastställda, och gapet mellan dessa två är där regressioner lever.

Mönstret för en andra åsikt

Den mest lönsamma vanan i hela paketet, och den enda som kräver mer än en modell.

Få ett svar från en modell. Byt sedan och lämna över det:

En annan utvecklare föreslog denna lösning på det här problemet. Hitta vad som är fel med den: korrekthet vid gränsfall, samtidighet, felhantering, prestanda vid [skala], eller ett enklare tillvägagångssätt som missats. Om den verkligen är sund, säg det rakt ut istället för att uppfinna invändningar. Problem: [klistra in]. Föreslagen lösning: [klistra in].

Två utfall och båda är användbara. Antingen hittar den andra modellen ett verkligt hål, vilket du nu vet innan du mergar, eller den håller med trots att den drivits att vara oenig, vilket är meningsfull bekräftelse. Att iterera med samma modell ger dig ingen av dessa, eftersom en modell som granskar sitt eget resultat mestadels håller med sig själv.

Använd det på beslut som skulle vara dyra att få fel: en schemaändring, en fix för samtidighet, allt som rör autentisering eller pengar. Inte på rutinarbete. Se jämföra modeller sida vid sida, byta modell mitt i en konversation och skriv och felsök kod med flera modeller för hela arbetsflödet på ett ställe.

Vad du ska hålla utkik efter

Uppfunna API:er. Självsäkra metodnamn, parametrar och konfigurationsnycklar som inte finns, särskilt för bibliotek som ändrats nyligen. Signaturen kommer att se rätt ut. Kontrollera den verkliga dokumentationen innan du bygger på något obekant.

Ingen säkerhetsindikator. En korrekt fix och en subtilt felaktig anländer med identisk säkerhet. Tonen säger dig ingenting.

Tyst scope creep. Det är detta den andra regeln finns till för.

Säkerhetsteater. Att namnge sårbarhetskategorier i din kod är en användbar första genomgång. Det är inte en granskning, och modellen känner inte till din hotmodell, driftmiljö eller datakänslighet.

Håll de prompts du använder varje vecka någonstans du kan klistra in från, och lägg stående villkor i ett projekts instruktioner så att de gäller automatiskt för varje chatt i det projektet.