Prompt mühendisliği, bir modelden istediğim çıktıyı daha açık tarif etmek ve bu tarifi sonuçlarla sınamak için kullandığım bir yaklaşım. Özel kelimelerden oluşan gizli bir formül olarak görmüyorum. Web geliştirmede asıl faydası, “güzel olsun” gibi bir beklentiyi uygulamada kontrol edilebilir davranışlara dönüştürmesi. Burada bir iletişim formu üzerinden iki komutu karşılaştıracağım; örnek, anlatım için hazırlanmış bir görev taslağıdır, ölçülmüş bir başarı deneyi değildir.
Belirsiz komut neden değerlendirmesi zor bir sonuç üretir?
“Bana modern, şık ve profesyonel bir iletişim formu yap” dediğimde model tasarım yönünü, alanları, gönderim yöntemini ve hata davranışlarını kendisi seçmek zorunda kalır. Sonuç güzel görünebilir; fakat işletmenin gerçekten hangi bilgiyi beklediği hâlâ belirsizdir. Formun e-posta taslağı mı açacağı, sunucuya mı kayıt yapacağı yoksa yalnız demo mu olduğu da bu komuttan anlaşılmaz.
Bu örnekte sorun kısa yazmak değil. Bazı küçük işler tek cümleyle çok iyi tarif edilebilir. Sorun, sonucu değiştiren kararların açık bırakılması. “Profesyonel” sözcüğü, kullanıcının hatalı e-posta yazdığında ne göreceğini anlatmıyor. Ben komutu iyileştirirken süslü sıfat eklemek yerine, hangi belirsizliklerin geliştirici tarafından çözülmesi gerektiğine bakıyorum. Önce ürün kararlarını netleştirmek daha iyi bir başlangıç oluyor.
Aynı isteği davranış üzerinden yeniden yazmak
İkinci komutta mevcut durumu, işin sınırını ve başarı koşullarını belirtiyorum. Örnekte formun yalnız e-posta taslağı açması özellikle yazılı. Böylece sunucu entegrasyonu olmadığı halde “mesaj gönderildi” ekranı üretilmesi beklenen davranış haline gelmiyor. Alanların görünen etiketlerini ve hata durumunu da aynı görev içinde ele alıyorum.
Buradaki komut biçimi tek doğru şablon değil. Önemli olan, her talimatın hangi kararı netleştirdiğini açıklayabilmek. İlgisiz teknik ayrıntıları eklemek zorunda değilim. Öte yandan mevcut projede ortak buton ve alan bileşenleri varsa onların kullanılacağını söylemek, birbirinden kopuk bir tasarımın önüne geçebilir. Girdi olarak yalnız ihtiyaç duyulan kaynakları eklemek de okunabilirliği koruyor.
İlk istek:
Modern ve profesyonel bir iletişim formu yap.
Geliştirilmiş görev:
Mevcut React sayfasına bir proje iletişim formu ekle.
Amaç: Ziyaretçi kendi e-posta uygulamasında taslak açabilsin.
Alanlar: Ad, e-posta, proje açıklaması.
Gönderim: Sunucuya kayıt yok; e-posta taslağı açılacak.
Tasarım: Mevcut sayfanın butonlarını ve renklerini kullan.
Kabul ölçütleri:
- Her alanın görünen, ilişkili etiketi olsun.
- Eksik veya geçersiz bilgiyle taslak açılmasın.
- Geçerli girişte konu ve mesaj doğru kodlansın.
- Kontrol, mesajın gönderildiğini iddia etmesin.
- Klavye ile bütün alanlara ve butona ulaşılabilsin.
- 390 px genişlikte uzun içerik yatay taşma üretmesin.
Teslimde yapılan değişikliği ve kontrol sınırını açıkla.Örnekler, talimatın nasıl yorumlanacağını gösterir
Bir görev için küçük bir örnek giriş ve beklenen davranış hazırlamak, soyut kuralı görünür hale getirir. İsim alanına “Ayşe & Ortakları” yazıldığında ampersand işareti e-posta gövdesini bozmamalı. Mesajdaki Türkçe karakterler korunmalı. Çok uzun bir sözcük de sayfanın dar ekranda genişlemesine yol açmamalı. Bu örnekler, metnin biçimiyle uygulamanın davranışını birlikte düşündürüyor.
Beklenen çıktıyı yalnız mutlu akışla tanımlamıyorum. E-posta alanı boşsa, yanlış biçimdeyse veya tarayıcıda uygun e-posta uygulaması yoksa kullanıcı ne anlayacak? Bütün durumları aynı yöntemle çözmek gerekmez; ama belirsiz bırakılanların farkında olmak gerekir. Test örneği eklemek, modelin mutlaka doğru davranacağını garanti etmez. Sonucu hangi gözle inceleyeceğimi belirler.
Bağlam ile talimatı karıştırmamak
AI’ya verdiğim kaynak içeriği, görev talimatıyla aynı şey değil. Örneğin bir ürün açıklaması neyi göstereceğimi belirleyen veri olabilir; açıklamanın içinde geçen rastgele bir cümle uygulamanın yetkisini değiştirmemeli. Bu ayrımı özellikle dışarıdan gelen belge, mesaj ve müşteri içeriğinde önemsiyorum. Girdi alanlarını açık isimlerle ayırmak, neyin veri neyin karar olduğunu daha anlaşılır hale getiriyor.
Ayrıca bilginin doğruluk durumunu koruyorum. “Bu fiyat örnektir” diye verilen veri, üretilen ekranda güncel satış fiyatına dönüşmemeli. Bir teknik çizim yoksa modelden makul bir ölçü tamamlamasını istemiyorum. Prompt tasarlarken eksik bilgi durumunu da tarif etmek, yanlış kesinlik üretmekten daha faydalı. Bu yaklaşım özellikle ürün sayfalarında ve satış asistanlarında sonuçları etkiliyor.
Prompt’u sonuçla birlikte geliştirmek
İlk çıktıda bir sorun gördüğümde bütün komutu baştan değiştirmek yerine sorunu ayırıyorum. Form etiketleri doğru, fakat e-posta konusu hatalıysa konu kodlamasını ele alıyorum. Tasarım tutarlı, fakat mobilde taşma varsa genişlik ve uzun içerik davranışına bakıyorum. Her turda yeni bir beklenti eklemek yerine, mevcut kabul ölçütünün neden karşılanmadığını açıklamak daha izlenebilir bir ilerleme sağlıyor.
OpenAI’nin resmi prompting rehberi de talimat, örnek, bağlam ve değerlendirme arasında ilişki kuruyor. Buradan aldığım pratik sonuç, kullandığım komutu yapılan işle birlikte saklamak. Özellikle uygulama içinde tekrar kullanılan bir prompt değişiyorsa temsilî örneklerle yeniden kontrol edilmeli. Bir konuşmada iyi görünen cevap, farklı girişlerde aynı kaliteyi göstereceğinin kanıtı değil.
Prompt’un çözemediği parçayı doğru yerde çözmek
Talimat metni arayüzde gerçek bir label oluşturmaz; kodun bunu uygulaması gerekir. Bir prompt da veritabanı yetkisini, API doğrulamasını veya gönderim onayını tek başına sağlayamaz. Gerekli kural uygulama katmanında açık biçimde yer almalı. Bu yüzden geliştirme komutlarında hem beklenen davranışı hem kontrol edeceğim gerçek yüzeyi tarif etmeye çalışıyorum.
Sonuçta prompt mühendisliğini, istek yazma ve çıktı okuma arasında gidip gelen bir tasarım işi olarak kullanıyorum. Bu örnekte hedef daha etkileyici bir cevap almak değil, formun ne yaptığını doğru anlatması ve beklenen davranışları karşılaması. Kendi çalışmamı değerlendirebildiğim, hatayı yerelleştirebildiğim ve sonraki düzenlemeyi açıklayabildiğim bir talimat, benim için işe yarayan talimat.