Claude'a İyi İş Yaptırmak: Instructions for Claude, Görev Tarifi ve Doğrulama Alışkanlıkları

Sürüm notu: Bu yazı Claude uygulamalarındaki kişiselleştirme ayarlarını ve görev tarifini 15 Kasım 2026 itibarıyla anlatır; menü yolları ve özellikler aynı gün Claude Help Center'dan (support.claude.com) kontrol edilmiştir. Bu yazıda resmî belgelerden yararlanılmıştır. Yazıdaki prompt'lar örnek olarak verilmiştir; Claude'un cevabı model, ayar ve hesaba göre değişir.

Önce Tahmin Et

Bookstore'un Product Owner'ı Selin, sitedeki serilerin ortak örnek uygulaması Bookstore (bir online kitapçı) için Kasım kampanyasının e-postasını hazırlıyor. Claude'a tek cümle yazıyor: "Bir kampanya maili yaz." Gelen metin düzgün ama kullanılamıyor: hangi kitaplar, hangi indirim, kime gidecek, ne kadar uzun olacak, hiçbiri Selin'in kafasındakiyle örtüşmüyor. Üstelik Selin'in Settings'te yıllar önce yazdığı iki talimat var: "Her zaman kısa yaz" ve "Konuyu her zaman ayrıntılı açıkla."

Tahminin ne? Sorun modelde mi, Selin'in tek cümlesinde mi, yoksa birbiriyle çelişen o iki talimatta mı? Ve aynı e-postayı tek seferde kullanılabilir hâle getirmek için tarife en az hangi bilgiler eklenmeli? Bu yazının sonunda iyi bir tarifin beş parçası ve Claude'un cevabını kullanmadan önce sorulacak üç soru olacak.

Claude'u Kişiselleştirmenin Katmanları

Claude'a "beni tanı" demenin birkaç yolu var ve hangisine ne yazacağın, her konuşmada aynı şeyi tekrar edip etmeyeceğini belirliyor. Help Center'ın "Understanding Claude's personalization features" makalesi (https://support.claude.com/en/articles/10185728, 15 Kasım 2026) üç katman tarif ediyor; dördüncüsü, Claude'un kendisinin tuttuğu memory:

Birleşik deneyime geçen hesaplarda eski Cowork'ün "Global instructions" alanı da Instructions for Claude'un içine taşındı; Help Center, geçişten sonra bu alanın hâlâ istediğin şeyi söyleyip söylemediğini kontrol etmeni öneriyor. Eskiden ton ve biçim için "styles" özelliği kullanılıyordu; güncel kişiselleştirme makalesi styles'tan söz etmiyor ve ton, format ve tekrar eden davranışlar için skill'leri gösteriyor. Skill'leri dokuzuncu yazıda, project'leri dördüncü yazıda, memory'yi beşinci yazıda ayrıntılı göreceğiz. Bu yazıda ağırlık ilk katmanda ve tek tek konuşmalardaki görev tarifinde.

Instructions for Claude'a Ne Yazılır

Bu alana yazdığın her şey her konuşmaya ekleniyor. Bu yüzden buraya yalnız her konuşmada doğru olan şeyler girmeli. Bookstore'da çalışan bir backend developer için makul bir başlangıç:

About me: backend developer on Bookstore (.NET 10, ASP.NET Core, SQL Server, Angular).
Language: answer in Turkish; keep code, identifiers and technical terms in English.
Code: C# 14, file-scoped namespaces, async/await everywhere, no .Result or .Wait().
When a request is ambiguous, ask one question before you start.
Say clearly when you are not sure, and label assumptions as assumptions.
Keep answers short unless I ask for detail.

Talimatları Türkçe de yazabilirsin; models overview sayfası güncel modellerin hepsinin çok dilli çalıştığını söylüyor. Önemli olan içerik. Bu altı satırın her biri bir kararı sabitliyor: kim olduğun ve hangi teknolojilerle çalıştığın, cevabın dili ve terimlerin nasıl yazılacağı, kod tercihlerin, belirsizlikte ne yapılacağı ve cevabın varsayılan uzunluğu. Dikkat edersen hiçbirinde belirli bir işe dair bilgi yok. "Bu sprintte iade akışı üzerinde çalışıyoruz" gibi bir cümle burada değil, ilgili project'in instructions'ında ya da o günkü konuşmada durmalı; aksi hâlde iki ay sonra alakasız bir soruda bile Claude iade akışını hatırlamaya çalışır.

Önce Tahmin Et'teki çelişkiye dönelim. "Her zaman kısa yaz" ile "her zaman ayrıntılı açıkla" aynı anda doğru olamaz; Claude ikisini birden yerine getirmeye çalıştığında sonuç ne kısa ne ayrıntılı olur. Bu tür kuralları koşulla birlikte yaz: "Varsayılan olarak kısa yaz; ben 'ayrıntılı' dersem adım adım açıkla." Talimat listesini ayda bir okuyup artık geçerli olmayan satırları silmek de iyi bir alışkanlık.

İyi Görev Tarifinin Parçaları

Prompt yazmanın sağlayıcıdan bağımsız temeli LLM Temelleri serisinin "LLM için Prompt Yazmak (1): Açık Talimat, Ayraçlar ve Few-shot" ve "LLM için Prompt Yazmak (2): Adım Adım Düşündürmek ve Reasoning Modelleri" yazılarında anlatıldı; burada onları tekrar etmeyeceğiz. Günlük işte bir görevi Claude'a verirken şu beş parça çoğu zaman yeterli:

• Hedef: bu iş bitince ne elde etmiş olacaksın, çıktı kime gidecek, neye karar verilecek?
• Bağlam: Claude'un bilmediği ve işin doğru yapılması için gereken bilgi; ilgili dosyayı ya da veriyi aynı mesaja ekle.
• Kısıtlar: uzunluk, ton, değiştirilmemesi gereken kurallar, kullanılmaması gereken kaynaklar.
• Çıktı formatı: tablo mu, e-posta mı, Excel dosyası mı; başlıklar, bölümler, dil.
• Belirsizlik kuralı: eksik bilgi varsa tahmin etmek yerine sormasını ya da varsayımını işaretlemesini iste.

Help Center'ın usage limit sayfası da aynı yönde öneriler veriyor: ilgili soruları tek mesajda birleştir, net ve kısa yaz, gereken bağlamı ekle; yazı işi için metnin tamamını, araştırma için soruyu ve bütün veriyi düzenli tek bir mesajda gönder. İyi tarif yalnız daha iyi cevap değil, daha az tur ve daha az kullanım demek.

Uzun işlerde bir adım daha işe yarıyor: önce plan istemek. "Önce adımları listele, onaylarsam başla" demek, yanlış anlaşılmış bir görevin yarım saat sonra fark edilmesini önlüyor. Claude Docs'un da yazmaya başlamadan önce netleştirici sorular sorduğunu Help Center belirtiyor; aynı davranışı tarifinle her işte isteyebilirsin. Taslak geldikten sonra da baştan yazdırmak zorunda değilsin: Haziran 2026'dan beri taslağın bir kısmını seçip değişikliği doğrudan yazarak yerinde düzenletebiliyorsun.

Claude'a Özgü Noktalar: Tool'ları Kendisi Seçer

Birleşik Claude deneyiminde birçok karar artık senin değil Claude'un. Web search için bir anahtar yok; Claude gerektiğinde arıyor. Dosya üretmek ya da kod çalıştırmak gerekiyorsa bunu da kendisi başlatıyor; bir skill işe yarayacaksa onu açıklamasına bakarak kendisi yüklüyor. Bu rahat bir çalışma biçimi ama tarifte bazı şeyleri açıkça söylemeyi gerektiriyor:

Kaynağı sınırlamak istiyorsan yaz. "Yalnız eklediğim dosyaları kullan, web'de arama" ya da tersi, "yalnız resmî dokümantasyon sitelerini kaynak al" gibi bir cümle, cevabın neye dayandığını belirliyor. Kapsamlı ve kaynaklı bir araştırma istiyorsan /deep-research ile ya da "+" menüsünden "Research" ile başlat; bunu yedinci yazıda göreceğiz.

Ne zaman durup soracağını söyle. Mesaj kutusundaki izin ayarı "Auto" iken Claude birçok adımı onay beklemeden yapıyor; Enterprise'da varsayılan "Manual". Dosya silmek, bir connector üzerinden dışarıya yazmak gibi geri alınması zor adımlar için tarifine "bu adımdan önce bana sor" eklemek, ayar ne olursa olsun işe yarıyor. Agentic görevlerin yetki ayarlarını onuncu yazıda ele alacağız.

Dosyayı ya da veriyi mesajla birlikte ver. "Geçen hafta konuştuğumuz rapor" demek yerine dosyayı eklemek ya da project'e koymak, Claude'un yanlış dosyayı hatırlamasını önler. Chat search ve memory önceki konuşmaları bulabiliyor ama bu, doğru bağlamı açıkça vermenin yerini tutmuyor.

Bookstore: Kampanya E-postası, Kötü ve İyi Tarif

Selin'in ilk denemesi:

Write a campaign e-mail.

Bu tarifle Claude'un elinde hedef, kitle, teklif, uzunluk ya da ton yok; boşlukların hepsini kendi tahminleriyle dolduruyor. Böyle bir tarifle Selin'in istediği metne ancak düzeltme mesajlarıyla yaklaşılabilir ve ardından gelen beş düzeltme mesajı, baştan iyi yazılmış tek bir tariften daha fazla kullanım harcar. İkinci deneme:

Goal: an e-mail for Bookstore's November campaign. It should bring back
customers who bought science fiction in the last 6 months.

Audience: only customers who gave consent for marketing e-mails.
Offer: 15% off the Dune series until 30 November, code DUNE15.
Tone: friendly, not pushy. Plain Turkish, no slang.
Length: subject line, preview text and a body of at most 120 words.
Must include: a one-line unsubscribe sentence at the end.
Must not include: any customer data except a {FirstName} placeholder.

Output: two versions, A and B, that differ in one thing only
(the subject line and the first sentence). After them, a table
that shows what differs and which customer reaction each version tests.

If anything needed for the e-mail is missing, ask before you write.

Beş parçanın hepsi burada: hedef ilk satırda, bağlam kitlede ve teklifte, kısıtlar ton, uzunluk ve zorunlu satırlarda, çıktı formatı iki versiyon ve tabloda, belirsizlik kuralı son satırda. İki kısıt ayrıca dikkat istiyor. "Yalnız pazarlama e-postasına onay vermiş müşteriler" cümlesi KVKK (Kişisel Verilerin Korunması Kanunu) ve ticari ileti onayı açısından ekibin kuralını tarife taşıyor; Claude e-postayı göndermiyor; bu satır metnin bu kitleye göre yazılmasını sağlıyor, kuralı uygulamak gönderimi yapan ekibin işi. {FirstName} yer tutucusu da gerçek müşteri verisinin prompt'a hiç girmemesini sağlıyor.

Bu tarife beklenen cevap; iki konu satırı ve önizleme metni, 120 kelimeyi geçmeyen iki gövde, sonunda abonelikten çıkma satırı ve farkları gösteren kısa bir tablo. Eksik bir bilgi fark ederse (örneğin kampanyanın e-kitapları kapsayıp kapsamadığı) yazmadan önce soru sormalı. Gelen cevabı tarifin her satırıyla tek tek karşılaştırmak birkaç dakika sürer ve bir hatayı müşteriye gitmeden yakalar.

Doğrulama Alışkanlıkları

Claude'un cevabı ne kadar akıcı olursa olsun, kullanmadan önce kontrol edilmesi gereken bir taslak. LLM Temelleri serisinin "LLM Halüsinasyonu ve Güvenilirlik: Kaynak Göster, Doğrula, Ölç" yazısı, modellerin neden kendinden emin biçimde yanlış bilgi üretebildiğini anlattı. Günlük kullanımda bunun karşılığı üç alışkanlık: varsayımları görünür kılmak, sayıları ve tarihleri kaynağına kadar izlemek, emin olunmayan yerleri işaretletmek. Bir taslağı kullanmadan önce aynı konuşmada şunu sormak bunların üçünü de karşılıyor:

Before I use this draft:
1. List every assumption you made that is not in my brief.
2. List every number, date and name in the text and where it came from:
   my brief, an attached file, a web source (with the link) or your own knowledge.
3. Mark anything you are not sure about.

Bu soruların cevabı da bir model çıktısı; ama "kendi bilgim" diye işaretlenen bir rakam, kontrol etmen gereken yeri doğrudan gösteriyor. Kampanya e-postasında bu, "yüzde 15" ve "30 Kasım"ın tarifinden geldiğini, başka bir rakamın metne girmediğini görmek demek. Web'den gelen bilgide kaynağın linkini açıp gerçekten o bilgiyi söyleyip söylemediğine bakmak gerekiyor; yedinci yazıda bunu kaynaklı araştırma üzerinden ayrıntılı göreceğiz. Effort'u yüksek modellerde cevabın üstündeki "Thinking" özeti de Claude'un hangi yoldan gittiğini görmek için faydalı, ama doğrulamanın yerini tutmaz.

Üretimde Dikkat

Ekipçe kullanırken ortak kuralları tek tek kişisel talimatlara yazdırmak yerine project instructions'a koy. Instructions for Claude kişisel; aynı ekipte beş kişinin beş farklı "terimler İngilizce kalsın" cümlesi zamanla birbirinden ayrışır. Project instructions'ı ise project'i düzenleme yetkisi olan herkes güncelleyebiliyor.

Talimatlara gizli bilgi yazma. API anahtarı, şifre, müşteri adı ya da iç sistem adresi her konuşmaya eklenen bir alana girmemeli. Gizlilik ayarlarını ve neyin nereye gittiğini serinin son yazısında konuşacağız.

Talimatın her şeyi çözmesini bekleme. Çok uzun bir talimat listesi, her konuşmanın başına aynı içeriği eklediği için kullanımı da artırır. Bir kural yalnız belirli işlerde gerekiyorsa onun yeri project ya da skill.

Sık Düşülen Tuzaklar

Birbiriyle çelişen kurallar yazmak. "Kısa yaz" ile "ayrıntılı açıkla" gibi kurallar koşulsuz yan yana durunca Claude ikisini de yarım uygular. Kuralı koşuluyla yaz.

Her konuşmaya aynı uzun bağlamı yapıştırmak. Tekrar eden bağlamın yeri project; orada hem tek yerden yönetilir hem de cache'lendiği için daha az kullanım sayılır.

"Bir şey yaz" tarzı tek cümleli istekler. Claude boşlukları tahminle doldurur; sonra gelen düzeltme turları baştan iyi yazılmış tariften daha pahalıya gelir.

Geçici bilgiyi kalıcı talimata yazmak. Bu sprintin işi, bu ayın kampanyası, bir müşterinin adı gibi bilgiler aylarca bütün konuşmalara taşınır.

Akıcı cevabı doğru cevap sanmak. Rakam, tarih, isim ve link içeren her cevabı kullanmadan önce varsayımlarını ve kaynaklarını sor.

Küçük Bir Deneme

★☆☆ Settings > Your Claude altındaki Instructions alanını aç. Her satır için "bu her konuşmada doğru mu?" diye sor; olmayanları sil ya da ilgili project'e taşı. Çelişen iki kural bulursan koşulla yeniden yaz.

★★☆ Bu hafta Claude'a verdiğin üç görevi seç ve her birini beş parçaya (hedef, bağlam, kısıtlar, çıktı formatı, belirsizlik kuralı) göre yeniden yaz. Aynı işi iki tarifle ayrı konuşmalarda çalıştır ve kabul edilebilir sonuca kaç turda geldiğini say.

★★★ Ekibin için ortak bir project instructions metni yaz: dil ve terim kuralı, kod tercihleri, gizli veri yasağı, belirsizlikte sorma kuralı. Üç ekip arkadaşına aynı görevi bu project içinde ve dışında yaptır, cevapları karşılaştırıp metni düzelt.

İyi tarif ve doğru talimat, Claude'un her konuşmada sıfırdan başlamasını engelliyor ama tekrar eden dokümanlar için yeterli değil. Dördüncü yazıda Claude Projects'i, project knowledge'ı, project instructions'ı ve knowledge context window'u aşınca devreye giren RAG'i (retrieval-augmented generation; soruya göre dokümanlardan ilgili parçaları bulup modele veren yöntem) Bookstore'un teknik dokümantasyon project'i üzerinden göreceğiz.