Kebanyakan orang salah menulis Skill: 5 refleksi setelah Anthropic mengungkap metodologi internalnya

Penulis: Produk AI Ah Ying

Saya membaca sebuah blog dari 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, semua orang sangat suka membuat berbagai Skill gaya penulisan, Skill menulis. Sepertinya selama kita memasukkan gaya penulisan kita 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 kata bahkan puluhan ribu kata. Saat Skill dimuat, konteks akan langsung memakan sebagian besar ruang. Ketika konteks terlalu penuh, 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, banyak pekerjaan yang berulang-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 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, sebenarnya ada banyak pengalaman di dalamnya.

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, pengalaman yang terkumpul, dan kemampuan yang dapat digunakan kembali.

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

#01 Jangan Buat Omong Kosong

Pada dasarnya, Skill adalah proses menanamkan "pengetahuan tersembunyi" dalam organisasi. Jadi, dalam Skill jangan mengulang hal-hal yang sudah diketahui. Yang benar-benar berharga adalah informasi yang sebenarnya tidak diketahui model.

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

Contohnya:

1. Tabel ini tidak boleh diurutkan berdasarkan created_at

2. Mengembalikan 200 dari staging 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 para ahli.

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

#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.

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

Mari kita lihat lagi struktur umum dari 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, model pertama-tama membaca SKILL.md. Jika semua informasi dimasukkan ke dalam file ini, maka konteks akan cepat menjadi terlalu penuh.

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 SKILL.md, setiap kali memanggil Skill, Claude harus membacanya ulang.

Bahkan jika pengguna hanya ingin memastikan arti sebuah kode error, atau hanya ingin melihat mengapa status pembayaran tertentu tidak terupdate, banyak informasi yang sebenarnya tidak relevan juga akan ikut masuk ke konteks.

Namun, pendekatan Anthropic sangat berbeda.

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

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

Proses ini bersifat bertahap dan terbuka.

Gambar berikut sangat saya sarankan untuk disimpan.

#03 Usahakan pakai skrip

Jangan biarkan model membuang-buang kapasitas konteks dan kemampuan inferensi untuk pekerjaan berulang. Serahkan pekerjaan ini ke skrip.

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

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

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

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

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

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

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

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 masalah 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 berdasarkan pengalaman. Sedangkan check_payment_events() adalah Script, karena ini adalah 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 setiap kali harus dibuat ulang. Keduanya saling melengkapi.

#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 adalah, model tidak mencari Skill berdasarkan fungsi, melainkan saat Claude Code dijalankan, akan memindai semua nama dan Deskripsi Skill.

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

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

Deskripsi sebenarnya bertanggung jawab atas routing Skill secara keseluruhan.

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

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

Saya bahkan merasa bisa menggunakan metode sederhana ini untuk memeriksa.

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

Kalau tidak bisa, besar kemungkinan perlu diperbaiki lagi.

#05 Pengelolaan dan distribusi Skill

Ada satu hal lagi tentang pengelolaan 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 menurut saya sangat patut dipelajari.

Saat tim kecil, Skill langsung mengikuti repositori kode. Disimpan di folder .claude/skills dalam proyek. Semua berbagi Skill yang sama, juga metode kerja yang sama.

Namun seiring jumlah Skill bertambah, muncul masalah baru.

Saat Claude Code dijalankan, akan memindai semua nama dan Deskripsi Skill, lalu menentukan Skill mana yang harus dipanggil. Semakin banyak Skill, semakin tinggi biaya routing.

Ini juga alasan mereka mulai membangun Marketplace. Tapi yang lebih menarik adalah cara mereka mengelola Marketplace.

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

Saya melihat organisasi Anthropic sangat ringan.

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, penulis mengajukan ke Marketplace resmi.

Jadi mereka tidak menilai dulu apakah Skill ini bernilai, melainkan membiarkan Skill tersebut melalui pengujian di dunia nyata. Kalau banyak yang pakai, otomatis masuk ke sistem resmi. Skill yang tersisa adalah yang benar-benar dibutuhkan tim.