Sådan skriver du prompts til AI-app-builders (med før-og-efter-eksempler)

En god prompt til en AI-app-builder beskriver produktet, ikke koden: hvem der bruger det, hvad de gør trin for trin, hvilke data det gemmer, og hvem der må se hvad. Når første version findes, så bed om én konkret ændring pr. besked, sig hvad der skal forblive det samme, og beskriv problemer som „Jeg gjorde X, forventede Y, fik Z“. Disse tre vaner retter de fleste skuffende resultater.

Resten af guiden viser mønstrene i detaljer med før-og-efter-eksempler, du kan tilpasse.

Hvorfor det er anderledes at prompte en app-builder end at chatte med en AI

Når du stiller en chat-assistent et spørgsmål, får en vag prompt et vagt svar, og så går du videre. Når du prompter en AI-app-builder, er svaret et kørende program. Hvert hul i din beskrivelse bliver fyldt ud med et gæt, og gættene bliver til kode, databasetabeller og skærme, som du så skal leve med eller fjerne igen.

Så målet med en prompt er ikke at lyde klog. Det er at efterlade færre vigtige beslutninger til tilfældighed. Du behøver ikke teknisk ordforråd til det. Du skal være konkret om de ting, kun du ved: dine brugere, dit arbejdsflow og dine regler.

Hvad du skal med i en første prompt

Før du skriver noget, så besvar disse spørgsmål. Hvert af dem lukker et hul, AI'en ellers ville gætte på.

Den sidste række er undervurderet. At sige, hvad du ikke vil have, forhindrer AI'en i at tilføje en blog, en prisside og en nyhedsbrevstilmelding, som du aldrig bad om.

Før og efter: den første prompt

Før:

Lav en app til mit fitnesscenter.

Builderen må gætte alt: medlemmer eller personale? Hold eller personlig træning? Betalinger? Du får noget, der ligner en hjemmeside for et fitnesscenter, og som ikke gør det, du har brug for.

Efter:

Byg en holdbookingapp til et lille yogastudie. Medlemmer ser ugens hold (navn, instruktør, tidspunkt, ledige pladser), booker en plads og kan afmelde op til to timer før. Medlemmer opretter sig med mail og adgangskode. Studieejeren logger ind for at tilføje hold, se hvem der er booket, og registrere fremmøde. Gem hold, medlemmer og bookinger i en database. Roligt, lyst design, der fungerer godt på telefoner. Ingen betalinger endnu.

Den anden version er stadig kort. Den besvarer bare spørgsmålene fra tabellen ovenfor.

Beskriv adfærd, ikke implementering

Du får ofte bedre resultater, hvis du beskriver, hvad der skal ske, i stedet for hvordan det skal bygges.

Før:

Tilføj en useEffect, der henter bookinger, og en modal-komponent til redigering.

Efter:

Når ejeren klikker på en booking, åbnes et panel, hvor de kan ændre tidspunktet eller annullere den. Ændringerne skal vises med det samme i listen.

Den første prompt låser AI'en fast på en bestemt teknik, som måske ikke passer til den måde, appen er bygget på. Den anden fortæller, hvad udfaldet skal være, og lader AI'en vælge den rette fremgangsmåde til den kode, den allerede har skrevet. Hvis du er udvikler og har en klar præference, så sig den, men kombinér den med udfaldet.

Vær konkret om reglerne

Forretningsregler er der, hvor AI-byggede apps oftest går galt, fordi de er åbenlyse for dig og usynlige for AI'en. Skriv dem ud.

• Grænser: „Et medlem kan højst have tre kommende bookinger.“
• Timing: „Afmeldinger lukker to timer før holdet starter.“
• Edge cases: „Hvis et hold er fuldt, vis en venteliste-knap i stedet for Book.“
• Rettigheder: „Instruktører kan se deres egne holds fremmøde, men ikke andre instruktørers.“

Hver af dem er én sætning. Hvis du udelader en af dem, betyder det, at appen enten ikke håndhæver reglen eller opfinder sin egen version af den.

Efter første version: én ændring pr. besked

Når noget kører i preview, så skift fra at beskrive hele produktet til at bede om små, kontrollerbare ændringer.

Før:

Designet er skævt, bookingen virker ikke ordentligt, og jeg vil have en kalendervisning og mails.

Efter (som fire separate beskeder):

1. Når jeg booker den sidste plads i et hold, står der stadig „1 plads tilbage“. Der skal stå „Fuld“, og Book-knappen skal skjules.
2. Tilføj en ugekalender på skemasiden med én kolonne pr. dag. Behold den nuværende listevisning som et valg.
3. Gør holdkortene mere kompakte på telefoner: mindre padding, instruktørens navn på samme linje som tidspunktet.
4. Send medlemmet en bekræftelsesmail, når de booker.

Hvorfor det virker:

• Hver ændring er lille nok til, at AI'en kan få den rigtig i ét forsøg.
• Du kan teste hver enkelt, før du går videre.
• Hvis én går galt, kan du rulle netop det trin tilbage uden at miste de andre.

Sig hvad der skal blive ved med at være det samme

Når du beder om en ændring i noget, der allerede virker, så sig, hvad der ikke må ændres. Det er den nemmeste måde at forhindre regressioner (ting, der virkede før, og som går i stykker efter en redigering).

Redesign forsidens hero med en større overskrift og et billede til højre. Behold navigationen, farverne og alt under hero'en præcis, som det er.

Det samme gælder data: „Tilføj et telefonnummerfelt til medlemmer. Fjern eller omdøb ikke nogen eksisterende felter.“

Brug skærmbilleder og præcis tekst

Ord som „tingen øverst“ er tvetydige. De fleste AI-app-builders accepterer billeder, og et skærmbillede med en kort note er hurtigere end et afsnit beskrivelse.

• Vedhæft et skærmbillede og skriv „knappen, der er cirklet med rødt, overlapper menuen på telefoner“.
• Indsæt den præcise tekst fra en fejlmeddelelse i stedet for at omskrive den.
• Citer labels på skærmen nøjagtigt: „Gem ændringer-knappen på indstillingssiden“.

Til fejl specifikt, brug denne form:

På bookingsiden klikkede jeg på Annuller for en booking i morgen. Jeg forventede, at den forsvandt fra min liste. I stedet skete der ingenting, og bookingen er der stadig efter en opdatering. Ret det, og tjek at annullering virker.

Vores guide om sådan fejlsøger du en AI-bygget app går dybere ind i det her.

Planlæg først ved store ændringer

Til alt, der berører mange dele af appen — tilføje brugerkonti til en app, der ingen havde, tilføje betalinger, ændre hvordan data er struktureret — så bed om en plan, før nogen kode ændres.

Før du ændrer noget, så forklar hvordan du ville tilføje teamkonti: hvilke nye tabeller, hvilke sider der ændres, og hvad der sker med eksisterende brugere. Rør ikke koden endnu.

Læs planen. Hvis den misforstår noget, er det langt billigere at rette et afsnit end at rette en færdig funktion. Mange builders har en særlig tilstand til det; på Mythex er det Plan-tilstanden ved siden af Build og Ask.

Hvad du skal undgå

Om API-nøgler: Hvis du har brug for en betalings- eller mailtjeneste, så læg dens nøgler i projektets hemmeligheder i stedet for i prompten. Se hvad miljøvariabler og hemmeligheder er, hvis det er nyt for dig.

Genbrugelige prompt-skabeloner

Tilpas disse ved at erstatte de bratte dele.

Ny app:

Byg en [type app] til [hvem]. De [hovedflow, trin for trin]. [Anden type bruger] logger ind for at [hvad de gør]. Gem [data] i en database. [Udseende og fornemmelse]. Udelad [ting til senere].

Ny funktion:

Tilføj [funktion] til [side]. Når [bruger] gør [handling], skal [hvad der skal ske]. Kun [hvem] kan [gøre det]. Behold [eksisterende ting], som de er.

Designændring:

På [siden], ændr [specifikt element] til [specifik ændring]. Behold [hvad der skal blive]. Tjek at det ser rigtigt ud på en skærm i telefonbredde.

Fejl:

På [side] gjorde jeg [trin]. Jeg forventede [forventet]. I stedet [faktisk, plus præcis fejltekst]. Ret det, og verificér at flowet virker.

Spørgsmål uden ændringer:

Ændr ikke noget kode. Forklar hvordan [del af appen] virker, og hvor [data] gemmes.

Skriv en længere specifikation

Til større projekter kan det hjælpe at skrive en brief på én side først og indsætte den som din åbningsprompt: brugerne, kerneflowene, dataene, reglerne og det, der er uden for omfang. Du kan endda få en AI til at hjælpe med at udkaste den — vores guide om at skrive en produktkravsdokument med AI forklarer hvordan. Hold bare den første byggeanmodning til kerneflowet, og tilføj resten trin for trin.

Prompting i Mythex

Alt ovenfor virker i Mythex. Et par specifikke ting, der hjælper:

• Build-, Plan- og Ask-tilstande. Brug Plan til store eller risikable ændringer, og Ask når du vil have en forklaring uden redigeringer.
• Checkpoints. Efter hver vellykket ændring gemmer Mythex et checkpoint, og Gå tilbage til dette punkt på et svar ruller projektet tilbage. Du kan også redigere en tidligere besked og sende den igen for at prøve en anden prompt fra det punkt.
• Hemmelighedskort. Når agenten har brug for en API-nøgle, spørger den via et kort i chatten, så værdien gemmes som projekthemmelighed i stedet for at blive skrevet ind i din besked.
• Billeder. Vedhæft skærmbilleder eller mockups, og agenten kigger på dem.

Dokumentationen har en kort side om effektive prompts og en om at iterere uden at genopbygge. Hvis du starter fra bunden, gennemgår sådan bygger du en app med AI et helt projekt, og sådan designer du en flot app med AI dækker prompts til visuel finpudsning.

Spørgsmål