Cum scrii prompturi pentru generatoarele de aplicații AI (cu exemple înainte și după)
Un prompt bun pentru un generator de aplicații AI descrie produsul, nu codul: cine îl folosește, ce face pas cu pas, ce date păstrează și cine are voie să vadă ce. După ce există prima versiune, cere câte o schimbare specifică pe mesaj, spune ce trebuie să rămână la fel și descrie problemele ca „am făcut X, mă așteptam la Y, a ieșit Z”. Aceste trei obiceiuri rezolvă majoritatea rezultatelor care dezamăgesc.
Restul ghidului arată modelele în detaliu, cu exemple înainte și după pe care le poți adapta.
De ce promptarea unui generator de aplicații este diferită de chatul cu un AI
Când pui o întrebare unui asistent de chat, un prompt vag primește un răspuns vag și treci mai departe. Când promptezi un generator de aplicații AI, răspunsul este un program care rulează. Fiecare lacună din descrierea ta este completată cu o presupunere, iar presupunerile devin cod, tabele de baze de date și ecrane pe care apoi trebuie să le suporți sau să le desfaci.
Așadar scopul unui prompt nu este să sune inteligent. Este să lase cât mai puține decizii importante la voia întâmplării. Nu ai nevoie de vocabular tehnic pentru asta. Ai nevoie să fii specific în legătură cu lucrurile pe care doar tu le știi: utilizatorii, fluxul de lucru și regulile tale.
Ce să incluzi într-un prim prompt
Înainte să scrii ceva, răspunde la aceste întrebări. Fiecare închide o lacună pe care AI-ul ar ghici-o altfel.
| Include | De ce contează | Exemplu |
|---|---|---|
| Produsul într-o propoziție | Stabilește cadrul pentru fiecare decizie ulterioară | „Un site de programări pentru un salon de frizerie cu două fotolii” |
| Cine îl folosește | Decide ecranele și tonul | „Clienți fără programare, pe telefon, și proprietarul, pe laptop” |
| Fluxul principal, pas cu pas | Lucrul care trebuie să funcționeze primul | „Alege un serviciu, alege o oră, introdu numele și telefonul, primești o confirmare” |
| Datele pe care le păstrează | Devin designul bazei de date | „Servicii, programări, clienți” |
| Cine poate vedea sau modifica ce | Decide autentificarea și permisiunile | „Doar proprietarul vede toate programările” |
| Aspectul și senzația, pe scurt | Evită un stil implicit generic | „Întunecat, simplu, butoane mari” |
| Ce lași deoparte deocamdată | Menține prima versiune mică | „Fără plăți sau recenzii încă” |
Acest ultim rând este subestimat. Spunând ce nu vrei, îl oprești pe AI să adauge un blog, o pagină de prețuri și un formular de newsletter pe care nu le-ai cerut.
Înainte și după: primul prompt
Înainte:
Fă-mi o aplicație pentru sala mea de sport.
Generatorul trebuie să ghicească totul: membri sau angajați? Cursuri sau antrenament personal? Plăți? Vei primi ceva care arată ca un site de sală și nu face nimic din ce ai nevoie.
După:
Construiește o aplicație de rezervare a cursurilor pentru un mic studio de yoga. Membrii văd cursurile din această săptămână (nume, profesor, oră, locuri rămase), rezervă un loc și anulează cu cel puțin două ore înainte. Membrii se înregistrează cu e-mail și parolă. Proprietarul studioului se autentifică ca să adauge cursuri, să vadă cine este rezervat și să marcheze prezența. Păstrează cursurile, membrii și rezervările într-o bază de date. Design calm, luminos, care funcționează bine pe telefoane. Fără plăți deocamdată.
A doua versiune este tot scurtă. Doar răspunde la întrebările din tabelul de mai sus.
Descrie comportamentul, nu implementarea
Deseori obții rezultate mai bune descriind ce ar trebui să se întâmple, în loc să descrii cum să construiești.
Înainte:
Adaugă un useEffect care aduce rezervările și o componentă modal pentru editare.
După:
Când proprietarul apasă pe o rezervare, deschide un panou în care poate schimba ora sau o poate anula. Modificările ar trebui să apară imediat în listă.
Primul prompt blochează AI-ul într-o tehnică specifică, care s-ar putea să nu se potrivească felului în care este construită aplicația. Al doilea îi spune rezultatul și îl lasă să aleagă abordarea potrivită pentru codul pe care l-a scris deja. Dacă ești dezvoltator și ai o preferință puternică, spune-o, dar împreună cu rezultatul.
Fii concret în privința regulilor
Regulile de business sunt locul unde aplicațiile construite cu AI greșesc cel mai des, pentru că ție ți se par evidente, iar AI-ului îi sunt invizibile. Scrie-le explicit.
- Limite: „Un membru poate avea cel mult trei rezervări viitoare.”
- Termene: „Anulările se închid cu două ore înainte de începerea cursului.”
- Cazuri limită: „Dacă un curs este plin, arată un buton de listă de așteptare în loc de Rezervă.”
- Permisiuni: „Profesorii își pot vedea prezența la propriile cursuri, dar nu și pe cea a altor profesori.”
Fiecare dintre acestea este o propoziție. Dacă lipsește una, aplicația fie nu va aplica regula, fie își va inventa propria versiune.
După prima versiune: o schimbare pe mesaj
Odată ce ceva rulează în previzualizare, treci de la descrierea întregului produs la cereri de schimbări mici, care pot fi verificate.
Înainte:
Designul nu e bun, rezervarea nu funcționează cum trebuie și vreau o vizualizare în calendar și e-mailuri.
După (ca patru mesaje separate):
- Când rezerv ultimul loc dintr-un curs, cursul încă arată „1 loc rămas”. Ar trebui să arate „Complet” și să ascundă butonul Rezervă.
- Adaugă pe pagina programului o vizualizare de calendar pe săptămână, cu o coloană pentru fiecare zi. Păstrează vizualizarea listă actuală ca opțiune.
- Fă cardurile cursurilor mai compacte pe telefoane: padding mai mic, numele profesorului pe aceeași linie cu ora.
- Trimite membrului un e-mail de confirmare când face o rezervare.
De ce funcționează asta:
- Fiecare schimbare este suficient de mică pentru ca AI-ul să o facă bine dintr-o dată.
- Poți testa fiecare schimbare înainte să treci mai departe.
- Dacă una merge prost, poți reveni doar la acel pas, fără să pierzi celelalte.
Spune ce trebuie păstrat
Când ceri o schimbare la ceva care deja funcționează, spune ce nu trebuie să se schimbe. Acesta este cel mai simplu mod de a opri regresiile (lucruri care mergeau și se strică după o modificare).
Redesenează secțiunea principală de pe pagina de start cu un titlu mai mare și o fotografie în dreapta. Păstrează navigarea, culorile și tot ce este sub secțiunea principală exact cum este.
La fel se aplică și datelor: „Adaugă un câmp pentru numărul de telefon la membri. Nu șterge și nu redenumi niciun câmp existent.”
Folosește capturi de ecran și text exact
Cuvinte ca „chestia de sus” sunt ambigue. Majoritatea generatoarelor de aplicații AI acceptă imagini, iar o captură de ecran cu o notă scurtă este mai rapidă decât un paragraf de descriere.
- Atașează o captură și scrie „butonul încercuit cu roșu se suprapune peste meniu pe telefoane”.
- Lipește textul exact al oricărui mesaj de eroare, în loc să îl parafrazezi.
- Citează exact etichetele de pe ecran: „butonul Salvează modificările de pe pagina Setări”.
Pentru erori, folosește această structură:
Pe pagina de rezervări, am apăsat Anulează pentru o rezervare de mâine. Mă așteptam ca ea să dispară din listă. În schimb, nu s-a întâmplat nimic, iar rezervarea este tot acolo și după reîncărcare. Repar-o și verifică dacă anularea funcționează.
Ghidul nostru despre cum depanezi o aplicație construită cu AI merge mai departe pe acest subiect.
Planifică înainte pentru schimbările mari
Pentru orice atinge multe părți ale aplicației — adăugarea conturilor de utilizator la o aplicație care nu avea, adăugarea plăților, schimbarea modului în care sunt structurate datele — cere un plan înainte ca vreun cod să fie modificat.
Înainte să schimbi ceva, explică-mi cum ai adăuga conturi de echipă: ce tabele noi, ce pagini se schimbă și ce se întâmplă cu utilizatorii existenți. Nu edita codul încă.
Citește planul. Dacă înțelege greșit ceva, corectarea unui paragraf costă mult mai puțin decât corectarea unei funcționalități terminate. Multe generatoare au un mod dedicat pentru asta; pe Mythex este modul Plan, alături de Build și Ask.
Ce să eviți
| Evită | De ce | În loc de |
|---|---|---|
| „Fă-o mai bună” / „Fă-o să strălucească” | Nu are un țel, deci AI-ul schimbă lucruri la întâmplare | Numește schimbarea: „mai mult spațiu între secțiuni, titluri mai mari” |
| Un prompt gigant cu zece funcționalități | Erorile se adună; greu de testat | O funcționalitate pe mesaj |
| Lipirea cheilor API în chat | Cheile ajung în istoricul chatului | Folosește secretele sau setările de mediu ale generatorului |
| Discuția cu un rezultat stricat | Fiecare reparație se adaugă peste eroare | Revino la versiunea anterioară, apoi reformulează |
| Specificarea unui cod pe care nu îl înțelegi | Fixează o soluție slabă | Descrie comportamentul dorit |
| Cererea de „securitate la nivel enterprise” | Nu înseamnă nimic concret | Enumeră regulile reale: cine ce poate vedea |
Despre cheile API: dacă ai nevoie de un serviciu de plăți sau de e-mail, pune cheile în secretele proiectului, nu în prompt. Vezi ce sunt variabilele de mediu și secretele dacă este un concept nou.
Șabloane de prompturi reutilizabile
Adaptează-le înlocuind părțile dintre paranteze.
Aplicație nouă:
Construiește un [tip de aplicație] pentru [cine]. Ei [flux principal, pas cu pas]. [Al doilea tip de utilizator] se autentifică pentru a [ce face]. Păstrează [date] într-o bază de date. [Aspect și senzație]. Lasă deoparte [lucruri pentru mai târziu].
Funcționalitate nouă:
Adaugă [funcționalitate] pe [pagina]. Când [utilizator] face [acțiune], [ce ar trebui să se întâmple]. Doar [cine] poate [să facă asta]. Păstrează [lucrurile existente] așa cum sunt.
Schimbare de design:
Pe [pagina], schimbă [element specific] în [schimbare specifică]. Păstrează [ce trebuie păstrat]. Verifică să arate bine pe un ecran de lățimea unui telefon.
Eroare:
Pe [pagina], am [pașii]. Mă așteptam la [așteptare]. În schimb [realitate, plus textul exact al erorii]. Repar-o și verifică dacă fluxul funcționează.
Întrebare fără modificări:
Nu schimba niciun cod. Explică-mi cum funcționează [partea aplicației] și unde sunt stocate [datele].
Scrierea unei specificații mai lungi
Pentru proiecte mai mari, poate ajuta un brief de o pagină scris mai întâi și lipit ca prim prompt: utilizatorii, fluxurile principale, datele, regulile și ce este în afara domeniului. Îl poți chiar redacta cu ajutorul unui AI — ghidul nostru despre cum scrii un document de cerințe de produs cu AI explică cum. Doar păstrează prima cerere de construire la fluxul principal și adaugă restul pas cu pas.
Promptarea în Mythex
Tot ce este mai sus funcționează în Mythex. Câteva lucruri specifice care ajută:
- Modurile Build, Plan și Ask. Folosește Plan pentru schimbări mari sau riscante și Ask când vrei o explicație fără modificări.
- Puncte de control. După fiecare schimbare reușită, Mythex salvează un punct de control, iar Revino la acest punct de pe un răspuns readuce proiectul înapoi. Poți, de asemenea, să editezi un mesaj mai vechi și să îl retrimiți, ca să încerci un alt prompt de la acel punct.
- Cardul de secrete. Când agentul are nevoie de o cheie API, cere printr-un card din chat, astfel încât valoarea este salvată ca secret al proiectului și nu scrisă în mesajul tău.
- Imagini. Atașează capturi de ecran sau mockup-uri, iar agentul se uită la ele.
Documentația are o scurtă pagină despre prompturi eficiente și una despre iterarea fără reconstruire. Dacă pornești de la zero, cum construiești o aplicație cu AI parcurge un proiect complet, iar cum proiectezi o aplicație arătoasă cu AI acoperă prompturile pentru finisajul vizual.
Întrebări
Cât de lung ar trebui să fie un prompt pentru un generator de aplicații AI?
Pentru prima versiune, de obicei ajunge un paragraf scurt de patru până la opt propoziții: cine folosește aplicația, fluxul principal, datele pe care le păstrează și cine poate vedea ce. După aceea, prompturile mai scurte care cer o singură schimbare pe rând funcționează mai bine decât cele lungi.
Ar trebui să spun AI-ului ce framework sau ce limbaj să folosească?
Doar dacă ai un motiv, de exemplu un dezvoltator care va prelua codul sau un serviciu care funcționează doar cu o anumită tehnologie. Altfel, descrie produsul și lasă generatorul să aleagă valori implicite rezonabile.
De ce schimbă AI-ul lucruri pe care nu i le-am cerut?
De obicei pentru că promptul a fost general („fă-o mai bună”) sau nu a spus ce să păstreze. Numește exact ce vrei să schimbi, spune ce trebuie să rămână la fel și cere câte o schimbare pe mesaj.
Este mai bine să repar un rezultat prost cu mai multe prompturi sau să încep de la zero?
Dacă ultima schimbare a stricat lucrurile, revino la versiunea de dinaintea ei și reformulează, în loc să pui reparații una peste alta. Începe un proiect nou doar când ideea în sine s-a schimbat.