En bra kodprompt beskriver inte vad du vill ha — den beskriver vad som redan är sant. Modellen kan formulera lösningar. Den kan inte veta vilka konventioner ni följer, vad ni redan provat eller vad som inte får ändras. Det är den informationen som avgör om svaret går att använda.
Varför en kodprompt inte är en chattfråga
När du frågar en modell något allmänt räcker frågan i sig. När du ber om kod finns det ett osynligt facit: ditt befintliga system. Samma fråga har olika rätt svar i två olika kodbaser, och modellen ser bara den ena om du visar den.
Det är därför "skriv en funktion som validerar e-postadresser" nästan alltid ger något du får skriva om. Svaret är korrekt i allmänhet och fel hos dig — det använder ett regex ni bannlyst, kastar ett undantag där ni returnerar ett resultatobjekt, och saknar den där specialregeln för era interna adresser.
Skillnaden mellan en prompt som fungerar och en som inte gör det ligger sällan i formuleringskonst. Den ligger i hur mycket av det osynliga facit du skrev ned.
Fyra delar som alltid ska med
Det här är inte en mall att följa slaviskt, utan fyra frågor att ha svar på. Saknas någon av dem gissar modellen, och gissningen ser lika självsäker ut som resten.
Att ge rätt kontext — och inte för mycket
Det vanliga rådet är "ge mer kontext". Det är rätt riktning men fel precision. Att klistra in hela kodbasen gör inte svaret bättre; det gör det svårare för modellen att avgöra vad som är relevant, och det ökar risken att den härmar mönster du inte bad om.
Rätt kontext är den minsta mängd som gör uppgiften entydig.
Vad som nästan alltid är värt att ta med
- Funktionen eller filen som ska ändras, i sin helhet — inte ett utdrag ur mitten.
- Typerna och signaturerna den anropar. Modellen behöver inte implementationen, bara formen.
- Ett exempel på hur ni brukar göra liknande saker. Ett enda exempel styr stilen mer än tre stycken instruktioner.
- Det som inte får ändras, och gärna varför. "Vi returnerar alltid ett Result-objekt här, kasta inte undantag."
- Vad du redan provat, om det är en andra runda. Annars får du samma förslag igen.
- "Du är en expert på …". Rollbeskrivningar gör lite för kodkvalitet jämfört med att visa faktisk kod.
- Hela repot. Mer brus, inte mer förståelse.
- "Gör det bra" eller "använd best practices". Ospecifikt beröm av kvalitet ger ospecifik kvalitet. Skriv ut vad du menar.
- Långa listor av allmänna regler som upprepas i varje prompt. Lägg dem i kontextfilen i stället.
Be om plan före kod
Det enskilt mest lönsamma tillägget till en prompt är att först be om en plan i punktform. Den tar en halv minut att läsa och avslöjar missförstånd innan de har blivit två hundra rader.
En plan visar också något kod inte gör: vad modellen tänker inte göra. Om planen saknar felhanteringen du förväntade dig vet du det direkt, i stället för efter att ha läst igenom en implementation som ser komplett ut.
Formuleringen kan vara så enkel som: "Skriv ingen kod än. Beskriv först i punktform vad du tänker ändra och i vilka filer, så säger jag till när du ska fortsätta." Den sista satsen är viktig — utan den brukar planen följas av koden ändå.
Mallar som är värda att återanvända
Tre lägen täcker det mesta av vardagen. Spara dem någonstans du når snabbt.
Jag ska lägga till [en mening om uppgiften] i [fil].
Projektet använder [språk, ramverk, version]. Så här ser den befintliga koden ut: [klistra in]. Vi följer mönstret att [konvention].
Ändra bara [fil]. Rör inte [det som ska lämnas].
Jag verifierar genom att [körning, test, anrop].
Beskriv planen i punktform först. Skriv ingen kod förrän jag säger till.
Förklara vad den här koden gör, rad för rad där det är icke-uppenbart: [klistra in]
Jag är van vid [språk du kan] men inte [språket i koden].
Säg särskilt till om något ser ut att bete sig annorlunda än man skulle tro vid en snabb genomläsning.
Ditt förslag gav [exakt vad som hände — felmeddelande, fel utdata, testet som föll].
Jag har redan uteslutit [vad du kontrollerat].
Föreslå inte samma lösning igen. Förklara först varför det blev så, sedan vad du vill ändra.
Fem misstag som kostar en omgång
- Att beskriva lösningen i stället för problemet. "Lägg till en cache här" låser modellen vid din idé. "Det här anropet tar tre sekunder och görs på varje sidladdning" öppnar för bättre förslag.
- Att inte säga vad som inte får ändras. Modellen städar gärna i förbifarten. Utan en gräns byter den namn på saker du inte bad om.
- Att fortsätta i samma konversation för länge. Efter ett antal olika uppgifter bryts modellens bild av koden ned. Starta om vid ny uppgift.
- Att acceptera första svaret när det ser rimligt ut. Rimligt utseende är precis det modellen optimerar för. Verifieringen är din.
- Att upprepa allmänna regler i varje prompt. Det som gäller alltid hör hemma i kontextfilen, inte i fingrarna.
När prompten är på plats och koden kommer tillbaka börjar nästa moment, och det är där de flesta problem faktiskt fångas: granskningen.