Claude Opus 5 Promptlama: Tekrar Kontrol Et Demeyi Bırakın

Çoğu geçiş kılavuzu size kodunuzda neyin bozulduğunu anlatır. Bu kılavuz ise komut istemlerinizde neyin bozulduğunu anlatıyor.

Apidog'u bugün deneyin

Claude Opus 5, 24 Temmuz 2026'da piyasaya sürüldü ve Anthropic bununla birlikte özel bir komut istemi kılavuzu yayınladı. Bu kılavuz önemli bir davranış değişikliğini belgeliyor: Opus 4.8'i iyileştiren bazı talimatlar Opus 5'i kötüleştiriyor. Bu etki ince değil; ölçülebilir biçimde daha pahalı, daha ayrıntılı ve bir durumda tamamen bozuk sonuçlar üretebiliyor.

Nedeni basit: Opus 5, daha önce açıkça istemeniz gereken birçok davranışı varsayılan olarak gerçekleştiriyor. Eski komut isteminiz bu davranışları yeniden istediğinde, talimat modelin mevcut davranışıyla birleşir. Doğruluk iki katına çıkmaz; iki kat doğrulama geçişi çalışır.

Bu kılavuz, belgelenen davranış değişikliklerini ve sistem komut isteminize doğrudan ekleyebileceğiniz parçacıkları inceler. Ayrıca düşünme devre dışı bırakıldığında görülen iki hata modunu ele alır: düzgün görünen bir çıktı üretilirken araç döngüsünün sessizce bozulması. Kod düzeyindeki değişiklikler için Opus 4.8'den Opus 5'e geçiş kılavuzuna bakın. İstek ve yanıt yüklerindeki farkları karşılaştırmak için Apidog ile aynı komut istemini farklı ayarlarla gönderebilirsiniz.

Tek satırlık özet

Opus 5, Opus 4.8'e göre daha fazla doğrulama yapar, daha fazla yazar, daha fazla yetki devreder ve düzeltmelerini daha çok açıklar. Opus 4.8 komut isteminiz modeli bu davranışlara yönlendirmek için ayarlanmıştı. Opus 5'te ise bu talimatlar çoğu zaman aşırıya kaçar.

Bu nedenle yaklaşımınız eklemek değil, çıkarmak olmalı. Eklediğiniz talimatlar da daha fazla çaba istemek yerine sınır koymalıdır: kısa yanıt verin, kapsam içinde kalın, alt aracı oluşturmayın.

1. Doğrulama talimatlarınızı silin

Bu en önemli değişikliktir.

Anthropic, Opus 5'in ek bir komut istemi olmadan kendi çalışmasını doğruladığını belirtiyor. Model yazdıklarını yeniden okur, aritmetiğini kontrol eder, testleri tekrar çalıştırır ve belirtilmeyen uç durumları arar. Opus 4.8 için sık kullanılan şu talimatlar artık varsayılan davranışla çakışır:

Yanıt vermeden önce çalışmanızı iki kez kontrol edin.
Bir sonraki adıma geçmeden önce her adımı doğrulayın.
Yanıtınızı hatalar için gözden geçirin, sonra düzeltin.
Muhakemenizi dikkatlice kontrol edin.
Çıktının doğru olduğundan emin olun, sonra geri döndürün.

Bu satırları taşırsanız aşırı doğrulama oluşur. Model zaten çalıştıracağı doğrulama geçişlerine sizin istediğiniz ek geçişleri de ekler. Uzun, araç odaklı çalıştırmalarda bu fark gerçek bir maliyet oluşturur.

Çözüm bu talimatları silmektir. Açık bir doğrulama geçişine gerçekten ihtiyaç duyduğunuz yüksek riskli bir adım varsa, bunu küresel kural yapmak yerine yalnızca o adıma bağlayın:

Genel doğrulama geçişleri eklemeyin; zaten varsayılan olarak doğrularsınız.
Tek istisna: geçiş SQL'ini yazdıktan sonra, şema dökümüne karşı bir kez çalıştırın
ve herhangi bir uyuşmazlığı bildirin. Başka hiçbir şeyi yeniden doğrulamayın.

Bu yapı önemlidir. Opus 5'te küresel bir “her şeyi doğrula” talimatı maliyet çarpanıdır. Tek, kapsamı belirlenmiş istisna ise kontrollü bir denetimdir.

API harcamasını takip ediyorsanız, Opus 5 fiyatlandırma dökümündeki önbellek ve toplu işlem seçeneklerini değerlendirin. Genel maliyet azaltma adımları için Claude API faturasını kesme kılavuzuna bakın.

2. Özlü yanıtlar için açık sınır koyun

Opus 5'in varsayılan yanıtları Opus 4.8'den daha uzundur. Bu durum raporlar, özetler, tasarım belgeleri ve README'ler gibi yazılı teslimatlarda da görülür.

Önemli ayrım şudur: effort parametresini düşürmek görünür yanıt uzunluğunu doğrudan azaltmaz. Çaba, modelin ne kadar düşündüğünü kontrol eder; ne kadar yazdığını değil. xhigh seviyesinden medium seviyesine indiğinizde düşünme jetonları azalabilir, ancak görünür yanıt benzer uzunlukta kalabilir.

Her seviyenin davranışını görmek için Opus 5 çaba parametresi kılavuzuna bakın.

Uzunluğu komut isteminde sınırlayın. “Kısa ol” gibi belirsiz bir talimat yerine ölçülebilir üst sınır kullanın:

Yanıt formatı: daha fazlasını istemediğim sürece en fazla 150 kelime.
Giriş yok, sorumun tekrarı yok, sonda özet yok.
Yanıtla başlayın, sonra gerekirse muhakemeyi ekleyin.

Yazılı teslimatlar için hem üst sınırı hem de çıkarılacak bölümleri belirtin:

Geçiş belgesini en fazla 800 kelime olacak şekilde yazın.
Dahil edin: kırıcı değişiklikleri, her biri için düzeltmeyi ve bir geri alma adımını.
Hariç bırakın: eski sistem hakkında arka plan, bir sözlük ve bir sonuç bölümü.
Bir bölüm payını aşarsa, adımları kesmeden önce örnekleri kesin.

Kod ağırlıklı görevlerde sınırlama kodun kendisinden çok açıklama miktarını hedeflemelidir:

Sadece farkı döndürün, başka hiçbir şeyi değil.
Değişiklik bariz değilse, neyi değiştirdiğinize dair bir açıklama yapmayın;
bu durumda, fark bloğunun üzerine tek bir cümle ekleyin.

3. Alt aracı yetki devrini sınırlayın

Opus 5, Opus 4.8'e göre alt aracılara daha kolay yetki devreder. Çok parçalı bir görevde ve alt aracı oluşturmayı destekleyen bir ortamda, işi paralelleştirmeye eğilimlidir.

Bu çoğu zaman doğru bir karar olabilir. Ancak her alt aracı kendi bağlamını ve jeton maliyetini taşır. Maliyet veya gecikmeye duyarlı iş yüklerinde sayısal sınır koyun.

Alt aracı istemiyorsanız:

Bu görev için alt aracı oluşturmayın. Bunu bu konuşmada halledin.

Bazı paralel çalışmalar faydalıysa, yetki devrini sınırlayın:

En fazla 2 alt aracıya yetki devredebilirsiniz ve bu sadece paralel çalışabilecek bağımsız
dosya düzeyindeki işler için geçerlidir.
Araştırma, planlama ve nihai sentezi bu iş parçacığında kendiniz yapın.

Kaçınılması gereken durumlar şunlardır:

• Tek bir dosyayı okumak için alt aracı oluşturmak
• Ana iş parçacığının zaten bağlamına sahip olduğu bir kararı alt aracıya devretmek
• Araştırma ve sentez gibi birbirine bağlı işleri gereksiz yere bölmek

Alt aracılarla bilinçli şekilde çalışıyorsanız, Claude Kod alt aracı oluşturma kılavuzu donanım tarafındaki kapsamlandırmayı ele alır.

4. Dar görevlerde kapsamı açıkça kısıtlayın

Opus 5 görev kapsamını genişletmeye eğilimlidir. Başarısız bir testi düzeltmesini isterseniz, testin çağırdığı yardımcıyı yeniden düzenleyebilir, tür imzasını güncelleyebilir ve ek test durumları yazabilir. Bir değişkeni yeniden adlandırmasını isterseniz, çevredeki işlevi de değiştirebilir.

Bu bazen faydalıdır. Ancak cerrahi bir değişiklikte istenmeyen yeniden düzenleme, daha büyük farklar ve daha geniş etki alanı anlamına gelir.

Sınırı açıkça belirtin; yasaklı işlemleri de adlandırın:

Kapsam: yalnızca src/client/http.ts dosyasındaki yeniden deneme sayısı sabitini değiştirin.
Çevreleyen kodu yeniden düzenlemeyin, hiçbir şeyi yeniden adlandırmayın,
test eklemeyin, belgeleri güncellemeyin. Başka bir değişiklik gerektiğini
düşünüyorsanız, onu yapmak yerine durun ve bana bildirin.

Son cümle kritiktir. Modelin gerçek bir sorunu bildirebileceği bir yol sağlar. Böylece ya değişikliği izinsiz yapması ya da gözlemi tamamen atlaması yerine, değişmemiş bir farkla birlikte işaretlenmiş bir endişe döndürür.

5. Düzeltme anlatımını kapatın

Opus 5, düzeltmelerini Opus 4.8'den daha fazla anlatır. Yanıtın ortasında yaklaşımını değiştirdiğinde, önceki yaklaşımın neden yanlış olduğunu ve nasıl değiştiğini açıklayabilir.

Bu, etkileşimli çalışmalarda faydalı olabilir. Ancak yanıtın bir ayrıştırıcıya, kullanıcı arayüzüne veya başka bir modele aktarıldığı işlem hatlarında gürültü oluşturur.

Yalnızca nihai sonucu istiyorsanız şu talimatı kullanın:

Düzeltmeleri veya yaklaşım değişikliklerini anlatmayın.
Sadece nihai cevabı döndürün. Eğer düşüncenizi revize ettiyseniz, bu
revizyon yanıtta değil, muhakemenizde yer almalıdır.

Yanıtları yapılandırılmış depolamaya gönderiyorsanız, biçimin yalnızca istenmesini değil uygulanmasını sağlamak için bunu yapılandırılmış çıktılarla birlikte kullanın.

Düşünme devre dışı bırakıldığında ortaya çıkan hata modları

Yukarıdaki başlıklar ayarlama problemidir. Bu bölüm ise doğrudan doğruluk problemidir.

Anthropic, thinking: {type: "disabled"} ile düşünme devre dışı bırakıldığında Opus 5'te ara sıra görülebilen iki davranışı belgeliyor. Bir aracı üretime almadan önce ikisini de test edin.

Araç çağrılarının düz metin olarak yazılması

Model, bir araç çağrısına benzeyen içerik üretebilir; ancak bunu yapılandırılmış tool_use bloğu yerine yanıt gövdesinde düz metin olarak döndürür. Bu durumda hiçbir araç çalışmaz.

Tek aşamalı bir sohbette bunu fark etmek kolaydır. Aracı döngüsünde ise hata sessizce ilerleyebilir:

1. Döngü yapılandırılmış araç çağrısı görmez.
2. Bu nedenle hiçbir eylem çalışmaz.
3. Düz metin konuşma geçmişinde kalır.
4. Sonraki aşamalar bu metni araç çağrısı tamamlanmış gibi yorumlayabilir.
5. Hata aşamalar arasında birleşir.

Görünür çıktıda dahili XML etiketleri

<thinking> gibi etiketler kullanıcıya görünen yanıtta yer alabilir. Bu durum yalnızca görsel bir sorun değildir; yanıtları HTML olarak işliyorsanız veya yapı için ayrıştırıyorsanız işlem hattını bozabilir.

Buradaki sezgisel olmayan nokta şudur: Komut isteminde bu etiketleri adlandırmak sızıntıyı azaltmak yerine artırabilir. Örneğin, “Asla <thinking> etiketleri çıktısı verme” talimatı jeton dizisini bağlama yerleştirir ve görünme olasılığını artırabilir. Bu nedenle böyle bir talimat yazmayın.

Anthropic'in önerdiği azaltma yöntemi komut istemi değildir. Düşünmeyi etkin bırakın ve maliyeti daha düşük bir çaba seviyesiyle kontrol edin:

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "output_config": { "effort": "low" },
  "messages": [
    { "role": "user", "content": "..." }
  ]
}

Bu yaklaşım, düşünme devre dışı bırakıldığında görülen yapıtlar olmadan düşük maliyetli ayarları kullanmanızı sağlar.

Ayrıca şu uyumluluk kuralına dikkat edin:

• thinking: {type: "disabled"} ile xhigh veya max çabasını birleştirmek 400 hatası döndürür.
• Düşünme devre dışı olduğunda çaba high ile sınırlıdır.
• Düşünme artık varsayılan olarak açıktır. thinking alanını atlamak, Opus 4.8'deki gibi düşünmesiz çalışma değil, uyarlanabilir düşünme anlamına gelir.

Düşünmeyi devre dışı bırakmanız kesin bir gereksinimse, komut istemi yerine aracı döngünüze savunmacı kontrol ekleyin. Metin gövdesinde yürütülmemiş araç çağrısına benzeyen bir dize bulunan asistan dönüşünü, geçmişe eklemeden önce reddedin. Hayalet çağrının kayda girmesine izin vermek yerine açık hata üretin.

Tahmin etmek yerine değişiklikleri test edin

Komut istemi değişikliklerini yalnızca okuyarak değerlendirmek zordur. Yanıt uzunluğu, doğrulama geçişleri ve alt aracı sayısı gibi davranışlar jeton sayılarında ve istek yükünde görünür. Bu nedenle en güvenilir yöntem, aynı isteği gönderip sonuçları karşılaştırmaktır.

Bu kurulumu, hepsi bir arada API geliştirme ve test platformu olan Apidog üzerinde şu şekilde yapabilirsiniz:

1. Anthropic Mesajlar uç noktasına "model": "claude-opus-5" ile bir istek oluşturun. API anahtarını gövdeye yapıştırmak yerine ortam değişkeni olarak saklayın.
2. Eski Opus 4.8 sistem komut isteminizi ve kırpılmış Opus 5 sürümünüzü, aynı kullanıcı girdisiyle çalışan iki kayıtlı istek olarak kaydedin.
3. Her yanıttaki usage bloğunu karşılaştırın. Çıktı jetonları özlülük sınırının uygulanıp uygulanmadığını; girdi jetonları ve önbellek alanları ise komut istemi düzenlemelerinin önbellek önekini bozup bozmadığını gösterir.
4. Düşünme jetonları azalırken görünür yanıt uzunluğunun korunup korunmadığını görmek için isteği farklı çaba seviyelerinde çoğaltın.
5. Araç çağrılarının düz metin yerine yapılandırılmış tool_use blokları olarak döndüğünü doğrulamak için akış yanıtını inceleyin.

Beşinci adım, düz metin araç çağrısı hatasını üretime ulaşmadan yakalamanızı sağlar. Yan yana karşılaştırma için Apidog'u indirin ve istek biçimi için Opus 5 API kılavuzuna bakın.

Dürüst üst sınır

Komut istemi kılavuzları genellikle modeli ihtiyacınız olacak son modelmiş gibi sunar. Ancak Opus 5, Claude yığınının zirvesi değildir. Fable 5, “en yetenekli geniş çapta yayınlanmış” unvanını korurken Opus 5; siber güvenlik sömürüsü ve otonom biyoloji araştırmalarında Mythos 5'in gerisindedir. Anthropic bunu kendi lansman yazısında belirtiyor.

Doğru çerçeveleme, sınır fiyatının yarısında sınır sınıfı yetenek sunması ve belirtilmiş bir üst sınıra sahip olmasıdır.

Lansman kıyaslama iddiaları — Frontier-Bench, ARC-AGI 3, OSWorld 2.0 ve CursorBench — tamamen Anthropic'in kendi rakamlarıdır ve 25 Temmuz 2026 itibarıyla bağımsız olarak tekrarlanmamıştır. Bunları satıcı tarafından bildirilen veriler olarak değerlendirin; kendi komut istemlerinizle değerlendirme çalıştırın.

Hepsini bir araya getirmek

Maliyet duyarlı bir aracı görev için kırpılmış Opus 5 sistem komut istemi şu şekilde olabilir:

Doğrulama geçişleri eklemeyin; varsayılan olarak doğrularsınız.
Yanıtlar: en fazla 150 kelime, giriş yok, kapanış özeti yok.
Alt aracı oluşturmayın. Bunu tek bir iş parçacığında halledin.
Belirttiğim görevin kesinlikle içinde kalın. Başka bir değişiklik
gerekli görünürse, onu yapmak yerine durun ve bana bildirin.
Düzeltmeleri veya yaklaşım değişikliklerini anlatmayın.

Bu altı satırın beşi kısıtlamadır ve hiçbiri modelden daha fazla çaba istemez. Temel değişim budur:

• Opus 4.8'de komut istemiyle modelin taban davranışını yükseltiyordunuz.
• Opus 5'te komut istemiyle modelin davranışına tavan koyuyorsunuz.

Bu şablonla başlayın. Ardından Opus 4.8 ayarlarını doğrudan taşımak yerine kendi değerlendirmeleriniz üzerinde çaba taraması yapın.

Parametre ayrıntıları için çaba parametresi kılavuzuna, düzenleyici iş akışları için Claude Kod'da Opus 5 kullanma kılavuzuna, modelin genel konumu için Claude Opus 5 nedir yazısına bakın. Anthropic'in modeller genel bakışı mevcut özellik tablosunu içerir.

Sıkça Sorulan Sorular

“Çalışmanızı iki kez kontrol edin” ifadesini komut istemlerimden gerçekten silmeli miyim?

Evet. Anthropic'in komut istemi kılavuzu, Opus 5'in ek talimat olmadan doğrulama yaptığını ve taşınan doğrulama talimatlarının aşırı doğrulamaya neden olduğunu belirtiyor. Küresel kuralı silin. Belirli bir adım gerçekten açık kontrol gerektiriyorsa, talimatı yalnızca o adıma bağlayın.

Opus 5 neden düşük çabada bile bu kadar ayrıntılı?

Çünkü çaba görünür çıktı uzunluğunu değil, düşünme miktarını kontrol eder. Çabayı düşürmek muhakeme jetonlarını azaltabilirken yanıt uzunluğu yaklaşık aynı kalabilir. Komut istemine açık bir kelime veya biçim sınırı ekleyin.

Opus 5'in alt aracı oluşturmasını nasıl durdurabilirim?

Doğrudan belirtin:

Alt aracı oluşturmayın; bunu bu konuşmada halledin.

Bazı paralel çalışmalar faydalıysa sayısal üst sınır belirleyin ve yetki devrini bağımsız paralel görevlerle sınırlayın.

Çıktımda neden <thinking> etiketleri görüyorum?

Bu yapı, düşünme devre dışı bırakıldığında ara sıra ortaya çıkabilir. Etiketleri adlandıran bir komut istemi talimatı eklemeyin; bu, sızıntıyı daha olası hale getirebilir. Anthropic'in önerisi düşünmeyi etkin bırakmak ve maliyeti düşük çaba seviyesiyle kontrol etmektir.

Bir araç çağrısı düz metin olarak geri dönerse ne olur?

Hiçbir araç çalışmaz. Sızan metin konuşma geçmişinde kalabilir ve sonraki dönüşler bunu tamamlanmış bir eylem gibi değerlendirebilir. Asistan dönüşlerini geçmişe eklemeden önce doğrulayın; mümkünse düşünmeyi devre dışı bırakmak yerine etkin tutun.