Tutorial 4 Prompting and Reviewing tr

Eğitim 4 · Yönlendirme ve İnceleme

Amaç: meta beceri. Artık bir ajanla bir özellik geliştirebiliyorsunuz — bu bölüm bunu akıcı ve tekrarlanabilir şekilde yapmakla ilgilidir: ilk seferde tutturan istemler yazmak, diff'leri verimli incelemek, işler ters gittiğinde yinelemek ve oturumlar arasında momentumu korumak.

← Önceki: Eğitim 3 İlk Ajan Göreviniz · Sonraki: Eğitim 5 Yerelleştirme

---

Bir arama kutusu gibi değil, bir lider gibi yönlendirin

Ajan, hızlı, harfi harfine ve istekli bir junior mühendistir. Onu iyi bir taneyi yönlendireceğiniz gibi yönlendirin:

• Amacı ve kısıtlamaları belirtin. "endorse ekle" zayıftır. "connect kalıbını izleyerek, yalnızca tohumlu RNG ile, testlerle, kapı yeşil kalarak endorse ekle" güçlüdür. Kısıtlamalar, uyan kodu elde etme yolunuzdur.
• Örnekleri gösterin. "renderConnect'in kullandığı kalıbı izle" bir paragraf açıklamayı yener. Mevcut kod en iyi spesifikasyondur.
• Önemsiz olmayan her şeyde düzenlemelerden önce bir plan isteyin. Bir planı yeniden yönlendirmek ucuzdur; on düzenlenmiş dosyayı geri almak pahalıdır.
• İstem başına bir görev. "endorse ekle, ayrıca RNG'yi yeniden düzenle, ayrıca README'yi güncelle" birleştirmesi, incelenmesi zor karmaşık bir diff üretir.
• Ona test kapısını verin. "npm test çalıştır ve yeşil olana kadar bitti sayma" ajanı kendi işini kontrol eden bir şeye dönüştürür.

Diff'i her seferinde inceleyin

Hız, bir ajanın tüm amacıdır — ama okunmamış hız, hataların gönderilme yoludur. Hızlı, tutarlı bir inceleme refleksi oluşturun:

1. Kapsam: yalnızca gerekeni mi değiştirdi? İlgisiz kaymış satırlar kötü bir koku.
2. Kalıplar: çevredeki kodla eşleşiyor mu, yeni bağımlılık ve src/ içinde I/O yok mu?
3. Projenin kuralları: bu depo için bu, yalnızca tohumlu RNG (diff'te Math.random arayın), kullanıcıya görünen metin dil paketlerinde (sabit kodlanmamış) ve kart satırları düzenin doldurduğu genişliği asla aşmaz.
4. Erişilebilirlik: yeni çıktı --accessible'dan sağ çıkar mı? lockedin --accessible <your command> çalıştırın ve temiz düz metin olarak okunduğunu kontrol edin — a11yFilter'dan sızan yeni dekoratif glif yok.
5. Testler: yeni bir test var mı ve özellik bozulsa gerçekten başarısız olur mu? Sorun: "Bu yeni testi başarısız kılmak için hangi satırı değiştirirdim?"
6. Çalıştırın: npm test, sonra komutu çalıştırın ve çıktıya bakın.

Her karakteri anlamanıza gerek yok — ama her kararı anlamalısınız. Bir değişikliği açıklayamıyorsanız, kabul etmeden önce ajandan onu açıklamasını isteyin.

Yeşil değilken yineleyin

Kırmızı bir kapı, bir başarısızlık değil, normal bir adımdır. Düzeltme, hassas geri bildirimdir:

"npm test şununla başarısız oluyor: [paste the exact error]. renderEndorse genişlik testi her kart satırının ≤ 60 görünür sütun olmasını bekliyor. Testi zayıflatmadan düzelt."

Gerçek hata metnini yapıştırın. "Bozuk" ajana tahmin ettirir; yığın izi ona düzelttirir. Ve yeniden başlamak yerine aynı konuşmayı sürdürmeyi tercih edin — ajanın az önce yazdığı şeyin bağlamı zaten var. İki veya üç yineleme yakınsamazsa, geri çekilip yeniden kapsam belirleyin: görev bir istem için çok büyük olabilir.

Oturumlar arasında momentumu koruyun

Gerçek iş, birden fazla oturumu kapsar. İki alışkanlık, bir ajanı zamanla etkili tutar:

• Bellek / kurallar. Ajanınız kalıcı bellek veya bir proje talimat dosyasını destekliyorsa, her zaman izlemesi gereken kuralları oraya kaydedin (örn. "tüm rastgelelik pick/shuffle kullanmalı", "bitti demeden önce npm test çalıştır"). Bir kuralı her istemde değil, bir kez belirtirsiniz.
• Bir devir notu. Bu depo, docs/HANDOFF.md'de kısa, temizlenmiş bir durum belgesi tutar: projenin ne olduğu, nasıl inşa edildiği, nasıl test edildiği ve sırada ne olduğu. Döndüğünüzde (veya bir takım arkadaşına — ya da başka bir ajana — devrettiğinizde), o not bağlamı saniyeler içinde yeniden inşa eder. Ajandan onu bir değişikliğin parçası olarak güncel tutmasını isteyin.

Korunmaya değer korkuluklar

• Kapı pazarlığa açık değildir. Herhangi bir şey gönderilmeden önce yeşil testler. Hızlı hareket etmenizi ve çıktıya güvenmenizi sağlayan şey budur.
• Kayıtlı incelemeci sizsiniz. Ajan yazar; siz karar verirsiniz. Bir diff'i kabul etmek, ona kefil olmanız demektir.
• Küçük, doğrulanabilir adımlar dev bir sıçramayı yener. Kabul edilen her değişiklik, uygulamayı çalışır bırakmalıdır.

---

✅ Ajanınızla deneyin

1. Bir mentor komutu için ("istenmeyen tavsiyeler dağıtır") kısıtlamalar dahil bir paragraflık spesifikasyon yazın ve ajana onu önce-test geliştirtin — plan, testler, kod, kapı — her adımda inceleyerek.
2. Ajandan yeni komuttan bahsetmek için docs/HANDOFF.md'yi güncellemesini isteyin.
3. Kasıtlı olarak bir şeyi bozun (örn. bir havuz girdisini silin), npm test çalıştırın ve ajana düzeltmesi için tam başarısızlığı besleme alıştırması yapın.

---

Sırada nereye

• src/lockedin.js'teki gerçek kodu tarayın — artık şeklini biliyorsunuz.
• Projenin kendi durumu ve mimari notları için docs/HANDOFF.md'yi okuyun.
• Komut Referansı'ndaki şakaların tadını çıkarın.

Eğitim bu kadar. Artık bir AI ajanını, hayal edilebilecek en aşırı kendinden emin örneği kullanarak, bir test kapısının arkasında gerçek yazılım geliştirmesi ve değiştirmesi için yönlendirebilirsiniz. Agree? 👇