İşte zekâyla hiçbir ilgisi olmayan bir başarısızlık.
İyi temellendirilmiş bir yapay zekâ asistanından SkySpark'ta bir Spark kuralı oluşturmasını isteyin. Axon'u bilir. Fonksiyon kütüphanesini indekslemiştir. Size temiz, sözdizimsel olarak geçerli kod yazar — ve geriye tek bir kayıt verir.
Çalışan bir Spark kuralı iki kayda ihtiyaç duyar: tespit mantığını tutan bir func kaydı ve kuralın nasıl ve nerede uygulanacağını yapılandıran bir sparkRule kaydı. İkisinin birbiriyle uyuşması gerekir. İkincisini atlarsanız hiçbir hata oluşmaz — izlendiğini sandığınız bir sahada, asla tetiklenmeyen bir kuralınız olur, o kadar.
Hiçbir sözdizimi bilgisi bunu önlemez. Bu bir dil sorunu değil. Bu bir prosedür sorunu ve prosedür, dışarıda bıraktığımız yarı.
İş akışı aslında nedir
Bir iş akışı bir markdown dosyasıdır. Bütün numara bu.
Kataloglanabilmesi için küçük bir frontmatter taşır, ardından tek bir işin nasıl düzgün yapılacağını anlatan düz metin ve tablolar gelir:
---
title: Create Spark Rule
description: Step-by-step guide for creating a Spark rule with func and sparkRule records
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---
Her iki MCP sunucusu da açılışta workflows/ dizinindeki her .md dosyasını yükler ve bunları Model Context Protocol üzerinden workflow:// URI'si altında okunabilir kaynaklar olarak sunar. Asistana bunların var olduğunun söylenmesi gerekmez — onları listeleyebilir, arayabilir ve iş sırasında talep üzerine tam metni çekebilir.
Fantom MCP Server o dizini izler. İçine yeni bir dosya bırakın; yeniden derleme ya da yeniden başlatma olmadan kullanılabilir hale gelir.
Bugünkü iki katalog
Fantom MCP Server — 13 iş akışı, inşa-ve-bakım tarafını kapsıyor:
ai-coding-loop · api-migration-reference · connector-workflow · create-pod · create-skyspark-extension · explore-code-relations · haxall-basics · haxall-coding-standards · haxall-methods-workflow · skyspark-4x-migration · unit-testing · use-fanr · xeto-spec-guide
Axon MCP Server — 10 iş akışı, analitik-ve-operasyon tarafını kapsıyor:
app-creation · axon-func-update · axon-lang-information · curRule-computed-points · html-email-skyspark · job-status-check · recform-template-design · spark-rule-creation · task-subscriber-permissions · visualytik-mcp-authoring
Yirmi üç dosya. Bu araç zincirinin şu anda kodlanmış prosedürel belleğinin tamamı bu — ve yeterli olmaktan çok uzak.
İyi bir örnek nasıl görünür
Amiral gemisi örnek ai-coding-loop; bir asistana, altındaki indeksin çürümesine izin vermeden kodu nasıl değiştireceğini öğretir. Sunucunun yapısal belleği 240+ projeyi ve 156K+ fonksiyonu kapsar; yeniden indekslenmeyen bir düzenleme, sonraki her aramayı sinsice yanlış hale getirir.
Tüm döngünün dayandığı kural tek bir cümle: her kod değişikliğinden sonra, dokunduğunuz yollar için reindexChangedFiles çağırın. Yeniden ayrıştır, grafiğin düğümlerini ve kenarlarını yeniden kur, gömme vektörlerini yeniden üret. Bunu atlayın; bir sonraki anlamsal arama artık var olmayan bir kod tabanından yanıt verir.
O iş akışının ne olmadığına dikkat edin. Bir API belgesi değil — araç açıklamaları bunu zaten yapıyor. O, işlem sırası; biri size söyledikten sonra apaçık, söyleyene kadar ise görünmez olan şey.
O dosya aynı zamanda çalınmaya değer bir satır taşıyor: “2026-06-10'da sedonaWebEditor üzerinde canlı olarak doğrulandı.” Doğrulama tarihi olan bir iş akışına ya güvenebilir ya da onu emekliye ayırabilirsiniz. Tarihi olmayan bir iş akışı ise söylentidir.
Bu neden darboğaz
İçgüdü, daha iyi modellerin bu açığı kapatacağını varsaymak. Kapatmıyorlar ve nedeni konusunda net olmakta fayda var.
Bir modelin bu alandaki zayıflığı muhakeme değil, giderek sözdizimi de değil — temellendirilmiş indeksler sözdizimini halleder. Zayıflık şu: bina otomasyonundaki prosedürel bilgi, hiçbir zaman herhangi bir şeyin yürütebileceği bir biçimde yazıya dökülmedi. Dünya genelinde birkaç bin uygulayıcının kafasında yaşıyor ve çıraklıkla aktarılıyor: bir Spark kuralının iki kayda ihtiyaç duyduğunu, kıdemli bir mühendis tetiklenmeyen bir kuralı devreye aldığınızı gördüğü için öğreniyorsunuz.
Bu aktarım mekanizması ölçeklenmez ve insanlar iş değiştirdiğinde ayakta kalmaz. Her entegratör aynı prosedürleri bağımsız olarak yeniden türetir. Aynı öğleden sonra, paralel biçimde, onlarca şirkette kaybedilir.
Bir iş akışı, o çıraklık anıdır: bir kez yazılır, o andan itibaren her projede her asistan tarafından uygulanır.
Neden bu iş topluluğun işi olmak zorunda
İşte tek başıma yapamayacağım kısım — ve tek bir şirketin de yapamayacağı.
Bu bilgiyi elinde tutan insanların çoğu sunucu yazmaz. Bir çatı tipi ünitenin doğru devreye alma sırasını ya da hesaplanmış noktalarda hangi curRule deseninin gerçekten işe yaradığını bilen mühendis bir kontrol uzmanıdır — TypeScript geliştiricisi değil. Katkı vermek bir indeksleme motoruna pull request açmayı gerektirseydi, bilgileri olduğu yerde kalırdı.
Gerektirmiyor. Bir iş akışı bir markdown dosyasıdır. Frontmatter, bir başlık, sırayla adımlar, tuzaklar. Nasıl yaptığınızı yazabiliyorsanız, bir tane katkı verebilirsiniz.
Ekonomi akıl almaz ölçüde lehimize. Bir iş akışını yazmak bir öğleden sonra sürer. Sonrasında, aksi halde onu yeniden türetecek her mühendise bir öğleden sonra kazandırır — her şirkette, süresiz olarak. Yazılımda kaldıracın bu kadar tek taraflı olduğu çok az yer vardır.
Ve bu alan parçalanamayacak kadar küçük. Bina otomasyonu web geliştirme değil; gelen bir katkıcı ordusu yok. Sedona, Haxall, Axon ve Xeto bilenlerin her biri prosedürlerini kendine saklarsa, herkes aynı öğrenim bedelini ödemeye devam eder. Yirmi üç dosya, bir avuç insanın başarabildiği kadarı. İncelenmiş ve tarihlendirilmiş iki yüz dosya ise, yeni gelen birinin ilk haftasında yapabileceklerini değiştirirdi.
Dürüst riskler
Bir iş akışı kataloğu kendiliğinden iyi değildir ve aksini varsaymak bu işi baştan başarısızlığa mahkûm eder.
Yanlış bir iş akışı, hiç iş akışı olmamasından kötüdür. Asistan onu kendinden emin şekilde izler ve kendinden emin şekilde yanlış bir sonuç üretir. Eksik prosedür en azından tereddüt üretir; kötü prosedür kötü devreye alma üretir. İnceleme burada çoğu belgede olduğundan daha önemlidir.
İş akışları sessizce bayatlar. SkySpark 4.0 eklenti biçimini değiştirdi ve gerçek prosedürleri bir gecede geçersiz kıldı. Bir iş akışı yaşlandığını fark etmez. Bu yüzden frontmatter'da version: var; daha iyisi ise açık bir doğrulama tarihi ve en son hangi projede kontrol edildiği bilgisi.
Kapsam disiplini. Her şeyi anlatmaya çalışan bir iş akışı hiçbir şey öğretmez. İyi olanlar tek bir iş yapar — şunu oluştur, bunu taşı, indeksi taze tut.
Bunların hiçbiri yaklaşımın aleyhine bir argüman değil. İncelemenin, tarihlendirmenin ve yeniden doğrulamanın, iki yüz dosyaya gelindiğinde sonradan eklenmek yerine en baştan işin parçası olması gerektiğini söylüyorlar.
Gelin kataloğu birlikte kuralım
Her iki sunucunun da kaynağı erişilebilir durumda ve iş akışı dizinleri başlamak için mümkün olan en kolay yer:
- FantomMcpServer —
workflows/, 13 dosya, inşa-ve-bakım - AxonMcpServer —
workflows/, 10 dosya, analitik-ve-operasyon
Boşluklar hiç de ince değil. BACnet nokta adlandırma kuralları için bir iş akışı yok, bir soğutma grubu tesisi sekansını devreye alma için yok, her projede yeniden tartışılan yarım düzine Haystack etiketleme kararı için yok.
Bu prosedürlerden birini biliyorsanız — nerede ters gittiği dahil, gerçekten biliyorsanız — o bir iş akışıdır ve şu anda kimse onu yazıya dökmemiş durumda.
Onu, çalışma gruplarının koordine olduğu foruma getirin ya da iki depodan birine pull request açın. Markdown dosyası, bilerek düşük tutulmuş bir eşik.
Bu sunucuların nasıl çalıştığı hakkında daha fazlası: Axon MCP Server · diller arası kod zekâsı · Sidecar filosu ve RLM.