Hogyan írjunk promptokat AI-alkalmazásépítőkhöz (előtte-utána példákkal)

Egy jó prompt AI-alkalmazásépítőnek a terméket írja le, nem a kódot: ki használja, lépésenként mit csinál, milyen adatokat tárol, és ki láthat mit. Miután létezik az első verzió, egy üzenetben egy konkrét változtatást kérj, mondd meg, mi maradjon ugyanaz, és a problémákat így írd le: „X-et csináltam, Y-t vártam, Z lett”. Ez a három szokás megoldja a legtöbb csalódást keltő eredményt.

Az útmutató többi része részletesen bemutatja a mintákat, előtte-utána példákkal, amelyeket a saját igényeidhez igazíthatsz.

Miért más egy alkalmazásépítő promptolása, mint egy AI-val való csevegés

Ha egy csevegőasszisztensnek kérdést teszel fel, egy homályos prompt homályos választ kap, és továbblépsz. Ha egy AI-alkalmazásépítőt promptolsz, a válasz egy működő program. A leírásod minden hiányát találgatással töltik ki, és ezek a találgatások kóddá, adattáblákká és képernyőkké válnak, amelyekkel aztán együtt kell élned, vagy vissza kell vonnod őket.

A prompt célja tehát nem az, hogy okosnak tűnj. Az, hogy kevesebb fontos döntés maradjon a véletlenre. Ehhez nincs szükséged műszaki szakszavakra. Pontosnak kell lenned azokban a dolgokban, amelyeket csak te tudsz: a felhasználóidról, a munkafolyamatodról és a szabályaidról.

Mit tartalmazzon egy első prompt

Mielőtt bármit leírnál, válaszolj ezekre a kérdésekre. Mindegyik egy olyan rést zár be, amelyet különben az AI találgatna.

Az utolsó sort gyakran alábecsülik. Ha kimondod, mit nem akarsz, az AI nem ad hozzá blogot, árazási oldalt és hírlevél-feliratkozást, amelyet soha nem kértél.

Előtte és utána: az első prompt

Előtte:

Csinálj nekem egy alkalmazást az edzőtermemhez.

Az építőnek mindent ki kell találnia: tagok vagy személyzet? Órák vagy személyi edzés? Fizetés? Olyasmit kapsz, ami úgy néz ki, mint egy edzőterem honlapja, és nem csinál azt, amire szükséged van.

Utána:

Építs órafoglaló alkalmazást egy kis jógastúdiónak. A tagok látják az aktuális heti órákat (név, oktató, időpont, szabad helyek), lefoglalnak egy helyet, és két órával a kezdés előtt lemondhatják. A tagok e-mail-címmel és jelszóval regisztrálnak. A stúdió tulajdonosa bejelentkezik órát hozzáadni, látni, ki van foglalva, és jelölni a jelenlétet. Az órákat, tagokat és foglalásokat adatbázisban tárold. Nyugodt, világos dizájn, amely jól működik telefonon. Egyelőre nincs fizetés.

A második változat is rövid. Csak az előbbi táblázat kérdéseire válaszol.

Viselkedést írj le, ne megvalósítást

Gyakran jobb eredményt kapsz, ha leírod, mi történjen, nem azt, hogyan építsd meg.

Előtte:

Adj hozzá egy useEffect-et, amely lekéri a foglalásokat, és egy modal komponenst a szerkesztéshez.

Utána:

Amikor a tulajdonos rákattint egy foglalásra, nyiss meg egy panelt, ahol módosíthatja az időpontot vagy lemondhatja. A változásoknak azonnal meg kell jelenniük a listában.

Az első prompt egy konkrét technikához köti az AI-t, amely nem biztos, hogy illik ahhoz, ahogyan az alkalmazás fel van építve. A második megmondja az eredményt, és hagyja, hogy a már megírt kódhoz a megfelelő megközelítést válassza. Ha fejlesztő vagy, és van erős elképzelésed, mondd ki, de párosítsd az eredménnyel.

Legyél konkrét a szabályokkal

Az üzleti szabályoknál hibázik a legtöbbször az AI-val épített alkalmazás, mert ezek neked nyilvánvalóak, az AI számára pedig láthatatlanok. Fogalmazd meg őket egyértelműen.

• Korlátok: „Egy tag legfeljebb három jövőbeli foglalást tarthat.”
• Időzítés: „A lemondás a kezdés előtt két órával lezárul.”
• Szélsőséges esetek: „Ha egy óra betelt, a Foglalás gomb helyett várólista-gombot mutass.”
• Jogosultságok: „Az oktatók csak a saját óráik jelenlétét láthatják, mások óráit nem.”

Mindegyik egy mondat. Ha bármelyiket kihagyod, az alkalmazás vagy nem fogja betartani a szabályt, vagy kitalál a saját változatát.

Az első verzió után: egy üzenet, egy változtatás

Amint valami fut az előnézetben, térj át arról, hogy az egész terméket írod le, konkrét, ellenőrizhető változtatások kérésére.

Előtte:

A dizájn nem jó, a foglalás nem működik rendesen, és szeretnék egy naptárnézetet és e-maileket.

Utána (négy külön üzenetként):

1. Amikor lefoglalom egy óra utolsó helyét, az óra még mindig „1 hely szabad”-ot mutat. „Betelt” felirattal kellene szerepelnie, a Foglalás gombot pedig elrejteni.
2. Adj a menetrend oldalhoz heti nézetű naptárt, napi egy oszloppal. A jelenlegi listanézet maradjon opcióként.
3. Tegyél tömörebbé az órakártyákat telefonon: kisebb margó, az oktató neve ugyanabban a sorban legyen az időponttal.
4. Küldj visszaigazoló e-mailt a tagnak, amikor lefoglal.

Azért működik ez:

• Minden változtatás elég kicsi ahhoz, hogy az AI egy menetben jól megcsinálja.
• Minden változtatást tesztelhetsz, mielőtt továbblépnél.
• Ha az egyik rosszul sül el, csak azt a lépést vonhatod vissza, a többit nem veszíted el.

Mondd meg, mit tartson meg

Ha egy már működő dolog változtatását kéred, mondd meg az AI-nak, mi nem változhat. Ez a legegyszerűbb módja annak, hogy megakadályozd a regressziókat (olyan dolgok elromlását, amelyek korábban működtek egy módosítás után).

Tervezd újra a főoldal fejlécét nagyobb címmel és jobb oldalon egy fotóval. Tartsd meg a navigációt, a színeket és mindent a fejléc alatt pontosan úgy, ahogy van.

Ugyanez igaz az adatokra is: „Adj telefonszám mezőt a tagokhoz. Ne törölj és ne nevezz át egyetlen meglévő mezőt sem.”

Használj képernyőképeket és pontos szöveget

Az olyan szavak, mint „a valami fent”, félreérthetőek. A legtöbb AI-alkalmazásépítő elfogad képeket, és egy képernyőkép rövid megjegyzéssel gyorsabb, mint egy bekezdésnyi leírás.

• Csatolj egy képernyőképet, és írd le: „a pirossal bekarikázott gomb telefonon átfedi a menüt”.
• Másold be egy hibaüzenet pontos szövegét, ne parafrazáld.
• Idézd pontosan a képernyőn látható feliratokat: „a Változtatások mentése gomb a Beállítások oldalon”.

Hibák esetén ezt a formát használd:

A foglalások oldalon lemondtam egy holnapi foglalást. Azt vártam, hogy eltűnik a listámból. Ehelyett nem történt semmi, és frissítés után is ott van a foglalás. Javítsd meg, és ellenőrizd, hogy a lemondás működik.

Az AI-val épített alkalmazás hibakeresése útmutatónk ezt részletesebben tárgyalja.

Nagyobb változtatásoknál előbb tervezz

Ami sok részt érint az alkalmazásban — felhasználói fiókok hozzáadása olyan appnál, amelynek nem volt, fizetések bevezetése, az adatok szerkezetének megváltoztatása —, ahhoz kérj tervet, mielőtt bármilyen kód változna.

Mielőtt bármit változtatnál, magyarázd el, hogyan adnál hozzá csapatfiókokat: mely új táblák kellenek, mely oldalak változnak, és mi történik a meglévő felhasználókkal. Még ne szerkeszd a kódot.

Olvasd el a tervet. Ha valamit félreért, egy bekezdés javítása sokkal olcsóbb, mint egy kész funkció javítása. Sok építőnek van erre külön módja; a Mythexben ez a Plan mód, a Build és az Ask mellett.

Mit kerülj

Az API-kulcsokkal kapcsolatban: ha fizetési vagy e-mail-szolgáltatásra van szükséged, a kulcsait a projekt titkos beállításaiba tedd, ne a promptba. Ha ez új neked, lásd: mik a környezeti változók és a titkos kulcsok.

Újrafelhasználható prompt-sablonok

Ezeket a zárójeles részek cseréjével alakítsd át.

Új alkalmazás:

Építs egy [alkalmazástípust] [kinek]. Ők [fő folyamat, lépésenként]. A [második felhasználótípus] bejelentkezik, hogy [mit csinál]. Az [adatok] adatbázisban tárolódjanak. [Megjelenés]. Hagyd ki [később jöhető dolgok].

Új funkció:

Adj [funkciót] a [oldalhoz]. Amikor [felhasználó] [műveletet] végez, [mi történjen]. Csak [kik] [tehetik meg]. A [meglévő dolgokat] tartsd meg úgy, ahogy vannak.

Dizájnváltoztatás:

A [oldalon] változtasd meg a [konkrét elem]et így: [konkrét változtatás]. Tartsd meg: [mit kell megtartani]. Ellenőrizd, hogy telefon-szélességű képernyőn is jól néz ki.

Hiba:

A [oldalon] ezt csináltam: [lépések]. Azt vártam: [elvárt]. Ehelyett: [tényleges, pontos hibaüzenettel]. Javítsd meg, és ellenőrizd, hogy a folyamat működik.

Kérdés változtatás nélkül:

Ne változtass semmilyen kódot. Magyarázd el, hogyan működik [az alkalmazás része], és hol tárolódnak [az adatok].

Hosszabb specifikáció írása

Nagyobb projektnél segíthet, ha előbb írsz egy egyoldalas összefoglalót, és azt illeszted be nyitó promptként: a felhasználókat, a fő folyamatokat, az adatokat, a szabályokat és azt, ami kívül esik a hatókörön. Az AI-val akár a vázlatát is megírathatod — a termékkövetelmény-dokumentum írása AI-val útmutatónk leírja, hogyan. Csak az első építési kérést tartsd a fő folyamatra, a többit lépésenként add hozzá.

Promptolás a Mythexben

Mindez működik a Mythexben. Néhány konkrét tipp:

• Build, Plan és Ask módok. A Plan-t használd nagy vagy kockázatos változtatásokhoz, az Ask-ot, ha magyarázatot kérsz szerkesztés nélkül.
• Ellenőrzőpontok. Minden sikeres változtatás után a Mythex mentést készít, és egy válasznál a Visszaállítás erre a pontra visszaforgatja a projektet. Egy korábbi üzenetet is szerkeszthetsz és újraküldhetsz, hogy onnan próbálj másik promptot.
• Titkos kulcsok kártya. Ha az ügynöknek API-kulcsra van szüksége, a csevegésben egy kártyán keresztül kéri, így az érték projekt-titokként tárolódik, nem a üzenetedbe íródik.
• Képek. Csatolj képernyőképeket vagy makettet, és az ügynök megnézi őket.

A dokumentációban van egy rövid oldal a hatékony promptokról és egy a finomításról újraépítés nélkül. Ha nulláról indulsz, a hogyan építsünk alkalmazást AI-val végigvezet egy teljes projekten, a hogyan tervezzünk jól kinéző alkalmazást AI-val pedig a vizuális finomítás promptjait mutatja be.

Kérdések