---
title: "Aturan Rekayasa Konteks untuk Model Claude 5"
locale: id
category: ai_data
category_name: "Data AI"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/claude-5-context-engineering-rules
published_at: 2026-07-27T05:12:07+09:00
---

# Aturan Rekayasa Konteks untuk Model Claude 5

> Untuk model Claude dengan kemampuan penalaran yang lebih baik, tujuan yang jelas, alat yang dirancang dengan baik, dan materi referensi yang sesuai dengan tugas lebih penting daripada banyak aturan terperinci. Artikel ini menjelaskan prinsip dan prosedur penerapan desain konteks yang mengurangi instruksi berulang serta menyediakan informasi yang diperlukan pada waktu yang tepat.

## Key Points

- Rekayasa konteks adalah pekerjaan merancang bukan hanya prompt, tetapi juga instruksi sistem, alat, memori, file, riwayat percakapan, dan hasil eksekusi secara terpadu.
- Aturan keselamatan, hukum, izin, dan integritas data harus tetap ketat, sedangkan pedoman gaya yang berubah sesuai situasi sebaiknya diubah menjadi prinsip berbasis konteks.
- Alih-alih memasukkan semua informasi sejak awal, informasi harus disediakan saat diperlukan melalui pencarian, pembacaan file, Skills, dan subagen.
- Alih-alih mencantumkan contoh penggunaan alat secara berulang, antarmuka harus dirancang dengan nama yang jelas, skema input, definisi status, dan struktur kesalahan.
- CLAUDE.md, memori otomatis, kode, pengujian, dan spesifikasi harus memiliki peran yang berbeda, dan instruksi yang sama tidak boleh diduplikasi di beberapa lokasi.

Untuk menggunakan model Claude dengan kemampuan penilaian yang lebih baik secara efektif, sekadar menyempurnakan satu kalimat prompt tidaklah cukup. Instruksi sistem, file proyek, alat, memori, riwayat percakapan, dan hasil eksekusi yang akan dilihat model dalam satu proses penalaran harus dirancang sebagai satu lingkungan informasi.

Prinsip utamanya sederhana.

> Alih-alih menetapkan semua tindakan sebelumnya, berikan tujuan yang jelas, batas keamanan, antarmuka yang ekspresif, dan materi referensi yang dapat dipercaya, lalu serahkan penilaian terperinci kepada model.

Dalam artikel ini, `Claude 5` mengacu pada lingkungan model Claude berperforma tinggi generasi berikutnya sebagaimana disebutkan dalam materi yang disediakan. Fokusnya bukan pada spesifikasi produk atau status peluncuran tertentu, melainkan pada prinsip desain konteks yang dapat diterapkan pada model dengan kemampuan penilaian yang lebih baik.

## Rekayasa prompt dan rekayasa konteks

### Rekayasa prompt

Rekayasa prompt adalah pekerjaan merancang cara menyampaikan permintaan saat ini. Umumnya, hal ini mencakup unsur-unsur berikut.

- Tujuan tugas
- Cakupan pelaksanaan
- Batasan
- Format keluaran
- Kriteria keberhasilan
- Contoh yang diperlukan

Contohnya sebagai berikut.

```text
Implementasikan fitur pembatalan pembayaran pada Next.js API Route.
Gunakan kembali lapisan layanan yang sudah ada dan tambahkan pengujian.
Jangan mengubah kontrak API publik dan jelaskan alasan perubahan.
```

### Rekayasa konteks

Rekayasa konteks adalah pekerjaan menyeleksi dan memelihara keseluruhan kumpulan informasi yang masuk ke dalam penalaran model. Dalam agen pengodean seperti Claude Code, konteks secara garis besar terdiri atas unsur-unsur berikut.

```text
Permintaan pengguna saat ini
+ Instruksi sistem
+ CLAUDE.md dan instruksi proyek
+ Skills
+ Memori otomatis
+ Kode·spesifikasi·pengujian·dokumentasi
+ Definisi alat dan sumber daya MCP
+ Riwayat percakapan
+ Hasil eksekusi alat dan log kesalahan
```

Karena itu, prompt yang baik pun dapat menjadi kurang efektif jika diberikan bersama memori lama, aturan proyek yang berulang, atau log yang sangat besar. Sebaliknya, permintaan singkat pun dapat dijalankan dengan cukup akurat apabila disertai kode dan pengujian yang relevan serta alat yang jelas.

| Kategori | Rekayasa prompt | Rekayasa konteks |
|---|---|---|
| Objek desain | Penyampaian permintaan saat ini | Keseluruhan lingkungan informasi yang masuk ke penalaran |
| Pertanyaan utama | Apa yang harus diminta dan bagaimana cara memintanya | Apa yang harus dilihat model dan kapan model harus melihatnya |
| Unsur utama | Tujuan, format, batasan, contoh | Instruksi sistem, file, alat, memori, riwayat |
| Kegagalan utama | Permintaan ambigu, kriteria keberhasilan tidak jelas | Konflik, duplikasi, informasi lama, log berlebihan |
| Metode perbaikan | Memperjelas permintaan dan menyajikan kriteria verifikasi | Menyeleksi informasi bersinyal tinggi, pencarian tepat waktu, pengelolaan siklus hidup |

## Mengapa lebih banyak konteks tidak selalu lebih baik

Meskipun jendela konteks LLM membesar, kapasitas perhatian yang dapat digunakan untuk tugas tidaklah tak terbatas. Jika jumlah token yang kurang relevan meningkat, masalah berikut dapat muncul.

1. Persyaratan penting terkubur dalam penjelasan yang bertele-tele.
2. Instruksi serupa di lokasi berbeda saling bertentangan secara halus.
3. Keputusan lama atau upaya yang gagal memengaruhi tugas saat ini.
4. Contoh bertindak seperti jawaban yang benar dan membatasi jalur penyelesaian lainnya.
5. Log dan keluaran alat menghabiskan ruang yang diperlukan untuk kode, spesifikasi, dan pengujian.
6. Model menghabiskan penalaran untuk menafsirkan prioritas instruksi alih-alih mengerjakan tugas sebenarnya.

Anthropic menjelaskan fenomena menurunnya efisiensi pemanfaatan informasi dalam konteks panjang dan menyarankan agar agen dirancang untuk mencari informasi yang diperlukan tepat pada waktunya serta memadatkan riwayat lama. Hal yang penting bukanlah memenuhi jumlah token maksimum, melainkan meningkatkan proporsi token bersinyal tinggi yang memengaruhi hasil.

## Makna kasus pengurangan prompt sistem

Dalam kasus Anthropic yang disediakan, dijelaskan bahwa setelah meninjau instruksi internal Claude Code, prompt sistem dikurangi setidaknya 80%. Angka ini bukan aturan bahwa prompt semua aplikasi harus dikurangi dengan rasio yang sama. Kasus tersebut harus dipahami sebagai contoh penataan instruksi perilaku yang berulang dan terlalu terperinci dalam sistem tertentu.

Sebagai contoh, instruksi berikut dapat masuk secara bersamaan dalam satu permintaan.

```text
Instruksi sistem: Tinggalkan dokumentasi yang sesuai dengan situasi.
Instruksi Skill: Jangan menambahkan komentar.
Permintaan pengguna: Buat agar berfungsi seperti versi sebelumnya.
```

Setiap kalimat mungkin masuk akal secara terpisah, tetapi jika ditempatkan bersama, akan muncul berbagai masalah penafsiran.

- Apakah dokumentasi dan komentar kode termasuk dalam kategori yang sama?
- Apakah larangan komentar merupakan aturan tanpa pengecualian?
- Apakah perilaku versi sebelumnya juga mencakup komentar atau struktur dokumentasi?
- Mana yang lebih diprioritaskan, permintaan saat ini atau Skill yang dapat digunakan kembali?

Dalam kasus ini, penyebab kegagalan bukan hanya kemampuan pengodean model. Lingkungan informasi yang disusun manusia juga menjadi penyebab karena mengandung kontradiksi yang tidak perlu.

## Enam aturan baru untuk desain konteks

| Pendekatan lama | Pendekatan yang disarankan |
|---|---|
| Menetapkan perilaku terperinci sebagai daftar larangan | Menyajikan tujuan dan kriteria penilaian serta memanfaatkan konteks |
| Memberikan banyak contoh pemanggilan alat | Merancang agar skema itu sendiri menjelaskan cara penggunaan |
| Memasukkan semua informasi saat tugas dimulai | Mengungkapkannya secara bertahap pada saat diperlukan |
| Mengulangi instruksi yang sama di berbagai lokasi | Menetapkan satu lokasi penyimpanan otoritatif untuk setiap instruksi |
| Menyimpan hingga ingatan sementara dalam CLAUDE.md | Memisahkan peran kebijakan permanen dan memori otomatis |
| Mengandalkan penjelasan Markdown yang panjang | Menyediakan materi yang dapat dieksekusi seperti kode, pengujian, HTML, dan rubrik evaluasi |

### 1. Ubah daftar larangan terperinci menjadi prinsip berbasis konteks

Untuk mencegah kesalahan berulang dari model terdahulu, terkadang aturan seperti berikut dicantumkan secara panjang lebar.

- Jangan menulis komentar.
- Jangan membuat docstring yang terdiri atas beberapa paragraf.
- Jangan membuat dokumen rencana yang tidak diminta.
- Jangan menyimpan file analisis sementara.

Aturan semacam ini mencegah kegagalan tertentu, tetapi bukan prinsip mutlak yang berlaku untuk semua situasi. Verifikasi keamanan yang kompleks atau kode konkurensi mungkin memerlukan penjelasan, sedangkan komentar justru dapat menimbulkan gangguan dalam kode CRUD yang sudah jelas.

Lebih baik menyajikan kriteria penilaian seperti berikut.

```text
Tulis kode yang dapat dibaca dengan cara yang sama seperti kode di sekitarnya.
Ikuti aturan penamaan, ungkapan idiomatis, dan kepadatan komentar dalam file yang ada.
Tambahkan dokumentasi yang diperlukan hanya pada logika yang keamanan atau maksudnya tidak jelas tanpa penjelasan.
```

Namun, tidak semua aturan boleh dibuat lebih longgar. Unsur-unsur berikut harus tetap dipertahankan sebagai batasan eksplisit atau kontrol pada tingkat alat.

- Persetujuan deployment ke lingkungan produksi dan penghapusan data
- Pembatasan penanganan informasi pribadi dan informasi rahasia
- Verifikasi autentikasi dan otorisasi
- Idempotensi transaksi keuangan dan catatan audit
- Kebijakan migrasi basis data
- Kepatuhan terhadap hukum, lisensi, dan regulasi
- Kontrak API publik yang tidak dapat diubah

| Jenis aturan | Cara penanganan yang tepat |
|---|---|
| Keamanan·hukum·wewenang | Pertahankan batasan yang eksplisit dan kuat |
| Operasi yang berpotensi menyebabkan kehilangan data | Kendalikan melalui prosedur persetujuan dan izin alat |
| Kontrak publik·kompatibilitas | Verifikasi dengan pengujian dan skema |
| Gaya kode·komentar | Gunakan prinsip penilaian berdasarkan kode di sekitar |
| Urutan tugas sementara | Kelola dalam rencana atau daftar tugas saat ini |

### 2. Rancang alat yang ekspresif daripada memberikan banyak contoh

Jika contoh pemanggilan normal dan abnormal terus ditambahkan ke deskripsi alat, konteks akan membesar dan model dapat meniru bentuk permukaan contoh tersebut. Cara yang lebih baik adalah merancang nama alat, kolom masukan, dan transisi status agar menunjukkan cara penggunaannya.

```text
TodoWrite
Tujuan: Membuat dan memperbarui daftar tugas sesi saat ini

status:
- pending
- in_progress
- completed

Batasan:
- Hanya satu tugas yang dapat berstatus in_progress pada waktu yang sama
```

Alat agen yang baik memiliki karakteristik berikut.

- Nama saja sudah menunjukkan tindakan dan sasarannya.
- Kolom wajib dan kolom opsional dibedakan.
- Nilai yang diizinkan dibatasi dengan enum.
- Operasi baca dan tulis, serta pratinjau dan eksekusi, dipisahkan.
- Kesalahan mengembalikan penyebab dan metode pemulihan secara terstruktur.
- Operasi berbahaya memerlukan token konfirmasi atau tahap persetujuan.
- Jika hasil terlalu panjang, alat menyediakan ringkasan dan fungsi navigasi halaman.

Sebaiknya contoh hanya ditambahkan untuk menjelaskan pengecualian atau masukan ambigu yang sulit diungkapkan melalui antarmuka.

### 3. Jangan masukkan semua informasi sejak awal; ungkapkan secara bertahap

Jangan memasukkan seluruh repositori, semua kebijakan, dan log panjang sejak awal hanya karena agen mungkin memerlukannya untuk mengerjakan tugas. Pertama, berikan informasi minimum yang diperlukan untuk eksplorasi, lalu minta agen membaca materi yang relevan saat tugas menjadi lebih spesifik.

Alur yang disarankan adalah sebagai berikut.

1. Berikan tujuan, kriteria keberhasilan, dan batas keamanan.
2. Temukan lokasi yang relevan melalui struktur repositori atau alat pencarian.
3. Baca hanya file dan spesifikasi yang diperlukan.
4. Setelah implementasi, jalankan pengujian dan analisis statis yang relevan.
5. Jika gagal, ambil hanya kesalahan tersebut dan kode di sekitarnya sebagai tambahan.
6. Setelah selesai, padatkan atau hapus log lama dan penalaran perantara.

Pengungkapan bertahap bukan berarti menyembunyikan informasi. Ini adalah metode menyediakan jalur pencarian dan struktur file yang jelas agar model dapat menemukan informasi yang diperlukan.

### 4. Hapus instruksi duplikat dan tetapkan lokasi otoritatif

Jika aturan yang sama disalin ke prompt sistem, CLAUDE.md, Skill, dan deskripsi alat, redaksinya dapat berubah seiring waktu. Untuk setiap jenis instruksi, satu lokasi penyimpanan yang otoritatif harus ditetapkan.

| Informasi | Lokasi yang disarankan |
|---|---|
| Kebijakan keamanan seluruh organisasi | Instruksi sistem atau hierarki izin |
| Perintah build·pengujian repositori | CLAUDE.md proyek |
| Prosedur tugas tertentu | Skill terkait |
| Masukan dan batasan alat | Skema dan deskripsi alat |
| Perilaku API publik | Skema kode, spesifikasi, dan pengujian kontrak |
| Kemajuan sesi saat ini | Daftar tugas atau status sesi |

Jika duplikasi tidak dapat dihindari, lebih aman untuk merujuk ke lokasi otoritatif atau membuatnya secara otomatis daripada menyalin isinya.

### 5. Pisahkan peran CLAUDE.md dan memori otomatis

CLAUDE.md cocok untuk instruksi berkelanjutan yang dapat ditinjau dan dikelola versinya oleh anggota proyek.

- Perintah build dan pengujian standar
- Penjelasan inti mengenai struktur repositori
- Area terlarang untuk perubahan yang telah disepakati tim
- Prosedur verifikasi khusus proyek
- Aturan yang sulit disimpulkan dengan alat umum

Sebaliknya, informasi berikut lebih cocok untuk memori otomatis atau status sesi.

- Preferensi personal yang ditemukan dalam tugas berulang
- Jalur eksplorasi yang berguna dalam tugas terbaru
- Karakteristik lingkungan pengembangan yang bersifat sementara
- Kemajuan sesi saat ini

Memori otomatis tidak boleh diasumsikan selalu akurat atau permanen. Entri lama harus dapat diperbaiki atau dihapus, dan memori otomatis tidak boleh digunakan sebagai satu-satunya tempat penyimpanan kebijakan keamanan serta kontrak publik.

### 6. Prioritaskan materi referensi yang dapat dieksekusi daripada dokumen penjelasan

Spesifikasi bahasa alami berguna untuk menjelaskan maksud, tetapi mungkin tidak dapat menggambarkan perilaku sebenarnya secara lengkap. Jika memungkinkan, sediakan juga materi berikut.

- Implementasi yang sudah ada dan serupa dengan kode saat ini
- Pengujian unit dan pengujian integrasi
- Skema API dan definisi tipe
- HTML aktual atau hasil desain
- File migrasi basis data
- Contoh data masukan·keluaran
- Rubrik evaluasi dan kriteria penilaian otomatis

Konflik juga dapat terjadi di antara materi referensi, sehingga prioritasnya harus dinyatakan secara eksplisit. Misalnya, dapat ditetapkan bahwa pengujian kontrak merupakan standar otoritatif untuk API publik, sedangkan README merupakan materi penjelasan.

## Templat penyusunan konteks untuk praktik kerja

Struktur berikut adalah contoh penataan ringkas atas informasi yang diperlukan untuk tugas pengodean.

```text
Tujuan
- Tambahkan API pembatalan pembayaran.

Kriteria keberhasilan
- Gunakan kembali lapisan layanan pembayaran yang sudah ada.
- Meskipun ada permintaan duplikat, pembatalan hanya dilakukan sekali.
- Pengujian kontrak terkait berhasil.

Batasan kuat
- Jangan mengubah skema respons publik.
- Jangan mengakses data produksi.

Materi referensi
- src/payments/capture.ts
- tests/contracts/payment-cancel.test.ts
- openapi/payments.yaml

Prinsip penilaian
- Ikuti penanganan kesalahan dan aturan penamaan pada kode pembayaran di sekitarnya.
- Jika ada asumsi yang tidak aman, ajukan pertanyaan sebelum implementasi.

Verifikasi
- Pengujian unit target
- Pengujian kontrak
- Pemeriksaan tipe
```

Format ini tidak mencantumkan semua situasi sebelumnya. Sebaliknya, format ini memisahkan tujuan, kondisi keberhasilan, batas yang tidak berubah, materi otoritatif, dan metode verifikasi.

## Prosedur menata konteks yang sudah ada

### Langkah 1: Daftar semua sumber instruksi

Periksa prompt sistem, CLAUDE.md, Skills, memori otomatis, deskripsi alat, dan konfigurasi CI secara bersamaan. Jika hanya memeriksa satu dokumen, konflik yang sebenarnya sulit ditemukan.

### Langkah 2: Berikan klasifikasi pada setiap instruksi

- Wajib demi keamanan atau hukum
- Wajib berdasarkan kontrak produk
- Kebiasaan berkelanjutan tim
- Penjelasan yang hanya diperlukan untuk alat tertentu
- Aturan sementara untuk mencegah kesalahan model terdahulu
- Aturan yang dasar alasannya saat ini tidak jelas

### Langkah 3: Temukan duplikasi dan konflik

Kelompokkan kalimat yang mengungkapkan perilaku yang sama dengan cara berbeda. Tinjau terlebih dahulu ungkapan seperti `selalu`, `tidak pernah`, `wajib`, dan `jangan`.

### Langkah 4: Pindahkan aturan ke pengujian atau izin

Untuk unsur yang dapat diverifikasi secara otomatis dengan lebih pasti daripada melalui peringatan bahasa alami, pindahkan ke lapisan berikut.

- Pengujian dan linter
- Sistem tipe dan skema
- Alat dengan hak akses minimum
- Prosedur persetujuan
- Sandbox
- Kebijakan CI

### Langkah 5: Evaluasi dengan tugas nyata

Jangan hanya mengukur panjang prompt. Bandingkan metrik berikut pada kumpulan tugas yang representatif.

- Tingkat keberhasilan dan tingkat kelulusan pengujian
- Jumlah perubahan file yang tidak perlu
- Jumlah koreksi oleh pengguna
- Tingkat kegagalan pemanggilan alat
- Waktu dan token yang diperlukan hingga selesai
- Ada atau tidaknya pelanggaran kebijakan keamanan

### Langkah 6: Tambahkan perbaikan minimum hanya untuk penyebab kegagalan

Jangan langsung menambahkan aturan larangan baru ketika terjadi kegagalan. Bedakan terlebih dahulu apakah penyebabnya adalah tujuan yang ambigu, materi referensi yang tidak memadai, atau skema alat yang salah.

## Instruksi yang tidak boleh dihapus

Penyederhanaan bukan berarti penghapusan tanpa syarat. Jika jawaban untuk salah satu pertanyaan berikut adalah `ya`, instruksi harus dipertahankan atau dipindahkan ke kontrol yang lebih kuat.

- Apakah pelanggaran dapat menyebabkan kehilangan data atau kerugian finansial?
- Apakah terkait dengan kewajiban hukum, informasi pribadi, atau lisensi?
- Apakah ini kebijakan organisasi yang tidak dapat diketahui model hanya dengan melihat kode?
- Apakah menentukan kompatibilitas API publik atau format data?
- Apakah persetujuan manusia diperlukan sebelum tugas dijalankan?
- Apakah pelanggaran sulit dideteksi sepenuhnya hanya dengan pengujian otomatis?

## Pola kegagalan umum

### Menambahkan aturan baru setelah setiap kegagalan

Jika satu kesalahan digeneralisasi menjadi aturan permanen, pengecualian dan konflik akan terus menumpuk. Tambahkan kasus evaluasi terlebih dahulu dan pastikan apakah kegagalan tersebut berulang.

### Menggunakan contoh panjang sebagai templat secara de facto

Jika contoh terlalu spesifik, model dapat memprioritaskan contoh daripada basis kode saat ini. Batasi contoh pada ukuran minimum yang diperlukan untuk menjelaskan prinsip.

### Menyimpan seluruh log apa adanya

Keluaran alat dan log build cepat memenuhi konteks. Sebaiknya simpan hanya penyebab kegagalan, stack yang relevan, dan status yang berubah secara terstruktur.

### Menggunakan memori otomatis sebagai tempat penyimpanan kebijakan

Memori otomatis memang praktis, tetapi sistem peninjauan, deployment, dan auditnya mungkin lemah. Kebijakan wajib organisasi harus disimpan dalam instruksi yang dikelola versinya atau hierarki izin.

### Menilai pengurangan konteks hanya sebagai penghematan token

Konteks yang pendek tidak selalu baik. Jika pengujian, aturan keamanan, atau spesifikasi yang diperlukan dihapus, hasilnya akan memburuk. Tujuannya bukan token minimum, melainkan jumlah minimum token bersinyal tinggi.

## Daftar periksa akhir

- Apakah tujuan dan kriteria keberhasilan permintaan saat ini dipisahkan?
- Apakah aturan keamanan dibedakan dari preferensi gaya?
- Apakah instruksi yang sama tidak disalin ke berbagai lokasi?
- Apakah skema alat menjelaskan cara penggunaan tanpa contoh panjang?
- Apakah file terkait dapat dicari saat diperlukan?
- Apakah tersedia cara untuk menghapus memori lama dan log eksekusi?
- Apakah aturan bahasa alami dapat diberlakukan melalui pengujian atau izin?
- Apakah prioritas di antara materi referensi sudah jelas?
- Apakah tersedia tugas evaluasi untuk membandingkan kondisi sebelum dan sesudah perubahan instruksi?

## Kesimpulan

Rekayasa konteks untuk model Claude berperforma tinggi bukanlah teknik untuk mengurangi instruksi tanpa syarat. Ini adalah desain informasi yang memperjelas tujuan, batas keamanan, dan dasar yang diperlukan model untuk menilai tugas saat ini, sekaligus menghapus informasi yang tidak relevan serta aturan yang saling bertentangan.

Prinsip yang paling praktis dapat diringkas sebagai berikut.

> Terapkan keamanan dan kontrak secara ketat, serahkan gaya kepada konteks, berikan informasi pada saat diperlukan, dan verifikasi hasil melalui pengujian yang dapat dieksekusi.

## FAQ

### Apa perbedaan antara rekayasa prompt dan rekayasa konteks?
Rekayasa prompt membahas cara mengungkapkan tujuan, format, dan batasan permintaan saat ini. Rekayasa konteks merancang apa saja dari instruksi sistem, file, alat, memori, riwayat percakapan, dan hasil eksekusi—termasuk prompt tersebut—yang akan ditampilkan kepada model dan kapan menampilkannya.

### Apakah konteks yang panjang selalu meningkatkan kinerja model?
Tidak. Konteks yang panjang dapat berisi campuran informasi yang tidak relevan, riwayat lama, dan instruksi yang saling bertentangan. Yang penting bukan jumlah total token, melainkan proporsi informasi bersinyal tinggi yang berkontribusi langsung pada tugas saat ini.

### Apakah semua aturan yang ada perlu dihapus untuk Claude 5?
Tidak. Aturan terperinci yang bergantung pada situasi, seperti gaya kode atau komentar, dapat diubah menjadi prinsip penilaian, tetapi batasan terkait keamanan, informasi pribadi, wewenang, transaksi keuangan, penghapusan data, dan kontrak API publik harus dipertahankan atau dikendalikan lebih ketat melalui alat dan pengujian.

### Konten apa yang tepat untuk dimasukkan ke dalam CLAUDE.md?
Instruksi yang berkelanjutan dan dapat ditinjau, seperti perintah build dan pengujian proyek, struktur repositori, area yang tidak boleh diubah, serta prosedur verifikasi yang disepakati tim, adalah konten yang tepat. Jika semua status progres sementara atau temuan yang dipersonalisasi disimpan, dokumen dapat dengan cepat menjadi usang.

### Apakah memori otomatis dapat menggantikan CLAUDE.md?
Tidak dapat menggantikannya sepenuhnya. Memori otomatis berguna untuk mempertahankan preferensi atau informasi penelusuran yang ditemukan dalam tugas berulang, tetapi instruksi yang memerlukan audit dan pengelolaan versi, seperti kebijakan keamanan dan kontrak publik, harus ditempatkan di CLAUDE.md atau lapisan kebijakan terpisah.

### Apa saja karakteristik antarmuka alat agen yang baik?
Tujuannya harus dapat dipahami hanya dari nama alat dan skema inputnya, sedangkan nilai wajib dan status yang diizinkan harus jelas. Operasi tulis yang berisiko sebaiknya mewajibkan pratinjau atau persetujuan, dan kesalahan sebaiknya mengembalikan penyebab serta cara pemulihan secara terstruktur.

### Apakah pengungkapan progresif berarti menyembunyikan informasi dari model?
Tidak. Ini adalah metode yang mula-mula memberikan tujuan dan jalur penelusuran, lalu memungkinkan model mencari file, spesifikasi, dan log yang diperlukan sambil memperjelas tugas. Tujuannya adalah mengurangi penyuntikan awal yang tidak perlu sambil tetap mempertahankan aksesibilitas informasi.

### Bagaimana cara mengevaluasi efektivitas setelah mengurangi konteks?
Pada sekumpulan tugas representatif, tingkat kelulusan pengujian, jumlah koreksi pengguna, perubahan yang tidak perlu, kesalahan alat, penggunaan token, serta ada tidaknya pelanggaran kebijakan keamanan harus dibandingkan antara sebelum dan sesudah perubahan. Keberhasilan tidak boleh dinilai hanya berdasarkan pengurangan panjang prompt.

### Apakah contoh penggunaan alat sama sekali tidak perlu diberikan?
Contoh tidak selalu tidak diperlukan. Contoh minimal berguna ketika terdapat kasus batas atau input ambigu yang sulit diungkapkan hanya dengan skema. Namun, memperjelas antarmuka itu sendiri harus diprioritaskan daripada mencantumkan panggilan normal secara berulang.

## Sources

- [Rekayasa konteks yang efektif untuk agen AI](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Membangun agen yang efektif](https://www.anthropic.com/engineering/building-effective-agents)
- [Ikhtisar rekayasa prompt](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)
- [Dokumentasi memori Claude Code](https://docs.anthropic.com/en/docs/claude-code/memory)

## Images

![Ikon dokumen dan data mengalir melalui corong menuju jaringan AI pusat](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzMywicHVyIjoiYmxvYl9pZCJ9fQ==--b6a9225f1d5837dd6ca93532a1e1a3388a1cc4fc/ai-e5c0c894.webp)
![Alur kerja AI dengan robot melalui pencarian, berkas, alat, kode, validasi, dan laporan menuju sasaran](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzOSwicHVyIjoiYmxvYl9pZCJ9fQ==--c5e1421a425951ca760407e2d7b6c78654f545e5/ai-8b2296c2.webp)