Kuidas siluda tehisintellektiga ehitatud rakendust: praktiline meetod

Tehisintellektiga ehitatud rakenduse silumiseks tekita esmalt viga tahtlikult uuesti, kogu seejärel tõendeid — täpsed sammud, veateade ning see, mida brauseri konsool ja võrgu vahekaart näitavad — ja anna need tehisintellektile vormis „tegin X, ootasin Y, sain Z“. Kui parandus teeb asjad hullemaks, pöördu viimase töötava versiooni juurde, selle asemel et lisada parandusi peale. Selleks ei pea koodi lugema.

See juhend käsitleb tervet tsüklit, sealhulgas kiiret ülevaadet brauseri arendustööriistadest mittearendajatele.

Silumistsükkel

Iga vea parandus, olgu seda teinud inimene või tehisintellekt, järgib sama tsüklit:

1. Taasesita — tee viga usaldusväärselt uuesti esile.
2. Jälgi — kogu veateade ja see, mida rakendus parajasti tegi.
3. Kirjelda — anna tehisintellektile täpsed sammud, oodatav tulemus ja tegelik tulemus.
4. Paranda — lase tehisintellektil muuta üks asi.
5. Kontrolli — korda täpseid samme ja kinnita, et viga on kadunud ega ole midagi lähedal katki läinud.
6. Pööra tagasi vajadusel — kui läks hullemaks, võta muudatus tagasi ja proovi uuesti paremate andmetega.

Enamik aega, mis AI-ga ehitatud rakendustel kaob, läheb raisku, kui jätad vahele sammud 1, 2 ja 5: ütled „see on katki“, võtad muudatuse vastu testimata ja palud siis järgmist parandust juba katkise peale.

Samm 1: taasesita viga

Viga, mida saad soovi korral esile kutsuda, on poolenisti parandatud. Proovi leida lühim sammude jada, mis selle põhjustab.

Küsi endalt:

• Kas see juhtub alati? Kui ainult mõnikord, mis on erinev, kui see juhtub — konkreetne kirje, aeglane ühendus, välja logitud olek?
• Kas see juhtub kõigile kasutajatele? Logi sisse teise kontoga. Paljud vead ilmnevad ainult uutele kasutajatele ilma andmeteta või teise rolliga kasutajale.
• Kas see juhtub igal seadmel? Proovi telefoniekraani laiusega ja teise brauseriga.
• Kas see algas pärast konkreetset muudatust? Kui see töötas eile, on viimased muudatused peamised kahtlusalused.

Kirjuta sammud lühikese nummerdatud nimekirjana. Kleebid need hiljem prompti.

Samm 2: loe veateadet

Veateated paistavad hirmutavad, kuid vajad neist ainult mõnda osa.

Sa ei pea seda mõistma; pead seda täpselt kopeerima. „Cannot read properties of undefined (reading 'name')“ ütleb tehisintellektile, et kood ootas andmeid (tõenäoliselt broneeringut või kasutajat), mida polnud. Parafraas nagu „mingi undefined-viga“ kaotab selle info.

Mõned levinumad, ligikaudsed tõlked:

• undefined / null vead — kood ootas andmeid, mis ei saabunud. Sageli laadimisolek või tühi nimekiri, mida kood ei käsitlenud.
• 404 Not Found — lehte või API aadressi ei ole olemas. Sageli kirjaviga marsruudis või link lehele, mis on ümber nimetatud.
• 401 Unauthorized / 403 Forbidden — päring ei olnud sisse logitud või kasutajal ei ole luba seda teha.
• 500 Internal Server Error — serveripoolne kood jooksis kokku. Tegelik põhjus on serveri logides, mitte brauseris.
• CORS vead — brauser blokeeris päringu teisele domeenile. Tavaliselt on tegu serveri konfiguratsiooniprobleemiga.

Samm 3: kasuta brauseri arendustööriistu

Iga töölaua brauseril on sisseehitatud arendustööriistad („devtools“). Need näitavad, mida leht kulisside taga teeb. Chrome’is, Edge’is ja Firefoxis paremklõpsa lehel suvalist kohta ja vali Inspect (Uuri) või vajuta F12 (Macis Cmd+Option+I). Safaris pead esmalt Safari seadetes sisse lülitama menüü Develop.

Vajad ainult kolme vahekaarti.

Console

Vahekaart Console loetleb lehe koodi vead ja teated. Vead on kuvatud punasena. Kui nupp ei tee midagi, kui sellele klõpsad, näitab konsool väga sageli punast viga just klõpsamise hetkel. Kopeeri vea täielik tekst (enamikus brauserites saad paremklõpsuga kopeerimisvaliku).

Network

Vahekaart Network loetleb kõik päringud, mida leht teeb — andmete laadimine, vormi salvestamine, sisselogimine. Ava see ja korda samme, mis viga põhjustavad.

• Vaata punaseid ridu või ridu staatusega 400 või suurem.
• Klõpsa ebaõnnestunud reale, et näha selle Response (vastust). Serveriviga sisaldab sageli sõnumit, mis on kasulikum kui miski ekraanil.
• Pane tähele päringu URL-i ja staatuskoodi — lause „POST /api/bookings andis 500“ on tehisintellektile väga kasulik.

Märgi Preserve log, kui viga on seotud lehe uuesti laadimise või suunamisega, et päringud ei kaoks.

Elements

Vahekaart Elements (või Inspector) näitab lehe struktuuri ja stiile. See on kõige kasulikum paigutusvigade puhul: hiire viimisel elemendi kohale näed selle suurust ja vahesid esile tõstetuna. Muutmist ei pea siin tegema; piisab, kui ütled „jalus on mobiilis 2000 pikslit lai ja lükkab lehe külgsuunas“.

Samm 4: vaata serveri logisid

Mõned vead juhtuvad serveris, mida brauser ei näe. Klassikaline märk on 500 viga võrgu vahekaardil. Serveri logid — sinu taustateenuse tekstiväljund töötamise ajal — sisaldavad tavaliselt tegelikku viga koos stack trace’iga (nimekiri funktsioonidest, mis jooksid, kui see ebaõnnestus).

Kus neid leiad, sõltub tööriistast. Enamikus tehisintellekti rakenduste koostajates saad avada projekti terminali või logivaate või lihtsalt küsida tehisintellektilt: „Vaata serveri logisid viimase päringu vigade kohta ja ütle, mis ebaõnnestus.“

Samm 5: kirjelda viga tehisintellektile

Pane kogutud andmed sellisesse vormi:

Lehel Bookings, sisse logituna liikmena: klõpsasin homse kell 9 tunni nupul Cancel. Oodatud: broneering kaob ja tund näitab ühe vaba koha rohkem. Tegelik: ekraanil ei muutu midagi. Konsoolis on TypeError: Cannot read properties of undefined (reading 'id') failis BookingCard.tsx:31, ning võrgu vahekaardil näitab DELETE /api/bookings/123 vastuseks 500. Leia põhjus, paranda see ja kontrolli, et tühistamine töötab liikmele ühe ja mitme broneeringuga.

Miks iga osa loeb:

• Kus ja kelle rollis kitsendab ühe ekraani ja ühe rolli peale.
• Täpsed sammud laseb tehisintellektil viga taasesitada.
• Oodatud vs tegelik määratleb, mida tähendab „parandatud“.
• Veateade ja ebaõnnestunud päring näitavad otse põhjuse suunas.
• „Kontrolli, et…“ palub tehisintellektil kontrollida, mitte ainult muuta.

Kui tehisintellekt on proovinud parandust kaks korda ja ebaõnnestunud, palu tal enne midagi muutmast selgitada:

Ära muuda veel koodi. Mis sinu arvates seda põhjustab ja milline tõend seda toetab?

Vale teooria on kirjalikult kergesti äratuntav ja palju odavam parandada kui vale parandus.

Samm 6: kontrolli ja vaata ümbrust

Kui tehisintellekt ütleb, et see on parandatud, korda samme 1. sammust. Seejärel kontrolli, mis on selle ümber:

• sama tegevus teise kasutajarolliga
• sama tegevus ilma andmeteta ja palju andmetega
• lehed, mis jagavad parandatud komponenti
• telefoniekraani laius, kui parandus puudutas paigutust

Tehisintellekti muudatused parandavad mõnikord ühe tee ja rikuvad vaikselt teise. Kahe minuti kontroll nüüd säästab hilisema segase tunni.

Samm 7: pööra tagasi, selle asemel et kuhjata

Kui parandus tegi asjad hullemaks või oled kolm ringi edasi jõudnud, pöördu tagasi. Viimase töötava versiooni juurde tagasi pöördumine ja paremate tõenditega ümber sõnastamine ületab peaaegu alati neljanda parandusega kolme vale peale. Iga ebaõnnestunud katse jätab maha koodi, mis segab järgmist katset.

Head harjumused, mis tagasipööramist lihtsustavad:

• Kontrolli pärast iga muudatust, et teaksid, milline muudatus viga põhjustas.
• Hoia muudatused väikesed — üks funktsioon või parandus sõnumi kohta.
• Märgi viimane töötav versioon enne riskantse asja alustamist.
• Kui kood on Gitis, tee töötavatest versioonidest commit’id, et neid tagasi saada.

Levinud vigade mustrid AI-ga ehitatud rakendustes

Kui probleem pole viga

Mõned „vead“ on see, kui tehisintellekt ehitab täpselt seda, mida talle öeldi, ja kirjeldus oli ebamäärane. Kui parandus, mida palud, on tegelikult käitumise muutus, ütle see selgelt: „Muuda nii, et…“. Kui ei ole kindel, milline õige käitumine üldse on, otsusta see esmalt. Meie juhend promptide kirjutamisest AI rakenduste koostajatele käsitleb, kuidas reegleid selgelt kirjeldada. Ja kui valmistad rakendust ette päris kasutajatele, käsitleb AI prototüübi viimine tootmisse kontrolle, mida enne käivitamist teha.

Silumine Mythexis

Mythexil on tööriistad iga tsükli sammu jaoks:

• Eelvaade vea taasesitamiseks, sealhulgas telefoni suuruses raamis.
• /test laseb agendil klikkida läbi su elava eelvaate nagu kasutaja ja teatada katkistest voogudest.
• /fix suunab agendi konkreetselt katkisuste peale.
• Plan režiim laseb agendil uurida ja selgitada enne, kui ta midagi muudab.
• Code → terminal näitab su rakenduse serveri logisid.
• Revert to this point igal vastusel viib projekti selle kontrollpunkti juurde tagasi.

Kui avaldamine ebaõnnestub, pakub avaldamisdialoog tavaliselt nuppu Fix with AI, mis loeb ehitusväljundit või rakenduse logisid. Vaata dokumentatsioonist Debug your app ja Publish troubleshooting.

Küsimused