AI içgörüleri, güvenli erişim, güvenilir veri ve ölçülebilir kalite ile bir admin dashboard web uygulamasını tasarlama, inşa etme ve yayınlama adım adım planı.

Grafikleri tasarlamadan veya bir LLM seçmeden önce, bu admin panosunun kime hizmet ettiğini ve hangi kararları desteklemesi gerektiğini acımasızca netleştirin. Admin panoları çoğunlukla “herkese” hizmet etmeye çalıştıklarında başarısız olur ve sonunda kimseye yardımcı olmaz.
Panoda yer alacak birincil rolleri listeleyin—genellikle ops, support, finance ve product olur. Her rol için, her gün veya her hafta verdikleri en önemli 3–5 kararı yazın. Örnekler:
Bir widget bir karara yardımcı olmuyorsa, muhtemelen gürültüdür.
“AI destekli admin panosu” ifadesi, genel bir sohbet botu eklemekten ziyade küçük bir set somut yardımcıya dönüşmelidir. Yaygın yüksek değerli AI özellikleri şunlardır:
Anında güncelleme gerektiren iş akışlarını (fraud kontrolleri, kesintiler, takılı ödemeler) saatlik veya günlük yenileme ile yetinebilecek iş akışlarından ayırın (haftalık finans özetleri, kohort raporları). Bu seçim karmaşıklığı, maliyeti ve AI cevaplarının tazeliğini belirler.
Gerçek operasyonel değeri gösterecek çıktıları seçin:
İyileşmeyi ölçemiyorsanız, AI özelliklerinin gerçekten yardımcı olup olmadığını söyleyemezsiniz—ve belki de sadece ek iş üretiyorlardır.
Ekranları tasarlamadan veya AI eklemeden önce, panonuzun aslında hangi verilere dayanacağını ve bu verinin nasıl birbirine uyduğunu netleştirin. Admin panosu acısının büyük kısmı uyumsuz tanımlardan (“Aktif kullanıcı nedir?”) ve gizli kaynaklardan (“İadeler faturalama aracında, DB'de değil”) gelir.
“Gerçek”in şu anda nerede saklandığını listeleyerek başlayın. Birçok ekip için bu şunları içerir:
Her kaynak için şunu yakalayın: sahibi kim, nasıl erişiliyor (SQL, API, export), ve ortak anahtarlar neler (email, account_id, external_customer_id). Bu anahtarlar daha sonra veriyi birleştirmeyi mümkün kılar.
Admin panoları, sıkça karşılaşılan ve her yerde görünen küçük bir varlık seti etrafında kurulduğunda en iyi çalışır. Tipik olanlar: users, accounts, orders, tickets ve events. Aşırı modelleme yapmayın—yöneticilerin gerçekten aradığı ve sorun giderdiği birkaç tanesini seçin.
Basit bir domain modeli şöyle olabilir:
Bu, mükemmel veritabanı tasarımıyla ilgili değil. Bir yönetici bir kaydı açtığında neye “baktığı” konusunda uzlaşmakla ilgilidir.
Her önemli alan ve metrik için, tanımın kimde olduğunu kaydedin. Örneğin Finance “MRR”ye, Support “ilk yanıt süresi”ne, Product ise “Activation”a sahip olabilir. Sahiplik açık olduğunda, çakışmaları çözmek ve sayıları sessizce değiştirmek daha kolaydır.
Panolar genellikle farklı yenileme gereksinimlerine sahip verileri birleştirir:
Ayrıca geç gelen olaylar ve düzeltmeler (daha sonra kaydedilen iadeler, geciken event teslimi, manuel ayarlamalar) için plan yapın. Ne kadar geriye dönük backfill'e izin vereceğinize ve düzeltilmiş geçmişi nasıl göstereceğinize karar verin ki yöneticiler güven kaybetmesin.
Adlandırmayı ve anlamı standartlaştıran basit bir veri sözlüğü oluşturun (bir doküman yeterlidir). İçerisine şunları koyun:
Bu, hem pano analitiği hem de daha sonra LLM entegrasyonu için referans noktası olur—çünkü AI yalnızca kendisine verilen tanımlar kadar tutarlı olabilir.
İyi bir admin pano yığını yenilikten çok öngörülebilir performansla ilgilidir: hızlı sayfa yükleme, tutarlı UI ve AI eklemeyi core operasyonlarla karıştırmadan ilerletme yolu.
Ekiplerin işe alabileceği ve sürdürebileceği yaygın bir framework seçin. React (Next.js ile) veya Vue (Nuxt ile) admin panoları için uygundur.
Tasarımı tutarlı kılmak ve teslimatı hızlandırmak için bir bileşen kütüphanesi kullanın:
Bileşen kütüphaneleri erişilebilirlik ve standart desenler (tablolar, filtreler, modallar) sağlar; bunlar admin paneli UI'sında özel görsellerden daha önemlidir.
Her ikisi de çalışır, ama tutarlılık seçimin kendisinden daha önemlidir.
/users, /orders, /reports?from=...&to=....Emin değilseniz, iyi sorgu parametreleri ve pagination ile REST ile başlayın. Daha sonra bir GraphQL gateway ekleyebilirsiniz.
Çoğu AI destekli admin pano ürünü için:
Yaygın bir desen, pahalı widget'ları kısa TTL'lerle cachelemek (ana KPI'lar, özet kartlar) böylece panolar hızlı kalır.
LLM entegrasyonunu anahtarları korumak ve veri erişimini kontrol etmek için sunucuda tutun.
Eğer hedefiniz RBAC, tablolar, drill-down sayfaları ve AI yardımcılarıyla operatörlerin önüne hızlıca güvenilir bir admin dashboard MVP koymaksa, vibe-coding bir platform (ör. Koder.ai) kurulumu kısaltabilir. Sohbette ekranları ve iş akışlarını tarif ederek React frontend ve Go + PostgreSQL backend üretebilir, repo'yu devralmak istediğinizde kaynak kodunu dışa aktarabilirsiniz. Planlama modu, anlık görüntüler/rollback gibi özellikler prompt şablonları ve AI UI üzerinde iterasyon yaparken core operasyonları bozmamanızı sağlar.
[Browser]
|
v
[Web App (React/Vue)]
|
v
[API (REST or GraphQL)] ---> [Auth/RBAC]
| |
| v
| [LLM Service]
v
[PostgreSQL] <--> [Redis Cache]
|
v
[Job Queue + Workers] (async AI/report generation)
Bu kurulum basit kalır, kademeli ölçeklenir ve AI özelliklerini her isteğin içine karıştırmak yerine ekleyici tutar.
Admin panoları “Ne yanlış?” ve “Sonra ne yapmalıyım?” sorularına cevap vermede hızla ölür veya yaşar. UX'i gerçek admin işleri etrafında tasarlayın ve kaybolmayı zorlaştırın.
Günün en önemli admin görevleriyle başlayın (iade bir siparişi işleme, bir kullanıcıyı engelini kaldırma, bir artışı araştırma, bir planı güncelleme). Navigasyonu bu işler etrafında gruplayın—altyapı verileri birden fazla tablodan gelse bile.
Sıklıkla işe yarayan basit bir yapı:
Yöneticiler sürekli birkaç işlem tekrarlar: arama, filtreleme, sıralama ve karşılaştırma. Navigasyonu bunların her zaman erişilebilir ve tutarlı olacağı şekilde tasarlayın.
Grafikler trendler için iyidir, ama yöneticiler genellikle kesin kaydı ister. Kullanın:
Erken aşamada temel erişilebilirlik kurallarını dahil edin: yeterli kontrast, görülebilir fokus durumları ve tablo kontrolleri ile diyaloglar için tam klavye navigasyonu.
Ayrıca her widget için boş/yükleniyor/hata durumlarını planlayın:
UX baskı altındayken tahmin edilebilir kaldığında yöneticiler güven hisser ve daha hızlı çalışır.
Yöneticiler panoyu “AI ile sohbet etmek” için açmaz; karar almak, sorunları çözmek ve operasyonları yürütmek için açarlar. AI özellikleriniz tekrarlayan işleri kaldırmalı, soruşturma süresini kısaltmalı ve hataları azaltmalı—yeni yönetilecek bir yüzey eklememeli.
Yöneticilerin her gün yaptıkları manuel adımları doğrudan yerine koyan küçük setler seçin. İyi ilk adaylar dar, açıklanabilir ve doğrulanması kolaydır.
Hızlı geri dönüş sağlayan örnekler:
AI'yı metin yazması için kullanınysa çıktı düzenlenebilir ve düşük riskliyse (özetler, taslaklar, dahili notlar). AI'yı eylem önerisi için kullanın ki insan kontrolü korunabilsin (önerilen sonraki adımlar, ilgili kayıtlara bağlantılar, ön-doldurulmuş filtreler).
Pratik bir kural: bir hata para, izinler veya müşteri erişimini değiştirebilecekse, AI öneri yapmalı—asla otomatik yürütmemeli.
Her AI bayrağı veya önerisi için küçük bir “Bunu neden görüyorsunuz?” açıklaması ekleyin. Hangi sinyallerin kullanıldığını belirtmelidir (ör. “14 günde 3 başarısız ödeme” veya “hata oranı 0.2%'den 1.1%'e çıktı, release 1.8.4 sonrası”). Bu güven oluşturur ve yöneticilerin kötü veriyi yakalamasına yardımcı olur.
AI'nın ne zaman reddetmesi gerektiğini (izin eksikliği, hassas istekler, desteklenmeyen işlemler) ve ne zaman açıklayıcı soru sorması gerektiğini (belirsiz hesap seçimi, çelişen metrikler, eksik zaman aralığı) belirtin. Bu deneyimi odaklı tutar ve kendinden emin ama yararsız çıktıları önler.
Bir admin panosu zaten pek çok yerde veri barındırır: faturalama, destek, ürün kullanımı, audit logları ve dahili notlar. Bir AI asistanı, hızlı, güvenli ve tutarlı bir şekilde birleştirebildiğiniz bağlam kadar faydalıdır.
Hızlandırmak istediğiniz admin görevlerinden başlayın (ör. “Bu hesap neden engellendi?” veya “Bu müşteri için son olayları özetle”). Ardından küçük, öngörülebilir bağlam girişleri tanımlayın:
Bir alan AI'nın cevabını değiştirmiyorsa dahil etmeyin.
Bağlamı kendi ürün API'niz gibi ele alın. Sunucu tarafında bir “context builder” oluşturun ve her varlık için minimal JSON payload üretsin. Yalnızca gerekli alanları dahil edin ve hassas verileri maskeleyin (tokenlar, tam kart bilgileri, tam adresler, ham mesaj gövdeleri).
Davranışı hata ayıklamak ve denetlemek için metadatalar ekleyin:
context_versiongenerated_atsources: hangi sistemlerin veri sağladığıredactions_applied: hangi verilerin kaldırıldığı veya maskelendiğiHer ticket, not ve politikayı prompt'a tıkıştırmak ölçeklenmez. Bunun yerine aranabilir içeriği (notlar, KB makaleleri, playbook'lar, ticket thread'leri) bir index'e koyun ve yalnızca en alakalı snippet'leri istekte bulunma zamanında çekin.
Basit bir desen:
Bu, prompt'ları küçük tutar ve cevapları gerçek kayıtlara dayandırır.
AI çağrıları bazen başarısız olur. Buna göre tasarlayın:
Birçok admin soru tekrarlanır (“hesap sağlığını özetle”). Sonuçları entity + prompt versiyonuna göre cache'leyin ve iş anlamına göre sona erdirin (ör. canlı metrikler için 15 dakika, özetler için 24 saat). Her zaman “hangi tarihe kadar” taze olduğunu gösteren zaman damgaları dahil edin.
Admin panosu yüksek güven ortamıdır: AI operasyonel veriyi görür ve kararları etkileyebilir. İyi prompting “zeki kelime oyunundan” çok, öngörülebilir yapı, katı sınırlar ve izlenebilirlik demektir.
Her AI isteğini bir API çağrısı gibi ele alın. Girdileri net bir formatta (JSON veya madde alanları) sağlayın ve belirli bir çıktı şemasını zorunlu kılın.
Örneğin isteyin:
Bu, serbest form yaratıcılığını azaltır ve cevapları UI'da göstermeden önce doğrulamayı kolaylaştırır.
Özellikler arasında şablonları tutarlı tutun:
Açık kurallar ekleyin: gizli bilgi yok, sadece sağlanan veriden fazlasını kullanma, ve insan onayı olmadan riskli eylemler (kullanıcı silme, iade, izin değiştirme) yapma.
Mümkünse atıf zorunluluğu getirin: her iddiayı bir kaynak kaydına (ticket ID, order ID, event timestamp) bağlayın. Model atıf yapamıyorsa bunu söylemeli.
Promptları, alınan bağlam kimliklerini ve çıktıları loglayın ki sorunları yeniden üretebilesiniz. Hassas alanları (tokenlar, e-postalar, adresler) maskelenmiş olarak kaydedin ve loglara erişimi kontrol altında tutun. “AI neden bunu önerdi?” sorusu geldiğinde bu kayıtlar çok değerli olur.
Admin panoları güç yoğunlaştırır: bir tık fiyatlandırmayı değiştirebilir, kullanıcıları silebilir veya özel verileri açığa çıkarabilir. AI destekli panolarda risk daha da yüksek—asistan önerilerle kararları etkileyebilir. Güvenliği sonradan eklenen bir katman olarak değil, çekirdek bir özellik olarak ele alın.
Veri modeliniz ve rotalarınız hâlâ evrilirken rol tabanlı erişim kontrolünü (RBAC) uygulayın. Küçük bir rol seti tanımlayın (ör. Viewer, Support, Analyst, Admin) ve izinleri rollere bağlayın—bireysel kullanıcılara değil. Sıkıcı ama açık tutun.
Pratik bir yaklaşım, “bu kim görebilir?” ve “bunu kim değiştirebilir?” sorularını yanıtlayan bir izin matrisi (dokümanda basit bir tablo) tutmaktır. Bu matris API ve UI'yi yönlendirir ve pano büyüdükçe yetki sızıntılarını önler.
Çoğu ekip sadece “sayfaya erişebilir” düzeyinde kalır. Bunun yerine izinleri en az iki seviyeye bölün:
Bu ayrım, geniş görünürlük vermeniz gerektiğinde (örn. destek personeli) kritik ayarları değiştirme yetkisini vermeden riski azaltır.
UX için butonları gizleyin ama güvenlik kontrollerinizi UI'ya bırakmayın. Her endpoint çağrısında çağıranın rolünü/izinlerini doğrulayın:
“Önemli eylemler”i kim/ne zaman/neyi/nasıl değiştirdiğini cevaplayacak şekilde loglayın. En azından: aktör user ID, eylem türü, hedef varlık, zaman damgası, önce/sonra değerleri (veya diff) ve istek meta verisi (IP/user agent) yakalayın. Denetim loglarını değiştirilemez (append-only), aranabilir ve düzenlemelerden korunmuş tutun.
Oturum yönetimi, admin erişim süreci, olay yanıtı prensipleri gibi güvenlik varsayımlarınızı ve işletme kurallarınızı yazın. Eğer bir security sayfanız varsa, ürün dokümanlarından referans verin (örn. görülebilir bir /security) ki adminler ve denetçiler ne bekleyeceklerini bilsin.
API yapınız ya admin deneyimini hızlı kılar ya da frontend'i her ekranda backend ile savaşmaya zorlar. En basit kural: endpoint'leri UI'nın gerçekten ihtiyaç duyduğu şekilde tasarlayın (list view'lar, detail sayfalar, filtreler ve birkaç ortak aggregate) ve cevap formatlarını öngörülebilir tutun.
Her ana ekran için küçük bir endpoint seti tanımlayın:
GET /admin/users, GET /admin/ordersGET /admin/orders/{id}GET /admin/metrics/orders?from=...&to=...Her şeyi döndüren “hepsi bir arada” GET /admin/dashboard gibi endpoint'lerden kaçının. Bunlar sınırsız büyür, cachelemeyi zorlaştırır ve kısmi UI güncellemelerini acılı hale getirir.
Admin tabloları tutarlılıktan yaşar veya ölür. Şunları destekleyin:
limit, cursor veya page)sort=created_at:desc)status=paid&country=US)Filtrelerin zaman içinde kararlı kalmasını sağlayın (anlamları sessizce değiştirmeyin), çünkü yöneticiler URL'leri yer işareti yapıp görünümleri paylaşacak.
Büyük exportlar, uzun süren raporlar ve AI üretimleri asenkron olmalı:
POST /admin/reports → job_id döndürürGET /admin/jobs/{job_id} → durum + ilerlemeGET /admin/reports/{id}/download hazır olduğundaAynı desen “AI özetleri” veya “taslak cevaplar” için de işe yarar, böylece UI duyarlı kalır.
Frontend'in net gösterebilmesi için hataları standartlaştırın:
{ "error": { "code": "VALIDATION_ERROR", "message": "Invalid date range", "fields": { "to": "Must be after from" } } }
Bu, AI özellikleriniz için de faydalıdır: belirsiz “bir şeyler ters gitti” yerine eyleme geçirilebilir hatalar sunabilirsiniz.
Mükemmel bir admin frontend modüler hissettirir: yeni bir rapor veya AI yardımcıyı tüm UI'yi yeniden inşa etmeden ekleyebilirsiniz. Önce küçük bir yeniden kullanılabilir blok seti standardize edin, sonra davranışlarını tüm uygulamada tutarlı kılın.
Her ekranda yeniden kullanabileceğiniz bir “dashboard kit” oluşturun:
Bu bloklar ekranları tutarlı kılar ve tek seferlik UI kararlarını azaltır.
Yöneticiler sıklıkla görünümlere yer imi koyar ve bağlantılar üzerinden paylaşır. Ana durumu URL'de tutun:
?status=failed&from=...&to=...)?orderId=123 side paneli açsın)Kaydedilmiş görünümler (“Benim QA kuyruğum”, “Son 7 gündeki iadeler”) ekleyin; bu, kullanıcıların aynı sorguları tekrar inşa etmek zorunda kalmadan panoyu daha hızlı hissetmesini sağlar.
AI çıktısını nihai cevap değil taslak gibi ele alın. Side panelde (veya bir “AI” sekmesinde) gösterin:
Her zaman AI içeriğini etiketleyin ve hangi kayıtların bağlam olarak kullanıldığını gösterin.
AI bir eylem öneriyorsa (kullanıcıyı işaretle, iade yap, ödemeyi engelle), bir inceleme adımı zorunlu kılın:
Önemli olanları takip edin: arama kullanımı, filtre değişimleri, exportlar, AI açılma/tıklama oranı, yeniden oluşturma oranı ve geribildirim. Bu sinyaller UI'ı iyileştirmenize ve hangi AI özelliklerinin gerçekten zaman kazandırdığını belirlemenize yardımcı olur.
Admin panosunu test etmek piksellerden çok gerçek koşullar altında güven kazanmakla ilgilidir: eski veri, yavaş sorgular, eksik girdiler ve hızlı tıklayan “power user”lar.
Asla bozulmaması gereken kısa bir iş akışı listesiyle başlayın. Bunları uçtan uca otomatikleştirin (tarayıcı + backend + veritabanı) ki entegrasyon hatalarını yakalayabilesiniz, sadece unit seviyesini değil.
Tipik “geçmesi gereken” akışlar: giriş (rollerle), global arama, bir kaydı düzenleme, rapor exportu ve herhangi bir onay/incele eylemi. Gerçekçi veri boyutunu kapsayan en az bir test ekleyin; performans regresyonları genellikle küçük fixture'ların arkasına saklanır.
AI özellikleri kendi test eserlerine ihtiyaç duyar. Hafif bir değerlendirme seti oluşturun: gerçek admin sorularını yansıtan 20–50 prompt, her biri için beklenen “iyi” cevaplar ve birkaç “kötü” örnek (halüsinasyonlar, politika ihlalleri veya eksik atıflar).
Bunu repo'da versionlayın ki prompt/araç/model değişiklikleri kod gibi gözden geçirilebilsin.
Birkaç basit metriği takip edin:
Ayrıca adversaryal girdilerle (prompt injection denemeleri) test edin ki gardıroplarınız sağlam olsun.
Modelin çalışmadığı durumlar için bir plan: AI panellerini devre dışı bırakın, sade analitik gösterin ve çekirdek eylemlerin kullanılabilir kalmasını sağlayın. Bir feature flag sistemi varsa AI'yı flag arkasına bağlayın ki hızlı geri alma mümkün olsun.
Son olarak gizlilik gözden geçirmesi yapın: logları maskeyle, hatırlamayacağınız kimlikleri içeren ham promptları saklamayın ve hata ayıklama ile değerlendirme için yalnızca gerekli olanı tutun. /docs/release-checklist içinde basit bir kontrol listesi ekiplerin tutarlı şekilde yayınlamasını sağlar.
AI destekli bir admin panoyu yayınlamak tek seferlik bir olay değildir—“kendi makinemde çalışıyor” halinden “operatörler tarafından güvenilen”e kontrollü bir geçiştir. En güvenli yaklaşım, yayını mühendislik iş akışı gibi ele almak: net ortamlar, görünürlük ve kasıtlı bir geribildirim döngüsü.
Geliştirme, staging ve prod'u farklı veritabanları, API anahtarları ve AI sağlayıcı kimlik bilgileriyle izole edin. Staging, prod ayarlarını (feature flag'ler, rate limitler, arka plan işler) yakından yansıtmalı ki gerçek dünya davranışını canlı riske atmadan doğrulayabilesiniz.
Çevresel yapılandırmayı environment variable'lar ile ve tutarlı bir dağıtım süreci kullanarak yönetin. Bu, rollback'leri öngörülebilir kılar ve “prod için özel durum”ları önler.
Eğer anlık görüntü ve rollback destekleyen bir platform kullanıyorsanız (ör. Koder.ai'nin yerleşik snapshot akışı), aynı disiplini AI özellik iterasyonlarına uygulayabilirsiniz: feature flag'in arkasında yayınlayın, ölçün ve prompt veya retrieval değişiklikleri admin güvenini bozmaya başlarsa hızla geri alın.
Sistem sağlığı ve kullanıcı deneyimini takip eden monitoring kurun:
Ayrıca veri tazeliği için uyarılar ekleyin (örn. “satış toplamları 6+ saattir güncellenmedi”) ve pano yükleme süreleri (örn. p95 2 saniyenin üstünde). Bu iki sorun yöneticiler için en çok kafa karıştıranlardır çünkü UI “iyi” görünürken veriler eski veya yavaş olabilir.
Küçük bir MVP yayınlayın, sonra gerçek kullanım verilerine göre genişletin: hangi raporlar günlük açılıyor, hangi AI önerileri kabul ediliyor, yöneticiler nerede tereddüt ediyor. Yeni AI özelliklerini flag arkasında tutun, kısa deneyler yapın ve erişimi genişletmeden önce metrikleri inceleyin.
Sonraki adımlar: /docs içinde dahili bir runbook yayınlayın ve eğer katmanlar veya kullanım sınırları sunuyorsanız, bunları /pricing üzerinde netleştirin.
Önce ana yönetici rollerini (support, ops, finance, product) listeleyin ve her rolün haftalık olarak verdiği 3–5 karari yazın. Ardından bu kararları doğrudan destekleyen widget'lar ve AI yardımcıları tasarlayın.
İyi bir filtre: eğer bir widget birinin bir sonraki adımını değiştirmiyorsa, muhtemelen gürültüdür.
Bu, iş akışlarına gömülü küçük, somut yardımcılar anlamına gelmeli; genel bir chatbot değil.
Yüksek değerli yaygın seçenekler:
Birinin hemen tepki vermesi gereken yerlerde gerçek zamanlı kullanın (fraud kontrolleri, kesintiler, takılı ödemeler). Raporlama odaklı iş akışları için saatlik/günlük yenileme yeterlidir (finans özetleri, kohort analizleri).
Bu seçim etki eder:
Her yerde “gerçek”in saklandığı her yeri envanterleyerek başlayın:
Her kaynak için , erişim yöntemi (SQL/API/eksport) ve nı (account_id, external_customer_id, email) kaydedin. Bu anahtarlar, admin görünümlerini ve AI bağlamını birleştirebilirlik açısından belirler.
Yöneticilerin gerçekten aradığı ve sorun giderdiği küçük bir çekirdek varlık seti seçin (sıklıkla: Account, User, Order/Subscription, Ticket, Event).
Basit bir ilişki modeli yazın (ör. Account → Users/Orders; User → Events; Account/User → Tickets) ve metrik sahipliğini belgeleyin (ör. Finance MRR'ye sahip). Bu, ekranları ve AI prompt'larını ortak tanımlara dayandırır.
Pratik bir taban şu şekildedir:
LLM çağrılarını sunucu tarafında tutun; anahtarları korumak ve erişimi denetlemek için.
UX'i işler etrafında organize edin, tablolar yerine iş akışlarına odaklanın. Sık yapılan görevleri (search/filter/sort/compare) her zaman erişilebilir kılın.
Pratik desenler:
Yinelenen işleri azaltan ve soruşturma süresini kısaltan AI özelliklerini oluşturun:
Kural: hata para, izinler veya erişimi etkileyebiliyorsa, AI öneri yapmalı; doğrudan işlem yapmamalı.
Bir sunucu tarafı “context builder” oluşturun: her varlık (account/user/ticket) için minimal, güvenli JSON döndürsün. Cevabı etkilemeyen alanları dahil etmeyin ve hassas verileri maskeleyin.
Hata ayıklama ve denetim için metadatalar ekleyin:
context_versiongenerated_atsourcesredactions_appliedİlk günden RBAC uygulayın ve her eylem için sunucu tarafında zorunlu hale getirin (AI tarafından üretilen raporlar ve exportlar dahil).
Ayrıca şunları ekleyin:
Uzun metinler (biletler, notlar, KB) için retrieval kullanın: sadece en alakalı parçaları çekip atıflarla birlikte prompt'a geçirin.