Aider.

Git ile birlikte düzenleme

Değişiklik birbiriyle bağlantılı birkaç dosyayı etkiliyorsa her dosyayı ayrı web sohbetine taşımak kullanışsızdır. Aider proje dizininde başlatılır ve gereken kaynak dosyalar oturuma eklenir. Yardımcı bu dosyaların içeriğini alır, ek bağlam için depo haritasını kullanır ve göreve göre dosyaları değiştirir. Değişiklikler Git üzerinden izlenebilir; istenmeyen değişiklikleri geri alma olanağı vardır.

Proje haritası ilişkileri bulmaya yardımcı olur, ancak bağlamı sonsuz yapmaz. Çok fazla dosya eklerseniz hem maliyet hem de önemli bir gereksinimi kaçırma olasılığı artar. Belirli davranışı tanımlamak, yeniden üretilebilir bir örnek eklemek ve başvuru materyallerini yalnızca gerçekten gereken yerlerde tutmak daha iyidir.

Önce bir soru, sonra bir değişiklik

ask modunda mevcut kodu düzenlemeden anlamak kolaydır. code modu değişiklik yapmak içindir; architect ise çözümü tasarlama ve dosyalara uygulama görevlerini planlayıcı model ile düzenleyici model arasında paylaştırır. Bu ayrım yararlıdır: bazen araca uygulamayı değiştirme izni vermeden önce hatanın nedenini anlamak gerekir.

Örneğin içe aktarma işlevi, zorunlu olmayan alanı boş olan satırları kaybediyor. Önce böyle bir satırın izlediği yolu ve elendiği noktayı göstermesini isteyin. Ardından değişikliği içe aktarma işleyicisiyle sınırlayın, boş değer için beklenen sonucu tanımlayın ve kontrol eklemesini isteyin. Böyle bir görev tanımını değerlendirmek, “içe aktarmayı düzgünce yeniden yaz” talebinden kolaydır.

Model ayrı olarak seçilir

Aider, Ollama üzerinden de kullanılabilen yerel modellerin yanı sıra bulut sağlayıcılarına bağlanır. Programı kurmak tek başına bulut modelinin işlem kaynaklarını ücretsiz yapmaz. Yerel seçenekte metin, seçilen yerel sunucu tarafından işlenir; düzenleme kalitesi, hız ve kullanılabilir bağlam uzunluğu modele ve bilgisayara bağlıdır.

Yerel çalıştırma olanağı her çalıştırmaya kendiliğinden uygulanmaz. Bulut anahtarı ilgili bağlamı sağlayıcıya gönderir; ek kaynaklar ve komutlar da ağa erişebilir. Özel bir projeyle çalışmadan önce etkin modeli, bağlantı adresini ve oturumdaki dosyaları kontrol edin. Üçüncü taraf API'lerin desteklenmesi, Aider'ın kendisinin ayrı bir bulut API'si bulunduğu anlamına gelmez.

Sonuç nasıl kabul edilir

Düzenlemeden sonra diff'i inceleyin ve yalnızca hata mesajının metninin değil, asıl sorunun düzeltildiğinden emin olun. Otomatik lint ve testler sorunların bir kısmını bulmaya yardımcı olur; bunların komutları ve ortamı kendi projenize göre ayarlanmalıdır. Dar kapsamlı düzeltmenin komşu işleyişi bozmaması için normal dosyayı ve geçersiz kaydı da kontrol edin.

Git'e yapılan bir kayıt önceki duruma dönmeyi kolaylaştırır, ancak kodun doğru olduğunu kanıtlamaz. Bağlama gizli bilgiler eklemeyin ve modelin kurum içi mimari kuralları kendiliğinden tahmin edeceğine güvenmeyin. Bunlar için gerçek örnekler içeren kısa bir kurallar dosyası hazırlamak daha iyidir.

Hangi görevler uygun

• Birden fazla dosyada yeniden üretilebilir hatayı düzeltmek
• Düzenlemeden önce kodu tartışmak
• Doğrulanabilir Git-diff hazırlamak
• Kendi yerel modelinizle çalışmak