Cum îmbunătățești o aplicație construită cu AI fără să o strici

Ca să îmbunătățești o aplicație construită cu AI fără să o strici, schimbă un singur lucru per prompt, verifică-l în previzualizare și salvează un punct de control înainte să mergi mai departe. Descrie ce vezi, nu ce crezi că face codul, planifică schimbările mari înainte să le construiești și, când o schimbare nu merge, revino la ultima versiune bună, în loc să ceri AI-ului să-și repare propria reparație.

Prima versiune a unei aplicații se adună adesea în câteva minute. Partea grea este a cincizecea schimbare, când fiecare prompt nou riscă să strice ceva care deja funcționa. Acest ghid este ciclul care împiedică asta.

Ciclul de îmbunătățire

1. Alege o schimbare. O funcție, o eroare, o pagină.
2. Descrie-o în termenii a ceea ce vede și face utilizatorul.
3. Pentru schimbările mari, planifică întâi. Cere un plan, citește-l, apoi construiește.
4. Verifică rezultatul în previzualizare — schimbarea și fluxurile din apropiere.
5. Salvează un punct de control sau un commit.
6. Repetă.

Fiecare pas există ca să păstreze schimbările mici și reversibile.

Pasul 1: Ține o listă scurtă

Înainte să scrii promptul, notează ce vrei să schimbi, în ordinea importanței. Te oprește să trimiți un paragraf cu zece dorințe într-un singur mesaj și îți oferă o cale să spui „nu acum” ideilor care apar pe parcurs.

Dacă o schimbare este mare, descompune-o. „Adaugă conturi de echipă” devine: creează echipe, invită un membru, comută între echipe, limitează datele la echipa curentă. Fiecare este propriul prompt. Scrierea poveștilor de utilizator este un mod bun de a face asta.

Pasul 2: Descrie ce vezi

AI-ul nu îți vede ecranul dacă nu îi spui. Indică lucruri concrete și spune ce ar trebui să se întâmple:

Pe pagina de prețuri, de pe telefon, butonul cardului Pro este tăiat la marginea dreaptă. Păstrează aspectul de desktop neschimbat; pe ecrane sub 640px, pune cardurile unul sub altul și fă butoanele cu lățime completă.

Comparează cu „pagina de prețuri arată prost pe mobil”. Primul poate fi făcut și verificat dintr-o dată; al doilea invită o regândire pe care nu ai cerut-o.

Captura de ecran ajută. Dacă constructorul tău acceptă imagini, atașează una și încercuiește problema.

Pasul 3: Planifică înainte de schimbările mari

Pentru orice atinge mai multe părți ale aplicației — un model nou de date, plăți, roluri de utilizator — cere un plan înainte ca vreun cod să se schimbe:

Nu schimba codul încă. Vreau ca utilizatorii să aparțină unor echipe și să vadă doar proiectele echipei lor. Planifică schimbarea: ce tabele, pagini și rute API se schimbă, ce se întâmplă cu datele utilizatorilor existenți și în ce ordine le-ai construi.

Citește planul. Dacă e greșit, corectarea unui plan costă mult mai puțin decât anularea unei construcții.

Pasul 4: Spune ce nu trebuie să se schimbe

Uneltele AI uneori „aranjează” lucruri despre care nu ai întrebat. Protejează ce funcționează:

Adaugă un filtru de dată în tabelul comenzilor. Nu schimba coloanele tabelului, stilul sau butonul de export.

Pentru regulile care se aplică peste tot — culorile brandului, tonul vocii, „nu șterge niciodată date fără confirmare” — pune-le într-un fișier de notițe al proiectului sau într-o setare de cunoștințe pe care AI-ul o citește de fiecare dată, în loc să le repeți.

Pasul 5: Verifică mai mult decât schimbarea

După fiecare prompt, testează:

• Schimbarea în sine. Face ce ai cerut, pe desktop și pe telefon?
• Vecinii. Lucrurile de pe aceeași pagină și fluxurile care folosesc aceleași date.
• Calea critică. Înscriere, autentificare, acțiunea principală, plata. O trecere de treizeci de secunde după fiecare schimbare mare prinde din timp cea mai mare parte a stricăciunilor.

Dacă ceva nu este în regulă, raportează-l precis — vezi cum să scrii un bun raport de eroare.

Pasul 6: Revino în urmă în loc să aduni reparații

Când o schimbare strică ceva și prima reparație nu funcționează, oprește-te. Fiecare „reparație” în plus se construiește pe o stare stricată, iar problemele se adună.

În schimb:

1. Revino la ultima versiune care a funcționat (un punct de control sau un commit Git).
2. Descoperă ce nu era clar în prompt.
3. Încearcă din nou cu o cerere mai mică sau mai clară.

Schimbarea aceea a stricat salvarea ciornelor. Am revenit în urmă. De data asta: adaugă doar indicatorul de salvare automată, ca text în antet. Nu schimba modul în care sunt salvate ciornele.

Pasul 7: Știi când o reconstrucție este potrivită

Reconstruirea de la zero aruncă multe detalii care funcționau deja. Merită doar când:

• Ideea de produs s-a schimbat complet.
• Structura de bază nu poate susține ce ai nevoie acum — de exemplu, a fost construită ca site static și acum are nevoie de conturi și de o bază de date.
• Proiectul este încă aproape gol.

Când reconstruiești, fă o listă cu ce să păstrezi: numele, culorile, textele, părțile care au plăcut utilizatorilor.

Exemple de prompturi

Înainte să continuăm, rezumă cum funcționează acum aplicația: pagini, date stocate și orice crezi că este fragil.

Vreau să adaug rezervări recurente. Care este cea mai mică versiune care ar fi utilă? Propune-o ca trei schimbări separate, pe care le putem face una câte una.

Verifică ultimele trei schimbări pentru orice ar fi putut strica fluxul de finalizare a comenzii. Nu edita încă.

Greșeli frecvente

• Zece cereri într-un singur prompt. Unele sunt făcute, altele pe jumătate, iar tu nu poți spune care.
• Feedback vag. „E stricat” sau „fă-l mai bun” produce ghicituri.
• Să nu verifici niciodată vecinii. O schimbare la o componentă comună strică alte trei pagini.
• Repararea reparațiilor. Dacă ești la patru prompturi de adâncime într-o eroare, revino în urmă.
• Repetarea contextului de fiecare dată în loc să păstrezi regulile permanente în notițele proiectului.
• Reconstruirea când ești blocat. Majoritatea momentelor de „o luăm de la capăt” înseamnă de fapt „revino doi pași în urmă”.

Listă de verificare

• Un singur obiectiv per prompt.
• Descriu ce văd și ce ar trebui să se întâmple.
• Schimbările mari primesc un plan înainte de orice cod.
• Spun ce nu trebuie să se schimbe.
• După fiecare schimbare testez schimbarea, vecinii și calea critică.
• Salvez un punct de control sau un commit după fiecare schimbare care funcționează.
• Când o reparație eșuează, revin în urmă în loc să adaug reparații peste reparații.
• Regulile permanente stau în notițele proiectului, pe care AI-ul le citește de fiecare dată.

Îmbunătățirea pe Mythex

Mythex este construit în jurul acestui ciclu:

• Modurile Plan, Build și Ask. Plan discută abordarea înainte de editare; Ask răspunde fără să schimbe codul; Build face schimbarea. Vezi Chat.
• Puncte de control. După fiecare tură reușită, Mythex salvează un punct de control git; Revert to this point revine în urmă. Poți, de asemenea, să editezi un mesaj anterior și să alegi Discard & resend ca să încerci un alt prompt din acel punct. Vezi Îmbunătățește fără să reconstruiești.
• Knowledge. Project settings → Knowledge conține notițe permanente pe care agentul le urmează la fiecare mesaj.
• /test îl face pe agent să parcurgă previzualizarea ca un utilizator, după o schimbare mare.

Cererile mai mici costă și mai puține credite. Pentru scrierea prompturilor, vezi cum să scrii prompturi pentru constructorii de aplicații cu AI; când ceva se strică, cum să depanezi o aplicație construită cu AI.

Întrebări