Tekoälyllä rakennetun sovelluksen virheiden korjaaminen: käytännön menetelmä

Tekoälyllä rakennetun sovelluksen virheen korjaamiseksi toista ensin bugi tarkoituksella, kerää sitten todisteet (tarkat askeleet, virheilmoitus ja se, mitä selaimen konsoli ja verkkovälilehti näyttävät) ja anna ne tekoälylle muodossa ”Tein X, odotin Y, sain Z”. Jos korjaus pahentaa tilannetta, palaa viimeisimpään toimivaan versioon sen sijaan, että lisäisit korjauksia päälle. Sinun ei tarvitse lukea koodia, jotta tämä onnistuu.

Tämä opas käy läpi koko silmukan ja antaa lyhyen kierroksen selaimen kehittäjätyökaluihin ei-kehittäjille.

Vianetsinnän silmukka

Jokainen bugikorjaus, oli se ihmisen tai tekoälyn tekemä, noudattaa samaa silmukkaa:

1. Toista bugi, eli saa se tapahtumaan luotettavasti.
2. Havainnoi: kerää virheilmoitus ja se, mitä sovellus teki.
3. Kuvaile: anna tekoälylle tarkat askeleet, odotettu tulos ja todellinen tulos.
4. Korjaa: anna tekoälyn muuttaa yksi asia.
5. Varmista: toista täsmälleen samat askeleet ja vahvista, että bugi on korjattu ja lähellä oleva ei rikkoutunut.
6. Palaa takaisin tarvittaessa: jos tilanne paheni, peru muutos ja yritä uudelleen paremmalla tiedolla.

Suurin osa ajasta, joka menee hukkaan tekoälyllä rakennetuissa sovelluksissa, kuluu siksi, että ohitetaan vaiheet 1, 2 ja 5: sanotaan ”se on rikki”, hyväksytään muutos testaamatta ja pyydetään sitten uutta korjausta rikkinäisen päälle.

Vaihe 1: Toista bugi

Bugi, jonka voit laukaista halutessasi, on puoliksi korjattu. Yritä löytää lyhin askelsarja, joka aiheuttaa sen.

Kysy itseltäsi:

• Tapahtuuko se joka kerta? Jos vain joskus, mikä eroaa silloin: tietty tietue, hidas yhteys, uloskirjautuminen?
• Tapahtuuko se jokaiselle käyttäjälle? Kirjaudu toisella tilillä. Monet bugit näkyvät vain uusille käyttäjille, joilla ei ole dataa, tai toisella roolilla.
• Tapahtuuko se jokaisella laitteella? Kokeile puhelimen levyistä ruutua ja eri selainta.
• Alkoiko se tietyn muutoksen jälkeen? Jos se toimi eilen, viimeisimmät muutokset ovat ensisijaiset epäillyt.

Kirjoita askeleet ylös lyhyeksi numeroituksi listaksi. Liität sen kehotteeseen myöhemmin.

Vaihe 2: Lue virheilmoitus

Virheilmoitukset näyttävät pelottavilta, mutta tarvitset niistä vain muutaman osan.

Sinun ei tarvitse ymmärtää sitä. Sinun täytyy kopioida se tarkasti. ”Cannot read properties of undefined (reading 'name')” kertoo tekoälylle, että koodi odotti dataa (todennäköisesti varausta tai käyttäjää), jota ei ollut. Parafraasi, kuten ”jokin undefined-virhe”, hukkaa tuon tiedon.

Muutama yleinen, karkeasti suomennettuna:

• undefined / null-virheet: koodi odotti dataa, joka ei saapunut. Usein latautumistila tai tyhjä lista, jota koodi ei käsitellyt.
• 404 Not Found: sivua tai API-osoitetta ei ole. Usein kirjoitusvirhe reitissä tai linkki sivulle, jonka nimi on vaihdettu.
• 401 Unauthorized / 403 Forbidden: pyyntö ei ollut kirjautunut, tai käyttäjällä ei ole oikeutta tehdä sitä.
• 500 Internal Server Error: palvelinpuolen koodi kaatui. Todellinen syy on palvelimen lokeissa, ei selaimessa.
• CORS-virheet: selain esti pyynnön eri verkkotunnukseen. Yleensä palvelimen asetusongelma.

Vaihe 3: Käytä selaimen kehittäjätyökaluja

Kaikissa pöytäkoneen selaimissa on sisäänrakennetut kehittäjätyökalut (”devtools”). Ne näyttävät, mitä sivu tekee kulissien takana. Chromessa, Edgessä ja Firefoxissa napsauta sivua hiiren oikealla ja valitse Tarkastele tai paina F12 (Mac-koneella Cmd+Option+I). Safarissa ota ensin käyttöön Kehittäjä-valikko Safarin asetuksista.

Tarvitset vain kolme välilehteä.

Konsoli

Konsoli-välilehti listaa virheet ja viestit sivun koodista. Virheet näkyvät punaisella. Jos nappi ei tee mitään, kun klikkaat sitä, konsoli näyttää hyvin usein punaisen virheen juuri klikkauksen hetkellä. Kopioi virheen koko teksti (useimmissa selaimissa hiiren oikealla on kopiointivaihtoehto).

Verkko

Verkko-välilehti listaa kaikki pyynnöt, joita sivu tekee: tietojen lataamiset, lomakkeiden tallennukset, kirjautumiset. Avaa se ja toista askeleet, jotka aiheuttavat bugin.

• Etsi punaisia rivejä tai rivejä, joiden tila on 400 tai enemmän.
• Napsauta epäonnistunutta riviä nähdäksesi sen vastauksen. Palvelinvirhe sisältää usein viestin, joka on hyödyllisempi kuin mikään ruudulla.
• Kirjaa pyynnön osoite ja tilakoodi. Lause ”POST /api/bookings palautti 500” on erittäin hyödyllinen antaa tekoälylle.

Valitse Preserve log (Säilytä loki), jos bugi liittyy sivun uudelleenlataukseen tai uudelleenohjaukseen, jotta pyynnöt eivät katoa.

Elementit

Elementit-välilehti (tai Inspector) näyttää sivun rakenteen ja tyylit. Se on hyödyllisin asettelubugeissa: kun viet hiiren elementin päälle, sen koko ja väli korostuvat. Sinun ei tarvitse muokata mitään siellä. Riittää sanoa ”alatunniste on mobiilissa 2 000 pikseliä leveä ja työntää sivun sivusuuntaan”.

Vaihe 4: Tarkista palvelimen lokit

Jotkin bugit tapahtuvat palvelimella, jota selain ei näe. Verkko-välilehden 500-virhe on klassinen merkki. Palvelimen lokit, eli taustajärjestelmäsi tekstitulostus sen ajon aikana, sisältävät yleensä todellisen virheen pinojäljen (lista funktioista, jotka olivat käynnissä, kun se kaatui).

Missä ne ovat, riippuu työkalustasi. Useimmissa tekoälysovellusrakentajissa voit avata projektin terminaalin tai lokinäkymän, tai voit yksinkertaisesti pyytää tekoälyä: ”Tarkista palvelimen lokit viimeisimmän pyynnön virheiden varalta ja kerro, mikä epäonnistui.”

Vaihe 5: Kuvaile bugi tekoälylle

Aseta keräämäsi tiedot tähän muotoon:

Varaussivulla, kirjautuneena jäsenenä: klikkasin Peru huomisen klo 9.00 tunnilla. Odotettu: varaus katoaa ja tunnilla on yksi vapaa paikka lisää. Todellinen: ruudulla ei muutu mitään. Konsoli näyttää TypeError: Cannot read properties of undefined (reading 'id') kohdassa BookingCard.tsx:31, ja verkkovälilehti näyttää, että DELETE /api/bookings/123 palautti 500. Etsi syy, korjaa se ja tarkista, että peruutus toimii jäsenelle, jolla on yksi varaus ja jolla on useita.

Miksi jokainen osa on tärkeä:

• Missä ja kenenä rajaa sen yhteen näkymään ja yhteen rooliin.
• Tarkat askeleet antavat tekoälyn toistaa bugin.
• Odotettu vs. todellinen määrittää, mitä ”korjattu” tarkoittaa.
• Virhe ja epäonnistunut pyyntö osoittavat suoraan syyn.
• ”Tarkista, että…” pyytää tekoälyä varmentamaan, ei vain muokkaamaan.

Jos tekoäly on yrittänyt korjata kahdesti eikä onnistunut, pyydä sitä selittämään ennen minkään muuttamista:

Älä vielä muuta koodia. Mikä mielestäsi aiheuttaa tämän, ja mikä todiste tukee sitä?

Väärä teoria on helppo huomata, kun se on kirjoitettu auki, ja paljon halvempi korjata kuin väärä korjaus.

Vaihe 6: Varmista ja tarkista lähistö

Kun tekoäly sanoo, että se on korjattu, toista askeleet vaiheesta 1. Tarkista sen jälkeen ympäröivät asiat:

• Sama toiminto eri käyttäjäroolilla
• Sama toiminto ilman dataa ja paljolla datalla
• Sivut, jotka jakavat komponentteja korjatun kanssa
• Puhelimen levyinen ruutu, jos korjaus koski asettelua

Tekoälyn muutokset korjaavat joskus yhden polun ja rikkovat hiljaa toisen. Kahden minuutin tarkistus nyt säästää hämmentävän tunnin myöhemmin.

Vaihe 7: Palaa takaisin, älä kasaa lisää

Jos korjaus pahensi tilannetta tai olet käynyt kolme kierrosta ilman edistymistä, palaa takaisin. Palaaminen viimeisimpään toimivaan versioon ja kysymys uudelleen paremmilla todisteilla voittaa lähes aina neljännen korjauksen kolmen väärän päälle. Jokainen epäonnistunut yritys jättää koodia taakseen, ja se koodi sekoittaa seuraavan yrityksen.

Hyvät tavat, jotka tekevät takaisin palaamisesta helppoa:

• Testaa jokaisen muutoksen jälkeen, jolloin tiedät, mikä muutos rikkoi jotain.
• Pidä muutokset pieninä: yksi ominaisuus tai korjaus viestiä kohden.
• Merkitse viimeisin toimiva versio ennen riskialtista asiaa.
• Jos koodi on Gitissä, tallenna toimivat versiot commitein, jotta voit palata niihin.

Yleisiä bugikuvioita tekoälyllä rakennetuissa sovelluksissa

Kun ongelma ei ole bugi

Jotkin ”bugit” ovat tekoälyn rakentamassa juuri sitä, mitä siltä pyydettiin, ja kuvaus oli epäselvä. Jos pyytämäsi korjaus on oikeasti käyttäytymisen muutos, sano se suoraan: ”Muuta niin, että…”. Jos et ole varma, mikä oikea toiminta on, päätä se ensin. Oppaamme kehotteiden kirjoittamisesta tekoälysovellusrakentajille kertoo, miten säännöt määritellään selkeästi. Ja jos valmistelet sovellusta todellisille käyttäjille, tekoälyprototyypin vieminen tuotantoon käy läpi tarkistukset, jotka kannattaa tehdä ennen lanseerausta.

Vianetsintä Mythexissä

Mythexissä on työkalu jokaiseen silmukan vaiheeseen:

• Esikatselu bugin toistamiseen, myös puhelimen kokoisena kehyksenä.
• /test: agentti klikkaa elävän esikatselun läpi kuin käyttäjä ja raportoi rikkinäiset kulut.
• /fix ohjaa agentin nimenomaan rikkoutuneisiin kohtiin.
• Plan-tila antaa agentin tutkia ja selittää ennen kuin se muokkaa mitään.
• Code → terminal näyttää sovelluksesi palvelinlokit.
• Revert to this point palauttaa projektin mihin tahansa vastaukseen liittyvään tarkistuspisteeseen.

Jos julkaisu epäonnistuu, julkaisudialogi tarjoaa yleensä Fix with AI -painikkeen, joka lukee käännöstulosteen tai sovelluksen lokit. Katso dokumentaatiosta Debug your app ja Publish troubleshooting.

Kysymykset