Ubah Wiki Bergaya Karpathy menjadi Skill yang Dapat Digunakan Kembali

Beberapa hari terakhir ini benar-benar perjuangan untuk membuat skill ini berfungsi.

Saya mulai dengan Opus 4.6. Saya menghabiskan lebih dari $20. Tetap saja tidak bisa berfungsi. Saya bahkan bertanya-tanya apakah model baru yang dirilis pada pagi hari tanggal 8 April 2026 telah menyedot semua komputasi mereka. Kalau tidak, bagaimana bisa ia paham suatu saat lalu melenceng di saat berikutnya?

Kemudian saya beralih ke Codex, dan saya berhasil membangunnya.

Tapi masalah baru muncul: membangunnya bukan berarti ia bekerja dengan andal.

Terutama saat Anda mulai mengujinya secara serius, kadang ia mengabaikan instruksi dan membuat perubahan sendiri, yang membuat saya gila.

Jadi dalam artikel ini, saya tidak hanya ingin mengatakan “Saya membuat sebuah skill, silakan unduh.”

Saya ingin menjelaskan hal lain: bagaimana sebenarnya menerapkan metode LLM Wiki yang diajukan Karpathy di dalam vault Obsidian.

Bab sebelumnya membahas metodenya. Bab ini tentang praktiknya.

Jika Anda ingin mengunduh versi skill saya yang sudah dibersihkan saat ini, berikut tautannya:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

Saya sudah menghapus kunci API, jalur lokal, dll. Tapi saya ingin katakan di awal: jangan menyalinnya mentah-mentah.

Anda bisa belajar dari metode ini. Anda juga bisa memodifikasi skill ini. Tapi jangan berharap ia langsung berfungsi. Vault catatan setiap orang terlalu berbeda.

Yang saya bangun bukan “AI mengatur catatan saya,” melainkan “AI mengerjakan pembukuan saya”

Mari kita lihat kembali Gist Karpathy.

Tautan asli:

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Ide intinya sebenarnya sederhana:

Kebanyakan orang saat ini menggunakan LLM untuk pemrosesan dokumen melalui RAG: masukkan banyak file, dan saat bertanya, ambil dan hasilkan jawaban secara langsung.

Itu tentu saja berhasil.

Tapi masalahnya adalah semuanya bersifat ad hoc.

Tanya sekali, rangkai sekali. Tanya lagi, mulai dari awal. Tidak ada akumulasi.

Jadi dia mengusulkan lapisan perantara: alih-alih merangkai jawaban setiap kali bertanya, rawatlah sebuah Wiki secara berkelanjutan.

Saat membaca ini, reaksi pertama saya bukan “ini keren.”

Melainkan: bukankah ini persis jenis tugas yang paling cocok untuk Obsidian?

Karena Obsidian pada dasarnya adalah vault file Markdown lokal.

Wiki yang dijelaskan Karpathy pada dasarnya adalah kumpulan file Markdown.

Format dasarnya hampir identik.

Perbedaannya adalah:

• Sebelumnya, Anda secara manual mengelola backlink, halaman topik, dan halaman struktur
• Sekarang AI membantu Anda mengerjakan “pembukuan” ini

Catatan: pembukuan, bukan berpikir.

Saya semakin setuju dengan ini.

Membaca artikel, membuat penilaian, menulis opini sendiri—itu masih tugas Anda.

Tapi tugas seperti melengkapi backlink, menormalisasi nama penulis, memeriksa format, dan menyegarkan halaman turunan pada dasarnya adalah pekerjaan kasar. AI bisa menanganinya.

Bagaimana Saya Menerapkan Struktur Tiga Lapis Karpathy di Obsidian

Bagian terpenting dari metode Karpathy adalah tiga lapisan:

• Raw Sources (Sumber Mentah)
• The Wiki (Wiki)
• The Schema (Skema)

Skill obsidian-wiki saya juga dibangun di sekitar tiga lapisan ini.

Lapisan Pertama: Raw Sources

Di vault saya, lapisan ini terdiri dari:

• 01-Notes/
• 04-Output/

Yaitu, koleksi mentah, catatan mentah, dan artikel yang saya tulis.

Saya menjaga lapisan ini sangat terbatas.

Tanggung jawabnya hanya satu: menjaga konten asli.

Saya tidak membiarkannya mengambil fungsi tambahan.

Saya tidak mencampur konten turunan.

Saya tidak membiarkan artikel mentah menjadi setengah halaman topik, setengah halaman indeks.

Karena jika tercampur, akan sulit dirawat.

Ini adalah salah satu pelajaran terdalam yang saya dapat saat membangun skill ini: semakin bersih lapisan mentah, semakin mudah segalanya.

Lapisan Kedua: The Wiki

Lapisan ini terpisah di vault saya:

01-Notes/wiki/

Ini menyimpan lapisan struktural yang dihasilkan AI, seperti:

• Halaman penulis
• Halaman topik
• Indeks
• Log
• Direktori backlink

Dengan kata lain, teks asli tetap teks asli.

Wiki tetaplah Wiki.

Kedua lapisan terpisah.

Kedengarannya sepele, tapi sebenarnya sangat penting.

Karena jika Anda tidak memisahkan lapisan, setiap kali AI mengatur, ia cenderung membuat teks asli semakin berantakan.

Hari ini ia menambahkan blok topik.

Besok ia menyisipkan indeks.

Lusa ia menambahkan ringkasan otomatis.

Akhirnya, seluruh vault terlihat seperti ruangan yang terus-menerus dibereskan tapi semakin kacau.

Lapisan Ketiga: The Schema

Banyak orang mengabaikan lapisan ini.

Karpathy menyebutkan schema di tulisan aslinya. Pemahaman saya: Anda perlu memberi tahu AI seperti apa bentuk vault yang diinginkan.

Dalam kasus saya, ini mencakup:

• SKILL.md
• Sekumpulan scripts/
• Konvensi frontmatter
• Batasan cara penulisan penulis dan topik
• Batasan proses untuk lint dan ingest

Misalnya, sekarang saya menerapkan:

• Penulis harus dalam format backlink
• Topik harus berupa daftar backlink
• Halaman penulis dan halaman topik hanya boleh masuk ke 01-Notes/wiki/
• 00-Inbox/ hanya sebagai kotak masuk pemrosesan, tidak langsung dicampur ke Wiki
• Artikel mentah tidak lagi berisi paragraf turunan

Anda akan menemukan bahwa yang membuat skill berfungsi bukanlah seberapa indah prompt ditulis. Kunci sebenarnya adalah batasan-batasan ini ditetapkan terlebih dahulu.

Menerjemahkan Tiga Tindakan ke dalam Alur Kerja yang Dapat Dijalankan

Karpathy juga memiliki tiga tindakan inti:

• Ingest
• Query
• Lint

Saya mengikuti pendekatan yang sama.

Dalam alur kerja nyata skill ini, tampilannya seperti ini:

• Ingest: wiki_lint.py --preflight + ob_shuanglian.py suggest/apply + wiki_ingest.py
• Query: Baca dulu wiki/index.md, authors/*.md, topics/*.md, lalu kembali ke teks asli untuk detail
• Lint: wiki_lint.py, wiki_migrate.py, wiki_build_skeleton.py

Ingest: Periksa konten baru sebelum menambahkannya ke vault

Saya tidak membiarkan AI “melihat artikel lalu berimprovisasi” begitu saja.

Alur kerja saya saat ini dimulai dengan pemeriksaan preflight.

Pertama periksa apakah frontmatter benar.

Lalu periksa kontaminasi historis.

Kemudian buat saran backlink.

Setelah konfirmasi pengguna, baru terapkan.

Terakhir, segarkan lapisan turunan Wiki.

Kenapa repot-repot?

Karena model-model telah mengajari saya berkali-kali.

Jika Anda tidak menambahkan pagar pengaman ini, ia akan dengan bersemangat “membuat keputusan” untuk Anda.

Masalahnya, keputusannya mungkin bukan yang Anda inginkan.

Jadi saya menambahkan gerbang konfirmasi yang kuat.

Jangan biarkan ia menulis topik sembarangan.

Jangan biarkan ia menerapkan backlink langsung.

Jangan biarkan ia memutuskan alias penulis sendiri.

Berikan saran, saya konfirmasi, lalu tulis.

Ini mungkin tampak kurang efisien.

Tapi dengan basis pengetahuan, ketakutan terbesar bukanlah lambat; melainkan diam-diam menulis sesuatu yang salah.

Query: Bukan memancing di lautan teks asli, tapi membaca lapisan Wiki terlebih dahulu

Untuk query, pendekatan saya bukan “cari seluruh vault lalu serahkan ke AI untuk diringkas.”

Sebaliknya, ia pertama-tama melalui:

• wiki/index.md
• authors/*.md
• topics/*.md

Biarkan AI melihat lapisan terstruktur terlebih dahulu.

Jika perlu, kembali ke artikel spesifik untuk detail.

Manfaatnya jelas:

Ia tidak perlu merangkai ulang dari teks asli yang tersebar setiap saat.

Sebaliknya, ia menjawab dari lapisan yang sudah terorganisir.

Ini lebih mendekati apa yang dimaksud Karpathy dengan “akumulasi.”

Lint: Langkah terpenting dan paling diremehkan

Banyak orang fokus pada Query saat melihat LLM Wiki.

Tapi semakin saya mengerjakannya, semakin saya merasa bahwa Lint adalah tempat nilai sebenarnya berada.

Karena begitu basis pengetahuan tumbuh, sakit kepala terbesar Anda bukanlah “tidak bisa mendapatkan jawaban,” melainkan:

• Frontmatter berantakan
• Nama penulis tidak konsisten
• Topik tersebar
• Struktur historis masih tersisa di teks asli
• Halaman turunan semakin melenceng
• Konsep yang sama muncul dengan beberapa nama berbeda

Jika Anda mencoba merawat ini secara manual, itu akan membuat Anda gila.

Dan Anda tidak akan mampu mempertahankannya.

Inilah yang paling bisa dilakukan AI.

Bukan memahami dunia untuk Anda.

Tapi berpatroli di vault, merekonsiliasi, menemukan data kotor, dan mengisi referensi silang.

Itulah mengapa istilah Karpathy sangat tepat: pembukuan.

Jebakan Sebenarnya Bukan Modelnya, Melainkan Vault Catatan Lama Saya

Ini juga yang paling ingin saya peringatkan kepada semua orang.

Banyak orang membaca artikel seperti ini dan langsung berpikir:

“Oh, saya bisa unduh skillnya, instal, dan AI akan mengelola basis pengetahuan saya.”

Tidak demikian.

Tantangan terbesar dengan skill ini bukanlah prompt, skrip, atau bahkan modelnya.

Melainkan bahwa saya memiliki terlalu banyak catatan lama, dan formatnya tidak konsisten.

Saat saya menjalankan lint sekarang, inilah skala yang saya lihat:

• Sumber Mentah tipe artikel: 457
• Total file Mentah: 833
• Antrian tertunda: 249
• Direktori backlink sudah memiliki 471 topik

Bayangkan volumenya.

Ini bukan lagi tentang “mengatur beberapa catatan.”

Ini lebih seperti mengambil alih sistem lama dengan sejarah panjang dan tanpa standar yang konsisten.

Beberapa artikel memiliki nama penulis lengkap.

Beberapa memiliki alias.

Beberapa topik sangat detail.

Beberapa sangat tersebar.

Beberapa file lama masih mengandung sisa-sisa struktur sebelumnya.

Jadi saya semakin yakin akan satu hal:

Jika Anda ingin membangun LLM Wiki, langkah pertama bukanlah membiarkan AI mengambil alih. Langkah pertama adalah membersihkan vault Anda ke kondisi yang “layak diambil alih.”

Jika tidak, semakin rajin AI, semakin ia menyebarkan kekacauan.

Jadi, Apa Lagi yang Sebenarnya Dilakukan Skill Ini?

Jika Anda hanya membaca tulisan asli Karpathy, Anda akan mengira itu adalah metodologi yang sangat elegan.

Tapi saat benar-benar membangunnya, saya menemukan banyak detail rekayasa yang perlu diisi.

Misalnya:

• Standarisasi frontmatter
• Normalisasi alias penulis
• Menerapkan format backlink untuk topik
• Memisahkan sepenuhnya lapisan mentah dan turunan
• Menggunakan 00-Inbox/ sebagai kotak masuk pemrosesan
• Menambahkan gerbang konfirmasi pengguna di langkah-langkah kunci
• Memecah alur kerja dengan skrip seperti lint, migrate, ingest

Bukan berarti Karpathy tidak memikirkan ini.

Tapi Gist-nya menggambarkan sebuah pola, bukan implementasi spesifik untuk vault Anda.

Saat benar-benar menerapkan, Anda harus mengisi lapisan ini sendiri.

Skill obsidian-wiki saya saat ini pada dasarnya melakukan ini:

Menerjemahkan pola abstrak menjadi alur kerja yang berjalan di vault Obsidian saya sendiri.

Jadi jika Anda mengunduhnya, hal terpenting untuk dipelajari bukanlah “salin struktur direktori saya.”

Melainkan memahami mengapa saya melapisi seperti ini, mengapa konfirmasi diperlukan di sini, mengapa lint dilakukan di sini, mengapa auto-apply tidak digunakan di sini.

Jika Anda Ingin Melakukan Ini Juga, Ubah Hal-Hal Ini Terlebih Dahulu

Saya telah menempatkan versi yang sudah dibersihkan di halaman unduhan blog saya:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

Tapi setelah mengunduh, hal pertama bukanlah menjalankannya.

Melainkan memodifikasinya.

Setidaknya periksa hal-hal ini:

1. Apakah jalur vault Anda sama dengan milik saya?
2. Apakah struktur 01-Notes/, 04-Output/, 00-Inbox/ Anda sama?
3. Apakah bidang frontmatter Anda konsisten dengan milik saya?
4. Apakah nama penulis dan nama topik Anda sudah cukup konsisten?
5. Apakah Anda ingin mempertahankan alur kerja “saran, konfirmasi, lalu tulis” saya?
6. Jika skrip melibatkan API, apakah Anda sudah menggantinya dengan kunci Anda sendiri?

Versi yang saya rilis telah membersihkan kunci API dan jalur lokal.

Setelah Anda mendapatkannya, Anda harus menyesuaikannya dengan lingkungan Anda sendiri.

Dan saya tetap merekomendasikan: jangan perlakukan metode saya sebagai template, hanya sebagai referensi.

Jika vault Anda terutama berisi catatan bacaan, aturannya mungkin berbeda dengan milik saya.

Jika vault Anda terutama berisi catatan proyek, granularitas topik akan berbeda.

Jika vault Anda masih dalam fase “kumpulkan dulu, atur nanti,” Anda mungkin sebaiknya tidak fokus pada Query dulu, tetapi buat Lint dan Ingest berjalan lancar.

Jadi jangan menyalin mentah-mentah.

Modifikasi berdasarkan pendekatannya, itu lebih andal.

Ringkasan

Di akhir artikel ini, perasaan saya sendiri semakin jelas.

Usulan Karpathy bukan sekadar ide bahwa “AI dapat membantu Anda mengatur basis pengetahuan.”

Nilai sebenarnya adalah bahwa ia mendefinisikan ulang pembagian kerja antara manusia dan AI dalam manajemen pengetahuan.

Manusia menangani penilaian.

AI menangani pembukuan.

Semakin saya mengerjakan ini, semakin saya percaya pada pernyataan itu.

Yang saya pelajari hari ini:

1. Kunci LLM Wiki Karpathy adalah struktur tiga lapis dan tiga operasi, bukan satu prompt
2. Kunci skill seperti obsidian-wiki bukanlah “apakah bisa merangkum,” melainkan apakah bisa memisahkan Raw Sources, Wiki, dan Schema
3. Dalam praktiknya, Lint sering lebih penting daripada Query, karena pembersihan data historis adalah bagian terbesar dari pekerjaan
4. Semakin banyak catatan lama dan semakin berantakan formatnya, semakin Anda tidak boleh menyalin skill orang lain secara langsung
5. Mengunduh skill itu mudah; tantangan sebenarnya adalah menyesuaikannya agar cocok dengan basis pengetahuan Anda sendiri

Poin-poin penting:

• AI paling cocok untuk pembukuan, bukan berpikir untuk Anda
• Lapisan mentah dan turunan harus dipisahkan, jika tidak basis pengetahuan semakin diatur semakin berantakan
• Gerbang konfirmasi pengguna bukan langkah tambahan; itu adalah pagar pengaman yang diperlukan untuk mencegah AI bertindak sendiri
• Standarisasi format dulu, baru bicara otomatisasi; jika urutannya terbalik, Anda akan menderita nanti
• Skill ini bisa dimodifikasi, tapi tidak disarankan untuk menyalinnya apa adanya