Claude Code Seri Tutorial 4: Apa Saja Kasus Penggunaan Claude Code?

Skenario Penggunaan Khas

Saya membagi skenario penggunaan menjadi empat kategori, diurutkan dari frekuensi tertinggi ke terendah.

Kategori Pertama: Memahami Kode

Ini mungkin yang paling sering digunakan. Saat mengambil alih proyek orang lain, melihat modul lama, atau membuka repositori tanpa dokumentasi, tanyakan langsung padanya.

Cara spesifik:

claude "Apa tujuan proyek ini? Di mana entry point-nya?" — Ini akan membaca package.json, struktur direktori, file kunci, dan memberikan ringkasan.
Buka sebuah fungsi, minta menjelaskan logika dan alurnya (dengan deskripsi teks).
Minta melacak jalur lengkap permintaan API dari frontend ke database.

Apa yang dilakukannya pada dasarnya adalah membantu Anda melakukan "pekerjaan kotor membaca kode". Anda tidak perlu grep berjam-jam lalu menyusun potongan di otak. Ia merapikan jalurnya, Anda yang menilai.

Objek pengganti skenario kategori ini: mencari-cari secara manual di basis kode, membuat catatan, menggambar diagram panggilan.

Kategori Kedua: Menulis dan Mengubah Kode

Ini adalah kategori yang paling banyak dibicarakan, tapi sebenarnya bukan yang paling sering digunakan. Skenario menulis kode biasanya seperti ini:

Membuat fitur baru: "Di bawah modul user, tambahkan antarmuka untuk mengubah email, dengan validasi format email, dan tulis unit test."
Refaktor lintas file: "Ganti semua moment() di tiga file ini dengan dayjs(), jangan ubah logika lain."
Migrasi dan upgrade: "Ubah komponen Vue 2 ini menjadi sintaks Vue 3 Composition API."

Kode yang dihasilkan mungkin tidak langsung benar, tapi ia bisa melakukan perubahan lintas file sekaligus, dan Anda bisa melihat diff per file, menerima atau menolak satu per satu.

Objek pengganti skenario kategori ini: menulis kode berulang secara manual, mencari dan mengganti referensi lintas file secara manual.

Kategori Ketiga: Debug dan Perbaikan

Saat bug muncul, alur kerja biasanya: lihat error, temukan file, tebak penyebab, coba ubah, jika tidak berhasil kembali lagi. Claude Code bisa langsung menerima seluruh stack trace error, dan bersama kode proyek, melokalisasi sendiri.

Penggunaan khas:

Berikan output tes yang gagal padanya, ia akan membaca kode terkait, memberikan solusi, lalu menjalankan tes lagi untuk melihat apakah lulus.
Jika ada error CI, tempel lognya, minta diperbaiki, lalu jalankan git diff untuk mengonfirmasi perubahan.

Perannya di sini lebih seperti "penyelidik putaran pertama". Yang memikirkan masalah adalah Anda, tapi yang membuka file, membandingkan perbedaan, dan menjalankan perintah verifikasi adalah ia.

Objek pengganti skenario kategori ini: menjalankan tes berulang kali, membaca log error, membandingkan perbedaan kode secara manual.

Kategori Keempat: Otomatisasi Lain-lain

Skenario ini paling tidak mencolok, tapi jika digabungkan, waktu yang dihemat paling banyak.

Contoh:

Menulis pesan commit Git: claude "Berdasarkan git diff saat ini, tulis pesan commit dengan format Conventional Commits"
Membuat deskripsi PR: Minta ia membandingkan perbedaan antara branch saat ini dan main, lalu buat ringkasan perubahan dan penjelasan pengujian.
Menulis catatan rilis: Minta Claude Code membaca riwayat commit seminggu terakhir, lalu buat CHANGELOG.
Menjawab masalah lingkungan: "Instal dependensi ini error, coba lihat output terminal, cari penyebabnya."

Kesamaan hal-hal ini: tidak rumit, tapi merepotkan. Jika dilakukan sendiri perlu pindah jendela, mengetik banyak. Serahkan padanya, selesai dalam beberapa detik.

Objek pengganti skenario kategori ini: mengedit teks secara manual, menulis dokumen yang sesuai standar, mencari masalah konfigurasi lingkungan.

Sebuah "Peta"

Jika keempat skenario ini dimasukkan ke dalam alur kerja sehari-hari, kira-kira seperti peta ini:

Mendapatkan proyek yang tidak familiar
    │
    ▼
[Memahami Kode] ─── Cari tahu struktur, entry point, logika kunci
    │
    ▼
Mulai menulis fitur baru atau mengubah modul
    │
    ▼
[Menulis/Mengubah Kode] ─── Hasilkan implementasi, refaktor lintas file
    │
    ▼
Jalankan tes, muncul bug
    │
    ▼
[Debug dan Perbaikan] ─── Analisis error, lokalisasi, perbaiki, jalankan lagi
    │
    ▼
Persiapan提交
    │
    ▼
[Otomatisasi Lain-lain] ─── Tulis commit, deskripsi PR, catatan rilis
    │
    ▼
提交, selesai

Anda tidak perlu menggunakan semuanya di empat kuadran ini. Beberapa tim hanya menggunakannya untuk memahami kode, yang lain hanya untuk menulis tes dan mengirim PR. Mana yang paling mengganggu Anda, mulailah dari skenario itu.

Dua Kriteria Penilaian yang Berguna

Jika Anda tidak yakin apakah suatu hal sebaiknya diserahkan ke Claude Code, tanyakan dua pertanyaan pada diri sendiri:

1. Apakah hal ini lebih bersifat "mekanis" daripada "kreatif"?

Mengubah seratus referensi, memformat output, menghasilkan kode boilerplate — hal-hal ini jika dilakukan sendiri akan memakan waktu, tapi Anda sudah punya idenya. Cocok untuk diserahkan padanya.

2. Apakah "biaya verifikasi" hal ini tinggi?

Jika suatu perubahan perlu bolak-balik, menjalankan tes, melihat log untuk memastikan, maka trial and error manual akan lambat. Claude Code bisa menyelesaikan siklus "ubah-jalankan-lihat-ubah lagi" sendiri, Anda akan jauh lebih ringan.