Si të përmirësoni një aplikacion të ndërtuar me AI pa e prishur

Për të përmirësuar një aplikacion të ndërtuar me AI pa e prishur, ndryshoni një gjë për çdo kërkesë, kontrolloni në pamjen paraprake dhe ruani një pikë kontrolli përpara se të vazhdoni. Përshkruani çfarë shihni në vend të asaj që mendoni se bën kodi, planifikoni ndryshimet e mëdha përpara se t'i ndërtoni, dhe kur një ndryshim shkon keq, kthehuni te versioni i fundit që funksionoi në vend që t'i kërkoni AI-së të rregullojë rregullimin e vet.

Versioni i parë i një aplikacioni shpesh mblidhet në minuta. Pjesa e vështirë është ndryshimi i pesëdhjetë, kur çdo kërkesë e re rrezikon të prishë diçka që tashmë funksionon. Ky udhëzues është cikli që e parandalon këtë.

Cikli i përmirësimit

1. Zgjidhni një ndryshim. Një veçori, një gabim, një faqe.
2. Përshkruajeni me fjalët e asaj që përdoruesi shikon dhe bën.
3. Për ndryshimet e mëdha, planifikoni së pari. Kërkoni një plan, lexojeni, pastaj ndërtoni.
4. Kontrolloni rezultatin në pamjen paraprake — ndryshimin dhe rrjedhat pranë tij.
5. Ruani një pikë kontrolli ose një commit.
6. Përsëriteni.

Çdo hap ekziston për të mbajtur ndryshimet të vogla dhe të kthyeshme.

Hapi 1: Mbani një listë të shkurtër

Para se të kërkoni, shkruani çfarë doni të ndryshoni, me rend rëndësie. Kjo ju ndalon të dërgoni një paragraf me dhjetë dëshira në një mesazh, dhe ju jep një mënyrë për të thënë „jo tani" për idetë që lindin në mes të punës.

Nëse një ndryshim është i madh, ndajeni. „Shto llogari ekipi" bëhet: krijo ekipe, fto një anëtar, kalo mes ekipeve, kufizo të dhënat në ekipin aktual. Secila është një kërkesë e veçantë. Shkrimi i historive të përdoruesit është një mënyrë e mirë për ta bërë këtë.

Hapi 2: Përshkruani çfarë shihni

AI nuk e sheh ekranin tuaj përveç nëse ia thoni ju. Tregoni elemente specifike dhe thoni çfarë duhet të ndodhë:

Në faqen e çmimeve në telefon, butoni i kartës Pro del jashtë buzës së djathtë. Mbaje paraqitjen e desktopit të njëjtë; në ekrane nën 640px, vendosi kartat njëra nën tjetrën dhe bëji butonat me gjerësi të plotë.

Krahasojeni me „faqja e çmimeve duket keq në celular". E para mund të bëhet dhe kontrollohet në një herë; e dyta fton një ridizajnim që nuk e keni kërkuar.

Përfshirja e një pamjeje ndihmon. Nëse builder-i juaj pranon imazhe, bashkëngjitni një dhe rrethoni problemin.

Hapi 3: Planifikoni përpara ndryshimeve të mëdha

Për çdo gjë që prek disa pjesë të aplikacionit — një model i ri të dhënash, pagesa, role përdoruesish — kërkoni një plan përpara se kodi të ndryshojë:

Mos ndrysho kodin ende. Dua që përdoruesit t'i përkasin ekipeve dhe të shohin vetëm projektet e ekipit të tyre. Planifiko ndryshimin: cilat tabela, faqe dhe rrugë API ndryshojnë, çfarë ndodh me të dhënat ekzistuese të përdoruesve, dhe në çfarë rendi do ta ndërtonit.

Lexoni planin. Nëse është i gabuar, korrigjimi i një plani kushton shumë më pak sesa zhbërja e një ndërtimi.

Hapi 4: Thoni çfarë nuk duhet të ndryshojë

Disa herë mjetet AI „rregullojnë" gjëra që nuk i keni kërkuar. Mbroni atë që funksionon:

Shto një filtër datash te tabela e porosive. Mos ndrysho kolonat, stilin ose butonin e eksportit të tabelës.

Për rregulla që zbatohen kudo — ngjyrat e markës, tonin e zërit, „mos fshi kurrë të dhëna pa konfirmim" — vendosini në një skedar shënimesh ose njohurish të projektit që AI e lexon çdo herë, në vend që t'i përsëritni.

Hapi 5: Kontrolloni më shumë sesa ndryshimi

Pas çdo kërkese, testoni:

• Vetë ndryshimin. A bën atë që kërkuat, në desktop dhe në telefon?
• Fqinjët e tij. Gjërat në të njëjtën faqe dhe rrjedhat që përdorin të njëjtat të dhëna.
• Rrugën kritike. Regjistrim, hyrje, veprimi kryesor, pagesa. Një kalim tridhjetësekondësh pas çdo ndryshimi të madh kap shumicën e prishjeve herët.

Nëse diçka nuk shkon, raportojeni saktë — shihni si të shkruani një raport të mirë gabimi.

Hapi 6: Kthehuni prapa në vend që të grumbulloni

Kur një ndryshim prish diçka dhe rregullimi i parë nuk funksionon, ndaloni. Çdo „rregullim“ shtesë ndërtohet mbi një gjendje të prishur, dhe problemet shtohen.

Në vend të kësaj:

1. Kthehuni te versioni i fundit që funksionoi (një pikë kontrolli ose një commit Git).
2. Mendoni çfarë ishte e paqartë në kërkesë.
3. Provoni përsëri me një kërkesë më të vogël ose më të qartë.

Ai ndryshim prishi ruajtjen e draft-eve. Jam kthyer prapa. Kësaj here: shto vetëm treguesin e ruajtjes automatike, si tekst në kokë. Mos ndrysho mënyrën se si ruhen draft-et.

Hapi 7: Dijeni kur ndërtimi nga e para është i duhuri

Ndërtimi nga e para hedh poshtë shumë detaje që funksionojnë. Vlen vetëm kur:

• Ideja e produktit ka ndryshuar plotësisht.
• Struktura themelore nuk mund të mbajë atë që ju duhet tani — për shembull, u ndërtua si faqe statike dhe tani ka nevojë për llogari dhe bazë të dhënash.
• Projekti është ende pothuajse bosh.

Kur e ndërtoni përsëri, listoni çfarë duhet ruajtur: emrin, ngjyrat, tekstin, pjesët që përdoruesit i pëlqyen.

Shembuj kërkesash

Përpara se të vazhdojmë, përmblidh si funksionon aplikacioni tani: faqet, të dhënat që ruan dhe çdo gjë që mendon se është e brishtë.

Dua të shtoj rezervime të përsëritura. Cila është versioni më i vogël që do të ishte i dobishëm? Sugjeroje si tre ndryshime të veçanta që mund t'i bëjmë një nga një.

Shqyrto tre ndryshimet e fundit për çdo gjë që mund të ketë prishur rrjedhën e pagesës. Mos redakto ende.

Gabimet e zakonshme

• Dhjetë kërkesa në një prompt. Disa përfundojnë, disa gjysmë, dhe nuk e dini cilat.
• Feedback i paqartë. „Është prishur" ose „bëje më mirë" prodhon supozime.
• Kurrë mos kontrolloni fqinjët. Një ndryshim në një komponent të përbashkët prish tre faqe të tjera.
• Rregullime mbi rregullime. Katër kërkesa thellë në një gabim, kthehuni prapa.
• Përsëritja e kontekstit çdo herë në vend që rregullat e qëndrueshme të mbahen në shënimet e projektit.
• Rindërtimi kur bllokoheni. Shumica e momenteve „fillo nga e para" janë në fakt „kthehu dy hapa prapa".

Lista e kontrollit

• Një qëllim për çdo kërkesë.
• Përshkruaj çfarë shoh dhe çfarë duhet të ndodhë.
• Ndryshimet e mëdha marrin plan përpara çdo kodi.
• Them çfarë nuk duhet të ndryshojë.
• Pas çdo ndryshimi testoj atë, fqinjët dhe rrugën kritike.
• Ruaj një pikë kontrolli ose commit pas çdo ndryshimi që funksionon.
• Kur një rregullim dështon, kthehem prapa në vend që të grumbulloj rregullime.
• Rregullat e qëndrueshme jetojnë në shënimet e projektit që AI i lexon çdo herë.

Përmirësimi në Mythex

Mythex është ndërtuar rreth këtij cikli:

• Modalitetet Plan, Build dhe Ask. Plan diskuton qasjen përpara redaktimit; Ask përgjigjet pa ndryshuar kodin; Build bën ndryshimin. Shihni Bisedën.
• Pikat e kontrollit. Pas çdo kthese të suksesshme, Mythex ruan një pikë kontrolli git; Revert to this point kthen prapa. Mund të ndryshoni edhe një mesazh të mëparshëm dhe të zgjidhni Discard & resend për të provuar një prompt tjetër nga ai pikë. Shihni Përmirëso pa rindërtuar.
• Njohuritë. Cilësimet e projektit → Knowledge mbajnë shënime të qëndrueshme që agjenti i ndjek në çdo mesazh.
• /test e bën agjentin të klikojë nëpër pamjen paraprake si përdorues pas një ndryshimi të madh.

Kërkesat më të vogla kushtojnë gjithashtu më pak kredite. Për të shkruar vetë prompt-et, shihni si të shkruani prompt-e për AI app builders; kur diçka prishet, si të korrigjoni një aplikacion të ndërtuar me AI.

Pyetje