Kā uzlabot AI veidotu lietotni, nesalaužot to

Lai uzlabotu AI veidotu lietotni, nemainiet vairāk par vienu lietu uzvednē, pārbaudiet to priekšskatījumā un saglabājiet kontrolpunktu, pirms ejat tālāk. Aprakstiet to, ko redzat, nevis to, ko, pēc jūsu domām, dara kods; lielas izmaiņas plānojiet pirms to veidošanas, un, kad izmaiņa noiet greizi, atgriezieties pie pēdējās labās versijas, nevis lūdziet AI labot savu pašu labojumu.

Lietotnes pirmā versija bieži top dažās minūtēs. Grūtākā daļa ir piecdesmitā izmaiņa, kad katra jauna uzvedne riskē salauzt to, kas jau strādāja. Šis ceļvedis ir cilpa, kas to novērš.

Iterācijas cilpa

1. Izvēlieties vienu izmaiņu. Viena funkcija, viena kļūda, viena lapa.
2. Aprakstiet to ar to, ko lietotājs redz un dara.
3. Lielām izmaiņām — vispirms plāns. Pieprasiet plānu, izlasiet to un tikai tad veidojiet.
4. Pārbaudiet rezultātu priekšskatījumā — izmaiņu un tuvējās plūsmas.
5. Saglabājiet kontrolpunktu vai commit.
6. Atkārtojiet.

Katrs solis pastāv, lai izmaiņas paliktu mazas un atgriezeniskas.

1. solis: turiet īsu sarakstu

Pirms uzvednes uzrakstiet, ko vēlaties mainīt, pēc svarīguma. Tas neļauj nosūtīt rindkopu ar desmit vēlmēm vienā ziņojumā un dod iespēju pateikt „ne šobrīd“ idejām, kas uzpeld pa vidu.

Ja izmaiņa ir liela, sadaliet to. „Pievienot komandu kontus“ kļūst par: izveidot komandas, uzaicināt dalībnieku, pārslēgties starp komandām, ierobežot datus pašreizējai komandai. Katrs ir atsevišķa uzvedne. Lietotāju stāstu rakstīšana ir labs veids, kā to izdarīt.

2. solis: aprakstiet, ko redzat

AI nevar redzēt jūsu ekrānu, ja jūs to neizstāstāt. Norādiet uz konkrētām lietām un pasakiet, kam vajadzētu notikt:

Cenu lapā telefonā Pro kartes poga ir apgriezta pa labo malu. Saglabājiet darbvirsmas izkārtojumu tādu pašu; zem 640 px ekrāniem sakārtojiet kartes vertikāli un padariet pogas pilnā platumā.

Salīdziniet ar „cenu lapa izskatās slikti mobilajā“. Pirmo var izdarīt un pārbaudīt vienā solī; otrs aicina uz pārprojektēšanu, ko neprasījāt.

Ekrānuzņēmumi palīdz. Ja jūsu veidotājs pieņem attēlus, pievienojiet vienu un apvelciet problēmu.

3. solis: plānojiet pirms lielām izmaiņām

Jebkam, kas skar vairākas lietotnes daļas — jaunu datu modeli, maksājumiem, lomām —, pieprasiet plānu, pirms kods mainās:

Vēl nemainiet kodu. Es gribu, lai lietotāji piederētu komandām un redzētu tikai savas komandas projektus. Izplāno izmaiņu: kuras tabulas, lapas un API maršruti mainīsies, kas notiks ar esošo lietotāju datiem un kādā secībā to būvētu.

Izlasiet plānu. Ja tas ir nepareizs, plāna labošana ir daudz lētāka nekā būves atsaukšana.

4. solis: pasakiet, kas nedrīkst mainīties

AI rīki dažkārt „sakārto“ lietas, par kurām neprasījāt. Aizsargājiet to, kas strādā:

Pievienojiet tabulai ar pasūtījumiem datuma filtru. Nemainiet tabulas kolonnas, stilu vai eksporta pogu.

Noteikumiem, kas attiecas visur — zīmola krāsas, toni, „nekad nedzēst datus bez apstiprinājuma“ —, ieliekiet tos projekta piezīmju failā vai zināšanu iestatījumos, ko AI lasa katru reizi, nevis atkārtojiet tos.

5. solis: pārbaudiet vairāk nekā pašu izmaiņu

Pēc katras uzvednes pārbaudiet:

• Pašu izmaiņu. Vai tā dara, ko prasījāt, datorā un tālrunī?
• Tās kaimiņus. Lietas tajā pašā lapā un plūsmas, kas izmanto tos pašus datus.
• Kritisko ceļu. Reģistrācija, pieteikšanās, galvenā darbība, maksājums. Trīsdesmit sekunžu pārbaude pēc katras lielās izmaiņas noķer lielāko daļu bojājumu agri.

Ja kaut kas nav kārtībā, ziņojiet precīzi — skatiet kā uzrakstīt labu kļūdas ziņojumu.

6. solis: atgriezieties, nevis uzkrājiet

Kad izmaiņa kaut ko salauž un pirmais labojums nepalīdz, apstājieties. Katrs papildu „labojums“ ir uzbūvēts uz salauzta stāvokļa, un problēmas sakrājas.

Tā vietā:

1. Atgriezieties pie pēdējās versijas, kas strādāja (kontrolpunkts vai Git commit).
2. Izdomājiet, kas uzvednē bija neskaidrs.
3. Mēģiniet vēlreiz ar mazāku vai skaidrāku pieprasījumu.

Šī izmaiņa salauza melnrakstu saglabāšanu. Esmu atgriezies. Šoreiz: pievienojiet tikai automātiskās saglabāšanas indikatoru kā tekstu galvenē. Nemainiet, kā melnraksti tiek saglabāti.

7. solis: zināt, kad pārveidošana ir pareiza

Pārveidošana no nulles izmet daudz strādājošas detaļas. Tā ir vērta tikai tad, ja:

• Produkta ideja ir pilnībā mainījusies.
• Pamatā esošā struktūra nevar atbalstīt to, kas tagad vajadzīgs — piemēram, tā veidota kā statiska vietne, bet tagad vajag kontus un datubāzi.
• Projekts vēl ir tuvu tukšam.

Kad tomēr pārveidojat, uzskaitiet, ko paturēt: nosaukumu, krāsas, tekstus, daļas, kas lietotājiem patika.

Piemēru uzvednes

Pirms turpinām, apkopo, kā lietotne pašlaik darbojas: lapas, dati, ko tā glabā, un tas, ko uzskati par trauslu.

Es gribu pievienot atkārtotas rezervācijas. Kāda ir mazākā versija, kas būtu noderīga? Iesaki to kā trīs atsevišķas izmaiņas, ko varam veikt pa vienai.

Pārskati pēdējās trīs izmaiņas, vai kāda varēja salauzt norēķinu plūsmu. Vēl nerediģē.

Biežākās kļūdas

• Desmit pieprasījumi vienā uzvednē. Daži tiek izdarīti, daži pusizdarīti, un nevar pateikt, kuri.
• Neskaidra atgriezeniskā saite. „Tas nestrādā“ vai „padari labāku“ rada minējumus.
• Nekad nepārbaudīt kaimiņus. Izmaiņa koplietotā komponentā salauž trīs citas lapas.
• Labojumu labošana. Ja četras uzvednes dziļi cīnāties ar vienu kļūdu, atgriezieties.
• Konteksta atkārtošana katru reizi, nevis pastāvīgo noteikumu glabāšana projekta piezīmēs.
• Pārveidošana, kad iestrēdzis. Vairums „sāc no jauna“ brīžu patiesībā nozīmē „atgriezties divus soļus atpakaļ“.

Kontrolsaraksts

• Viens mērķis uzvednē.
• Aprakstu, ko redzu un kam vajadzētu notikt.
• Lielas izmaiņas saņem plānu pirms jebkāda koda.
• Pasaku, kas nedrīkst mainīties.
• Pēc katras izmaiņas pārbaudu to, tās kaimiņus un kritisko ceļu.
• Saglabāju kontrolpunktu vai commit pēc katras darba izmaiņas.
• Kad labojums neizdodas, atgriežos, nevis uzkrāju labojumus.
• Pastāvīgie noteikumi dzīvo projekta piezīmēs, ko AI lasa katru reizi.

Iterēšana Mythex

Mythex ir veidots ap šo cilpu:

• Plāna, būves un jautāšanas režīmi. Plāns apspriež pieeju pirms rediģēšanas; Ask atbild, nemainot kodu; Build veic izmaiņu. Skatiet Čats.
• Kontrolpunkti. Pēc katras veiksmīgas kārtas Mythex saglabā git kontrolpunktu; Revert to this point atgriež atpakaļ. Varat arī rediģēt iepriekšēju ziņu un Discard & resend, lai izmēģinātu citu uzvedni no šī punkta. Skatiet Iterēt bez pārbūves.
• Zināšanas. Projekta iestatījumi → Knowledge satur pastāvīgas piezīmes, ko aģents ievēro katrā ziņojumā.
• /test liek aģentam pārklikšķināt priekšskatījumu kā lietotājam pēc lielām izmaiņām.

Mazāki pieprasījumi arī maksā mazāk kredītu. Par pašu uzvedņu rakstīšanu skatiet kā rakstīt uzvednes AI lietotņu veidotājiem; kad kaut kas tomēr salūst, kā atkļūdot AI veidotu lietotni.

Jautājumi