Hogyan fejleszd tovább az AI-val épített appot anélkül, hogy elromlana

Az AI-val épített app hibamentes fejlesztéséhez promptonként egy dolgot változtass, ellenőrizd az előnézetben, és mielőtt továbblépnél, mentsd el egy ellenőrzőponttal. Azt írd le, amit látsz, ne azt, amit szerinte a kód csinál; a nagy változtatásokat tervezd meg, mielőtt megépíted őket; és ha egy változtatás elromlik, térj vissza az utolsó jó verzióhoz, ahelyett hogy az AI-t kérnéd, javítsa a saját javítását.

Az app első verziója gyakran percek alatt összeáll. A nehéz rész az ötvenedik változtatás, amikor minden új prompt kockáztatja, hogy valami elromlik, ami addig működött. Ez az útmutató az a ciklus, amely ezt megakadályozza.

A fejlesztési ciklus

1. Válassz egy változtatást. Egy funkció, egy hiba, egy oldal.
2. Írd le úgy, ahogy a felhasználó látja és csinálja.
3. Nagy változtatásnál tervezz először. Kérj tervet, olvasd el, aztán építs.
4. Ellenőrizd az eredményt az előnézetben — a változtatást és a közeli folyamatokat.
5. Mentsd el ellenőrzőponttal vagy commit-tal.
6. Ismételd.

Minden lépés azért van, hogy a változtatások kicsik és visszacsinálhatóak maradjanak.

1. lépés: Vezess rövid listát

Prompt előtt írd le, mit szeretnél megváltoztatni, fontossági sorrendben. Így nem küldesz tíz kívánságot egy üzenetben, és van módod „most nem” mondani azokra az ötletekre, amelyek közben felmerülnek.

Ha egy változtatás nagy, bontsd részekre. A „csapatfiókok hozzáadása” így lesz: csapatok létrehozása, tag meghívása, váltás csapatok között, az adatok korlátozása az aktuális csapatra. Mindegyik külön prompt. A felhasználói történetek írása jó módszer erre.

2. lépés: Írd le, amit látsz

Az AI nem látja a képernyődet, hacsak el nem mondod. Mutass konkrét dolgokra, és mondd meg, mi történjen:

Telefonon az árazási oldalon a Pro kártya gombja le van vágva a jobb szélen. Az asztali elrendezés maradjon ugyanaz; 640 px alatt a kártyák egymás alá kerüljenek, a gombok legyenek teljes szélesek.

Ezt hasonlítsd össze azzal, hogy „az árazási oldal mobilon rossznak néz ki”. Az első egy lépésben megvalósítható és ellenőrizhető; a második egy olyan átdizájnt hív elő, amit nem kértél.

A képernyőkép segít. Ha az építőd fogad képet, csatolj egyet, és karikázd be a problémát.

3. lépés: Tervezz a nagy változtatások előtt

Ami az app több részét érinti — új adatmodell, fizetés, felhasználói szerepkörök —, kérj tervet, mielőtt bármi kódot változtatnának:

Ne változtass még kódot. Azt szeretném, hogy a felhasználók csapatokhoz tartozzanak, és csak a saját csapatuk projektjeit lássák. Tervezd meg a változtatást: mely táblák, oldalak és API-útvonalak változnak, mi lesz a meglévő felhasználók adataival, és milyen sorrendben építenéd.

Olvasd el a tervet. Ha rossz, a terv javítása sokkal olcsóbb, mint egy rossz build visszacsinálása.

4. lépés: Mondd meg, mit nem szabad megváltoztatni

Az AI-eszközök néha „rendbe teszik” azt, amit nem kértél. Védd meg, ami működik:

Adj dátumszűrőt a rendelési táblázathoz. Ne változtasd meg a táblázat oszlopait, stílusát vagy az exportálás gombot.

Az olyan szabályokra, amelyek mindenhol érvényesek — márkaszínek, hangnem, „soha ne töröljön adatot megerősítés nélkül” —, tegyél egy projektjegyzet-fájlt vagy tudásbeállítást, amelyet az AI minden alkalommal olvas, ahelyett hogy minden promptban megismételnéd.

5. lépés: Ne csak a változtatást ellenőrizd

Minden prompt után teszteld:

• A változtatást magát. Azt csinálja, amit kértél, asztali gépen és telefonon?
• A szomszédait. Ami ugyanazon az oldalon van, és azokat a folyamatokat, amelyek ugyanazt az adatot használják.
• A kritikus utat. Regisztráció, bejelentkezés, a fő művelet, fizetés. Egy harminc másodperces átnézés minden nagy változtatás után a legtöbb törést korán elkapja.

Ha valami nem stimmel, pontosan jelezd — lásd: hogyan írj jó hibajelentést.

6. lépés: Térj vissza, ne halmozz

Ha egy változtatás elrontott valamit, és az első javítás nem működik, állj meg. Minden újabb „javítás” egy elromlott állapotra épül, és a problémák összeadódnak.

Helyette:

1. Térj vissza az utolsó működő verzióhoz (ellenőrzőpont vagy Git-commit).
2. Derítsd ki, mi volt nem egyértelmű a promptban.
3. Próbáld újra egy kisebb vagy világosabb kéréssel.

Ez a változtatás elrontotta a piszkozatok mentését. Visszatértem. Most csak ezt add hozzá: egy automentés-jelzőt szövegként a fejlécben. Ne változtasd meg, hogyan mentjük a piszkozatokat.

7. lépés: Tudd, mikor helyes az újraépítés

A nulláról való újraépítés sok működő részletet dob ki. Csak akkor éri meg, ha:

• A termékötlet teljesen megváltozott.
• A mögöttes szerkezet nem bírja azt, amire most szükséged van — például statikus oldalként épült, de most fiókokra és adatbázisra van szükség.
• A projekt még közel üres.

Ha mégis újraépítesz, írd össze, mit tartsanak meg: név, színek, szövegek, azok a részek, amiket a felhasználók szerettek.

Példa promptok

Mielőtt folytatjuk, foglald össze, hogyan működik most az app: oldalak, tárolt adatok, és amit törékenynek tartasz.

Ismétlődő foglalásokat szeretnék hozzáadni. Mi a legkisebb változat, ami hasznos lenne? Javasolj három külön változtatást, amelyeket egyesével meg tudunk csinálni.

Nézd át az utolsó három változtatást, hogy valamelyik nem törte-e el a fizetési folyamatot. Még ne szerkessz.

Gyakori hibák

• Tíz kérés egy promptban. Néhány kész lesz, néhány félkész, és nem tudod megmondani, melyik.
• Homályos visszajelzés. A „elromlott” vagy „csináld jobbá” találgatásokat szül.
• Soha nem ellenőrzöd a szomszédokat. Egy közös komponens változtatása három másik oldalt elront.
• Javítások javítása. Ha négy prompttal mélyen vagy egy hibában, térj vissza.
• A kontextus minden alkalommal ismétlése, ahelyett hogy az állandó szabályok a projektjegyzetben lennének.
• Újraépítés, amikor elakadsz. A legtöbb „kezdjük újra” pillanat valójában „térj vissza két lépést”.

Ellenőrzőlista

• Egy cél promptonként.
• Leírom, amit látok, és mit kellene történnie.
• A nagy változtatások kapnak tervet, mielőtt kód készül.
• Megmondom, mi nem változhat.
• Minden változtatás után tesztelem: magát, a szomszédait és a kritikus utat.
• Mentek ellenőrzőpontot vagy commitot minden működő változtatás után.
• Ha egy javítás nem működik, visszatérek, nem halmozok.
• Az állandó szabályok a projektjegyzetben vannak, amelyet az AI minden alkalommal olvas.

Iteráció a Mythexben

A Mythex erre a ciklusra épül:

• Terv-, Build- és Kérdés-módok. A Terv a megközelítésről beszél szerkesztés előtt; a Kérdés kódváltoztatás nélkül válaszol; a Build megcsinálja a változtatást. Lásd: Csevegés.
• Ellenőrzőpontok. Minden sikeres kör után a Mythex git-ellenőrzőpontot ment; a Visszaállítás erre a pontra visszahoz. Egy korábbi üzenetet is szerkeszthetsz, és a Elvetés és újraküldés gombbal más promptot próbálhatsz ugyanonnan. Lásd: Iteráció újraépítés nélkül.
• Tudás. A projektbeállítások → Tudás tartalmazza az állandó jegyzeteket, amelyeket az ágens minden üzenetnél követ.
• /test: nagy változtatás után az ágens úgy kattint végig az előnézeten, mint egy felhasználó.

A kisebb kérések kevesebb kreditbe is kerülnek. A promptok megírásához lásd: hogyan írj promptokat AI-app-építőknek; ha mégis valami elromlik, hogyan hibakeresd az AI-val épített appot.

Kérdések