Daphne Koller'in ML ürün dersleri: araştırmadan üretime

Neden araştırma sonuçları sık sık ürün gerçekliğinde başarısız olur

Mükemmel bir ML makalesi yine de hayal kırıklığı yaratan bir ürüne dönüşebilir. Makaleler kontrollü koşullar altında bir noktayı kanıtlamak için yazılır. Ürünler ise insanların dağınık bir günde, dağınık verilerle ve az sabırla bir görevi bitirmesine yardımcı olmak için yapılır.

Daphne Koller ML ürün derslerinden (bir biyografi değil, bir mercek olarak) alınacak faydalı sonuçlardan biri, teşviklerin değişmesidir: araştırma yeniliği ve temiz kazançları ödüllendirir, ürün ise kullanılabilirlik ve güveni ödüllendirir. Modeliniz etkileyici olabilir ama özellik anlaşılması güç, yavaş veya öngörülemezse kullanıcılar benchmarkla ilgilenmez.

Kullanıcıların fark ettiği şeyler temel ve anidir. Gecikmeyi hissederler. Aynı girdinin farklı cevaplar vermesi göze çarpar. On iyi sonucu bir kötü hatanın yanında unuturlar. Ve özellik para, sağlık veya halka açık bir şeyle ilgiliyse, güvenip güvenemeyeceklerine çabucak karar verirler.

Çoğu “makale kazanımı” gerçek dünyada aynı birkaç sebepten başarısız olur: hedef bulanıktır (ekip ölçmesi kolay olana optimize eder), veri kayar (yeni kullanıcılar, yeni konular, yeni uç durumlar), sahiplik belirsizdir (kalite sorunları sürer) ya da özellik “AI sihiri” olarak piyasaya sürülür ve çıktıların tahmin edilmesi, doğrulanması veya düzeltilmesi için bir yol yoktur.

Basit bir örnek: bir özetleme modeli çevrimdışı testlerde güçlü görünebilir, ancak ürün bir kritik detayı düşürürse, yanlış bir tonu kullanırsa veya 12 saniye sürerse başarısız olur. Kullanıcılar bunu bir baseline ile karşılaştırmaz; kendi zamanları ve riskleriyle kıyaslarlar.

Ekipler ayrıca modeli ürün olarak görmekte zaman kaybeder. Pratikte model sistemin tek bileşeni değildir: girdi işleme, koruyucular, UI, geri bildirim, günlükleme ve model emin olmadığında fallback yolu gerekir.

Bunu Koder.ai gibi kullanıcıya yönelik AI oluşturucularda açıkça görebilirsiniz. Sohbetten bir uygulama üretmek demo'da harika görünebilir, ama gerçek kullanıcılar sonucun çalışıp çalışmadığını, düzenlemelerin öngörülebilir davranıp davranmadığını ve bir şey bozulduğunda geri alıp alamayacaklarını umursar. Bu ürün gerçekliği: “en iyi model”den çok, güvenilir bir deneyimle ilgilidir.

Makale metrikleri vs ürün çıktıları: uygulamada ne değişir

Araştırma tipik olarak bir noktayı kanıtlamaya çalışır: bir model sabit bir test altında temiz bir veri kümesinde baseline'ı yener. Ürün ise dağınık koşullarda, gerçek risklerle ve sınırlı sabırla bir kullanıcının bir görevi bitirmesine yardımcı olmaya çalışır. Bu uyumsuzluk birçok umut vaat eden fikrin kırıldığı yerdir.

Daphne Koller ML ürün derslerinden en pratik çıkarımlardan biri, “doğruluk”u bitiş çizgisi değil başlangıç sinyali olarak ele almaktır. Makalede küçük bir metrik artışı önemli olabilir. Üründe ise aynı artış görünmez olabilir ya da yeni maliyetler getirebilir: daha yavaş yanıtlar, kafa karıştıran uç durumlar veya destek taleplerinde artış.

Prototip, pilot, üretim: yer kuralları değişir

Bir prototip “bu işe yarar mı?” sorusuna cevap verir. Veri el ile seçilebilir, modeli bir kez çalıştırıp en iyi vakaları demo edebilirsiniz. Bir pilot “gerçek kullanıcılara yardımcı oluyor mu?” der. Artık gerçek girdilere, gerçek zaman sınırlarına ve net bir başarı ölçüsüne ihtiyacınız vardır. Üretim ise “bunu çalışır tutabilir miyiz?”i sorar. Bu güvenilirlik, güvenlik, maliyet ve kötü günlerde ne olacağı gibi konuları içerir.

Kısa hatırlatma:

• Prototip: küçük veri örneği, basit metrik, çok manuel kontrol
• Pilot: gerçek kullanıcı akışları, yapılandırılmış hata analizi, geri bildirim döngüleri
• Üretim: izleme, yedekler, maliyet limitleri ve yeniden eğitme planı

Makalelerin örtük olarak yaptığı işler

Ürün çıktıları modelin etrafındaki her şeye bağlıdır. Veri boru hatları bozulur. Kullanıcı davranışı değiştikçe girdiler kayar. Etiketler eskir. Sorunları erken fark etme ve AI yanlış olduğunda kullanıcıların toparlanmasına yardım etme yollarına da ihtiyacınız vardır.

Bu “örtük işler” genellikle girdi kalitesini takip etmeyi, hataları kaydetmeyi, tuhaf vakaları gözden geçirmeyi ve ne zaman yeniden eğitileceğine karar vermeyi içerir. Ayrıca destek betikleri ve net UI mesajları gerekir, çünkü kullanıcılar deneyimin tamamını, modeli izole şekilde değil, değerlendirir.

İnşa etmeden önce “yeterince iyi”nin ne anlama geldiğini tanımlayın ve sade bir dille yazın: hangi kullanıcılar, hangi görevler, kabul edilebilir hata tipleri ve yayınlama veya durdurma eşiği. “Yüksek riskli hataları artırmadan manuel inceleme süresini %20 azaltmak” gibi bir hedef, “F1 skorunu iyileştir” demekten çok daha kullanışlıdır.

Tahminde bulunmadan bir ML özelliğinin kapsamını belirleme

Modelden değil kullanıcının işinden başlayın. İyi bir kapsam, bir soru ile başlar: insanlar neyi başarmaya çalışıyor ve bugün onları ne yavaşlatıyor? Özelliğin iş akışındaki tam anı tarif edemiyorsanız, hâlâ “makale modundasınız”, ürün modunda değilsiniz.

Daphne Koller ML ürün derslerinden yararlı bir çerçeve, özelliği kullanıcının rolüyle tanımlamaktır. İşten onlara iş alıyor mu (otomasyon), işi daha iyi yapmalarına yardım ediyor mu (yardımcı), yoksa kabul edip reddedebilecekleri bir öneri mi sunuyor (karar desteği)? Bu seçim UI'ı, metriği, kabul edilebilir hata oranını ve hataları nasıl yöneteceğinizi şekillendirir.

Bir şey inşa etmeden önce UI sözünü tek cümleyle yazın. Bu cümlenin özelliğin en kötü gününde bile doğru olması gerekir. “Düzenleyebileceğiniz ilk taslağı hazırlar” “Nihai cevabı yazar”dan daha güvenlidir. Sözün doğru olması için çok fazla koşula ihtiyacınız varsa, kapsam çok büyüktür.

Kısıtlamalar gerçek kapsamdır. Bunları açıkça yazın.

Basit bir kapsam belirleme şablonu

Bu beş satır netleşene kadar ilerlemeyin:

• Kullanıcı işi: belirli görev ve ne zaman gerçekleştiği
• Özellik rolü: otomasyon, yardımcı veya karar desteği
• Tek cümlelik söz: UI'nın neyi garanti ettiğinin kısa ifadesi
• Kısıtlamalar: gecikme, istek başına maliyet, gizlilik ve verinin nerede tutulabileceği
• Hata toleransı: yanlış veya belirsiz olduğunda ne olacağı

Örnek: vibe-coding tarzı bir araç olan Koder.ai içinde bir “AI şema yardımcısı” ekliyorsunuz diyelim. Kullanıcı işi “Hızla bir veritabanı tablosuna ihtiyacım var ki geliştirmeye devam edebileyim.” Eğer bunu yardımcı olarak kapsamlayorsanız, söz şu olabilir: “İnceleyip uygulayabileceğiniz bir tablo şeması önerir.” Bu hemen koruyucuları ima eder: değişiklikleri uygulamadan önce farkı göster, geri alma izin ver, ve karmaşık muhakemeden çok hızlı yanıtları tercih et.

İlk sürümü değeri yaratan en küçük eylemin etrafında gönderin. Henüz desteklemeyeceğiniz şeyleri (diller, veri türleri, çok uzun girdiler, yüksek trafik) kararlı bir şekilde belirleyin ve UI'da görünür yapın. Bu, kullanıcıları modelin hata modlarının sorumluluğuna bırakmamanın yoludur.

Gerçek kullanıcı değerine uyan metrikleri seçmek

İyi bir ML metriği, iyi bir ürün metriği ile aynı değildir. Aradaki farkı görmek için en hızlı yol: bu sayı artarsa gerçek bir kullanıcı fark edip memnun olur mu diye sormaktır? Eğer hayırsa, muhtemelen laboratuvar metriğidir.

Daphne Koller ML ürün derslerinden güvenilir bir alışkanlık, lansmandan sonra ölçülebilen kullanıcı değerine bağlı bir birincil başarı metriği seçmektir. Diğer her şey onu desteklemeli, onunla rekabet etmemelidir.

Basit bir metrik yığını

Bir birincil metrikle başlayın, sonra küçük bir koruyucu set ekleyin:

• Birincil başarı metriği: kullanıcıların istediği çıktı (görev tamamlama oranı, doğru cevaba ulaşma süresi, oturumların % kaçında “bu yardımcı oldu” gibi)
• Koruyucu metrikler: kullanıcıların zarar görmesini engelleyen ölçüler (zararlı öneri oranı, şikayet oranı, yüksek etki hatası oranı)
• Maliyet ve gecikme: yanıt süresi ve istek başına maliyet, çünkü yavaş veya pahalı AI hızla kullanılamaz hale gelir

Koruyucular kullanıcıların gerçekten hissettiği hatalara odaklanmalıdır. Düşük riskli vakalarda küçük bir doğruluk düşüşü sorun olmayabilir, ancak yüksek riskli bir anda bir tane emin yanlış cevap güveni bozar.

Çevrimdışı metrikler (accuracy, F1, BLEU, ROUGE) hâlâ yararlıdır, ama onları tarama araçları olarak ele alın. Çevrimiçi metrikler (dönüşüm, tutunma, destek talepleri, iadeler, yeniden çalışma süresi) özelliğin üründe yeri olup olmadığını söyler.

İkisini bağlamak için, model çıktısını bir eyleme eşleyen bir karar eşiği tanımlayın ve sonra o eylemi ölçün. Model cevap öneriyorsa, kullanıcıların ne sıklıkla kabul ettiğini, yoğun şekilde düzenlediğini veya reddettiğini izleyin.

Temeli atlamayın. Yenmeniz gereken bir şey olmalı: kural tabanlı bir sistem, bir şablon kütüphanesi veya mevcut insan iş akışı. Eğer AI sadece temeli yakalıyor ama kafa karışıklığı ekliyorsa, net kayıp olur.

Örnek: müşteri sohbetleri için AI özeti gönderirsiniz. Çevrimdışı, özetler ROUGE üzerinde iyi puan alır. Çevrimiçi, ajanlar karmaşık vakalarda özetleri düzeltmek için daha uzun zaman harcar. Daha iyi bir birincil metrik “AI özeti olan sohbetlerde ortalama işlem süresi” olabilir; koruyucular olarak haftalık denetlenen “kritik eksiklik içeren özetlerin %si” ve “kullanıcı tarafından bildirilen yanlış özet” oranı gibi metrikler eklenir.

Adım adım: bir ML fikrini dağıtıma uygun bir sisteme dönüştürmek

Bir araştırma sonucu, gönderebildiğiniz, ölçebildiğiniz ve destekleyebildiğinizde ürüne dönüşür. Pratik versiyon genellikle makale versiyonundan daha küçük ve daha kısıtlıdır.

1) MVP dilimini tanımlayın

Kabul edebileceğiniz en küçük girdiden ve yine de yardımcı olan en basit çıktısından başlayın.

“Her tür belgeyi özetle” demek yerine “1.000 kelimenin altındaki destek biletlerini 3 madde halinde özetle” ile başlayın. Daha az format daha az sürpriz demektir.

2) Hangi verilere ihtiyacınız olduğunu kararlaştırın

Zaten neye sahip olduğunuzu, güvenli bir şekilde neleri kaydedebileceğinizi ve amaçlı olarak ne toplamanız gerektiğini yazın. Birçok fikir burada takılır.

Yeterli gerçek örneğiniz yoksa, hafif bir toplama aşaması planlayın: kullanıcılara çıktıyı puanlatma veya “yararlı/yararsız” olarak işaretleme ve kısa bir sebep alma imkanı verin. Topladığınız şeyin geliştirmek istediğiniz hedefle eşleştiğinden emin olun.

3) Erken bir değerlendirme yöntemi seçin

En büyük hataları yakalayacak en ucuz değerlendirmeyi seçin. Bir ayrılmış set, net kurallarla hızlı insan incelemesi veya bir koruyucu metrikli A/B testi işe yarayabilir. Tek bir sayıya güvenmeyin; bir kalite sinyalini güvenlik veya hata sinyaliyle eşleştirin.

4) Yayını bir deney gibi planlayın

Aşamalar halinde yayınlayın: dahili kullanım, küçük bir kullanıcı grubu, sonra daha geniş dağıtım. Sıkı bir geri bildirim döngüsü tutun: hataları kaydedin, haftalık örnek inceleyin ve küçük düzeltmeler gönderin.

Araçlarınız anlık görüntüleme ve geri alma destekliyorsa, bunları kullanın. Hızlı geri alma imkanı yinelemeyi ne kadar güvenli yapabileceğinizi değiştirir.

5) Net durdurma kurallarıyla yineleyin

“Genişletmeye hazır”ın ne anlama geldiğini ve neyin durdurma tetikleyicisi olduğunu önceden belirleyin. Örneğin: “Yardım seviyesi %70'in üzerinde ve şiddetli hatalar %1'in altında iki hafta boyunca” gibi. Bu, bitmeyen tartışmaları önler ve veremeyeceğiniz sözlerden kaçınır.

Kullanıcıya yönelik AI uygulamalarında beklentileri ayarlamak

Kullanıcılar modelinizi en iyi cevaplarına göre yargılamaz. Resmî görünen uygulamada kendinden emin bir şekilde yanlış yaptığında karar verirler. Beklenti ayarlamak bir ürün parçasıdır; sadece bir feragatname değildir.

Mutlak ifadeler yerine aralıklarla konuşun. “Bu doğru” demek yerine “X için genellikle doğru” ve “Y için daha az güvenilir” deyin. Mümkünse güveni basit dilde göstermek (yüksek, orta, düşük) ve her seviyeyi kullanıcının sonraki adımıyla ilişkilendirmek faydalıdır.

Sistemin ne için olduğunu ve ne için olmadığını açıkça belirtin. Çıktının yanında kısa bir sınır kullanımı yanlış yönlendirmeyi önler: “Taslak hazırlama ve özetleme için harika. Hukuki tavsiye veya nihai kararlar için değil.”

Belirsizlik işaretleri görünür ve eyleme geçirilebilir olduğunda en iyi şekilde çalışır. Kullanıcılar AI'nın neden böyle cevap verdiğini görebildiklerinde ya da uygulamanın kontrol gerektiğini kabul ettiğinde daha hoşgörülüdür.

Kullanıcıların anladığı pratik belirsizlik işaretleri

Bir veya iki işareti seçin ve tutarlı kullanın:

• Kısa bir neden (hangi girdileri kullandığı)
• Cevap belgelerle bağlıysa atıflar veya kaynak parçacıkları
• Güven düşükse “İnceleme gerektirir” gibi basit bir etiket
• Girdi belirsizse iki seçenek gösterme

Günden bir yedekleme için tasarlayın. AI emin olmadığında ürün yine de kullanıcının görevi bitirmesine izin vermelidir: manuel bir form, insan inceleme adımı veya daha basit kural tabanlı bir akış.

Örnek: bir destek yanıt asistanı otomatik göndermemelidir. Taslak üretmeli ve riskli bölümleri (iade, politika sözleri) “İnceleme gerektirir” olarak vurgulamalıdır. Güven düşükse bir şey tahmin etmek yerine bir takip sorusu sormalıdır.

Aşırı vaat ve müşteri kaybına yol açan yaygın tuzaklar

Kullanıcılar model kusurlu olduğu için ayrılmaz. Uygulama kendinden emin görünüp, güveni kıran hatalar yaptığında ayrılırlar. Birçok Daphne Koller ML ürün dersi buraya gelir: iş yalnızca bir model eğitmek değil, gerçek kullanım altında güvenli davranan bir sistem tasarlamaktır.

Yaygın tuzaklar şunlardır: benchmark'a aşırı uyum (ürün verileri veri kümesine benzemiyor), izleme veya geri alma olmadan gönderme (küçük güncellemeler kullanıcıların iki günlük acısına dönüşür), gündelik uç durumları göz ardı etme (kısa sorgular, dağınık girdiler, karışık diller), tek bir modelin her segment için uygun olduğunu varsayma (yeni kullanıcılar vs ileri kullanıcılar farklı davranır), ve “insan seviyesi” performans vaat etme (kullanıcılar kendinden emin hataları hatırlar).

Bu hatalar genellikle “ML olmayan” ürün kararlarının atlanmasından kaynaklanır: modelin ne yapmasına izin verildiği, ne zaman reddetmesi gerektiği, güven düşük olduğunda ne olacağı ve insanların bunu nasıl düzeltebileceği. Bu sınırları tanımlamazsanız, pazarlama ve UI onlar için sınır çizer.

Basit bir senaryo: müşteri desteğine AI otomatik yanıt özelliği eklediniz. Çevrimdışı testler harika görünüyor, ama gerçek biletler kızgın mesajlar, eksik sipariş numaraları ve uzun konular içerir. İzleme yoksa, bir model değişikliğinden sonra yanıtların daha kısa ve daha genel hale geldiğini kaçırırsınız. Geri alma yoksa ekip iki gün tartışırken ajanlar özelliği manuel kapatır. Kullanıcılar önemli detayları kaçıran kendinden emin yanıtlar görür ve iyi olan AI önerilerine bile güvenmeyi bırakır.

Çözüm nadiren “daha çok eğitim”dir. Kapsam konusunda kesin olmak, kullanıcı zararını yansıtan metrikler seçmek (kendinden emin yanlış cevaplar güveni güvenli refusallardan daha hızlı bozar) ve operasyonel güvenlik inşa etmek (uyarılar, kademeli sürümler, snapshotlar, geri alma) gerektirir.

Örnek senaryo: insanların güvenebileceği bir AI özelliği göndermek

Müşteri destek triyajı, Daphne Koller ML ürün derslerini uygulamak için gerçekçi bir yerdir. Amaç “AI ile desteği çözmek” değil. Amaç insanın bir bileti doğru yere yönlendirmesi için harcadığı zamanı azaltmaktır.

Küçük, dürüst bir söz tanımlayın

Bir dar şeyi taahhüt edin: yeni bir bilet geldiğinde sistem kategori (fatura, hata, özellik isteği) ve öncelik (düşük, normal, acil) önerir. Bir insan bunu onaylar veya düzenler; sistem bunu otomatik olarak yönlendirmede kullanmaz.

Sözcük seçimi önemlidir. “Önerir” ve “ajan onaylar” ifadeleri doğru beklentiyi koyar ve erken hataların müşteri yüzüne çıkmasını engeller.

İşe uygun metrikleri seçin

Çevrimdışı doğruluk yardımcı olur ama skor tahtası değildir. Gerçek işi yansıtan sonuçları izleyin: ilk yanıt süresi, yeniden atama oranı, ajanın geçersiz kılma oranı ve kullanıcı memnuniyeti (CSAT). Aynı zamanda modelin etiketlediği acil biletler için işlem süresinin uzaması gibi “sessiz başarısızlık” sinyallerini izleyin.

Mükemmellik yerine hataya göre tasarlayın

Tek cevap yerine en iyi 3 kategori önerisini basit bir güven etiketiyle gösterin (yüksek, orta, düşük). Güven düşükse “inceleme gerektirir”e varsayılan yapın ve açık bir insan seçimi zorunlu kılın.

Ajanlar geçersiz kıldığında hızlı bir neden kodu verin (yanlış ürün alanı, eksik bağlam, müşteri kızgın). Bu nedenler eğitim verisi olur ve sistematik boşlukları gösterir.

Sürpriz olmadan yayınlayın

Küçük başlayın ve sadece metrikler doğru yönde ilerlediğinde genişletin. Bir ekibe eski iş akışını yedek olarak sunun. Haftalık örnek incelemeyle tekrarlayan hataları tespit edin. Etiketleri ve UI yazılarını yeniden eğitmeden önce ayarlayın. Model güncellemesinden sonra geçersiz kılma oranı patladığında uyarı ekleyin.

Bu özelliği Koder.ai gibi bir platformda inşa ediyorsanız, promptları, kuralları ve UI metinlerini ürünün parçası olarak görün. Güven tam sistemden gelir, sadece modelden değil.

Yayınlamadan önce hızlı kontrol listesi

Kullanıcıya yönelik bir ML özelliğini yayınlamadan önce, vaadettiğinizin en basit versiyonunu yazın. Çoğu Daphne Koller ML ürün dersi, değere özgül olma, sınırlara dürüst olma ve gerçeğe hazır olma konusunda özetlenir.

Yayın öncesi kontrol edin:

• Kullanıcı sözü (tek cümle): Özellik ne yapacak ve ne zaman? Test edilebilir olsun.
• Temel ve hedef iyileştirme: ML olmadan bugün ne oluyor ve hangi sayı anlamlı bir gelişme olur?
• Model yanlış veya belirsiz olduğunda: Hata davranışını tanımlayın (güven ipucu, açıklayıcı soru, kural yedeği veya özelliği gizleme). Güvensiz çıktıyı nelerin engelleyeceğini tanımlayın.
• Haftalık başarı sinyali: Haftalık kolayca gözden geçirilir 1-2 ölçü seçin (tercihli kullanım, tekrar kullanım, tamamlama oranı, kaydetme oranı, şikayet oranı, geri alma oranı).
• İzleme, geri alma, sahiplik: Kalitenin kimden sorumlu olduğunu, kimin uyarıldığını ve değişiklikleri hızla nasıl geri alacağınızı bilin.

Eğer tek bir ekstra şey yapacaksanız, gerçek kullanıcılarla küçük bir sürüm çalıştırın, en sık 20 hatayı toplayın ve etiketleyin. Bu hatalar genellikle kapsamı, UI'yı veya vaadi ayarlamanız gerektiğini söyler; sadece modeli değil.

Fikirlerden gönderime geçmek için pratik bir plan

İki dakikada okunabilecek bir tek sayfa spes ile başlayın. Basit dil kullanın ve kullanıcının güvenebileceği bir söze odaklanın.

Dört şeyi yazın: kullanıcı sözü, girdiler (ve nelerin kullanılmaması gerektiği), çıktılar (belirsizlik veya reddetmeyi nasıl gösterdiği dahil) ve sınırlar (beklenen hata modları ve henüz desteklemeyeceğiniz şeyler).

Metrikleri ve koruyucuları inşa etmeden önce seçin. Bir metrik kullanıcı değerini yansıtmalı (görev tamamlama, daha az düzenleme, tasarruf edilen zaman). Bir diğeri kullanıcıyı korumalı (gerçekçi test setinde halisünasyon oranı, politika ihlali oranı, engellenen tehlikeli eylem denemeleri). Sadece doğruluk izlerseniz, müşteri kaybına neden olan etkenleri kaçırırsınız.

Sonra riske uygun bir MVP dağıtımı seçin: dağınık bir test setinde çevrimdışı değerlendirme, gölge mod, kolay geri bildirim düğmesine sahip sınırlı beta ve öldürme anahtarı ile kademeli dağıtım.

Canlıya geçtiğinde, izleme özelliğin parçasıdır. Temel metrikleri günlük izleyin ve kötü davranışta artış olduğunda uyarı verin. Prompt ve model sürümlerini saklayın, çalışan durumların snapshotlarını alın ve geri almayı rutin hale getirin.

Daha hızlı prototip yapmak isterseniz, sohbet tabanlı bir oluşturma akışı ürün şeklini erken doğrulamanıza yardımcı olabilir. Örneğin Koder.ai üzerinde, özelliğiniz etrafında küçük bir uygulama oluşturabilir, seçtiğiniz metrikler için temel izleme ekleyebilir ve kullanıcı sözü üzerinde yineleme yaparken hız kazanabilirsiniz. Hız fayda sağlar, ama disiplini korumanız gerekir: sadece metrikleriniz ve koruyucularınız destekleyebildiği şeyi gönderin.

Son bir test: Özelliğin nasıl davrandığını, yanlış olabileceği zaman dahil olmak üzere bir paragrafta bir kullanıcıya açıklayabiliyor musunuz? Eğer açıklayamıyorsanız, demo ne kadar iyi görünürse görünsün, gönderilmeye hazır değildir.