Kimi’de Vision Prompting: Ekran Görüntüsünden Hata Ayıklama ve UI Fix
Kimi vision prompting ile ekran görüntüsünden bug bulma, UI düzeltme ve tekrarlanabilir prompt kalıpları. Pratik hata ayıklama rehberi.
Bir UI hatasını metinle anlatmak bazen hatanın kendisinden uzun sürer. “Kart sağa kayıyor”, “modal kesiliyor”, “mobilde buton görünmüyor” gibi şikayetler belirsiz kalır. Kimi’de vision prompting, ekran görüntüsünü doğrudan bağlama koyarak hem teşhis hem de düzeltme önerisini hızlandırır.
İyi Bir Vision Prompt’un Anatomisi
Görüntü göndermek tek başına yetmez. Modelin işini kolaylaştıran dört parça vardır:
1. Beklenen davranış: “Desktop’ta üç sütun, mobilde tek sütun olmalı.”
2. Gözlemlenen sorun: “768px civarında kartlar üst üste biniyor.”
3. Stack / dosya ipucu: “Tailwind, ProductGrid.tsx şüpheli.”
4. İstenen çıktı formatı: “Kök neden + minimal patch + test önerisi.”
Bu yapı, genel “düzelt şunu” taleplerinden çok daha az halüsinasyon üretir.
Hata Ayıklama İçin Prompt Kalıpları
Teşhis odaklı: “Bu ekran görüntüsünde layout bozulmasının olası CSS/Flex nedenlerini öncelik sırasıyla listele. Varsayım yapmadan önce hangi ek bilgiye ihtiyacın olduğunu söyle.”
Düzeltme odaklı: “Yalnızca ilgili bileşeni değiştirerek sorunu gider. Global CSS’e dokunma. Diff olarak ver.”
Regresyon odaklı: “Bu fix’in breakpoint’lerde yan etki yaratıp yaratmayacağını kontrol listesiyle değerlendir.”
Aynı görüntüyü üç turda (teşhis → patch → regresyon) kullanmak, tek uzun prompt’tan daha kontrollüdür.
UI Fix’te Sık Yapılan Hatalar
Vision destekli düzeltmelerde tekrar eden tuzaklar:
- Görüntüdeki metni yanlış okuyup yanlış bileşene gitmek
- “Hızlı çözüm” diye
!importantveya sabit piksel yığını üretmek - Tasarım sistemini yok sayıp one-off stil eklemek
- Erişilebilirlik durumlarını (fokus, kontrast) hiç kontrol etmemek
Bunu azaltmak için modelden önce kök nedeni, sonra minimal değişikliği isteyin. Patch’i uygulamadan önce ilgili dosyayı siz de açın.
Kimi K2.5 ile Görselden Koda: UI Mockup’tan Front-end Üretmek
Kimi K2.7 Code vs Claude / GPT: Kodlama Benchmark’larında Ne Değişti?
Ne Zaman En Çok İşe Yarar?
Vision prompting özellikle şu durumlarda güçlüdür:
- Responsive kırılmalar
- Z-index / overflow kaynaklı kesilmeler
- Form hata mesajlarının yanlış hizalanması
- Tasarım ile implementasyon farkının görsel kanıtı
Buna karşılık, saf mantık bug’larında (yanlış sorgu, race condition) ekran görüntüsü yardımcı olsa da asıl kanıt hâlâ log ve testtir. Görseli tamamlayıcı kanıt gibi kullanın.
Görüntü Kalitesi ve Bağlam
Modelin doğru teşhis koyabilmesi için ekran görüntüsü de “temiz girdi” olmalıdır. Çok düşük çözünürlük, aşırı sıkıştırma veya kritik alanın kadraj dışında kalması yanılgı üretir. Mümkünse ilgili bileşeni yakınlaştırılmış ikinci bir kare ekleyin; genel sayfa + detay çifti çoğu zaman tek geniş görüntüden daha işe yarar.
Tarayıcı DevTools açıkken alınan görüntülerde computed style ipuçları da görünebilir. Bunları prompt’a kısa not olarak eklemek, modelin spekülasyon alanını daraltır.
Ticket Şablonuna Dönüştürmek
Ekip içinde vision prompting’i kişiselleşmiş bir beceri olmaktan çıkarın. Bug ticket şablonuna “ekran görüntüsü / beklenen / gözlenen / ortam / şüpheli dosya” alanlarını ekleyin. Kimi’ye yapıştırılan metin bu şablondan gelsin. Böylece hem insan triyajı hem AI teşhisi aynı yapıda ilerler ve bilgi kaybı azalır. Birkaç sprint sonra en sık tekrar eden UI bug sınıflarına özel mini prompt’lar da ekleyebilirsiniz; bu, genel “düzelt” taleplerinden daha tutarlı sonuç verir.
Sonuç
Kimi’de vision prompting, UI hata ayıklamayı “anlatmaya çalışmak”tan “göstermek”e çevirir. Kaliteli sonuç için görüntü + beklenen davranış + stack ipucu + çıktı formatı birlikte gitmelidir. Küçük bir bug backlog’unda bu kalıbı standartlaştırırsanız, frontend düzeltme süreniz ölçülebilir biçimde kısalır.
