Kako unaprijediti aplikaciju izgrađenu uz AI, a da je ne pokvarite

Da biste unaprijedili aplikaciju izgrađenu uz AI, a da je ne pokvarite, mijenjajte jednu stvar po upitu, provjerite je u pregledu i sačuvajte kontrolnu tačku prije nego što pređete dalje. Opišite šta vidite umjesto onoga što mislite da kod radi, planirajte velike promjene prije nego što ih gradite i kada promjena pođe po zlu, vratite se na posljednju dobru verziju umjesto da tražite od AI-ja da popravi vlastitu popravku.

Prva verzija aplikacije često nastane za nekoliko minuta. Teži dio je pedeseta promjena, kada svaki novi upit može pokvariti nešto što je ranije radilo. Ovaj vodič je petlja koja to sprječava.

Petlja unapređenja

1. Odaberite jednu promjenu. Jednu funkciju, jednu grešku, jednu stranicu.
2. Opišite je u smislu onoga što korisnik vidi i radi.
3. Za velike promjene, planirajte prvo. Tražite plan, pročitajte ga, zatim gradite.
4. Provjerite rezultat u pregledu — promjenu i tokove oko nje.
5. Sačuvajte kontrolnu tačku ili commit.
6. Ponovite.

Svaki korak postoji da bi promjene ostale male i da se mogu poništiti.

Korak 1: Vodite kratak spisak

Prije upita, zapišite šta želite promijeniti, po redu važnosti. To vas sprječava da pošaljete paragraf s deset želja u jednoj poruci i 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: kreiraj 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 šta vidite

AI ne vidi vaš ekran dok mu ne kažete. Ukažite na konkretne stvari i recite šta treba da se desi:

Na stranici s cijenama na telefonu, dugme Pro kartice je odsječeno s desne ivice. Zadrži isti izgled na desktopu; na ekranima ispod 640px, poredaj kartice jednu ispod druge i neka dugmad budu pune širine.

Uporedite to s „stranica s cijenama loše izgleda na mobilnom”. Prvo se može uraditi i provjeriti odjednom; drugo poziva redizajn koji niste tražili.

Snimci ekrana pomažu. Ako vaš graditelj prihvata slike, priložite jednu i zaokružite problem.

Korak 3: Planirajte prije velikih promjena

Za sve što dira više dijelova aplikacije — novi model podataka, plaćanja, korisničke uloge — tražite plan prije bilo kakve promjene koda:

Još ne mijenjaj kod. Želim da korisnici pripadaju timovima i vide samo projekte svog tima. Isplaniraj promjenu: koje se tabele, stranice i API rute mijenjaju, šta se dešava s podacima postojećih korisnika i kojim redoslijedom bi to gradio.

Pročitajte plan. Ako nije ispravan, ispravljanje plana mnogo je jeftinije od poništavanja izgradnje.

Korak 4: Recite šta ne smije da se promijeni

AI alati ponekad „srede” stvari koje niste tražili. Zaštitite ono što radi:

Dodaj filter datuma u tabelu narudžbi. Ne mijenjaj kolone tabele, stil ni dugme za izvoz.

Za pravila koja važe svuda — boje brenda, ton komunikacije, „nikada ne briši podatke bez potvrde” — stavite ih u datoteku s bilješkama 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 desktopu i telefonu?
• Susjedne dijelove. Stvari na istoj stranici i tokove koji koriste iste podatke.
• Kritičan 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, precizno to opišite — pogledajte kako napisati dobar izvještaj o grešci.

Korak 6: Vratite se unazad umjesto gomilanja

Kada promjena nešto pokvari, a prva popravka ne radi, stanite. Svaka dodatna „popravka” gradi se na pokvarenom stanju, pa se problemi uvećavaju.

Umjesto toga:

1. Vratite se na posljednju verziju koja je radila (kontrolna tačka ili Git commit).
2. Utvrdite šta u upitu nije bilo jasno.
3. Pokušajte ponovo s manjim ili jasnijim zahtjevom.

Ta promjena je pokvarila čuvanje nacrta. Vratio sam se unazad. Ovaj put: dodaj samo indikator automatskog čuvanja, kao tekst u zaglavlju. Ne mijenjaj način na koji se nacrti čuvaju.

Korak 7: Znajte kada je ponovna izgradnja prava odluka

Ponovna izgradnja od nule odbacuje mnogo radnih detalja. Vrijedi samo kada:

• Ideja proizvoda se potpuno promijenila.
• Osnovna struktura ne može podržati ono što sada treba — na primjer, izgrađena je kao statički sajt, a sada treba računi i baza podataka.
• Projekat je još gotovo prazan.

Kada ponovo gradite, napravite spisak šta treba zadržati: naziv, boje, tekst, dijelove koje su korisnici voljeli.

Primjeri upita

Prije nego nastavimo, sažmi kako aplikacija trenutno radi: stranice, podatke koje čuva i sve što smatraš krhkim.

Ž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 posljednje tri promjene i provjeri da li je nešto moglo pokvariti tok plaćanja. Još ne mijenjaj.

Česte greške

• Deset zahtjeva u jednom upitu. Neki se urade, neki napola, a ne možete znati koji.
• Nejasne povratne informacije. „Pokvareno je” ili „učini bolje” proizvodi nagađanja.
• Nikada ne provjeravati susjede. Promjena zajedničke komponente pokvari tri druge stranice.
• Popravljanje popravki. Ako ste četiri upita duboko u grešci, vratite se unazad.
• Ponavljanje konteksta svaki put umjesto čuvanja stalnih pravila u bilješkama projekta.
• Ponovna izgradnja kada zapnete. Većina trenutaka „počni ispočetka” zapravo znači „vrati se dva koraka unazad”.

Kontrolna lista

• Jedan cilj po upitu.
• Opisujem šta vidim i šta treba da se desi.
• Velike promjene dobijaju plan prije bilo kakvog koda.
• Kažem šta ne smije da se mijenja.
• Nakon svake promjene testiram nju, susjedne dijelove i kritičan put.
• Čuvam kontrolnu tačku ili commit nakon svake promjene koja radi.
• Kada popravka ne uspije, vraćam se unazad umjesto gomilanja.
• Stalna pravila žive u bilješkama projekta koje AI čita svaki put.

Unapređenje na Mythexu

Mythex je izgrađen oko ove petlje:

• Režimi Plan, Build i Ask. Plan raspravlja o pristupu prije izmjene; Ask odgovara bez mijenjanja koda; Build pravi promjenu. Pogledajte Chat.
• Kontrolne tačke. Nakon svakog uspješnog koraka, Mythex čuva git kontrolnu tačku; Revert to this point vraća unazad. Takođe možete urediti raniju poruku i Discard & resend da isprobate drugi upit od te tačke. Pogledajte Unapređujte bez ponovne izgradnje.
• Znanje. Postavke projekta → Knowledge sadrži stalne bilješke koje agent slijedi uz svaku poruku.
• /test nakon velike promjene natjera agenta da klikće kroz pregled kao korisnik.

Manji zahtjevi koštaju i manje kredita. Za pisanje samih upita pogledajte kako pisati upite za AI graditelje aplikacija; kada se nešto ipak pokvari, kako debagovati aplikaciju izgrađenu uz AI.

Pitanja