Grok Bot'u gerçekten kullanmak: çoğu kişinin atladığı 18 kurallık kurulum

Şef Bot iş yapmaz, her Bot sözleşmeyle çalışır, tekrar eden hata kurala dönüşür ve ciddi otomasyonun önünde üç kapı durur: Grok Bot'u Bot duvarı değil, organizasyon gibi kurmanın 18 kuralı.

Hızlı not: Grok Bot rehberlerinin çoğu arayüzü anlatıyor, bu yazı organizasyon tasarımını anlatıyor. Kuralların neredeyse hepsi ya resmi dokümanlara ya da Çin'deki Grok Bot topluluğunun gerçek iş akışlarına dayanıyor. Yani teoriye değil, sahada kırılıp düzeltilmiş şeylere.

Çoğu rehber neden yanlış şeyi öğretiyor?

Grok Bot çıktığında herkes aynı şeyi yaptı: bir Araştırma Bot'u, bir Yazı Bot'u, bir Satış Bot'u, bir de Şef Bot kurdu ve kenar çubuğunda on renkli AI çalışanın durduğu ekran görüntüsünü paylaştı. Gelecekten gelmiş gibi görünüyor. Ama Bot duvarı bir AI şirketi değil; yönetmek zorunda olduğun on yeni iş arkadaşı.

Grok Bot kalıcı durum tutabiliyor, bir bulut bilgisayarı kullanabiliyor, laptop kapalıyken çalışabiliyor, olaylardan tetiklenebiliyor, diğer Botlarla konuşabiliyor, izin verilirse yerel bilgisayara uzanabiliyor ve kod işleri için ayrı Cursor Cloud Agent'ları başlatabiliyor. Yani hedef en akıllı asistanı kurmak değil, bir organizasyon tasarlamak: bilgi doğru çalışana gidiyor, kanıt devirde kaybolmuyor, rutin iş sensiz oluyor, hatalar kurala dönüşüyor ve sadece senin kararını gerektiren şeyler sana geri geliyor.

Çin'deki ileri kullanıcılar Grok Bot'u zaten böyle kullanıyor. Xiaohongshu'da paylaşılan gerçek bir iş akışında Grok Bot esas olarak dağıtıcı: ağır düşünme işini bulut modelleri yapıyor, yerel Cursor kanıt ve gerçek ekran görüntüsü üretiyor, uzman Botlar sonucu paketliyor, yayın kararı insanda kalıyor.

Bot tek başına ürün değil. Botlar arasındaki sistem ürün.

Bölüm 1: buradan başla

1. İlk Bot'un işi kendisi yapmasın

Akla ilk gelen kurulum her şeyi yapabilen bir Şef Bot (Chief of Staff). Bunu yapma. Şef Bot üretim işi için bilerek yetersiz bırakılmalı. İşi sadece şu:

Şef araştırmaya, yazmaya ve web sitesi kullanmaya başladığı anda kaçmaya çalıştığın o dev sohbet botunu yeniden kurmuş olursun. Çin'deki en iyi iş akışlarından biri de sonunda bu yapıya gelmiş: kullanıcı tek bir koordinatörle konuşuyor, uzman işçiler görevleri arka planda alıyor. SpaceXAI'ın rehberi de aynı yönü gösteriyor: Botlar işi kendi aralarında devredebiliyor, böylece insan yönlendirici olmaktan çıkıyor.

Şef'e şunu ver:

Sen benim Şef Bot'umsun.
Asıl işin uzman işi yapmak DEĞİL. İşin şu:

1. İstediğim sonucu anla.
2. Her parçanın sahibi kim olacak, karar ver.
3. Mümkün olan en az sayıda uygun uzmana dağıt.
4. Bitmemiş devirleri takip et.
5. Uzmanlar arasındaki çelişkileri çöz.
6. Nihai teslimi topla.
7. Beni sadece kararım, iznim ya da eksik bir bilgi
   gerçekten gerektiğinde çağır.

Kendin ciddi bir iş yapmadan önce sor:
"Bunun sahibi olması gereken bir uzman var mı?"
Varsa dağıt.

Sen yönlendirmenin ve kapanışın sahibisin. Uzman
olmadığı durumlar dışında araştırmacı, yazar, tasarımcı,
mühendis, analist ya da operatör olmazsın.

2. Uygulamaya göre değil, darboğaza göre işe al

İnsanlar doğal olarak şunları kuruyor: Gmail Bot, Chrome Bot, Slack Bot, Notion Bot, X Bot. Bu tersten gitmek. Kimse "Chrome çalışanı" işe almaz; gelirden, araştırmadan, müşteri başarısından, finanstan ya da yayından sorumlu birini işe alır. İnsanların en çok yanıldığı yer pazar yeri ekranı: her ikon kendisi için bir Bot kurulmasını istiyor. Direnmek gerekiyor.

Çin'deki Grok Bot topluluğunun kullanışlı bir ilkesi var: organizasyonu işin tıkandığı yerden böl. Araştırma yayını tıkıyorsa istihbarat Bot'u, görseller tıkıyorsa görsel Bot'u, rakam doğrulama tıkıyorsa doğrulayıcı kur. Xiaohongshu'daki uygulama sadece koordinatör ve istihbarat rolüyle başlamış; yeni pozisyonlar ancak tekrar eden bir darboğaz çıktığında eklenmiş. SpaceXAI da yeni Bot'u ancak işin farklı bir hedefi, kaynak seti, çalışma tarzı, onay sınırı ya da tekrar eden sorumluluğu varsa kurmayı öneriyor.

Şef'e sor:

Bot ekibimi kullandığım uygulamalara göre değil,
tekrar eden darboğazlarıma göre tasarla.

Anlattığım son 2 haftalık işi incele ve şunları bul:
- sürekli beni bekleyen işler
- sürekli araştırmayı bekleyen işler
- sürekli doğrulamayı bekleyen işler
- sürekli yazıyı bekleyen işler
- sürekli uygulamayı bekleyen işler
- sürekli unutulan işler
- önceki çıktı yanlış olduğu için yeniden yaptığım işler

Yeni Bot'u sadece bir darboğaz kalıcı bir sahibi hak
edecek kadar sık tekrar ediyorsa öner.

Önerdiğin her Bot için yaz:
Darboğaz:
Sahip:
Sonuç:
Neden ayrı bir Bot gerekiyor:
Bu Bot ne yapmamalı:

Başka bir AI var diye AI işe alma. Bir yerde iş bekliyor diye işe al.

3. Her Bot'a kişilik değil sözleşme yaz

"Dünya çapında bir pazarlamacı ol." "Steve Jobs gibi düşün." "Çok zeki ol." Çoğu işe yaramaz. Bot'un bir çalışma sözleşmesine ihtiyacı var. Çin'deki bir Grok Bot rehberi iyi bir rolü dört alana indiriyor: sorumluluk, bilgi kaynakları, yargı ölçütleri, rapor formatı. Yazar buna beşinciyi ekliyor: yasak eylemler. Böylece beş alan çıkıyor: İş (hangi sonucun sahibisin), Kaynaklar (bilgiyi nereden alabilirsin), Yargı (neyin iyi, riskli ya da tamam olduğuna nasıl karar veriyorsun), Çıktı (bir sonrakine tam olarak ne teslim ediyorsun), Yasaklar (neden sorumlu değilsin). Bir araştırma Bot'u için doldurulmuş hali:

İŞ
Yayınlamaya değer, sinyali yüksek AI gelişmelerini bul.

KAYNAKLAR
Resmi şirket hesapları, sürüm notları, GitHub, seçilmiş
araştırmacılar, birincil makaleler ve onaylı izleme listesi.

YARGI
Öne al: gerçekten yeni bilgi, ölçülebilir değişim,
sıradışı teknik detay, kitlemizin kullanabileceği sonuçlar.
Ele: yeniden ısıtılmış duyurular, belirsiz kurucu sözleri,
dayanaksız söylentiler, altında olay olmayan etkileşim yemi.

ÇIKTI
Kabul edilen her madde için: tek cümlelik bulgu, orijinal
kaynak, neden önemli, ne değişti, güven düzeyi, önerilen
içerik açısı.

YASAKLAR
Nihai yazıyı yazma. Kişisel deneyim uydurma. Yayınlama.
İkincil haberi birincil kaynağa çevirme.

Böylece İçerik Bot'u, Araştırma Bot'unun ne demek istediğini çözmek için bağlamının yarısını harcamıyor; temiz malzeme alıyor.

4. Şirketi hatalardan büyüt

Bu, Çin kaynaklarındaki en iyi fikirlerden biri. İlk gün 4.000 kelimelik kusursuz bir anayasa yazmaya çalışma. Gerçek işi çalıştır. Sistem tekrar eden bir hata yaptığında o hatayı kalıcı kurala çevir. Çin'deki bir üretim akışı tek bir dev prompt'la değil, tam böyle olgunlaşmış: başlık beklenen formatı aştı, yeni kural. Yanlış görsel kaynağı kullanıldı, yeni kural. Gerçek kanıt yerine sahte görünen çıktı geldi, yeni kural. Aynı hata sahibinin zamanını iki kez almıyor.

Her düzeltmeden sonra şunu kullan:

İşletim sistemimizde bir hata bulduk.

HATA: [ne oldu]
NEDEN ÖNEMLİYDİ: [etkisi]
DOĞRU DAVRANIŞ: [bunun yerine ne olmalıydı]

Bu kuralın nereye ait olduğuna karar ver:
- Bot iş sözleşmesi
- Skill
- Kaynak politikası
- Onay politikası
- Handoff sözleşmesi
- Rutin
- Genel çalışma kuralı

Kuralı, ilgisiz işi gereksiz kısıtlamadan tam bu hata
sınıfını engelleyen en dar yere ekle.

Sonra bana söyle:
ESKİ DAVRANIŞ
YENİ KURAL
NEREYE KAYDEDİLDİ
NASIL TEST EDECEĞİZ

Aynı hatayı üç kez elle düzeltiyorsan artık AI yönetmiyorsun. Ücretsiz kalite kontrol yapıyorsun.

Bölüm 2: Grok Bot sandığın gibi kurulmamış

5. Botların ayrı bilgisayarı yok

Pazarlama dili her Bot için ayrı makine hayal ettiriyor. Öyle değil. Resmi dokümana göre bütün Botlar, kullanıcı hesabına bağlı tek bir kalıcı bulut bilgisayarını paylaşıyor. Her Bot kendi ekranını alıyor, bu yüzden birkaçı paralel çalışabiliyor. Ama o makinedeki dosyalar, tarayıcı oturumları, girişler ve komut satırı kimlik bilgileri bütün Bot kadrosuna açık olabiliyor. Ayrı Bot, ayrı güvenlik sınırı demek değil.

İyi taraf: bir kez giriş yapıyorsun, birden fazla Bot akışı sürdürebiliyor; Araştırma bir dosya üretiyor, Yazar alıyor, Koordinatör inceliyor. Tehlikeli taraf: bir "Finans Bot'u" kurmak, banka oturumunu "İçerik Bot'u"ndan teknik olarak ayırmıyor.

O yüzden "hangi Bot'un erişimi olsun" diye düşünmeyi bırak. "Paylaşılan bilgisayarda ne bulunsun" diye düşün. Kurulumu şu prompt'la denetle:

Paylaşılan Grok Bot bilgisayarından erişilebilen her şeyi
denetle: tarayıcı girişleri, bağlayıcılar, kimlik bilgileri,
dosyalar, API erişimleri, servis hesapları.

Her birini sınıflandır: BİRÇOK BOT'A GEREKLİ / TEK İŞ
AKIŞINA GEREKLİ / GEÇİCİ / GEREKSİZ / YÜKSEK RİSKLİ

Minimum erişim mimarisini öner. Farklı Botları güvenlik
izolasyonu sayma. Salt okunur erişimi, kapsamı dar servis
hesaplarını ve sonucu olan eylemler için açık onayı tercih et.

6. /workspace şirketin iç veri yolu olsun

Çoğu kişi ajanları sohbet üzerinden çalıştırıyor. Araştırma Bot'u dev bir mesaj yazıyor, Yazar dev mesajı alıyor, İnceleyici bir dev mesaj daha alıyor. Bağlam sıkışıyor, kaynaklar kayboluyor, rakamların nereden geldiği belirsizleşiyor. Bunun yerine ajanlar birbirine artefakt, yani dosya devretsin. Paylaşılan makine Botların bağlamı ortak dosyalarla aktarmasına izin veriyor ve resmi güvenlik rehberi proje dosyaları için açıkça /workspace klasörünü gösteriyor.

Şu klasörleri kur:

/workspace/research/
/workspace/drafts/
/workspace/evidence/
/workspace/reviews/
/workspace/approved/
/workspace/archive/

Sonra handoff paketini tanımla:

Her uzman devri bir artefakt üretmeli. Ciddi işi başka
bir Bot'a sadece sohbetle devretme.

HANDOFF.md oluştur, içinde:
GÖREV: Senden ne istendi.
DURUM: Tamamlandı / kısmi / engellendi.
ÇIKTI: Asıl teslim.
KAYNAKLAR: Orijinal linkler, dosyalar, zaman damgaları,
           ekran görüntüleri.
KARARLAR: Verdiğin önemli yargı kararları.
BELİRSİZLİKLER: Doğrulayamadığın her şey.
SONRAKİ SAHİP: İşi kim sürdürecek.
VARSAYMA: Sonraki Bot'un yeniden kontrol etmesi gereken bilgi.

Destekleyici dosyaları handoff'un yanına kaydet.

Artık organizasyonun AI hafızasından çok daha değerli bir şeyi var: kurumsal kanıt.

7. Hafıza tercihleri saklasın, gerçekleri değil

Botlar hatırlıyor. Kulağa güzel geliyor, hatırlanan bilgi değişene kadar. Güncel fiyat, müşteri durumu, stok, hesap bakiyesi, kampanya performansı, ürün özellikleri, teslim tarihleri, kimin nerede çalıştığı. Bunlar hafıza değil; yapılmayı bekleyen veritabanı sorguları. SpaceXAI de Bot hafızasının yetkili kaynağın yerine geçmediğini açıkça söylüyor ve sonucu olan kararlarda güncel veriyi yeniden açmayı öneriyor.

Bu kuralı bütün ekipte kullan:

HAFIZA POLİTİKASI

Hafızaya izin var: tercihlerim, yazım tarzı, sabit
tanımlar, tekrar eden format, çalışma ilişkileri, kalıcı
çalışma kuralları, kararların bana nasıl sunulacağı.

Hafıza şunlarda yetkili DEĞİL: fiyatlar, bakiyeler,
tarihler, müsaitlik, kampanya metrikleri, hesap durumu,
müşteri durumu, çalışan durumu, sözleşmeler, piyasa
verisi, değişen teknik dokümantasyon, bayatlayabilen
her önemli şey.

Değişen gerçekler için: değeri kullanmadan önce yetkili
kaynağı yeniden aç. Kaynağa ulaşılamıyorsa "KAYNAK
ULAŞILAMIYOR" de. Hatırlanan veriyi asla sessizce
yerine koyma.

İyi bir ajan her şeyi hatırlamaz. Neyi hatırlamaya güvenmemesi gerektiğini bilir.

8. Bulut çalışanın senin gerçek bilgisayarına uzanabilir

Grok Bot'un bulut bilgisayarı ile önündeki Mac ya da Windows makine ayrı ortamlar. Ama yerel çalıştırmayı açarsan Botlar yerel makinede de komut çalıştırabiliyor, dosya okuyabiliyor ve bulutla yerel arasında dosya taşıyabiliyor. Bunun ayrı izin kontrolleri var ve sadece iş akışı gerçekten gerektiriyorsa açılmalı.

Bu ilginç bir mimari doğuruyor: bulut orkestrasyon için, yerel makine özel kanıt ya da makineye bağlı işler için. Girişte anlatılan Çin iş akışı da tam buraya gelmiş: bulut modelleri sentezi yapıyor, yerel Cursor gerçek raporları ve ekran görüntülerini üretiyor. Örnek kural:

Bulutu araştırma, okuma, sentez, planlama ve koordinasyon
için kullan. Yerel bilgisayarımı SADECE yerel proje
dosyaları, yerel scriptler, gerçek ekran görüntüleri ve
makineye bağlı kanıt gerektiğinde kullan.

Yerel işten önce: bulutun neden yetmediğini açıkla, hangi
komut ya da dosya erişimi gerektiğini söyle, en küçük
kapsamı kullan, çıkan artefaktı /workspace/evidence/ içine
koy, ilgisiz yerel dosyalara dokunma.

Farklı güven rolleri olan iki bilgisayara yayılan iş akışları kurabiliyorsun. Bu, "AI'ın bulut bilgisayarı var" cümlesinden çok daha güçlü.

9. Grok Bot kodlama ajanlarının yöneticisi olabilir

Grok Bot'un geliştirici olması gerekmiyor. Ekipler için SpaceXAI, Grok Botların Cursor Cloud Agent başlatmasına izin veren bir Cloud Agents ayarını belgeliyor; ayar ekip kurulumunda varsayılan olarak açık. Cloud Agent'lar tam geliştirme ortamı olan izole sanal makinelerde çalışıyor. Ortaya şu zincir çıkıyor:

Ajanlardan biri ön yüzü, biri arka yüzü, biri testleri alıyor. Grok Bot'a "bu özelliğin tamamını yaz" demek yerine şunu de:

Sen teknik lidersin, tek mühendis değilsin.

İşi bağımsız test edilebilir parçalara böl, paralel
gidebilecekleri belirle ve gereken en az sayıda Cursor
Cloud Agent başlat. Her ajana tam kapsam, repo, kabul
kriterleri, gereken testler ve açık "hedef değil" listesi ver.
İlerlemeyi takip et, çıktıları incele, çelişen uygulamaları
çöz, son doğrulamayı çalıştır ve tek bir birleşik rapor döndür.

Bir Cloud Agent'a verilmiş uygulama işini tekrar yapma.

Önemli zihinsel değişim şu: bir AI'ın işin tamamını kendisi yapması gerekmiyor. İşin sahibi olabilir, işi başka bir işlem gücü yapar.

10. Grok Bot'un hangi modeli kullandığına takılma

İleri kullanıcılar şunu sormayı seviyor: bu Bot hangi modelde çalışıyor? Ama Grok Bot giderek bir orkestrasyon yüzeyi oluyor. Kurumsal dokümana göre Grok Bot model seçici sunmuyor; istekleri sabit bir model setine otomatik yedeklemeyle dağıtıyor. Cursor Cloud Agent'larının ise kendi model ayarı var ve topluluk dış modelleri araç ya da MCP yeteneği olarak da bağlıyor.

O yüzden "her işi en akıllı modelden nasıl geçiririm" yerine "her aşama için en ucuz güvenilir işçi hangisi" diye sor:

İşi şöyle ayır:
YÖNLENDİRME: Görevin sahibi kim olmalı.
MEKANİK: Çıkarma, dönüştürme, formatlama.
DERİN AKIL YÜRÜTME: Hatanın pahalı olduğu belirsiz analiz.
UYGULAMA: Tarayıcı, terminal, kod ya da dış araç işi.
DOĞRULAMA: Önemli iddiaların bağımsız kontrolü.

En pahalı yolu sadece var diye kullanma. Grok Bot sonucu,
bağlamı ve kalite çizgisini korusun; uzman işini uygun
araca, Bot'a ya da Cloud Agent'a devretsin.

Grok Bot'un şirketindeki en akıllı zekâ olması gerekmiyor. En önemli zekâ olması yeterli.

Bölüm 3: otomasyon ve güven

11. Mükemmel skill'i yazma, gerçek işle kazan

Çoğu kişi şöyle otomatikleştiriyor: mükemmel iş akışını hayal et, dev bir prompt yaz, zamanla, sabah 3'te 17 istisna keşfet. Daha iyi sıra şu:

SpaceXAI de bu sırayı öneriyor. Çin'deki saha raporu da aynı şeyi söylüyor: iş akışı ancak gerçek girdiler başlık, kaynak ve görsel hatalarını ortaya çıkardıktan sonra güvenilir olmuş.

Bir görev nihayet çalıştığında şunu söyle:

Bunu henüz otomatikleştirme. Başarılı olan yöntemi çıkar.

Şunları içeren bir taslak Skill oluştur:
NE ZAMAN KULLANILIR / GİRDİLER / YETKİLİ KAYNAKLAR /
SÜREÇ / KARAR KURALLARI / DOĞRULAMA / ÇIKTI SÖZLEŞMESİ /
HATA DURUMLARI / ONAY SINIRLARI / YASAK EYLEMLER

Ayrıca ekle:
BAŞARISIZ DENEMELERDEN DERSLER
(bu görevde verdiğim her düzeltmeyi listele ve tekrar
edebilecek olanları kurala çevir)

Sonra Skill'i farklı bir gerçek örnekte test et.
Rutini ancak ondan sonra konuşuruz.

En iyi skill yazabileceğin en akıllı prompt değil. Daha önce yanlış giden her şeyin sıkıştırılmış tarihi.

12. Her ciddi otomasyonun önüne üç kapı koy

Çin'deki Grok Bot topluluğunun muhtemelen en değerli tekniği bu. Xiaohongshu'daki bir hattın tekrar tekrar çalışmasına izin verilmeden önce sahibi üç sert sınır koymuş: içerik onaylı kaynak olmadan ilerleyemiyor, rakamlar bir kanıt katmanından geliyor, AI yayın paketini hazırlıyor ama yayınlayan insan. Bu desen içeriğin çok ötesinde çalışıyor:

Bunu her ciddi iş akışına koy:

Bu iş akışının üç zorunlu kapısı var.

KAPI 1: KAYNAK
Akıl yürütmeden önce gereken girdilerin onaylı, yetkili
bir kaynaktan geldiğini doğrula. Değilse: DUR.

KAPI 2: KANIT
Sonucu olan bir çıkarım yapmadan önce her önemli rakamı,
iddiayı ve durumu kanıta karşı doğrula.
Ayır: DOĞRULANDI / ÇIKARIM / BİLİNMİYOR.
Kanıt yetersizse: DUR ya da eksik olarak işaretle.

KAPI 3: EYLEM
Sonucu olan her dış eylemden önce eylemi incelenmek
üzere hazırla. Gereken onay olmadan gönderme, yayınlama,
satın alma, silme, transfer, imza, üretim değişikliği ya
da izin değişikliği yapma.

Bir Rutin hiçbir kapıyı atlayamaz.

Kapısı olmayan otomasyon tehlikeli: hem yetkisi var hem de çıktısını kimse kontrol etmiyor.

13. Olay tetikleyicileri sürekli kontrolden iyidir

Diyelim ki bir Bot müşteri yükseltmelerini yakalasın istiyorsun. Basit kurulum: 10 dakikada bir Slack'e bak. Bot sürekli uyanıyor, çoğu koşuda hiçbir şey bulmuyor, kullanım hakkı yanıyor. Oysa Grok Bot rutinleri eşleşen Slack mesajları ya da GitHub bildirimleri gibi olaylarla tetiklenebiliyor. SpaceXAI de "her yeni mesaj" gibi geniş dinleyicilere karşı açıkça uyarıyor.

"10 dakikada bir #support kanalını kontrol et" yerine şunu yaz:

#customer-escalations kanalından bir olay geldiğinde:

Sadece HEPSİ doğruysa tetiklen:
- mesajda destek bileti URL'si var
- müşteri önceliği P1 ya da P2
- mesajda "needs repro" ya da benzeri yükseltme ifadesi var

Sonra:
1. Bileti aç.
2. Güncel kanıtı topla.
3. Onaylı ortamda yeniden üretmeyi dene.
4. Bir repro paketi oluştur.
5. Beni sadece şu durumlarda bilgilendir: yeniden üretim
   başarılı, önemli bilgi eksik, sorun yükseltme
   kriterlerini karşılıyor.

Aksi halde sessizce bitir. Onaysız dışarıya hiçbir şey yazma.

Sürekli "yapacak bir şey var mı" diye soran bir AI çalışanı istemiyorsun. İşin onu uyandırmasını istiyorsun.

14. İyi bir rutin çoğu zaman sessizdir

İnsanlar otomasyonu rapor üretsin diye kuruyor. Her sabah: "İşte kontrol ettiğim 34 şey." Tebrikler, işi işle ilgili okumayla değiştirdin. Gözetimsiz çalışan iyi bir Bot çoğu zaman görünür hiçbir şey yapmamalı. İstisnaları, kararları, hataları, anlamlı değişimleri ve değerli fırsatları öne çıkarmalı; uyanık olduğunun kanıtını değil. Resmi Grok Bot rehberi de bayat veri davranışını, veri yok davranışını, idempotent (tekrar edildiğinde aynı sonucu veren) yeniden denemeleri ve kısmi tamamlanma raporunu tanımlamayı öneriyor.

"Sessiz başarı" kuralını kur:

Bu Rutin istisnayla çalışır.

NORMAL BAŞARILI DURUM: Bana mesaj atma.

Beni sadece şu durumlarda bilgilendir: bir eşik aşıldı,
yeni anlamlı bir madde çıktı, kaynak ulaşılamaz oldu, bayat
veri sonucu etkileyecek, güvenli yeniden denemelerden
sonra görev başarısız oldu, onay gerekiyor, insan kararının
gerçek değeri var, sonuç önceki koşudan belirgin farklı.

YENİDEN DENEME POLİTİKASI:
Yeniden denemeler idempotent olmalı. Mesaj, satın alma,
yükleme, kayıt oluşturma ya da başka dış değişiklikleri
tekrarlama.

İşin bir kısmı başarılıysa onu koru ve sadece engellenen
kalanı raporla.

İyi otomasyonun ölçüsü ne kadar sık konuştuğu değil. Onu ne kadar az düşünmen gerektiği.

15. Tam denetim izi henüz yok, kendi kanıt izini oluştur

Kurumsal dokümandaki en az konuşulan detaylardan biri: SpaceXAI şu an kullanım ve harcama bilgisini gösteriyor, Bot eylemlerine dair daha geniş bir denetim görünümü ise "geliyor" diye anlatılıyor. Yani ciddi kullanıcılar kusursuz gözlemlenebilirliği beklememeli. Hafif bir denetim izini şimdi kendin kur:

Sonucu olan her iş akışı için ACTION_LOG.md tut.

Her koşuda ekle:
ZAMAN DAMGASI / BOT / TETİKLEYİCİ / İSTENEN SONUÇ /
ERİŞİLEN KAYNAKLAR / OLUŞTURULAN YA DA DEĞİŞEN DOSYALAR /
ÖNEMLİ İDDİALAR / DENENEN DIŞ EYLEMLER / TAMAMLANAN DIŞ
EYLEMLER / İSTENEN ONAYLAR / ALINAN ONAYLAR / HATALAR /
DOĞRULANMAMIŞ MADDELER / SON DURUM

Loga parola, token, tek kullanımlık kod ya da gereksiz
hassas içerik yazma.

Sonra başka bir Bot'a örneklem denetimi yaptır: her cuma, sonucu olan kararlar içeren 5 tamamlanmış koşu seçsin; kaynak kalitesini, dayanaksız iddiaları, yanlış rakamları, atlanan onay sınırlarını, tekrar eden hataları ve gereksiz araç çağrılarını bağımsız incelesin; geçme oranını, tekrar eden hata desenlerini, eklenmesi ya da kaldırılması gereken kuralları ve yeniden eğitim gereken Botları döndürsün. Sistem böyle iyileşiyor ve sen her görevi tek tek yeniden okumuyorsun.

16. Auto-review bir politika motoru, kalkan değil

Grok Bot eylemleri Auto-review (otomatik inceleme) kurallarına göre değerlendirebiliyor. Şaşırtıcı derecede işe yarayan bir detay: iki kural aynı eyleme uyuyorsa "Onay Gerekir", "Her Zaman İzin Ver"i yeniyor. SpaceXAI ayrıca Auto-review'ın model tabanlı olduğunu ve güvenlik sınırı olarak görülmemesi gerektiğini açıkça söylüyor. O yüzden "tarayıcı kullanımına her zaman izin ver" yazma. Dar kurallar yaz:

HER ZAMAN İZİN VER: onaylı herkese açık kaynakları okuma,
/workspace/drafts içinde taslak oluşturma, salt okunur repo
incelemesi, iç analiz dosyaları oluşturma.

ONAY GEREKİR: dışa e-posta, herkese açık paylaşım, satın
alma, finansal işlem, izin değişikliği, dış veri silme,
üretim değişikliği, sözleşme ya da şart kabulü, hassas
bilgi yükleme.

Önemli fikir şu: özerklik Bot'un kişiliğine göre değil, eylem sınıfına göre verilir. "Araştırma Bot'una güveniyorum" deme. "Şu kaynaklardan salt okunur araştırmaya güveniyorum" de. Bu çok daha güvenli bir cümle.

17. AI çalışanlarına kendi kimliklerini ver, seninkini değil

Bütün Botlar aynı bulut makinesini ve oturumları paylaşabildiği için kendi ana hesabını her yerde kullanmak başka bir sorun doğuruyor: dış sistemler seni görüyor, hangi iç Bot'un ne yaptığını bilemiyor. Servis destekliyorsa daha iyi desen kapsamı dar servis kimlikleri: ayrı bir posta kutusu, kısıtlı topluluk hesabı, salt okunur analitik kullanıcısı, kapsamı dar bir CRM koltuğu, Bot'a özel API ya da servis hesabı. SpaceXAI de en az yetkiyi öneriyor ve ilk Grok Bot kullanıcıları ajanlara ayrı posta kutusu ve hesap açmış; böylece ajanlar sistemlere kurucunun şifresiyle değil, çalışan olarak davet ediliyor.

Her dış sistem için en güvenli kimliği seç:
A. Salt okunur bağlayıcı   B. Kapsamı dar servis hesabı
C. Bot'a özel çalışan hesabı   D. Kişisel hesabım   E. Erişim yok
A-C'yi tercih et.

Seçilen kimlik için gereken izinleri, görebildiği veriyi,
yapabildiği eylemleri, etkinliğin nasıl ilişkilendirileceğini
ve erişimin nasıl geri alınacağını tanımla.
Sadece kolay diye daha geniş erişim isteme.

Gerçek bir şirket her stajyere kurucunun parolasını vermez. Bunun dijital versiyonunu yapma.

18. Grok Bot'un bilgisayarını tek kullanımlık altyapı gibi gör

Grok Bot'un sohbet geçmişi bulut makinesinden ayrı saklanıyor: Cursor'ın kurtarma dokümanına göre kutunun içindeki dosyaları silmek bile geçmişi yok etmiyor. Ama Cursor desteği bazı bilgisayar yenilemelerinden sonra sadece /workspace içindeki proje dosyalarının, tarayıcı profilinin ve yapılandırma dizinlerinin kaldığını, diğer makine durumunun gidebileceğini belgelemiş. Kendi makinendeki yerel dosyalar için de kendi yedeğin gerekiyor.

Yani bulut bilgisayarını sonsuza dek özenle ayarladığın el yapımı bir sunucu gibi görme. Değiştirilebilir altyapı gibi gör. Önemli durumun yetkili dış sistemlerde, /workspace içinde, sürüm kontrolünde, tekrarlanabilir kurulum talimatlarında, skill'lerde ve Bot sözleşmelerinde olsun. Üç hafta önce elle kurduğun bir paketin içinde değil.

Bu Grok Bot bilgisayarını kırılgan durum için denetle:
elle kurulmuş yazılım, geçici dizinler, belgelenmemiş
makine durumu, senkronize edilmemiş dosyalar, kabuk
geçmişi, tek seferlik elle yapılandırma.

Her bağımlılık için kalıcı gerçeği /workspace, sürüm
kontrolü, yetkili bir dış sistem, tekrarlanabilir bir
kurulum scripti ya da belgelenmiş bir Skill içine taşı.

Makine yeniden kurulabilir olmalı. Hiçbir kritik iş süreci
bu sanal makineyi elle nasıl ayarladığımızı hatırlamaya
bağlı olmasın.

En iyi Grok Bot sistemi bilgisayarını kaybetse de ayakta kalır. Çünkü organizasyon bilgisayar değil. Organizasyon, işi yeniden kurabilen kurallar, kaynaklar, artefaktlar, roller ve devirler.

Topluluk şimdiden belgelenmemiş yollara giriyor

Grok Bot'un etrafında şimdiden gayri resmi bir ekosistem oluşuyor: resmi arayüzün dışından ajan seçen, durum sorgulayan ve skill çağıran Telegram köprüleri gibi projeler var. Bunların bir kısmı Grok Bot ortamındaki belgelenmemiş bir iç ağ geçidine dayanıyor ve Cursor çalışanları bu mekanikleri açıkça belgelenmemiş diye tarif ediyor.

Asıl mesele

Çoğu kişi Grok Bot'u şöyle kullanacak: 12 ajan yarat, her birine zekice bir isim ver, her şeyi bağla, her şeyi zamanla, sürekli düzelt, kullanım hakkını yak, sonunda uygulamayı açmayı bırak. İlk topluluk raporları bunu şimdiden gösteriyor: karmaşık çoklu Bot kurulumu olan kullanıcılar takılan ajanlardan, süresi geçen onaylardan, kaçırılan zamanlanmış işlerden ve hızla tükenen kullanım hakkından şikâyet ediyor. Grok Bot hâlâ beta.

Cevap daha iyi bir 2.000 kelimelik prompt değil. Daha iyi organizasyon tasarımı:

1. Tek bir koordinatörle başla.
2. Ona neredeyse hiç üretim sorumluluğu verme.
3. Tek bir gerçek iş akışını çalıştır.
4. İlk darboğazı bul.
5. Bir uzman işe al.
6. Onun doğruluk kaynağını tanımla.
7. Ne yapamayacağını tanımla.
8. Ona bir artefakt ürettir.
9. Hatanın önemli olduğu yere bağımsız bir doğrulama katmanı ekle.
10. İş akışını yeniden çalıştır.

Tekrar eden her hata kurala, güvenilir her süreç skill'e dönüşür; olgunlaşan skill bir rutin alır; her rutin kaynak, kanıt, hata ve eylem politikası alır. Sürekli sorgulama yerine olayları kullan, değişen gerçekleri hafızanın dışında tut, kritik durumu makinenin dışında tut. Mekanik işi ucuz işçilere, zor akıl yürütmeyi güçlü modellere, kodu Cloud Agent'lara bırak; Grok Bot koordine etsin. Geri alınamayan son karar sende kalsın.

En büyük hata Grok Bot'un sana AI çalışanları verdiğini düşünmek. Vermiyor; sana bir AI organizasyonu kurmak için yapı taşları veriyor. Çalışanlar görev yapar. Organizasyonlar görevin sahibini, doğrunun nerede yaşadığını, işin nasıl aktığını, kimin kontrol ettiğini, hata olunca ne olacağını ve patronun ne zaman rahatsız edileceğini belirler. Bu kurallar kurulunca tek tek modelin, prompt'un, hatta Bot'un önemi azalıyor. Çünkü artık üçünü de aşan bir şey var: bir sistem.