Slik skriver du ledetekster til AI-appbyggere (med før- og etter-eksempler)

En god ledetekst til en AI-appbygger beskriver produktet, ikke koden: hvem som bruker det, hva de gjør steg for steg, hvilke data det lagrer, og hvem som har lov til å se hva. Etter at første versjon finnes, be om én konkret endring per melding, si hva som må være likt, og beskriv problemer som «jeg gjorde X, forventet Y, fikk Z». Disse tre vanene løser de fleste skuffende resultatene.

Resten av denne guiden viser mønstrene i detalj, med før- og etter-eksempler du kan tilpasse.

Hvorfor det er annerledes å skrive ledetekster til en appbygger enn å chatte med en AI

Når du stiller et chat-verktøy et spørsmål, gir en vag ledetekst et vagt svar, og så går du videre. Når du skriver til en AI-appbygger, er svaret et kjørende program. Hvert hull i beskrivelsen din fylles med en gjetning, og gjetningene blir til kode, databasetabeller og skjermbilder som du må leve med eller reversere.

Så målet med en ledetekst er ikke å høres smart ut. Det er å etterlate færre viktige beslutninger til tilfeldighet. Du trenger ikke teknisk ordforråd for det. Du må være spesifikk om det bare du vet: brukerne dine, arbeidsflyten din og reglene dine.

Hva du bør ta med i første ledeteksten

Før du skriver noe, svar på disse spørsmålene. Hvert av dem lukker et hull AI-en ellers ville gjettet på.

Den siste raden undervurderes. Å si hva du ikke vil ha, stopper AI-en fra å legge til en blogg, en prisside og en nyhetsbrevpåmelding du aldri ba om.

Før og etter: den første ledeteksten

Før:

Lag en app til treningsstudioet mitt.

Byggeren må gjette alt: medlemmer eller ansatte? Hold eller personlig trening? Betaling? Du får noe som ser ut som en treningsside og ikke gjør det du trenger.

Etter:

Bygg en timebookingapp for et lite yogastudio. Medlemmer ser ukens timer (navn, instruktør, tidspunkt, ledige plasser), booker en plass og avbestiller inntil to timer før. Medlemmer registrerer seg med e-post og passord. Studioeieren logger inn for å legge til timer, se hvem som er booket og registrere oppmøte. Lagre timer, medlemmer og bookinger i en database. Rolig, lys design som fungerer godt på mobil. Ingen betaling ennå.

Den andre versjonen er fortsatt kort. Den svarer bare på spørsmålene i tabellen over.

Beskriv oppførsel, ikke implementering

Du får ofte bedre resultater ved å beskrive hva som skal skje, i stedet for hvordan det skal bygges.

Før:

Legg til en useEffect som henter bookinger og en modal-komponent for redigering.

Etter:

Når eieren klikker på en booking, åpne et panel der de kan endre tidspunktet eller avbestille. Endringer skal vises med en gang i listen.

Den første ledeteksten låser AI-en til en bestemt teknikk som kanskje ikke passer til hvordan appen er bygget. Den andre forteller hva resultatet skal være, og lar AI-en velge riktig tilnærming for koden den allerede har skrevet. Hvis du er utvikler og har en sterk preferanse, si det, men kombiner det med resultatet.

Vær konkret om reglene

Forretningsregler er der AI-bygde apper oftest går galt, fordi de er åpenbare for deg og usynlige for AI-en. Skriv dem ut.

• Grenser: «Et medlem kan ha maks tre fremtidige bookinger.»
• Tidspunkter: «Avbestillinger stenger to timer før timen starter.»
• Kantsituasjoner: «Hvis en time er full, vis en venteliste-knapp i stedet for Book.»
• Tilganger: «Instruktører kan se oppmøte for sine egne timer, men ikke for andre instruktørers.»

Hver av disse er én setning. Hvis du utelater en av dem, vil appen enten ikke håndheve regelen, eller finne opp sin egen versjon av den.

Etter første versjon: én endring per melding

Når noe kjører i forhåndsvisningen, gå fra å beskrive hele produktet til å be om små endringer du kan sjekke.

Før:

Designet er feil, bookingen fungerer ikke ordentlig, og jeg vil ha en kalendervisning og e-poster.

Etter (som fire separate meldinger):

1. Når jeg booker den siste plassen i en time, står det fortsatt «1 plass igjen». Det skal stå «Full» og Book-knappen skal skjules.
2. Legg til en ukekalender på timeplan-siden, en kolonne per dag. Behold den nåværende listevisningen som et alternativ.
3. Gjør timekortene mer kompakte på mobil: mindre padding, instruktørnavnet på samme linje som tidspunktet.
4. Send medlemmet en bekreftelses-e-post når de booker.

Hvorfor dette fungerer:

• Hver endring er liten nok til at AI-en får den riktig i ett pass.
• Du kan teste hver enkelt før du går videre.
• Hvis en går galt, kan du rulle tilbake akkurat det steget uten å miste de andre.

Si hva som skal beholdes

Når du ber om en endring på noe som allerede fungerer, si hva som ikke må endres. Dette er det enkleste middelet mot regresjoner (ting som fungerte før og går i stykker etter en endring).

Gi forsiden en ny hero-seksjon med større overskrift og et bilde til høyre. Behold navigasjonen, fargene og alt under hero-seksjonen akkurat slik det er.

Det samme gjelder data: «Legg til et telefonnummerfelt for medlemmer. Ikke fjern eller gi nytt navn til eksisterende felt.»

Bruk skjermbilder og nøyaktig tekst

Ord som «tingen øverst» er tvetydige. De fleste AI-appbyggere tar imot bilder, og et skjermbilde med en kort notis er raskere enn et avsnitt med beskrivelse.

• Legg ved et skjermbilde og skriv «knappen med rød ring overlapper menyen på mobil».
• Lim inn den nøyaktige teksten i feilmeldinger i stedet for å omskrive den.
• Sitér knappetekster nøyaktig: «Lagre endringer-knappen på innstillingssiden».

For feil spesielt, bruk denne formen:

På bookingsiden klikket jeg Avbestill på en booking for i morgen. Jeg forventet at den skulle forsvinne fra listen min. I stedet skjedde ingenting, og bookingen er fortsatt der etter at jeg oppdaterer siden. Fiks det og sjekk at avbestilling fungerer.

Vår guide om hvordan du feilsøker en AI-bygget app går dypere på dette.

Planlegg først ved store endringer

For alt som berører mange deler av appen, for eksempel å legge til brukerkontoer i en app som ikke hadde det, legge til betaling eller endre hvordan data er strukturert, be om en plan før noen kode endres.

Før du endrer noe, forklar hvordan du ville legge til teamkontoer: hvilke nye tabeller, hvilke sider som endres, og hva som skjer med eksisterende brukere. Ikke endre kode ennå.

Les planen. Hvis den misforstår noe, er det mye billigere å rette et avsnitt enn en ferdig funksjon. Mange byggere har en egen modus for dette; på Mythex er det Plan-modus, sammen med Build og Ask.

Hva du bør unngå

Når det gjelder API-nøkler: hvis du trenger en betalings- eller e-posttjeneste, legg nøklene i prosjektets hemmeligheter i stedet for i ledeteksten. Se hva miljøvariabler og hemmeligheter er hvis det er nytt for deg.

Gjenbrukbare ledeteksmaler

Tilpass disse ved å erstatte de hakeparentesede delene.

Ny app:

Bygg en [type app] for [hvem]. De [hovedflyt, steg for steg]. [Annen type bruker] logger inn for å [hva de gjør]. Lagre [data] i en database. [Utseende og følelse]. Utelat [ting til senere].

Ny funksjon:

Legg til [funksjon] på [siden]. Når [bruker] gjør [handling], skal [hva som skal skje]. Bare [hvem] kan [gjøre det]. Behold [eksisterende ting] som de er.

Designendring:

På [siden], endre [spesifikt element] til [spesifikk endring]. Behold [hva som skal beholdes]. Sjekk at det ser riktig ut på en skjerm i telefonbredde.

Feil:

På [side] gjorde jeg [steg]. Jeg forventet [forventet]. I stedet [faktisk, pluss nøyaktig feiltekst]. Fiks det og verifiser at flyten fungerer.

Spørsmål uten endringer:

Ikke endre noen kode. Forklar hvordan [del av appen] fungerer, og hvor [data] lagres.

Skrive en lengre spesifikasjon

For større prosjekter kan det hjelpe å skrive en brief på én side først og lime den inn som din første ledetekst: brukerne, kjerneflytene, dataene, reglene og det som er utenfor omfanget. Du kan til og med få en AI til å hjelpe deg med å utarbeide den. Vår guide om hvordan du skriver en produktkravspesifikasjon med AI forklarer hvordan. Hold bare den første byggeforespørselen til kjerneflyten, og legg til resten steg for steg.

Ledetekster i Mythex

Alt over fungerer i Mythex. Noen konkrete ting som hjelper:

• Build-, Plan- og Ask-modus. Bruk Plan for store eller risikable endringer, og Ask når du vil ha en forklaring uten redigeringer.
• Sjekkpunkter. Etter hver vellykket endring lagrer Mythex et sjekkpunkt, og Gå tilbake til dette punktet på et svar ruller prosjektet tilbake. Du kan også redigere en tidligere melding og sende den på nytt for å prøve en annen ledetekst fra det punktet.
• Hemmelighetskort. Når agenten trenger en API-nøkkel, spør den via et kort i chatten, slik at verdien lagres som en prosjekthemmelighet i stedet for å skrives inn i meldingen din.
• Bilder. Legg ved skjermbilder eller mockups, så ser agenten på dem.

Dokumentasjonen har en kort side om effektive ledetekster og en om å iterere uten å bygge på nytt. Hvis du starter fra bunnen av, går hvordan du bygger en app med AI gjennom et helt prosjekt, og hvordan du designer en fin app med AI dekker ledetekster for visuell finpuss.

Spørsmål