Önceki yazımda, doğrulamanın ajanlarla yaptığım her şeyin temeli olduğunu ve kendi doğrulama becerilerinizi oluşturmaya nasıl başlayacağınızı göstermiştim. Ana ders şuydu: Bir ajan kendi işini doğrulayamıyorsa, diğer hiçbir şeyin önemi kalmaz. Siz darboğaz olarak kalırsınız ve tüm gününüzü ajanlarınıza bakıcılık yaparak geçirirsiniz.
https://x.com/poteto/status/2094457600259842065
Ancak doğrulama çalışmaya başladığında, sıradaki soru şu: Aslında ne inşa edeceğinizi nasıl anlayacaksınız?
https://x.ai/bot/plugin/9717366
Bu yazıda, pstack ile araştırma, planlama, prototipleme ve mimariyi nasıl yaptığımı adım adım anlatacağım. Bu, kod kalitesini olağanüstü yüksek tutarken ayda binlerce PR'ı üretime göndermemi sağlayan tam iş akışıdır.
Ağustos ayını üretimde 2.462 PR ile bitirmek
Sizden daha zeki birini denetleme sanatı
2024'ün eski günlerinde, bir sistemde herhangi bir değişiklik yapmak için önce sistemin ne yaptığına dair bir zihinsel model oluşturmak adına yeterince okumanız gerekiyordu. Kod tabanının boyutuna ve karmaşıklığına bağlı olarak, bu size saatler, hatta günler ve aylar sürebilirdi. Küçük bir değişiklikle, belki sadece küçük bir alt sistemin yerel olarak anlaşılmasıyla idare edebilirdiniz. Ancak çekirdeği yeniden düzenliyorsanız, yeniden düzenlemeyi doğru ve etkili bir şekilde yapmak için muhtemelen tüm sistemin nasıl çalıştığına dair bir zihinsel modele sahip olmanız gerekirdi.
Ajanlar açıkçası bu engeli kaldırır. Sadece ajanınıza komut vererek sistemlerde çok kolay bir şekilde değişiklik yapabilirsiniz ve kod hakkında ne kadar az veya çok bilginiz olursa olsun, ajan bunu yapacaktır. Ancak kodun ve kullanıcı deneyiminin kalitesini yüksek tutmak hala zordur, özellikle de neye bakacağını ve neyi soracağını bilen bir alan uzmanı değilseniz.
Sınır modelleri çok yetenekli hale gelmiş olsa da, sürekli gözlemlediğim 2 başarısızlık modu var:
- Niyetinizi tam olarak anlayamazlar çünkü yetersiz/kötü belirtilmiştir.
- İşi doğru bir şekilde nasıl yapacaklarına dair yeterli bağlama sahip değillerdir.
Bu sorunların her ikisi de birbiriyle ilişkilidir. Ajanları iyi kullanmak, ajanın bağlam penceresini yüksek kaliteli bağlamla ne kadar iyi hazırlayabildiğinize bağlıdır. Bunu yapmadan çalışan kod yazabilirsiniz, ancak ajanlarıma yüksek kaliteli bir iş çıkarmaları için ihtiyaç duydukları her şeyi sağlama işini yaptığımda sonuçların ve kalitenin çok daha iyi olduğunu görüyorum.
Kendi kelimelerinizle
Sınır modelleri çok yetenekli kod yazıcılarıdır. Eski modellerle ne yapmasını istediğimi çok spesifik olarak belirtmem gerekirken, neredeyse onları mikro düzeyde yönetirken, en son modeller sizin veya benim yazabileceğimden daha iyi kod yazabiliyor. Bu nedenle, ajana neyi başarmasını istediğimi söylemek ile ona benim aklıma gelmeyen şekillerde çözme özgürlüğü vermek arasında ince bir denge kurmak istiyorum.
Bu, sizden daha zeki birini, kendinizin yazmadığı bir kod tabanında ve insanların artık kod tabanının tüm zihinsel modelini kafalarına sığdıramadığı bir ortamda denetleme sanatıdır.
Kullanmayı sevdiğim bir teknik, dolaylı komuttur. Ajana tam olarak ne istediğimi söylemek yerine, onu ajandan çıkarmaya çalışıyorum - kendi kelimeleriyle.
Örneğin, birisi Slack'te bir sorun bildirdiğinde, ajandan başka bir şey yapmadan önce konuyu okumasını ve sorunu kendi kelimeleriyle yeniden ifade etmesini isterim.
Örneğin, şöyle diyebilirim:
/poteto-mode bu slack konusunu oku. altta yatan sorunun ne olduğunu düşündüğünü kendi kelimelerinle ve düz bir dille yeniden ifade et
Bu üç şeyi başarır:
İlk olarak, ajana gürültülü bir konuşmayı yapılandırılmış bir problem ifadesine sıkıştırmasını zorlar. İkinci olarak, yanlış anlamaları hemen yakalamamı sağlar. Ajan konudaki yanıltıcı bir ayrıntıya takılırsa, herhangi bir kod yazmaya başlamadan önce onu hızlıca düzeltebilirim.
Ve üçüncü olarak, yanlış olabilecek veya ajanın başka türlü başarabileceklerini sınırlayabilecek kendi varsayımlarımı ve hipotezlerimi belirterek onu potansiyel olarak yanlış yola yönlendirmemiş olurum.
Bir zihinsel model oluşturmak
Ajandan, anlayabileceğiniz bir şekilde kendini yeniden ifade etmesini istemek, sizden daha zeki biriyle çalışmanın önemli bir parçasıdır. /teach becerisine ilham kaynağı olan da buydu; bu beceri, ajanınızın size bir şeyleri sezgisel bir şekilde açıklamasına yardımcı olur. Ajanımın bana mantıklı gelen bir şey yaptığından emin olmam gerektiğinde bunu kullanırım.
Perde arkasında, /teach, /how ve /why becerilerini çağırır.
/how, çalışma zamanı mekaniğini izler. /how diye sorduğunuzda, ajan alt sistemin karmaşıklığını değerlendirir. Alt sistem birden çok dizini veya hizmeti kapsıyorsa, Grok gibi hızlı, verimli modellerde paralel keşif ajanları başlatır.
/how sanallaştırma nasıl uygulanıyor?
/why, motivasyonu ve amacı araştırır. Kod size ne olduğunu söyler. Size nadiren birisinin neden bu şekilde yazdığını söyler. /why çalıştırdığınızda, pstack birden çok kaynaktan geçmişe dair kanıtları paralel olarak sorgular: Git geçmişi ve PR inceleme yorumları, Linear biletleri, Notion tasarım belgeleri, Slack konuşmaları, Datadog monitörleri, Sentry hataları, kod soyu ve analitik ambarı olayları.
/why neden hala eski bir node.js sürümünde takılıp kaldık?
Ajanın bir şeyi daha iyi anlayabilmem ve çalışmasına güvenebilmem için yeniden ifade etmesini istediğimde /teach kullanırım.
/teach bana neden bu şekilde uyguladığını ve <diğer yol> ile değil. yaptığın ödünleşimler nelerdi ve neden?
Pratikte, /teach becerisi tarafından yapılan araştırmanın sadece insanlar için değil, ajanlar için de yararlı olduğunu buldum. En son sınır modelleriyle bile (bu aynı zamanda koşum takımının kalitesine de bağlıdır), genel olarak, hala sık sık bir şeyleri veriyle desteklemeden veya nasıl çalıştığına dair bir zihinsel model oluşturmak için gereken kodu fiilen okumadan kendinden emin bir şekilde ifade ettiklerini görüyorum. Yani size ne yapacağını ve neden yapacağını öğretme eylemi, sonuçta ajana da yardımcı oluyor.
Geçmişten öğrenmek
Projelerimin çoğu birden çok konuşmayı kapsar. Örneğin, birkaç ay önce Cursor'da insanların bildirdiği sanallaştırma hatalarını ve performans sorunlarını düzeltmek üzerinde çalışıyordum. Her yeni bir sohbet başlattığımda, ajanımın daha önce benzer bir sorunu çözerken sahip olduğu zengin bağlamı oluşturmaya temelde yeniden başlamam gerektiğini fark ettim.
Fark ettiğim şey, geçmiş konuşma kayıtlarınızın genellikle zengin bağlam için bir altın madeni olduğudur. pstack, sohbet geçmişinizden yakın zamandaki bağlamınızı çekmek için /recall becerisiyle birlikte gelir, böylece yeni ajanlar bile iyi bir duruma geri dönmek için ihtiyaç duydukları doğru bağlama sahip olur.
/recall dün sanallaştırma üzerinde yaptığım çalışmayı ve ardından slack'teki bu hata raporunu oku
/teach, /recall, /how ve /why kullanmak, kod tabanına dair kendi zihinsel modellerimi güncel tutma, kolayca anlayabileceğim ve hatırlayabileceğim bir biçimde sıkıştırma yöntemimdir. Ve ajanlara da yardımcı oluyor!
Geriye doğru çalışmak
Sorunu anladıktan sonra, çözümü nasıl belirlersiniz?
Bence, plan modlarına sahip çoğu koşum takımı, uygulama ayrıntılarını aşırı belirtme ve diğer her şeyi eksik belirtme eğilimindedir. Bu yüzden pstack'te, "planlamaya inanmadığımı" arsızca söyledim. Gerçek şu ki plan yapıyorum, ancak bunu kod aracılığıyla yapıyorum.
Başkalarının kullanacağı paylaşılan kod veya paketler oluşturmak gibi belirli iş türleri için, readme odaklı geliştirmeye büyük bir inancım var. Eğer aşina değilseniz, bu, geçmişte popüler olan bir geliştirme tekniğidir; burada önce readme'nizi hazırlayarak başlarsınız. Bu sizi geliştirici deneyimi şapkanızı takmaya zorlar, burada varsayımsal bir kullanıcıya API'leri tanımlayarak başlar ve uygulama ve mimariye doğru geriye doğru çalışırsınız.
Örneğin, masaüstü uygulamaları için dahili istemci çerçevemiz Dune'u inşa ederken, önce bunun için bir eğitim yazarak başladım, böylece onunla bir uygulama oluşturmanın nasıl bir şey olacağını anlayabilirdim. Ya da en azından denedim. Ajandan iyi veya okunabilir bir şey üretmesini sağlamak gerçek bir mücadeleydi. Bu yüzden önce /technical-writing becerisini oluşturarak bıçağımı bilemek için biraz zaman harcamam gerekti.
/technical-writing becerisi olmadan readme'nin ilk geçişini okumak acı vericiydi çünkü farklı hedefleri birbirine karıştırıyordu. Her zamanki AI slop ve yapmacık düzyazınız ile yazılmış, aynı belgede bir eğitim, bir nasıl yapılır kılavuzu, bir mimari açıklama ve bir API referansı olmaya çalışıyordu.
/technical-writing, dokümantasyonu dört farklı moda ayırmak için Diátaxis çerçevesini kullanır:
- Eğitim: Yaparak öğrenme. Yeni başlayan birini görünür bir şey inşa etmek için bir dizi adımda yönlendiren bir derstir.
- Nasıl yapılır kılavuzu: Deneyimli bir kullanıcı için belirli, gerçek dünya sorununu çözme adımları.
- Referans: Makinelerin, API'lerin ve yapılandırma bayraklarının kuru, eksiksiz, otoriter teknik açıklamaları.
- Açıklama: Arka planı, tasarım seçimlerini ve ödünleşimleri netleştiren ve aydınlatan üst düzey tartışma.
Ayrıca /unslop kullanır, bu nedenle çok okunabilir dokümantasyon üretir.
Bu şekilde bir plan yazmak çok faydalıdır çünkü ajanlarınıza aynı zamanda kendi çalışmalarını kontrol edebilecekleri somut bir hedef ve amaç verir. Ve elbette, ajanın tam olarak ne inşa edeceğini anlamak da çok daha kolaydır.
pstack'in becerilerinin çoğu, tasarım aşamasında burada birleşir. Örneğin:
(1) /recall son 7 gündeki sanallaştırma hatalarını ve performans sorunlarını düzeltme çalışmalarımı. mevcut sanallaştırma uygulamamızın nasıl çalıştığını anlamak için /how ve /why kullan.
(2) ardından, titreme ve sarsılmayı kategorik olarak ortadan kaldıran yeni bir sanallaştırma motoru bulmak için /poteto-mode planning ve /technical-writing kullan. bu yeni paketi bir React uygulamasını sanallaştırmak için nasıl kullanacağıma dair bir eğitim yazarak başlayalım
(3) planı yazdıktan sonra, /teach bana ve bu yeni yaklaşımın neden mevcut motorumuzdan üstün olduğunu kanıtla
Buradaki teknik gerçekten de ajanlarınıza sorunu sizinle aynı şekilde görme yeteneği veren ilginç ve zengin bağlamı ortaya çıkarmakla ilgilidir - sadece küçük bir dilim olarak değil:
- Komutun ilk kısmı, uygulamamda sanallaştırmanın nasıl uygulandığına dair ilgili geçmiş ve mevcut bağlamı hatırlar.
- İkinci kısım, ajana, daha önce düzelttiği hatalar gibi bu bağlamı kullanarak bu sorunları tamamen ortadan kaldıran yeni bir tasarım bulması için rehberlik eder.
- Son kısım, ajanınızdan size bu yeni paketin üstün olduğunu kanıtlamasını istemektir. Burada doğrulama becerileri gibi yüksek kaliteli araçlara sahip olmak önemlidir.
Yüz kere ölç, bir kere kes
Planlama yaparken gördüğüm en yaygın iki hata şunlardır:
- Ajanın ilk tasarımını kabul etmek.
- Ampirik kanıt olmadan planı aşırı pişirmek.
İnsanlar kod yazarken, genellikle tasarım belgeleri üzerinde birbirimizle işbirliği yapardık. Bunlar, üst düzey mimari, düşünülen alternatifler, ödünleşimler ve olağandışı uygulama notları hakkında konuşan belgelerdi. Kesinleşmiş bir tasarıma ulaşmadan önce bu belgelerin birden çok yinelemesinden geçmek çok yaygındı.
Ajanlarla, tasarım belgesinin formalitesini atlayabilsek de, ajanın size geri verdiği ilk şeyi kabul etme hatasını sık sık görüyorum. pstack ile bunun yerine, paralel ajanlar kullanarak "iki kere ölç, bir kere kes" yaklaşımını sınırına kadar götürebiliriz.
Bunu prototipleme oyun kitabını kullanarak yapıyoruz.
pstack'te oyun kitapları beceri değil, /poteto-mode içindeki referans dosyalarıdır. Bu oyun kitapları, üzerinde çalıştığınız görevin türüne bağlı olarak (token verimliliği için) koşullu olarak yüklenir. Bu 23 oyun kitabı (0.15.0 itibarıyla), her biri bir görev üzerinde çalışırken kullandığım bir iş akışını içerir.
Becerilerin aksine, oyun kitapları /poteto-mode'un bir parçası olarak ajan tarafından otomatik olarak kullanılır. Örneğin:
/poteto-mode yeni açılır menü için birkaç seçeneği prototiple /poteto-mode bu hatayı düzelt /poteto-mode bu beceri değişikliğini değerlendir
Prototipleme, en sevdiğim pstack oyun kitaplarından biridir. Size bir hedefe yönelik birçok deneme verir ve ajanın en iyi seçeneği değerlendirmesine yardımcı olur. Bu sadece görsel prototipleme için değil, aynı zamanda özellikler, hata düzeltmeleri vb. için farklı çözümleri prototiplemek için de kullanışlıdır.
/poteto-mode <özellik talebi> için birkaç seçeneği prototiple. incelemem ve aralarından seçim yapmam için /control-app* kullan ve videolar/ekran görüntüleri al
\ not: /control-app, [Bölüm 1]([https://x.com/poteto/status/2094457600259842065](https://x.com/poteto/status/2094457600259842065))'de oluşturduğumuz doğrulama becerisidir*
Görsel değişiklikleri prototiplenirken, ajan uygulamanızda veya bir karalama dizininde tek kullanımlık eskizler oluşturur. Bir UI etkileşimini test ediyorsa, iki veya üç varyasyonu basit bir değiştiricinin arkasına koyar. Ardından /control-app becerisiyle etkileşimi yönlendirir, her varyantın ekran görüntülerini alır ve gerçek zamanlamayı veya düzeni ölçer.
Prototipleme, planlamadır, ancak kodla. Ajanların sorun alanını keşfetme özgürlüğüne sahip olmasını sağlar ve onlara kendi başınıza düşünemeyeceğiniz bir şeyle sizi şaşırtma şansı verir. Prototipler, ajanların kendi sorularını benim girdimi beklemek yerine ampirik kanıtlarla yanıtlamalarını sağlar.
Daha büyük değişiklikleri mimarileştirmek
Ajan çağında bir mühendis olarak, zamanımı mimariye, doğru veri yapılarını seçmeye ve inşa ettiğim sistemlerin birlikte nasıl çalışacağını düşünmeye harcamam daha önemlidir. Ajanlarım uygulama ayrıntılarını doldurur.
pstack ile birlikte gelen bir diğer kullanışlı beceri de /architect'tir. Tasarımı farklı, disiplinli aşamalara yapılandırır:
- Sorunu temellendirin. Ajan, mevcut sahiplik ve kısıtlamalar hakkında doğru bir zihinsel model oluşturmak için etkilenen sistemler üzerinde /how ve /why çalıştırır.
- Eskiz yapın. Ajan bir mimari arenasına girer. Genellikle farklı model ailelerinde olmak üzere, paralel olarak bağımsız aday çalıştırıcıları başlatır. Her çalıştırıcı, temellendirme brifingini alır ve eksiksiz bir tasarım paketi hazırlar: arayanın kullanım taslağı, çekirdek tür tanımları, genel işlev imzaları ve kısa bir gerekçe. Bunlar genellikle, çağrı sitelerinin nasıl görünmesini istediğimizden türetilen, yalnızca tür imzalarının taslağını çizerek yapılır. Her çalıştırıcı, arayüz derinliğini değerlendirmeli, zayıf modellerdeki başarısızlık modlarını incelemeli ve tasarım kırmızı bayrak kataloğumuza karşı tarama yapmalıdır.
- Çapraz değerlendirin ve Sentezleyin. Ana ajandan farklı bir model kullanan bir çapraz değerlendirme ajanı, adayları katı bir rubriğe karşı değerlendirir.
- Eskize karşı uygulayın. Ajan, eskizin yer tutucu gövdelerini gerçek mantıkla değiştirir. Ajan, uygulama sırasında bir işlevin beklenmeyen parametrelere veya ekstra duruma ihtiyaç duyduğunu keşfederse, tutarsızlığı yüzeye çıkarır.
- Tasarım yanlış olduğunda hurdaya çıkarın. Uygulama sırasında eskizlerin yanlış olduğunu tespit edersek, ajan her şeyi atar ve yeniden başlar.
Buradaki amaç, ajana, farklı model ailelerinden gelen birden çok rakip tasarımı en uygun bir yaklaşımda sentezleyebileceği, titiz olmaya özen göstereceği ve ampirik kanıtlara dayanarak bulduğu mimarinin yanlış olduğu ortaya çıkarsa tasarımını atmaktan korkmayacağı, kendi kendine yeten bir mini döngü vermektir. Aynı geçici çözüm, ilgisiz çağrı sitelerinde görünüyorsa veya türler 𝚊𝚗𝚢 veya zorlamalı dönüşümler gibi kaçış kapakları gerektiriyorsa, bu, mimarinin yanlış olduğunun ampirik kanıtıdır.
/architect bu yeni <özellik talebi>
Buradaki büyük ders, /poteto-mode prototipleme ve /architect kullanarak kodla plan yapmanın çok daha etkili olduğudur.
Ayrıca soyut planları düşmanca incelemekle asla uğraşmamamın nedeni de budur. Ajanlar teorik riskler hayal etmeye ve asla gerçekleşmeyecek sorunlara karşı korunmak için karmaşık uç durumlar icat etmeye başlar. Planlarınız hala soyutken onları aşırı pişirmeyin: ajanın açık soruları prototipleme ve kendi çalışmasını doğrulama yoluyla kendi başına yanıtlamasına izin verin.
Tamam ama gerçekten bir planlama belgesi istiyorum
pstack bir planlama becerisiyle gelmese de, çok aşamalı planlama oyun kitabı ile birlikte gelir. Bunu tipik olarak, ajan memnun olduğum bir tasarımla ortaya çıktıktan sonra, taktiksel bir uygulama planı oluşturmanın bir yolu olarak kullanırım.
/poteto-mode bu tasarımı bir plana dönüştür
Plandaki her bir görev, kanıt ve doğrulama etrafında yapılandırılmıştır. Oyun kitabı, ajanlara testlerin tek başına yeterli doğrulama olmadığını söyler. Yalnızca kodu fiilen çalıştırdığında ve çalıştığını doğruladığında doğrulanmış olur.
Her plan, yapısını ve biçimlendirmesini doğrulayan otomatik bir komut dosyası tarafından kontrol edilir. Onaylandıktan sonra plan, madde madde yürütülür. Her PR küçük, kendi kendine yeten ve kolayca incelenebilirdir.
Gerçekten büyük projeler için (beni tam bir hafta alabilecek bir proje gibi), bazen planları geçici olarak kod tabanına işlemeye karar verebilirim, böylece diğer ajanlar devam eden çalışmadan haberdar olur. Ancak işim bittiğinde genellikle onları silerim, böylece kod tabanını kafa karışıklığı içinde bırakmam. Planları kalıcı olarak saklamayı değerli bulmuyorum.
Pratikte iş akışı
Tüm bu parçaların nasıl bir araya geldiğini görmek için, bu iş akışlarını nasıl yönlendirdiğime dair üç somut örnek üzerinde geçelim.
Örnek 1: Belirsiz bir hatayı araştırmak
Üretimde bir sorun ortaya çıktığında ve temel neden net olmadığında:
/poteto-mode arka plan çalışanlarının neden periyodik olarak zaman aşımı hatalarıyla başarısız olduğunu araştır. bana bildiklerimizin, kullandığın verilerin ve en iyi hipotezlerinin bir dökümünü ver.
Ajan kodu keşfeder, paralel olarak metrikleri ve geçmiş taahhütleri kontrol eder ve size sorunun nerede olabileceğine dair en iyi tahminlerini verir.
Örnek 2: Yeni bir hizmet sınırı tasarlamak
Diğer modüllerin bağımlı olacağı yeni bir alt sistem tanıtılırken:
/poteto-mode harici web kancaları için hız sınırlaması eklememiz gerekiyor. önce bunu /architect ile yap ve açık soruları prototiplerle yanıtla. devam etmeden önce incelememe izin ver.
Ajan, mevcut web kancası mimarisini temellendirir, birden çok modelde rakip tasarım çalıştırıcılarını başlatır, tek kullanımlık prototiplerle kıyaslama yapar ve temiz, doğrulanmış bir arayüz üretir.
Örnek 3: Çoklu PR geçişini yürütmek
Birçok dosyada karmaşık bir yeniden düzenleme yapılırken:
/poteto-mode tüm UI kütüphanemizi StyleX'e taşımak için bir plan oluştur. geçişi küçük, doğrulanabilir PR'lara böl. her PR'ın görsel regresyon testleri ve canlı doğrulama adımları olmalı. nihai sonucun orijinaliyle %100 aynı olmasını istiyorum - hatalar dahil
Ajan, işi bağımsız adımlara böler, denetlenebilir bir kontrol listesi yazar ve her birimi güvenli bir şekilde oluşturulabilecek, doğrulanabilecek ve teslim edilebilecek şekilde hazırlar.
Örnek 4: Slack'te bildirilen sorunları düzeltmek
Beni Slack'teki sorunlarımızdan veya geri bildirim kanallarımızdan birinde gördüyseniz, muhtemelen şu klasikleri görmüşsünüzdür:
# konu zaten yeterli bağlama sahip
/poteto-mode yap şunu
/poteto-mode bunu /control-app ile yeniden üret. main'de yeniden üretiyorsa, düzelt ve bana kanıt olarak bir video göster
Burada bahsettiğim becerilerin çoğu, /poteto-mode tarafından zaten otomatik olarak kullanılıyor, bu nedenle zamanın büyük çoğunluğunda sadece /poteto-mode kullanabilir ve hayatınıza devam edebilirsiniz!
Planlama sanatı
Plan Modu, genellikle ajanın doğru şeyi yapacağına kendinizi inandırmanın bir yolu olarak kullanılır. Ancak gerçek şu ki, soyut planlar size yalnızca ilerleme yanılsaması verir. Uzun ve ayrıntılı bir plan, sizin ve ajanınızın çok üretken olduğunuzu gösterir, ancak muhtemelen içerikten yoksundur.
pstack size kapsamlı araştırma, ampirik kanıt ve titiz doğrulamayı birleştirmek için araçlar sunar. Bu şekilde plan yaptığınızda, ajanlarla mühendislik yapmak bir kumar gibi hissettirmez. Tahmin edilebilir ve tekrarlanabilir hale gelir.
https://x.ai/bot/plugin/9717366
Okuduğunuz için teşekkürler, 3. Bölüm için takipte kalın!
