Pacchetto di prompt Claude per debug, refactoring e revisioni architetturali

I quattro vincoli che fanno funzionare ogni prompt qui sotto

Prima dei prompt, le regole che condividono tutti. Aggiungerle a qualsiasi prompt di coding migliora l'output più di quanto faccia cambiare modello.

Indica la tua versione. I dati di addestramento sono sbilanciati verso la versione principale su cui si è scritto di più, che spesso non è quella che stai usando. Usiamo [framework] [versione], [linguaggio] [versione] previene la maggior parte delle risposte obsolete.

Limita il diff. Chiedi una correzione e spesso ottieni un refactoring. Cambia il meno possibile, mantieni struttura e nomi esistenti, ed elenca ogni riga modificata con una motivazione di una riga è la frase più utile di questo documento.

Chiedi ipotesi prima delle soluzioni. Un modello a cui chiedi cosa non va ti dà un'ipotesi presentata come conclusione. Un modello a cui chiedi cause ordinate per probabilità e controlli economici ti dà un piano di debug.

Richiedi la modalità di guasto. Cosa potrebbe rompere questo, e sta risolvendo la causa o il sintomo? intercetta la classe di assistenza AI più costosa, cioè una modifica che fa sparire il sintomo mentre il difetto resta.

Debug

1. Ipotesi ordinate per probabilità

Ecco l'errore, il codice rilevante e cosa ho già escluso. Non darmi ancora una correzione. Elenca le quattro cause più probabili ordinate per probabilità, e per ciascuna il controllo più economico che la confermerebbe o la escluderebbe. Errore: [incolla]. Codice: [incolla]. Già escluso: [elenco]. Stack: [linguaggio, framework, versioni].

2. Il bug intermittente

Questo fallisce in modo intermittente, circa [frequenza], in condizioni [condizioni]. Elenca le categorie di guasto intermittente che potrebbero produrre questo sintomo specifico: tempistiche, ordinamento, esaurimento delle risorse, una dipendenza esterna, stato che trapela tra esecuzioni, orario o fuso orario, caching. Per ciascuna, dimmi cosa nel codice la conferma o la contraddice, ed esattamente cosa dovrei loggare per distinguerle. Codice: [incolla].

3. Funziona in locale

Questo funziona in locale e fallisce in [ambiente]. Elenca ogni categoria di differenza tra ambienti che potrebbe causare questo sintomo specifico: configurazione, variabili d'ambiente, versioni, filesystem e sensibilità alle maiuscole, fuso orario e locale, rete e DNS, permessi, limiti di risorse, differenze di build o bundling. Ordina per probabilità dato il sintomo, e dammi il comando diagnostico per ciascuna.

4. Spiega la correzione prima che io la applichi

Spiega perché questa correzione funziona, cosa non risolve, e cosa potrebbe rompere. Se la causa reale è altrove e questa è una toppa sul sintomo, dillo apertamente.

Code review

5. Rivedi un diff

Rivedi questo diff come un revisore esigente. Categorie in ordine di priorità: bug di correttezza, problemi di sicurezza, modalità di guasto non gestite, race condition, poi stile. Per ogni rilievo dai gravità, la riga specifica, e perché conta in questa codebase e non in generale. Non commentare la formattazione. Se il diff è solido, dillo invece di inventare rilievi. Convenzioni: [descrivi]. Diff: [incolla].

6. Il passaggio sulla sicurezza

Rivedi questo codice specificamente per problemi di sicurezza: injection, lacune di autenticazione e autorizzazione, deserializzazione non sicura, segreti nel codice o nei log, input non validato che raggiunge un'operazione sensibile, e rischio delle dipendenze. Per ciascuno, dai il percorso di attacco in modo concreto invece di nominare solo la categoria. Dichiara chiaramente cosa non puoi valutare senza vedere [deployment, livello di autenticazione, sensibilità dei dati].

7. L'audit delle modalità di guasto

Per ogni chiamata esterna in questo codice, indica cosa succede quando è lenta, quando fallisce, quando restituisce dati inattesi, e quando ha successo ma solo in parte. Quali di questi casi non sono attualmente gestiti, e quali sarebbero silenziosi?

Quest'ultimo trova più problemi reali di produzione di una revisione generica, perché chiede dei percorsi per cui nessuno ha scritto un test.

Refactoring e architettura

8. Il piano di refactoring

Proponi un piano sequenziale per rifattorizzare [descrizione]. Vincoli: l'API pubblica di [x] non può cambiare, distribuiamo continuamente quindi ogni passo deve essere rilasciabile in modo indipendente, e i test devono passare dopo ogni passo. Per ogni passo dai la modifica, il rischio, come verificarlo, e come annullarlo. Ordina per rischio, dal più basso. Non scrivere ancora il codice.

9. Argomenta l'altra posizione

Sto scegliendo [approccio A] rispetto a [approccio B] per [contesto e vincoli]. Costruisci il caso più forte a favore di B. Cosa dovrebbe essere vero riguardo ai nostri vincoli perché B sia corretto, e qualcosa di tutto ciò è vero qui? Non concludere che entrambi sono validi.

10. Capisci cosa hai ereditato

Ecco i file sorgente principali. Produci: i punti di ingresso, il flusso dei dati dalla richiesta alla risposta, lo stato condiviso e dove viene modificato, le dipendenze esterne e cosa succede quando ciascuna non è disponibile, e le tre aree più probabilmente contenenti bug in base a complessità e accoppiamento. Dichiara esplicitamente cosa non puoi determinare da quanto ti ho fornito.

Quest'ultima istruzione conta. I modelli descriveranno il comportamento di un file che non hai incollato, inferendolo dal nome. Forzare un elenco esplicito di incognite ti dice cosa andare a leggere.

Test

11. I test che non avresti scritto

Scrivi casi di test per questa funzione, concentrandoti su input che probabilmente non ho considerato: confini, valori vuoti e null, unicode, valori molto grandi, chiamate concorrenti, e qualsiasi assunzione implicita nell'implementazione. Per ogni test, dichiara l'assunzione che sta verificando. Funzione: [incolla].

12. Metti alla prova la suite di test

Ecco una funzione e i suoi test esistenti. Quale comportamento non è coperto? Nello specifico: percorsi di errore, valori limite, interazioni tra parametri, e qualsiasi cosa faccia l'implementazione che nessun test verifica. Non riscrivere i test esistenti.

Il secondo è il prompt di maggior valore ed è raramente usato. Le percentuali di copertura ti dicono quali righe sono state eseguite, non quali comportamenti sono davvero verificati, e il divario tra i due è dove vivono le regressioni.

Lo schema del secondo parere

L'abitudine a maggior leva di tutto questo pacchetto, e quella che richiede più di un modello.

Ottieni una risposta da un modello. Poi cambia e passala così:

Un altro ingegnere ha proposto questa soluzione a questo problema. Trova cosa non va: correttezza nei casi limite, concorrenza, gestione degli errori, prestazioni a [scala], oppure un approccio più semplice che è stato tralasciato. Se è genuinamente valida, dillo apertamente invece di inventare obiezioni. Problema: [incolla]. Soluzione proposta: [incolla].

Due esiti, ed entrambi sono utili. O il secondo modello trova una falla reale, che ora conosci prima del merge, oppure concorda nonostante sia stato spinto a dissentire, il che è una conferma significativa. Iterare con lo stesso modello non ti dà nessuno dei due, perché un modello che rivede il proprio output tende a concordare con se stesso.

Usalo sulle decisioni che sarebbe costoso sbagliare: una modifica dello schema, una correzione di concorrenza, qualsiasi cosa che tocchi autenticazione o denaro. Non sul lavoro di routine. Consulta confrontare modelli fianco a fianco, cambiare modello a metà conversazione e scrivere e fare debug del codice con più modelli per il flusso completo in un unico posto.

A cosa fare attenzione

API inventate. Nomi di metodi, parametri e chiavi di configurazione presentati con sicurezza ma inesistenti, specialmente per librerie cambiate di recente. La firma sembrerà corretta. Controlla la documentazione reale prima di costruire su qualcosa di poco familiare.

Nessun segnale di affidabilità. Una correzione giusta e una sottilmente sbagliata arrivano con identica sicurezza. Il tono non ti dice nulla.

Scope creep silenzioso. È esattamente per questo che esiste il secondo vincolo.

Teatro della sicurezza. Nominare classi di vulnerabilità nel tuo codice è un primo passaggio utile. Non è un audit, e il modello non conosce il tuo modello di minaccia, il deployment, o la sensibilità dei dati.

Tieni i prompt che usi ogni settimana in un posto da cui puoi copiarli, e metti i vincoli permanenti nelle istruzioni di un progetto così si applicano automaticamente a ogni chat di quel progetto.