Android otomasyonu geliştirirken ekipler genellikle Codex veya Claude gibi yapay zeka asistanlarından yardım alıyor. Ancak 'uygulamayı aç, giriş yap, sonucu kontrol et, ekran görüntüsü al, metin eksikse dur' gibi doğal dil talimatları, gerçek bir cihazda çalışacak iş akışı oluşturmak için yetersiz kalıyor. İşte bu noktada devreye bağlam sözleşmesi (context contract) giriyor. Bağlam sözleşmesi, yapay zeka asistanının bir Android otomasyon profili oluşturmadan önce okuması gereken minimum bilgi kümesini tanımlar: hedef ortam, bağlı cihazlar, uygulama paketi, mevcut ekran, düğüm şeması, görsel varlıklar, kanıt politikası, kaydetme politikası ve durma sınırları. Bu sözleşme olmadan asistan tahmin yürütmek zorunda kalır ve mobil otomasyonda tahmin, hatalı iş akışlarının başlangıcıdır.
Bağlam sözleşmesinin önemi, Android otomasyonunun çok sayıda çalışma zamanı detayı içermesinden kaynaklanır. Bir model 'giriş yap'ın ne anlama geldiğini bilir ancak uygulamanın staging, production, emülatör veya özel test derlemesi olduğunu bilmez; sistem söylemediği sürece bilemez. Ayrıca OCR'nin metni doğrulayabildiğini bilir ancak hangi OCR bölgesinin kararlı olduğunu bilmez; mevcut ekran ve düzen bilgisi olmadan bilemez. Bir düğmeye dokunmak için koordinat seçmek yerine UI ağacı hedefi veya görsel kontrol daha güvenliyken, model bunu bilemez. İşte bu nedenle Model Bağlam Protokolü (MCP), yapay zeka destekli iş akışı oluşturma için kritik öneme sahiptir. MCP, asistanın yerel sistemden araçlar ve yapılandırılmış bağlam istemesine olanak tanır. İyi bir LaiCai MCP iş akışı, oluşturma bağlamı, düğüm şeması, varlıklar, profiller, cihazlar, paketler, ekran görüntüleri, UI ağacı verileri ve son çalışma durumunu taslak oluşturmadan önce kullanılabilir hale getirmelidir. Amaç modele sınırsız güç vermek değil, gizli varsayımları azaltmaktır: önce bağlam okunur, sonra taslak, ardından inceleme ve en son çalıştırma.
Oluşturma öncesi minimum girdiler beş başlıkta toplanır. İlk girdi kullanıcı hedefidir; görevi, ortamı, hesap türünü, beklenen kanıtı ve durma noktasını adlandırmalıdır. 'Staging'de test hesabı kullan ve ödeme öncesi dur' ifadesi, 'ürünü satın al'dan çok daha güvenlidir. İkinci girdi düğüm şemasıdır; mevcut LaiCai Flow şeması bir düğümü desteklemiyorsa asistan onu icat etmemelidir. Taslak, geçerli düğüm türlerinden, geçerli girdi adlarından ve bilinen çıktı değerlerinden oluşturulmalıdır. Üçüncü girdi cihaz bağlamıdır; asistan hangi cihazların veya emülatörlerin bağlı olduğunu, ön plandaki uygulamayı, hangi paketlerin yüklü olduğunu ve hangi ekran kanıtlarının mevcut olduğunu bilmelidir. Paket adı eksikse asistan sormalı veya cihaz paket listesini okumalı, ürün adından tahmin yürütmemelidir. Dördüncü girdi varlık bağlamıdır; şablonlar, OCR bölgeleri, görüntü modelleri, betikler ve ekran görüntüleri soyut süslemeler değil, çalışma zamanı bağımlılıklarıdır. Bir taslak görüntü şablonu kullanıyorsa şablon var olmalıdır; sabit bir OCR bölgesi öneriliyorsa inceleyen kişi bölgenin neden yeterince kararlı olduğunu bilmelidir. Beşinci girdi kaydetme ve çalıştırma politikasıdır; bir profili kaydetmek kullanıcının otomasyon kütüphanesini değiştirir, bir profili çalıştırmak cihaz durumunu değiştirir. Bu eylemler salt okunur bağlam toplamadan ayrılmalıdır.
İyi bir yapay zeka taslağı, bir ekip arkadaşının inceleyebileceği bir iş akışı gibi okunmalıdır. Düğüm adları spesifik olmalıdır: 'Staging uygulamasını aç', 'Giriş ekranını bekle', 'Durum ekran görüntüsünü al', 'Sipariş durumunu OCR ile oku', 'Durum eksikse dur' gibi. 'dokun1' veya 'düğüm12' gibi genel adlar riski gizler. Grafik ayrıca dallanma davranışını da göstermelidir: uygulama beklenmeyen bir ekrana açıldığında ne olur? OCR beklenen metni bulamazsa ne olur? Cihaz çevrimdışıysa ne olur? Doğru cevap genellikle kanıtı korumak ve durmaktır, dokunmaya devam etmek değil. İşte bu noktada LaiCai Flow rehberli grafik incelemesi önem kazanır. Grafik sadece görsel bir düzenleyici değil, bir yapay zeka taslağını ekibin hata ayıklayabileceği bir yapıta dönüştüren inceleme eseridir. Yapay zeka tarafından oluşturulan bir Flow'un ilk çalıştırması izlenmelidir. İyi yapılandırılmış bir taslak bile cihaz performansı, dil, izinler, uygulama durumu veya zamanlama nedeniyle başarısız olabilir. Taslağı çalıştırırken Android ekran yansıtma ile gerçek uygulamayı görmek, inceleyenin loglar, ekran görüntüleri ve OCR kanıtları oluşturulurken gerçek uygulamayı izlemesine olanak tanır. Bu, kalite güvence ve destek için önemlidir. Bir kalite güvence mühendisi hatanın uygulamada, test verisinde, otomasyon mantığında mı yoksa cihaz durumunda mı olduğunu görmelidir. Bir destek lideri, başka bir ekip arkadaşına aktarılabilecek ekran görüntüleri ve net durma durumlarına ihtiyaç duyar. Bir operasyon kullanıcısı, hassas eylemlerin kontrolünü kaybetmeden tekrarlanabilirliğe ihtiyaç duyar. Ekran yansıtma tek başına otomasyonu daha akıllı yapmaz, ancak ilk otomasyon çalıştırmasını gözlemlenebilir kılar ve gözlemlenebilirlik, oluşturulan bir taslağın kara kutu haline gelmesini engeller.
