Prompt Sürümleme: Çalışan Promptu Kaybetmemek

Üç tur yineledikten sonra promptunuz nihayet istediğiniz gibi çalışıyor. Kopyalayıp bir yere yapıştırıyorsunuz.

İki ay sonra o promptu bulamıyorsunuz. Bulsanız bile neden o şekilde yazdığınızı hatırlamıyorsunuz — “yalnızca verdiğim metni kullan” satırı neden vardı, gereksiz mi?

Siliyorsunuz. Bir hafta sonra uydurulmuş bilgiler geri geliyor.

Bu döngüyü kıran şey karmaşık bir araç değil, iki satırlık bir not alışkanlığı.

Neyi saklamak gerekiyor?

Promptun metni yeterli değil. Dört şey birlikte anlam taşıyor:

Üçüncü ve dördüncü maddeler çoğu kişinin atladığı ve en değerli olan kısım. Prompt metni bir çıktıdır; gerekçe ve sınır ise bilgidir.

Kişisel kütüphane

Tek başınıza çalışıyorsanız düz bir metin dosyası yeterli. Araç aramayın.

## Toplantı notundan görev çıkarma
Kullanım: Haftalık ekip toplantısı notları
Son güncelleme: 2026-08-03

[prompt metni]

### Neden bu satırlar var
- "Tarih yoksa belirtilmemiş yaz" → model tarih uyduruyordu
- Format en sonda → başta olunca uzun notlarda ıskalanıyordu

### Nerede çalışmıyor
- 3 sayfayı geçen notlarda son görevleri atlıyor → bölmek gerekiyor
- Türkçe-İngilizce karışık notlarda kategori adları karışıyor

Bu yapı beş dakikada kurulur ve bir promptun tüm hikâyesini taşır.

Sürüm açmak ve not düşmek

Ne zaman yeni sürüm açmalı?

Her düzenlemede değil. Sürüm, geri dönebilmek istediğiniz nokta demektir.

Yeni sürüm açın: Yapıyı değiştirdiyseniz, bir kısıtı kaldırdıysanız, model değiştirdiyseniz veya çıktı biçimi değiştiyse.

Açmayın: Yazım hatası düzelttiyseniz, kelime değiştirdiyseniz, biçimsel düzeltme yaptıysanız.

Basit bir numaralandırma yeterli: v1, v2, v3. Yanına tek satır not:

v3 (2026-08-03) — Format bloğu sona alındı. Uzun notlarda ıskalama düzeldi.
v2 (2026-07-20) — Boş tarih kuralı eklendi. Uydurma durdu.
v1 (2026-07-11) — İlk çalışan hâl.

Eski sürümleri silmeyin. Bir sürüm bozulduğunda geri dönebileceğiniz nokta bu liste.

Blueprint: Prompt kütüphanesi

Kim kurar: İçerik ekipleri, operasyon, geliştirme ekipleri Yapı taşları: Kalıp dosyası → Sürüm notu → Değerlendirme bağlantısı → Sahip Tipik ölçek: 10–30 kalıp Zorluk: Kolay Nerede kırılır: Otuz kalıbı geçince aranamaz hâle gelir; ayıklama bulmaktan önemli olur.

Ekipte kullanım: iki ek gereksinim

Kütüphane paylaşıldığında iki şey daha gerekiyor.

Sahip. Her promptun bir sorumlusu olsun. Sahipsiz prompt, bozulduğunda kimsenin fark etmediği prompttur.

Değerlendirme bağlantısı. Promptun test setine ve son ölçüm sonucuna bağlantı. Bir promptu değiştirmek isteyen kişi, mevcut hâlin nasıl performans gösterdiğini görebilmeli. → Promptları Test Etme: \"Bana İyi Göründü\"yü Bırakmak

Bir de kültürel bir kural: kimse doğrudan üretimdeki promptu düzenlemesin. Kopyasını alıp değiştirsin, ölçsün, sonra değiştirsin. Yazılımdaki alışkanlığın karşılığı bu.

Kalıplaştırmak

Sakladığınız şey bir prompt değil bir kalıp olmalı. Kendi işinize özel kısımları boşaltın:

Sana [girdi türü] vereceğim.
[tek cümlelik işlem]
Çıktıyı şu yapıda ver: [format]
Bilgi yoksa "belirtilmemiş" yaz.

Kalıp, aynı yapıyı farklı işlerde kullanmanızı sağlar ve kütüphanenin şişmesini önler. Beş ayrı prompt yerine bir kalıp saklamak, aranabilirliği doğrudan artırır. → Prompt Örnekleri: ChatGPT ve Gemini'de İşe Yarayan 6 Kalıp

Sürüm notu nasıl yazılır?

Kötü sürüm notu neyi değiştirdiğinizi yazar. İyi sürüm notu neden değiştirdiğinizi yazar.

✗ v4 — Format bölümü güncellendi.
✓ v4 — Format bloğu girdiden sonraya alındı.
       3 sayfayı geçen notlarda son iki alan boş geliyordu.

İkincisi altı ay sonra da anlamlı. Birincisi bir hafta sonra bile anlamsız.

Üç bilgi taşıyın: ne değişti, hangi belirtiyi çözdü, hangi girdide görüldü. Üçüncüsü özellikle değerli çünkü aynı belirti tekrarladığında hangi girdiyle test edeceğinizi bilirsiniz.

Bir de tersini kaydedin: denenip vazgeçilenler.

DENENDİ, İŞE YARAMADI:
- "Sen deneyimli bir editörsün" → ton oynadı, tutarlılık gelmedi (v2'de silindi)
- Örnek sayısını 3'ten 6'ya çıkarmak → fark görülmedi, maliyet arttı (v3'te geri alındı)

Bu liste, kütüphanenin en az yazılan ve en çok zaman kazandıran kısmı. Aylar sonra aynı fikri tekrar denemenizi önlüyor. → Prompt Yinelemesi: Beğenmediğiniz Çıktıdan Düzeltmeye Giden Yol

Kütüphane büyüdüğünde

Otuz kalıbı geçtiğinizde asıl sorun bulmak değil, hangisinin hâlâ geçerli olduğunu bilmek olur.

Bu sayı bir ölçüm değil, paylaşılan kütüphaneler için bir yön göstergesi. Kişisel bir kütüphanede eşik daha erken gelir — orada kalıbı arayan kişi onu yazan kişidir ve neyin nerede olduğunu hatırlar. → Prompt Örnekleri: ChatGPT ve Gemini'de İşe Yarayan 6 Kalıp

Altı ayda bir ayıklama yapın. Son üç ayda kullanılmamış kalıpları arşive taşıyın. Kullanılmayan kalıp bakım borcudur.

Kalıpları kategorilere değil işe göre adlandırın. “Özetleme kalıbı 3” kötü bir ad; “Toplantı notundan görev çıkarma” iyi bir ad.

Tekrarları birleştirin. Aynı yapının üç varyantı varsa, muhtemelen bir kalıp ve üç doldurma örneğidir.

Promptu nereye yazmalı: dosya mı, kod mu?

Prompt bir ürünün içinde çalışıyorsa bu soru kritik hâle geliyor ve iki yaklaşım var.

Kodun içine gömmek. En hızlı yol. Promptu doğrudan kaynak dosyaya yazarsınız, sürüm kontrolü kendiliğinden gelir, değişiklikler kod incelemesinden geçer.

Sorunu şu: promptu değiştirmek kod değişikliği demektir. Bir kelimeyi düzeltmek için sürüm çıkarmak gerekir ve prompt üzerinde çalışan kişi geliştirici değilse süreç tıkanır.

Dışarıda tutmak. Prompt ayrı bir dosyada ya da yapılandırma katmanında durur, kod onu okur. Prompt üzerinde çalışan kişi kod dokunmadan değişiklik yapabilir.

Sorunu şu: sürüm kontrolü ve inceleme disiplini kendiliğinden gelmez, ayrıca kurulması gerekir. Kurulmazsa promptlar sessizce değişir ve kimse ne zaman ne değiştiğini bilmez.

Pratikte işleyen orta yol: promptu kod deposunda ama ayrı bir dosyada tutmak. Sürüm kontrolü ve inceleme gelir, ama prompt dosyaları kod dosyalarından ayrılmış olduğu için üzerinde çalışmak daha rahat olur. Küçük ekipler için bu genellikle yeterli.

Hangi yaklaşımı seçerseniz seçin, değişmeyen bir kural var: prompt değişikliği de bir değişikliktir. Kodda dikkatle uyguladığınız disiplin — kim değiştirdi, neden değiştirdi, test edildi mi — prompt için de geçerli olmalı. Prompt kod değil diye bu disiplini atlamak, en sık yapılan ve en pahalıya patlayan tercih.

Aynı promptun birden fazla varyantı

Bir promptun farklı bağlamlar için varyantları oluşur: bir dil için ayrı, bir müşteri segmenti için ayrı, bir ürün hattı için ayrı.

Bunları ayrı promptlar olarak saklamak ilk anda kolay ama hızla bakım yüküne dönüşür. Ortak bir düzeltme gerektiğinde beş dosyayı birden güncellemeniz gerekir ve biri unutulur.

Çözüm kalıp yaklaşımı: ortak gövdeyi tek yerde tutup değişen kısımları parametre olarak dışarı almak. Beş varyant yerine bir kalıp ve beş doldurma seti saklarsınız. Bir düzeltme tek yerde yapılır ve beşine birden yansır. → Prompt Örnekleri: ChatGPT ve Gemini'de İşe Yarayan 6 Kalıp

Sınırlar

Araç gerekmiyor. Metin dosyası çoğu ekip için yeterli. Özel prompt yönetim araçları ölçek büyüdüğünde anlam kazanır; öncesinde ek karmaşıklıktır.

Sürümleme kaliteyi ölçmez. Hangi sürümün daha iyi olduğunu bilmek için ölçüm gerekir. → Promptları Test Etme: \"Bana İyi Göründü\"yü Bırakmak

Kütüphane eskir. Model güncellemeleriyle çalışan kalıplar bozulabilir. → Model Güncellenince Promptlar Neden Bozulur?

Fazla süreç işi öldürür. Tek kişilik bir kullanımda sahip, onay ve inceleme adımları gereksiz yüktür.

Kütüphaneyi kim kullanacak?

Bir prompt kütüphanesinin başarısız olmasının en sık sebebi teknik değil: kimse bakmıyor.

Kurulduğu gün herkes heyecanlı, üç ay sonra kimse açmıyor. Sebebi genellikle şu: kütüphane, ihtiyaç anında bulunabilir değil. Birinin bir prompta ihtiyacı olduğunda kütüphaneyi açıp aramaktansa sıfırdan yazması daha hızlı geliyor.

Bunu önleyen iki şey var.

Adlandırma. Kalıplar yaptıkları işle adlandırılmalı, kategorilerine göre değil. Birisi “toplantı notundan görev çıkarmam lazım” diye düşünüyorsa, arayacağı kelime tam olarak budur.

Giriş noktası. Kütüphanenin başında, hangi kalıbın hangi işe yaradığını gösteren tek sayfalık bir liste olsun. Otuz dosyayı tek tek açmak kimsenin yapacağı bir şey değil.

Üçüncü ve en önemlisi: kütüphaneye eklemek kolay olmalı. Bir promptu kaydetmek beş dakika sürüyorsa kimse kaydetmez. İki satır not yeterli olmalı; mükemmel bir kayıt beklemek, hiç kayıt olmamasına yol açar.

Ne zaman araç gerekir?

Metin dosyası çoğu durumda yeterli, ama üç belirti araç ihtiyacını gösteriyor.

Prompt sayısı bakılamayacak kadar arttıysa. Otuz kalıbı geçtikten sonra arama, etiketleme ve ilişkilendirme elle yönetilemez hâle geliyor.

Prompt üzerinde çalışanlar geliştirici değilse. Metin dosyası bir kod deposunda duruyorsa ve pazarlama ekibi ona erişemiyorsa, süreç tıkanır. Bu durumda arayüzü olan bir çözüm gerekiyor.

Değerlendirme otomatik çalışıyorsa. Her prompt değişikliğinde test setinin kendiliğinden koşması isteniyorsa bu bir altyapı işidir ve dosya bunu yapmaz. → Promptları Test Etme: \"Bana İyi Göründü\"yü Bırakmak

Üçü de yoksa araç almayın. Erken alınan araç, çözdüğünden fazla karmaşıklık getiriyor — ve bir kütüphanenin terk edilmesinin en sık sebeplerinden biri, kullanımının gereğinden zor olması.

Özet

Prompt metnini saklamak yetmez. Dört şey birlikte anlam taşır: promptun kendisi, ne işe yaradığı, hangi satırın neden eklendiği ve nerede başarısız olduğu.

Son iki madde en değerlisidir — gerekçesini bilmediğiniz bir satırı silersiniz, sınırını bilmediğiniz kalıba fazla güvenirsiniz.

Sürüm, geri dönmek isteyeceğiniz noktadır. Yapı değişikliklerinde açın, yazım düzeltmelerinde açmayın. Eski sürümleri silmeyin.

Ekipte iki ek gereksinim var: her promptun bir sahibi ve bir değerlendirme bağlantısı olsun.

Sık sorulanlar

İlgili yazılar