Tek seferlik ayarı kalıcı tercihten ayır

Kullanıcı bir müşteriye gidecek e-postayı yazdırıyor ve asistana “bunu resmî yaz” diyor. Taslak iyi çıkıyor. Ertesi gün ekibine bir toplantı notu istiyor ve not “Sayın ekip üyeleri” diye başlıyor. Asistan dünkü cümleyi bir tercih olarak kaydetmiş, artık her metne uyguluyor. Kullanıcı bunu ancak yanlış tonda bir metin aldığında fark ediyor.

Ters yönü de aynı sıklıkta yaşanıyor. Başka bir kullanıcı her sohbete aynı cümleyle başlıyor: “Kısa yaz, madde kullanma, Türkçe cevap ver.” Bunu bir kez söyleyip kalıcı yapmanın yolunu bilmiyor ya da bulduğu yol tercihi yanlış yere yazıyor. Aylar içinde aynı üç cümleyi yüzlerce kez yazıyor.

İki sorunun kökü aynı. Kullanıcı bir tercih söylediğinde asistanın önünde dört ayrı kapsam var: bu mesaj, bu sohbet, bu proje, her zaman. Arayüz bu kapsamları ayırmıyorsa kararı model veriyor. Kullanıcı kararın sonucunu sonradan, başka bir işin ortasında görüyor. Yanlış kapsam başkasını da etkileyebilir. Claude Code'da proje talimatları ekip üyelerine kaynak denetimi üzerinden gidiyor¹. Kişisel bir alışkanlık proje dosyasına yazılırsa bütün ekibin ajanı onu uygular.

Bir tercihin ne kadar süre geçerli olacağına kullanıcı karar vermeli.

Kalıcı bellek ürün ekiplerinin vitrin özelliği ve vitrinde kaydetmek unutmaktan iyi görünür. Asistan bir şeyi hatırladığında kullanıcı şaşırır, ekip bunu demoya koyar. Tek seferlik bir isteği kaydetmemek hiçbir demoda görünmez. Kayıt bu yüzden varsayılan olur, kapsam sorusu sonraya kalır.

Kaydetme kararı da çoğu zaman modelin elinde. Anthropic'in belgesine göre Claude belleği kendi kendine kaydediyor², kullanıcı ayrıca “remember this” diyerek kayıt yazdırabiliyor. Claude Code'un otomatik belleği neyin hatırlanmaya değer olduğuna bilginin sonraki bir konuşmada işe yarayıp yaramayacağına bakarak¹ karar veriyor. “Bu e-postayı resmî yaz” cümlesindeki “bu” kelimesi tek seferlik bir sınır çiziyor, ama işe yarayabilecek her bilgiyi kaydetmeye ayarlanmış bir sistem o sınırı kolayca atlar ve kapsamı geniş seçer.

Üçüncü neden ölçümde. Aynı tercihi her sohbette yeniden yazan kullanıcı şikâyet etmez, yalnız yorulur. Yanlış kalıcı tercih ise panoya “kötü cevap” olarak düşer ve kökü belleğe bağlanmaz. İki kayıp da kapsam diye bir sütunu olmayan bir tabloda görünmez.

Her tercihin bir kapsamı var. Asistan kapsamı kullanıcının cümlesinden okur, emin olmadığında dar tutar ve genişletmeyi kullanıcıya tek tıkla bırakır.

1. Kapsamı cümleden oku. “Bu e-postayı”, “şimdilik”, “bu sefer” tek seferlik bir istek. “Bundan sonra”, “hep”, “her zaman” kalıcı bir tercih. Ürün iki türü aynı kayda yazmaz ve ikisini aynı biçimde onaylamaz.
2. Emin değilsen dar tut. Kapsamı belirsiz bir istek o işte uygulanır ve kaydedilmez. Dar kapsamın bedeli kullanıcının bir cümleyi yeniden söylemesi. Geniş kapsamın bedeli sonraki her çıktının yanlış gelmesi.
3. Genişletmeyi tek tıka bırak. Tek seferlik uygulanan tercihin yanında “bu projede hep” ve “her zaman” seçenekleri durur. Kullanıcı aynı tercihi ikinci kez söylediğinde asistan kaydetmeyi kendisi önerir.
4. Kaydı söyle ve yerini göster. Kalıcı bir tercih yazıldığında asistan neyi, hangi kapsama yazdığını aynı mesajda söyler ve kayda giden yolu verir: hesap ayarı, proje talimatı ya da bellek.
5. Katmanlar çakışınca sırayı belirle. Hesap tercihi, proje talimatı ve bu sohbetteki istek çeliştiğinde daha dar olan geçerli olur. Ürün bu sırayı yazar ve her seferinde aynı biçimde uygular.

Kalıcı kaydı kullanıcı seçer. Asistan yalnız önerir ve seçimin nereye yazıldığını gösterir.

Aynı resmî e-posta isteği, iki ayrı asistanla. Soldaki isteği bütün sohbetler için bir tercihe çeviriyor ve ertesi günkü ekip notu yanlış tonda geliyor. Sağdaki resmî tonu yalnız o e-postada kullanıyor, kaydetmediğini söylüyor ve kalıcı yapmayı iki düğmeye bırakıyor.

Anthropic, Claude'da kapsamı ayrı ayarlara bölüyor. Hesap düzeyindeki talimatlar bütün sohbetlere uygulanıyor³, proje talimatları yalnız o projedeki sohbetlere. Bellek de projeye göre ayrılıyor. Her projenin kendi belleği var ve Claude bir projede çalışırken öteki projelerin belleğini kullanmıyor². Kullanıcı sohbette neyi hatırlamasını, değiştirmesini ya da unutmasını istediğini söylediğinde güncelleme bir sonraki sohbette geçerli oluyor. Belleği tek bir sohbet için kapatmak da mümkün, ama yalnız ilk mesajdan önce.

Claude Code aynı ayrımı dosyalarla yapıyor. Kurumun yönettiği talimat, kullanıcının bütün projelerdeki tercihi, ekiple paylaşılan proje talimatı ve yalnız kullanıcının o projedeki notu ayrı dosyalarda duruyor. Kullanıcı “always use pnpm, not npm” gibi bir şeyi hatırlamasını istediğinde Claude bunu otomatik belleğe yazıyor. Proje talimatına yazdırmak için kullanıcının bunu ayrıca istemesi¹ gerekiyor. Arayüz “Saved 2 memories” gibi satırlarla kaydı gösteriyor. Aynı belge bir boşluğu da açıkça yazıyor. Kullanıcı düzeyindeki bir kural ile proje kuralı çeliştiğinde Claude ikisinden birine uyabilir. Belge çözüm olarak iki dosyayı tutarlı tutmayı öneriyor.

Google'ın Gemini'sinde kullanıcı kayıtlı bilgiyi ayarlardaki Personal context sayfasından ekleyebiliyor ya da sohbette “Remember that I don't own a car” gibi bir cümleyle kaydettirebiliyor⁴. Kalıcı kayıt burada kullanıcının açık isteğiyle başlıyor.

Üç ürün de kapsamı ayarlarda ayırıyor. Ayarlardaki ayrım kullanıcı ayarlara gittiğinde işe yarar. Tercih ise çoğu zaman sohbetin ortasında söylenir ve kapsamın da orada, o cümlenin hemen altında görünmesi gerekir.

Bu desenin dayanağı ürünlerin kendi belgeleri. Kamuya mal olmuş bir olay ya da yayımlanmış bir ölçüm yok. Belgeler yine de üç şeyi açıkça gösteriyor.

Birincisi, kalıcı tercih modelin bağlamına giren bir metin. Claude Code'un belgesi bellek dosyalarını Claude'un bağlam olarak okuduğunu, zorunlu yapılandırma saymadığını¹ yazıyor ve bir eylemi her koşulda engellemek için ayrı bir mekanizma öneriyor. Yanlış kapsama yazılan bir tercih bu yüzden sonraki her cevapta okunmaya devam eder. Kullanıcı onu bulup silene kadar cevapları sessizce eğer.

İkincisi, katmanlar çoğaldıkça çakışma kaçınılmaz. Aynı belge kullanıcı ve proje kuralları çeliştiğinde sonucun belirsiz kaldığını kabul ediyor ve çözümü kullanıcıya bırakıyor. Kapsamı ayırmak işin yarısı. Çakışmada hangi katmanın geçerli olduğunu ürünün belirlemesi öteki yarısı.

Üçüncüsü paylaşım. Claude Code'da proje talimatı ekip üyelerine gidiyor, yerel not yalnız kullanıcıda kalıyor. Yanlış kapsam seçimi bir kişinin alışkanlığını bütün ekibin ajanına taşıyabiliyor.

Bu belgeler ürünlerin ne yaptığını söyler. Tek seferlik isteklerin ne sıklıkla kalıcı kayda dönüştüğünü ya da kullanıcıların aynı tercihi kaç kez tekrarladığını söylemez. O sayıyı kendi ürününün günlüğünden çıkarabilirsin.

Kayıtlı tercih sayısı bu desenin çalışıp çalışmadığını söylemez. Bakılacak yer kaydın doğru kapsama düşüp düşmediği.

• Tekrarlanan tercih. Aynı tercihi (ton, dil, uzunluk, biçim) üç ayrı sohbette yazan kullanıcıların payı. Yüksekse kullanıcı kalıcı yolu bulamıyor.
• Kayıttan sonra geri alma. Kalıcı kaydedilen tercihlerin bir hafta içinde silinme ya da düzeltilme payı. Yüksekse tek seferlik istekler kalıcı yazılıyor.
• Kapsam dağılımı. Yeni kayıtların ne kadarı tek seferlik kalıyor, ne kadarı projeye, ne kadarı hesaba yazılıyor. Hepsi hesap düzeyindeyse ürün kapsamı ayırmıyor.
• “Neden böyle yazdın” soruları. Kullanıcının beklemediği bir tonun ya da biçimin nedenini sorduğu mesajlar. Cevap eski bir kayda gidiyorsa kapsam yanlış seçilmiş.
• Çakışma tutarlılığı. Hesap ve proje tercihi çeliştiğinde hangisinin uygulandığını günlükten say. Aynı çakışmada farklı sonuç çıkıyorsa sıra tanımlı değil.

Üç metin var. Denetim promptu ürünündeki tercih yazan ve okuyan kodu tarar, bir tercihin hangi kapsama yazıldığını ve kapsama kimin karar verdiğini raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu kapsam ayrımını kurar. Önce planı gösterir, onayınla uygular ve tek seferlik bir isteğin yeni sohbete taşınmadığını sınayan bir test ekler. Kural kodlama ajanının kendi çalışması için. Ona söylediğin bir tercihi bellek dosyasına yazmadan önce kapsamını sorsun.

Bu depoda kullanıcının tercihlerini (ton, dil, biçim, uzunluk, araç seçimi gibi) hatırlayan ya da uygulayan bir AI özelliği var: bellek, özel talimat, proje talimatı, kullanıcı profili ya da ayarlar. Görevin, tek seferlik isteklerin kalıcı tercihten ayrılıp ayrılmadığını denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Tercih yazan bütün yolları bul: bellek kaydı oluşturan araç çağrıları, sohbetten tercih çıkaran arka plan işleri, ayar ve profil güncelleyen kod, talimat dosyası yazan komutlar.
2. Her yol için bak: tercihin kapsamı (bu mesaj, bu sohbet, bu proje, hesap) nerede belirleniyor? Kayıtta açık bir kapsam alanı var mı, yoksa her kayıt tek bir genel listeye mi gidiyor?
3. Kapsam kararını kim veriyor: kullanıcı mı, kod mu, model mi? Model veriyorsa sistem promptunda ya da araç tanımında "bu sefer" ile "bundan sonra" gibi ifadeleri ayırması için bir kural var mı?
4. Tek seferlik bir istek (örnek: "bu e-postayı resmî yaz") bir sonraki sohbette okunan bir kayda dönüşebiliyor mu? Bunu mümkün kılan yolu dosya ve satırla yaz.
5. Kalıcı bir tercih yazıldığında kullanıcıya ne gösteriliyor: neyin kaydedildiği, hangi kapsama yazıldığı, kayda giden yol? Kişisel bir tercih ekiple paylaşılan bir yere (proje talimatı, ortak ayar) yazılabiliyor mu?
6. Okuma tarafında katmanlar (kurum, hesap, proje, sohbet) çeliştiğinde hangisi geçerli? Sıra kodda tanımlı mı, yoksa hepsi modele birlikte verilip seçim ona mı bırakılıyor?
7. Kullanıcı aynı tercihi birkaç sohbette tekrarladığında ürün kaydetmeyi öneriyor mu? Tekrarı fark eden bir iz var mı?

Rapor biçimi: her bulgu için dosya ve satır, tercihin hangi yoldan hangi kapsama yazıldığı, olası sonuç (örnek: tek bir müşteri e-postası için istenen resmî ton bütün sohbetlere geçer) ve önerdiğin düzeltme. Kapsamı modelin seçtiği yollardan başla.

Bu depodaki AI özelliğine "tek seferlik ayarı kalıcı tercihten ayır" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Her tercih kaydının açık bir kapsamı olsun: sohbet, proje ya da hesap. Kapsamsız kayıt yazılamasın.
2. Kullanıcının cümlesindeki kapsam işaretlerini ayır. "Bu sefer", "bu e-postayı", "şimdilik" tek seferlik, "bundan sonra", "hep", "her zaman" kalıcı. Kapsamı belirsiz istek o işte uygulansın ve kaydedilmesin.
3. Tek seferlik uygulanan bir tercihin yanında kalıcı yapma seçenekleri dursun ("bu projede hep", "her zaman"). Kullanıcı aynı tercihi ikinci kez söylediğinde asistan kaydetmeyi önersin.
4. Kalıcı bir tercih yazıldığında aynı mesajda neyin, hangi kapsama yazıldığını göster ve kayda giden bağlantıyı ver. Kayıt tek tıkla geri alınabilsin.
5. Okurken katman sırası kodda tanımlı olsun: sohbetteki istek proje talimatını, proje talimatı hesap tercihini geçsin. Bağlamı kurarken bu sırayı uygula, çelişen alt katmanı bağlama koyma ya da çeliştiğini işaretle.

Uygularken:
- Kapsam kararını modelin serbest metnine bırakma. Bellek ya da tercih aracının şemasına zorunlu bir kapsam alanı ekle ve geçersiz değeri reddet.
- Var olan kayıtları taşırken kapsamı bilinmeyenleri hesap düzeyine yazmadan önce bana listele.
- Kullanıcıya görünen metinleri (kayıt satırı, düğmeler) tek bir yerde tut.
- Bir test ekle: bir sohbette "bu e-postayı resmî yaz" de, yeni bir sohbet aç ve bağlama giren tercihlerde resmî tonun olmadığını doğrula. Sonra "bundan sonra hep kısa yaz" de ve yeni sohbette bu tercihin hesap kapsamında bulunduğunu doğrula.

## Tercihin kapsamını sor
- Kullanıcı bir tercih söylediğinde (ton, araç, komut, biçim) onu bellek ya da talimat dosyasına yazmadan önce kapsamını belirle: yalnız bu iş, bu proje ya da bütün projeler.
- "Bu sefer", "şimdilik", "bu dosyada" gibi ifadeleri tek seferlik say ve hiçbir dosyaya yazma.
- Kapsam belirsizse yazma, tek cümleyle sor.
- Bir tercihi kaydettiğinde hangi dosyaya, hangi kapsama yazdığını söyle.
- Kişisel bir tercihi ekiple paylaşılan proje talimatına yazma, kullanıcının kendi dosyasına yaz.
- Yeni tercih var olan bir kuralla çelişiyorsa ikisini yan yana göster ve hangisinin geçerli olacağını sor.

Belleği ve kalıcı ayarı olmayan ürün bu deseni gerektirmez. Her sohbet sıfırdan başlıyorsa her istek zaten tek seferlik.

Her tercihte soru sormak gürültü. Kullanıcı “bundan sonra” ya da “bu sefer” dediyse kapsam belli, asistan sormadan uygular ve yalnız sonucu gösterir. Seçenek düğmeleri yalnız belirsiz durumda görünür.

Dar varsayılanın bir bedeli var. Kullanıcı bazı tercihleri birkaç kez söylemek zorunda kalır. Asistan ikinci tekrarda kaydetmeyi önerirse bu bedel küçük kalır.

Bu desen kaydın sonradan nasıl görüleceğini ve silineceğini çözmez, o ayrı bir iş. Kurumun ya da platformun koyduğu kurallar da kullanıcının tercihi sayılmaz. Onların kaynağı kullanıcıya ayrıca gösterilmeli.