Bir kullanıcı “düğmeye bastım ama olmadı” dediğinde ekip hemen çözüm arayabilir. Oysa bu cümle, hangi ekranda ve koşulda işlem yapıldığını, ne beklendiğini ve ne görüldüğünü tek başına açıklamaz. Yapay zekâdan doğrudan neden veya düzeltme istemek boşlukları tahminle doldurabilir. Bu rehber, serbest anlatımı geliştiricinin inceleyebileceği bir sorun kaydına dönüştürmek için sınırlı bir talimat akışı kurar. Çıktı teşhis değildir: bildirilen bilgi, eksik bilgi ve insanın doğrulayacağı adımlar ayrı tutulur.

Hata çözümünden önce bildirim kaydını yapılandırın

Bir sorun bildirimi ile teknik inceleme aynı iş değildir. Bildirim, kişinin gördüğünü ve yaptığı işlemi kayda geçirir. Teknik inceleme ise kodu, kayıtları, ortamı ve olası nedenleri araştırır. Talimat yalnız ilk parçaya yardım etmelidir. “Ödeme başarısız” ifadesinden kart sağlayıcısını, sunucu nedenini veya çözümü çıkarmasına izin verilmez. Kayıtta yalnız kaynak metinde bulunan gerçekler yer alır; çıkarımlar ayrı bir “doğrulanmadı” alanında ve gerekçesiyle gösterilir.

Benzer biçimde bu çalışma, kabul sınaması senaryosu hazırlamak değildir. Kabul sınaması önceden belirlenmiş bir beklentinin karşılanıp karşılanmadığını kontrol eder. Buradaki girdi ise çoğu zaman henüz sınanabilir olmayan, gerçek bir kişinin kısa ve eksik anlatımıdır. Amaç anlatıyı kesip atmak değil, kişinin kullandığı dili korurken araştırmaya yarayan parçaları görünür kılmaktır.

Kaynak anlatımı değiştirmeden saklayın

İlk alan bildirimin aslına sadık metni veya işletmenin onayladığı kimliksiz özettir. Yazım yanlışı, günlük dil ve belirsizlik kişi söylemiş gibi düzeltilmemelidir. Tarafsız özet kaynakla birlikte tutulur; geliştirici yorum farkını görebilir. Ekran görüntüsü ya da dosya varsa talimat yalnız adını ve erişim bilgisini taşır; görülmeyen kanıt içeriğini anlatmaz.

Gereksiz kişisel bilgi, parola, erişim belirteci veya ödeme ayrıntısını talimata eklemeyin. Bu verilerin işlenmesi için uygunluk, kullanılan hesap ve araç koşulları işletmece ayrıca değerlendirilmelidir. Kimliksizleştirilmiş bir özet bile bağlamdan kişiyi belirleyebilecek bilgi içerebilir. İç kullanımda olduğu için her metnin paylaşılabilir olduğunu varsaymayın. İhtiyaç duyulan en az bilgiyi yetkili kaynaktan sağlayın; güvenli olduğuna dair evrensel bir garanti vermeyin.

Çıktı alanlarını araştırma sırasına göre belirleyin

Hazır örnek talimat: “Aşağıdaki bildirimi, yalnızca verilen kaynağa dayanarak sorun kaydı taslağına dönüştür. Alanları şu sırayla yaz: bildirilen davranış; ekran veya iş adımı; ortam; başlangıç koşulu; kişinin anlattığı adımlar; bildirilen beklenti; gözlenen sonuç; tekrar bilgisi; kanıt referansı; bilinmeyenler. Her alanı kaynaktaki ifadeye bağla. Bilinmeyeni tahmin etme; eksikse ‘belirtilmemiş’ yaz ve gerekiyorsa kısa bir soru öner. Beklenen davranışı onaylı gereksinim gibi sunma. Kök neden veya çözüm çıkarma. Kişi, hesap, parola veya ödeme verisi ekleme. Sonucu insan incelemesine sun; yeniden üretildiğini veya düzeltildiğini söyleme.” Bu taslak her işletmenin kendi erişim ve paylaşım koşullarına göre gözden geçirilmelidir.

“Beklenen” ve “gözlenen” ayrımına dikkat edin. Kişi “kaydetmek istedim” diyorsa bu, sistemin hangi sonucu vermesi gerektiğinin resmî gereksinimi olmayabilir. Kayıt, kullanıcının beklentisini “bildirilen beklenti” olarak aktarır; onaylı gereksinim varsa ayrı kaynağa bağlar. “Gözlenen” alanda ise yalnız kişinin gördüğü sonuç bulunur. Bu iki alan birleştirilirse yorum, kanıt gibi görünebilir.

Adımlar kısa, numaralı ve yalnız bildirilen sırada tutulabilir: hangi sayfaya gelindi, hangi işlem yapıldı, ardından ne görüldü? Eksik sıra parçalarını eklemek gerekirse bunlar tamamlanmış gerçekler değil, sorulacak açıklama soruları olarak yazılır. Örneğin “Hata oluşmadan önce oturum kapandı mı?” sorusu, kullanıcının oturumunun kapandığı iddiasına dönüştürülmemelidir. Kayıt hem araştırmayı başlatmalı hem de bilinmeyenin sınırını korumalıdır.

Tek bir örnekle sınırı görünür kılın

Serbest bildirim şu olsun: “Ürün sayfasında iki seçenek arasında geçtim; ekle dedikten sonra aynı ürün yeniden geldi.” Yapay zekâ, kaynakta yazmayan cihazı, tarayıcıyı, stok durumunu veya hatanın her seferinde oluştuğunu eklememelidir. Tarafsız özet şöyle olabilir: “Kullanıcı, ürün sayfasında iki seçenek arasında geçiş yaptıktan sonra ekle işlemiyle ilgili aynı ürünün yeniden göründüğünü bildirdi.” Bu ifade, işlemin nereye yapıldığını veya ürünün hangi alanda tekrar belirdiğini varsaymaz. Kayıt şu soruları önerebilir: “Hangi kontrolü kullandınız? Ekle işleminden sonra ürün nerede yeniden göründü? O sırada hangi seçenek görünüyordu?” Yanıt gelene kadar işlem yeri ve seçili seçenek bilinmeyen kalır. Kaynakta olmayan ayrıntılar alan olarak boş veya soru olarak tutulur.

Bir insan daha sonra bildirimi yapan kişiye uygun kanaldan açıklayıcı soru sorabilir; gerekiyorsa yetkili sınama ortamında aynı yolu deneyebilir. Bu iki eylem farklıdır. Talimatın oluşturduğu kayıt, yeniden üretildiğini veya yazılım hatasının doğrulandığını göstermez. Tek bir örnekte sonucu görebilmek, problemin bütün kullanıcılarda bulunduğunu kanıtlamaz. İnceleme sonucu geldikçe kayıt güncellenir ve yeni bilgi kimin tarafından, hangi kanıtla eklendiği anlaşılır biçimde tutulur.

Belirsizliği karar değil, soru olarak gösterin

İyi bir taslak, her alanı doldurmak yerine yeterli bilgi bulunmayan noktaları gruplar. Sorular, araştırmanın sırasını kolaylaştıracak şekilde seçilebilir: hangi sayfa veya kayıt kullanıldı; işlemden önce hangi durum vardı; beklenen sonuç nereden biliniyor; sorun yeniden görüldü mü; kanıtın kaynağı nedir? Birden çok soruyu tek seferde göndermek yerine, önce karar için gerekli olanları sorun. Kullanıcıdan gereksiz teknik uzmanlık istemeyin. Kendisinin gözleyebileceği şeyle yalnız teknik ekip tarafından doğrulanabilecek şeyi ayırın.

İki olasılık birden makul görünüyorsa talimat birini seçmemelidir. “Tarayıcı sorunu”, “kullanıcı hatası” veya “entegrasyon arızası” gibi neden etiketleri, inceleme başlamadan önce dosyayı yanlış yöne çekebilir. Bunun yerine “kaynağa göre belirlenemiyor” yazıp hangi kanıtın eksik olduğunu belirtin. Ürün, veri veya hesap durumu hakkında yetkili bir kaynak gerekiyorsa bunu ilgili insana bırakın. Muğlaklığı saklamayan bir kayıt, iddialı ama dayanaksız kök neden cümlesinden daha güvenilirdir.

Küçük denemeyi hem açık hem karşıt örneklerle sınayın

Talimatı gerçek müşteri kayıtlarına uygulamadan önce işletmenin oluşturduğu kimliksiz örneklerle deneyin. Açık, eksik, çelişkili ve teknik sorun olmayan örnekler seçilebilir. Her örnek için beklenen alanları ve doldurulmaması gerekenleri önceden yazın. Sonra çıktının kaynağı doğru koruyup korumadığını, beklentiyle gözlemi karıştırıp karıştırmadığını, olmayan ayrıntı ekleyip eklemediğini inceleyin. Bu örnekler yalnız hazırlanan senaryolarda davranışı gösterir; genel doğruluk kanıtı değildir.

Sınama notunda her farkı “kaynakta var”, “özet doğru”, “çıkarım eklendi”, “bilinmeyen yanlış dolduruldu” veya “açıklama sorusu eksik” gibi anlaşılır şekilde kaydedin. Aynı talimatı küçük bir düzenle değiştirdiğinizde önceki örnekleri yeniden çalıştırın. Başarılı bir çıktı biçimi, gerçek sorunun çözüldüğü anlamına gelmez. İnsan incelemesi olmadan kaydın otomatik olarak görev açması, bir kişiye atanması veya kullanıcıya yanıt göndermesi bu kapsamın dışındadır.

Kanıt ve gizlilik sınırını koruyun

Kanıt alanı dosya adı, kayıt numarası veya erişilebilir iç bağlantı taşıyabilir; bağlantının içeriği görülmediyse model onu biliyormuş gibi yazmamalıdır. Ekran görüntüsünden gereksiz kişisel bilgiler çıkarılmalıdır. Hangi kanıtın gerekli olduğu, kaydın nerede ve kimlerce tutulacağı işletmenin kendi koşullarına göre belirlenir; bu yazı saklama veya hukuki uygunluk garantisi vermez.

Birden çok bildirim aynı olayı anlatıyor olabilir. Talimat benzer cümleleri görse bile bunları otomatik birleştirmemelidir; aynı görünen belirtiler farklı hesap, sürüm veya koşullardan kaynaklanabilir. İnsan, ilişki kurmak için yeterli ortak kanıt olup olmadığını inceler. Her bildirime bir referans verilmesi, sonradan aynı olaya bağlanırsa bu bağın açıklanmasını kolaylaştırır. Fakat otomatik birleştirme veya silme kuralı eklemek, ilk taslağın sınırını aşar.

Kayıt başka teknik çalışmalara ne zaman bağlanır?

Bir sorun kaydı hazırlandıktan sonra teknik ekip gözlem verisini inceleyebilir; ancak bu ayrı bir araştırma aşamasıdır. Hata mesajından neden analizine uzanan gözlemlenebilirlik rehberi kayıt, ölçüm ve işlem izlerini araştırma bağlamında ele alır. Buradaki talimat bu verileri çözümlemez. Benzer şekilde yazılım teslimini kabul senaryolarıyla değerlendirme önceden tanımlanmış beklentileri sınar; bildirimden gereksinim uydurmaz.

Denetim izi rehberi iş kayıtlarındaki değişikliğin kim, ne ve neden boyutlarını açıklar. Sorun bildirimi ise bir olayın belirtilerini yapılandırır ve kendi başına yetki, değişiklik kararı ya da kapanış kaydı değildir. Bu iş akışını bir yapay zekâ talimatı ve insan incelemesiyle sınamak isteyenler, Dijital Pazarlama hizmeti sayfasından kapsam, kaynak, kontrol ve teslim biçimini görüşmeye hazırlayabilir. Sağlayıcının ne sunacağı ayrıca netleştirilmelidir; belirli teknik sonuç veya yerel ofis varsayılmamaktadır.

Sık Sorulan Sorular

Bu talimat teknik ekibin yerine hata teşhisi yapar mı?

Hayır. Görevi, bildirilen anlatımı alanlara ayırmak ve eksik bilgiyi görünür kılmaktır. Kod, sunucu kaydı, sürüm veya harici hizmet incelenmeden kök neden belirlenmiş sayılmaz. Teknik ekip, yapılandırılmış bildirimi araştırmaya başlama noktası olarak kullanabilir; tanı ve düzeltme sorumluluğu insan incelemesinde kalır. Çıktının “doğrulandı” gibi sunulmaması için ekip yönergesi ve süreç notlarında bu sınır açıkça yazılmalıdır.

Eksik işletim sistemi ya da sürüm bilgisi nasıl gösterilmeli?

Kaynakta yoksa “bilinmiyor” veya “sorulmalı” olarak bırakılmalıdır. Yaygın bir cihaz veya güncel sürüm tahmin ederek doldurulmamalıdır. Bu bilgi araştırma için gerekli görünüyorsa, kullanıcının kolayca yanıtlayabileceği tek bir açıklama sorusu hazırlayın. Gerekli değilse yalnız form tamam olsun diye istemeyin. Boş alan, yanlış bir kesinlikten daha dürüst bir kayıttır.

Beklenen davranış ile kullanıcının beklentisi aynı şey midir?

Her zaman değil. Kullanıcının “kaydedilmesini bekliyordum” demesi, onaylı iş gereksiniminin tam ifadesi olmayabilir. Kayıtta “bildirilen beklenti” ayrı tutulmalı, doğrulanmış gereksinim varsa kaynağı belirtilmelidir. Böylece kişisel beklenti sistemin taahhüdü gibi görünmez. Gereksinim kaynağı bulunamıyorsa bu konu sorumlu kişiye yöneltilir; talimat kendi başına hüküm vermez.

Yapay zekâ adımları daha anlaşılır olsun diye tamamlayabilir mi?

Hayır; yalnızca kullanıcının anlattığı sırayı sade ve numaralı biçimde düzenleyebilir. Arada olası görünen bir tıklama veya ekran eklememelidir. Sıra eksikse “hangi sayfadan sonra oldu?” gibi soru üretmesi yeterlidir. Bu ayrım özellikle tekrar denemesinde önemlidir: kurgulanmış bir adım, olay gerçekten öyle yaşanmış gibi kayda girmemelidir.

Tek bir deneme başarılı olursa talimatı kullanıma alabilir miyiz?

Tek başarılı örnek, farklı anlatımların doğru işlendiğini göstermez. Açık, eksik, çelişkili ve konu dışı kayıtları da deneyin; yanlış çıkarım ve hatalı kesinlikleri özellikle arayın. İşletme, kullanım alanını ve insan kontrolünü belirlemelidir. Deneme sonucu yalnız incelenen örneklerle sınırlı raporlanmalı, bütün bildirimlerde doğruluk veya hata oranı garantisi olarak sunulmamalıdır.

Gerçek kullanıcı metnini dışarıdaki bir araca vermek gerekir mi?

Gerekli olduğu varsayılmamalıdır. İlk deneme sentetik veya uygun biçimde kimliksizleştirilmiş örneklerle yapılabilir. Gerçek veri düşünülüyorsa, hangi hesap ve hizmet koşullarının geçerli olduğu, kimin erişeceği ve paylaşımın işletmece uygun bulunup bulunmadığı ayrıca değerlendirilmelidir. Kimlik bilgileri, parola ve benzeri sırları talimata eklemeyin. Her sağlayıcı ve hesap türü için tek bir veri işleme kuralı varmış gibi yazmayın.

Bir bildirimde iki farklı arıza anlatılıyorsa ne yapılmalı?

İki belirti ayrı kayıt adayları olarak gösterilebilir, fakat aynı olaya bağlı oldukları varsayılmamalıdır. Her birinin bildirilen adımları ve gözlenen sonucu ayrıştırılır; aralarındaki ilişki bilinmiyorsa “bağlantı doğrulanmadı” denir. İnsan incelemesi, aynı olay olup olmadığını değerlendirir. Talimat otomatik birleştirme, öncelik sıralaması veya ekip ataması yapmaz.

Bu çıktı hata kaydının kapandığını gösterir mi?

Hayır. Yapılandırılmış bildirim, inceleme ve düzeltme öncesindeki bir hazırlık kaydıdır. Teknik ekip yeniden üretme, araştırma, değişiklik ve kontrol adımlarını kendi sürecinde yürütür. Sonuç doğrulandığında kayıt yetkili kişi tarafından güncellenebilir. İlk talimat çıktısına “çözüldü” veya “kapatıldı” durumu eklemek, yapılmamış bir kontrolü tamamlanmış gibi göstereceğinden kullanılmamalıdır.