Claude-promptpakke for koding: debugging, refaktorering og arkitekturgjennomganger

De fire begrensningene som gjør alle promptene nedenfor til noe som virker

Før promptene, reglene de alle deler. Å legge disse til i en kodeprompt forbedrer outputen mer enn å bytte modell.

Angi versjonen din. Treningsdata er skjevt mot hvilken hovedversjon det er skrevet mest om, som ofte ikke er den du bruker. Vi bruker [rammeverk] [versjon], [språk] [versjon] forhindrer de fleste utdaterte svar.

Avgrens diffen. Ber du om en fiks, får du ofte en refaktorering. Endre så lite som mulig, bevar eksisterende struktur og navngiving, og list opp hver linje du endret med en enlinjes begrunnelse er den mest nyttige setningen i dette dokumentet.

Be om hypoteser før løsninger. En modell spurt om hva som er feil, gir en gjetning levert som en konklusjon. En modell spurt om rangerte årsaker og billige sjekker gir deg en debuggingsplan.

Krev feilmoduset. Hva kan dette ødelegge, og fikser dette årsaken eller symptomet? fanger opp den mest kostbare typen AI-hjelp, en endring som får symptomet til å forsvinne mens defekten blir igjen.

Debugging

1. Rangerte hypoteser

Her er feilen, den relevante koden og det jeg allerede har utelukket. Ikke gi meg en fiks ennå. List de fire mest sannsynlige årsakene rangert etter sannsynlighet, og for hver den billigste sjekken som ville bekrefte eller eliminere den. Feil: [lim inn]. Kode: [lim inn]. Allerede utelukket: [list]. Stack: [språk, rammeverk, versjoner].

2. Den periodiske feilen

Dette feiler periodisk, omtrent [frekvens], under [forhold]. List kategoriene av periodiske feil som kan gi dette spesifikke symptomet: timing, rekkefølge, ressursuttømming, en ekstern avhengighet, tilstand som lekker mellom kjøringer, klokke eller tidssone, caching. For hver, si hva i koden som støtter eller motsier den, og nøyaktig hva jeg bør logge for å skille dem. Kode: [lim inn].

3. Det virker lokalt

Dette virker lokalt og feiler i [miljø]. List hver kategori av miljøforskjell som kan forårsake dette spesifikke symptomet: konfigurasjon, miljøvariabler, versjoner, filsystem og skille mellom store og små bokstaver, tidssone og lokalitet, nettverk og DNS, tillatelser, ressursgrenser, og forskjeller i bygg eller pakking. Rangér etter sannsynlighet gitt symptomet, og gi meg diagnosekommandoen for hver.

4. Forklar fiksen før jeg tar den

Forklar hvorfor denne fiksen virker, hva den ikke fikser, og hva den kan ødelegge. Hvis den virkelige årsaken er et annet sted og dette er en symptomlapp, si det direkte.

Kodegjennomgang

5. Gjennomgå en diff

Gjennomgå denne diffen som en krevende reviewer. Kategorier i prioritert rekkefølge: korrekthetsfeil, sikkerhetsproblemer, uhåndterte feilmoduser, race conditions, deretter stil. For hvert funn, gi alvorlighetsgrad, den spesifikke linjen, og hvorfor det er viktig i denne kodebasen snarere enn generelt. Kommenter ikke formatering. Hvis diffen er solid, si det i stedet for å produsere funn. Konvensjoner: [beskriv]. Diff: [lim inn].

6. Sikkerhetsgjennomgangen

Gjennomgå denne koden spesifikt for sikkerhetsproblemer: injeksjon, mangler i autentisering og autorisasjon, usikker deserialisering, hemmeligheter i kode eller logger, uvalidert input som når en sensitiv operasjon, og avhengighetsrisiko. For hver, gi angrepsveien konkret i stedet for å bare navngi kategorien. Angi klart hva du ikke kan vurdere uten å se [distribusjon, autentiseringslag, datasensitivitet].

7. Feilmodusrevisjonen

For hvert eksterne kall i denne koden, angi hva som skjer når det er langsomt, når det feiler, når det returnerer uventet data, og når det lykkes, men bare delvis. Hvilke av disse er for øyeblikket uhåndterte, og hvilke ville være stille?

Den siste finner flere reelle produksjonsproblemer enn en generell gjennomgang gjør, fordi den spør om stiene ingen skrev en test for.

Refaktorering og arkitektur

8. Refaktoreringsplanen

Foreslå en sekvensert plan for å refaktorere [beskrivelse]. Begrensninger: det offentlige API-et til [x] kan ikke endres, vi distribuerer kontinuerlig så hvert trinn må kunne leveres uavhengig, og testene må bestå etter hvert trinn. For hvert trinn, gi endringen, risikoen, hvordan verifisere den, og hvordan rulle den tilbake. Ordne etter risiko, lavest først. Skriv ikke koden ennå.

9. Argumenter for den andre siden

Jeg velger [løsning A] over [løsning B] for [kontekst og begrensninger]. Lag den sterkeste saken for B. Hva måtte vært sant om våre begrensninger for at B skulle være riktig, og er noe av det sant her? Konkluder ikke med at begge er gyldige.

10. Forstå hva du har fått i arv

Her er hovedkildefilene. Produser: inngangspunktene, dataflyten fra forespørsel til svar, tilstanden som deles og hvor den muteres, eksterne avhengigheter og hva som skjer når hver er utilgjengelig, og de tre områdene som mest sannsynlig inneholder feil basert på kompleksitet og kobling. Angi eksplisitt hva du ikke kan avgjøre fra det jeg har gitt.

Den siste instruksjonen betyr noe. Modeller vil beskrive oppførselen til en fil du ikke limte inn, utledet fra navnet. Å tvinge en eksplisitt liste over ukjente forteller deg hva du bør gå og lese.

Tester

11. Testene du ikke ville skrevet

Skriv testcaser for denne funksjonen, med fokus på input jeg sannsynligvis ikke har tenkt på: grenseverdier, tom og null, unicode, veldig store verdier, samtidige kall, og enhver implisitt antagelse i implementasjonen. For hver test, angi antagelsen den sjekker. Funksjon: [lim inn].

12. Test testsuiten

Her er en funksjon og dens eksisterende tester. Hvilken oppførsel er ikke dekket? Spesifikt: feilstier, grenseverdier, interaksjoner mellom parametere, og alt implementasjonen gjør som ingen test verifiserer. Skriv ikke om de eksisterende testene.

Den andre er den mer verdifulle prompten, og den kjøres sjeldent. Dekningsprosenter forteller deg hvilke linjer som ble kjørt, ikke hvilken oppførsel som faktisk er sikret, og gapet mellom disse er der regresjoner lever.

Mønsteret for et andre synspunkt

Den vanen med høyest verdi i hele denne pakken, og den som krever mer enn én modell.

Få et svar fra en modell. Deretter bytter du og gir den videre:

En annen utvikler foreslo denne løsningen på dette problemet. Finn hva som er feil med den: korrekthet under edge cases, samtidighet, feilhåndtering, ytelse ved [skala], eller en enklere tilnærming som ble oversett. Hvis den er genuint solid, si det tydelig i stedet for å finne opp innvendinger. Problem: [lim inn]. Foreslått løsning: [lim inn].

To utfall, og begge er nyttige. Enten finner den andre modellen et reelt hull, som du nå vet om før merge, eller den er enig selv om den ble presset til å være uenig, som er en meningsfull bekreftelse. Å iterere med samme modell gir deg ingen av dem, fordi en modell som gjennomgår sin egen output i stor grad er enig med seg selv.

Bruk det på beslutningene som ville vært kostbare å ta feil: en skjemaendring, en samtidighetsfiks, alt som berører autentisering eller penger. Ikke på rutinearbeid. Se sammenligning av modeller side ved side, bytte modeller midt i en samtale, og skriv og feilsøk kode med flere modeller for hele arbeidsflyten på ett sted.

Hva du bør se opp for

Oppfunne API-er. Selvsikre metodenavn, parametere og konfigurasjonsnøkler som ikke finnes, spesielt for biblioteker som ble endret nylig. Signaturen vil se riktig ut. Sjekk den virkelige dokumentasjonen før du bygger på noe ukjent.

Ingen sikkerhetssignal. En riktig fiks og en subtilt feil fiks kommer med identisk sikkerhet i tonen. Tonen forteller deg ingenting.

Stille scope creep. Dette er hva begrensning to finnes for.

Sikkerhetsteater. Å navngi sårbarhetsklasser i koden din er en nyttig første gjennomgang. Det er ikke en revisjon, og modellen kjenner ikke din trusselmodell, distribusjon eller datasensitivitet.

Hold promptene du bruker ukentlig et sted du kan lime fra, og legg stående begrensninger i et prosjekts instruksjoner slik at de gjelder for hver chat i det prosjektet automatisk.