Sadece Dahilerin ve Yüksek Gelirlilerin Kullandığı Obsidian İnşa Teknikleri

AI ile Para Kazanmak "Not Sayısıyla" İlgili Değil

Öncelikle sakin bir şekilde konuşalım.

Yıllık 100 milyon yen gelir ile Obsidian konfigürasyonu arasında nedensel bir ilişki olduğunu gösteren hiçbir araştırma yok. "Zenginlerin bildiği gizli eklentiler" diye bir şey de yok.

"100 milyon yen oyuncusu" derken kastettiğim, devasa miktarda bilgi depolayan biri değil.

Elde ettiği bilgiyi şunlara dönüştürebilen kişilerden bahsediyorum:

• Karar verme
• Müzakere
• İşe alım
• Yatırım kararları
• Ürün tasarımı
• İçerik
• Satış materyalleri
• Organizasyonel sistemler
• Tekrar kullanılabilir entelektüel varlıklar

...ve bunu son derece yüksek bir hızda yapabilenler.

Sıradan Obsidian kullanıcıları "neyi kaydedeceğini" düşünür.

Güçlü kullanıcılar önce şunu düşünür: "Gelecekte bu bilgiyi hangi durumda, hangi soruyu kullanarak geri getireceğim?"

Daha da güçlü kullanıcılar, geri getirilen bilginin hangi karara veya çıktıya dönüştüğünü takip eder.

Başka bir deyişle, tasarlamanız gereken şey bir "İkinci Beyin" değil.

Karar alma ve entelektüel üretimi birleştiren bir Kişisel Zeka İşletim Sistemidir.

Obsidian notları yerel Markdown dosyaları olarak kaydeder. Bir Vault sadece bir klasördür ve harici düzenleyicilerden veya script'lerden yapılan değişiklikler Obsidian'a yansıtılır. Ayarlar ve eklenti bilgileri .obsidian klasöründe ayrılır. Bu, Obsidian'ın sadece bir uygulama değil, Git, CLI, Claude ve Codex tarafından yönetilebilen bir "bilgi deposu" olduğu anlamına gelir.

Bu makalede, Obsidian'daki öğeleri şu şekilde ele alıyoruz:

Bu bakış açısına ulaştığınızda, Obsidian'ı kullanma şekliniz tamamen değişir.

Bölüm 1: Yurtdışı Vakalarını Araştırmak—Kazanan Strateji "Düzenleme" Değil, "Arama"ydı

1. 7 Araştırmacının Vault'larından Öğrenilenler

2025'te yayınlanan bir vaka çalışması, Brezilya'daki bir araştırma enstitüsünde yedi bilgisayar bilimi araştırmacısının Obsidian kullanımını inceliyor.

Bu çalışmadan çıkarılacak en önemli ders, katılımcıların notları nasıl oluşturduğu değildi.

Gelecekte onları nasıl geri getirmeyi planladıklarının, notları oluşturma ve düzenleme şekillerini güçlü bir şekilde etkilediği keşfiydi. Katılımcılar arama çubuklarını, etiket listelerini, metin içindeki etiketleri ve iç bağlantıları farklı amaçlar için kullanıyordu. Bazı kullanıcılar oluşturulan notları bir Gelen Kutusu'na koyuyor ve haftada bir işliyordu.

Araştırmacılar tarafından türetilen tasarım önerileri şu üç noktada özetlenebilir:

1. Baştan mükemmel bir sınıflandırma talep etmeyin; minimum bir başlangıç yapısı hazırlayın.
2. Kullanım sırasında yapının değiştirilmesine izin verin.
3. Oluşturma/düzenleme yöntemini en baştan gelecekteki arama yöntemiyle ilişkilendirin.

Yani mesele "doğru klasörleri oluşturmak" değil.

Gelecekteki benliğinizin nasıl arama yapacağına karar vermek ve bu arama yoluna uygun olarak kayıt yapmaktır.

Tek başına bu nokta bile, çoğu yaygın Obsidian kursunun ters olduğunu gösteriyor.

Birçok kurs önce klasörlere, etiketlere, eklentilere ve görünüme karar vermenizi sağlar.

Oysa gerçekte, önce karar vermeniz gereken soru şudur:

Üç ay sonra, bu bilgiye ihtiyacım olduğunda ne için endişeleniyor olacağım?

2. Nicole van der Hoeven—Notları Bir Kariyer Öğrenme Aracı Haline Getirmek

Developer Advocate ve Performans Mühendisi olarak çalışan Nicole van der Hoeven, işte sürekli not almanın sadece öğrenme hızı üzerinde değil, aynı zamanda teknoloji sektöründeki kariyeri üzerinde de olumlu bir etkisi olduğunu belirtiyor.

Anahtar nokta, "güzel bir bilgi veritabanı oluşturması" değil.

İş sırasında öğrendiklerini kaydetmesi ve bunları herkese açık paylaşım, açıklama ve sunumlar için yeniden kullanmasıdır.

Öğrenme notlarını kişisel kayıtların ötesine taşıyarak şunlara akıtıyor:

• Sunumlar
• Makaleler
• Videolar
• Belgeler
• Eğitim materyalleri
• Bir sonraki iş

Bu "girdiden çıktıya dönüşüm", bilginin ekonomik değerini yaratır.

3. Bruno Paz—Yerel, Markdown, Minimal Eklenti

Yazılım mühendisi Bruno Paz, kod parçacıklarından toplantılara ve proje spesifikasyonlarından araştırma ve yaşam bilgisine kadar her şeyi Obsidian'da topluyor.

Ancak her şeyi Obsidian'a koymaktan daha önemli olan, tasarım felsefesidir.

Markdown'ın taşınabilirliğini ve Git aracılığıyla geçmiş yönetimini vurguluyor ve eklenti sayısını minimumda tutma politikası izliyor. Eklentiler Obsidian'ı kullanışlı hale getirir, ancak içeriğin kendisi belirli eklentilere çok fazla bağımlı olmamalıdır.

Ayrıca type gibi Frontmatter'ı şablonlarla standartlaştırıyor, Wikilink'leri ilgili notlara topics içinde koyuyor ve bunları Bases veya Dataview ile listeliyor.

Buradaki sonuç açıktır:

Yüksek işlevsellikten daha önemli olan, bir şey bozulduğunda sadece Markdown ile kurtarılabilmektir.

4. Ian O'Byrne—Bilgiyi "Tüket → Kürasyon Yap → Oluştur" Akışına Sokmak

Obsidian'ı eğitim ve araştırmada kullanan Ian O'Byrne, Vault'unu kabaca şu akışla yapılandırıyor:

• Tüket: Makaleler, kitaplar, makaleler, podcast'ler gibi girdiler
• Kürasyon Yap: Kilit noktaları damıtmak, ilişkilendirmek, MOC'ler oluşturmak
• Oluştur: Bloglar, bültenler, öğretim materyalleri gibi çıktılar
• Meta: Vault'un kendisi için operasyonel bilgiler

Önemli olan klasör adları değil.

Bilginin girdiden anlamlandırmaya ve çıktıya doğru hareket ettiği yapıdır. Platformdan çok sürecin önemli olduğunu ve Vault'un gerektiği gibi geliştiğini açıklıyor.

Bu yurtdışı vakalarını özetlersek, mükemmel Vault'ların beş ortak özelliği vardır:

1. Önce getirme—Gelecekteki aramalardan geriye doğru çalışın
2. Çıktı odaklı—Sadece depolamaya değil, teslimatlara doğru akış sağlayın
3. Önce yerel—Markdown'ı gerçeklik kaynağı olarak kullanın
4. Minimal şema—Giriş alanlarını aşırı karmaşık hale getirmeyin
5. Evrimsel—Kullanırken yapıyı değiştirin

Bölüm 2: "100 Milyon Yen Vault"unu Tanımlayan Altı Metrik

Not sayısı, bağlantı sayısı ve Grafiğin güzelliği temel performans metrikleri değildir.

Vault performansını şu altı metrikle ölçerim:

1. Yakalama Gecikmesi

Bir fikre sahip olmaktan onu kaydetmeye kadar geçen süre.

Hedef 30 saniye içindedir. Giriş anında etiketler, ilgili notlar ve kaydetme konumları hakkında düşünmeye zorlayan bir yapı zayıftır.

2. Getirme Süresi

Gerekli bilgiye ulaşmak için geçen süre.

Genel bilgiler için 30 saniye, önemli karar kayıtları için 60 saniye içinde hedefleyin.

3. Bağlam Yeniden Yapılandırma Maliyeti

Eski notlara bakıldığında bir hikayenin neyle ilgili olduğunu geri getirmek için geçen süre.

Sadece bir toplantı başlığı olan bir not zayıftır. "Arka Plan", "Karar", "Neden", "Ön Koşul" ve "Sonraki Eylem"i koruyan bir not güçlüdür.

4. Karar İzlenebilirliği

Daha sonra aşağıdakileri takip edebildiğiniz önemli kararların yüzdesi:

• Neden karar verildiği
• Neyin reddedildiği
• Hangi ön koşulların var olduğu
• Hangi koşulların bir geri dönüşü tetikleyeceği

5. Çıktı Dönüşüm Oranı

Makaleler, teklifler, ürünler, kararlar, toplantılar veya satış faaliyetleri için yeniden kullanılan Kaynak Notlar veya Evergreen Notların yüzdesi.

6. Ajan Yürütülebilirliği

Claude veya Codex'in Vault'un kurallarını yanlış anlamadan arama yapma, önerme ve doğrulama yapabildiği zamanın yüzdesi.

Bunları özetlersek, bir bilgi sisteminin ROI'si şu şekilde düşünülebilir:

Bilgi ROI'si = (Yeniden Kullanılan Bilgi + Geliştirilmiş Kararlar + Önlenen Başarısızlıklar) / Kaydetme, düzenleme ve bakım için harcanan zaman

Not sayısı artsa bile, yeniden kullanılmazlarsa, sadece payda büyüyor demektir.

Bölüm 3: Türk Kullanıcılar İçin Kolay Bir Vault Yapısı

Sıfırdan inşa ediyor olsaydım, şu üst düzey yapıyı kullanırdım:

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

Sınıflandırılmamış girdiler. Burada düzenleme yapmayın. Etiketler genellikle gerekli değildir. Burası "sadece kaydetmek" için bir yerdir.

10_Daily

Kronolojik çalışma günlükleri. Bağımsız notlar oluşturmaya değmeyecek notları, konuşmaları, farkındalıkları ve ilerlemeyi buraya bırakın.

20_Projects

Tamamlanma koşulu olan faaliyetler. "Satışları artırmak" bir Alan veya Hedef iken, "Kurumsal plan fiyatlandırmasını Eylül 2026'ya kadar revize etmek" bir Proje'dir. Projelerin her zaman bir next_action'ı olmalıdır.

30_Areas

Devam eden sorumluluk alanları. Yönetim, satış, işe alım, finans, sağlık, aile, öğrenme vb. Bir Proje tamamlandıktan sonra bile Alanlar devam eder.

40_Notes

Uzun vadeli yeniden kullanım için bilgi. Sadece alıntılar değil, kendi kelimelerinizle açıklayabileceğiniz içerikleri buraya koyun. "Bir not, bir kavram" kuralına sıkı sıkıya bağlı kalmaya gerek yoktur. Konular ve ön koşullar kolayca atlanabileceğinden, aşırı parçalama bağlamı bozar. Standart şudur:

1 Not = Gelecekte tek bir birim olarak yeniden kullanmak istediğiniz içerik

50_Sources

Harici bilgilerin kayıtları. Kitaplar, makaleler, yazılar, videolar, toplantı materyalleri, araştırma verileri vb. "Karşı tarafın söylediklerini" "benim nasıl yorumladığımdan" ayırın.

60_Entities

Kişiler, şirketler, ürünler, müşteriler, rakipler ve teknolojiler gibi varlıklar. Aynı kişi veya şirket birden fazla projede yer alsa bile, yalnızca bir Varlık Notu tutun.

70_Outputs

Makaleler, planlama belgeleri, teklifler, video senaryoları, sunumlar, satış materyalleri, ürün özellikleri vb. Çıktıları bağımsız bir üst düzey klasöre yerleştirmek çok önemlidir. Sadece depolamayı hedefleyen bir Vault, bilgi mezarlığı haline gelir.

90_System

Şablonlar, Şemalar, Bases, AI kuralları ve Beceriler gibi Vault'un kendisini çalıştıran mekanizmalar. Bunu inşa ederek, kendi operasyonlarınızı açıklayabilir hale gelirsiniz.

Tek Vault mu?

Prensip olarak, evet. Obsidian'daki iç bağlantılar bir Vault içinde çözülür; Vault'ları bölmek, bilgi arasındaki ilişkileri koparır. Bahsedilen çalışmada, Vault'larını üçe bölen katılımcılar arama karmaşası bildirmiştir.

Ancak, aşağıdakileri fiziksel olarak ayırın:

• Harici AI girdisinin sözleşmeyle yasaklandığı bilgiler.
• Tıbbi bilgiler, kişisel kimlik numaraları, kimlik bilgileri.
• Son derece hassas İK bilgileri.
• Düzenlemeye tabi veriler.
• Kurumsal politikaya göre harici modellere aktarılamayan bilgiler.

Bunu bir "Kişisel Vault" ve "Düzenlemeye Tabi Vault" olarak ayırmayı düşünün.

Bölüm 4: Klasörlerin, Özelliklerin, Bağlantıların ve Etiketlerin Rollerini Karıştırmayın

Obsidian sistemlerinin çökmesinin en büyük nedeni, aynı sınıflandırmayı klasörler, etiketler, özellikler ve bağlantılar kullanarak aynı anda ifade etmektir. Rollerini şu şekilde belirleyin:

Klasörler "Yaşam Döngüsü" İçindir

Gelen Kutusu, Proje, Kaynak, Çıktı, Arşiv vb. Bir notun sürecin hangi aşamasında olduğunu temsil ederler.

Özellikler "Makine Tarafından İşlenen Türler ve Durumlar" İçindir

type, status, created, project, revisit, vb. Obsidian Özellikleri YAML olarak kaydedilir ve metin, liste, sayı, onay kutusu, tarih, datetime ve etiketler gibi türlere sahip olabilir.

Bağlantılar "Anlamsal İlişkiler" İçindir

[[Fiyatlandırma Stratejisi]], [[ABC Şirketi]], [[Kararların Geri Döndürülebilirliği]] vb. Bir konuyu etiket yerine not haline getirmek, o konunun kendisinin açıklamalar, karşı kanıtlar, referans materyalleri ve MOC'ler barındırmasına olanak tanır.

Etiketler "Geçici Çapraz Durumlar" İçindir

Etiketleri #review, #waiting, #question, #contradiction, #publish gibi şeylerle sınırlayın.

"Pazarlama" veya "Yapay Zeka" gibi kavramlar mümkün olduğunca bağlantı olmalıdır. Etiketleri kavramsal bir sözlük olarak kullanmak, etiket çoğalmasına yol açar (ör. #YZ, #YapayZeka, #ÜretkenAI). Bunun yerine, kavram notlarında Takma Adlar (Aliases) kullanın.

Bölüm 5: Minimal Özellik Şeması

Baştan 20 öğe doldurmaya çalışmayın. Şemayı üç aşamaya ayırın:

Yakalama Aşaması

Sadece temel bilgiler:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Yükseltilmiş Aşama

Uzun vadeli depolama için değer kazandığında ekleyin:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Fiyatlandırma Stratejisi]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Rakip Fiyatlandırma Araştırması 2026-07]]"
confidence: medium
sensitivity: internal
``

Operasyonel Aşama

Projeler veya Kararlar için gereken öğeleri ekleyin:
``yaml
type: project
created: 2026-07-24
status: active
owner: ben
area: "[[Yönetim]]"
due: 2026-09-30
next_action: 5 rakibin yıllık planlarını karşılaştır
``

Bölüm 6: Türkçe Dosya Adları İçin Kurallar

Türkçe gövde metnini veya başlıklarını İngilizce'ye zorlamaya gerek yoktur. Ancak, makine işleme için kullanılan Özellik adlarını ve klasör adlarını ASCII'de tutun. Şu adlandırma kurallarını kullanıyorum:

• Proje: PJT Kurumsal Fiyatlandırmanın Yeniden Tasarımı
• Karar: DEC 2026-07-24 Yıllık Planı Standart Teklif Haline Getir
• Evergreen Not: Fiyat, Özellik Sayısından Ziyade Uygulama Başarısızlık Riskiyle Belirlenir

Evergreen Not başlıklarını "Kategori Adları" yerine "İddialar" haline getirin. İddialı başlıklar, içeriği sadece arama sonuçlarından hatırlamanıza yardımcı olur.

Bölüm 7: Dahil Edilecek Şablonlar

Günlük Not

Bir "Sürtünme Günlüğü" ekleyin. "Aradığım ama bulamadığım şey"i kaydetmek, Vault'u gerçek arama başarısızlıklarına dayanarak geliştirmenizi sağlar. Yapıyı estetik tercihten değil, başarısız aramalardan yola çıkarak geliştirin.

Proje Notu

Bir Proje Notu, görevler için bir depo değildir. Herkesin mevcut durumu 30 saniyede anlayabileceği Proje Komuta Merkezidir.

Karar Notu

Yüksek kârlı işlerde, kararların kalitesi bilgiden daha önemlidir. Bu nedenle, Karar Notları en değerli not türüdür. En önemli alan Geri Dönüş Tetikleyicisidir. Mükemmel bir karar verici, karar anında hangi koşullar altında fikrini değiştireceğini yazabilen kişidir.

Bölüm 8: MOC'ler "Bağlantı Listeleri" Değil, "Düzenlenmiş Düşünce Modelleridir"

İyi bir MOC (İçerik Haritası), editörün yargısını içerir. Sadece ilgili notların bir listesi değil, bir alanı şu anda nasıl anladığınızı sıkıştıran düzenlenmiş bir bilişsel modeldir.

Bölüm 9: Bases ile "Yönetim Panosu" Oluşturmak

Obsidian Bases, not Özelliklerini bir veritabanı gibi görüntülemenize, filtrelemenize ve sıralamanıza olanak tanıyan temel bir özelliktir. Bunu kullanarak bir "Aktif Projeler Panosu" veya "Karar İnceleme Panosu" oluşturun ve askıda kalan kararları kurtarın.

Bölüm 10: Katmanlı Eklentiler

• Katman 0 (Sadece çekirdek): Properties, Templates, Daily Notes, Bases, Search, Canvas vb.
• Katman 1 (Sürtünme oluştuğunda): QuickAdd, Templater, Tasks.
• Katman 2 (Sadece Bases yeterli değilse): Dataview.

Aktif Topluluk Eklentilerini 12 veya daha azında tutun. Her biri için amacı, alternatifi ve silme koşullarını kaydedin.

Bölüm 11: 2026'daki Belirleyici Değişim—Resmi Obsidian CLI

Temmuz 2026 itibarıyla Obsidian'ın resmi bir CLI'sı var. Masaüstü sürümünü terminalden çalıştırmanıza olanak tanır: arama, okuma, oluşturma, özellikleri güncelleme ve görevleri kontrol etme. Bu, Claude ve Codex'in sadece Markdown'ı doğrudan düzenlemek yerine Obsidian'ın kendi çözümleme mantığını kullanarak çalışmasını sağlar.

Bölüm 12: AI-Yerel Bir Vault İçin Doğru Yapı

AI'nın tüm notları serbestçe düzenlemesine izin vermek "AI kullanımı" değildir. Bu, tüm şirket belgelerini denetlenmemiş bir stajyere vermek gibidir. Doğru iş bölümü şudur:

• İnsan: Hedefler, değer yargıları, son onay, MOC düzenleme.
• Obsidian: Gerçeklik kaynağı, ilişkiler, geçmiş, görünümler.
• Claude: Anlamı damıtma, karşılaştırma, karşı argümanlar, taslak oluşturma.
• Codex: Yapısal değişiklikler, script'ler, doğrulama, fark incelemeleri.
• Git: Kurtarma, denetim, deneylerin izolasyonu.
• Doğrulayıcı: Şema ihlallerini ve bağlantı anomalilerini tespit etme.

Bölüm 13: CLAUDE.md ve AGENTS.md Yerleştirme

Claude Code, CLAUDE.md'yi sürekli talimatlar olarak okur. Codex, AGENTS.md'yi arar. Bu dosyalara bir "Vault İşletim Sözleşmesi" yerleştirerek dili (Türkçe düzyazı, ASCII özellikler), güvenlik kurallarını (varsayılan olarak kuru çalıştırma) ve şema kurallarını tanımlayın.

Bölüm 14: Obsidian Görevlerini Claude ile Becerilere Dönüştürmek

Üç kereden fazla yaptığınız veya standart kalite gerektiren görevler için "Ajan Becerileri" tanımlayın. Örneğin, bir obsidian-distill becerisi, ham toplantı notlarını Kararlara, Görevlere ve Evergreen Notlara dönüştürebilir. İyi bir Beceri, açık girdileri, prosedürleri, yasakları ve tamamlanma koşulları olan tekrar çalıştırılabilir bir çalışma standardıdır.

Bölüm 17: Claude, Codex ve Obsidian CLI İçin İş Birliği Modelleri

• Model 1: Toplantı Notu Damıtma (Claude kararları/görevleri çıkarır).
• Model 2: Haftalık Yönetim İncelemesi (Claude haftanın ilerlemesini ve takılmış projeleri özetler).
• Model 3: Şema Kayması Denetimi (Codex özellik tutarsızlıklarını tespit eder).
• Model 4: Karar Ön Koşul Denetimi (Claude, geçmiş kararların arkasındaki varsayımların hala geçerli olup olmadığını kontrol eder).

Bu, "notları AI ile özetlemenin" ötesine geçen bir kullanımdır. AI'yı, geçmiş yargılarınızı denetleyen bir entelektüel kontrolör olarak kullanırsınız.

Bölüm 18: Bir Vault Doğrulayıcı Dahil Etmek

AI, Vault'unuzu düzenliyorsa, sadece "iyi görünüyor" ile yetinmeyin. İzin verilen türleri, durumları ve gerekli özellikleri doğrulamak için script'ler (ör. vault_check.py) aracılığıyla minimum statik test uygulayın.