Anthropic akhirnya mengungkapkan metodologi Skill internal mereka

Saya membaca sebuah blog yang ditulis oleh tim Anthropic berjudul 《Lessons from building Claude Code: How we use skills》. Ini seharusnya adalah ringkasan praktik paling mendalam tentang Skill yang pernah saya lihat sejauh ini.

Skill sebenarnya tidak rumit, tetapi untuk benar-benar membuat Skill yang baik, saya rasa tidak semudah itu.

Saya ingat saat Skill mulai populer, banyak orang sangat suka membuat berbagai Skill gaya penulisan, Skill menulis. Sepertinya selama memasukkan gaya penulisan sendiri, model bisa secara stabil menghasilkan output sesuai gaya tersebut.

Namun setelah saya coba sendiri, saya menemukan banyak kasus di mana hal itu sama sekali tidak memungkinkan.

Karena sebuah gaya penulisan Skill mungkin hanya berisi beberapa ribu hingga puluhan ribu kata. Setelah Skill dimuat, konteks akan langsung memakan sebagian besar memori. Ketika konteks menjadi besar, kemampuan berpikir model malah cenderung menurun.

Akhirnya sering muncul situasi seperti ini: gaya berhasil dipelajari, tetapi isi menjadi dangkal, kemampuan analisis juga melemah.

Ada juga situasi umum lainnya.

Banyak orang saat menulis Skill, suka memasukkan berbagai instruksi operasional. Langkah pertama melakukan apa, langkah kedua melakukan apa, langkah ketiga melakukan apa. Hasilnya saat dijalankan, model tidak stabil dalam eksekusi.

Baru kemudian saya perlahan memahami bahwa banyak pekerjaan yang diulang-ulang seperti ini sebenarnya lebih cocok disusun menjadi Script, bukan ditulis sebagai instruksi panjang.

Setelah membaca artikel dari Anthropic ini, saya merasa bahwa banyak orang sebenarnya sudah menggunakan Skill, tetapi belum benar-benar memahami apa itu Skill.

Pada dasarnya, Skill adalah tentang melakukan Engineering Konteks. Kapan harus memasukkan pengetahuan ke dalam Skill, kapan harus memecahnya menjadi References, kapan harus menulisnya sebagai Script, kapan harus menggunakan Gotchas untuk membatasi model, semua ini sebenarnya mengandung banyak pengalaman.

Setelah memahami prinsip kerja Skill, jika kita kembali melihat Skill yang bagus, kita akan menyadari bahwa mereka bukan menyelesaikan masalah prompt, melainkan menyelesaikan masalah konteks, akumulasi pengalaman, dan reuse kemampuan.

Jika ingin mendalami penelitian tentang Skill, sangat direkomendasikan membaca dua artikel berikut:

#01 Jangan Buat Omong Kosong

Pada dasarnya, Skill adalah akumulasi pengetahuan implisit dalam organisasi. Jadi, jangan mengulang hal-hal yang sudah diketahui dalam Skill. Yang benar-benar berharga adalah informasi yang model sama sekali tidak tahu.

Di internal Anthropic sering ditekankan bahwa yang harus ditulis dalam Skill adalah Gotchas, yaitu jebakan yang sering dilalui.

Contohnya:

1、Daftar ini tidak boleh diurutkan berdasarkan created_at

2、Staging mengembalikan 200 tidak berarti berhasil

3、request_id dan trace_id adalah hal yang sama

Karena informasi ini biasanya ada dalam pengalaman karyawan. Jadi, penting untuk ingat apa esensi dari Skill.

Skill = menuliskan pengalaman dari master.

Melalui Skill, pengalaman yang tersebar di berbagai pikiran orang dapat diakumulasi.

#02 Skill sebenarnya adalah Engineering Konteks

Ini mungkin salah satu pandangan paling mendalam dari Anthropic.

Skill bukanlah sebuah file markdown, melainkan sebuah folder. Bagi yang pernah menggunakan Skill, ini terdengar seperti omong kosong.

Tapi dua hari terakhir ini, saya merenung dan perlahan menyadari: mereka sebenarnya ingin menggunakan format folder ini untuk mengekspresikan konsep Engineering Konteks.

Mari kita lihat lagi struktur umum dari sebuah Skill:

skill/ ├── SKILL.md ├── references/ (berisi penjelasan detail, referensi API, batasan) ├── scripts/ (berisi skrip yang dapat dieksekusi) ├── examples/ (berisi contoh) ├── assets/ (berisi template, gambar, bahan tetap)

Saat memanggil sebuah Skill, yang pertama dibaca model adalah SKILL.md. Jika semua informasi dimasukkan ke dalam file ini, maka konteks akan cepat menjadi terlalu besar dan berantakan.

Misalnya, ini adalah Skill troubleshooting pembayaran, berisi penjelasan kode error Stripe, kasus kerusakan sebelumnya, skrip troubleshooting, dan template laporan akhir.

Jika semua konten ini dimasukkan ke dalam SKILL.md, setiap kali memanggil Skill, Claude harus membacanya ulang dari awal.

Bahkan jika pengguna hanya ingin memastikan arti sebuah kode error, atau sekadar ingin melihat mengapa status pembayaran tertentu tidak terupdate, banyak informasi yang sebenarnya tidak perlu dan tetap akan dimasukkan ke dalam konteks.

Sedangkan pendekatan Anthropic sangat berbeda.

SKILL.md lebih seperti halaman navigasi. Tugasnya adalah memberi tahu model, saat menemui error Stripe, untuk mencari penjelasan terkait di references.

Kalau perlu merujuk kasus sebelumnya, cari di examples. Kalau perlu melakukan troubleshooting secara nyata, jalankan skrip di scripts. Saat membuat laporan troubleshooting, gunakan template di assets.

Proses ini bersifat progresif dan terstruktur.

Gambar di bawah ini sangat saya sarankan untuk disimpan.

#03 Usahakan pakai skrip

Jangan membuang kemampuan konteks dan inferensi model yang terbatas untuk pekerjaan berulang. Serahkan pekerjaan ini ke skrip.

Contohnya, banyak orang saat membuat Skill, menulis seperti ini:

1. Query data pendaftaran; 2. Query data pembayaran; 3. Hitung rasio konversi; 4. Analisis penyebab anomali.

Tentu saja, cara ini tidak salah. Model bisa menyelesaikannya. Tapi setiap kali dijalankan, model harus mengulangi seluruh proses analisis dari awal.

Pengambilan data, pengolahan data, penanganan berbagai kondisi batas, semua pekerjaan ini sebenarnya berulang-ulang.

Karena kemampuan ini sudah teruji berkali-kali, mengapa harus dibuat ulang oleh model? Lebih baik berikan skrip spesifik saja.

Selain itu, dengan skrip, eksekusi Skill akan lebih akurat dan lebih hemat Token.

Dari sudut pandang ini, Scripts dalam Skill sebenarnya adalah akumulasi kemampuan organisasi. Di balik setiap skrip, biasanya adalah praktik terbaik yang disusun dari pengalaman banyak kegagalan sebelumnya.

Dengan mengkonsolidasikan kemampuan ini, Claude setiap kali dapat bekerja berdasarkan pengalaman tersebut, bukan dari nol lagi.

Jadi, saya semakin yakin bahwa Instructions dan Scripts dalam Skill menyelesaikan dua level masalah yang berbeda.

Instructions menyampaikan pengalaman dan penilaian, sedangkan Scripts menyampaikan kemampuan dan eksekusi.

Contohnya, dalam Skill troubleshooting pembayaran mungkin ada kalimat seperti:

Jika Stripe mengembalikan 200, jangan langsung anggap pembayaran berhasil, perlu cek tabel payment_events.

Ini termasuk Instructions, karena berisi pengalaman, sedangkan check_payment_events() adalah Script, karena berisi kemampuan eksekusi.

Kalau hanya ada Script, model tahu cara melakukan pengecekan, tapi tidak tahu alasannya.

Kalau hanya Instructions, model tahu apa yang harus dilakukan, tapi harus dibuat ulang setiap saat. Keduanya sama-sama penting.

#04 Deskripsi lebih seperti aturan routing

Banyak orang salah dalam menulis Skill Description.

Karena mereka terbiasa menulis pengenalan fungsi. Misalnya: PR Management Skill membantu pengguna memantau status PR, menangani masalah CI, otomatis melakukan Merge.

Tapi masalahnya, model tidak mencari Skill berdasarkan fungsi, melainkan melalui nama dan Deskripsi Skill saat Claude Code diaktifkan.

Kemudian, berdasarkan masalah pengguna saat ini, model memutuskan Skill mana yang harus dimuat.

Jadi, informasi terpenting dalam Deskripsi bukanlah apa yang bisa dilakukan Skill, melainkan kapan harus memuatnya.

Deskripsi sebenarnya berfungsi sebagai routing untuk seluruh Skill.

Dalam dunia nyata, jarang orang mengatakan: tolong panggilkan alat manajemen PR. Mereka lebih sering berkata: tolong pantau PR ini, atau CI-nya error lagi.

Jadi, deskripsi yang baik harus menggambarkan niat pengguna, bukan sekadar daftar fungsi.

Saya bahkan ingin mencoba metode sederhana ini.

Setelah menulis Deskripsi, hapus seluruh isi Skill, tinggal simpan satu baris Deskripsi. Lalu tanya ke diri sendiri: setelah model melihat masalah pengguna, apakah dia bisa tahu kapan harus memuat Skill ini?

Kalau tidak bisa, kemungkinan besar perlu diperbaiki lagi.

#05 Manajemen dan distribusi Skill

Ada satu hal lagi tentang manajemen Skill.

Kalau satu orang pakai Skill sendiri, ini cukup sederhana. Menulis beberapa Skill, memelihara, dan memperbarui sendiri sudah cukup. Tapi saya yakin sebagian besar tim akan menghadapi masalah yang sama.

Ketika Skill dari beberapa menjadi puluhan, bahkan ratusan, bagaimana mengelolanya? Bagaimana memperbaruinya? Bagaimana mendistribusikannya ke anggota tim?

Pengalaman Anthropic dalam hal ini sangat patut dipelajari.

Dalam tim kecil, Skill langsung mengikuti kode sumber. Disimpan di folder .claude/skills di proyek. Semua berbagi Skill yang sama, dan metode kerja yang sama.

Namun, seiring jumlah Skill bertambah, muncul masalah baru.

Saat Claude Code diaktifkan, ia akan memindai semua nama dan deskripsi Skill, lalu memutuskan Skill mana yang harus dipanggil sesuai tugas. Semakin banyak Skill, semakin tinggi biaya routing.

Ini juga alasan mereka mulai membangun Marketplace. Tapi yang lebih menarik, mereka mengelola Marketplace dengan cara yang cukup ringan.

Banyak perusahaan yang menghadapi masalah ini, biasanya membuat proses approval. Siapa yang menulis Skill, harus mengajukan permohonan; setelah disetujui, baru masuk ke katalog Skill resmi. Kami juga pernah melakukan ini, tapi sangat kaku. Untuk sekadar mengelola.

Saya perhatikan, organisasi Anthropic sangat efisien.

Skill baru pertama kali disebarkan secara terbatas, biarkan rekan-rekan menginstal dan mencoba sendiri.

Kalau semakin banyak orang mulai menggunakannya, berarti Skill ini benar-benar menyelesaikan masalah nyata. Pada tahap ini, penulisnya baru mengajukan ke Marketplace resmi.

Jadi, mereka tidak menilai dulu apakah Skill bernilai, melainkan membiarkan Skill tersebut diuji dalam penggunaan nyata. Kalau banyak yang pakai, otomatis masuk ke sistem resmi. Skill yang tersisa adalah Skill yang benar-benar dibutuhkan tim.