Kako izboljšati aplikacijo, zgrajeno z AI, ne da bi jo pokvarili

Za izboljšanje aplikacije, zgrajene z AI, ne da bi jo pokvarili, spremenite eno stvar na poziv, preverite jo v predogledu in pred nadaljevanjem shranite kontrolno točko. Opišite, kaj vidite, namesto kaj mislite, da koda počne, velike spremembe načrtujte, preden jih gradite, in ko sprememba gre narobe, se vrnite na zadnjo dobro različico, namesto da AI prosite, naj popravi svoj popravek.

Prva različica aplikacije se pogosto sestavi v nekaj minutah. Težko je pri petdesetih spremembah, ko vsak nov poziv tvega, da pokvari nekaj, kar je že delovalo. Ta vodnik je zanka, ki to preprečuje.

Zanka izboljšav

1. Izberite eno spremembo. Ena funkcija, ena napaka, ena stran.
2. Opišite jo z vidika tega, kar uporabnik vidi in naredi.
3. Pri velikih spremembah najprej načrtujte. Zahtevajte načrt, preberite ga in šele nato gradite.
4. Preverite rezultat v predogledu – spremembo in tokove okoli nje.
5. Shranite kontrolno točko ali commit.
6. Ponovite.

Vsak korak obstaja zato, da bi bile spremembe majhne in povratne.

1. korak: vodite kratek seznam

Pred pozivom zapišite, kaj želite spremeniti, po vrstnem redu pomembnosti. Tako ne pošljete odstavka z desetimi željami naenkrat, pa tudi lažje rečete „ne zdaj“ idejam, ki se pojavijo sredi dela.

Če je sprememba velika, jo razdelite. „Dodaj ekipne račune“ postane: ustvari ekipe, povabi člana, preklapljaj med ekipami, omeji podatke na trenutno ekipo. Vsaka je svoj poziv. Pisanje uporabniških zgodb je dober način za to.

2. korak: opišite, kaj vidite

AI ne vidi vašega zaslona, dokler mu tega ne poveste. Pokažite na določene stvari in povejte, kaj naj se zgodi:

Na strani s cenami na telefonu je gumb kartice Pro odrezan na desnem robu. Ohrani namizno postavitev enako; na zaslonih, manjših od 640 px, zloži kartice in naredi gumbe čez celo širino.

Primerjajte to z „stran s cenami na mobilnem izgleda slabo“. Prvo lahko naredite in preverite v enem koraku; drugo vabi k prenovi, ki je niste zahtevali.

Pomagajo tudi posnetki zaslona. Če vaš graditelj sprejema slike, priložite eno in označite težavo.

3. korak: načrtujte pred velikimi spremembami

Za vse, kar se dotika več delov aplikacije – nov podatkovni model, plačila, uporabniške vloge – zahtevajte načrt, preden se koda spremeni:

Še ne spreminjaj kode. Želim, da uporabniki pripadajo ekipam in vidijo samo projekte svoje ekipe. Načrtuj spremembo: katere tabele, strani in API poti se spremenijo, kaj se zgodi s podatki obstoječih uporabnikov in v katerem vrstnem redu bi gradil.

Preberite načrt. Če je napačen, je popravek načrta veliko cenejši kot razveljavitev gradnje.

4. korak: povejte, kaj se ne sme spremeniti

Orodja z AI včasih „uredijo“ stvari, ki jih niste zahtevali. Zaščitite, kar deluje:

Dodaj filter datumov v tabelo naročil. Ne spreminjaj stolpcev tabele, sloga ali gumba za izvoz.

Za pravila, ki veljajo povsod – barve blagovne znamke, ton glasu, „nikoli ne brišite podatkov brez potrditve“ – jih zapišite v datoteko z opombami projekta ali nastavitve znanja, ki jo AI prebere vsakič, namesto da jih ponavljate.

5. korak: preverite več kot samo spremembo

Po vsakem pozivu preverite:

• Samo spremembo. Ali naredi to, kar ste zahtevali, na namizju in telefonu?
• Sosede. Stvari na isti strani in tokove, ki uporabljajo iste podatke.
• Kritično pot. Registracija, prijava, glavno dejanje, plačilo. Pol minute preverjanja po vsaki večji spremembi ujame večino okvar zgodaj.

Če nekaj ni v redu, to natančno opišite – glejte kako napisati dobro poročilo o napaki.

6. korak: vrnite se nazaj, namesto da kopičite popravke

Ko sprememba nekaj pokvari in prvi popravek ne deluje, se ustavite. Vsak dodatni „popravek“ temelji na pokvarjenem stanju, težave pa se kopičijo.

Namesto tega:

1. Vrnite se na zadnjo različico, ki je delovala (kontrolna točka ali commit v Gitu).
2. Ugotovite, kaj je bilo v pozivu nejasno.
3. Poskusite znova z manjšo ali jasnejšo zahtevo.

Ta sprememba je pokvarila shranjevanje osnutkov. Vrnil sem se nazaj. Tokrat samo: dodaj indikator samodejnega shranjevanja kot besedilo v glavi. Ne spreminjaj, kako se osnutki shranjujejo.

7. korak: vedite, kdaj je gradnja znova prava odločitev

Gradnja od začetka zavrže veliko delujočih podrobnosti. Vredna je le, ko:

• se je ideja izdelka povsem spremenila;
• struktura ne more podpreti tistega, kar zdaj potrebujete – na primer, zgrajena je bila kot statična stran, zdaj pa potrebuje račune in bazo podatkov;
• je projekt še blizu praznega.

Ko gradite znova, naštejte, kaj obdržati: ime, barve, besedilo, dele, ki so se uporabnikom všeč.

Primeri pozivov

Preden nadaljujemo, povzemi, kako aplikacija zdaj deluje: strani, podatke, ki jih shranjuje, in kar meniš, da je krhko.

Želim dodati ponavljajoče se rezervacije. Kaj je najmanjša različica, ki bi bila uporabna? Predlagaj jo kot tri ločene spremembe, ki jih lahko naredimo eno za drugo.

Preglej zadnje tri spremembe, ali so morda pokvarile tok plačila. Še ne ureja.

Pogoste napake

• Deset zahtev v enem pozivu. Nekatere so narejene, nekatere pol, in ne veste, katere.
• Nejasne povratne informacije. „Je pokvarjeno“ ali „naredi bolje“ povzroči ugibanje.
• Nikoli ne preverite sosedov. Sprememba skupne komponente pokvari tri druge strani.
• Popravljanje popravkov. Če ste štiri pozive globoko v eni napaki, se vrnite nazaj.
• Ponavljanje konteksta vsakič, namesto da stalna pravila hranite v opombah projekta.
• Gradnja od začetka, ko ste obupani. Večina trenutkov „začnimo znova“ je v resnici „vrnite se dva koraka nazaj“.

Kontrolni seznam

• En cilj na poziv.
• Opisujem, kaj vidim in kaj naj se zgodi.
• Velike spremembe dobijo načrt, preden pride koda.
• Povem, kaj se ne sme spremeniti.
• Po vsaki spremembi preverim to, sosede in kritično pot.
• Shranim kontrolno točko ali commit po vsaki delujoči spremembi.
• Ko popravek ne uspe, se vrnem nazaj, namesto da kopičim popravke.
• Stalna pravila so v opombah projekta, ki jih AI prebere vsakič.

Izboljševanje na Mythex

Mythex je zgrajen okoli te zanke:

• Načini Plan, Build in Ask. Plan obravnava pristop, preden se ureja; Ask odgovarja, ne da bi spremenil kodo; Build naredi spremembo. Glejte Klepet.
• Kontrolne točke. Po vsakem uspešnem koraku Mythex shrani git kontrolno točko; Revert to this point se vrne nazaj. Lahko tudi uredite prejšnje sporočilo in izberete Discard & resend, da poskusite drugačen poziv od tam naprej. Glejte Izboljšujte brez ponovne gradnje.
• Znanje. Nastavitve projekta → Knowledge hranijo stalne opombe, ki jim agent sledi pri vsakem sporočilu.
• /test naj agent po veliki spremembi klikne po predogledu kot uporabnik.

Manjše zahteve stanejo tudi manj kreditov. Za pisanje samih pozivov glejte kako pisati pozive za AI graditelje aplikacij; ko kaj vseeno pokvari, kako odpravljati napake v aplikaciji, zgrajeni z AI.

Vprašanja