Claude coding prompts til debugging, refaktorering og arkitekturgennemgange

De fire regler, der får alle prompts nedenfor til at virke

Før selve prompts, reglerne de alle deler. Tilføjer du disse til enhver kodeprompt, forbedrer det outputtet mere end at skifte model.

Angiv din version. Træningsdata skævvrider mod den major-version, der er skrevet mest om, hvilket ofte ikke er den du bruger. Vi bruger [framework] [version], [sprog] [version] forhindrer de fleste forældede svar.

Begræns diffen. Bed om en fix, og du får ofte en refaktorering. Ret så lidt som muligt, bevar eksisterende struktur og navngivning, og angiv hver linje du ændrede med en enkelt begrundelse er den mest nyttige sætning i dette dokument.

Bed om hypoteser før løsninger. En model, der bliver spurgt hvad der er forkert, giver dig et gæt fremsat som en konklusion. En model, der bliver spurgt om rangerede årsager og billige checks, giver dig en debugging-plan.

Kræv fejlmåden. Hvad kunne dette gå i stykker, og retter det årsagen eller symptomet? fanger den dyreste type AI-hjælp, nemlig en ændring der får symptomet til at forsvinde, mens defekten forbliver.

Debugging

1. Rangerede hypoteser

Her er fejlen, den relevante kode, og hvad jeg allerede har udelukket. Giv mig ikke en fix endnu. List de fire mest sandsynlige årsager rangeret efter sandsynlighed, og for hver den enkelte billigste check, der ville bekræfte eller udelukke den. Fejl: [indsæt]. Kode: [indsæt]. Allerede udelukket: [liste]. Stack: [sprog, framework, versioner].

2. Den periodiske fejl

Dette fejler periodisk, cirka [hyppighed], under [forhold]. Opstil kategorierne af periodisk fejl, der kunne give dette specifikke symptom: timing, ordning, ressourceudtømning, en ekstern afhængighed, state der lækker mellem kørsler, tidszone eller ur, caching. For hver, sig hvad i koden der støtter eller modsiger den, og hvad jeg præcis bør logge for at skelne dem. Kode: [indsæt].

3. Det virker lokalt

Dette virker lokalt og fejler i [miljø]. List hver kategori af miljøforskel, der kunne give dette specifikke symptom: konfiguration, miljøvariabler, versioner, filsystem og case-sensitivitet, tidszone og locale, netværk og DNS, rettigheder, ressourcegrænser og forskelle i build eller bundling. Ranger efter sandsynlighed givet symptomet, og giv mig diagnosekommandoen for hver.

4. Forklar fixet, før jeg tager det

Forklar hvorfor dette fix virker, hvad det ikke fikser, og hvad det kan gå i stykker. Hvis den egentlige årsag ligger et andet sted, og dette er en symptombehandling, så sig det direkte.

Code review

5. Gennemgå en diff

Gennemgå denne diff som en krævende reviewer. Kategorier i prioriteret orden: korrekthedsfejl, sikkerhedsproblemer, uhåndterede fejltilstande, race conditions, derefter stil. For hvert fund, giv sværhedsgrad, den specifikke linje, og hvorfor det betyder noget i denne kodebase snarere end generelt. Kommenter ikke på formatering. Er diffen god, så sig det i stedet for at opfinde fund. Konventioner: [beskriv]. Diff: [indsæt].

6. Sikkerhedsgennemgangen

Gennemgå denne kode specifikt for sikkerhedsproblemer: injection, huller i autentificering og autorisation, usikker deserialisering, secrets i kode eller logs, uvalideret input der når en sensitiv operation, og afhængighedsrisiko. For hver, giv angrebsvejen konkret i stedet for blot at nævne kategorien. Angiv klart, hvad du ikke kan vurdere uden at se [deployment, autentificeringslag, datasensitivitet].

7. Gennemgang af fejltilstande

For hvert eksternt kald i denne kode, angiv hvad der sker når det er langsomt, når det fejler, når det returnerer uventet data, og når det lykkes men kun delvist. Hvilke af disse er i øjeblikket uhåndterede, og hvilke ville være tavse?

Den sidste finder flere rigtige produktionsproblemer end en generel gennemgang, fordi den spørger om de veje, ingen skrev en test til.

Refaktorering og arkitektur

8. Refaktoreringsplanen

Foreslå en trinvis plan for at refaktorere [beskrivelse]. Begrænsninger: det offentlige API for [x] kan ikke ændres, vi deployer løbende så hvert trin skal kunne shippes uafhængigt, og tests skal bestå efter hvert trin. For hvert trin, giv ændringen, risikoen, hvordan man verificerer den, og hvordan man ruller den tilbage. Sorter efter risiko, lavest først. Skriv ikke koden endnu.

9. Argumenter for den anden side

Jeg vælger [løsning A] over [løsning B] til [kontekst og begrænsninger]. Fremfør det stærkeste argument for B. Hvad skulle være sandt om vores begrænsninger for at B var korrekt, og er noget af det sandt her? Konkludér ikke, at begge er gyldige.

10. Forstå hvad du har overtaget

Her er hovedkildefilerne. Producer: entry points, datastrømmen fra request til response, den state der deles og hvor den muteres, eksterne afhængigheder og hvad der sker når hver er utilgængelig, og de tre områder mest sandsynlige for at indeholde fejl baseret på kompleksitet og kobling. Angiv tydeligt, hvad du ikke kan afgøre fra det jeg har givet.

Den sidste instruks betyder noget. Modeller vil beskrive adfærden af en fil, du ikke indsatte, udledt af dens navn. At tvinge en tydelig liste af ukendte fortæller dig, hvad du skal gå og læse.

Tests

11. De tests du ikke ville have skrevet

Skriv testcases for denne funktion, med fokus på input jeg sandsynligvis ikke har overvejet: grænser, tom og null, unicode, meget store værdier, samtidige kald, og enhver implicit antagelse i implementeringen. For hver test, angiv den antagelse den tjekker. Funktion: [indsæt].

12. Test testpakken

Her er en funktion og dens eksisterende tests. Hvilken adfærd er ikke dækket? Specifikt: fejlveje, grænseværdier, interaktioner mellem parametre, og alt hvad implementeringen gør, som ingen test tjekker. Omskriv ikke de eksisterende tests.

Den anden er den mest værdifulde prompt, og den bliver sjældent kørt. Dækningsprocenter viser hvilke linjer der blev udført, ikke hvilken adfærd der faktisk er sikret, og forskellen mellem de to er hvor regressioner lever.

Second opinion-mønstret

Vanen med størst udbytte i hele denne pakke, og den eneste der kræver mere end én model.

Få et svar fra en model. Skift derefter og giv det videre:

En anden udvikler foreslog denne løsning på dette problem. Find hvad der er forkert med den: korrekthed under edge cases, samtidighed, fejlhåndtering, performance ved [skala], eller en simplere tilgang der blev overset. Er den virkelig god, så sig det klart i stedet for at opfinde indvendinger. Problem: [indsæt]. Foreslået løsning: [indsæt].

To udfald, og begge er nyttige. Enten finder den anden model et reelt hul, hvilket du nu kender inden du merger, eller den er enig på trods af at være skubbet til at være uenig, hvilket er en meningsfuld bekræftelse. At iterere med samme model giver dig ingen af de to, fordi en model der gennemgår sit eget output stort set er enig med sig selv.

Brug det på de beslutninger, der ville være dyre at få forkert: en skemaændring, en samtidighedsfix, noget der rører auth eller penge. Ikke på rutineopgaver. Se sammenligning af modeller side by side, skift af modeller midt i en samtale, og skriv og fejlret kode med flere modeller for hele arbejdsgangen ét sted.

Hvad du skal holde øje med

Opfundne API'er. Sikre metodenavne, parametre og konfigurationsnøgler, der ikke findes, især for biblioteker der er ændret for nylig. Signaturen ser rigtig ud. Tjek den rigtige dokumentation, før du bygger på noget ukendt.

Intet sikkerhedssignal. En korrekt fix og en subtilt forkert ankommer med identisk sikkerhed i tonen. Tonen fortæller dig ingenting.

Tavs scope creep. Det er derfor regel to findes.

Sikkerhedsteater. At nævne sårbarhedskategorier i din kode er en nyttig første omgang. Det er ikke en audit, og modellen kender ikke din trusselsmodel, deployment eller datasensitivitet.

Gem de prompts du bruger ugentligt et sted du kan indsætte fra, og læg stående begrænsninger i et projekts instruktioner, så de gælder for hver chat i det projekt automatisk.