Grok för kodning: prompter, arbetsflöde och goda vanor

Grok är en kompetent kodningspartner för vardaglig programmering: tyda felmeddelanden, skriva korta funktioner, skissa tester, förklara okända filer eller göra en första version av en grov idé. I vår chatt kan den inte köra din kod, öppna ditt arkiv eller kolla dagens dokumentation. Kvaliteten på hjälpen beror därför på vad du klistrar in och hur noggrant du granskar svaren. Den här guiden går igenom båda delarna.

När Grok hjälper – och när den inte gör det

Grok fungerar bäst för problem som ryms i ett vanligt samtal. Bra användningsområden:

• avkoda stackspårningar eller kompilatorfel och föreslå troliga orsaker;
• skriva fristående funktioner, skript, SQL-frågor eller reguljära uttryck;
• förklara vad ett kodblock gör, rad för rad om du vill;
• ta fram förslag på enhetstester, inklusive gränsfall du kanske missat;
• granska korta diffar för buggar, otydliga namn och saknade kontroller;
• översätta kod mellan språk eller mellan biblioteksversioner.

Mindre lämpligt för: ändringar som berör många filer den aldrig har sett, allt som beror på ditt systems exakta tillstånd och frågor om biblioteksversioner som släppts efter dess träningsperiod. Den kan inte heller testa något. Varje kodsnutt den skriver är otestad tills du kör den.

Klistra in sammanhanget en ny kollega skulle behöva

Den vanligaste orsaken till ett oanvändbart kodsvar är att sammanhang saknas. Innan du frågar, samla ihop:

1. Språk och versioner. "Python 3.12, pandas 2" eller "Node 22, Express 5". Versionsskillnader orsakar en stor del av alla felaktiga svar.
2. Den relevanta koden. Funktionen som kraschar och det den anropar, inte hela projektet.
3. Det exakta felmeddelandet. Kopiera hela meddelandet och stackspårningen; sammanfatta inte med egna ord.
4. Förväntat kontra faktiskt utfall. Vad som borde hända, vad som faktiskt händer och vad du redan har provat.
5. Begränsningar. Inga nya beroenden, måste vara kompatibel med en äldre version, måste vara lättläst för nybörjare.

Dåligt:
min kod fungerar inte, fixa den

Bra:
Python 3.12. Den här funktionen ska returnera genomsnittligt
ordervärde per kund, men kunder med en enda order får NaN. Förväntat:
värdet på deras enda order. Här är funktionen och lite exempeldata.
Förklara orsaken först, och ge sedan den rättade funktionen. Lägg
inte till nya bibliotek.
---
[funktion]
[fem exempelrader]

Den bra varianten ger Grok språk, felsymtom, förväntat resultat och begränsningar att följa. Den ber dessutom om förklaringen före lösningen, så att du förstår vad som gick fel.

Prompter för vanliga programmeringsuppgifter

Förstå ett felmeddelande

Klistra in hela spårningen och raderna den pekar på, och fråga sedan: "Lista de tre troligaste orsakerna, med den mest sannolika först, och berätta hur jag bekräftar varje." Då får du en kort felsökningsplan i stället för en enstaka gissning.

Skriva en funktion

Beskriv indata, utdata och gränsfall i klartext. Be sedan om kod tillsammans med två eller tre exempelanrop och deras förväntade resultat. Exemplen fungerar direkt som ett snabbt test du kan köra.

Skriva tester

Skriv pytest-tester för funktionen nedan. Täck: normal indata,
tom indata, ett enskilt element, mycket stora tal och ogiltiga typer.
Ett test per fall, med ett tydligt namn. Ändra inte funktionen.
---
[funktion]

Granska din egen kod

Be om en granskning med ett tydligt fokus, till exempel: "Granska detta enbart med avseende på buggar och ohanterade fel; ignorera kodstil." En fokuserad granskning blir kortare och enklare att agera på. Testa granskningsprompten med din egen kodsnutt.

Förklara okänd kod

"Förklara vad det här gör som om jag kan JavaScript men inte det här biblioteket. Lista sedan allt som verkar riskabelt eller föråldrat." Att fråga efter risker gör förklaringen till en minigranskning.

Ett arbetsflöde där du behåller kontrollen

1. Börja med en plan. För allt som är större än en enskild funktion: be om ett upplägg innan du ber om kod. Justera planen först, be om koden sedan.
2. Jobba i små steg. En funktion eller en ändring per meddelande. Långa svar döljer misstag och kan klippas av på grund av längdbegränsningen.
3. Kör koden själv. Klistra in resultat eller nya felmeddelanden i samma chatt. "Det här hände när jag körde koden" är den bästa uppföljningen som finns.
4. Läs varje rad innan du sparar den. Om du inte skulle kunna förklara en rad för en kollega: be Grok förklara den, eller skriv om den.
5. Gör commits ofta och i små steg. Med versionshantering är det enkelt att backa om ett förslag visar sig fungera dåligt.

Verktyget kodassistent samlar dessa vanor i ett enkelt gränssnitt: välj uppgift, klistra in kod, få ett strukturerat svar. Vår sida för utvecklare visar fler sätt att använda Grok i vardagen, och våra kodningsprompter är färdiga att fylla i.

Vilken Grok-modell du ska välja för kod

• Grok 4.20 (standard) är snabb för förklaringar, små kodsnuttar, reguljära uttryck och standardkod.
• Grok 4.3 Thinking tänker efter före svar, vilket hjälper vid klurig felsökning, algoritmer och logik med många villkor.
• Grok 4.7 är den senaste modellen i vår chatt, och xAI beskriver den som sitt flaggskepp för kodning och agentuppgifter. Du har upp till 10 meddelanden per dag med den, så spara den till dina svåraste problem och skicka med allt sammanhang direkt i första meddelandet.

Vår guide om resonerande modeller förklarar när den extra tanketiden lönar sig.

Vanliga fällor att se upp för

• Påhittade funktioner. Grok anropar ibland metoder eller flaggor som låter rimliga men inte finns. Om du inte känner igen något, slå upp det i den officiella dokumentationen.
• Gamla versioner. Modellens kunskap har ett slutdatum. Bibliotek kan ha bytt namn på eller tagit bort funktioner sedan dess. Ange vilken version du kör och dubbelkolla ändringsloggen om du är osäker.
• Fokus på solskensscenarion. Första utkast missar ofta tom indata, saknade filer, tidszoner och nätverksfel. Fråga: "Vilken typ av indata skulle få detta att krascha?"
• Smygändringar. När modellen fixar en sak kan den samtidigt "snygga till" en annan. Be om en minimal ändring, eller om enbart de rader som skiljer sig.
• Säkerhetsluckor. Se upp för databasfrågor som byggs ihop med strängar, saknad indatavalidering och hemligheter hårdkodade i koden. Fråga rakt ut: "Är detta skyddat mot SQL-injektioner?"

Håll hemligheter borta från chatten

Innan du klistrar in kod, ta bort API-nycklar, lösenord, tokens, anslutningssträngar, kunddata och interna värdnamn. Ersätt dem med platshållare som DITT_API_KEY. Om din arbetsgivare har regler för att dela källkod med externa tjänster måste du följa dem. Vid tveksamheter, koka ner problemet till ett litet exempel som visar samma beteende utan känsliga delar. Ett sådant avskalat exempel avslöjar ofta buggen direkt. Vår guide om integritet och säkerhet förklarar hur meddelanden hanteras i vår chatt.

Vanliga frågor

Kan Grok köra min kod i er chatt?

Nej. Den läser och skriver kod men kör den inte, så den kan inte se det verkliga resultatet. Kör koden själv och klistra in resultatet eller felmeddelandet i chatten.

Kan jag skicka en skärmdump på ett fel?

Ja, alla tre modeller kan läsa bilder. Det är ändå bättre att klistra in texten om du kan, eftersom Grok då kan citera den exakt utan risk för felläsningar.

Vilka programmeringsspråk kan den?

Grok hanterar de stora språken utan problem: Python, JavaScript, TypeScript, Java, C#, C++, Go, PHP, SQL, shell-skript med flera. För ovanliga språk och nischade ramverk får du räkna med fler misstag och granska koden noggrannare.

Varför klipptes koden av mitt i?

Svar har en maxlängd. Be om "resten, med början från funktionen där du avbröts", eller be om en del av programmet i taget.

Är det okej att använda AI-genererad kod på jobbet?

Det beror på din arbetsgivares regler och projektets licens. Behandla genererad kod som vilket externt bidrag som helst: granska den, testa den och se till att du har tillåtelse att använda den.