Oppaat

Näin kirjoitat kehotteita tekoälysovelluskehittäjille (esimerkein ennen ja jälkeen)

Hyvä kehote tekoälysovelluskehittäjälle kuvaa tuotteen, ei koodia: kuka sitä käyttää, mitä he tekevät askel askeleelta, mitä dataa se tallentaa ja kenen on sallittu nähdä mitä. Kun ensimmäinen versio on olemassa, pyydä yhtä tiettyä muutosta viestiä kohden, kerro mikä pysyy samana ja kuvaa ongelmat muodossa „Tein X, odotin Y, sain Z”. Nämä kolme tapaa korjaavat useimmat pettymykset.

Loppuosa oppaasta näyttää mallit tarkemmin esimerkein ennen ja jälkeen, joita voit muokata omiisi.

Miksi sovelluskehittäjälle kirjoittaminen eroaa chattaamisesta tekoälyn kanssa

Kun kysyt chat-avustajalta kysymyksen, epämääräinen kysymys saa epämääräisen vastauksen, ja siirryt eteenpäin. Kun kirjoitat tekoälysovelluskehittäjälle, vastaus on toimiva ohjelma. Jokainen aukko kuvauksessasi täytetään arvauksella, ja arvaukset muuttuvat koodiksi, tietokantatauluiksi ja näkymiksi, joiden kanssa sinun pitää elää tai jotka sinun pitää purkaa.

Kehotteen tavoite ei siis ole kuulostaa älykkäältä. Se on jättää vähemmän tärkeitä päätöksiä sattuman varaan. Tarvitset siihen teknistä sanastoa vähemmän kuin tarkkuutta asioissa, jotka vain sinä tiedät: käyttäjät, työnkulku ja säännöt.

Mitä ensimmäiseen kehotteeseen kuuluu

Ennen kuin kirjoitat mitään, vastaa näihin kysymyksiin. Jokainen niistä sulkee aukon, jonka tekoäly muuten arvaisi.

MainitseMiksi se on tärkeääEsimerkki
Tuote yhdellä lauseellaAsettaa kehyksen kaikille myöhemmille päätöksille„Varausjärjestelmä kaksipaikkaiselle parturiliikkeelle”
Kuka sitä käyttääMäärää näkymät ja sävyn„Satunnaiset asiakkaat puhelimella ja omistaja kannettavalla”
Pääasiallinen kulku askel askeleeltaAsia, jonka pitää toimia ensin„Valitse palvelu, valitse aika, syötä nimi ja puhelinnumero, saa vahvistus”
Data, jota se tallentaaMuuttuu tietokantasuunnitelmaksi„Palvelut, varaukset, asiakkaat”
Kuka saa nähdä tai muuttaa mitäMäärää kirjautumisen ja oikeudet„Vain omistaja näkee kaikki varaukset”
Ulkoasu lyhyestiEstää yleisen oletustyylin„Tumma, yksinkertainen, isot painikkeet”
Mitä jätetään pois toistaiseksiPitää ensimmäisen version pienenä„Ei vielä maksuja tai arvioita”

Tuo viimeinen rivi on aliarvostettu. Kun sanot, mitä et halua, tekoäly ei lisää blogia, hinnoittelusivua ja uutiskirjeen tilausta, joita et pyytänyt.

Ennen ja jälkeen: ensimmäinen kehote

Ennen:

Tee minulle sovellus kuntosalilleni.

Rakentajan pitää arvata kaikki: jäsenet vai henkilökunta? Ryhmäliikunta vai henkilökohtainen valmennus? Maksut? Saat jotain, mikä näyttää kuntosalin verkkosivulta eikä tee mitään, mitä tarvitset.

Jälkeen:

Rakenna pienen joogastudion ryhmävarausten sovellus. Jäsenet näkevät tämän viikon tunnit (nimi, ohjaaja, aika, vapaita paikkoja), varaavat paikan ja voivat perua sen kaksi tuntia ennen alkua. Jäsenet rekisteröityvät sähköpostilla ja salasanalla. Studion omistaja kirjautuu lisätäkseen tunteja, näkee kuka on varannut ja merkitsee läsnäolon. Tallenna tunnit, jäsenet ja varaukset tietokantaan. Rauhallinen, vaalea ulkoasu, joka toimii hyvin puhelimella. Ei maksuja vielä.

Toinen versio on edelleen lyhyt. Se vain vastaa taulukon kysymyksiin.

Kuvaa käyttäytyminen, ei toteutusta

Saat usein parempia tuloksia, kun kuvaat, mitä pitää tapahtua, eikä sitä, miten se rakennetaan.

Ennen:

Lisää useEffect, joka hakee varaukset, ja muokkausikkunan komponentti.

Jälkeen:

Kun omistaja klikkaa varausta, avaa paneeli, jossa hän voi muuttaa aikaa tai perua varauksen. Muutosten pitää näkyä heti listassa.

Ensimmäinen kehote lukitsee tekoälyn tiettyyn tekniikkaan, joka ei välttämättä sovi siihen, miten sovellus on rakennettu. Toinen kertoo lopputuloksen ja antaa sen valita oikean tavan jo kirjoitetulle koodille. Jos olet kehittäjä ja sinulla on vahva mielipide, kerro se, mutta yhdistä se lopputulokseen.

Ole tarkka säännöistä

Liiketoimintasäännöt ovat kohta, jossa tekoälyllä tehdyt sovellukset useimmin menevät vikaan, koska ne ovat sinulle ilmeisiä ja tekoälylle näkymättömiä. Kirjoita ne auki.

  • Rajat: „Jäsenellä voi olla enintään kolme tulevaa varausta.”
  • Ajoitus: „Peruutukset sulkeutuvat kaksi tuntia ennen tunnin alkua.”
  • Reunatapaukset: „Jos tunti on täynnä, näytä Varaa-painikkeen sijaan jonotuspainike.”
  • Oikeudet: „Ohjaajat näkevät oman tuntinsa läsnäolon mutta eivät muiden ohjaajien.”

Jokainen näistä on yksi lause. Jos jätät minkä tahansa pois, sovellus joko ei noudata sääntöä tai keksii oman versionsa siitä.

Ensimmäisen version jälkeen: yksi muutos viestiä kohden

Kun jokin on käynnissä esikatselussa, siirry kuvaamasta koko tuotetta ja pyydä pieniä, tarkistettavia muutoksia.

Ennen:

Ulkoasu on pielessä, varaus ei toimi kunnolla, ja haluan kalenterinäkymän ja sähköpostit.

Jälkeen (neljä erillistä viestiä):

  1. Kun varaan tunnin viimeisen paikan, tunti näyttää edelleen „1 paikka vapaana”. Sen pitäisi näyttää „Täynnä” ja piilottaa Varaa-painike.
  2. Lisää viikkonäkymän kalenteri aikataulusivulle, yksi sarake per päivä. Pidä nykyinen listanäkymä vaihtoehtona.
  3. Tee tuntikorteista tiiviimmät puhelimella: pienempi sisennys, ohjaajan nimi samalle riville kellonajan kanssa.
  4. Lähetä jäsenelle vahvistussähköposti, kun hän varaa.

Miksi tämä toimii:

  • Jokainen muutos on tarpeeksi pieni, jotta tekoäly saa sen oikein yhdellä kierroksella.
  • Voit testata jokaisen ennen seuraavaan siirtymistä.
  • Jos yksi menee vikaan, voit palauttaa vain sen vaiheen menettämättä muita.

Kerro, mitä pitää säilyttää

Kun pyydät muutosta johonkin, joka jo toimii, kerro tekoälylle, mitä ei saa muuttaa. Tämä on helpoin tapa estää regressiot (asioita, jotka toimivat aiemmin ja hajoavat muokkauksen jälkeen).

Suunnittele etusivun pääotsikko uudelleen isommalla otsikolla ja kuvalla oikealla. Pidä navigaatio, värit ja kaikki pääotsikon alapuolella täsmälleen ennallaan.

Sama pätee dataan: „Lisää jäsenille puhelinnumerokenttä. Älä poista tai nimeä uudelleen olemassa olevia kenttiä.”

Käytä kuvakaappauksia ja tarkkaa tekstiä

Sanat kuten „se asia ylhäällä” ovat epäselviä. Useimmat tekoälysovelluskehittäjät hyväksyvät kuvia, ja kuvakaappaus lyhyellä muistiinpanolla on nopeampi kuin kappale kuvausta.

  • Liitä kuvakaappaus ja kirjoita „punaisella ympyröity painike menee päällekkäin valikon kanssa puhelimilla”.
  • Liitä virheilmoitus kirjaimellisesti sen sijaan, että parafraasaisit sen.
  • Lainaa näytöllä näkyvät nimet tarkasti: „Asetukset-sivun Tallenna muutokset -painike”.

Virheissä käytä tätä muotoa:

Varaussivulla klikkasin huomisen varauksen kohdalta Peruuta. Odotin, että se katoaa listalta. Mitään ei kuitenkaan tapahtunut, ja varaus on yhä listalla päivityksen jälkeen. Korjaa se ja tarkista, että peruutus toimii.

Oppaamme tekoälyllä rakennetun sovelluksen virheiden etsimisestä menee tähän syvemmälle.

Suunnittele ensin isoissa muutoksissa

Koskettaa paljon osia sovelluksessa — käyttäjätilien lisääminen sovellukseen, jossa niitä ei ollut, maksujen lisääminen tai datan rakenteen muuttaminen — pyydä suunnitelma ennen kuin koodi muuttuu.

Ennen kuin muutat mitään, selitä, miten lisäisit tiimitilit: mitä uusia tauluja tulee, mitkä sivut muuttuvat ja mitä tapahtuu olemassa oleville käyttäjille. Älä vielä muokkaa koodia.

Lue suunnitelma. Jos se ymmärtää jotain väärin, yhden kappaleen korjaaminen on paljon halvempaa kuin valmiin ominaisuuden korjaaminen. Monilla rakentajilla on tähän oma tila; Mythexissä se on Suunnittelu-tila, rinnalla Rakenna ja Kysy.

Mitä välttää

VältäMiksiSen sijaan
„Tee siitä parempi” / „Tee siitä näyttävä”Ei kohdetta, joten tekoäly muuttaa asioita sattumanvaraisestiNimeä muutos: „enemmän tilaa osioiden välillä, isommat otsikot”
Yksi valtava kehote kymmenellä ominaisuudellaVirheet kasautuvat; vaikea testataYksi ominaisuus viestiä kohden
API-avainten liittäminen chattiinAvaimet jäävät chat-historiaanKäytä rakentajan salaisuuksia tai ympäristöasetuksia
Väittely rikkinäisestä tuloksestaJokainen korjaus kasaantuu virheen päällePalauta, ja muotoile uudelleen
Koodin määrittäminen, jota et ymmärräLukitsee huonon sovituksenKuvaa haluamasi toiminta
„Yritystason tietoturvan” pyytäminenEi tarkoita mitään tarkkaaListaa todelliset säännöt: kuka näkee mitä

API-avaimista: jos tarvitset maksu- tai sähköpostipalvelun, laita sen avaimet projektin salaisuuksiin kehotteen sijaan. Katso mitä ympäristömuuttujat ja salaisuudet ovat, jos aihe on uusi.

Uudelleenkäytettävät kehotemallit

Muokkaa näitä vaihtamalla hakasulkeiden osat.

Uusi sovellus:

Rakenna [sovelluksen tyyppi] käyttäjille [kenelle]. He [pääasiallinen kulku askel askeleelta]. [Toinen käyttäjätyyppi] kirjautuu [mitä he tekevät]. Tallenna [data] tietokantaan. [Ulkoasu]. Jätä [myöhempiin vaiheisiin kuuluvat asiat] pois.

Uusi ominaisuus:

Lisää [ominaisuus] sivulle [sivu]. Kun [käyttäjä] tekee [toiminto], [mitä pitää tapahtua]. Vain [kuka] voi [tehdä sen]. Pidä [olemassa olevat asiat] ennallaan.

Ulkoasumuutos:

Muuta sivulla [sivu] elementti [tarkka elementti] muotoon [tarkka muutos]. Pidä [mitä säilytetään]. Tarkista, että se näyttää oikealta puhelimen leveyden näytöllä.

Virhe:

Sivulla [sivu] tein [vaiheet]. Odotin [odotettu]. Sen sijaan [todellinen, mukaan lukien virheilmoituksen tarkka teksti]. Korjaa se ja varmista, että kulku toimii.

Kysymys ilman muutoksia:

Älä muuta koodia. Selitä, miten [sovelluksen osa] toimii ja mihin [data] tallennetaan.

Pidemmän määrittelyn kirjoittaminen

Isommissa projekteissa voi auttaa kirjoittaa ensin yhden sivun pohja ja liittää se avauskehotteeksi: käyttäjät, ydinkulut, data, säännöt ja se, mikä on rajauksen ulkopuolella. Voit jopa pyytää tekoälyä auttamaan luonnoksen laatimisessa — oppaamme tuotevaatimusmäärittelyn kirjoittamisesta tekoälyllä kertoo miten. Rajaa vain ensimmäinen rakennuspyyntö ydinkulkuun ja lisää loput askel kerrallaan.

Kehottaminen Mythexissä

Kaikki yllä oleva toimii Mythexissä. Muutama asia, jotka auttavat:

  • Rakenna-, Suunnittelu- ja Kysy-tilat. Käytä Suunnittelua suurille tai riskialttiille muutoksille ja Kysy-tilaa, kun haluat selityksen ilman muokkauksia.
  • Tarkistuspisteet. Jokaisen onnistuneen muutoksen jälkeen Mythex tallentaa tarkistuspisteen, ja vastauksen Palauta tähän kohtaan -toiminto palauttaa projektin siihen. Voit myös muokata aiempaa viestiä ja lähettää sen uudelleen kokeillaksesi eri kehotetta siitä kohdasta.
  • Salaisuuskortti. Kun agentti tarvitsee API-avaimen, se pyytää sitä chatissa olevan kortin kautta, jolloin arvo tallentuu projektin salaisuutena eikä kirjoitu viestiisi.
  • Kuvat. Liitä kuvakaappauksia tai luonnoksia, ja agentti katsoo ne.

Dokumentaatiossa on lyhyt sivu tehokkaista kehotteista ja sivu iteroinnista ilman uudelleenrakentamista. Jos aloitat tyhjästä, näin rakennat sovelluksen tekoälyllä käy läpi koko projektin, ja näin suunnittelet hyvännäköisen sovelluksen tekoälyllä kertoo kehotteista visuaaliseen viimeistelyyn.

Kysymykset

Kuinka pitkän kehotteen tekoälysovelluskehittäjälle kannattaa kirjoittaa?

Ensimmäiseen versioon riittää yleensä lyhyt kappale, joka on neljästä kahdeksaan lausetta: kuka sovellusta käyttää, pääasiallinen kulku, data jota se tallentaa ja kuka saa nähdä mitä. Sen jälkeen lyhyet kehotteet, jotka pyytävät yhtä muutosta kerrallaan, toimivat paremmin kuin pitkät.

Pitäisikö minun kertoa tekoälylle, mitä ohjelmointikieltä tai kehystä käyttää?

Vain jos sinulla on siihen syy, kuten kehittäjä, joka ottaa koodin jatkossa hoitaakseen, tai palvelu, joka toimii vain tietyllä pinolla. Muuten kuvaa tuote ja anna rakentajan valita järkevät oletukset.

Miksi tekoäly muuttaa asioita, joita en pyytänyt muuttamaan?

Yleensä siksi, että kehote oli laaja (”tee siitä parempi”) tai siinä ei sanottu, mitä pitää säilyttää. Nimeä tarkasti muutettava asia, kerro mikä pysyy samana ja pyydä yksi muutos viestiä kohden.

Onko parempi korjata huono tulos lisäkehotteilla vai aloittaa alusta?

Jos viimeisin muutos heikensi tilannetta, palaa edelliseen versioon ja muotoile pyyntö uudelleen sen sijaan, että kasaat korjauksia päällekkäin. Aloita uusi projekti vain silloin, kun idea itsessään on muuttunut.

Mythex · Pricing · Rakenna mitä tahansa tekoälyllä · Verkkosivu- ja sovellusmallipohjat · Mythex vertailussa · Tekoälysovellusten rakentamisen sanasto · Ilmaiset työkalut tekoälysovellusten rakentamiseen · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)