Πώς να συνεχίσετε να εξελίσσετε μια εφαρμογή χτισμένη με AI χωρίς να την χαλάσετε

Για να εξελίξετε μια εφαρμογή χτισμένη με AI χωρίς να την χαλάσετε, αλλάξτε ένα πράγμα ανά prompt, ελέγξτε το στην προεπισκόπηση και αποθηκεύστε ένα checkpoint πριν προχωρήσετε. Περιγράψτε τι βλέπετε αντί για το τι πιστεύετε ότι κάνει ο κώδικας, σχεδιάστε τις μεγάλες αλλαγές πριν τις χτίσετε, και όταν μια αλλαγή πάει στραβά, επιστρέψτε στην τελευταία καλή έκδοση αντί να ζητάτε από την AI να διορθώσει τη δική της διόρθωση.

Η πρώτη έκδοση μιας εφαρμογής συχνά ολοκληρώνεται σε λίγα λεπτά. Το δύσκολο είναι η πεντηκοστή αλλαγή, όταν κάθε νέο prompt κινδυνεύει να σπάσει κάτι που ήδη δούλευε. Αυτός ο οδηγός είναι ο βρόχος που το εμποδίζει.

Ο βρόχος εξέλιξης

1. Επιλέξτε μία αλλαγή. Μία λειτουργία, ένα σφάλμα, μία σελίδα.
2. Περιγράψτε την με όρους όσων βλέπει και κάνει ο χρήστης.
3. Για μεγάλες αλλαγές, σχεδιάστε πρώτα. Ζητήστε ένα πλάνο, διαβάστε το, και μετά χτίστε.
4. Ελέγξτε το αποτέλεσμα στην προεπισκόπηση — την αλλαγή και τις ροές γύρω της.
5. Αποθηκεύστε ένα checkpoint ή ένα commit.
6. Επαναλάβετε.

Κάθε βήμα υπάρχει για να κρατά τις αλλαγές μικρές και αναστρέψιμες.

Βήμα 1: Κρατήστε μια σύντομη λίστα

Πριν στείλετε prompt, γράψτε τι θέλετε να αλλάξετε, με σειρά σημασίας. Σας εμποδίζει να στείλετε μια παράγραφο με δέκα επιθυμίες σε ένα μήνυμα, και σας δίνει τρόπο να πείτε «όχι τώρα» σε ιδέες που εμφανίζονται στη μέση.

Αν μια αλλαγή είναι μεγάλη, χωρίστε την. Το «Πρόσθεσε λογαριασμούς ομάδας» γίνεται: δημιουργία ομάδων, πρόσκληση μέλους, εναλλαγή μεταξύ ομάδων, περιορισμός των δεδομένων στην τρέχουσα ομάδα. Κάθε ένα είναι δικό του prompt. Το πώς να γράφετε ιστορίες χρηστών είναι ένας καλός τρόπος για αυτό.

Βήμα 2: Περιγράψτε τι βλέπετε

Η AI δεν βλέπει την οθόνη σας αν δεν της το πείτε. Δείξτε συγκεκριμένα πράγματα και πείτε τι πρέπει να συμβαίνει:

Στη σελίδα τιμολόγησης σε κινητό, το κουμπί της κάρτας Pro κόβεται στη δεξιά άκρη. Κράτα την διάταξη της επιφάνειας εργασίας ίδια· σε οθόνες κάτω από 640px, βάλε τις κάρτες η μία κάτω από την άλλη και κάνε τα κουμπιά πλήρους πλάτους.

Συγκρίνετέ το με το «η σελίδα τιμολόγησης φαίνεται άσχημα σε κινητό». Το πρώτο μπορεί να γίνει και να ελεγχθεί μονομιάς· το δεύτερο προσκαλεί έναν ανασχεδιασμό που δεν ζητήσατε.

Τα στιγμιότυπα οθόνης βοηθούν. Αν ο builder σας δέχεται εικόνες, επισυνάψτε μία και κυκλώστε το πρόβλημα.

Βήμα 3: Σχεδιάστε πριν από τις μεγάλες αλλαγές

Για οτιδήποτε αγγίζει πολλά μέρη της εφαρμογής — ένα νέο μοντέλο δεδομένων, πληρωμές, ρόλοι χρηστών — ζητήστε πλάνο πριν αλλάξει οποιοσδήποτε κώδικας:

Μην αλλάξεις ακόμη κώδικα. Θέλω οι χρήστες να ανήκουν σε ομάδες και να βλέπουν μόνο τα έργα της ομάδας τους. Σχεδίασε την αλλαγή: ποιοι πίνακες, σελίδες και διαδρομές API αλλάζουν, τι γίνεται με τα δεδομένα των υπαρχόντων χρηστών, και με ποια σειρά θα τα χτίζατε.

Διαβάστε το πλάνο. Αν είναι λάθος, η διόρθωση ενός πλάνου κοστίζει πολύ λιγότερο από το ξεφτιλίσμα ενός χτισίματος.

Βήμα 4: Πείτε τι δεν πρέπει να αλλάξει

Τα εργαλεία AI μερικές φορές «τακτοποιούν» πράγματα για τα οποία δεν ρωτήσατε. Προστατέψτε ό,τι δουλεύει:

Πρόσθεσε φίλτρο ημερομηνίας στον πίνακα παραγγελιών. Μην αλλάξεις τις στήλες, το στυλ ή το κουμπί εξαγωγής του πίνακα.

Για κανόνες που ισχύουν παντού — χρώματα της επωνυμίας, τόνος φωνής, «ποτέ μη διαγράφεις δεδομένα χωρίς επιβεβαίωση» — βάλτε τους σε ένα αρχείο σημειώσεων έργου ή ρύθμιση γνώσης που διαβάζει η AI κάθε φορά, αντί να τους επαναλαμβάνετε.

Βήμα 5: Ελέγξτε περισσότερα από την αλλαγή

Μετά από κάθε prompt, δοκιμάστε:

• Την ίδια την αλλαγή. Κάνει αυτό που ζητήσατε, στην επιφάνεια εργασίας και στο κινητό;
• Τους γείτονές της. Πράγματα στην ίδια σελίδα, και ροές που χρησιμοποιούν τα ίδια δεδομένα.
• Την κρίσιμη διαδρομή. Εγγραφή, σύνδεση, η κύρια ενέργεια, η πληρωμή. Ένας έλεγχος τριάντα δευτερολέπτων μετά από κάθε μεγάλη αλλαγή πιάνει τα περισσότερα προβλήματα νωρίς.

Αν κάτι δεν πάει καλά, αναφέρετέ το με ακρίβεια — δείτε πώς να γράψετε καλή αναφορά σφάλματος.

Βήμα 6: Κάντε rollback αντί να στοιβάζετε

Όταν μια αλλαγή σπάσει κάτι και η πρώτη διόρθωση δεν λειτουργεί, σταματήστε. Κάθε επιπλέον «διόρθωση» βασίζεται σε χαλασμένη κατάσταση, και τα προβλήματα πολλαπλασιάζονται.

Αντ' αυτού:

1. Επιστρέψτε στην τελευταία έκδοση που δούλευε (ένα checkpoint ή ένα commit Git).
2. Βρείτε τι ήταν ασαφές στο prompt.
3. Δοκιμάστε ξανά με μικρότερο ή σαφέστερο αίτημα.

Αυτή η αλλαγή χάλασε την αποθήκευση των προσχεδίων. Έκανα rollback. Αυτή τη φορά: πρόσθεσε μόνο την ένδειξη αυτόματης αποθήκευσης, ως κείμενο στην κεφαλίδα. Μην αλλάξεις τον τρόπο αποθήκευσης των προσχεδίων.

Βήμα 7: Ξέρετε πότε ο ξαναχτισμός είναι σωστός

Ο ξαναχτισμός από την αρχή πετάει πολλές λεπτομέρειες που δούλευαν. Αξίζει μόνο όταν:

• Η ιδέα του προϊόντος έχει αλλάξει εντελώς.
• Η υποκείμενη δομή δεν μπορεί να στηρίξει όσα χρειάζεστε τώρα — για παράδειγμα, χτίστηκε ως στατικός ιστότοπος και τώρα χρειάζεται λογαριασμούς και βάση δεδομένων.
• Το έργο είναι ακόμη σχεδόν άδειο.

Όταν ξαναχτίζετε, γράψτε τι να κρατήσετε: όνομα, χρώματα, κείμενα, τα μέρη που άρεσαν στους χρήστες.

Παραδείγματα prompts

Πριν συνεχίσουμε, συνόψισε πώς λειτουργεί τώρα η εφαρμογή: σελίδες, δεδομένα που αποθηκεύει και ό,τι θεωρείς εύθραυστο.

Θέλω να προσθέσω επαναλαμβανόμενες κρατήσεις. Ποια είναι η μικρότερη έκδοση που θα ήταν χρήσιμη; Πρότεινέ την ως τρεις ξεχωριστές αλλαγές που θα κάνουμε μία μία.

Ελέγξε τις τρεις τελευταίες αλλαγές για οτιδήποτε μπορεί να έχει χαλάσει τη ροή του ταμείου. Μην επεξεργαστείς ακόμη.

Συχνά λάθη

• Δέκα αιτήματα σε ένα prompt. Κάποια γίνονται, κάποια μισά, και δεν μπορείτε να πείτε ποια.
• Ασαφή σχόλια. Το «είναι χαλασμένο» ή «κάν' το καλύτερο» παράγει εικασίες.
• Να μην ελέγχετε ποτέ τους γείτονες. Μια αλλαγή σε κοινό στοιχείο χαλάει τρεις άλλες σελίδες.
• Διορθώσεις διορθώσεων. Τέσσερα prompts βαθιά σε ένα σφάλμα, κάντε rollback.
• Επανάληψη του ίδιου πλαισίου κάθε φορά αντί να κρατάτε τους κανόνες στις σημειώσεις έργου.
• Ξαναχτίζετε όταν κολλάτε. Τα περισσότερα στιγμιότυπα «ξεκινάμε από την αρχή» σημαίνουν στην πραγματικότητα «επιστρέφουμε δύο βήματα πίσω».

Λίστα ελέγχου

• Ένας στόχος ανά prompt.
• Περιγράφω τι βλέπω και τι πρέπει να συμβαίνει.
• Οι μεγάλες αλλαγές έχουν πλάνο πριν από τον κώδικα.
• Λέω τι δεν πρέπει να αλλάξει.
• Μετά από κάθε αλλαγή ελέγχω αυτήν, τους γείτονές της και την κρίσιμη διαδρομή.
• Αποθηκεύω checkpoint ή commit μετά από κάθε αλλαγή που δουλεύει.
• Όταν μια διόρθωση αποτύχει, κάνω rollback αντί να στοιβάζω διορθώσεις.
• Οι σταθεροί κανόνες ζουν στις σημειώσεις έργου που διαβάζει η AI κάθε φορά.

Εξέλιξη στο Mythex

Το Mythex είναι χτισμένο γύρω από αυτόν τον βρόχο:

• Λειτουργίες Plan, Build και Ask. Το Plan συζητά την προσέγγιση πριν από οποιαδήποτε επεξεργασία· το Ask απαντά χωρίς να αλλάζει κώδικα· το Build κάνει την αλλαγή. Δείτε Συνομιλία.
• Checkpoints. Μετά από κάθε επιτυχημένη σειρά, το Mythex αποθηκεύει ένα checkpoint git· το Επιστροφή σε αυτό το σημείο κάνει rollback. Μπορείτε επίσης να επεξεργαστείτε ένα προηγούμενο μήνυμα και να επιλέξετε Απόρριψη και επαναποστολή για να δοκιμάσετε διαφορετικό prompt από εκείνο το σημείο. Δείτε Εξέλιξη χωρίς ξαναχτίσιμο.
• Γνώση. Ρυθμίσεις έργου → Γνώση κρατά σταθερές σημειώσεις που ακολουθεί ο agent σε κάθε μήνυμα.
• Το /test ζητά από τον agent να κάνει κλικ στην προεπισκόπηση σαν χρήστης μετά από μια μεγάλη αλλαγή.

Οι μικρότερες παραγγελίες κοστίζουν και λιγότερα credits. Για τη συγγραφή των ίδιων των prompts, δείτε πώς να γράφετε prompts για AI app builders· όταν κάτι χαλάσει, πώς να κάνετε debug μια εφαρμογή χτισμένη με AI.

Ερωτήσεις