# Uzun Kodlama Oturumlarının Bağlam Kaybetmesi Nasıl Önlenir? > Kalıcı gerçekleri sohbetten kısa bir görev günlüğüne, karar kaydına, test kaydına ve repository checkpoint’lerine taşıyarak bağlam kaybını önleyin. Sıkıştırma veya model değişiminden önce bu artefaktları yeniden yükleyin. Uzun oturumlar çoğunlukla ani unutma yerine kademeli sapmayla başarısız olur. Ajan ana hedefi hatırlar ama küçük bir kısıtı kaybeder, eski test sonucuna güvenir, araştırmayı tekrarlar veya repository ile artık uyuşmayan plana göre düzenleme yapar. Çözüm, transkriptten daha kısa ve güvenilir kalıcı dış durumdur. Konuşmayı çalışma belleği, repository’yi doğruluk kaynağı olarak görün. Her anlamlı checkpoint’te neyin değiştiğini, neyin doğrulandığını, neyin belirsiz kaldığını ve sırada ne olduğunu yazın. ## Dört tür bağlamı izleyin Özetin ayrışmamış bir hikâyeye dönüşmemesi için gerçekleri işlevlerine göre ayırın. | Bağlam türü | Örnekler | Kalıcı konum | |---|---|---| | Hedef | Kullanıcı sonucu ve kabul kriterleri | Görev günlüğü | | Kısıtlar | Uyumluluk, güvenlik, stil, kapsam | Görev günlüğü | | Repository durumu | Değişen dosyalar ve güncel branch | Version control | | Kanıt | Testler, loglar, ekran görüntüleri, benchmarklar | Doğrulama kaydı | Varsayımları ancak açıkça etiketlenmiş beşinci kategori olarak ekleyin. Her varsayım onu doğrulayacak veya reddedecek en ucuz eylemi içersin. ## Kısa bir görev günlüğü tutun Yararlı bir günlük tek ekrana sığar. Her mesajdan sonra değil, kilometre taşlarından sonra güncelleyin. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Kesin yolları, komutları ve hata adlarını koruyun. Tartışmanın nasıl geliştiğine ilişkin günlük tutmayın. ## Checkpoint’leri doğrulanmış durum çevresine yerleştirin Bir checkpoint, sonraki oturumun yeniden üretebileceği sonucu izlemelidir. Geçen test grubu, küçük kaydedilmiş değişiklik, doğrulanmış API yanıtı veya fixture ile desteklenen tasarım kararı iyi sınırlardır. Model değişimi veya bağlam sıkıştırması öncesinde değişmiş dosyaları kaydedin. Kod yazıldığı için özelliğin çalıştığını söylemeyin; iddiayı test, build veya gözlenebilir artefakta bağlayın. | İddia | Gerekli kanıt | |---|---| | Parser iki çağrıyı destekler | İki korelasyonlu call ID içeren fixture | | Retry güvenlidir | Bağlantı kopmasında idempotency testi | | Refactor davranışı korur | Eski ve yeni test paketleri geçer | | UI doğrudur | Hedef boyutlarda render incelemesi | ## Sohbeti oynatmak yerine güncel kaynağı alın Bir ayrıntı önemliyse güncel dosyayı, şemayı veya resmi belgeyi yeniden açın. Eski transkript artık değişmiş kodu anlatabilir. Ajana son durumu incelemesi için yollar ve arama terimleri verin. Retrieval dar tutulmalıdır: tüm repository’den önce arayüzü, uygulamayı, başarısız testi ve ilgili logu yükleyin. Bu, akıl yürütme alanını korur. ## Kararları ve kanıtları koruyarak sıkıştırın İyi sıkıştırma konuşma tekrarını kaldırırken kısıtları, geri döndürülmesi zor kararları, reddedilen seçenekleri ve doğrulamayı korur. `verified`, `observed`, `assumed` ve `pending` durumlarını ayırın. Başarısız deneyi son tasarım gibi özetlemeyin. Aynı cazip yaklaşımın geri gelmemesi için neden reddedildiğini saklayın. ## Araç çıktısını bağlama girmeden sınırlayın Uzun loglar ve üretilen dosyalar dikkati hızla tüketir. İlgili aralık, sayı veya eşleşen satır isteyin. Tam çıktıyı artefakt olarak saklayıp kısa özeti yoluyla birlikte döndürün. Test hatalarında ilk yararlı stack trace, başarısız assertion ve ortam ayrıntıları yeterlidir. Yüzlerce tekrarlı frame’i modele geri göndermeyin. ## Deterministik bir ritüelle devam edin Duraklama, bağlam sıkıştırması veya model değişiminden sonra: * Hedefi ve kısıtları okuyun. * Version control durumunu ve son değişiklikleri inceleyin. * Güncel durum bölümünde adı geçen dosyaları açın. * Son ilgili kontrolü yeniden çalıştırın. * Kaydedilen sonraki eylemin hâlâ geçerli olduğunu doğrulayın. Bu rutin eski özetleri yeni düzenlemelere yol açmadan yakalar. ## Transkript belleğine güvenmeden model seçin Gateway model değişimini kolaylaştırır ama durum hâlâ sizin sorumluluğunuzdadır. Atlas Cloud tek base URL’den birden fazla LLM protokolü sunar; canlı bir ajanı taşımadan önce [protokol matrisini](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) ve güncel [model kataloğunu](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) kontrol edin. Yeni modele görev günlüğünü, ilgili kaynak dosyalarını ve taze doğrulama sonucunu verin. Aynı protokol ve davranış doğrulanmadıkça sağlayıcıya özgü durum handle’larına güvenmeyin. ## Sonuç Kalıcı durum kısa, kanıta dayalı ve yeniden yüklenmesi kolay olduğunda uzun kodlama oturumları bağlamı korur. Tek ekranlık günlük tutun, doğrulanmış değişikliklerde checkpoint oluşturun, sohbeti oynatmak yerine güncel kaynağı alın, araç çıktısını sınırlayın ve deterministik devam ritüeli kullanın. Büyük context window yardımcıdır; işi kurtarılabilir yapan disiplinli dış durumdur. ## FAQ ### Daha büyük context window uzun kodlama oturumu için yeterli mi? Hayır. Daha fazla alan baskıyı geciktirir ancak eski kısıtların görünür kalacağını veya bayat gözlemlerin düzeltileceğini garanti etmez. ### Bir kodlama oturumu günlüğünde neler olmalı? Hedefi, kısıtları, güncel planı, değişen dosyaları, önemli kararları, doğrulama sonuçlarını, açık riskleri ve kesin sonraki eylemi kaydedin. ### Ajan ne sıklıkta checkpoint oluşturmalı? Geçen bir test, tamamlanan geçiş adımı, tasarım kararı veya planı değiştiren keşif gibi anlamlı bir durum değişiminden sonra. ### Tüm transkripti yeni modele yapıştırmalı mıyım? Genellikle hayır. Seçilmiş checkpoint’i, ilgili kaynak dosyalarını ve logları verin; yeni model güncel repository durumunu incelesin. ### Özetin eski bir hatayı korumasını nasıl önlerim? Doğrulanmış gerçekleri varsayımlardan ayırın, komut ya da dosya konumu gibi kanıt ekleyin ve yeni testler çeliştiğinde iddiaları kaldırın. ### Kesintiden sonra devam etmenin en güvenli yolu nedir? Görev günlüğünü yükleyin, version control durumunu inceleyin, son ilgili doğrulamayı yeniden çalıştırın ve kaydedilmiş sonraki eylemden başlayın.