Cele patru constrângeri care fac ca fiecare prompt de mai jos să funcționeze
Înainte de prompturi, regulile comune tuturor. Adăugarea acestora la orice prompt de programare îmbunătățește rezultatul mai mult decât schimbarea modelului.
Precizează-ți versiunea. Datele de antrenament sunt înclinate spre versiunea majoră despre care s-a scris cel mai mult, care de multe ori nu este cea pe care o folosești. Folosim [framework] [versiune], [limbaj] [versiune] previne majoritatea răspunsurilor învechite.
Limitează diff-ul. Ceri o remediere și primești adesea o refactorizare. Schimbă cât mai puțin posibil, păstrează structura și denumirile existente și listează fiecare linie modificată cu un motiv de o linie este cea mai utilă propoziție din acest document.
Cere ipoteze înainte de soluții. Un model întrebat ce este greșit îți oferă o presupunere prezentată drept concluzie. Un model căruia i se cer cauze ordonate și verificări ieftine îți oferă un plan de depanare.
Cere modul de eșec. Ce ar putea strica asta și această soluție rezolvă cauza sau simptomul? prinde cea mai costisitoare categorie de asistență AI: o schimbare care face simptomul să dispară, în timp ce defectul rămâne.
Depanare
1. Ipoteze ordonate
Iată eroarea, codul relevant și ce am exclus deja. Nu-mi da încă o remediere. Listează cele patru cauze cele mai probabile, ordonate după probabilitate, iar pentru fiecare cea mai ieftină verificare care ar confirma-o sau ar elimina-o. Eroare: [paste]. Cod: [paste]. Deja exclus: [listă]. Stack: [limbaj, framework, versiuni].
2. Bug-ul intermitent
Acest lucru eșuează intermitent, aproximativ [frecvență], în condițiile [condiții]. Enumeră categoriile de eșec intermitent care ar putea produce exact acest simptom: sincronizare, ordine, epuizarea resurselor, o dependență externă, stare care se scurge între rulări, ceas sau fus orar, caching. Pentru fiecare, spune ce din cod susține sau contrazice ipoteza și exact ce ar trebui să loghez pentru a le distinge. Cod: [paste].
3. Funcționează local
Funcționează local și eșuează în [mediu]. Listează fiecare categorie de diferență de mediu care ar putea cauza acest simptom specific: configurare, variabile de mediu, versiuni, sistem de fișiere și sensibilitate la majuscule, fus orar și localizare, rețea și DNS, permisiuni, limite de resurse și diferențe de build sau bundling. Ordonează după probabilitate în funcție de simptom și dă-mi comanda de diagnosticare pentru fiecare.
4. Explică remedierea înainte să o aplic
Explică de ce funcționează această remediere, ce nu rezolvă și ce ar putea strica. Dacă adevărata cauză este în altă parte și aceasta este doar un plasture pe simptom, spune-mi direct.
Revizuirea codului
5. Revizuiește un diff
Revizuiește acest diff ca un reviewer exigent. Categorii în ordinea priorității: bug-uri de corectitudine, probleme de securitate, moduri de eșec netratate, condiții de cursă (race conditions), apoi stilul. Pentru fiecare constatare, dă severitatea, linia exactă și de ce contează în acest cod, nu în general. Nu comenta formatarea. Dacă diff-ul este solid, spune asta în loc să inventezi constatări. Convenții: [descrie]. Diff: [paste].
6. Trecerea de securitate
Revizuiește acest cod specific pentru probleme de securitate: injecție, breșe de autentificare și autorizare, deserializare nesigură, secrete în cod sau loguri, intrare nevalidată care ajunge la o operație sensibilă și riscul dependențelor. Pentru fiecare, dă traseul concret de atac, nu doar numele categoriei. Spune clar ce nu poți evalua fără să vezi [deployment, stratul de autentificare, sensibilitatea datelor].
7. Auditul modurilor de eșec
Pentru fiecare apel extern din acest cod, spune ce se întâmplă când este lent, când eșuează, când returnează date neașteptate și când reușește doar parțial. Care dintre acestea sunt netratate în prezent și care ar trece neobservate?
Ultimul găsește mai multe probleme reale de producție decât o revizuire generală, pentru că întreabă despre căile pentru care nimeni nu a scris un test.
Refactorizare și arhitectură
8. Planul de refactorizare
Propune un plan secvențial pentru a refactoriza [descriere]. Constrângeri: API-ul public al [x] nu se poate schimba, facem deploy continuu, deci fiecare pas trebuie să poată fi livrat independent, iar testele trebuie să treacă după fiecare pas. Pentru fiecare pas, dă schimbarea, riscul, cum se verifică și cum se anulează. Ordonează după risc, de la cel mai mic. Nu scrie încă codul.
9. Argumentează partea opusă
Aleg [abordarea A] în locul [abordării B] pentru [context și constrângeri]. Construiește cel mai puternic argument pentru B. Ce ar trebui să fie adevărat despre constrângerile noastre pentru ca B să fie corectă și este ceva din asta adevărat aici? Nu concluziona că ambele sunt valide.
10. Înțelege ce ai moștenit
Iată fișierele sursă principale. Produ: punctele de intrare, fluxul de date de la cerere la răspuns, starea care este partajată și unde este modificată, dependențele externe și ce se întâmplă când fiecare este indisponibilă, precum și cele trei zone cel mai probabil să conțină bug-uri pe baza complexității și cuplării. Precizează explicit ce nu poți determina din ce ți-am oferit.
Această ultimă instrucțiune contează. Modelele vor descrie comportamentul unui fișier pe care nu l-ai lipit, dedus din numele lui. Forțarea unei liste explicite de necunoscute îți spune ce ar trebui să citești.
Teste
11. Testele pe care nu le-ai fi scris
Scrie cazuri de test pentru această funcție, concentrându-te pe intrări la care probabil nu m-am gândit: limite, valori goale și null, unicode, valori foarte mari, apeluri concurente și orice presupunere implicită din implementare. Pentru fiecare test, precizează presupunerea pe care o verifică. Funcție: [paste].
12. Testează suita de teste
Iată o funcție și testele ei existente. Ce comportament nu este acoperit? Concret: căile de eroare, valorile limită, interacțiunile dintre parametri și orice face implementarea pe care niciun test nu îl verifică. Nu rescrie testele existente.
Al doilea este promptul cu valoare mai mare și este rareori folosit. Procentele de acoperire îți spun ce linii au fost executate, nu ce comportamente sunt de fapt fixate, iar diferența dintre cele două este locul unde trăiesc regresiile.
Modelul „a doua opinie”
Obiceiul cu cel mai mare impact din tot acest pachet și singurul care necesită mai mult de un model.
Obține un răspuns de la un model. Apoi schimbă și predă-l mai departe:
Un alt inginer a propus această soluție pentru această problemă. Găsește ce este greșit la ea: corectitudinea în cazuri limită, concurență, tratarea erorilor, performanță la [scală], sau o abordare mai simplă care a fost ratată. Dacă este cu adevărat solidă, spune-o clar în loc să inventezi obiecții. Problemă: [paste]. Soluție propusă: [paste].
Două rezultate posibile, ambele utile. Fie al doilea model găsește o breșă reală, pe care acum o știi înainte de merge, fie este de acord chiar dacă a fost împins să nu fie, ceea ce este o confirmare semnificativă. Iterarea cu același model nu îți oferă niciuna dintre ele, pentru că un model care își revizuiește propriul rezultat este de obicei de acord cu sine.
Folosește-l pentru deciziile care ar fi costisitoare dacă sunt greșite: o schimbare de schemă, o remediere de concurență, orice atinge autentificarea sau banii. Nu pentru munca de rutină. Vezi compararea modelelor una lângă alta, schimbarea modelelor în mijlocul conversației și scrierea și depanarea codului cu mai multe modele pentru tot fluxul de lucru într-un singur loc.
La ce să fii atent
API-uri inventate. Nume de metode, parametri și chei de configurare prezentate cu încredere, care nu există, mai ales pentru biblioteci schimbate recent. Semnătura va arăta corect. Verifică documentația reală înainte de a construi pe ceva necunoscut.
Niciun semnal de încredere. O remediere corectă și una subtil greșită vin cu aceeași certitudine. Tonul nu îți spune nimic.
Extindere silențioasă a domeniului. Pentru asta există a doua constrângere.
Teatru de securitate. Denumirea claselor de vulnerabilități din codul tău este o primă trecere utilă. Nu este un audit, iar modelul nu îți cunoaște modelul de amenințări, deployment-ul sau sensibilitatea datelor.
Păstrează prompturile pe care le folosești săptămânal undeva de unde le poți lipi, iar constrângerile permanente pune-le în instrucțiunile unui proiect, ca să se aplice automat la fiecare chat din acel proiect.
- Precizează limbajul, framework-ul și versiunea în fiecare prompt de programare
- Adaugă propoziția de limitare a diff-ului la orice prompt care produce cod
- Cere ipoteze ordonate și verificări ieftine înainte de a cere o remediere
- Întreabă mereu ce ar putea strica o remediere și dacă tratează doar simptomul
- Rulează modelul „a doua opinie” pentru orice ar fi costisitor dacă e greșit
- Întreabă ce nu acoperă suita de teste existentă, nu doar pentru mai multe teste
- Verifică API-urile necunoscute față de documentația reală
- Păstrează prompturile pe care le folosești săptămânal undeva de unde le poți lipi
Întrebări frecvente
Aceste prompturi funcționează doar cu Claude?
Nu. Sunt scrise pentru stilul de raționament atent, cu context lung, la care Claude excelează, dar funcționează direct și cu GPT și Gemini. De fapt, câteva sunt mai bune folosite între modele: promptul „a doua opinie” necesită două modele, iar promptul „argumentează partea opusă” este mai util când modelul care argumentează nu a făcut alegerea inițială.
Ce model ar trebui să folosesc pentru fiecare prompt?
Ca punct de plecare: Claude pentru raționament subtil, arhitecturi necunoscute și explicarea comportamentului; GPT pentru implementare rapidă pe teren bine cunoscut și rezultat structurat strict; un model cu context mare când întrebarea acoperă mai mult cod decât încape confortabil într-un prompt normal. Apoi ajustează asta cu o săptămână de comparații proprii, pentru că răspunsul corect depinde mai mult de stack-ul tău decât de orice benchmark.
Este acesta un înlocuitor pentru un instrument agentic de programare?
Nu, rezolvă probleme diferite. Un agent trăiește în repository-ul tău și editează fișiere. Aceste prompturi sunt pentru stratul de raționament: înțelegerea unei erori, revizuirea unui diff, planificarea unei refactorizări, argumentarea unei abordări. Majoritatea dezvoltatorilor folosesc ambele, iar alegerea modelului contează mai mult aici, pentru că evaluezi raționamentul, nu diff-ul rezultat.
Cum îl opresc să rescrie cod pe care nu l-am cerut?
Adaugă asta în prompt: schimbă cât mai puțin posibil, păstrează structura și denumirile existente și listează fiecare linie modificată cu un motiv de o linie. Refactorizarea nesolicitată este principalul motiv pentru care sugestiile AI devin imposibil de revizuit, iar limitarea diff-ului face diferența dintre o schimbare pe care o poți raționa și una pe care trebuie să o recitești de la zero.
Pot lipi cod proprietar?
Whizi nu se antrenează pe conversațiile tale, iar politica de date a fiecărui furnizor poate fi consultată înainte să activezi modelul respectiv, dar politica angajatorului tău este constrângerea decisivă și variază mult. Acolo unde se aplică restricții, reproducerea problemei ca exemplu minimal, care păstrează structura și elimină logica de business, este de obicei atât permisă, cât și un prompt mai bun, pentru că elimină detaliile care distrăgeau atenția.