1. İyi istem, iyi bir iş tarifidir
Bir kod asistanına verilen görevde eksik bilgi, bazen yanlış teknoloji seçimine bazen de doğru dosyanın gereksiz yere yeniden yazılmasına yol açar. “Düzelt” demek yerine bozuk davranışı ve beklenen sonucu anlatmak daha belirgin bir başlangıçtır. Hatanın oluştuğu adımları ver; mümkünse küçük bir örnek ekle.
Örneğin “mobil menü bozuk” yerine “390 piksel genişlikte menü düğmesine basıldığında bağlantılar görünmüyor; klavyeyle açılıp kapatılmalı ve Escape ile kapanmalı” yaz. Böylece asistan yalnızca görünüşü değil, etkileşimi de değerlendirebilir. Ayrıntı, gereksiz uzunluk anlamına gelmez; kararı değiştiren bilgileri seçmek anlamına gelir.
2. Dört parçalı bir görev şablonu
Amaç bölümüne kullanıcının tamamlayacağı işlemi yaz. Bağlam bölümüne ilgili dosyaları ve mevcut davranışı koy. Sınır bölümünde korunacak URL, veri veya bileşeni belirt. Doğrulama bölümünde sonucun hangi gözlemle kabul edileceğini açıkla.
Aşağıdaki şablon bir arayüz değişikliğine uyarlanmıştır. Asistandan uygulamadan önce kısa bulgu sunmasını istemek, yanlış dosya veya yanlış varsayımı erken fark etmeyi sağlar. Her görevde uzun bir plan istemek gerekmez; küçük değişikliklerde tarif ve görünür kontrol yeterli olabilir.
Amaç: Mobil menü okunabilir ve klavyeyle kullanılabilir olsun.
Bağlam: Header bileşeni ve navigation.css; mevcut URL'ler korunacak.
Hata: 390 px ekranda bağlantılar görünmüyor.
Sınır: Masaüstü sıralamasını ve giriş akışını değiştirme.
Kabul: Aç/kapat, Escape, görünür odak, yatay taşma yok.
İşleyiş: Önce nedeni belirt; ardından dar düzeltmeyi yap ve göster.3. Araştırma isteğini somutlaştır
Güncel bir API veya paket sürümü soruyorsan resmî belgeyi kontrol etmesini iste. Modelin bir yöntemi hatırlaması, kullandığın sürümde hâlâ geçerli olduğunu kanıtlamaz. İstemine mevcut sürümü ve aldığın hata mesajını eklemek, araştırmayı daraltır.
“En iyi kütüphaneyi seç” isteğinde ise karar ölçütü eksiktir. Tarayıcı desteği, lisans, ekip alışkanlığı, paket boyutu ve bakım maliyeti farklı sonuçlar üretebilir. Asistandan seçenekleri bu ölçütlere göre karşılaştırmasını iste; uydurulmuş benchmark veya doğrulanmamış fiyat isteme.
4. Sırları ve üçüncü taraf metinlerini sınırla
Bir hata kaydı veya web sayfası, görev verisi olabilir; ancak içindeki yönergelerin uygulanması gereken talimat olduğu varsayılmamalıdır. Asistana logu yalnızca tanı için kullanmasını söylemek, metnin başka bir işlem çağrısına dönüşmesini azaltır. Özellikle araç kullanan asistanlarda kaynak ile yetkiyi ayrı tut.
Gerçek anahtar ve kişisel veri yerine anonimleştirilmiş örnek kullan. Görev için bir bağlantı gerekiyorsa herkese açık dokümanı ver; token içeren URL'yi sohbet metnine taşıma. Hata bağlamını korurken hassas parçaları çıkarmak, daha az bilgi vermek değil daha uygun bilgi vermektir.
5. Çıktıyı kabul etmeden önce iki soru
İlk soru: sonuç istediğim davranışı gerçekten sağlıyor mu? İkinci soru: bu davranışı sağlarken başka bir kuralı bozuyor mu? Bir düzeltme başarılı görünürken veri kaybı, erişim genişlemesi veya mobil taşma yaratabilir. İstemin kabul ölçütleri bu iki soruyu görünür hale getirmelidir.
Bu şablonun amacı tek seferde kusursuz cevap garantisi vermek değildir. Belirsizliği azaltmak ve sonraki incelemeyi kolaylaştırmaktır. Çıktı hatalıysa yeni bir genel istek yerine başarısız ölçütü, gözlenen sonucu ve ilgili farkı geri ver; bir sonraki düzeltme daha dar olsun.
Kaynaklar ve kontrol notu
Bu rehber yapay zekâ desteğiyle hazırlanmış özgün bir editoryal içeriktir. Kaynak kontrolü: 30 Eylül 2026. Örnekleri kendi proje koşullarına uyarlayarak doğrula.
Bir hata fark ettiysen editörlüğe bildir; düzeltmeleri güncelleme tarihiyle işleriz.
