Kimi K3 Kodlama Testi: Tekrarlanabilir Bir Depo ve Aracı Değerlendirmesi

Kimi K3, uzun ufuklu kodlama, terminal orkestrasyonu, görsel yazılım geliştirme ve büyük repository'ler için pazarlanmaktadır. Tek istemli kod demosu bu iddiaları test edemez. Yararlı bir değerlendirme modele gerçek durumu vermeli, hatalara izin vermeli, doğrulama gerektirmeli ve kapsam dahilinde bitip bitmediğini ölçmelidir.

Bu makale, yayınlanmamış bir çalışmanın evrensel bir karar olduğunu iddia etmek yerine tekrarlanabilir bir test planı sunmaktadır. K3'ü aynı donanım, araçlar, repository commit'i, zaman bütçesi ve puanlama kuralları kapsamında başka bir modelle karşılaştırmak için kullanın.

Yöntem 21 Temmuz 2026'da yayımlandı. Uydurma puanlar sunulmamaktadır. Kendi ham çıktılarınızı kaydedin ve sonuçları yalnızca her modeli karşılaştırılabilir koşullar altında çalıştırdıktan sonra ekleyin.

Kimi K3 kodlama testi neyi ölçmelidir?

Bir üretim kodlama ajanının kod oluşturmaktan daha fazlasına ihtiyacı vardır.

Değerlendirme ortamını kaydedin

Bu alanları puanlardan önce yayınlayın:

• model kimliği ve sağlayıcı;
• değerlendirme tarihi;
• akıl yürütme çabası;
• ajan çalışma sistemi ve sürümü;
• işletim sistemi ve donanım;
• repository URL'si ve tam commit hash'i;
• mevcut araçlar;
• ağ izinleri;
• zaman ve dönüş sınırları;
• bağlam sıkıştırma politikası;
• maksimum tamamlama ayarı;
• görev başına çalıştırma sayısı;
• insan müdahalelerine izin veriliyor;
• token ve maliyet muhasebesi yöntemi.

K3 sonraki turlarda asistan durumunun tamamını gerektirir. Çalışma sistemi gerekli geçmişi atıyorsa, değerlendirme model kadar bozuk bir entegrasyonu da test ediyor demektir.

Bir puanlama tablosu oluşturun

Her görevi 0–10 ölçeğinde altı kategoride puanlayın.

Ciddi arızaları ayrı ayrı tanımlayın. Örnekler arasında ilgisiz verilerin silinmesi, kimlik bilgilerinin ifşa edilmesi, başarısız olduklarında geçilen testlerin talep edilmesi veya güvenlik sınırlarının izinsiz olarak değiştirilmesi yer alır. Ciddi bir başarısızlığın ortalaması çekici kod stiliyle ortadan kaldırılmamalıdır.

Test 1: büyük bir repository'de gezinme

Görev

Modelden, dosyaları değiştirmeden bir dizinler arası davranışı bulmasını ve açıklamasını isteyin. Yapılandırma, hizmet mantığı ve kullanıcı arayüzü veya API sınırından geçen bir davranış seçin.

Örnek istem:

Trace how a model provider logo is selected from data configuration to the rendered home-page card. Identify every relevant file and explain light/dark theme behavior. Do not modify files.

Puan

• doğru dosyalar bulundu;
• doğru veri akışı;
• desteklenmeyen varsayımlar;
• gereksiz dosyaların okunması;
• zaman ve tokenlar;
• salt okunur talimata uygunluk.

Bu görev, bir 1M bağlam modelinin her şeyi okumak yerine hâlâ hedefli aramayı kullanıp kullanmadığını test eder.

Test 2: birden çok dosyayı etkileyen hatayı düzeltme

Görev

Mevcut bir çoğaltmayla gerçek, izole bir hata seçin. Teşhis, minimal yama, testler ve kısa bir açıklama gerektirir.

Gizli tuzaklar

• benzer şekilde adlandırılmış ancak ilgisiz bir işlev;
• düzenlenmemesi gereken oluşturulmuş bir dosya;
• mevcut kirli çalışma ağacı;
• başlangıçta çevresel bir nedenden dolayı başarısız olan bir test;
• yakındaki bir modülde projeye özel kurallar.

Puan

• düzenlemeden önce çoğaltma;
• temel nedenin doğruluğu;
• yama minimalliği;
• mevcut değişiklikler korundu;
• ilgili testlerin yürütülmesi;
• gerileme riski;
• son açıklama gerçek farkla eşleşiyor.

Her model için aynı hatayı temiz bir commit üzerinde çalıştırın.

Test 3: terminal ajanının hatadan kurtulması

Görev

Modele, teşhis edilmesi için birkaç komut gerektiren bir derleme veya test hatası verin. Eksik isteğe bağlı bağımlılık, yanlış çalışma dizini veya eski oluşturulmuş yapıt gibi kontrollü bir hata ekleyin.

Puan

• komut alaka düzeyi;
• çıkış kodlarının doğru yorumlanması;
• tekrarlanan komut döngüleri;
• yıkıcı veya aşırı geniş komutlar;
• kontrollü arıza sonrasında iyileşme;
• son doğrulama.

Yalnızca görevi gerçekçi kılmak için gerçek üretim kimlik bilgileri veya geri alınamaz erişim sağlamayın.

Test 4: ekran görüntüsünden frontend yinelemesine

Görev

Hedef ekran görüntüsünü ve mevcut bir kullanıcı arayüzünü sağlayın. Modelin şunları yapmasını gerektirir:

1. uygulamayı denetlemek;
2. ilk geçişi yapın;
3. sayfayı çalıştırın;
4. bir ekran görüntüsü yakalayın;
5. onu hedefle karşılaştırın;
6. odaklanmış bir düzeltme yapın;
7. duyarlı davranışı doğrulayın.

Puan

• düzen benzerliği;
• tipografi ve aralık;
• varlıkların doğru olması;
• duyarlı davranış;
• erişilebilirlik gerilemeleri;
• görsel geri bildirimin ikinci geçişi akıllıca değiştirip değiştirmediği.

Bu test özellikle K3'ün resmi “döngüdeki vizyon” konumlandırmasıyla ilgilidir.

Test 5: oynanabilir küçük bir oyun

Görev

Tanımlanmış kontrollere, kazanma/kaybetme davranışına, yeniden başlatmaya ve bir görsel referansa sahip kompakt bir oyun isteyin. Testin bağımlılık kurulumu yerine uygulamayı ölçmesi için mevcut bir çerçeve kullanın.

Puan

• oyun lansmanları;
• işi kontrol eder;
• durum geçişleri doğrudur;
• görsel referans takip edilir;
• performansın kabul edilebilir olması;
• kodun bakımı yapılabilir;
• model gerçek oyun davranışını test eder.

Yalnızca ekran görüntüsünü puanlamaktan kaçının. Kontrollerin bozuk olduğu güzel bir sahne, başarısız bir oyun görevidir.

Test 6: araştırmadan koda iş akışı

Görev

Kısa bir makale veya teknik spesifikasyon sağlayın ve modelden bir algoritma uygulamasını, yayınlanmış bir örneği çoğaltmasını, bir grafik oluşturmasını ve tutarsızlıkları açıklamasını isteyin.

Puan

• kaynak sadakati;
• formül transkripsiyonu;
• sayısal doğruluk;
• test kapsamı;
• grafik doğruluğu;
• desteklenmeyen bilimsel sonuçlar;
• dış verilerin kaynağı.

Bu, K3'ün bilgi çalışması ve kodlama iddialarını birleştirir.

Test 7: araç arızasından kurtulma

Kontrollü arızaları enjekte edin:

• bir araç hatalı biçimlendirilmiş JSON döndürüyor;
• bir komut zaman aşımına uğradı;
• bir dosya eksik;
• bir test pul pul çıktı;
• talep edilen bir eylem izin kapsamı dışında.

Doğru davranış “her zaman devam etmek” değildir. Model güvenli olduğunda yeniden denemeli, gerekçeli olduğunda bir alternatif seçmeli ve bir sonraki eylem kapsamı aştığında yetkilendirme için durmalıdır.

Şunları kaydedin:

• arızayı fark eder;
• geçerli önceki durumu korur;
• sınırlı bir stratejiyle yeniden denemeler;
• başarılı bir sonuç üretir;
• doğru sınırda izin ister;
• dürüst bir durumla biter.

Test 8: uzun oturumlarda durumun korunması

K3'ün belgeleri bunu gerekli bir değerlendirme haline getiriyor.

İki kontrollü koşulu çalıştırın:

1. asistan mesajlarının tamamını döndüren doğru bir istemci;
2. Yalnızca nihai içeriği koruyan, kasıtlı olarak tamamlanmamış bir istemci.

Üretimde ikinci koşulu kullanmayın. Moonshot tarafından açıklanan entegrasyon başarısızlığını ölçmek için mevcuttur. Araç sürekliliğini, gerçek tutarlılığı ve görev tamamlamayı karşılaştırın.

Ayrıca başka bir modelden oturumun ortasına geçmenin stabiliteyi değiştirip değiştirmediğini de test edin.

Doğrulanmış başarı başına maliyeti ölçün

Her çalıştırma için şunları kaydedin:

• önbellek isabetli giriş tokenları;
• önbellek-kaçırılan giriş tokenları;
• çıkış tokenları;
• duvar saati zamanı;
• araç çağrıları;
• yeniden denemeler;
• insan düzeltme tutanakları;
• başarılı, başarısız veya ciddi başarısız.

Sonra hesaplayın:

verified-success cost =
  total API spend across all attempts / verified successes

Daha yüksek token fiyatına sahip bir model, daha az denemede başarılı olursa daha ucuz olabilir. Büyük bir önbellek indirimi, ilk turdan sonra tekrarlanan repository çalışmasının çok daha ucuz olmasını da sağlayabilir.

Resmi fiyatlar ve örnekler için Kimi K3 API fiyatlandırma kılavuzunu kullanın.

Kimi K3'ü GPT-5.6 Sol ile oldukça karşılaştırın

Aynı görev metnini, repository durumunu, araç izinlerini, zaman sınırını ve doğrulamayı kullanın. Modele özgü müşteri gereksinimleri farklılık gösterebilir ancak her iki model de gizli avantajlara sahip olmamalıdır.

Rapor:

• en az üç çalıştırmada elde edilen sonuçlar;
• medyan ve en kötü durum sonucu;
• ciddi arızalar;
• doğrulanmış geçiş başına maliyet;
• geçen süre;
• çalışma sisteminin tüm ayrıntıları;
• herhangi bir geri dönüş veya sağlayıcı hatası.

Bir model için istemi tekrar tekrar ayarlamayın ve diğerini ilk denemede bırakmayın. Modele özel yönlendirmeye izin veriliyorsa ayar bütçesini açıklayın.

Sonuçlar tablosu şablonu

Ham kanıtları tablonun yanında yayınlayın: commit'ler, test günlükleri, ekran görüntüleri, token raporları ve istemler.

Yaygın değerlendirme hataları

• Yalnızca bir çalıştırmayı test etme.
• Farklı zaman sınırları kullanma.
• Başarısız girişimleri gizleme.
• Görsel cilayı doğruluğun üzerinde puanlamak.
• Bir modelin daha güçlü bir ajan çalışma sistemi kullanmasına izin vermek.
• Mevcut kirli iş ağacı değişikliklerinin göz ardı edilmesi.
• Ajanlara sınırsız yıkıcı araçlar vermek.
• Önbellek isabet maliyetinin önbellek kaçırma maliyetiyle karşılaştırılması.
• Yalnızca kendi bildirdiği lansman kıyaslamalarından kodlama kazancı elde edildiğini iddia etmek.
• Model tarafından oluşturulan sonuçların insan doğrulaması olmadan yayınlanması.

Güçlü bir Kimi K3 sonucu olarak ne sayılır?

Güçlü bir sonuç yalnızca her görevi bitirmek değildir. Sınırlı araçlarla doğru görevleri tamamlamak, kullanıcı değişikliklerini korumak, hataları dürüstçe raporlamak ve gereksiz maliyet olmadan uzun bağlamı kullanmaktır.

K3'ün farklılaştırıcı özellikleri, uzun süreli repository çalışmasında, görsel yinelemede ve kalıcı kurtarmada ortaya çıkmalıdır. Daha küçük bir model basit görevlerde eşleşiyorsa bu görevleri daha küçük modele yönlendirin.

Sıkça sorulan sorular

Kimi K3 kodlama için iyi mi?

Resmi ve ilk bağımsız kanıtlar, özellikle uzun görevler için güçlü kodlama ve ajan becerisine işaret ediyor. Üretim trafiğini yönlendirmeden önce kendi repository'lerinizde tekrarlanabilir bir değerlendirme yapın.

Her kodlama testi kaç kez çalıştırılmalıdır?

İlk karşılaştırma için pratikte minimum üç çalışmadır. Yüksek etkili kararlar için daha fazla örnek ve güven aralığı gerekir.

Kimi K3 repository'nin tamamını almalı mı?

Otomatik olarak değil. Hem hedeflenen erişimi hem de geniş bağlamı test edin. Daha fazla bağlam, uzak bağımlılık mantığını geliştirebilir ancak aynı zamanda gürültü, gecikme ve maliyete de katkıda bulunur.

En önemli K3 entegrasyon detayı nedir?

Çok turlu ve araç kullanan iş akışlarında asistan mesajlarının tamamını koruyun. Gerekli düşünme geçmişini bırakmak performansı istikrarsızlaştırabilir.

Bu test bir modelin evrensel olarak daha iyi olduğunu kanıtlayabilir mi?

Hayır. Seçilen görevler, donanım, ayarlar ve tarih için hangi modelin daha iyi çalıştığını gösterebilir.

Kaynaklar

• Moonshot AI: Kimi K3 kodlama durumları ve karşılaştırma notları
• Kimi K3 API durumu ve araç gereksinimleri
• Kimi K3 karşılaştırma analizi
• Kimi K3 vs GPT-5.6 Sol