Så skriver du prompter för AI-appbyggare (med exempel före och efter)

En bra prompt till en AI-appbyggare beskriver produkten, inte koden: vem som använder den, vad de gör steg för steg, vilken data den sparar och vem som får se vad. När den första versionen finns, be om en specifik ändring per meddelande, säg vad som måste förbli kvar och beskriv problem som ”jag gjorde X, förväntade mig Y, fick Z”. De tre vanorna löser de flesta besvikelser.

Resten av guiden visar mönstren i detalj, med exempel före och efter som du kan anpassa.

Varför det är annorlunda att skriva prompter till en appbyggare

När du frågar en chattassistent något ger en vag prompt ett vagt svar och du går vidare. När du skriver en prompt till en AI-appbyggare blir svaret ett körbart program. Varje lucka i din beskrivning fylls med en gissning, och gissningarna blir kod, databastabeller och skärmar som du sedan måste leva med eller ångra.

Alltså är målet med en prompt inte att låta smart. Det är att lämna färre viktiga beslut åt slumpen. Du behöver inte teknisk vokabulär för det. Du behöver vara specifik om det enda som bara du vet: dina användare, ditt arbetsflöde och dina regler.

Vad du ska ta med i en första prompt

Innan du skriver något, svara på dessa frågor. Varje fråga stänger en lucka som AI:n annars skulle gissa om.

Den sista raden är underskattad. Att säga vad du inte vill hindrar AI:n från att lägga till en blogg, en prissida och ett nyhetsbrevsformulär som du aldrig bad om.

Före och efter: den första prompten

Före:

Gör en app åt mitt gym.

Byggaren måste gissa allt: medlemmar eller personal? Klasser eller personlig träning? Betalningar? Du får något som ser ut som en gymsajt och inte gör det du behöver.

Efter:

Bygg en bokningsapp för gruppträning på en liten yogastudio. Medlemmar ser veckans pass (namn, lärare, tid, lediga platser) och bokar en plats, och de kan avboka upp till två timmar före. Medlemmar registrerar sig med e-post och lösenord. Studioägaren loggar in för att lägga till pass, se vem som är bokad och markera närvaro. Spara pass, medlemmar och bokningar i en databas. Lugn, ljus design som fungerar bra i mobilen. Inga betalningar än.

Den andra versionen är fortfarande kort. Den svarar bara på frågorna i tabellen ovan.

Beskriv beteende, inte implementering

Du får ofta bättre resultat om du beskriver vad som ska hända i stället för hur det ska byggas.

Före:

Lägg till en useEffect som hämtar bokningar och en modal-komponent för redigering.

Efter:

När ägaren klickar på en bokning, öppna en panel där den kan ändra tiden eller avboka den. Ändringarna ska synas direkt i listan.

Den första prompten låser AI:n vid en specifik teknik som kanske inte passar hur appen är byggd. Den andra berättar resultatet och låter AI:n välja rätt angreppssätt för koden den redan skrivit. Om du är utvecklare och har en stark preferens, säg den, men kombinera den med resultatet.

Var konkret kring reglerna

Affärsregler är där AI-byggda appar oftast går fel, eftersom de är självklara för dig och osynliga för AI:n. Skriv ut dem.

• Gränser: ”En medlem kan ha högst tre framtida bokningar.”
• Tidpunkter: ”Avbokningar stängs två timmar före passet börjar.”
• Kantfall: ”Om ett pass är fullt, visa en väntelisteknapp i stället för Boka.”
• Behörigheter: ”Lärare kan se närvaron för sina egna pass men inte för andra lärares.”

Varje av dessa är en mening. Om du utelämnar någon av dem kommer appen antingen inte att upprätthålla regeln eller hitta på sin egen version av den.

Efter första versionen: en ändring per meddelande

När något kör i förhandsvisningen, byt från att beskriva hela produkten till att be om små, kontrollerbara ändringar.

Före:

Designen är fel, bokningen fungerar inte ordentligt och jag vill ha en kalendervy och e-post.

Efter (som fyra separata meddelanden):

1. När jag bokar den sista platsen i ett pass står det fortfarande ”1 plats kvar”. Det ska stå ”Fullt” och bokaknappen ska döljas.
2. Lägg till en veckokalender på schemasidan, en kolumn per dag. Behåll den nuvarande listvyn som alternativ.
3. Gör passkorten mer kompakta i mobilen: mindre marginaler, lärarens namn på samma rad som tiden.
4. Skicka medlemmen en bekräftelse via e-post när hen bokar.

Varför det fungerar:

• Varje ändring är tillräckligt liten för att AI:n ska få rätt i ett pass.
• Du kan testa varje ändring innan du går vidare.
• Om en går fel kan du rulla tillbaka just det steget utan att förlora de andra.

Säg vad som ska behållas

När du ber om en ändring i något som redan fungerar, säg vad som inte får ändras. Det är det enklaste sättet att stoppa regressioner (saker som fungerade förut och går sönder efter en redigering).

Gör om startsidans rubrik med en större rubrik och en bild till höger. Behåll navigeringen, färgerna och allt under rubriken exakt som det är.

Samma sak gäller data: ”Lägg till ett telefonnummerfält för medlemmar. Ta inte bort eller byt namn på några befintliga fält.”

Använd skärmbilder och exakt text

Ord som ”saken högst upp” är tvetydiga. De flesta AI-appbyggare accepterar bilder, och en skärmbild med en kort notering går snabbare än ett stycke beskrivning.

• Bifoga en skärmbild och skriv ”knappen som är markerad med rött överlappar menyn på mobilen”.
• Klistra in den exakta texten i ett felmeddelande i stället för att omformulera den.
• Citera texter på skärmen exakt: ”knappen Spara ändringar på sidan Inställningar”.

För buggar specifikt, använd den här formen:

På bokningssidan klickade jag på Avboka för en bokning imorgon. Jag väntade mig att den skulle försvinna från min lista. Istället hände ingenting och bokningen finns kvar efter att jag laddat om. Rätta det och kontrollera att avbokning fungerar.

Vår guide om hur du felsöker en AI-byggd app går djupare på det här.

Planera först vid stora ändringar

För allt som berör många delar av appen — att lägga till användarkonton i en app som inte hade några, att lägga till betalningar, att ändra hur data är strukturerad — be om en plan innan någon kod ändras.

Innan du ändrar något, förklara hur du skulle lägga till teamkonton: vilka nya tabeller, vilka sidor som ändras och vad som händer med befintliga användare. Redigera inte koden än.

Läs planen. Om den missförstår något är det mycket billigare att rätta ett stycke än att rätta en färdig funktion. Många byggare har ett särskilt läge för detta; i Mythex är det läget Plan, tillsammans med Build och Ask.

Vad du ska undvika

När det gäller API-nycklar: om du behöver en betal- eller e-posttjänst, lägg dess nycklar i projektets hemligheter i stället för i prompten. Se vad miljövariabler och hemligheter är om det är nytt för dig.

Återanvändbara promptmallar

Anpassa dessa genom att ersätta de hakparenteser som finns.

Ny app:

Bygg en [typ av app] för [vem]. De [huvudflöde, steg för steg]. [Andra typen av användare] loggar in för att [vad de gör]. Spara [data] i en databas. [Utseende och känsla]. Lämna utanför [saker för senare].

Ny funktion:

Lägg till [funktion] på [sida]. När [användare] gör [handling], ska [vad som ska hända]. Bara [vem] kan [göra det]. Behåll [befintliga saker] som de är.

Designändring:

På [sida], ändra [specifikt element] till [specifik ändring]. Behåll [vad som ska behållas]. Kontrollera att det ser rätt ut på en skärm i mobilbredd.

Bugg:

På [sida] gjorde jag [steg]. Jag förväntade mig [förväntat]. Istället [faktiskt, plus exakt felmeddelande]. Rätta det och kontrollera att flödet fungerar.

Fråga utan ändringar:

Ändra ingen kod. Förklara hur [del av appen] fungerar och var [data] lagras.

Skriva en längre specifikation

För större projekt kan det hjälpa att skriva en brief på en sida först och klistra in den som din första prompt: användarna, kärnflödena, datan, reglerna och vad som ligger utanför omfattningen. Du kan till och med låta en AI hjälpa dig utforma den — vår guide om hur du skriver en PRD med AI visar hur. Håll bara den första byggbegäran till kärnflödet och lägg till resten steg för steg.

Prompta i Mythex

Allt ovan fungerar i Mythex. Några saker som hjälper särskilt:

• Lägena Build, Plan och Ask. Använd Plan för stora eller riskfyllda ändringar och Ask när du vill ha en förklaring utan redigeringar.
• Kontrollpunkter. Efter varje lyckad ändring sparar Mythex en kontrollpunkt, och Återställ till denna punkt på ett svar rullar tillbaka projektet. Du kan också redigera ett tidigare meddelande och skicka om det för att prova en annan prompt från den punkten.
• Hemlighetskort. När agenten behöver en API-nyckel frågar den via ett kort i chatten, så att värdet lagras som en projekthemlighet i stället för att skrivas in i ditt meddelande.
• Bilder. Bifoga skärmbilder eller mockups så tittar agenten på dem.

Dokumentationen har en kort sida om effektiva prompter och en om att iterera utan att bygga om. Om du börjar från noll går så bygger du en app med AI igenom ett helt projekt, och så designar du en snygg app med AI tar upp prompter för visuell finputsning.

Frågor