24. Prompt Mühendisliğinin İlkeleri

24.1 Ne Değildir?

Prompt mühendisliği, sihirli kelimeler bulma sanatı değildir. İnternette dolaşan "şu cümleyi ekleyin, model on kat iyi çalışsın" türü tavsiyelerin çoğu, ölçülmemiş iddialardır.

Gerçek prompt mühendisliği, Bölüm 1'de anlatılan mekanizmanın nasıl çalıştığını bilerek talimat yazmaktır. Model bir sonraki tokeni bağlamdan tahmin ediyorsa, bağlamı düzenlemek doğrudan çıktıyı etkiler. Teknikler buradan türer, hafızadan değil.

24.2 Temel Benzetme

Anthropic'in kendi dokümantasyonunda kullandığı benzetme, kitabın geri kalanı için yararlı bir çerçevedir: Claude'u, sizin normlarınız, üslubunuz ve çalışma biçiminiz hakkında hiçbir bağlamı olmayan, parlak ama çok yeni bir çalışan gibi düşünün.

Benzetmenin önemli bir uzantısı vardır: bu çalışanın hafızası yoktur. Her görev, sıfırdan başlar. Dün açıkladığınız kuralı bugün bilmez.

Kaynak: Anthropic prompt mühendisliği dokümantasyonu ve "Prompting best practices" — https://claude.com/blog/best-practices-for-prompt-engineering. Doğrulama tarihi: 7 Eylül 2026.

Bu benzetme, Bölüm 7'deki projelerin ve Bölüm 9'daki hafızanın neden var olduğunu da açıklar: her ikisi de bu hafızasızlığı telafi etmek için tasarlanmıştır.

24.3 Beş İlke

Aşağıdaki beş ilke, kalan tüm tekniklerin dayanağıdır. Her birinin Kısım I'de bir mekanizma karşılığı vardır.

İlke 1 — Açık ve Doğrudan Ol

Resmî dokümantasyonun "tek başına en etkili teknik" dediği ilke budur. Ne istediğinizi belirsiz bırakırsanız, model boşluğu istatistiksel olarak en olası şeyle doldurur — sizin istediğinizle değil.

Pratik sınama: istemi, konuyu bilmeyen bir meslektaşınıza gösterin. O kafası karışıyorsa model de karışacaktır.

İlke 2 — Bağlam Ver

Mekanizma: Bölüm 2.5. Model, kendisine verilen metin üzerinde çalışırken uydurma riski belirgin biçimde düşer, çünkü bilgiyi üretmesi değil okuması gerekir.

Pratik sonuç: mümkün olduğunca modelden bilgi çekmek yerine ona bilgi verin. Bir makaleyi özetletmek, o makale hakkında soru sormaktan güvenlidir.

İlke 3 — Yapı Kur

Mekanizma: Bölüm 1.4. Dikkat mekanizması tokenler arası ilişkileri hesaplar; açık yapı bu ilişkileri güçlendirir ve modelin hangi metnin talimat, hangisinin veri olduğunu ayırt etmesini kolaylaştırır.

Resmî rehber, istemleri belirgin bölümlere ayırmayı ve bunları etiketlerle veya başlıklarla sınırlandırmayı önerir. Aynı kaynak, modeller güçlendikçe biçimin öneminin azaldığını da belirtir — yani yapı bir zorunluluk değil, bir kolaylaştırıcıdır.

İlke 4 — Kısıt Koy

Mekanizma: Bölüm 4.4. Kısıt koymak, ortaklık modelinin kurulduğu yerdir; sizin bilişsel katkınız burada devreye girer.

Modelin yapmamasını istediğiniz şey, yapmasını istediğiniz kadar önemlidir. Yasakları açıkça yazmak, ima etmekten daima daha güvenilirdir.

İlke 5 — Belirsizliğe İzin Ver

Mekanizma: Bölüm 2.3. Değerlendirme ölçütleri tahmin yürütmeyi ödüllendirdiği için model çekimser kalmayı öğrenmez. Resmî rehber de halüsinasyonu önleme yöntemi olarak "bilmiyorum deme izni" vermeyi listeler.

24.4 Başlamadan Önce: Üç Ön Koşul

Resmî rehber, prompt üzerinde çalışmaya başlamadan önce üç şeye sahip olmanızı önerir. Bunlar yoksa körlemesine iyileştirme yapıyorsunuz demektir.

• Başarı ölçütü. "İyi çıktı" ne demek? Ölçülebilir biçimde tanımlayın.
• Sınama yöntemi. Bir istemin öncekinden iyi olduğunu nasıl anlayacaksınız?
• Taslak istem. İyileştirilecek bir başlangıç noktası.

24.5 Prompt Mühendisliğinden Bağlam Mühendisliğine

Anthropic'in kendi mühendislik yazıları, bağlam mühendisliğini prompt mühendisliğinin doğal devamı olarak tanımlar. Ayrım şudur: prompt mühendisliği bir talimatı nasıl yazacağınızla, bağlam mühendisliği modelin görüş alanında ne bulunacağıyla ilgilenir.

Aynı kaynağın verdiği ilke önemlidir: hedef, beklenen davranışı tam olarak tanımlayan en küçük bilgi kümesidir. Daha fazla bağlam daima daha iyi değildir — Bölüm 1.7'deki dikkat seyrelmesi bunu açıklar.

24.6 İteratif Süreç

Prompt yazımı tek seferlik bir iş değildir. Resmî rehber süreci açıkça yinelemeli ve modelle işbirlikçi olarak tanımlar.

• Taslağı yaz ve çalıştır.
• Çıktıyı başarı ölçütüne göre değerlendir.
• Sapmanın nedenini teşhis et: talimat mı belirsiz, bağlam mı eksik, kısıt mı yok?
• Tek bir değişiklik yap. Aynı anda üç şeyi değiştirirsen hangisinin işe yaradığını bilemezsin.
• Birkaç kez çalıştır. Tek örnek karşılaştırma için yetmez.
• İşe yarayan sürümü sakla ve neyi neden değiştirdiğini not et.

Altıncı madde, bu kitabın Bölüm 7.3'te verdiği tavsiyeyle aynıdır: modelin tekrarlayan bir hatasını gördüğünüzde talimata bir kural ekleyin. İstem, kod gibi sürümlenmelidir.

24.7 Bu Kitaptan Çıkan İki Ek İlke

Kısım IV'teki testler, resmî rehberlerde öne çıkmayan iki ilke daha ortaya çıkardı.

Ek İlke A — Süreci İste, Yalnızca Sonucu Değil

Uzun bir işte modelden planını önce sunmasını istemek, hatalı bir yönelimi baştan yakalamayı sağlar. Bu, Bölüm 4.7'deki "ara adımları gör" ilkesinin istem düzeyindeki karşılığıdır ve Bölüm 13'teki plan modunun mantığıdır.

Ek İlke B — Kanıt İste

"Bunun çalıştığını bana kanıtla" biçimindeki bir talep, doğrulanmamış iddiaları azaltır. Kısım IV'ün tek cümlelik özeti burada uygulanır: başarı mesajı doğrulama değildir. Modelden test çıktısı, hesap doğrulaması veya sayısal kontrol istemek, istemin bir parçası olabilir.

24.8 Ne Zaman Prompt Yeterli Değildir?

Prompt mühendisliği güçlüdür ama her sorunun çözümü değildir. Aşağıdaki durumlarda başka araçlara geçilmelidir.

İlk satır özellikle önemlidir ve kitabın tekrarlayan ölçütüdür: aynı talimatı ikinci kez yazıyorsanız, o artık bir istem değil, bir yapılandırmadır.

24.9 Bölüm Özeti

• Prompt mühendisliği sihirli kelime bulma değil, mekanizmayı bilerek talimat yazmadır.
• Model, bağlamı olmayan ve hafızası bulunmayan yeni bir çalışan gibidir.
• Açık ve doğrudan olmak tek başına en etkili tekniktir.
• Modele bilgi vermek, modelden bilgi çekmekten güvenlidir.
• Yapı, dikkat mekanizmasının işini kolaylaştırır ama zorunlu değildir.
• Yasakları açıkça yazmak, ima etmekten güvenilirdir.
• Belirsizliğe izin vermek uydurma riskini azaltır.
• Başlamadan önce başarı ölçütü, sınama yöntemi ve taslak gereklidir.
• Hissedilen iyileşme ölçülen iyileşme değildir; birkaç kez çalıştırın.
• Bağlam mühendisliğinde hedef, en küçük yeterli bilgi kümesidir.
• Aynı talimatı ikinci kez yazıyorsanız, o bir yapılandırma olmalıdır.

Güncellik kontrolü: Bu bölümdeki ilkeler https://claude.com/blog/best-practices-for-prompt-engineering ve Anthropic'in bağlam mühendisliği yazısından 7 Eylül 2026 itibarıyla doğrulanmıştır. Kavramsal içerik yavaş eskiyen niteliktedir; modele özgü tavsiyeler değişebilir.