Kıdemli kod inceleyici promptu — hataları, performans sorunlarını, uç
LLM kod incelemelerinin çoğu sizi stil ayrıntılarına boğar ve asıl hataları kaçırır. Bu prompt, modeli önem derecesine göre triyaj yapmaya, yalnızca katı bir tech-lead incelemesinden geçecek şeyleri işaretlemeye ve endişelendiği tam satır numaralarını alıntılamaya zorlar; böylece her bulguyu hızla doğrulayabilirsiniz.
Aşağıdaki diff'i inceleyen kıdemli bir staff engineer'sınız. Hedefiniz, katı bir tech-lead incelemesinden gerçekten geçecek olanları yakalamak — lint gürültüsü değil. İnceleme kuralları: 1. Her bulguyu şu kategorilerden birine ayır: BLOCKER, MAJOR, MINOR, NIT. 2. Varsayılan olarak yalnızca BLOCKER ve MAJOR yayınla. Açıkça istemedikçe MINOR ve NIT'i bastır. 3. Her bulgu için tam dosya yolunu + satır numarası aralığını alıntıla. Sonra açıkla: (a) neyin yanlış olduğunu, (b) üretimdeki hata modunu, (c) önerilen çözümü. 4. Sorunun gerçek olduğuna %80'in altında eminsen, bulguyu [düşük-güven] olarak işaretle ve hangi ek bağlamın doğrulamana izin vereceğini açıkla. 5. Bir paragraflık genel özetle bitir: gönder / takip-issue'larla gönder / gönderme. Şu konularda yorum YAPMA: - Aktif olarak yanıltıcı olmadıkça adlandırma tercihleri. - Bir formatter kullanılıyorsa biçimlendirme/boşluk. - Ölçülmüş bir sıcak yola bağlayamadığın hipotetik optimizasyonlar. - Kod tabanının başka yerlerde zaten kullandığı kalıplar (bu bir hata değil, stilistik tutarlılıktır). İncelenecek diff: [birleşik diff'inizi veya dosya içeriğinizi buraya yapıştırın]
Bunu ne zaman kullanmalı
- Önemsiz olmayan bir PR'ı birleştirmeden önce — ikinci bir göze istemeniz gereken her şeyi ortaya çıkarmak için diff'i bu prompttan geçirin.
- Kendi çalışmanızın öz incelemesi — insan incelemesi istemeden önce yararlıdır, utanç verici şeyleri yakalar.
- Tanıdık olmayan bir kod tabanına alışırken — değiştirmeden önce risklerini anlamak için bir fonksiyonu prompla birlikte yapıştırın.
Model ipuçları
- claude
- Claude (Sonnet 4.6 veya Opus 4.7) genellikle en düşünceli triyajı sağlar. Diff'i bir kod bloğunda yapıştırın; uzun bağlamlar tam PR incelemelerini iyi yönetir.
- chatgpt
- GPT-5 / GPT-4o stil işaretlemede daha agresif olma eğilimindedir. Yukarıdaki 'MINOR ve NIT'i bastır' kuralı onu yolda tutar.
- cursor
- Cursor'da bunu bir .cursorrules girdisi olarak kaydedin veya composer'a yapıştırın. @file referansları ile iyi çalışır.
Örnek çıktı
BLOCKER: src/auth/session.ts:42-58 - ne: Oturum belirteci karşılaştırması === kullanıyor, sabit zamanlı karşılaştırma değil. - hata modu: Uzaktan girişte zamanlama saldırısıyla sızdırılabilir. - düzeltme: Buffer çifti üzerinde crypto.timingSafeEqual() kullanacak şekilde değiştir. MAJOR: src/auth/session.ts:73 [düşük-güven] - ne: Yenileme belirteci localStorage'a yazılıyor. - hata modu: Sayfaya temizlenmemiş kullanıcı içeriği ulaşırsa XSS sızdırma riski. - düzeltme: İstemcinin okumasına gerek yoksa httpOnly cookie'ye taşıyın. (düşük-güven: Front-end'in bu belirteci nasıl kullandığını göremiyorum.) Özet: takip-issue'larla gönder. Sabit zamanlı düzeltme birleştirmeden önce gereklidir; depolama konumu bu PR'dan bağımsız olarak açılmaya değer bir takip sorunudur.
Nasıl çalışır
AI kod incelemelerinin çoğu neden işe yaramaz
Varsayılan olarak, dil modelleri kod inceleme görevlerinde 'yardımcı kıdemsiz' kişiliğine bürünür. Bu, adlandırma konusunda aşırı yorum yapmaları, sorunsuz koda 'temiz kod' yeniden yazımları önermeleri ve görmezden gelmeniz gereken bir öneri duvarında tek gerçek hatayı gömmeleri anlamına gelir. Sinyal-gürültü oranı iş akışını öldürür — çoğu ekip bir hafta içinde AI'yı inceleme için kullanmayı bırakır.
Yukarıdaki prompt üç şeyi tersine çevirir: önemsiz sorunların açıkça bastırılması için önem derecesi triyajı ister, her bulgunun saniyeler içinde doğrulanabilmesi için satır numaralarını talep eder ve hangi bulgulara tam dosyayı okumadan güveneceğinizi bilmeniz için bir güven bayrağına zorlar.
Bunu CI'nızla eşleştirme
Bu promptu PR iş akışınızda bir 'ikinci görüş' adımı olarak çalıştırın — kapı kontrolü olarak değil. Modeller hâlâ halüsinasyon görür, özellikle dosyalar arası değişmezlerde ve yapıştırmadığınız çerçeve kurallarına bağlı kodlarda. Çıktıyı mekanik olarak düzeltilecek sorunlar listesi olarak değil, doğrulanacak şeyler listesi olarak kullanın.
CI'da istiyorsanız, bulguları JSON olarak çıktıla (promptu değiştirin: 'severity, path, lineStart, lineEnd, what, fix, confidence alanlarına sahip bir JSON dizisi döndür'). Sonra BLOCKER/MAJOR olanları açık bir 'AI yardımı — harekete geçmeden doğrulayın' başlığıyla tek bir yorum olarak PR'a gönderin.
Promptu ekibiniz için uyarlama
Diff'in üstüne bir 'Kod tabanı bağlamı' bölümü ekleyin — yığınınızı, test kurallarınızı ve bariz olmayan değişmezleri açıklayan 5-10 satır yapıştırın (örneğin, 'tüm DB yazımları src/db/withTx üzerinden gider, asla ham istemci değil'). Aksi takdirde modeller kod tabanına özgü kuralları kaçırır.
Ekibinizin bilinen zayıf noktaları varsa (bir job runner'da yarış koşulları, belirli bir serviste N+1 sorguları), bir 'Özellikle dikkat et: …' satırı ekleyin. Model bu hata sınıflarına daha fazla ağırlık verecek ve mevcut olduklarında onları işaretleme olasılığı daha yüksek olacaktır.
Sıkça sorulan sorular
›Bunu kapalı kaynaklı kod üzerinde kullanabilir miyim?
Evet, ancak önce işvereninizin politikasını kontrol edin. Promptun kendisi zararsızdır; önemli olan, kullandığınız modele kodunuzu yapıştırmanıza izin verilip verilmediğidir. Claude ve ChatGPT enterprise planları genellikle girdilerinizle eğitilmez; tüketici planları eğitebilir.
›Neden MINOR ve NIT bulguları bastırılır?
Çünkü uygulamada inceleme yorgunluğu yaratırlar. Üçüncü 'bunu bir fonksiyona çıkarmayı düşünün' notundan sonra okumayı bırakırsınız. Onları bastırmak BLOCKER/MAJOR sinyalini keskin tutar. Derin bir inceleme istediğinizde 'MINOR ve NIT dahil tüm bulguları göster' diyerek tekrar açın.
›Diff ne kadar uzun olabilir?
Claude Sonnet/Opus ve GPT-5, 50K+ token diff'i rahatlıkla idare eder. Çok büyük PR'lar için, modelin her alt sistemi izole düşünebilmesi için incelemeyi dizine göre bölün (önce src/auth, sonra src/billing).
›Güvenlik odaklı incelemeler ne olacak?
Bu prompt bariz kripto/depolama/SSRF sorunlarını yakalar ancak kimlik doğrulama veya ödeme koduna yönelik güvenlik incelemesinin yerine geçmez. Bu yollar için bu promptu ve özel bir güvenlik inceleme promptunu çalıştırın (ayrıca yayınlayacağız).
›Birden fazla dosyada inceleme yapabilir mi?
Evet — tüm dosyaları içeren diff'i yapıştırın. Tek bir yapıştırmada dosyalar arası değişmezleri makul derecede iyi yönetir; birden fazla PR'a yayılan sorunlar için (örneğin, 'bu, özellik bayraklarının başka yerlerde nasıl koşullandırıldığı ile tutarlı mı?'), o diğer dosyalardan birkaç temsili alıntı ekleyin.
›[düşük-güven] bulgularına güvenmeli miyim?
Onları 'harekete geçmeden önce araştır' olarak değerlendirin. Düşük güvenli bulguların yaklaşık yarısı gerçektir ancak model doğrulayamamıştır; diğer yarısı yanlış okumalardır. Bayrak, dürüst bir sinyaldir, bulguyu görmezden gelmek için bir neden değildir.
›Neden hata modunu belirtmemi istiyor?
Çünkü 'bu yanlış' demek 'bu unicode girdide çökecek' demeden işe yaramaz. Hata modu satırı size önceliği söyler: milyonda bir uç durumu önleyen bir düzeltme, günlük bir üretim olayını önleyen bir düzeltmeden farklıdır.
›Bunu Cursor'da nasıl kullanırım?
Prompt gövdesini repo kök dizininizdeki .cursorrules dosyasına kaydedin veya inceleme altındaki dosyalar için @file referanslarıyla composer'a yapıştırın. Cursor, kuralları o proje için aktif tutacaktır.
İlgili hesaplayıcılar
İlgili promptlar
Son güncelleme: