Si të shkruani prompte për ndërtuesit e aplikacioneve me AI (me shembuj para dhe pas)
Një prompt i mirë për një ndërtues aplikacionesh me AI përshkruan produktin, jo kodin: kush e përdor, çfarë bën hap pas hapi, çfarë të dhënash mban dhe kush lejohet të shohë çfarë. Pasi të ekzistojë versioni i parë, kërkoni një ndryshim specifik për mesazh, thoni çfarë duhet të mbetet e njëjtë dhe përshkruani problemet si „bëra X, prisja Y, mora Z“. Këto tre zakone rregullojnë shumicën e rezultateve zhgënjyese.
Pjesa tjetër e këtij udhëzuesi tregon modelet në detaje, me shembuj para dhe pas që mund t’i përshtatni.
Pse promptimi i një ndërtuesi aplikacionesh është ndryshe nga biseda me një AI
Kur i bëni një pyetje një asistenti chat, një prompt i paqartë merr një përgjigje të paqartë dhe ju shkoni tutje. Kur i jepni prompt një ndërtuesi aplikacionesh me AI, përgjigjia është një program që punon. Çdo boshllëk në përshkrimin tuaj mbushet me një supozim, dhe ato supozime bëhen kod, tabela të bazës së të dhënave dhe ekrane që më pas duhet t’i duronit ose t’i zhbëni.
Pra qëllimi i një prompti nuk është të tingëllojë i zgjuar. Është të lërë më pak vendime të rëndësishme në providencë. Nuk ju duhet gjuhë teknike për këtë. Ju duhet të jeni specifikë për gjërat që vetëm ju i dini: përdoruesit tuaj, rrjedha e punës dhe rregullat tuaja.
Çfarë të përfshini në prompt-in e parë
Para se të shkruani ndonjë gjë, përgjigjuni këtyre pyetjeve. Secila mbyll një boshllëk që AI përndryshe do ta merrte me supozim.
| Përfshije | Pse ka rëndësi | Shembull |
|---|---|---|
| Produkti në një fjali | Vendos kornizën për çdo vendim të mëvonshëm | „Një sit rezervimesh për një berber me dy karrige“ |
| Kush e përdor | Përcakton ekranet dhe tonin | „Klientë që hyjnë pa rezervim, në telefona, dhe pronari në laptop“ |
| Rrjedha kryesore, hap pas hapi | Gjëja që duhet të funksionojë së pari | „Zgjidh një shërbim, zgjidh një orë, shkruaj emrin dhe telefonin, merr konfirmimin“ |
| Të dhënat që mban | Bëhet dizajni i bazës së të dhënave | „Shërbime, rezervime, klientë“ |
| Kush mund të shohë ose ndryshojë çfarë | Vendos hyrjen dhe lejet | „Vetëm pronari sheh të gjitha rezervimet“ |
| Pamja dhe ndjesia, shkurt | Shmang një stil të përgjithshëm parazgjedhur | „Të errët, i thjeshtë, butona të mëdhenj“ |
| Çfarë të lihet jashtë tani | E mban versionin e parë të vogël | „Pa pagesa ose vlerësime ende“ |
Rreshti i fundit është i nënvlerësuar. Të thuash çfarë nuk do të ndalon AI-në të shtojë një blog, një faqe çmimesh dhe një formular regjistrimi për buletin që nuk i kishit kërkuar.
Para e pas: prompti i parë
Para:
Më bëj një aplikacion për palestrën time.
Ndërtuesi duhet të supozojë gjithçka: anëtarë ose staf? Klasa apo trajnim personal? Pagesa? Do të merrni diçka që duket si faqe interneti e një palestre dhe nuk bën asgjë që ju nevojitet.
Pas:
Ndërtoni një aplikacion rezervimi klasash për një studio të vogël jogaje. Anëtarët shohin klasat e kësaj jave (emri, instruktori, ora, vendet e lira), rezervojnë një vend dhe anulojnë deri dy orë më parë. Anëtarët regjistrohen me email dhe fjalëkalim. Pronari i studios hyn për të shtuar klasa, për të parë kush është rezervuar dhe për të shënuar prezencën. Ruajini klasat, anëtarët dhe rezervimet në një bazë të dhënash. Dizajn i qetë, i lehtë, që punon mirë në telefona. Pa pagesa ende.
Versioni i dytë është ende i shkurtër. Thjesht u përgjigjet pyetjeve nga tabela më sipër.
Përshkruani sjelljen, jo implementimin
Shpesh do të merrni rezultate më të mira nëse përshkruani çfarë duhet të ndodhë, në vend se si ta ndërtojë.
Para:
Shto një useEffect që merr rezervimet dhe një komponent modal për redaktim.
Pas:
Kur pronari klikon një rezervim, hap një panel ku mund të ndryshojë orën ose ta anulojë. Ndryshimet duhet të shfaqen menjëherë në listë.
Prompti i parë e detyron AI-në në një teknikë të caktuar që mund të mos përshtatet me mënyrën si është ndërtuar aplikacioni. I dyti i thotë rezultatin dhe e lë AI-në të zgjedhë qasjen e duhur për kodin që ka shkruar tashmë. Nëse jeni zhvillues dhe keni një preferencë të fortë, thuajeni, por çifteëzojeni me rezultatin.
Jini konkretë për rregullat
Rregullat e biznesit janë aty ku aplikacionet e ndërtuara me AI shpesh gabojnë, sepse janë të dukshme për ju dhe të padukshme për AI-në. Shpjegojini qartë.
- Kufijtë: „Një anëtar mund të ketë të shumtën tre rezervime të ardhshme.“
- Afatet: „Anulimet mbyllen dy orë para fillimit të klasës.“
- Raste kufitare: „Nëse një klasë është plot, shfaq një buton listë pritjeje në vend të Rezervo.“
- Lejet: „Instruktorët shohin prezencën e klasave të tyre, por jo të instruktorëve të tjerë.“
Secila nga këto është një fjali. Ta lësh pa të një nga këto do të thotë që aplikacioni ose nuk do ta zbatojë rregullin, ose do të shpikë versionin e vet.
Pas versionit të parë: një ndryshim për mesazh
Njëherë që diçka është duke punuar në pamjen paraprake, kaloni nga përshkrimi i gjithë produktit te kërkesat për ndryshime të vogla që mund t’i kontrolloni.
Para:
Dizajni është jashtë vendit, rezervimi nuk funksionon siç duhet dhe dua një pamje kalendari dhe email.
Pas (si katër mesazhe të veçanta):
- Kur rezervoj vendin e fundit në një klasë, klasa ende shfaq „1 vend të lirë“. Duhet të shfaqë „Plot“ dhe të fshehë butonin Rezervo.
- Shto një pamje kalendari javore në faqen e orarit, me një kolonë për çdo ditë. Mbaj pamjen aktuale të listës si opsion.
- Bëji kartat e klasave më kompakte në telefona: më pak hapësirë brenda, emri i instruktorit në të njëjtin rresht me orën.
- Dërgo anëtarit një email konfirmimi kur rezervon.
Pse funksionon kjo:
- Çdo ndryshim është aq i vogël sa AI ta bëjë saktë në një përpjekje.
- Mund ta testoni çdo ndryshim para se të kaloni tek tjetri.
- Nëse një gjë shkon keq, mund ta ktheni vetëm atë hap pa e humbur të tjerët.
Thoni çfarë të mbahet
Kur kërkoni një ndryshim në diçka që tashmë punon, thuajini AI-së çfarë nuk duhet të ndryshojë. Ky është mënyra më e lehtë për të ndaluar regresionet (gjëra që dikur funksiononin dhe prishen pas një redaktimi).
Ri-dizajno seksionin kryesor të faqes kryesore me një titull më të madh dhe një foto në të djathtë. Mbaj navigimin, ngjyrat dhe gjithçka poshtë seksionit kryesor pikërisht ashtu siç janë.
E njëjta gjë vlen për të dhënat: „Shto një fushë numri telefoni te anëtarët. Mos hiq dhe mos riemërto asnjë fushë ekzistuese.“
Përdorni pamje ekrani dhe tekst të saktë
Fjalë si „gjënë në krye“ janë të paqarta. Shumica e ndërtuesve të aplikacioneve me AI pranojnë imazhe, dhe një pamje ekrani me një shënim të shkurtër është më e shpejtë se një paragraf përshkrimi.
- Bashkëngjitni një pamje ekrani dhe thoni „butoni i rrethuar me të kuqe mbivendoset mbi menunë në telefona“.
- Ngjitni tekstin e saktë të çdo mesazhi gabimi në vend që ta parafrazoni.
- Citoni etiketat e ekranit saktësisht: „butoni Ruaj ndryshimet në faqen e Cilësimeve“.
Për gabimet në veçanti, përdorni këtë formë:
Në faqen e rezervimeve, klikova Anulo te një rezervim për nesër. Prisja që të zhdukej nga lista ime. Në vend të kësaj, nuk ndodhi asgjë dhe rezervimi është ende aty pas rifreskimit. Rregulloje dhe kontrollo që anulimi funksionon.
Udhëzuesi ynë mbi si të korrigjoni një aplikacion të ndërtuar me AI shkon më thellë në këtë.
Planifikoni së pari për ndryshime të mëdha
Për çdo gjë që prek shumë pjesë të aplikacionit — shtimi i llogarive të përdoruesve në një aplikacion që s’kishte, shtimi i pagesave, ndryshimi i mënyrës si strukturohen të dhënat — kërkoni një plan përpara se të ndryshohet ndonjë kod.
Para se të ndryshoni ndonjë gjë, shpjego si do të shtoja llogari ekipi: cilat tabela të reja, cilat faqe ndryshojnë dhe çfarë ndodh me përdoruesit ekzistues. Mos e ndrysho kodin ende.
Lexojeni planin. Nëse ka keqkuptuar diçka, korrigjimi i një paragrafi kushton shumë më pak sesa korrigjimi i një veçorie të përfunduar. Shumë ndërtues kanë një modalitet të veçantë për këtë; në Mythex ai është modaliteti Plan, krahas Build dhe Ask.
Çfarë të shmangni
| Shmangeni | Pse | Në vend të kësaj |
|---|---|---|
| „Bëje më mirë“ / „Bëje të bujshëm“ | Nuk ka objektiv, prandaj AI ndryshon gjëra rastësisht | Emërtoni ndryshimin: „më shumë hapësirë mes seksioneve, tituj më të mëdhenj“ |
| Një prompt gjigant me dhjetë veçori | Gabimet shumohen; vështirë për t’u testuar | Një veçori për mesazh |
| Ngjitja e çelësave API në chat | Çelësat mbeten në historikun e chat-it | Përdorni sekretet ose cilësimet e mjedisit të ndërtuesit |
| Debatimi me një rezultat të prishur | Çdo rregullim shton mbi gabimin | Ktheni prapa, pastaj riformuloni |
| Specifikimi i kodit që nuk e kuptoni | Ngulit një përshtatje të dobët | Përshkruani sjelljen që dëshironi |
| Kërkimi i „sigurisë me nivel ndërmarrjeje“ | Nuk do të thotë asgjë konkrete | Listoni rregullat e vërteta: kush mund të shohë çfarë |
Për çelësat API: nëse ju duhet një shërbim pagese ose email, vendosini çelësat te sekretet e projektit, jo në prompt. Shihni çfarë janë variablat e mjedisit dhe sekretet nëse kjo është e re për ju.
Modele promptesh të ripërdorshme
Përshtatini këto duke zëvendësuar pjesët në kllapa.
Aplikacion i ri:
Ndërtoni një [lloj aplikacioni] për [kë]. Ata [rrjedha kryesore, hap pas hapi]. [Lloji i dytë i përdoruesit] hyn për të [çfarë bën]. Ruani [të dhënat] në një bazë të dhënash. [Pamja dhe ndjesia]. Lini jashtë [gjërat për më vonë].
Veçori e re:
Shtoni [veçorinë] te [faqja]. Kur [përdoruesi] bën [veprimin], [çfarë duhet të ndodhë]. Vetëm [kush] mund [ta bëjë këtë]. Mbani [gjërat ekzistuese] ashtu siç janë.
Ndryshim dizajni:
Në [faqen], ndrysho [elementin specifik] në [ndryshimin specifik]. Mbaj [çfarë mbahet]. Kontrollo që duket mirë në një ekran me gjerësi telefoni.
Gabim:
Në [faqe], [hapat e mi]. Prisja [pritshmërinë]. Në vend të kësaj [realiteti, plus tekstin e saktë të gabimit]. Rregulloje dhe verifiko që rrjedha funksionon.
Pyetje pa ndryshime:
Mos ndrysho asnjë kod. Shpjego si funksionon [pjesa e aplikacionit] dhe ku ruhen [të dhënat].
Shkrimi i një specifikimi më të gjatë
Për projekte më të mëdha, mund të ndihmojë të shkruani fillimisht një brief një-faqësh dhe ta ngjitni si prompt hapjeje: përdoruesit, rrjedhat kryesore, të dhënat, rregullat dhe ç’është jashtë shtrirjes. Mund edhe t’i kërkoni një AI-je ta hartojë me ju — udhëzuesi ynë për si të shkruani një PRD me AI shpjegon si. Thjesht mbajeni kërkesën e parë për ndërtim të kufizuar te rrjedha kryesore, dhe shtoni pjesën tjetër hap pas hapi.
Promptimi në Mythex
Gjithçka më sipër funksionon në Mythex. Disa specifika që ndihmojnë:
- Modalitetet Build, Plan dhe Ask. Përdorni Plan për ndryshime të mëdha ose me rrezik, dhe Ask kur doni një shpjegim pa redaktime.
- Pikat e ruajtjes. Pas çdo ndryshimi të suksesshëm Mythex ruan një pikë ruajtjeje, dhe Kthehu në këtë pikë te një përgjigje e kthen projektin mbrapsht. Mund edhe të redaktoni një mesazh të mëparshëm dhe ta dërgoni përsëri për të provuar një prompt tjetër nga ai pikë.
- Kartela e sekreteve. Kur agjenti ka nevojë për një çelës API, e kërkon përmes një kartele në chat, kështu që vlera ruhet si sekret i projektit dhe nuk shkruhet në mesazhin tuaj.
- Imazhet. Bashkëngjitni pamje ekrani ose makete dhe agjenti do t’i shikojë.
Dokumentacioni ka një faqe të shkurtër mbi promptet efektive dhe një tjetër mbi përsëritjen pa rindërtuar. Nëse po filloni nga zero, si të ndërtoni një aplikacion me AI shpjegon një projekt të plotë, dhe si të dizajnoni një aplikacion të bukur me AI mbulon promptet për përmirësimin vizual.
Pyetje
Sa e gjatë duhet të jetë një prompt për një ndërtues aplikacionesh me AI?
Për versionin e parë, një paragraf i shkurtër me katër deri në tetë fjali zakonisht mjafton: kush e përdor aplikacionin, rrjedha kryesore, të dhënat që mban dhe kush mund të shohë çfarë. Pas kësaj, promptet më të shkurtra që kërkojnë një ndryshim në një herë funksionojnë më mirë se ato të gjata.
A duhet t’i them AI-së cilën kornizë ose gjuhë të përdorë?
Vetëm nëse keni një arsye, si një zhvillues që do ta marrë kodin më vonë ose një shërbim që funksionon vetëm me një stack të caktuar. Përndryshe përshkruani produktin dhe lejojeni ndërtuesin të zgjedhë parazgjedhje të arsyeshme.
Pse AI vazhdon të ndryshojë gjëra që nuk i kam kërkuar të ndryshojë?
Zakonisht sepse prompti ishte i gjerë („bëje më mirë“) ose nuk thoshte çfarë të mbahet. Emërtoni saktësisht gjënë që duhet ndryshuar, thoni çfarë duhet të mbetet e njëjtë dhe kërkoni një ndryshim për mesazh.
A është më mirë të rregulloni një rezultat të keq me prompte të tjera apo të filloni nga e para?
Nëse ndryshimi i fundit i bëri gjërat më keq, ktheni në versionin para tij dhe riformuloni, në vend që të grumbulloni rregullime mbi të tjerat. Filloni një projekt të ri vetëm kur vetë ideja ka ndryshuar.