Tutorial 4 Prompting and Reviewing el

Μάθημα 4 · Prompting και έλεγχος

Στόχος: η μετα-δεξιότητα. Μπορείς πλέον να χτίσεις ένα χαρακτηριστικό με έναν πράκτορα — αυτό το κεφάλαιο αφορά το να το κάνεις ομαλά και επαναλήψιμα: γράφοντας prompts που πετυχαίνουν με την πρώτη, ελέγχοντας τα diffs αποδοτικά, επαναλαμβάνοντας όταν τα πράγματα πάνε στραβά, και διατηρώντας τη δυναμική σε όλες τις συνεδρίες.

← Προηγούμενο: Μάθημα 3 Η πρώτη σου εργασία με πράκτορα · Επόμενο: Μάθημα 5 Τοπικοποίηση

---

Κάνε prompt σαν επικεφαλής, όχι σαν κουτί αναζήτησης

Ο πράκτορας είναι ένας γρήγορος, κυριολεκτικός, πρόθυμος junior μηχανικός. Καθοδήγησέ τον όπως θα καθοδηγούσες έναν καλό:

• Δήλωσε τον στόχο και τους περιορισμούς. Το «Πρόσθεσε endorse» είναι αδύναμο. Το «Πρόσθεσε endorse ακολουθώντας το μοτίβο του connect, μόνο γεννήτρια με seed, με tests, η πύλη μένει πράσινη» είναι δυνατό. Οι περιορισμοί είναι ο τρόπος με τον οποίο παίρνεις κώδικα που ταιριάζει.
• Δείξε παραδείγματα. Το «Ακολούθησε το μοτίβο που χρησιμοποιεί η renderConnect» υπερτερεί μιας παραγράφου περιγραφής. Ο υπάρχων κώδικας είναι η καλύτερη προδιαγραφή.
• Ζήτα ένα πλάνο πριν τις επεξεργασίες σε οτιδήποτε μη τετριμμένο. Φτηνό να ανακατευθύνεις ένα πλάνο· ακριβό να ξηλώσεις δέκα επεξεργασμένα αρχεία.
• Μία εργασία ανά prompt. Το να μαζεύεις «πρόσθεσε endorse, επίσης κάνε refactor τη γεννήτρια, επίσης ενημέρωσε το README» παράγει ένα μπερδεμένο diff που είναι δύσκολο να ελεγχθεί.
• Δώσε του την πύλη ελέγχου. Το «Τρέξε npm test και μην το θεωρήσεις ολοκληρωμένο μέχρι να είναι πράσινο» μετατρέπει τον πράκτορα σε κάτι που ελέγχει τη δική του δουλειά.

Έλεγξε το diff κάθε φορά

Η ταχύτητα είναι όλο το νόημα ενός πράκτορα — αλλά η αδιάβαστη ταχύτητα είναι ο τρόπος με τον οποίο δημοσιεύονται bugs. Χτίσε ένα γρήγορο, σταθερό αντανακλαστικό ελέγχου:

1. Εύρος: άλλαξε μόνο ό,τι έπρεπε; Άσχετες μετακινημένες γραμμές είναι κακό σημάδι.
2. Μοτίβα: ταιριάζει με τον γύρω κώδικα, χωρίς νέες εξαρτήσεις και χωρίς I/O μέσα στο src/;
3. Οι κανόνες του έργου: για αυτό το αποθετήριο, αυτό είναι μόνο γεννήτρια με seed (κάνε grep το diff για Math.random), ορατό στον χρήστη κείμενο στα γλωσσικά bundles (όχι hardcoded), και οι γραμμές κάρτας ποτέ να μην ξεπερνούν το πλάτος στο οποίο η διάταξη κάνει padding.
4. Προσβασιμότητα: επιβιώνει η νέα έξοδος με --accessible; Τρέξε lockedin --accessible <your command> και έλεγξε ότι διαβάζεται ως καθαρό απλό κείμενο — χωρίς νέα διακοσμητικά glyphs να ξεγλιστρούν από το a11yFilter.
5. Tests: υπάρχει νέο test, και θα αποτύγχανε πράγματι αν το χαρακτηριστικό έσπαγε; Ρώτα: «Ποια γραμμή θα άλλαζα για να κάνω αυτό το νέο test να αποτύχει;»
6. Τρέξε το: npm test, μετά τρέξε την εντολή και κοίτα την έξοδο.

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

Επανάλαβε όταν δεν είναι πράσινο

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

«Το npm test αποτυγχάνει με: [paste the exact error]. Το test πλάτους της renderEndorse περιμένει κάθε γραμμή κάρτας ≤ 60 ορατές στήλες. Διόρθωσέ το χωρίς να αποδυναμώσεις το test.»

Επικόλλησε το πραγματικό κείμενο του σφάλματος. Το «Χάλασε» βάζει τον πράκτορα να μαντεύει· το stack trace τον βάζει να διορθώσει. Και προτίμησε να συνεχίσεις την ίδια συνομιλία αντί να ξεκινάς από την αρχή — ο πράκτορας έχει ήδη το context του τι μόλις έγραψε. Αν δύο ή τρεις επαναλήψεις δεν συγκλίνουν, κάνε ένα βήμα πίσω και επανακαθόρισε το εύρος: η εργασία μπορεί να είναι πολύ μεγάλη για ένα prompt.

Διατήρησε τη δυναμική σε όλες τις συνεδρίες

Η πραγματική δουλειά εκτείνεται σε περισσότερες από μία συνεδρίες. Δύο συνήθειες κρατούν έναν πράκτορα αποτελεσματικό με τον χρόνο:

• Μνήμη / συμβάσεις. Αν ο πράκτοράς σου υποστηρίζει μόνιμη μνήμη ή ένα αρχείο οδηγιών έργου, κατέγραψε εκεί τους κανόνες που πρέπει πάντα να ακολουθεί (π.χ. «όλη η τυχαιότητα πρέπει να χρησιμοποιεί pick/shuffle», «τρέξε npm test πριν δηλώσεις ολοκληρωμένο»). Δηλώνεις μια σύμβαση μία φορά αντί για κάθε prompt.
• Ένα σημείωμα παράδοσης. Αυτό το αποθετήριο κρατά ένα σύντομο, καθαρισμένο έγγραφο κατάστασης στο docs/HANDOFF.md: τι είναι το έργο, πώς είναι φτιαγμένο, πώς ελέγχεται, και τι ακολουθεί. Όταν επιστρέφεις (ή παραδίδεις σε συνάδελφο — ή σε άλλον πράκτορα), αυτό το σημείωμα ξαναχτίζει το context σε δευτερόλεπτα. Ζήτα από τον πράκτορά σου να το κρατά ενημερωμένο ως μέρος μιας αλλαγής.

Προστατευτικά κιγκλιδώματα που αξίζει να κρατήσεις

• Η πύλη είναι αδιαπραγμάτευτη. Πράσινα tests πριν δημοσιευτεί οτιδήποτε. Είναι αυτό που σε αφήνει να κινείσαι γρήγορα και να εμπιστεύεσαι την έξοδο.
• Είσαι ο επίσημος ελεγκτής. Ο πράκτορας γράφει· εσύ αποφασίζεις. Το να αποδεχτείς ένα diff σημαίνει ότι εγγυάσαι γι' αυτό.
• Μικρά, επαληθεύσιμα βήματα υπερτερούν ενός γιγαντιαίου άλματος. Κάθε αποδεκτή αλλαγή θα πρέπει να αφήνει την εφαρμογή λειτουργική.

---

✅ Δοκίμασέ το με τον πράκτορά σου

1. Γράψε μια προδιαγραφή μιας παραγράφου για μια εντολή mentor («μοιράζει αζήτητες συμβουλές»), συμπεριλαμβάνοντας περιορισμούς, και βάλε τον πράκτορα να την χτίσει tests-πρώτα — πλάνο, tests, κώδικας, πύλη — ελέγχοντας σε κάθε βήμα.
2. Ζήτα από τον πράκτορα να ενημερώσει το docs/HANDOFF.md ώστε να αναφέρει τη νέα εντολή.
3. Χάλασε επίτηδες κάτι (π.χ. διάγραψε μια εγγραφή pool), τρέξε npm test, και εξασκήσου στο να τροφοδοτείς τον πράκτορα με την ακριβή αποτυχία για διόρθωση.

---

Πού να πας στη συνέχεια

• Ξεφύλλισε τον πραγματικό κώδικα στο src/lockedin.js — ξέρεις πλέον το σχήμα του.
• Διάβασε το docs/HANDOFF.md για τις δικές του σημειώσεις κατάστασης και αρχιτεκτονικής του έργου.
• Απόλαυσε τα αστεία στην Αναφορά εντολών.

Αυτό είναι το μάθημα. Μπορείς πλέον να καθοδηγείς έναν πράκτορα AI ώστε να χτίζει και να αλλάζει πραγματικό λογισμικό πίσω από μια πύλη ελέγχου — χρησιμοποιώντας το πιο υπερβολικά σίγουρο παράδειγμα που μπορείς να φανταστείς. Συμφωνείς; 👇