Tester geri bildirimi, uygulamayı değiştirdiğinde ancak işe yarar. Ağırlıklı olarak prompt yazarak geliştiriyorsan, bir tester notundan düzeltmeye giden en kısa yol iyi bir prompt'tan geçer. Belirsiz bir prompt belirsiz bir değişiklik getirir; doğrulamadığın bir değişiklik de başka bir şeyi bozabilir. Bu sayfa, her geri bildirim turunda tekrarlayabileceğin bir döngü veriyor.
Döngü
- Topla
- Önceliklendir
- Prompt'u yaz
- Değişikliği uygula ve oku
- Gerçek cihazda doğrula
- Tester'a haber ver
1. Yapılandırılmış geri bildirim topla
Serbest biçimdeki "bozuk" demek, harekete geçmesi zor bir şeydir. Tester'lardan her seferinde aynı birkaç alanı iste: ne yaptıklarını, ne beklediklerini, ne olduğunu, cihaz ve işletim sistemi sürümünü. Bu biçimdeki bir rapor neredeyse hiç değiştirilmeden bir prompt'a yapıştırılabilir. Bkz. geliştiricinin işine yarayan geri bildirim nasıl yazılır ve hata raporu şablonu.
2. Prompt'tan önce önceliklendir
Asistana aynı anda on rapor gönderme. Etki ve çabaya göre sırala (rehber): çökmeler ve engellenen ana akışlar önce, cilalama en son. Her prompt'ta tek bir sorun üzerinde çalış. Küçük değişiklikler kontrol etmek ve geri almak için daha kolaydır.
3. Kesin bir prompt yaz
İyi bir prompt dört şey taşır: - Bağlam: hangi ekran ya da özellik, bir iki cümleyle. - Rapor: adımlar, beklenen sonuç, gerçekleşen sonuç, cihaz ve işletim sistemi. - Sınır: "yalnızca gerekeni değiştir; ilgisiz kodu yeniden düzenleme". - Kontrol: bunun çalıştığını nasıl anlayacağın; bir de aynı kalması gereken yakın bir davranış.
Kopyala-yapıştır sürümü: tester raporundan düzeltme prompt şablonu.
Sorunu kendin yeniden üretemiyorsan prompt'ta bunu söyle ve asistandan kod değiştirmeden önce tahminini açıklamasını iste. "Bu rapordaki her şeyi düzelt" demeyi deneme.
4. Değişikliği oku
Her satırı anlamak zorunda değilsin, ama neyin değiştiğine bak: hangi dosyalar, kaç satır. Tek satırlık bir hata on dosyada değişiklik ürettiyse ikinci bir bakışı hak eder. Her düzeltmeyi kendi commit'inde ya da kayıt noktasında tut ki geri dönebilesin.
5. Gerçek cihazda doğrula
Raporun tam adımlarını gerçek bir telefonda çalıştır, mümkünse tester'ın kullandığı türden bir cihazda. Sonra "aynı kalmalı" diye adlandırdığın yakın davranışı çalıştır. Emülatör ilk geçiştir; gerçek telefon kanıttır. Bkz. neden emülatör yetmez.
6. Döngüyü kapat
Tester'a neyi değiştirdiğini söyle ve tekrar kontrol etmesini iste. Notlarının kullanıldığını görenler bir dahaki sefere daha iyi notlar gönderir. Bunun için bir oran iddia etmiyoruz; geri bildirimin tek seferlik bir şey olmaktan çıkıp bir alışkanlığa dönüşmesi budur.
Düzeltme tutmadığında
- Asistan "düzeltti" ama adımlar hâlâ başarısız oluyor: aynı raporu, değişiklikten sonra gözlemlediklerinle birlikte yeniden gönder.
- Düzeltme başka bir şeyi bozdu: geri al ve bozulan davranışı "aynı kalmalı" satırına ekle.
- İki deneme, ilerleme yok: sorunu kendi cümlelerinle, daha küçük ve daha az bağlamla anlat.
Kısa bir günlük tut
Rapor başına bir satır: tarih, sorun, cihaz, kullanılan prompt, sonuç. Birkaç turdan sonra hangi tür raporların temiz düzeltmeler ürettiğini göreceksin.
AppReviewX nerede yer alır
AppReviewX, bu döngüye uyan bir biçimde diğer geliştiricilerden özel, yapılandırılmış geri bildirim verir. Yazdığın bir geri bildirim 1 kredi kazandırır, krediler kendi uygulamana geri bildirim satın alır ve yeni hesaplar 0 krediyle başlar.
İlgili: Vibe coding merkezi, ilk dürüst mağaza yorumlarını almak, yaygın mağaza red nedenleri, gerçek cihaz testi.
Ücretsiz başla ve döngüyü çalıştırmaya başla.