PROMPTBIBLIOTEK

FÖR INGENJÖRER OCH TEKNIKER // KOPIERA OCH ANPASSA

Senast uppdaterad: 2026-05-24

ROLLSPECIFIKT EXEMPEL

Exempel för ingenjörer

Utgå från promptarna när en ingenjör förklarar en teknisk avvikelse för kollegor utanför specialistgruppen, men byt alltid ut hakparenteser mot konkret mål, material som får användas och kontrollkrav. Be AI markera osäkerheter i stället för att fylla luckor.

ANPASSA EFTER LOKALA REGLER OCH DATASKYDD

OM PROMPTARNA

Hur du använder det här biblioteket

Alla promptar är utgångspunkter. Byt ut det i hakparenteser mot din kontext. Mata aldrig in API-nycklar, lösenord eller proprietär affärslogik i icke-godkända verktyg.

KOPIERA → ANPASSA → GRANSKA → ANVÄND

KOD

Kodgenerering och granskning

Generera kod med kontext

Jag behöver implementera [beskriv vad funktionen/modulen ska göra]. Kontext: - Språk: [t.ex. Python 3.11, TypeScript 5.x, Go 1.21] - Ramverk/bibliotek: [t.ex. FastAPI, React, net/http] - Befintliga konventioner: [t.ex. "vi använder dependency injection", "vi undviker globalt state"] - Begränsningar: [t.ex. "får inte göra nätverksanrop synkront", "måste vara trådsäker"] Skriv implementationen med: 1. Tydliga typer/annotationer 2. Felhantering för de vanligaste felfallen 3. En kort kommentar om varje icke-uppenbara designval Avsluta med: vilka undantagsfall hanterar INTE den här koden, och vilka antaganden har du gjort?

Granska kod för problem

RÖD NIVÅ: Granska inte proprietär kärnlogik utan godkänt internt verktyg.
Granska följande kod och identifiera potentiella problem: ```[språk] [klistra in koden] ``` Fokusera specifikt på: 1. Buggar och logikfel (eventuella) 2. Säkerhetsproblem (input-validering, injektionssårbarheter, osäker hantering av känslig data) 3. Felhantering som saknas för rimliga felfall 4. Prestandaproblem som kan uppstå i skala 5. Läsbarhetsproblem (namn, komplexitet, nästling) För varje problem: beskriv problemet, var i koden det finns, och föreslå en konkret lösning. Markera tydligt om något är kritiskt vs. kosmetiskt.

Förklara komplex kod

Förklara vad följande kod gör, rad för rad om det behövs: ```[språk] [klistra in koden] ``` Förklara: 1. Vad koden övergripande åstadkommer 2. Logiken i de icke-uppenbara delarna 3. Varför specifika designval troligen gjordes (om du kan sluta dig till det) 4. Eventuella mönster eller idiom som används Anpassa förklaringen för en senior ingenjör som är ny i den här kodbasen.

FELSÖKNING

Debugga och analysera fel

Felsökning med kontext

Jag har ett fel som jag försöker förstå. Felmeddelande: [klistra in exakt felmeddelande och stacktrace] Relevant kod: ```[språk] [klistra in relevant kod] ``` Kontext: - Vad jag försöker åstadkomma: [beskriv] - Vad som faktiskt händer: [beskriv] - Vad jag redan provat: [lista det du testat] - Miljö: [OS, runtime-version, relevanta beroenden] Lista de 3-5 troligaste orsakerna i sannolikhetsordning. För varje orsak: vad jag ska kontrollera för att verifiera eller avfärda den. Avsluta med vilken orsak du bedömer som mest sannolik och varför.

DOKUMENTATION

Teknisk dokumentation

Skriv ett Architecture Decision Record (ADR)

GUL NIVÅ: Verifiera att arkitekturdetaljer och strategiska val får delas.
Hjälp mig skriva ett Architecture Decision Record (ADR) för följande beslut: Beslut: [vad vi har beslutat] Kontext: [varför vi behövde fatta ett beslut, vilket problem vi löste] Alternativ vi övervägde: 1. [alternativ 1] — [kort motivering till varför vi inte valde det] 2. [alternativ 2] — [kort motivering] 3. Valt alternativ: [varför vi valde detta] Kända konsekvenser: - Positiva: [lista] - Negativa/avvägningar: [lista] - Öppna frågor: [vad vi inte vet ännu] Strukturera detta som ett välformulerat ADR med standardsektioner: Status, Kontext, Beslut, Konsekvenser.

Generera API-dokumentation

Generera API-dokumentation för följande kod: ```[språk] [klistra in API-kod, endpoint-definitioner eller funktionssignaturer] ``` Format: [Markdown / OpenAPI YAML / JSDoc / docstrings] Målgrupp: [interna utvecklare / externa API-konsumenter] Dokumentationen ska inkludera: - Beskrivning av vad varje endpoint/funktion gör - Parametrar med typ, om de är obligatoriska, och vad de förväntas innehålla - Returvärde och typ - Möjliga felkoder/exceptions med förklaring - Minst ett konkret användningsexempel per endpoint/funktion

KOMMUNIKATION

Teknisk kommunikation för icke-tekniker

Omformulera teknisk information till affärsspråk

Jag behöver kommunicera följande tekniska information till [mottagare: produktchef / VD / styrelse / kund]: Teknisk information: [beskriv det tekniska beslutet, problemet eller statusen] Mottagarens bakgrund: [teknisk förförståelse: ingen / viss / god] Vad jag vill att de ska förstå: [formulera målet] Vad jag behöver från dem (om något): [beslut / godkännande / information / ingenting] Skriv en kommunikation som: - Fokuserar på affärspåverkan (kostnad, risk, tid, möjligheter) snarare än teknisk implementation - Är kortfattad — max [X] meningar/stycken - Undviker jargong utan att förenkla bort det väsentliga - Avslutar med ett tydligt nästa steg om du behöver något från dem

TILLBAKA TILL START

ALLA AVSNITT // VÄLJ DIN INGÅNG

Tillbaka till översikten

VANLIGA FRÅGOR

Använda promptbiblioteket

Hur anpassar jag promptarna i biblioteket till min situation?

Byt ut allt inom [hakparenteser] mot din konkreta kontext: organisation, målgrupp, tidsram och eventuellt format. Ju mer specifik kontext, desto användbarare svar — generiska promptar ger generiska svar.

Vad ska jag aldrig klistra in i en prompt?

Personuppgifter, sekretessbelagda dokument, proprietär information och inloggningsuppgifter ska aldrig in i konsumentversioner av AI. Använd enterprise-verktyg med biträdesavtal när materialet kräver det — se etik-juridik-sidan.

Hur vet jag att AI-svaret är användbart?

Granska sakuppgifter mot oberoende källa, låt en kollega läsa igenom om innehållet är viktigt, och misstänkliggör svar som låter mycket självsäkra. AI lyckas ofta med struktur och utkast men mindre ofta med exakt fakta.