Gevinster:
- Evne til at skrive funktioner, klasser og moduler til AI med klare input-output og begrænsningsdefinitioner
- Evne til at bruge AI som en parprogrammeringspartner og gøre fremskridt trin for trin i små, verificerbare bidder
- Evne til at fange logik og edge case-fejl ved at kompilere koden genereret af AI og køre den med små eksempler
Parprogrammering er, når to udviklere arbejder på det samme problem, hvor den ene skriver og den anden reviderer. Kodning med AI er den digitale version af netop dette forhold: du sætter retningen, begrænsningerne og acceptkriterierne; AI producerer hurtigt udkast; Du verificerer hvert trin ved at kompilere og teste det. Den største fælde her er at fortælle AI'en "skriv mig denne applikation fra start til slut" og blindt acceptere en 200-linjers blok. God parprogrammering foregår i små trin: hvert trin skal være forståeligt, testbart og reversibelt.
I denne enhed lærer du at udskrive funktioner, klasser og moduler med en klar input-output kontrakt; Sådan guider du AI trin for trin; og vi vil se, hvordan man fanger logik og kant-case-fejl ved at køre den kode, den producerer, med små eksempler. Målet er ikke hastighed, men verificeret hastighed.
Begreber: Input-output kontrakt: En klar definition af, hvilket input en funktion tager, og hvilken output- og fejladfærd den lover. Kant-case: Input, der ikke er almindeligt, men som faktisk kan forekomme (tom, nul, negativ, meget stor, null). Inkrementel udvikling: Fortsæt med små, arbejdende stykker og validering af hvert trin.
Udskrivning af kode med netkontrakt
Grundlaget for kvalitetskoden er at definere præcist "hvad du vil have", inden arbejdet påbegyndes. Når du skriver en funktion til AI, skal du give den fem ting: sprog og version, inputtyper og betydninger, output, fejlbetingelser og begrænsninger (ydeevne, eksternt biblioteksforbud, stil). Dette forhindrer AI i at gætte.
- Skriv kontrakten. Input, output, fejl, begrænsning.
- Bed om en lille enhed. En funktion med et enkelt ansvar; Det er ikke et stort modul.
- Anmod om en testblok. Tilføj et par prøvekørsler/tests ved siden af koden.
- Kompiler og kør. Prøv det med kantkasser, bekræft outputtet med øjet.
- Gå til næste trin. Når et stykke er bekræftet, skal du bygge videre på det.
Contracted function prompt: "Skriv en funktion til TypeScript 5. Formål: Beregn det samlede antal varer i en indkøbskurv. Input: { pris: antal, mængde: antal }[] array. Output: antal (total). Regler: smid Fejl, hvis antal eller pris er negativ; returner 0 for tom array; afrund fejlbeløb til 2 decimaler. Brug ikke decimaler. 5 testcases under funktionen (normal, tom, negativ mængde, decimalpris, enkelt vare)."
Vejleder AI som et par
Gode fremskridt inden for parprogrammering er en dialog snarere end én stor anmodning. Først skal du anmode om skelettet og køre det; tilføj derefter en kanttilstand; så få rettet en fejl. Denne tilgang holder koden forståelig og giver dig kontrol ved hvert trin.
Inkrementel fremskridtsprompt: "Vi vil skrive en læser, der læser en CSV-fil og konverterer linjerne til et objekt. Lad os gå TRIN FOR TRIN og gå videre til næste trin, uden at jeg bekræfter hvert trin. Trin 1: bare skriv skelettet, der opdeler filen i linjer og adskiller overskriftslinjen. Tilføj ikke tekstkonvertering eller fejlhåndtering endnu.".
Forklar og begrund kodeprompten: "Forklar den funktion du lige har skrevet, ikke linje for linje, men beslutning for beslutning: hvilken designbeslutning du tog og hvorfor, hvilken kantsag du håndterede og hvordan, hvilke sager du bevidst udelukkede? Skriv 3 antagelser i koden, som jeg ikke bør gå glip af."
Tip: Accepter ikke den AI-genererede kode uden at forstå den. "Forklar mig det, hvilke antagelser gjorde du?" Spørgsmålet afslører både skjulte fejl og giver dig mulighed for at forsvare den kode, da koden forbliver dit ansvar. At sætte kode, du ikke forstår, i produktion er som at sende en kontrakt ud uden at underskrive den.
Svag prompt / stærk prompt
SVAG:"Skriv en sorteringsfunktion."(Resultat: hvilket sprog, hvad der sorteres, er det stabilt, hvad er præstationsbegrænsningen, kode, der er vag og sandsynligvis ikke passer til kravet.)STÆRK:"For Java 17, skriv en metode, der sorterer et List<Medarbejder>-objekt først efter afdeling (alfabetisk), derefter efter løn (Lad IKKE returnere den nye afdeling. Lad IKKE den nye afdeling returneres). sidste. Forklar metodens kompleksitet i kommentarlinjen angiv en hovedtestblok med 4 prøver."
Kraftig prompt; Indeholder sorteringskriterium (to-niveau), bivirkningsregel (erstatter original), nuladfærd og testforventning. Uden disse detaljer producerer AI en plausibel, men forkert løsning; for eksempel kan det ødelægge den originale liste, og dette vil føre til en tavs fejl andre steder.
Validering med Edge Cases og små prøver
Den kode, der virker i det glade scenarie, er ikke den korrekte kode. Tving bevidst hver funktion produceret:
Kantkassetype
prøve input
forventet adfærd
blank input
Tom array/streng
Ikke en fejl, logisk tomt resultat
Nul/negativ
0, -1
Defineret og korrekt adfærd
stor værdi
Millioner af rekorder
Overløbs-/ydelseskontrol
null/udefineret
manglende plads
Kontrolleret fejl eller standard
Dublet/usædvanlig
gentagne, omvendt rækkefølge
korrekt resultat
Mini sager
Tilfælde 1 — Tavs afrundingsfejl. AI skriver en funktion, der indsamler penge med decimaltyper (float); 0,1 + 0,2 giver 0,300000000000000004. Fejlen er løst, når ingeniøren tilføjer reglen "Rund til 2 cifre og brug hele øre". En 3-linjers regel forhindrer tusindvis af øre af afvigelse i den månedlige afstemning.
Case 2 — Bivirkningsfælde. AI'en skriver en metode, der "sorterer" en liste, men ændrer den originale liste på plads. Uventet adfærd opstår, fordi et andet modul bruger den samme liste. Hvis "ændre original"-begrænsningen var i prompten, ville fejlen aldrig opstå; bliver fanget i kodegennemgang og forhindrer 2 timers fejlretning.
Case 3 — Indtjening trin for trin. En udvikler udskriver et 150-linjers importmodul på én gang; Når han finder en fejl, kan han ikke finde, hvor den kom fra. En anden udvikler deler det samme arbejde op i 5 små trin, tester hvert trin på 2 minutter og fanger fejlen med det samme i 3. trin.
Almindelige fejl
- Udskrivning af store blokke på én forespørgsel. Risikabel kode, der er svær at forstå og fejlfinding er født.
- At bede om en kode uden at give en kontrakt. Hvis input-output-fejl er tvetydig, vil AI gætte og tage fejl.
- Tester bare det lykkelige scenario. Hvis tomme, null, negative og store input ikke prøves, overlades fejlen til produktionen.
- Accepter uden forståelse. Koden, du ikke oplyser, er en gæld, du ikke kan forsvare.
- Ignorerer følsomme typer som bivirkninger og penge/dato. Float-penge med tidløs historie er en klassisk fejlkilde.
Sammenfattende
At skrive kode med AI er disciplineret parprogrammering: klar kontrakt, små trin, byg og test på hvert trin. At give input-output-error-constraint-kvartetten fra begyndelsen bestemmer kvaliteten af koden. At forklare den kode, den producerer, og tvinge den med kant-cases, bringer de fejl, der er gemt under det lykkelige scenarie, til overfladen. Kilden til hastighed er ikke blind accept; er hurtig udkast plus hurtig verifikation.
Ansøgningsopgave
Vælg en lille, men reel funktion (f.eks. kurvtotal, datoforskel, tekstparsing). Udskriv ved hjælp af den kontrakterede funktionsprompt; Tilføj mindst 5 testscenarier ved siden af. Kør koden og prøv bevidst 5 kantcases ved at bruge tabellen som guide. Find en fejl i mindst ét kanttilfælde (hvis ikke, design et nyt input for at tvinge funktionen), ret det med AI, og bekræft ved at genteste, at rettelsen virkede.
tjekliste
- [ ] Jeg skrev en kontrakt, der inkluderer input, output, fejl og begrænsninger.
- [ ] Jeg genererede koden i små trin i stedet for en stor blok.
- [ ] Jeg tilføjede en test-/prøvekørselsblok ved siden af koden.
- [ ] Jeg har bevidst testet mindst 5 kantsager.
- [ ] Jeg forklarede koden til AI og gennemgik dens antagelser.
- [ ] Jeg rettede den fundne fejl og bekræftede rettelsen ved at teste igen.