{"content_id":"ardq66qm2e","slug":"claude-opus-5-verification-and-migration-guide","locale":"id","schema_type":"TechArticle","category":"how_to","category_name":"Panduan","title":"Cara Memeriksa Prompt dan Harness Sebelum Beralih ke Claude Opus 5","summary":"Menjelaskan cara membedakan karakteristik Claude Opus 5 yang diklaim dalam materi yang diberikan dari informasi yang dapat diverifikasi, serta cara merancang ulang prompt, harness, dan sistem evaluasi saat mengadopsi model generasi baru. Status peluncuran, harga, dan nama model harus selalu diperiksa melalui daftar model dan tabel harga resmi Anthropic.","author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["Tanggal peluncuran, harga, dan performa Claude Opus 5, Fable 5, serta Sonnet 5 yang tercantum dalam materi harus diverifikasi secara independen melalui sumber resmi sebelum digunakan.","Alih-alih langsung menyalin prompt lama ke model baru, kualitas, biaya, dan latensi harus diukur kembali menggunakan data pekerjaan nyata.","Instruksi verifikasi yang tumpang tindih dan pemanggilan subagent tanpa batas dapat meningkatkan biaya serta waktu eksekusi tanpa memperbaiki hasil.","Pemisahan instruksi sistem, aturan proyek, Skill yang dimuat saat diperlukan, dan referensi teknis memudahkan pengelolaan konteks.","Dibandingkan peringkat benchmark, evaluasi internal yang mencerminkan pekerjaan nyata dan biaya kegagalan organisasi memberikan dasar yang lebih langsung untuk memilih model."],"content_markdown":"Materi yang diberikan memperkenalkan Claude Opus 5 sebagai model yang disesuaikan untuk pekerjaan enterprise dan agen sehari-hari, serta menyatakan bahwa prompt dan harness yang ada perlu dirancang ulang untuk generasi baru Claude. Namun, **tanggal rilis, harga, performa, dan pernyataan mitra terkait Claude Opus 5, Fable 5, dan Sonnet 5 yang disebutkan dalam materi belum diverifikasi secara independen hanya berdasarkan informasi yang diberikan dalam tulisan ini.** Secara khusus, perlu diperiksa terlebih dahulu dalam daftar model resmi apakah `Fable` merupakan nama model resmi Anthropic.\n\nOleh karena itu, dokumen ini tidak mengulangi informasi rilis tersebut sebagai fakta yang telah dipastikan, tetapi mengelompokkan hal-hal yang perlu dikonfirmasi melalui dokumentasi resmi dan prosedur verifikasi yang dapat diterapkan dalam peralihan model aktual.\n\n## Informasi rilis yang harus diperiksa terlebih dahulu\n\nSebelum menerapkan model baru pada API, aplikasi Claude, atau Claude Code, hal-hal berikut harus dicocokkan dengan dokumentasi resmi Anthropic dan layar pemilihan model pada layanan yang digunakan.\n\n| Hal yang diperiksa | Klaim materi yang diberikan | Verifikasi yang diperlukan |\n|---|---|---|\n| Nama model | Claude Opus 5, Fable 5, Sonnet 5 | Nama produk dan ID model yang tepat dalam daftar model resmi |\n| Tanggal rilis | Masing-masing 9 Juni, 30 Juni, 24 Juli | Tahun dan tanggal dalam pengumuman resmi serta riwayat perubahan |\n| Harga Opus 5 | Input 5 dolar, output 25 dolar/1 juta token | Daftar harga API resmi, tarif terpisah untuk batch, cache, dan konteks panjang |\n| Model default dalam produk | Model default baru Claude Max | Ketersediaan berdasarkan wilayah, paket harga, dan klien |\n| Peran antarmodel | Dibagi menjadi pekerjaan otonom jangka panjang, pekerjaan sehari-hari, dan pekerjaan ringan | Deskripsi model resmi dan hasil evaluasi pekerjaan aktual |\n| Peningkatan performa | Peningkatan dengan persentase tertentu dibandingkan model sebelumnya | Tugas evaluasi, jumlah sampel, kriteria pengukuran, dan sumber asli mitra |\n\nJika nama model atau harga tidak tercantum dalam dokumentasi resmi, informasi tersebut tidak boleh digunakan untuk konfigurasi API dan perhitungan anggaran. Jika menggunakan penyedia cloud atau layanan penjualan kembali, ID model, harga, dan waktu ketersediaannya mungkin berbeda dari API langsung Anthropic.\n\n## Kriteria penilaian yang perlu berubah dalam peralihan model\n\n### 1. Ukur efisiensi per tugas, bukan performa tertinggi\n\nMemproses semua permintaan dengan model termahal dapat meningkatkan biaya dengan cepat ketika agen berulang kali memanggil berbagai alat dan subagent. Model harus dipilih bukan berdasarkan nama atau kelasnya, melainkan dengan mempertimbangkan indikator berikut secara bersamaan.\n\n- **Tingkat keberhasilan:** Persentase pemenuhan persyaratan tanpa perlu koreksi manusia\n- **Total biaya:** Biaya yang mencakup tidak hanya permintaan awal, tetapi juga percobaan ulang, pemanggilan alat, dan pemanggilan subagent\n- **Waktu penyelesaian:** Waktu yang mencakup waktu tunggu serta waktu peninjauan dan koreksi oleh manusia\n- **Biaya kegagalan:** Dampak yang ditimbulkan kegagalan, seperti celah keamanan, deployment yang salah, atau analisis yang terlewat\n- **Konsistensi:** Tingkat perubahan hasil ketika jenis tugas yang sama diulang\n\nBiaya per tugas tidak boleh dinilai hanya berdasarkan tarif token. Secara konseptual, biaya tersebut dapat dihitung sebagai berikut.\n\n`Total biaya per tugas = biaya model utama + biaya subagent + biaya alat + biaya percobaan ulang + biaya peninjauan manusia`\n\n### 2. Pisahkan benchmark publik dan evaluasi internal\n\nBenchmark publik merupakan titik awal untuk membandingkan karakteristik umum model, tetapi tidak menjamin keberhasilan pada codebase, format dokumen, atau aturan pekerjaan tertentu. Organisasi harus membuat set evaluasi internal yang menganonimkan pekerjaan aktual.\n\nSet evaluasi yang baik mencakup kasus-kasus berikut.\n\n- Tugas representatif yang harus diselesaikan secara normal\n- Kasus batas yang sering dijawab salah oleh model\n- Tugas dengan permintaan ambigu yang memerlukan pertanyaan tambahan\n- Tugas yang memerlukan pemanggilan alat atau pemeriksaan materi eksternal\n- Tugas berisiko tinggi yang mengharuskan eksekusi dihentikan atau persetujuan manusia diperoleh\n- Tugas yang mengharuskan status disimpan dan dipulihkan selama pelaksanaan jangka panjang\n\nAgar dapat dibandingkan, input, alat, batas waktu, dan kriteria keberhasilan yang sama harus diterapkan pada setiap model. Lebih aman mencatat tingkat keberhasilan dan distribusi biaya dari beberapa kali pengulangan daripada mengandalkan satu atau dua hasil yang mengesankan.\n\n### 3. Evaluasi model dan harness sebagai satu sistem\n\n**Harness** berarti lingkungan eksekusi yang mengelilingi model. Ini mencakup system prompt, petunjuk proyek, pencarian, memori, alat, Skill, subagent, pengelolaan izin, serta logika verifikasi dan percobaan ulang.\n\nModel yang sama dapat memberikan hasil berbeda bergantung pada harness. Misalnya, jika model itu sendiri menulis dan menjalankan pengujian sementara harness juga mewajibkan verifikasi yang sama, pekerjaan tersebut dapat terduplikasi. Sebaliknya, berisiko jika tahap yang memerlukan kontrol deterministik, seperti persetujuan deployment atau pemeriksaan keamanan, diserahkan pada penilaian otonom model.\n\nPrinsip utamanya adalah **membedakan penalaran yang dikuasai model dari kontrol yang wajib dijamin oleh sistem**.\n\n## 6 hal yang perlu diperiksa dalam prompt dan harness\n\n### 1. Hapus instruksi verifikasi dan pemeriksaan ulang yang duplikatif melalui eksperimen\n\nMenghapus tanpa syarat kalimat seperti `Setelah selesai, Anda wajib memeriksanya kembali` bukanlah jawaban yang selalu benar. Pertama-tama, lacak apakah verifikasi yang dilakukan secara sukarela oleh model baru bertumpang tindih dengan tahap verifikasi harness.\n\n- Jika peninjauan mandiri model hanya berulang tanpa meningkatkan kualitas, kurangi prompt.\n- Pertahankan pemeriksaan yang dapat diotomatisasi dalam harness, seperti pengujian, validasi skema, dan analisis statis.\n- Jangan mengganti persetujuan untuk tugas berisiko tinggi seperti pembayaran, deployment, dan penghapusan data dengan verifikasi mandiri model.\n\n### 2. Tetapkan syarat pemanggilan dan batas maksimum subagent\n\nsubagent berguna untuk riset paralel atau pemisahan bidang khusus, tetapi mendelegasikan tugas kecil sekalipun akan meningkatkan biaya dan latensi. Kebijakan berikut dapat ditetapkan secara eksplisit.\n\n- Gunakan subagent hanya untuk tugas yang dapat dibagi secara independen.\n- Batasi jumlah yang dapat dijalankan secara bersamaan dalam satu permintaan.\n- Berikan hasil akhir dan syarat penghentian yang jelas kepada setiap subagent.\n- Cegah beberapa agen menelusuri materi yang sama secara duplikatif.\n- Dapatkan persetujuan manusia jika perkiraan biaya atau waktu melampaui ambang batas.\n\n### 3. Ubah aturan larangan terperinci menjadi kriteria penilaian\n\nDaftar larangan yang panjang dapat saling bertentangan atau gagal menangani situasi baru. Untuk area berisiko rendah seperti gaya, model dapat diberi kewenangan untuk membaca konteks sekitar dan membuat penilaian.\n\n- Berbasis aturan: `Jangan pernah menulis docstring dalam beberapa paragraf.`\n- Delegasi penilaian: `Ikuti kepadatan komentar, format docstring, penamaan, dan idiom pada kode yang ada.`\n\nNamun, aturan dengan biaya pelanggaran yang besar, seperti penanganan data pribadi, keamanan, dan kewajiban hukum, harus dipertahankan dalam bentuk batasan eksplisit dan pemeriksaan terprogram.\n\n### 4. Tentukan panjang respons dan format output secara langsung\n\nSumber daya yang digunakan untuk penalaran dan panjang jawaban yang terlihat oleh pengguna bukanlah konsep yang sama. Meskipun klien menyediakan opsi intensitas penalaran seperti `effort` atau opsi serupa, jika memerlukan jawaban singkat, tuliskan ketentuan output secara terpisah.\n\nBerikut contohnya.\n\n- `Tuliskan kesimpulan terlebih dahulu dan rangkum alasannya dalam paling banyak tiga poin.`\n- `Tulis jawaban akhir dalam paling banyak 500 karakter.`\n- `Kembalikan hanya objek JSON yang valid tanpa penjelasan.`\n- `Laporkan hanya file yang diubah, alasan utama, dan risiko yang tersisa.`\n\n### 5. Kalibrasikan kembali intensitas penalaran menggunakan pekerjaan aktual\n\nJangan langsung menerapkan intensitas penalaran atau nilai default effort yang digunakan pada model sebelumnya ke model baru. Ukur kurva biaya dengan memulai dari pengaturan rendah dan meningkatkannya hanya ketika kualitas tidak memadai.\n\n| Jenis tugas | Arah pengaturan awal | Kondisi untuk meningkatkan |\n|---|---|---|\n| Klasifikasi dan konversi format | Mulai dari rendah | Ketika kesalahan skema atau kelalaian terjadi berulang kali |\n| Modifikasi dokumen dan kode umum | Bandingkan rentang menengah | Ketika dependensi beberapa file terlewat |\n| Debugging kompleks | Uji pada tingkat menengah atau lebih tinggi | Ketika tingkat keberhasilan analisis penyebab dan verifikasi tidak memadai |\n| Pekerjaan agen jangka panjang | Ukur per tahap | Bagian sulit yang memerlukan perencanaan ulang dan pemulihan |\n\nNama opsi yang tepat dan cakupan dukungannya dapat berbeda menurut versi API dan produk, sehingga dokumentasi resmi harus diperiksa.\n\n### 6. Pisahkan konteks berdasarkan peran dan ungkapkan secara bertahap\n\nJika semua petunjuk dimasukkan ke dalam satu system prompt atau `CLAUDE.md`, informasi yang tidak relevan pun dapat disertakan dalam setiap permintaan. Struktur hierarkis berikut bersifat praktis.\n\n1. **Petunjuk sistem dan produk:** Aturan yang selalu diperlukan, seperti peran, batas keamanan, dan kontrak output\n2. **Petunjuk proyek ringan:** Perintah build, struktur direktori, dan metode kerja umum\n3. **Skill yang dimuat saat diperlukan:** Prosedur bersyarat seperti deployment, perubahan database, dan framework tertentu\n4. **Referensi teknis:** Skema API, contoh kode, dokumen desain, dan spesifikasi yang dapat diuji\n\nHal ini dapat disebut **pengungkapan bertahap**. Model dapat mencari atau memuat materi yang diperlukan pada tahap saat ini, tetapi materi yang digunakan harus dicatat untuk memastikan reproduktibilitas dan kemampuan audit.\n\n## Prosedur migrasi yang disarankan\n\n### Tahap 1: Bekukan kondisi saat ini\n\nSimpan prompt model lama, versi alat, tingkat keberhasilan, penggunaan token, latensi, dan kasus kegagalan. Tanpa baseline, sulit untuk menilai apakah model baru benar-benar memberikan peningkatan.\n\n### Tahap 2: Verifikasi informasi dan izin model\n\nPeriksa ID model resmi, harga, batas konteks, dukungan alat, dan kebijakan retensi data. Di lingkungan pengujian, batasi izin untuk menulis, menghapus, dan melakukan deployment.\n\n### Tahap 3: Uji harness lama apa adanya\n\nPada awalnya, jangan mengubah semuanya sekaligus. Dengan hanya mengganti model dan membandingkannya dengan baseline, dampak perubahan model dapat dipisahkan.\n\n### Tahap 4: Hapus instruksi duplikatif satu per satu\n\nHapus satu per satu jenis instruksi verifikasi, aturan gaya yang bertele-tele, contoh yang tidak perlu, dan referensi yang selalu disuntikkan. Ukur kembali kualitas dan biaya setelah setiap perubahan.\n\n### Tahap 5: Buat kebijakan routing\n\nPilih model berdasarkan tingkat kesulitan pekerjaan, risiko, perkiraan konteks, dan batas waktu. Peran setiap model yang diusulkan oleh materi yang diberikan harus diuji sebagai hipotesis setelah nama resmi dan performanya dikonfirmasi, dan tidak boleh langsung diadopsi sebagai kebijakan operasional.\n\n### Tahap 6: Lakukan deployment mulai dari traffic terbatas\n\nTerapkan terlebih dahulu pada sebagian pengguna atau tugas yang tidak berisiko. Perluas cakupan setelah mengamati tingkat kegagalan, percobaan ulang, jumlah subagent, kesalahan alat, dan waktu koreksi manusia.\n\n## Checklist operasional\n\n- [ ] Nama model resmi dan ID model API telah diperiksa.\n- [ ] Tarif yang benar-benar diterapkan, termasuk input, output, cache, dan batch, telah diperiksa.\n- [ ] Tersedia set evaluasi internal yang terdiri atas pekerjaan aktual.\n- [ ] Tahap verifikasi model dan harness tidak tumpang tindih.\n- [ ] Tersedia kriteria pemanggilan subagent, jumlah eksekusi bersamaan, dan batas maksimum anggaran.\n- [ ] Panjang respons dan skema output telah ditentukan.\n- [ ] Kualitas, biaya, dan latensi berdasarkan intensitas penalaran telah dibandingkan.\n- [ ] Pemeriksaan deterministik dan persetujuan manusia tetap diberlakukan untuk tugas berisiko tinggi.\n- [ ] Konteks telah dipisahkan menjadi petunjuk tetap, Skill, dan referensi.\n- [ ] Model dan pengaturan lama untuk rollback telah disiapkan.\n\n## Kesimpulan\n\nInti peralihan ke model baru bukanlah mempersingkat prompt tanpa syarat atau memperluas otonomi tanpa syarat. Intinya adalah **memeriksa informasi produk resmi terlebih dahulu, lalu membagi kembali peran model dan harness melalui evaluasi pekerjaan aktual**.\n\nAngka dan nama terkait Claude Opus 5 dalam materi yang diberikan harus diperlakukan sebagai informasi sementara sampai dasar resminya dikonfirmasi. Namun, penghapusan verifikasi duplikatif, pembatasan subagent, kontrak output yang jelas, pengungkapan konteks secara bertahap, dan routing berbasis evaluasi internal merupakan prinsip peralihan yang dapat diterapkan terlepas dari generasi model.","content_html":"\u003cp\u003eMateri yang diberikan memperkenalkan Claude Opus 5 sebagai model yang disesuaikan untuk pekerjaan enterprise dan agen sehari-hari, serta menyatakan bahwa prompt dan harness yang ada perlu dirancang ulang untuk generasi baru Claude. Namun, \u003cstrong\u003etanggal rilis, harga, performa, dan pernyataan mitra terkait Claude Opus 5, Fable 5, dan Sonnet 5 yang disebutkan dalam materi belum diverifikasi secara independen hanya berdasarkan informasi yang diberikan dalam tulisan ini.\u003c/strong\u003e Secara khusus, perlu diperiksa terlebih dahulu dalam daftar model resmi apakah \u003ccode\u003eFable\u003c/code\u003e merupakan nama model resmi Anthropic.\u003c/p\u003e\n\u003cp\u003eOleh karena itu, dokumen ini tidak mengulangi informasi rilis tersebut sebagai fakta yang telah dipastikan, tetapi mengelompokkan hal-hal yang perlu dikonfirmasi melalui dokumentasi resmi dan prosedur verifikasi yang dapat diterapkan dalam peralihan model aktual.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#informasi-rilis-yang-harus-diperiksa-terlebih-dahulu\" class=\"anchor\" id=\"informasi-rilis-yang-harus-diperiksa-terlebih-dahulu\"\u003e\u003c/a\u003eInformasi rilis yang harus diperiksa terlebih dahulu\u003c/h2\u003e\n\u003cp\u003eSebelum menerapkan model baru pada API, aplikasi Claude, atau Claude Code, hal-hal berikut harus dicocokkan dengan dokumentasi resmi Anthropic dan layar pemilihan model pada layanan yang digunakan.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eHal yang diperiksa\u003c/th\u003e\n\u003cth\u003eKlaim materi yang diberikan\u003c/th\u003e\n\u003cth\u003eVerifikasi yang diperlukan\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Hal yang diperiksa\"\u003eNama model\u003c/td\u003e\n\u003ctd data-label=\"Klaim materi yang diberikan\"\u003eClaude Opus 5, Fable 5, Sonnet 5\u003c/td\u003e\n\u003ctd data-label=\"Verifikasi yang diperlukan\"\u003eNama produk dan ID model yang tepat dalam daftar model resmi\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Hal yang diperiksa\"\u003eTanggal rilis\u003c/td\u003e\n\u003ctd data-label=\"Klaim materi yang diberikan\"\u003eMasing-masing 9 Juni, 30 Juni, 24 Juli\u003c/td\u003e\n\u003ctd data-label=\"Verifikasi yang diperlukan\"\u003eTahun dan tanggal dalam pengumuman resmi serta riwayat perubahan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Hal yang diperiksa\"\u003eHarga Opus 5\u003c/td\u003e\n\u003ctd data-label=\"Klaim materi yang diberikan\"\u003eInput 5 dolar, output 25 dolar/1 juta token\u003c/td\u003e\n\u003ctd data-label=\"Verifikasi yang diperlukan\"\u003eDaftar harga API resmi, tarif terpisah untuk batch, cache, dan konteks panjang\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Hal yang diperiksa\"\u003eModel default dalam produk\u003c/td\u003e\n\u003ctd data-label=\"Klaim materi yang diberikan\"\u003eModel default baru Claude Max\u003c/td\u003e\n\u003ctd data-label=\"Verifikasi yang diperlukan\"\u003eKetersediaan berdasarkan wilayah, paket harga, dan klien\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Hal yang diperiksa\"\u003ePeran antarmodel\u003c/td\u003e\n\u003ctd data-label=\"Klaim materi yang diberikan\"\u003eDibagi menjadi pekerjaan otonom jangka panjang, pekerjaan sehari-hari, dan pekerjaan ringan\u003c/td\u003e\n\u003ctd data-label=\"Verifikasi yang diperlukan\"\u003eDeskripsi model resmi dan hasil evaluasi pekerjaan aktual\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Hal yang diperiksa\"\u003ePeningkatan performa\u003c/td\u003e\n\u003ctd data-label=\"Klaim materi yang diberikan\"\u003ePeningkatan dengan persentase tertentu dibandingkan model sebelumnya\u003c/td\u003e\n\u003ctd data-label=\"Verifikasi yang diperlukan\"\u003eTugas evaluasi, jumlah sampel, kriteria pengukuran, dan sumber asli mitra\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eJika nama model atau harga tidak tercantum dalam dokumentasi resmi, informasi tersebut tidak boleh digunakan untuk konfigurasi API dan perhitungan anggaran. Jika menggunakan penyedia cloud atau layanan penjualan kembali, ID model, harga, dan waktu ketersediaannya mungkin berbeda dari API langsung Anthropic.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#kriteria-penilaian-yang-perlu-berubah-dalam-peralihan-model\" class=\"anchor\" id=\"kriteria-penilaian-yang-perlu-berubah-dalam-peralihan-model\"\u003e\u003c/a\u003eKriteria penilaian yang perlu berubah dalam peralihan model\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-ukur-efisiensi-per-tugas-bukan-performa-tertinggi\" class=\"anchor\" id=\"1-ukur-efisiensi-per-tugas-bukan-performa-tertinggi\"\u003e\u003c/a\u003e1. Ukur efisiensi per tugas, bukan performa tertinggi\u003c/h3\u003e\n\u003cp\u003eMemproses semua permintaan dengan model termahal dapat meningkatkan biaya dengan cepat ketika agen berulang kali memanggil berbagai alat dan subagent. Model harus dipilih bukan berdasarkan nama atau kelasnya, melainkan dengan mempertimbangkan indikator berikut secara bersamaan.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eTingkat keberhasilan:\u003c/strong\u003e Persentase pemenuhan persyaratan tanpa perlu koreksi manusia\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTotal biaya:\u003c/strong\u003e Biaya yang mencakup tidak hanya permintaan awal, tetapi juga percobaan ulang, pemanggilan alat, dan pemanggilan subagent\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eWaktu penyelesaian:\u003c/strong\u003e Waktu yang mencakup waktu tunggu serta waktu peninjauan dan koreksi oleh manusia\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eBiaya kegagalan:\u003c/strong\u003e Dampak yang ditimbulkan kegagalan, seperti celah keamanan, deployment yang salah, atau analisis yang terlewat\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eKonsistensi:\u003c/strong\u003e Tingkat perubahan hasil ketika jenis tugas yang sama diulang\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBiaya per tugas tidak boleh dinilai hanya berdasarkan tarif token. Secara konseptual, biaya tersebut dapat dihitung sebagai berikut.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eTotal biaya per tugas = biaya model utama + biaya subagent + biaya alat + biaya percobaan ulang + biaya peninjauan manusia\u003c/code\u003e\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-pisahkan-benchmark-publik-dan-evaluasi-internal\" class=\"anchor\" id=\"2-pisahkan-benchmark-publik-dan-evaluasi-internal\"\u003e\u003c/a\u003e2. Pisahkan benchmark publik dan evaluasi internal\u003c/h3\u003e\n\u003cp\u003eBenchmark publik merupakan titik awal untuk membandingkan karakteristik umum model, tetapi tidak menjamin keberhasilan pada codebase, format dokumen, atau aturan pekerjaan tertentu. Organisasi harus membuat set evaluasi internal yang menganonimkan pekerjaan aktual.\u003c/p\u003e\n\u003cp\u003eSet evaluasi yang baik mencakup kasus-kasus berikut.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTugas representatif yang harus diselesaikan secara normal\u003c/li\u003e\n\u003cli\u003eKasus batas yang sering dijawab salah oleh model\u003c/li\u003e\n\u003cli\u003eTugas dengan permintaan ambigu yang memerlukan pertanyaan tambahan\u003c/li\u003e\n\u003cli\u003eTugas yang memerlukan pemanggilan alat atau pemeriksaan materi eksternal\u003c/li\u003e\n\u003cli\u003eTugas berisiko tinggi yang mengharuskan eksekusi dihentikan atau persetujuan manusia diperoleh\u003c/li\u003e\n\u003cli\u003eTugas yang mengharuskan status disimpan dan dipulihkan selama pelaksanaan jangka panjang\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAgar dapat dibandingkan, input, alat, batas waktu, dan kriteria keberhasilan yang sama harus diterapkan pada setiap model. Lebih aman mencatat tingkat keberhasilan dan distribusi biaya dari beberapa kali pengulangan daripada mengandalkan satu atau dua hasil yang mengesankan.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-evaluasi-model-dan-harness-sebagai-satu-sistem\" class=\"anchor\" id=\"3-evaluasi-model-dan-harness-sebagai-satu-sistem\"\u003e\u003c/a\u003e3. Evaluasi model dan harness sebagai satu sistem\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eHarness\u003c/strong\u003e berarti lingkungan eksekusi yang mengelilingi model. Ini mencakup system prompt, petunjuk proyek, pencarian, memori, alat, Skill, subagent, pengelolaan izin, serta logika verifikasi dan percobaan ulang.\u003c/p\u003e\n\u003cp\u003eModel yang sama dapat memberikan hasil berbeda bergantung pada harness. Misalnya, jika model itu sendiri menulis dan menjalankan pengujian sementara harness juga mewajibkan verifikasi yang sama, pekerjaan tersebut dapat terduplikasi. Sebaliknya, berisiko jika tahap yang memerlukan kontrol deterministik, seperti persetujuan deployment atau pemeriksaan keamanan, diserahkan pada penilaian otonom model.\u003c/p\u003e\n\u003cp\u003ePrinsip utamanya adalah \u003cstrong\u003emembedakan penalaran yang dikuasai model dari kontrol yang wajib dijamin oleh sistem\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-hal-yang-perlu-diperiksa-dalam-prompt-dan-harness\" class=\"anchor\" id=\"6-hal-yang-perlu-diperiksa-dalam-prompt-dan-harness\"\u003e\u003c/a\u003e6 hal yang perlu diperiksa dalam prompt dan harness\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-hapus-instruksi-verifikasi-dan-pemeriksaan-ulang-yang-duplikatif-melalui-eksperimen\" class=\"anchor\" id=\"1-hapus-instruksi-verifikasi-dan-pemeriksaan-ulang-yang-duplikatif-melalui-eksperimen\"\u003e\u003c/a\u003e1. Hapus instruksi verifikasi dan pemeriksaan ulang yang duplikatif melalui eksperimen\u003c/h3\u003e\n\u003cp\u003eMenghapus tanpa syarat kalimat seperti \u003ccode\u003eSetelah selesai, Anda wajib memeriksanya kembali\u003c/code\u003e bukanlah jawaban yang selalu benar. Pertama-tama, lacak apakah verifikasi yang dilakukan secara sukarela oleh model baru bertumpang tindih dengan tahap verifikasi harness.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eJika peninjauan mandiri model hanya berulang tanpa meningkatkan kualitas, kurangi prompt.\u003c/li\u003e\n\u003cli\u003ePertahankan pemeriksaan yang dapat diotomatisasi dalam harness, seperti pengujian, validasi skema, dan analisis statis.\u003c/li\u003e\n\u003cli\u003eJangan mengganti persetujuan untuk tugas berisiko tinggi seperti pembayaran, deployment, dan penghapusan data dengan verifikasi mandiri model.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-tetapkan-syarat-pemanggilan-dan-batas-maksimum-subagent\" class=\"anchor\" id=\"2-tetapkan-syarat-pemanggilan-dan-batas-maksimum-subagent\"\u003e\u003c/a\u003e2. Tetapkan syarat pemanggilan dan batas maksimum subagent\u003c/h3\u003e\n\u003cp\u003esubagent berguna untuk riset paralel atau pemisahan bidang khusus, tetapi mendelegasikan tugas kecil sekalipun akan meningkatkan biaya dan latensi. Kebijakan berikut dapat ditetapkan secara eksplisit.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eGunakan subagent hanya untuk tugas yang dapat dibagi secara independen.\u003c/li\u003e\n\u003cli\u003eBatasi jumlah yang dapat dijalankan secara bersamaan dalam satu permintaan.\u003c/li\u003e\n\u003cli\u003eBerikan hasil akhir dan syarat penghentian yang jelas kepada setiap subagent.\u003c/li\u003e\n\u003cli\u003eCegah beberapa agen menelusuri materi yang sama secara duplikatif.\u003c/li\u003e\n\u003cli\u003eDapatkan persetujuan manusia jika perkiraan biaya atau waktu melampaui ambang batas.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-ubah-aturan-larangan-terperinci-menjadi-kriteria-penilaian\" class=\"anchor\" id=\"3-ubah-aturan-larangan-terperinci-menjadi-kriteria-penilaian\"\u003e\u003c/a\u003e3. Ubah aturan larangan terperinci menjadi kriteria penilaian\u003c/h3\u003e\n\u003cp\u003eDaftar larangan yang panjang dapat saling bertentangan atau gagal menangani situasi baru. Untuk area berisiko rendah seperti gaya, model dapat diberi kewenangan untuk membaca konteks sekitar dan membuat penilaian.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eBerbasis aturan: \u003ccode\u003eJangan pernah menulis docstring dalam beberapa paragraf.\u003c/code\u003e\n\u003c/li\u003e\n\u003cli\u003eDelegasi penilaian: \u003ccode\u003eIkuti kepadatan komentar, format docstring, penamaan, dan idiom pada kode yang ada.\u003c/code\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNamun, aturan dengan biaya pelanggaran yang besar, seperti penanganan data pribadi, keamanan, dan kewajiban hukum, harus dipertahankan dalam bentuk batasan eksplisit dan pemeriksaan terprogram.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#4-tentukan-panjang-respons-dan-format-output-secara-langsung\" class=\"anchor\" id=\"4-tentukan-panjang-respons-dan-format-output-secara-langsung\"\u003e\u003c/a\u003e4. Tentukan panjang respons dan format output secara langsung\u003c/h3\u003e\n\u003cp\u003eSumber daya yang digunakan untuk penalaran dan panjang jawaban yang terlihat oleh pengguna bukanlah konsep yang sama. Meskipun klien menyediakan opsi intensitas penalaran seperti \u003ccode\u003eeffort\u003c/code\u003e atau opsi serupa, jika memerlukan jawaban singkat, tuliskan ketentuan output secara terpisah.\u003c/p\u003e\n\u003cp\u003eBerikut contohnya.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eTuliskan kesimpulan terlebih dahulu dan rangkum alasannya dalam paling banyak tiga poin.\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eTulis jawaban akhir dalam paling banyak 500 karakter.\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eKembalikan hanya objek JSON yang valid tanpa penjelasan.\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eLaporkan hanya file yang diubah, alasan utama, dan risiko yang tersisa.\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#5-kalibrasikan-kembali-intensitas-penalaran-menggunakan-pekerjaan-aktual\" class=\"anchor\" id=\"5-kalibrasikan-kembali-intensitas-penalaran-menggunakan-pekerjaan-aktual\"\u003e\u003c/a\u003e5. Kalibrasikan kembali intensitas penalaran menggunakan pekerjaan aktual\u003c/h3\u003e\n\u003cp\u003eJangan langsung menerapkan intensitas penalaran atau nilai default effort yang digunakan pada model sebelumnya ke model baru. Ukur kurva biaya dengan memulai dari pengaturan rendah dan meningkatkannya hanya ketika kualitas tidak memadai.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eJenis tugas\u003c/th\u003e\n\u003cth\u003eArah pengaturan awal\u003c/th\u003e\n\u003cth\u003eKondisi untuk meningkatkan\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Jenis tugas\"\u003eKlasifikasi dan konversi format\u003c/td\u003e\n\u003ctd data-label=\"Arah pengaturan awal\"\u003eMulai dari rendah\u003c/td\u003e\n\u003ctd data-label=\"Kondisi untuk meningkatkan\"\u003eKetika kesalahan skema atau kelalaian terjadi berulang kali\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Jenis tugas\"\u003eModifikasi dokumen dan kode umum\u003c/td\u003e\n\u003ctd data-label=\"Arah pengaturan awal\"\u003eBandingkan rentang menengah\u003c/td\u003e\n\u003ctd data-label=\"Kondisi untuk meningkatkan\"\u003eKetika dependensi beberapa file terlewat\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Jenis tugas\"\u003eDebugging kompleks\u003c/td\u003e\n\u003ctd data-label=\"Arah pengaturan awal\"\u003eUji pada tingkat menengah atau lebih tinggi\u003c/td\u003e\n\u003ctd data-label=\"Kondisi untuk meningkatkan\"\u003eKetika tingkat keberhasilan analisis penyebab dan verifikasi tidak memadai\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Jenis tugas\"\u003ePekerjaan agen jangka panjang\u003c/td\u003e\n\u003ctd data-label=\"Arah pengaturan awal\"\u003eUkur per tahap\u003c/td\u003e\n\u003ctd data-label=\"Kondisi untuk meningkatkan\"\u003eBagian sulit yang memerlukan perencanaan ulang dan pemulihan\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eNama opsi yang tepat dan cakupan dukungannya dapat berbeda menurut versi API dan produk, sehingga dokumentasi resmi harus diperiksa.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#6-pisahkan-konteks-berdasarkan-peran-dan-ungkapkan-secara-bertahap\" class=\"anchor\" id=\"6-pisahkan-konteks-berdasarkan-peran-dan-ungkapkan-secara-bertahap\"\u003e\u003c/a\u003e6. Pisahkan konteks berdasarkan peran dan ungkapkan secara bertahap\u003c/h3\u003e\n\u003cp\u003eJika semua petunjuk dimasukkan ke dalam satu system prompt atau \u003ccode\u003eCLAUDE.md\u003c/code\u003e, informasi yang tidak relevan pun dapat disertakan dalam setiap permintaan. Struktur hierarkis berikut bersifat praktis.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003ePetunjuk sistem dan produk:\u003c/strong\u003e Aturan yang selalu diperlukan, seperti peran, batas keamanan, dan kontrak output\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003ePetunjuk proyek ringan:\u003c/strong\u003e Perintah build, struktur direktori, dan metode kerja umum\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eSkill yang dimuat saat diperlukan:\u003c/strong\u003e Prosedur bersyarat seperti deployment, perubahan database, dan framework tertentu\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eReferensi teknis:\u003c/strong\u003e Skema API, contoh kode, dokumen desain, dan spesifikasi yang dapat diuji\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eHal ini dapat disebut \u003cstrong\u003epengungkapan bertahap\u003c/strong\u003e. Model dapat mencari atau memuat materi yang diperlukan pada tahap saat ini, tetapi materi yang digunakan harus dicatat untuk memastikan reproduktibilitas dan kemampuan audit.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#prosedur-migrasi-yang-disarankan\" class=\"anchor\" id=\"prosedur-migrasi-yang-disarankan\"\u003e\u003c/a\u003eProsedur migrasi yang disarankan\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#tahap-1-bekukan-kondisi-saat-ini\" class=\"anchor\" id=\"tahap-1-bekukan-kondisi-saat-ini\"\u003e\u003c/a\u003eTahap 1: Bekukan kondisi saat ini\u003c/h3\u003e\n\u003cp\u003eSimpan prompt model lama, versi alat, tingkat keberhasilan, penggunaan token, latensi, dan kasus kegagalan. Tanpa baseline, sulit untuk menilai apakah model baru benar-benar memberikan peningkatan.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#tahap-2-verifikasi-informasi-dan-izin-model\" class=\"anchor\" id=\"tahap-2-verifikasi-informasi-dan-izin-model\"\u003e\u003c/a\u003eTahap 2: Verifikasi informasi dan izin model\u003c/h3\u003e\n\u003cp\u003ePeriksa ID model resmi, harga, batas konteks, dukungan alat, dan kebijakan retensi data. Di lingkungan pengujian, batasi izin untuk menulis, menghapus, dan melakukan deployment.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#tahap-3-uji-harness-lama-apa-adanya\" class=\"anchor\" id=\"tahap-3-uji-harness-lama-apa-adanya\"\u003e\u003c/a\u003eTahap 3: Uji harness lama apa adanya\u003c/h3\u003e\n\u003cp\u003ePada awalnya, jangan mengubah semuanya sekaligus. Dengan hanya mengganti model dan membandingkannya dengan baseline, dampak perubahan model dapat dipisahkan.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#tahap-4-hapus-instruksi-duplikatif-satu-per-satu\" class=\"anchor\" id=\"tahap-4-hapus-instruksi-duplikatif-satu-per-satu\"\u003e\u003c/a\u003eTahap 4: Hapus instruksi duplikatif satu per satu\u003c/h3\u003e\n\u003cp\u003eHapus satu per satu jenis instruksi verifikasi, aturan gaya yang bertele-tele, contoh yang tidak perlu, dan referensi yang selalu disuntikkan. Ukur kembali kualitas dan biaya setelah setiap perubahan.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#tahap-5-buat-kebijakan-routing\" class=\"anchor\" id=\"tahap-5-buat-kebijakan-routing\"\u003e\u003c/a\u003eTahap 5: Buat kebijakan routing\u003c/h3\u003e\n\u003cp\u003ePilih model berdasarkan tingkat kesulitan pekerjaan, risiko, perkiraan konteks, dan batas waktu. Peran setiap model yang diusulkan oleh materi yang diberikan harus diuji sebagai hipotesis setelah nama resmi dan performanya dikonfirmasi, dan tidak boleh langsung diadopsi sebagai kebijakan operasional.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#tahap-6-lakukan-deployment-mulai-dari-traffic-terbatas\" class=\"anchor\" id=\"tahap-6-lakukan-deployment-mulai-dari-traffic-terbatas\"\u003e\u003c/a\u003eTahap 6: Lakukan deployment mulai dari traffic terbatas\u003c/h3\u003e\n\u003cp\u003eTerapkan terlebih dahulu pada sebagian pengguna atau tugas yang tidak berisiko. Perluas cakupan setelah mengamati tingkat kegagalan, percobaan ulang, jumlah subagent, kesalahan alat, dan waktu koreksi manusia.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#checklist-operasional\" class=\"anchor\" id=\"checklist-operasional\"\u003e\u003c/a\u003eChecklist operasional\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e Nama model resmi dan ID model API telah diperiksa.\u003c/li\u003e\n\u003cli\u003e Tarif yang benar-benar diterapkan, termasuk input, output, cache, dan batch, telah diperiksa.\u003c/li\u003e\n\u003cli\u003e Tersedia set evaluasi internal yang terdiri atas pekerjaan aktual.\u003c/li\u003e\n\u003cli\u003e Tahap verifikasi model dan harness tidak tumpang tindih.\u003c/li\u003e\n\u003cli\u003e Tersedia kriteria pemanggilan subagent, jumlah eksekusi bersamaan, dan batas maksimum anggaran.\u003c/li\u003e\n\u003cli\u003e Panjang respons dan skema output telah ditentukan.\u003c/li\u003e\n\u003cli\u003e Kualitas, biaya, dan latensi berdasarkan intensitas penalaran telah dibandingkan.\u003c/li\u003e\n\u003cli\u003e Pemeriksaan deterministik dan persetujuan manusia tetap diberlakukan untuk tugas berisiko tinggi.\u003c/li\u003e\n\u003cli\u003e Konteks telah dipisahkan menjadi petunjuk tetap, Skill, dan referensi.\u003c/li\u003e\n\u003cli\u003e Model dan pengaturan lama untuk rollback telah disiapkan.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#kesimpulan\" class=\"anchor\" id=\"kesimpulan\"\u003e\u003c/a\u003eKesimpulan\u003c/h2\u003e\n\u003cp\u003eInti peralihan ke model baru bukanlah mempersingkat prompt tanpa syarat atau memperluas otonomi tanpa syarat. Intinya adalah \u003cstrong\u003ememeriksa informasi produk resmi terlebih dahulu, lalu membagi kembali peran model dan harness melalui evaluasi pekerjaan aktual\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eAngka dan nama terkait Claude Opus 5 dalam materi yang diberikan harus diperlakukan sebagai informasi sementara sampai dasar resminya dikonfirmasi. Namun, penghapusan verifikasi duplikatif, pembatasan subagent, kontrak output yang jelas, pengungkapan konteks secara bertahap, dan routing berbasis evaluasi internal merupakan prinsip peralihan yang dapat diterapkan terlepas dari generasi model.\u003c/p\u003e\n","tags":["Rekayasa prompt","Agen AI","Anthropic","Claude","Evaluasi model"],"faqs":[{"question":"Apakah Claude Opus 5 merupakan model yang telah dirilis secara resmi?","answer":"Materi yang diberikan mencantumkan tanggal rilis dan harga, tetapi hal tersebut belum diverifikasi secara independen hanya berdasarkan informasi yang diberikan dalam tulisan ini. Sebelum nama model dan ID model yang tepat dikonfirmasi melalui daftar model resmi Anthropic, pengumuman, dan konsol API, sebaiknya informasi tersebut tidak dianggap sebagai informasi produk yang telah dipastikan."},{"question":"Apakah Fable 5 merupakan nama model resmi Anthropic?","answer":"Hal tersebut tidak dapat dikonfirmasi hanya berdasarkan materi yang diberikan. Meskipun nama produknya serupa, Anthropic dapat menggunakan ID model API atau penamaan yang berbeda untuk setiap layanan. Oleh karena itu, perlu diverifikasi dalam daftar model resmi apakah nama `Fable 5` benar-benar ada."},{"question":"Apakah semua prompt yang ada harus dihapus jika beralih ke model Claude yang baru?","answer":"Tidak. Pertama-tama, lakukan evaluasi dasar dengan konfigurasi yang ada, kemudian hapus satu per satu instruksi verifikasi yang tumpang tindih atau aturan gaya yang tidak diperlukan sambil membandingkan kualitas dan biaya. Kontrol yang harus dijamin oleh sistem, seperti pemeriksaan keamanan, validasi skema output, dan persetujuan deployment, harus tetap dipertahankan."},{"question":"Apa itu harness?","answer":"Harness adalah sistem yang mengelilingi model AI agar dapat dijalankan dalam pekerjaan nyata. Sistem ini mencakup prompt sistem, pedoman proyek, alat, pencarian, memori, Skill, subagent, percobaan ulang, pengelolaan izin, dan prosedur verifikasi otomatis."},{"question":"Bagaimana cara membatasi penggunaan subagent?","answer":"Gunakan hanya untuk tugas yang dapat dibagi secara independen dan tetapkan batas maksimum jumlah eksekusi simultan serta jumlah total pemanggilan. Hasil dan syarat penghentian setiap subagent harus ditentukan secara jelas. Sistem juga dapat dirancang agar meminta persetujuan manusia jika perkiraan biaya atau waktu melampaui ambang batas."},{"question":"Mengapa evaluasi internal lebih penting daripada benchmark publik?","answer":"Benchmark publik tidak sepenuhnya mencerminkan basis kode, format dokumen, lingkungan alat, dan biaya kegagalan suatu organisasi. Tingkat keberhasilan, total biaya, waktu penyelesaian, dan konsistensi hasil harus diukur menggunakan kasus pekerjaan nyata agar dapat menentukan model mana yang sesuai untuk lingkungan operasional."},{"question":"Jika model memiliki verifikasi mandiri, apakah pengujian dapat dihilangkan?","answer":"Tidak. Peninjauan mandiri oleh model merupakan sarana pendukung dan tidak menggantikan pengujian, pemeriksaan skema, analisis statis, maupun kebijakan keamanan. Terutama untuk tugas berisiko tinggi seperti deployment, pembayaran, dan penghapusan data, diperlukan pemeriksaan deterministik dan persetujuan manusia."},{"question":"Jika effort diturunkan, apakah jawaban juga otomatis menjadi lebih singkat?","answer":"Belum tentu. Intensitas penalaran dan panjang output akhir dapat menjadi sasaran kontrol yang terpisah. Jika memerlukan jawaban yang ringkas, format respons seperti jumlah karakter, jumlah butir, atau skema output harus ditentukan secara langsung dalam prompt."}],"sources":[{"url":"https://docs.anthropic.com/en/docs/about-claude/models/overview","title":"Dokumentasi Anthropic: Ikhtisar model","type":"source"},{"url":"https://www.anthropic.com/pricing","title":"Harga Anthropic","type":"data_point"},{"url":"https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview","title":"Dokumentasi Anthropic: Ikhtisar rekayasa prompt","type":"source"},{"url":"https://docs.anthropic.com/en/docs/claude-code/memory","title":"Dokumentasi Anthropic: Memori Claude Code","type":"source"}],"images":[{"id":324,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--f44d725b558668593419631e29f28834deb66ecc/ai-95ae89bc.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"체크 항목과 경고 장벽 사이에서 AI 큐브를 돋보기로 점검하는 일러스트","caption":"모델 전환 전 프롬프트와 하네스의 성능, 보안, 비용을 점검하는 과정을 나타낸다.","description":null},"en":{"alt":"Illustration of AI cubes being inspected beside a warning barrier and checklist icons","caption":"The scene represents checking prompts, harnesses, performance, security, and cost before a model switch.","description":null},"ja":{"alt":"警告バリケードと確認項目のそばでAIキューブを虫眼鏡で点検するイラスト","caption":"モデル移行前にプロンプトやハーネスの性能、安全性、コストを確認する工程を表している。","description":null},"es":{"alt":"Ilustración de cubos de IA inspeccionados junto a una barrera de alerta e iconos de control","caption":"La escena representa la revisión de prompts, arneses, rendimiento, seguridad y costes antes de cambiar de modelo.","description":null},"id":{"alt":"Ilustrasi kubus AI yang diperiksa di dekat penghalang peringatan dan ikon daftar cek","caption":"Adegan ini menggambarkan pemeriksaan prompt, harness, kinerja, keamanan, dan biaya sebelum beralih model.","description":null},"pt":{"alt":"Ilustração de cubos de IA inspecionados junto a uma barreira de alerta e ícones de verificação","caption":"A cena representa a revisão de prompts, harnesses, desempenho, segurança e custos antes da troca de modelo.","description":null},"zh-hant":{"alt":"在警示柵欄與檢查圖示旁以放大鏡檢視 AI 方塊的插圖","caption":"此圖呈現模型切換前檢查提示詞、工具框架、效能、安全性與成本的流程。","description":null}}},{"id":325,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5NiwicHVyIjoiYmxvYl9pZCJ9fQ==--5ddddd2dfbbbcedb1849fbdfe606aca94f9a98af/ai-b298a672.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"중앙 AI 모델에 보안, 문서, 사용자, 도구와 에이전트 차단 장치가 연결된 점검 구성도","caption":"모델 전환 전 프롬프트와 에이전트 하네스의 연결, 안전장치, 평가 항목을 점검하는 흐름을 나타낸다.","description":null},"en":{"alt":"AI model linked to security, documents, users, tools, agent controls, and evaluation indicators","caption":"The diagram contextualizes checks for prompts, agent harnesses, safeguards, and evaluations before a model switch.","description":null},"ja":{"alt":"中央のAIモデルにセキュリティ、文書、ユーザー、ツール、エージェント制御が接続された構成図","caption":"モデル移行前にプロンプトやエージェントハーネス、安全策、評価項目を確認する流れを示している。","description":null},"es":{"alt":"Modelo de IA conectado con seguridad, documentos, usuarios, herramientas, controles de agentes e indicadores","caption":"El diagrama representa la revisión de prompts, arneses de agentes, salvaguardas y evaluaciones antes de cambiar de modelo.","description":null},"id":{"alt":"Model AI terhubung ke keamanan, dokumen, pengguna, alat, kontrol agen, dan indikator evaluasi","caption":"Diagram ini menggambarkan pemeriksaan prompt, harness agen, pengaman, dan evaluasi sebelum pergantian model.","description":null},"pt":{"alt":"Modelo de IA ligado a segurança, documentos, usuários, ferramentas, controles de agentes e indicadores","caption":"O diagrama representa a verificação de prompts, harnesses de agentes, proteções e avaliações antes da troca de modelo.","description":null},"zh-hant":{"alt":"中央 AI 模型連接安全、文件、使用者、工具、代理控制與評估指標的架構圖","caption":"此圖呈現模型切換前對提示詞、代理框架、安全機制與評估項目的檢查流程。","description":null}}}],"published_at":"2026-07-28T11:42:11+09:00","updated_at":"2026-07-28T11:42:11+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/claude-opus-5-verification-and-migration-guide"}