Kako nadograđivati aplikaciju izrađenu uz AI bez njezinog kvarenja
Da biste nadograđivali aplikaciju izrađenu uz AI bez njezinog kvarenja, mijenjajte jednu stvar po upitu, provjerite je u pregledu i spremite kontrolnu točku prije nego što nastavite. Opisujte što vidite, a ne što mislite da kod radi, planirajte velike promjene prije gradnje, a kada promjena pođe po zlu, vratite se na posljednju dobru verziju umjesto da od AI-ja tražite da popravi vlastiti popravak.
Prva verzija aplikacije često nastane za nekoliko minuta. Teži dio je pedeseta promjena, kada svaki novi upit riskira kvar nečega što je već radilo. Ovaj vodič opisuje petlju koja to sprječava.
Petlja nadogradnje
- Odaberite jednu promjenu. Jedna značajka, jedna greška, jedna stranica.
- Opišite je u smislu onoga što korisnik vidi i radi.
- Za velike promjene, najprije planirajte. Tražite plan, pročitajte ga, zatim gradite.
- Provjerite rezultat u pregledu — promjenu i tokove oko nje.
- Spremite kontrolnu točku ili commit.
- Ponovite.
Svaki korak postoji kako bi promjene ostale male i reverzibilne.
Korak 1: Vodite kratak popis
Prije upita zapišite što želite promijeniti, redom po važnosti. To vas sprječava da u jednoj poruci pošaljete odlomak s deset želja, a daje vam način da kažete „ne sada“ idejama koje iskoče usred rada.
Ako je promjena velika, razložite je. „Dodaj timske račune“ postaje: stvori timove, pozovi člana, prebacuj se između timova, ograniči podatke na trenutni tim. Svaka je zaseban upit. Pisanje korisničkih priča dobar je način za to.
Korak 2: Opišite što vidite
AI ne vidi vaš ekran dok mu to ne kažete. Ukažite na konkretne stvari i recite što treba da se dogodi:
Na stranici s cijenama na telefonu gumb kartice Pro je odrezan na desnom rubu. Zadrži isti izgled za računalo; na ekranima ispod 640 piksela složi kartice jednu ispod druge i neka gumbi budu pune širine.
Usporedite to s „stranica s cijenama loše izgleda na mobitelu“. Prvo se može napraviti i provjeriti u jednom koraku; drugo poziva redizajn koji niste tražili.
Snimke ekrana pomažu. Ako vaš graditelj prihvaća slike, priložite jednu i označite problem.
Korak 3: Planirajte prije velikih promjena
Za sve što dira nekoliko dijelova aplikacije — novi model podataka, plaćanja, korisničke uloge — tražite plan prije nego se promijeni ijedan redak koda:
Još ne mijenjaj kod. Želim da korisnici pripadaju timovima i vide samo projekte svog tima. Isplaniraj promjenu: koje se tablice, stranice i API rute mijenjaju, što se događa s podacima postojećih korisnika i kojim redoslijedom bi to gradio.
Pročitajte plan. Ako je pogrešan, ispravljanje plana puno je jeftinije od poništavanja izgradnje.
Korak 4: Recite što se ne smije mijenjati
AI alati ponekad „srede“ stvari o kojima niste pitali. Zaštitite ono što radi:
Dodaj filtar datuma u tablicu narudžbi. Ne mijenjaj stupce tablice, stil niti gumb za izvoz.
Za pravila koja vrijede svuda — boje brenda, ton glasa, „nikada ne brišite podatke bez potvrde“ — stavite ih u datoteku bilješki projekta ili postavku znanja koju AI čita svaki put, umjesto da ih ponavljate.
Korak 5: Provjerite više od same promjene
Nakon svakog upita testirajte:
- Samu promjenu. Radi li ono što ste tražili, na računalu i na telefonu?
- Susjedne dijelove. Stvari na istoj stranici i tokove koji koriste iste podatke.
- Kritični put. Registracija, prijava, glavna radnja, plaćanje. Pregled od trideset sekundi nakon svake velike promjene hvata većinu kvarova rano.
Ako nešto nije u redu, prijavite to precizno — pogledajte kako napisati dobru prijavu greške.
Korak 6: Vratite se unatrag umjesto da gomilate
Kada promjena nešto pokvari i prvi popravak ne uspije, stanite. Svaki dodatni „popravak“ gradi se na pokvarenom stanju, a problemi se umnožavaju.
Umjesto toga:
- Vratite se na posljednju verziju koja je radila (kontrolna točka ili Git commit).
- Razmislite što je u upitu bilo nejasno.
- Pokušajte ponovno s manjim ili jasnijim zahtjevom.
Ta promjena je pokvarila spremanje nacrta. Vratio sam se unatrag. Ovaj put: dodaj samo indikator automatskog spremanja, kao tekst u zaglavlju. Ne mijenjaj kako se nacrti spremaju.
Korak 7: Znajte kada je ponovna gradnja ispravna
Gradnja ispočetka odbacuje mnogo detalja koji rade. Vrijedi je napraviti samo kada:
- Se ideja proizvoda potpuno promijenila.
- Temeljna struktura ne može podržati ono što sada trebate — na primjer, izgrađena je kao statička stranica, a sada treba račune i bazu podataka.
- Projekt je još blizu praznog.
Kada ponovno gradite, napišite što zadržati: naziv, boje, tekstove, dijelove koji su korisnicima bili dragi.
Primjeri upita
Prije nego nastavimo, sažmi kako aplikacija trenutno radi: stranice, podatke koje sprema i sve što misliš da je krhko.
Želim dodati ponavljajuće rezervacije. Koja je najmanja verzija koja bi bila korisna? Predloži je kao tri zasebne promjene koje možemo napraviti jednu po jednu.
Pregledaj zadnje tri promjene i reci možda li je nešto pokvarilo tok plaćanja. Još ništa ne mijenjaj.
Česte greške
- Deset zahtjeva u jednom upitu. Neki se naprave, neki napola, a vi ne možete reći koji.
- Nejasne povratne informacije. „Pokvareno je“ ili „učini bolje“ izaziva nagađanja.
- Nikada ne provjeravati susjede. Promjena zajedničke komponente pokvari tri druge stranice.
- Popravljanje popravaka. Četiri upita duboko u grešci — vratite se unatrag.
- Ponavljanje konteksta svaki put umjesto da stalna pravila držite u bilješkama projekta.
- Ponovna gradnja kada zapnete. Većina trenutaka „počni ispočetka“ zapravo su „vrati se dva koraka unatrag“.
Popis za provjeru
- Jedan cilj po upitu.
- Opisujem što vidim i što treba da se dogodi.
- Velike promjene dobivaju plan prije bilo kakvog koda.
- Kažem što se ne smije mijenjati.
- Nakon svake promjene testiram nju, njezine susjede i kritični put.
- Spremam kontrolnu točku ili commit nakon svake promjene koja radi.
- Kada popravak ne uspije, vraćam se unatrag umjesto da gomilam popravke.
- Stalna pravila žive u bilješkama projekta koje AI čita svaki put.
Nadogradnja na Mythexu
Mythex je izgrađen oko ove petlje:
- Načini Plan, Build i Ask. Plan raspravlja o pristupu prije uređivanja; Ask odgovara bez mijenjanja koda; Build provodi promjenu. Pogledajte Chat.
- Kontrolne točke. Nakon svakog uspješnog koraka Mythex sprema git kontrolnu točku; Revert to this point vraća unatrag. Također možete urediti raniju poruku i odabrati Discard & resend kako biste iz te točke isprobali drugačiji upit. Pogledajte Iteracija bez ponovne gradnje.
- Znanje. Postavke projekta → Knowledge sadrže stalne bilješke koje agent slijedi uz svaku poruku.
/testnakon velike promjene natjera agenta da klikće kroz pregled kao korisnik.
Manji zahtjevi također koštaju manje kredita. Za pisanje samih upita pogledajte kako pisati upite za AI graditelje aplikacija; kada se nešto ipak pokvari, kako ispraviti greške u aplikaciji izrađenoj uz AI.
Pitanja
Zašto se moja aplikacija izrađena uz AI pokvari kada dodajem značajke?
Obično zato što svaki upit traži previše odjednom ili zato što AI popravlja prethodne popravke. Tražite jednu promjenu po upitu, provjerite da radi, spremite kontrolnu točku i vratite se unatrag umjesto da slažete popravke na pokvarenom stanju.
Trebam li aplikaciju graditi ispočetka ili nastaviti nadograđivati?
U većini slučajeva nastavite nadograđivati. Gradite ispočetka samo ako se ideja proizvoda potpuno promijenila, struktura ne može podržati ono što sada trebate ili je projekt još gotovo prazan. Kada to učinite, navedite što treba zadržati.
Kako natjerati AI da pamti odluke o mojoj aplikaciji?
Zapišite ih na mjesto gdje ih AI vidi svaki put: bilješke projekta ili datoteku znanja, ili kratak sažetak koji uključujete u upite. Uključite publiku, pravila stila i stvari koje ne smije mijenjati.
Koliko velik treba biti svaki upit?
Jedan jasan cilj po upitu: jedna značajka, jedna greška, jedna stranica. Ako ne možete provjeriti rezultat za minutu ili dvije, promjena je vjerojatno prevelika da bi se tražila u jednom koraku.