Bir AI aracının kalıcı talimat katmanı: .md dosyaları ne işe yarar?

.md, AI'a özel bir dosya biçimi değildir.

Markdown aslında düz metindir. Başlık, liste, bağlantı, tablo ve kod bloğu gibi yapıları birkaç basit işaretle gösterebilir. Herhangi bir metin düzenleyicide açılır; insan tarafından kolay okunur ve yazılım tarafından kolay işlenir. AI araçları açısından avantajı da tam olarak budur: Metin doğal dil olarak kalırken yapısı görünür olur.

Başlıklar konu hiyerarşisini, listeler işlem sırasını, kod blokları değiştirilmemesi gereken örnekleri anlatır. Model metni yalnızca uzun bir paragraf olarak değil; bölümleri ve aralarındaki ilişkileri daha açık bir bağlam olarak görür. Buna rağmen dosyanın uzantısında özel bir zekâ yoktur. Kullanılan sistem o dosyayı okumuyor veya modele vermiyorsa .md dosyası davranışı hiçbir şekilde değiştirmez.

Bu yüzden Markdown'ı 'AI'ın sevdiği format' diye değil, insanın yazabildiği ve sistemin gerektiğinde yeniden yükleyebildiği kalıcı bir talimat ve bağlam kaynağı olarak düşünmek daha doğrudur.

Sohbet talimatı oturuma aittir; .md dosyası oturumlar arasında korunur.

Bir AI ile tek seferlik çalışırken ihtiyacını mesaj içinde anlatabilirsin. Fakat aynı işi her gün yapan, farklı kişiler tarafından kullanılan veya başka sistemlerle işlem yapan bir araçta bu yeterli olmaz. Her kullanıcının aynı açıklamayı yeniden yazmasını beklemek, aracın davranışını kişisel hafızaya bağlar.

Örneğin IT deposuna gelen talepleri değerlendiren bir AI aracı; yalnızca 'talebi sınıflandır' komutunu değil, hangi envanter kaydının esas olduğunu, aciliyetin nasıl belirlendiğini, hangi durumda otomatik işlem yapılabileceğini ve ne zaman sorumlu kişiye dönülmesi gerektiğini bilmelidir. Bunlar modelin genel bilgisinden çıkaracağı ayrıntılar değildir. Kuruma ve sürece özgü gereksinimlerdir.

.md dosyaları bu gereksinimleri sohbet geçmişinden çıkarıp kalıcı ve sürüm kontrollü bir talimat kaynağına dönüştürür. Ancak dosyanın varlığı tek başına yetmez: aracın onu keşfetmesi, doğru görevde yüklemesi ve içeriğini modele bağlam olarak vermesi gerekir. Model talimatı sonsuza kadar öğrenmez; sistem her gerektiğinde aynı tanımı yeniden sunar.

Aynı alarmı her vardiyada yeniden yorumlamamak.

Bir üretim hattı teşhis asistanı geliştirdiğimizi düşünelim. Asistan; operatörün bildirdiği belirtiyi, PLC veya SCADA alarmını, sensör eğilimlerini, ekipman dokümantasyonunu ve bakım geçmişini birlikte değerlendirir. Hangi kaynağın öncelikli olduğu, kontrollerin hangi sırayla yürütüleceği, hangi güvenlik sınırlarının hiçbir koşulda aşılmayacağı ve ne zaman uzman desteğine geçileceği tek bir uzun promptta değil, sorumlulukları ayrılmış .md dosyalarında tanımlanabilir.

Örneğin bir basınç alarmı tekrar ettiğinde sistem önce görev kapsamını ve güvenlik kurallarını okur; ardından hat ekipman haritasını, ilgili alarm bilgisini ve teşhis akışını bağlama alır. Güncel basınç değeri veya makine durumu .md dosyasından değil, yetkili canlı sistemden alınır. Asistan kanıta dayalı olası nedenleri ve kontrol adımlarını sıralar; interlock atlatma, koruyucu devreyi devre dışı bırakma veya yetkisiz yeniden başlatma önermez. Böylece sensör verileri yorumlanırken alarm ve arıza akışı vardiyadan vardiyaya aynı güvenlik mantığıyla yönetilir.

Her dosyanın her görevde okunması gerekmez.

Modüler yapının faydası yalnızca düzen değildir. Bir kullanıcı e-posta taslağı istediğinde envanter politikalarının, veri analizi istediğinde de kurumsal yazışma örneklerinin modele verilmesi gereksizdir. İlgisiz içerik token tüketir, önemli kuralların görünürlüğünü azaltır ve modelin dikkatini dağıtır.

İyi bir AI aracı önce kısa dosya açıklamalarına veya metadata'ya bakar, sonra yalnızca görevle ilişkili belgeleri yükler. Beceri dosyaları, arama tabanlı getirme ve RAG yaklaşımlarının ortak mantığı budur: Bütün bilgi her zaman bağlamda durmaz; doğru bilgi ihtiyaç anında getirilir.

Burada dosyanın içeriği kadar adı, açıklaması ve ne zaman okunacağını belirleyen tetikleme kuralı da önemlidir. Çok iyi yazılmış fakat hiçbir akışın çağırmadığı bir .md dosyası, çalışan bağlam değil arşivdir.

.md kullanmak tek başına token tasarrufu sağlamaz.

Model açısından token sayısını belirleyen şey dosya uzantısı değil, bağlama gerçekten giren metindir. Aynı talimatı bir sohbet mesajında, düz metin dosyasında veya .md dosyasında verdiğinde içerik büyük ölçüde aynıysa token miktarı da büyük ölçüde aynı kalır. Başlık ve liste işaretleri metni daha okunabilir hâle getirir; fakat onu sıkıştırmaz. Bu nedenle yalnızca uzun bir promptu olduğu gibi bir .md dosyasına taşımak token verimliliği sağlamaz.

.md kullanım alışkanlığı dolaylı olarak verim yaratır. Ortak kuralların kısa bir çekirdek dosyada tutulması, görev bilgisinin ayrı dosyalara bölünmesi ve yalnızca ilgili parçaların yüklenmesi; her istekte aynı açıklamaların tekrar edilmesini ve gereksiz bağlamın modele gönderilmesini azaltır. Kazanç Markdown sözdiziminden değil, seçici bağlam yönetiminden gelir.

Tersi de mümkündür: Sistem her görevde bütün .md arşivini yüklüyor, aynı kural birkaç dosyada tekrarlanıyor veya dosyalar zamanla gereksiz örneklerle büyüyorsa token tüketimi artar. Sağlıklı yaklaşım; kısa bir indeks kullanmak, dosyaları görev tetikleyicileriyle yönlendirmek, tekrarları temizlemek ve gerçek isteklerde modele kaç giriş tokenı gönderildiğini ölçmektir. Başka bir deyişle amaç, en az tokenı kullanmak değil; doğru karar için gereken en küçük ve en açık bağlamı kurmaktır.

EXAMPLES.md bazen on sayfa kuraldan daha etkilidir.

AI modelleri yalnızca açık kurallardan değil, örüntülerden de güçlü biçimde yararlanır. 'Kısa, teknik ve suçlayıcı olmayan bir açıklama yaz' demek bir yön verir; fakat iyi bir örnek hedeflenen uzunluğu, tonlamayı, ayrıntı seviyesini ve paragraf ritmini aynı anda gösterir.

Özellikle çıktı şeması, hata mesajı, rapor düzeni veya araç seçimi gibi konularda iyi-kötü örnek çiftleri belirsizliği azaltır. Model ne yapması gerektiği kadar, hangi görünüşteki sonucun kabul edilmemesi gerektiğini de görür. Bu yöntem genellikle daha fazla sıfat ve soyut kural eklemekten etkilidir.

Yine de örnek, tek doğru cevaba dönüşmemelidir. Temsil edici birkaç örnek davranışın sınırlarını göstermeli; modeli yalnızca isimleri ve cümleleri kopyalamaya zorlamamalıdır.

Bir .md değişikliği, aslında davranış değişikliğidir.

Talimat dosyaları Git gibi bir sürüm kontrol sisteminde tutulduğunda, aracın davranışındaki değişiklik görünür hâle gelir. Hangi kuralın eklendiği, bir istisnanın neden değiştiği ve önceki sürümde nasıl çalışıldığı satır satır incelenebilir. Gerekirse değişiklik geri alınabilir.

Bu, prompt düzenlemeyi kişisel bir deneme alanından ekipçe yönetilen bir mühendislik faaliyetine yaklaştırır. Alan uzmanı metni okuyabilir, geliştirici teknik uygulanabilirliği değerlendirebilir ve yapılan değişiklik aynı örnek görevlerle yeniden test edilebilir.

Sürüm geçmişi tek başına kalite sağlamaz; fakat kötü sonucu tartışırken 'model yine farklı cevap verdi' demek yerine, modele verilen davranış tanımının da değişip değişmediğini somut biçimde kontrol etmeyi sağlar.

.md dosyasına her şeyi koymak doğru değildir.

Parola, erişim anahtarı ve hassas kişisel bilgiler okunabilir metin dosyalarında tutulmamalıdır. Sürekli değişen envanter, fiyat veya kullanıcı listeleri de .md içine kopyalanmamalı; doğrudan güncel sistemden alınmalıdır. Markdown kaynağın nasıl kullanılacağını anlatabilir, fakat canlı kaynağın yerine geçmemelidir.

Kesin hesaplama, yetkilendirme, şema kontrolü veya veri dönüştürme gibi deterministik işler de doğal dil talimatına bırakılmamalıdır. Aynı girdi için her zaman aynı sonucu vermesi gereken bölüm kodla güvence altına alınmalıdır.

Son olarak iyi yazılmış bir dosya doğru davranışı garanti etmez. Dosyanın gerçekten yüklenmesi, kuralların çelişmemesi ve aracın olumlu-olumsuz senaryolarla test edilmesi gerekir. Dokümantasyon kontrol sağlar; doğrulamanın yerini almaz.