System Prompt Claude: Cara Menetapkan Batasan Nada untuk Dokumentasi Teknis

Dokumentasi teknis sering kali gagal secara halus sebelum gagal secara faktual. Sebuah draf bisa jadi akurat namun terlalu santai, terlalu promosi, terlalu bertele-tele, terlalu samar mengenai ketidakpastian, atau tidak konsisten dengan bagian lain dari set dokumentasi. Jika Anda menggunakan Claude untuk menghasilkan panduan API, artikel pemecahan masalah, catatan rilis, runbook internal, atau dokumentasi pengembang, system prompt adalah salah satu tempat terbaik untuk mendefinisikan batasan penulisan yang persisten tersebut.

Ada juga perubahan perilaku model terkini yang perlu dicatat. Per September 2026, dokumentasi deprecation Anthropic menyatakan bahwa temperature, top_p, dan top_k telah dideprekasi untuk Claude Opus 4.7 ke atas dan Claude Mythos Preview, dengan rekomendasi penggunaan prompting sebagai gantinya untuk kontrol perilaku. Hal ini membuat instruksi gaya eksplisit di level system menjadi lebih penting daripada resep lama yang mencoba membentuk nada terutama melalui parameter sampling. Lihat panduan deprecation model dan API Anthropic.

Apa yang seharusnya dikendalikan oleh “batasan nada”?

Batasan nada harus mendefinisikan perilaku komunikasi yang tetap stabil di berbagai permintaan dokumentasi. Ini bukan sekadar “terdengar profesional.” Batasan yang berguna biasanya mencakup lima hal: audiens, suara, tingkat detail, bahasa ketidakpastian yang dapat diterima, dan kebiasaan format.

Misalnya, asisten dokumentasi yang ditujukan untuk pengembang mungkin diberi instruksi untuk menulis dengan nada profesional dan netral, menjelaskan istilah yang tidak dikenal saat pertama kali digunakan, lebih memilih kalimat langsung daripada bahasa pemasaran, membedakan fakta yang terkonfirmasi dari asumsi, dan hanya menggunakan judul serta blok kode ketika hal tersebut meningkatkan navigasi.

Panduan prompting Anthropic saat ini secara eksplisit merekomendasikan instruksi yang jelas dan langsung, konteks mengenai mengapa suatu perilaku penting, contoh untuk nada dan struktur, serta tag XML ketika prompt mencampurkan berbagai jenis informasi. Panduan tersebut juga menyatakan bahwa memberikan peran kepada Claude dalam system prompt membantu memfokuskan perilaku dan nada. Lihat praktik terbaik prompting Anthropic.

Haruskah aturan nada berada di system prompt atau user prompt?

Letakkan aturan yang tahan lama di system prompt dan instruksi spesifik tugas di user prompt. System prompt adalah tempat yang tepat untuk aturan seperti “tulis untuk pengembang perangkat lunak,” “hindari klaim pemasaran,” “nyatakan ketidakpastian alih-alih menebak,” dan “gunakan prosa teknis yang ringkas.” Pesan pengguna harus mendeskripsikan pekerjaan saat ini: misalnya, “Tulis panduan migrasi dari versi 4 ke versi 5 menggunakan catatan rilis ini.”

Pemisahan ini mengurangi pengulangan dan membuat pipeline dokumentasi Anda lebih mudah diuji. Hal ini juga mencegah satu permintaan tugas mendefinisikan ulang seluruh suara editorial Anda.

Pola system-prompt sederhana

<role>
Anda adalah penulis dokumentasi teknis.
</role>

<audience>
Tulis untuk pengembang perangkat lunak dan administrator sistem.
Asumsikan literasi teknis umum, tetapi jelaskan istilah spesifik produk saat pertama kali digunakan.
</audience>

<tone>
Gunakan nada profesional, netral, dan langsung.
Lebih suka bahasa konkret daripada hype atau klaim promosi.
Hindari slang, pengisi, emoji, dan kepastian yang berlebihan.
Jaga kalimat tetap cukup pendek dan paragraf tetap fokus.
</tone>

<accuracy>
Jangan mengarang perintah, fitur, versi, benchmark, atau perilaku.
Bedakan fakta terverifikasi dari asumsi atau rekomendasi.
Jika informasi yang diperlukan hilang, nyatakan apa yang tidak diketahui.
</accuracy>

<format>
Gunakan judul deskriptif.
Gunakan daftar hanya untuk langkah atau pemeriksaan yang benar-benar diskret.
Gunakan blok kode untuk perintah dan kode.
Jangan tambahkan kesimpulan yang hanya mengulang artikel.
</format>

Ini berhasil karena setiap bagian memiliki satu tugas. Anthropic secara khusus merekomendasikan tag XML yang konsisten dan deskriptif untuk prompt kompleks agar model dapat membedakan instruksi, konteks, contoh, dan input dengan lebih andal.

Seberapa spesifik aturan nada harus dibuat?

Cukup spesifik sehingga penulis lain dapat mengikutinya tanpa bertanya apa maksud Anda. “Jadilah profesional” lemah karena dokumentasi API profesional, catatan arsitektur eksekutif, dan instruksi pengaturan pengguna akhir dapat terdengar berbeda.

Aturan yang lebih kuat mendeskripsikan perilaku yang dapat diamati:

Instruksi positif biasanya lebih mudah dioperasionalkan daripada aturan yang hanya berisi larangan. Alih-alih hanya mengatakan “jangan terdengar promosi,” tambahkan alternatif yang diinginkan: “Jelaskan manfaat dalam istilah konkret yang terkait dengan hasil pengguna.”

Bagaimana cara mencegah aturan nada merugikan akurasi teknis?

Jangan biarkan gaya mengesampingkan bukti. Kesalahan umum adalah meminta “penulisan yang percaya diri dan otoritatif” tanpa juga mendefinisikan apa yang harus dilakukan model ketika materi sumber tidak lengkap. Hal itu dapat mendorong ketidakpastian yang dipoles alih-alih dokumentasi yang berguna.

Tambahkan batasan akurasi seperti:

Ketika sumber dokumentasi tidak menetapkan sebuah fakta:
- Jangan menyimpulkan kemampuan produk dari penamaan atau tampilan UI.
- Nyatakan bahwa perilaku tersebut tidak dapat diverifikasi.
- Minta sumber yang hilang ketika fakta tersebut diperlukan untuk menyelesaikan tugas.
- Jangan mengubah asumsi menjadi instruksi definitif.

Untuk dokumentasi teknis, aturan ini sering kali lebih berharga daripada instruksi generik untuk “menghindari halusinasi,” karena aturan ini mendefinisikan perilaku yang diharapkan ketika bukti hilang.

Haruskah Anda menentukan verboseitas dalam system prompt?

Ya, jika panjang dan kepadatan dokumen penting. Panduan prompting Anthropic saat ini mencatat bahwa model Claude terbaru berbeda dalam gaya komunikasi dan verboseitas default. Dokumentasi secara khusus menyarankan untuk prompting secara eksplisit untuk ringkas ketika diperlukan, alih-alih mengasumsikan bahwa usaha atau pengaturan model lain akan mengontrol panjang jawaban yang terlihat secara konsisten.

Batasan dokumentasi praktis dapat mendefinisikan kepadatan alih-alih jumlah kata tetap:

Mulai dengan informasi yang diperlukan untuk bertindak.
Gunakan penjelasan yang cukup untuk membuat instruksi aman dan tidak ambigu.
Jangan mengulang rekomendasi yang sama di pendahuluan, isi, dan kesimpulan.
Untuk perbaikan sederhana, lebih suka bagian yang pendek.
Untuk topik arsitektur atau migrasi, jelaskan trade-off dan prasyarat dengan lebih mendalam.

Ini lebih mudah diskalakan daripada instruksi “selalu tulis 1.000 kata” yang menyeluruh.

Berapa banyak contoh yang harus disertakan?

Gunakan contoh ketika aturan prosa masih menyisakan ruang untuk interpretasi. Anthropic menyebut contoh sebagai salah satu cara paling andal untuk mengarahkan format, nada, dan struktur, dan panduan saat ini merekomendasikan penggunaan sekitar tiga hingga lima contoh yang relevan dan beragam ketika Anda mengandalkan prompting few-shot.

Untuk dokumentasi, contoh harus mencakup kasus yang berbeda alih-alih mengulang satu sampel suara. Set yang berguna mungkin mencakup jawaban pemecahan masalah singkat, paragraf referensi API, peringatan tentang kehilangan data, catatan yang bergantung pada versi, dan contoh di mana model harus menyatakan bahwa sesuatu tidak terverifikasi.

Jangan membuat contoh terlalu panjang sehingga menjadi prompt itu sendiri. Tujuannya adalah untuk menunjukkan pola, bukan untuk menyediakan template tersembunyi yang disalin secara mekanis oleh setiap artikel.

Batasan nada apa yang berguna untuk jenis dokumentasi umum?

Apa yang tidak boleh dikodekan sebagai “nada”?

Jangan kubur logika bisnis, kebijakan keamanan, atau batasan faktual di dalam bagian gaya yang samar. “Jangan pernah mengungkapkan kredensial,” “hanya gunakan informasi dari sumber yang disetujui,” dan “jangan eksekusi perintah” adalah aturan perilaku atau keamanan, bukan preferensi nada. Berikan mereka bagian terpisah agar tetap terlihat dan dapat diuji.

Hal yang sama berlaku untuk skema output. Jika sebuah aplikasi membutuhkan JSON yang valid, kunci yang tepat, atau field yang dapat dibaca mesin, tentukan itu sebagai kontrak output alih-alih mendeskripsikannya sebagai preferensi gaya.

Bagaimana cara menguji system prompt dokumentasi?

Jangan menilainya dari satu contoh yang berhasil. Bangun set evaluasi kecil yang mencakup tugas normal dan kasus tepi. Paket uji yang berguna mungkin berisi:

• Permintaan sederhana “bagaimana cara menginstal ini?”.
• Panduan migrasi dengan perubahan yang merusak.
• Dokumen sumber yang mengandung bahasa pemasaran berat yang tidak boleh bocor ke nada akhir.
• Prompt dengan informasi versi yang tidak lengkap.
• Pertanyaan teknis yang jawabannya tidak ditetapkan oleh sumber yang disediakan.
• Permintaan untuk penjelasan panjang di mana ringkas masih harus dipertahankan.
• Instruksi pengguna yang meminta gaya yang bertentangan dengan kebijakan dokumentasi organisasi Anda.

Tinjau output terhadap kriteria eksplisit: audiens yang benar, nada netral, tidak ada klaim yang tidak didukung, detail yang tepat, terminologi yang konsisten, ketidakpastian yang jelas, dan struktur yang dapat digunakan. Panduan prompt Anthropic juga merekomendasikan untuk mendefinisikan kriteria keberhasilan yang jelas dan memverifikasi hasil alih-alih mengandalkan intuisi saja.

Bagaimana cara mencegah system prompt menjadi membengkak?

Jaga aturan pada tingkat kebijakan editorial yang stabil. Jika satu kalimat menangani beberapa kasus, jangan menggantinya dengan dua belas larangan sempit. Panduan Anthropic saat ini untuk model terbaru juga memperingatkan terhadap over-prompting: kepatuhan instruksi yang lebih kuat dapat membuat kata-kata warisan agresif seperti aturan “CRITICAL” atau “MUST” yang berulang memicu perilaku berlebih yang akan sudah diikuti oleh model baru dengan frasa normal.

Aturan pemeliharaan yang baik adalah menambahkan instruksi system-prompt hanya setelah Anda dapat menyebutkan kegagalan berulang yang dicegahnya. Jika sebuah aturan hanya ada untuk satu artikel, letakkan di user prompt untuk artikel tersebut.

System prompt dokumentasi teknis yang dapat digunakan kembali

<role>
Anda adalah penulis dokumentasi teknis senior.
</role>

<audience>
Tulis untuk audiens yang ditentukan dalam permintaan pengguna.
Jika tidak ada audiens yang diberikan, asumsikan praktisi yang melek teknologi.
Jelaskan terminologi spesifik produk yang tidak umum saat pertama kali digunakan.
</audience>

<tone>
Gunakan bahasa Inggris Amerika yang jelas, profesional, dan netral.
Mulai dengan informasi yang diperlukan untuk bertindak.
Hindari hype, pengisi kasual, lelucon, emoji, kepastian yang berlebihan,
dan frasa yang terdengar seperti salinan pemasaran.
Gunakan pernyataan langsung ketika fakta terverifikasi.
</tone>

<accuracy>
Jangan pernah mengarang perilaku produk, perintah, label UI, versi,
benchmark, batasan, atau hasil tes.
Pisahkan fakta terverifikasi, perilaku kondisional, rekomendasi,
dan hal yang tidak diketahui.
Jika bukti tidak cukup, nyatakan secara eksplisit.
</accuracy>

<structure>
Gunakan judul deskriptif yang membantu navigasi.
Lebih suka paragraf pendek dan fokus.
Gunakan langkah bernomor hanya untuk prosedur berurutan.
Gunakan bullet untuk pemeriksaan atau opsi yang benar-benar diskret.
Gunakan blok kode untuk perintah dan kode.
Hindari ringkasan yang repetitif.
</structure>

<examples>
Berikan 3–5 contoh yang relevan dengan tugas dalam prompt produksi
ketika nada atau format tetap ambigu.
</examples>

<quality_check>
Sebelum memfinalisasi, verifikasi bahwa respons sesuai dengan audiens
yang diminta, menggunakan terminologi yang konsisten, menghindari klaim
tanpa dukungan, dan mengikuti format output yang diminta.
</quality_check>

Tujuannya bukan membuat setiap dokumen terdengar identik. Tujuannya adalah membuat batasan stabil: akurasi tidak menjadi antusiasme, ketidakpastian tidak menjadi tebakan, kedalaman teknis tidak menjadi jargon yang tidak perlu, dan ringkas tidak menghilangkan prasyarat atau informasi keselamatan.

System prompt Claude yang dirancang dengan baik bekerja paling baik sebagai lapisan kebijakan editorial. Pertahankan suara permanen dan batasan kualitas di sana, pertahankan persyaratan spesifik artikel di user prompt, dan gunakan set evaluasi kecil untuk memverifikasi bahwa kedua lapisan terus menghasilkan dokumentasi yang dapat dipercaya oleh pembaca Anda.