Hata ayıklama, refactoring ve mimari inceleme için Claude kodlama promptları

Aşağıdaki her promptu işe yarayan dört kısıtlama

Promptlardan önce, hepsinin paylaştığı kurallar. Bunları herhangi bir kodlama promptuna eklemek, çıktıyı modeli değiştirmekten daha çok iyileştirir.

Sürümünü belirt. Eğitim verisi, hakkında en çok yazı bulunan büyük sürüme kayma eğilimindedir ve bu çoğunlukla senin kullandığın sürüm değildir. [framework] [sürüm], [dil] [sürüm] kullanıyoruz ifadesi çoğu güncel olmayan yanıtı önler.

Diff'i sınırla. Bir düzeltme istersin ama sık sık bir refactoring alırsın. Mümkün olduğunca az değişiklik yap, mevcut yapı ve isimlendirmeyi koru ve değiştirdiğin her satırı tek satırlık bir gerekçeyle listele bu belgedeki en yararlı tek cümledir.

Çözümlerden önce hipotez iste. Neyin yanlış olduğu sorulan bir model, sonuç gibi sunulan bir tahmin verir. Sıralı nedenler ve ucuz kontroller istenen bir modelse sana bir hata ayıklama planı verir.

Hata modunu zorunlu kıl. Bu neyi bozabilir ve bu, nedeni mi yoksa belirtiyi mi düzeltiyor? yapay zeka yardımının en pahalı türünü yakalar: belirtiyi ortadan kaldırırken kusuru yerinde bırakan bir değişiklik.

Hata ayıklama

1. Sıralanmış hipotezler

İşte hata, ilgili kod ve zaten elediklerim. Bana henüz bir çözüm verme. Olasılığa göre sıralanmış dört en olası nedeni listele ve her biri için doğrulayacak veya eleyecek en ucuz tek kontrolü belirt. Hata: [yapıştır]. Kod: [yapıştır]. Zaten elenenler: [liste]. Stack: [dil, framework, sürümler].

2. Aralıklı hata

Bu, yaklaşık [sıklık] ile [koşullar] altında aralıklı olarak başarısız oluyor. Bu belirli belirtiyi üretebilecek aralıklı hata kategorilerini sırala: zamanlama, sıralama, kaynak tükenmesi, harici bir bağımlılık, çalıştırmalar arasında sızan durum, saat veya saat dilimi, önbellekleme. Her biri için kodda neyin bunu desteklediğini veya çeliştiğini ve bunları ayırt etmek için tam olarak neyi loglamam gerektiğini söyle. Kod: [yapıştır].

3. Yerelde çalışıyor

Bu yerelde çalışıyor ama [ortam] üzerinde başarısız oluyor. Bu belirli belirtiye neden olabilecek her ortam farkı kategorisini listele: yapılandırma, ortam değişkenleri, sürümler, dosya sistemi ve büyük küçük harf duyarlılığı, saat dilimi ve yerel ayar, ağ ve DNS, izinler, kaynak sınırları ve derleme veya paketleme farkları. Belirtiye göre olasılığa göre sırala ve her biri için tanı komutunu ver.

4. Düzeltmeyi uygulamadan önce açıkla

Bu düzeltmenin neden işe yaradığını, neyi düzeltmediğini ve neyi bozabileceğini açıkla. Gerçek neden başka bir yerdeyse ve bu bir belirti yaması ise, bunu açıkça söyle.

Kod incelemesi

5. Bir diff'i incele

Bu diff'i talepkar bir inceleyici gibi gözden geçir. Öncelik sırasına göre kategoriler: doğruluk hataları, güvenlik sorunları, ele alınmamış hata modları, yarış durumları, ardından stil. Her bulgu için önem derecesini, ilgili satırı ve genelde değil bu kod tabanında neden önemli olduğunu belirt. Biçimlendirme hakkında yorum yapma. Diff sağlamsa, bulgu uydurmak yerine bunu söyle. Kurallar: [açıkla]. Diff: [yapıştır].

6. Güvenlik geçişi

Bu kodu özellikle güvenlik sorunları için incele: enjeksiyon, kimlik doğrulama ve yetkilendirme açıkları, güvensiz deserileştirme, kodda veya loglarda gizli bilgiler, hassas bir işleme ulaşan doğrulanmamış girdi ve bağımlılık riski. Her biri için kategoriyi adlandırmak yerine saldırı yolunu somut olarak ver. [Dağıtım, kimlik doğrulama katmanı, veri hassasiyeti] görmeden değerlendiremeyeceğin şeyi açıkça belirt.

7. Hata modu denetimi

Bu koddaki her harici çağrı için, yavaş olduğunda, başarısız olduğunda, beklenmedik veri döndürdüğünde ve kısmen başarılı olduğunda ne olacağını belirt. Bunlardan hangileri şu anda ele alınmamış ve hangileri sessiz kalır?

Bu sonuncusu, genel bir incelemeden daha fazla gerçek üretim sorunu bulur, çünkü kimsenin test yazmadığı yolları sorar.

Refactoring ve mimari

8. Refactoring planı

[açıklama] için refactoring yapmak üzere sıralı bir plan öner. Kısıtlamalar: [x]'in genel API'si değişemez, sürekli dağıtım yapıyoruz, bu yüzden her adım bağımsız olarak yayınlanabilir olmalı ve testler her adımdan sonra geçmeli. Her adım için değişikliği, riski, nasıl doğrulanacağını ve nasıl geri alınacağını ver. Riske göre sırala, en düşükten başla. Kodu henüz yazma.

9. Karşı tarafı savun

[Bağlam ve kısıtlamalar] için [yaklaşım B] yerine [yaklaşım A]'yı seçiyorum. B için en güçlü savunmayı yap. Kısıtlarımız hakkında neyin doğru olması gerekirdi ki B doğru olsun ve bunlardan herhangi biri burada doğru mu? İkisinin de geçerli olduğu sonucuna varma.

10. Devraldığını anla

İşte ana kaynak dosyalar. Şunları üret: giriş noktaları, istekten yanıta veri akışı, paylaşılan ve nerede değiştirilen durum, harici bağımlılıklar ve her biri kullanılamaz olduğunda ne olduğu ve karmaşıklık ile bağlantıya dayanarak hata içermesi en olası üç alan. Sağladığımdan neyi belirleyemediğini açıkça belirt.

Bu son talimat önemlidir. Modeller, yapıştırmadığın bir dosyanın davranışını adından çıkarsayarak tarif eder. Açık bir bilinmeyenler listesi istemek, neyi okuman gerektiğini sana söyler.

Testler

11. Yazmayacağın testler

Muhtemelen düşünmediğim girdilere odaklanarak bu fonksiyon için test senaryoları yaz: sınırlar, boş ve null, unicode, çok büyük değerler, eşzamanlı çağrılar ve uygulamadaki her türlü örtük varsayım. Her test için hangi varsayımı kontrol ettiğini belirt. Fonksiyon: [yapıştır].

12. Test paketini test et

İşte bir fonksiyon ve mevcut testleri. Hangi davranış kapsanmıyor? Özellikle: hata yolları, sınır değerleri, parametreler arası etkileşimler ve uygulamanın hiçbir testin doğrulamadığı yaptığı herhangi bir şey. Mevcut testleri yeniden yazma.

İkincisi daha değerli promptdur ve nadiren kullanılır. Kapsama yüzdeleri hangi satırların çalıştığını söyler, hangi davranışların gerçekten sabitlendiğini değil, ve bu ikisi arasındaki boşluk, regresyonların yaşadığı yerdir.

İkinci görüş deseni

Bu paketteki en yüksek kaldıraçlı alışkanlık ve birden fazla model gerektiren tek alışkanlık.

Bir modelden bir cevap al. Sonra geç ve devret:

Başka bir mühendis bu soruna şu çözümü önerdi. Bununla ilgili neyin yanlış olduğunu bul: uç durumlarda doğruluk, eşzamanlılık, hata yönetimi, [ölçek]'te performans veya gözden kaçan daha basit bir yaklaşım. Gerçekten sağlamsa, itiraz uydurmak yerine bunu açıkça söyle. Sorun: [yapıştır]. Önerilen çözüm: [yapıştır].

İki sonuç var ve ikisi de faydalı. Ya ikinci model gerçek bir açık bulur, ki bunu birleştirmeden önce öğrenmiş olursun, ya da karşı çıkmaya itilmesine rağmen aynı fikirde olur, ki bu anlamlı bir doğrulamadır. Aynı modelle yinelemek sana ikisini de vermez, çünkü kendi çıktısını inceleyen bir model çoğunlukla kendisiyle aynı fikirde olur.

Bunu yanlış gitmesi pahalıya mal olacak kararlarda kullan: bir şema değişikliği, bir eşzamanlılık düzeltmesi, kimlik doğrulama veya parayla ilgili herhangi bir şey. Rutin işlerde değil. Tüm iş akışını tek bir yerde görmek için modelleri yan yana karşılaştırma, sohbet ortasında model değiştirme ve birden fazla modelle kod yazma ve hata ayıklama sayfalarına bak.

Nelere dikkat etmeli

Uydurulmuş API'ler. Var olmayan, kendinden emin metot adları, parametreler ve yapılandırma anahtarları, özellikle son zamanlarda değişen kütüphaneler için. İmza doğru görünecektir. Yabancı olduğun herhangi bir şeyin üzerine inşa etmeden önce gerçek dokümantasyonu kontrol et.

Güven sinyali yok. Doğru bir düzeltme ile ustaca yanlış olan biri aynı kesinlikle gelir. Ton sana hiçbir şey söylemez.

Sessiz kapsam genişlemesi. İkinci kısıtlamanın var olma nedeni budur.

Güvenlik tiyatrosu. Kodundaki zafiyet sınıflarını adlandırmak faydalı bir ilk geçiştir. Bu bir denetim değildir ve model senin tehdit modelini, dağıtımını veya veri hassasiyetini bilmez.

Haftalık kullandığın promptları yapıştırabileceğin bir yerde tut ve süregelen kısıtlamaları bir proje talimatlarına koy, böylece o projedeki her sohbete otomatik olarak uygulanır.