Hogyan hibakeress AI-val épített appot: gyakorlati módszer

Egy AI-val épített app hibájának hibakereséséhez először szándékosan idézd elő újra a hibát, aztán gyűjts bizonyítékot — a pontos lépéseket, a hibaüzenetet, és azt, amit a böngésző konzolja és a hálózati fül mutat —, és add oda az AI-nak ezt a formát: „Ezt csináltam, ezt vártam, ezt kaptam”. Ha egy javítás rontja a helyzetet, térj vissza az utolsó működő verzióhoz, ahelyett hogy még több javítást halmoznál rá. Ahhoz, hogy mindezt jól csináld, nem kell olvasnod a kódot.

Ez az útmutató a teljes ciklust lefedi, beleértve a böngésző fejlesztőeszközeinek gyors bemutatását nem fejlesztőknek.

A hibakeresési ciklus

Minden hibajavítás — akár ember, akár AI végzi — ugyanezt a ciklust követi:

1. Reprodukálás — idézd elő megbízhatóan a hibát.
2. Megfigyelés — gyűjtsd össze a hibaüzenetet és azt, mit csinált az app.
3. Leírás — adj az AI-nak pontos lépéseket, a várt és a valódi eredményt.
4. Javítás — hagyd, hogy az AI egy dolgot változtasson.
5. Ellenőrzés — ismételd meg pontosan a lépéseket, és győződj meg róla, hogy javult, és a közeli dolgok nem törtek el.
6. Visszagörgetés, ha kell — ha rosszabb lett, vond vissza, és próbáld újra jobb információval.

Az AI-val épített appoknál az idő nagy része az 1., 2. és 5. lépés kihagyásából vész el: amikor azt mondjuk, „elromlott”, elfogadunk egy változtatást anélkül, hogy teszteltük volna, és aztán egy újabb javítást kérünk egy eleve törött változatra.

1. lépés: Reprodukáld a hibát

Amit szándékosan ki tudsz váltani, az félig már megjavított. Próbáld megtalálni a legrövidebb lépéssorozatot, amely kiváltja.

Kérdezd meg magadtól:

• Minden alkalommal előjön? Ha csak néha, mi más, amikor előjön — egy konkrét rekord, lassú kapcsolat, kijelentkezett állapot?
• Minden felhasználónál előjön? Lépj be egy másik fiókkal. Sok hiba csak új felhasználóknál jelenik meg, akiknek nincs adatuk, vagy egy másik szerepkörnél.
• Minden eszközön előjön? Próbálj telefon szélességű képernyőt és másik böngészőt.
• Egy konkrét változtatás után kezdődött? Ha tegnap még működött, az utolsó néhány változtatás a fő gyanúsítottak.

Írd le a lépéseket rövid, számozott listaként. Később bemásolod a promptba.

2. lépés: Olvasd el a hibaüzenetet

A hibaüzenetek ijesztőnek tűnhetnek, de csak néhány részük kell neked.

Nem kell megértened; pontosan kell átmásolnod. A „Cannot read properties of undefined (reading 'name')” azt mondja az AI-nak, hogy a kód olyan adatot várt (valószínűleg egy foglalást vagy felhasználót), amely nem érkezett meg. Egy átfogalmazás, mint „valami undefined hiba”, ezt elveszíti.

Néhány gyakori, nagyjából lefordítva:

• undefined / null hibák — a kód olyan adatot várt, ami nem érkezett meg. Gyakran egy betöltési állapot vagy egy üres lista, amit a kód nem kezel.
• 404 Not Found — az oldal vagy API-cím nem létezik. Gyakran elgépelt útvonal, vagy egy átnevezett oldalra mutató link.
• 401 Unauthorized / 403 Forbidden — a kérés nem volt bejelentkezve, vagy a felhasználó nem végezheti el a műveletet.
• 500 Internal Server Error — a szerveroldali kód összeomlott. Az igazi ok a szerver naplóiban van, nem a böngészőben.
• CORS hibák — a böngésző blokkolta a kérést egy másik domain felé. Általában a szerveroldali beállítás a gond.

3. lépés: Használd a böngésző fejlesztőeszközeit

Minden asztali böngészőben van beépített fejlesztőeszköz („devtools”). Megmutatják, mit csinál az oldal a színfalak mögött. Chrome-ban, Edge-ben és Firefoxban kattints jobb gombbal az oldal bármely pontján, és válaszd a Vizsgálat (Inspect) lehetőséget, vagy nyomd meg az F12-t (Macen Cmd+Option+I). Safariban először kapcsold be a Fejlesztés menüt a Safari beállításaiban.

Csak három fül kell.

Konzol

A Konzol (Console) fül listázza az oldal kódjának hibáit és üzeneteit. A hibák pirossal jelennek meg. Ha egy gomb nem csinál semmit a kattintásra, a konzolban nagyon gyakran pont a kattintás pillanatában jelenik meg egy piros hiba. Másold ki a hiba teljes szövegét (a legtöbb böngészőben jobb gombbal másolási lehetőség van).

Hálózat

A Hálózat (Network) fül minden kérést listáz, amelyet az oldal küld — adatok betöltése, űrlap mentése, bejelentkezés. Nyisd meg, majd ismételd meg a hibát kiváltó lépéseket.

• Keress piros sorokat, vagy olyan státuszt, amely 400 vagy annál nagyobb.
• Kattints egy hibás sorra, és nézd meg a Válasz (Response) részt. A szerverhiba gyakran olyan üzenetet tartalmaz, ami hasznosabb bármi másnál, amit a képernyőn látsz.
• Jegyezd fel a kérés címét és a státuszkódot — „a POST a /api/bookings címre 500-at adott” nagyon hasznos mondat az AI-nak.

Jelöld be a Napló megőrzése (Preserve log) opciót, ha a hiba oldalújratöltéssel vagy átirányítással jár, hogy a kérések ne tűnjenek el.

Elemek

Az Elemek (Elements) vagy Vizsgáló fül az oldal szerkezetét és stílusait mutatja. Leginkább elrendezési hibáknál hasznos: ha egy elemre viszed az egeret, megjelenik a mérete és a térköze. Itt nem kell szerkesztened; elég annyit mondani: „a lábléc mobilon 2000 pixel széles, és oldalra tolja az oldalt”.

4. lépés: Nézd meg a szerver naplóit

Vannak hibák, amelyek a szerveren történnek, ahová a böngésző nem lát. A hálózati fülön a 500 hiba a klasszikus jel. A szerver naplói — a backend szöveges kimenete futás közben — általában tartalmazzák a valódi hibát veremkövetéssel (stack trace), vagyis azoknak a függvényeknek a listájával, amelyek futottak, amikor elbukott.

Hogy hol találod őket, az eszköztől függ. A legtöbb AI-appépítőben nyithatsz terminált vagy naplónézetet a projekthez, vagy egyszerűen megkérheted az AI-t: „Nézd meg a szerver naplóit az utolsó kérés hibáira, és mondd meg, mi bukott el.”

5. lépés: Írd le a hibát az AI-nak

Öntsd az összegyűjtött információt ebbe a formába:

A Foglalások oldalon, tagként bejelentkezve: rákattintottam a Lemondás gombra a holnapi 9:00-s órán. Várt: a foglalás eltűnik, és az órán eggyel több szabad hely lesz. Valós: a képernyőn nem változik semmi. A konzolban ez látszik: TypeError: Cannot read properties of undefined (reading 'id') a BookingCard.tsx:31 sorban, a hálózati fülön pedig a DELETE /api/bookings/123 500-at adott. Találd meg az okot, javítsd, és ellenőrizd, hogy a lemondás működik egy foglalással rendelkező tagnál és többel is.

Miért fontos minden rész:

• Hol és kiként egy képernyőre és egy szerepkörre szűkíti.
• A pontos lépések lehetővé teszik, hogy az AI reprodukálja.
• Várt vs. valós meghatározza, mit jelent a „javítva”.
• A hibaszöveg és a sikertelen kérés közvetlenül az okra mutat.
• „Ellenőrizd, hogy…” arra kéri az AI-t, hogy ellenőrizzen, ne csak szerkesszen.

Ha az AI kétszer próbált javítani, és nem sikerült, kérd meg, hogy magyarázza meg, mielőtt változtat:

Ne változtass még kódot. Mi szerinted okozza ezt, és milyen bizonyíték támasztja alá?

A hibás elmélet leírva könnyen felismerhető, és sokkal olcsóbb kijavítani, mint egy rossz javítást.

6. lépés: Ellenőrizz, aztán nézd meg a környéket

Ha az AI azt mondja, hogy javította, ismételd meg az 1. lépés pontos lépéseit. Utána nézd meg a környező dolgokat:

• Ugyanaz a művelet más szerepkörrel
• Ugyanaz a művelet adat nélkül, és sok adattal
• Azok az oldalak, amelyek ugyanazokat az összetevőket használják, mint amit javítottál
• Telefon szélességű képernyő, ha a javítás elrendezést érintett

Az AI-s változtatások néha az egyik utat javítják, a másikat csendben elrontják. Egy kétperces ellenőrzés most sok zavaros órát spórol meg később.

7. lépés: Gördíts vissza, ahelyett hogy halmoznál

Ha egy javítás rontott a helyzeten, vagy három körön át nincs előrelépés, menj vissza. Az utolsó működő verzióhoz való visszagörgetés és a jobb bizonyítékkal való újrafogalmazás szinte mindig jobb, mint a negyedik javítás kérése három rossz javítás tetejére. Minden sikertelen próbálkozás hagy maga után kódot, és ez a kód összezavarja a következő próbálkozást.

Jó szokások, amelyek megkönnyítik a visszagörgetést:

• Teszteld minden változtatás után, hogy tudd, melyik változtatás törte el a dolgokat.
• Tartsd kicsin a változtatásokat — egy funkció vagy javítás üzenetenként.
• Jegyezd fel az utolsó jó verziót, mielőtt valami kockázatosat kezdenél.
• Ha a kód Gitben van, commitold a működő verziókat, hogy vissza tudj térni hozzájuk.

Gyakori hibamintázatok AI-val épített appokban

Amikor a probléma nem hiba

Néhány „hiba” valójában az, hogy az AI pontosan azt építette meg, amit mondtál, a leírás pedig kétértelmű volt. Ha a kért javítás valójában viselkedésváltozás, mondd ki egyértelműen: „Változtasd úgy, hogy…”. Ha bizonytalan vagy abban, mi lenne a helyes viselkedés, azt előbb döntsd el. Az utasítások írása AI-appépítőknek útmutatónk leírja, hogyan határozz meg szabályokat egyértelműen. Ha pedig valódi felhasználóknak készítesz appot, a hogyan vidd élesbe az AI-prototípusodat útmutató azokat az ellenőrzéseket sorolja fel, amelyeket indulás előtt érdemes elvégezni.

Hibakeresés a Mythexben

A Mythexnek van eszköze a ciklus minden lépéséhez:

• Előnézet a hiba reprodukálásához, beleértve egy telefonméretű keretet is.
• /test: az ügynök úgy kattintgat végig az élő előnézeten, mint egy felhasználó, és jelenti a törött folyamatokat.
• /fix: az ügynököt kifejezetten a törésekre irányítja.
• Terv (Plan) mód: az ügynök vizsgálódhat és magyarázhat, mielőtt bármit szerkesztene.
• Kód → terminál: megmutatja az app szerveroldali naplóit.
• Visszaállítás erre a pontra bármely válasznál visszagörgeti a projektet arra az ellenőrzőpontra.

Ha egy publikálás elbukik, a publikálási párbeszédablak általában felajánlja a Javítás AI-val (Fix with AI) lehetőséget, amely a build kimenetét vagy az app naplóit olvassa. Lásd a dokumentációban a Hibakeresd az appodat és a Publikálási hibaelhárítás oldalakat.

Kérdések