Merangkai prompt kompleks untuk performa yang lebih kuat

While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.

Ketika bekerja dengan tugas-tugas kompleks, Claude terkadang bisa kehilangan fokus jika Anda mencoba menangani semuanya dalam satu prompt. Prompt berantai pemikiran (Chain of thought/CoT) memang bagus, tapi bagaimana jika tugas Anda memiliki beberapa langkah berbeda yang masing-masing membutuhkan pemikiran mendalam?

Inilah saatnya perangkaian prompt: memecah tugas kompleks menjadi sub-tugas yang lebih kecil dan dapat dikelola.

Mengapa merangkai prompt?

Akurasi: Setiap sub-tugas mendapat perhatian penuh Claude, mengurangi kesalahan.
Kejelasan: Sub-tugas yang lebih sederhana berarti instruksi dan output yang lebih jelas.
Keterlacakan: Mudah mengidentifikasi dan memperbaiki masalah dalam rangkaian prompt Anda.

Kapan merangkai prompt

Gunakan perangkaian prompt untuk tugas multi-langkah seperti sintesis penelitian, analisis dokumen, atau pembuatan konten iteratif. Ketika sebuah tugas melibatkan beberapa transformasi, kutipan, atau instruksi, perangkaian mencegah Claude melewatkan atau salah menangani langkah-langkah.

Ingat: Setiap mata rantai mendapat perhatian penuh Claude!

Tips debugging: Jika Claude melewatkan langkah atau berkinerja buruk, isolasi langkah tersebut dalam promptnya sendiri. Ini memungkinkan Anda menyempurnakan langkah-langkah bermasalah tanpa mengulang seluruh tugas.

Cara merangkai prompt

Identifikasi sub-tugas: Pecah tugas Anda menjadi langkah-langkah berbeda dan berurutan.
Struktur dengan XML untuk serah terima yang jelas: Gunakan tag XML untuk meneruskan output antar prompt.
Memiliki tujuan tugas tunggal: Setiap sub-tugas harus memiliki satu tujuan yang jelas.
Iterasi: Sempurnakan sub-tugas berdasarkan kinerja Claude.

Contoh alur kerja berantai:

Analisis multi-langkah: Lihat contoh hukum dan bisnis di bawah.
Pipeline pembuatan konten: Riset → Outline → Draft → Edit → Format.
Pemrosesan data: Ekstrak → Transform → Analisis → Visualisasi.
Pengambilan keputusan: Kumpulkan info → Daftar opsi → Analisis masing-masing → Rekomendasikan.
Loop verifikasi: Buat konten → Tinjau → Sempurnakan → Tinjau ulang.

Tips optimisasi: Untuk tugas dengan sub-tugas independen (seperti menganalisis beberapa dokumen), buat prompt terpisah dan jalankan secara paralel untuk kecepatan.

Lanjutan: Rantai koreksi diri

Anda dapat merangkai prompt agar Claude meninjau pekerjaannya sendiri! Ini menangkap kesalahan dan menyempurnakan output, terutama untuk tugas-tugas berisiko tinggi.

Contoh: Ringkasan penelitian yang mengoreksi diri

Prompt 1

Role	Content
User	Ringkas makalah penelitian medis ini. <paper>{{RESEARCH_PAPER}}</paper> Fokus pada metodologi, temuan, dan implikasi klinis.
Assistant {{SUMMARY}}	Metodologi: RCT ganda-buta dengan 500 pasien diabetes Tipe 2. Kelompok A (n=250) menerima agonis ganda GLP-1/GIP baru; Kelompok B (n=250) menerima agonis GLP-1 standar. Uji coba 24 minggu, titik akhir primer: pengurangan HbA1c. Temuan: - Kelompok A: pengurangan HbA1c rata-rata 1,8% - Kelompok B: pengurangan HbA1c rata-rata 1,1% - 68% Kelompok A vs. 52% Kelompok B mencapai HbA1c <7% - Kelompok A: penurunan berat badan rata-rata 5,2kg - Kelompok B: penurunan berat badan rata-rata 3,1kg Keamanan: Profil efek samping serupa, tidak ada kejadian serius yang dikaitkan dengan pengobatan. Implikasi Klinis: Agonis ganda menunjukkan kontrol glikemik dan penurunan berat badan yang lebih unggul dibandingkan terapi standar. Bisa menjadi terobosan, terutama untuk penderita diabetes obesitas.

Role

Content

User

Ringkas makalah penelitian medis ini.

<paper>{{RESEARCH_PAPER}}</paper>

Fokus pada metodologi, temuan, dan implikasi klinis.

Assistant
{{SUMMARY}}

Metodologi: RCT ganda-buta dengan 500 pasien diabetes Tipe 2. Kelompok A (n=250) menerima agonis ganda GLP-1/GIP baru; Kelompok B (n=250) menerima agonis GLP-1 standar. Uji coba 24 minggu, titik akhir primer: pengurangan HbA1c.

Temuan:
- Kelompok A: pengurangan HbA1c rata-rata 1,8%
- Kelompok B: pengurangan HbA1c rata-rata 1,1%
- 68% Kelompok A vs. 52% Kelompok B mencapai HbA1c <7%
- Kelompok A: penurunan berat badan rata-rata 5,2kg
- Kelompok B: penurunan berat badan rata-rata 3,1kg

Keamanan: Profil efek samping serupa, tidak ada kejadian serius yang dikaitkan dengan pengobatan.

Implikasi Klinis: Agonis ganda menunjukkan kontrol glikemik dan penurunan berat badan yang lebih unggul dibandingkan terapi standar. Bisa menjadi terobosan, terutama untuk penderita diabetes obesitas.

Prompt 2

Role	Content
User	Tugas Anda adalah memberikan umpan balik pada ringkasan makalah penelitian. Berikut adalah ringkasan makalah penelitian medis: <summary> {{SUMMARY}} </summary> Berikut adalah makalah penelitiannya: <paper> {{RESEARCH_PAPER}} </paper> Tinjau ringkasan ini untuk akurasi, kejelasan, dan kelengkapan pada skala nilai A-F.
Assistant {{FEEDBACK}}	1. Akurasi: A - Melaporkan statistik kunci dengan benar: pengurangan HbA1c, penurunan berat badan. - Mencatat profil keamanan dan tidak adanya efek samping serius dengan akurat. - Pernyataan “terobosan” dibenarkan oleh hasil yang secara signifikan lebih baik. 2. Kejelasan: A- - Ringkas dan terstruktur dengan baik dengan bagian yang jelas. - Penggunaan bahasa komparatif yang baik (mis., “naik 3% dari Q1”) untuk konteks. - Masalah kecil: Singkatan seperti “RCT,” “GLP-1,” dan “GIP” tidak didefinisikan. Pertimbangkan untuk menuliskan lengkap pada penggunaan pertama. 3. Kelengkapan: B+ - Mencakup semua area yang diminta: metodologi, temuan, implikasi klinis. - Kurang: Karakteristik dasar kelompok (apakah mereka cocok dengan baik?). - Kurang: Titik akhir sekunder (mis., tekanan darah, lipid). - Pertimbangkan: Implikasi jangka panjang atau kebutuhan penelitian lebih lanjut. Secara keseluruhan, ringkasan ini akurat dan jelas, memberikan wawasan kunci untuk pemahaman cepat tentang studi. Untuk meningkatkan ke A+, definisikan singkatan, sebutkan statistik dasar kelompok, catat hasil sekunder, dan singgung singkat tentang kebutuhan studi jangka panjang.

Role

Content

User

Tugas Anda adalah memberikan umpan balik pada ringkasan makalah penelitian. Berikut adalah ringkasan makalah penelitian medis:
<summary>
{{SUMMARY}}
</summary>

Berikut adalah makalah penelitiannya:
<paper>
{{RESEARCH_PAPER}}
</paper>

Tinjau ringkasan ini untuk akurasi, kejelasan, dan kelengkapan pada skala nilai A-F.

Assistant
{{FEEDBACK}}

1. Akurasi: A
- Melaporkan statistik kunci dengan benar: pengurangan HbA1c, penurunan berat badan.
- Mencatat profil keamanan dan tidak adanya efek samping serius dengan akurat.
- Pernyataan “terobosan” dibenarkan oleh hasil yang secara signifikan lebih baik.

2. Kejelasan: A-
- Ringkas dan terstruktur dengan baik dengan bagian yang jelas.
- Penggunaan bahasa komparatif yang baik (mis., “naik 3% dari Q1”) untuk konteks.
- Masalah kecil: Singkatan seperti “RCT,” “GLP-1,” dan “GIP” tidak didefinisikan. Pertimbangkan untuk menuliskan lengkap pada penggunaan pertama.

3. Kelengkapan: B+
- Mencakup semua area yang diminta: metodologi, temuan, implikasi klinis.
- Kurang: Karakteristik dasar kelompok (apakah mereka cocok dengan baik?).
- Kurang: Titik akhir sekunder (mis., tekanan darah, lipid).
- Pertimbangkan: Implikasi jangka panjang atau kebutuhan penelitian lebih lanjut.

Secara keseluruhan, ringkasan ini akurat dan jelas, memberikan wawasan kunci untuk pemahaman cepat tentang studi. Untuk meningkatkan ke A+, definisikan singkatan, sebutkan statistik dasar kelompok, catat hasil sekunder, dan singgung singkat tentang kebutuhan studi jangka panjang.

Prompt 3

Role	Content
User	Tugas Anda adalah memperbaiki ringkasan makalah berdasarkan umpan balik. Berikut adalah draft pertama makalah penelitian medis: <summary> {{SUMMARY}} </summary> Berikut adalah makalah penelitiannya: <paper> {{RESEARCH_PAPER}} </paper> Berikut adalah umpan baliknya: <feedback> {{FEEDBACK}} </feedback> Perbarui ringkasan berdasarkan umpan balik tersebut.
Assistant	Metodologi: Uji coba terkontrol acak (RCT) ganda-buta dengan 500 pasien diabetes Tipe 2. Kelompok A (n=250) menerima agonis ganda peptida-1 seperti glukagon/polipeptida insulinotropik bergantung glukosa (GLP-1/GIP) baru; Kelompok B (n=250) menerima agonis GLP-1 standar. Uji coba 24 minggu dengan titik akhir primer pengurangan HbA1c. Kelompok cocok dengan baik untuk usia, BMI, dan HbA1c dasar. Temuan: - Kelompok A: pengurangan HbA1c rata-rata 1,8% - Kelompok B: pengurangan HbA1c rata-rata 1,1% - 68% Kelompok A vs. 52% Kelompok B mencapai HbA1c <7% - Kelompok A: penurunan berat badan rata-rata 5,2kg - Kelompok B: penurunan berat badan rata-rata 3,1kg Titik akhir sekunder menunjukkan perbaikan tekanan darah dan profil lipid untuk kedua kelompok, dengan Kelompok A menunjukkan hasil yang sedikit lebih baik. Keamanan: Profil efek samping serupa, tanpa kejadian serius yang dikaitkan dengan salah satu pengobatan. Implikasi Klinis: Agonis ganda GLP-1/GIP menunjukkan kontrol glikemik dan penurunan berat badan yang lebih unggul dibandingkan terapi GLP-1 standar. Hasil ini menunjukkan bahwa ini bisa menjadi kemajuan signifikan, terutama untuk penderita diabetes obesitas. Namun, studi jangka panjang diperlukan untuk mengkonfirmasi efektivitas dan keamanan berkelanjutan, serta untuk menyelidiki potensi manfaat pada hasil kardiovaskular.

Role

Content

User

Tugas Anda adalah memperbaiki ringkasan makalah berdasarkan umpan balik. Berikut adalah draft pertama makalah penelitian medis:
<summary>
{{SUMMARY}}
</summary>

Berikut adalah makalah penelitiannya:
<paper>
{{RESEARCH_PAPER}}
</paper>

Berikut adalah umpan baliknya:
<feedback>
{{FEEDBACK}}
</feedback>

Perbarui ringkasan berdasarkan umpan balik tersebut.

Assistant

Metodologi: Uji coba terkontrol acak (RCT) ganda-buta dengan 500 pasien diabetes Tipe 2. Kelompok A (n=250) menerima agonis ganda peptida-1 seperti glukagon/polipeptida insulinotropik bergantung glukosa (GLP-1/GIP) baru; Kelompok B (n=250) menerima agonis GLP-1 standar. Uji coba 24 minggu dengan titik akhir primer pengurangan HbA1c. Kelompok cocok dengan baik untuk usia, BMI, dan HbA1c dasar.

Temuan:
- Kelompok A: pengurangan HbA1c rata-rata 1,8%
- Kelompok B: pengurangan HbA1c rata-rata 1,1%
- 68% Kelompok A vs. 52% Kelompok B mencapai HbA1c <7%
- Kelompok A: penurunan berat badan rata-rata 5,2kg
- Kelompok B: penurunan berat badan rata-rata 3,1kg

Titik akhir sekunder menunjukkan perbaikan tekanan darah dan profil lipid untuk kedua kelompok, dengan Kelompok A menunjukkan hasil yang sedikit lebih baik.

Keamanan: Profil efek samping serupa, tanpa kejadian serius yang dikaitkan dengan salah satu pengobatan.

Implikasi Klinis: Agonis ganda GLP-1/GIP menunjukkan kontrol glikemik dan penurunan berat badan yang lebih unggul dibandingkan terapi GLP-1 standar. Hasil ini menunjukkan bahwa ini bisa menjadi kemajuan signifikan, terutama untuk penderita diabetes obesitas. Namun, studi jangka panjang diperlukan untuk mengkonfirmasi efektivitas dan keamanan berkelanjutan, serta untuk menyelidiki potensi manfaat pada hasil kardiovaskular.

Contoh

Contoh: Menganalisis kontrak hukum (tanpa perangkaian)

Perhatikan bahwa Claude melewatkan instruksi untuk memberikan perubahan yang diusulkan dalam draft emailnya.

Role	Content
User	Anda adalah Chief Legal Officer kami. Tinjau kontrak SaaS ini untuk risiko, fokus pada privasi data, SLA, dan batas kewajiban. <contract> {{CONTRACT}} </contract> Kemudian buat draft email ke vendor dengan kekhawatiran dan perubahan yang diusulkan.
Assistant	Setelah meninjau kontrak SaaS, saya telah mengidentifikasi beberapa kekhawatiran: 1. Privasi Data (Bagian 7): - Masalah: Vendor memiliki hak luas untuk menggunakan data klien untuk “peningkatan layanan.” - Risiko: Bisa menyebabkan pembagian data atau monetisasi yang tidak sah. 2. SLA (Bagian 5): - Masalah: Jaminan uptime 99,5% di bawah standar industri. - Risiko: Downtime berlebihan bisa mempengaruhi operasi kami. 3. Kewajiban (Bagian 9): - Masalah: Batas ditetapkan pada 3 bulan biaya. - Risiko: Tidak memadai untuk potensi pelanggaran data atau kegagalan layanan. Draft email: Yth. {{VENDOR}}, Setelah meninjau perjanjian SaaS, kami memiliki kekhawatiran: 1. Privasi Data: Kami membutuhkan data kami hanya digunakan untuk penyediaan layanan langsung, bukan “peningkatan layanan” yang luas. Mohon ubah Bagian 7. 2. SLA: Uptime 99,5% tidak memadai. Kami membutuhkan 99,99% dengan penalti yang jelas didefinisikan. Mohon revisi Bagian 5. 3. Kewajiban: Batas saat ini 3 bulan biaya tidak memadai. Kami mengusulkan batas 12 bulan biaya, tanpa batas untuk pelanggaran data atau kesalahan yang disengaja. Kami menghargai potensi kemitraan kita dan percaya perubahan ini akan mempersiapkan kita untuk sukses. Mohon kirimkan perjanjian yang direvisi. Salam hormat, {{CLO_NAME}}

Role

Content

User

Anda adalah Chief Legal Officer kami. Tinjau kontrak SaaS ini untuk risiko, fokus pada privasi data, SLA, dan batas kewajiban.

<contract>
{{CONTRACT}}
</contract>

Kemudian buat draft email ke vendor dengan kekhawatiran dan perubahan yang diusulkan.

Assistant

Setelah meninjau kontrak SaaS, saya telah mengidentifikasi beberapa kekhawatiran:

1. Privasi Data (Bagian 7):
- Masalah: Vendor memiliki hak luas untuk menggunakan data klien untuk “peningkatan layanan.”
- Risiko: Bisa menyebabkan pembagian data atau monetisasi yang tidak sah.

2. SLA (Bagian 5):
- Masalah: Jaminan uptime 99,5% di bawah standar industri.
- Risiko: Downtime berlebihan bisa mempengaruhi operasi kami.

3. Kewajiban (Bagian 9):
- Masalah: Batas ditetapkan pada 3 bulan biaya.
- Risiko: Tidak memadai untuk potensi pelanggaran data atau kegagalan layanan.

Draft email:

Yth. {{VENDOR}},

Setelah meninjau perjanjian SaaS, kami memiliki kekhawatiran:

1. Privasi Data: Kami membutuhkan data kami hanya digunakan untuk penyediaan layanan langsung, bukan “peningkatan layanan” yang luas. Mohon ubah Bagian 7.

2. SLA: Uptime 99,5% tidak memadai. Kami membutuhkan 99,99% dengan penalti yang jelas didefinisikan. Mohon revisi Bagian 5.

3. Kewajiban: Batas saat ini 3 bulan biaya tidak memadai. Kami mengusulkan batas 12 bulan biaya, tanpa batas untuk pelanggaran data atau kesalahan yang disengaja.

Kami menghargai potensi kemitraan kita dan percaya perubahan ini akan mempersiapkan kita untuk sukses. Mohon kirimkan perjanjian yang direvisi.

Salam hormat,
{{CLO_NAME}}

Contoh: Menganalisis kontrak hukum (dengan perangkaian)

Prompt 1

Role	Content
User	Anda adalah Chief Legal Officer kami. Tinjau kontrak SaaS ini untuk risiko, fokus pada privasi data, SLA, dan batas kewajiban. <contract> {{CONTRACT}} </contract> Keluarkan temuan Anda dalam tag <risks>.
Assistant {{CONCERNS}}	1. Privasi Data (Bagian 7): - Masalah: Vendor memiliki hak luas untuk menggunakan data klien untuk “peningkatan layanan.” - Risiko: Bisa menyebabkan pembagian data atau monetisasi data klien yang tidak sah. - Dampak: Potensi pelanggaran kepercayaan klien, denda regulasi (GDPR, CCPA). 2. SLA (Bagian 5): - Masalah: Jaminan uptime 99,5% di bawah standar industri (biasanya 99,99%). - Risiko: Hingga 43,8 jam downtime per tahun vs. 52,6 menit pada 99,99%. - Dampak: Gangguan operasional, kehilangan pendapatan, ketidakpuasan klien. 3. Kewajiban (Bagian 9): - Masalah: Batas kewajiban ditetapkan pada 3 bulan biaya. - Risiko: Tidak memadai untuk potensi pelanggaran data, pencurian IP, atau kegagalan layanan berkepanjangan. - Dampak: Kompensasi tidak mencukupi untuk kerusakan yang bisa jauh melebihi batas, seperti gugatan class-action atau denda regulasi.

Role

Content

User

Anda adalah Chief Legal Officer kami. Tinjau kontrak SaaS ini untuk risiko, fokus pada privasi data, SLA, dan batas kewajiban.

<contract>
{{CONTRACT}}
</contract>

Keluarkan temuan Anda dalam tag <risks>.

Assistant
{{CONCERNS}}

1. Privasi Data (Bagian 7):
- Masalah: Vendor memiliki hak luas untuk menggunakan data klien untuk “peningkatan layanan.”
- Risiko: Bisa menyebabkan pembagian data atau monetisasi data klien yang tidak sah.
- Dampak: Potensi pelanggaran kepercayaan klien, denda regulasi (GDPR, CCPA).

2. SLA (Bagian 5):
- Masalah: Jaminan uptime 99,5% di bawah standar industri (biasanya 99,99%).
- Risiko: Hingga 43,8 jam downtime per tahun vs. 52,6 menit pada 99,99%.
- Dampak: Gangguan operasional, kehilangan pendapatan, ketidakpuasan klien.

3. Kewajiban (Bagian 9):
- Masalah: Batas kewajiban ditetapkan pada 3 bulan biaya.
- Risiko: Tidak memadai untuk potensi pelanggaran data, pencurian IP, atau kegagalan layanan berkepanjangan.
- Dampak: Kompensasi tidak mencukupi untuk kerusakan yang bisa jauh melebihi batas, seperti gugatan class-action atau denda regulasi.

Prompt 2

Role	Content
User	Buat draft email ke vendor produk SaaS yang menguraikan kekhawatiran berikut dan mengusulkan perubahan. Berikut adalah kekhawatirannya: <concerns> {{CONCERNS}} </concerns>
Assistant {{EMAIL}}	Yth. {{VENDOR}}, Setelah peninjauan menyeluruh terhadap perjanjian SaaS yang diusulkan, tim hukum kami telah mengidentifikasi beberapa kekhawatiran prioritas tinggi yang harus ditangani sebelum kami dapat melanjutkan: 1. Privasi Data (Bagian 7): - Saat ini: Hak luas untuk menggunakan data klien untuk “peningkatan layanan.” - Kekhawatiran: Potensi pembagian data atau monetisasi yang tidak sah. - Perubahan yang Diusulkan: Batasi penggunaan data untuk penyediaan layanan langsung. Setiap penggunaan untuk peningkatan, analitik, atau pemasaran harus opt-in, dapat dicabut, dan dianonimkan. 2. SLA (Bagian 5): - Saat ini: Jaminan uptime 99,5%. - Kekhawatiran: Hingga 43,8 jam downtime per tahun, berisiko gangguan operasional. - Perubahan yang Diusulkan: 99,99% uptime dengan kredit layanan bertingkat. Mis., kredit 10% untuk <99,99%, 25% untuk <99,9%, 50% untuk <99,5%. 3. Kewajiban (Bagian 9): - Saat ini: Batas pada 3 bulan biaya. - Kekhawatiran: Sangat tidak memadai untuk pelanggaran data, pencurian IP, atau outage berkepanjangan. - Perubahan yang Diusulkan: 12 bulan biaya untuk kewajiban umum. Tanpa batas untuk pelanggaran data, kesalahan yang disengaja, pelanggaran IP. Perubahan ini tidak dapat dinegosiasikan untuk kami. Mereka selaras dengan standar industri dan komitmen kami terhadap keamanan data, keunggulan operasional, dan tanggung jawab fidusia. Kami menghargai potensi kemitraan kita, dan menangani hal-hal ini akan membangun fondasi yang kuat. Mohon tim hukum Anda meninjau dan memasukkan perubahan ini. Kami senang untuk berdiskusi lebih lanjut untuk memastikan pemahaman dan kesepakatan bersama. Salam hormat, {{CLO_NAME}}

Role

Content

User

Buat draft email ke vendor produk SaaS yang menguraikan kekhawatiran berikut dan mengusulkan perubahan. Berikut adalah kekhawatirannya:
<concerns>
{{CONCERNS}}
</concerns>

Assistant
{{EMAIL}}

Yth. {{VENDOR}},

Setelah peninjauan menyeluruh terhadap perjanjian SaaS yang diusulkan, tim hukum kami telah mengidentifikasi beberapa kekhawatiran prioritas tinggi yang harus ditangani sebelum kami dapat melanjutkan:

1. Privasi Data (Bagian 7):
- Saat ini: Hak luas untuk menggunakan data klien untuk “peningkatan layanan.”
- Kekhawatiran: Potensi pembagian data atau monetisasi yang tidak sah.
- Perubahan yang Diusulkan: Batasi penggunaan data untuk penyediaan layanan langsung. Setiap penggunaan untuk peningkatan, analitik, atau pemasaran harus opt-in, dapat dicabut, dan dianonimkan.

2. SLA (Bagian 5):
- Saat ini: Jaminan uptime 99,5%.
- Kekhawatiran: Hingga 43,8 jam downtime per tahun, berisiko gangguan operasional.
- Perubahan yang Diusulkan: 99,99% uptime dengan kredit layanan bertingkat. Mis., kredit 10% untuk <99,99%, 25% untuk <99,9%, 50% untuk <99,5%.

3. Kewajiban (Bagian 9):
- Saat ini: Batas pada 3 bulan biaya.
- Kekhawatiran: Sangat tidak memadai untuk pelanggaran data, pencurian IP, atau outage berkepanjangan.
- Perubahan yang Diusulkan: 12 bulan biaya untuk kewajiban umum. Tanpa batas untuk pelanggaran data, kesalahan yang disengaja, pelanggaran IP.

Perubahan ini tidak dapat dinegosiasikan untuk kami. Mereka selaras dengan standar industri dan komitmen kami terhadap keamanan data, keunggulan operasional, dan tanggung jawab fidusia. Kami menghargai potensi kemitraan kita, dan menangani hal-hal ini akan membangun fondasi yang kuat.

Mohon tim hukum Anda meninjau dan memasukkan perubahan ini. Kami senang untuk berdiskusi lebih lanjut untuk memastikan pemahaman dan kesepakatan bersama.

Salam hormat,
{{CLO_NAME}}

Prompt 3

Role	Content
User	Tugas Anda adalah meninjau email dan memberikan umpan balik. Berikut adalah emailnya: <email> {{EMAIL}} </email> Berikan umpan balik tentang nada, kejelasan, dan profesionalisme.
Assistant	1. Nada: - Profesional dan tegas tanpa bersifat konfrontatif. - Penggunaan “tidak dapat dinegosiasikan” kuat tapi dibenarkan mengingat kekritisan masalah. - Bahasa kolaboratif (“kami menghargai,” “senang untuk berdiskusi”) menyeimbangkan ketegasan, mempertahankan nada konstruktif. 2. Kejelasan: - Penataan sangat baik: Keadaan saat ini, kekhawatiran, dan perubahan yang diusulkan untuk setiap masalah. - Istilah teknis (mis., “EBITDA,” “kredit layanan bertingkat”) sesuai untuk konteks B2B SaaS. - Item tindakan jelas: tim hukum vendor untuk meninjau dan memasukkan perubahan. 3. Profesionalisme: - Fokus pada manfaat bersama dan standar industri, bukan hanya tuntutan kami. - Menyebutkan tanggung jawab yang lebih luas (keamanan data, keunggulan operasional, tugas fidusia), meningkatkan diskusi. - Menawarkan diskusi lebih lanjut, menunjukkan komitmen untuk memahami dan menyelesaikan masalah. Secara keseluruhan, email ini mencapai keseimbangan yang tepat antara ketegasan dan kolaborasi. Ini dengan jelas mengartikulasikan kekhawatiran kami, mengusulkan solusi spesifik, dan mempertahankan nada profesional yang berorientasi kemitraan. Tidak perlu revisi; lanjutkan untuk mengirim.

Role

Content

User

Tugas Anda adalah meninjau email dan memberikan umpan balik. Berikut adalah emailnya:
<email>
{{EMAIL}}
</email>

Berikan umpan balik tentang nada, kejelasan, dan profesionalisme.

Assistant

1. Nada:
- Profesional dan tegas tanpa bersifat konfrontatif.
- Penggunaan “tidak dapat dinegosiasikan” kuat tapi dibenarkan mengingat kekritisan masalah.
- Bahasa kolaboratif (“kami menghargai,” “senang untuk berdiskusi”) menyeimbangkan ketegasan, mempertahankan nada konstruktif.

2. Kejelasan:
- Penataan sangat baik: Keadaan saat ini, kekhawatiran, dan perubahan yang diusulkan untuk setiap masalah.
- Istilah teknis (mis., “EBITDA,” “kredit layanan bertingkat”) sesuai untuk konteks B2B SaaS.
- Item tindakan jelas: tim hukum vendor untuk meninjau dan memasukkan perubahan.

3. Profesionalisme:
- Fokus pada manfaat bersama dan standar industri, bukan hanya tuntutan kami.
- Menyebutkan tanggung jawab yang lebih luas (keamanan data, keunggulan operasional, tugas fidusia), meningkatkan diskusi.
- Menawarkan diskusi lebih lanjut, menunjukkan komitmen untuk memahami dan menyelesaikan masalah.

Secara keseluruhan, email ini mencapai keseimbangan yang tepat antara ketegasan dan kolaborasi. Ini dengan jelas mengartikulasikan kekhawatiran kami, mengusulkan solusi spesifik, dan mempertahankan nada profesional yang berorientasi kemitraan. Tidak perlu revisi; lanjutkan untuk mengirim.

Contoh: Tinjauan strategi multitenancy

Prompt 1

Role	Content
User	Sebagai arsitek solusi senior, tinjau dan analisis strategi multitenancy ini untuk produk SaaS enterprise baru kami. <strategy> {{STRATEGY}} </strategy> Fokus pada skalabilitas, keamanan, dan efektivitas biaya.
Assistant {{ANALYSIS}}	1. Skalabilitas: + Sharding database berdasarkan tenant mengurangi kontestasi, mendukung pertumbuhan tinggi. + Microservices memungkinkan penskalaan independen komponen. - Server aplikasi bersama bisa menjadi bottleneck di bawah beban ekstrem. - Tidak ada penyebutan auto-scaling atau penyeimbangan beban untuk tier aplikasi. 2. Keamanan: + Isolasi data tenant melalui sharding mengurangi kebocoran data. + JWT dengan masa berlaku singkat dan token penyegaran adalah praktik terbaik industri. - Tidak ada penyebutan enkripsi (saat diam, dalam transit) atau manajemen kunci. - Strategi IAM kurang detail tentang peran, izin, atau RBAC. 3.Efektivitas biaya: + Server aplikasi bersama mengurangi biaya sumber daya idle. + Fungsi serverless untuk tugas yang jarang menoptimalkan biaya. - DB per-tenant bisa meningkatkan biaya pada skala vs. DB multi-tenant yang dioptimalkan. - Tidak ada diskusi tentang instance cadangan atau instance spot untuk penghematan biaya.

Role

Content

User

Sebagai arsitek solusi senior, tinjau dan analisis strategi multitenancy ini untuk produk SaaS enterprise baru kami.

<strategy>
{{STRATEGY}}
</strategy>

Fokus pada skalabilitas, keamanan, dan efektivitas biaya.

Assistant
{{ANALYSIS}}

1. Skalabilitas:
+ Sharding database berdasarkan tenant mengurangi kontestasi, mendukung pertumbuhan tinggi.
+ Microservices memungkinkan penskalaan independen komponen.
- Server aplikasi bersama bisa menjadi bottleneck di bawah beban ekstrem.
- Tidak ada penyebutan auto-scaling atau penyeimbangan beban untuk tier aplikasi.

2. Keamanan:
+ Isolasi data tenant melalui sharding mengurangi kebocoran data.
+ JWT dengan masa berlaku singkat dan token penyegaran adalah praktik terbaik industri.
- Tidak ada penyebutan enkripsi (saat diam, dalam transit) atau manajemen kunci.
- Strategi IAM kurang detail tentang peran, izin, atau RBAC.

3.Efektivitas biaya:
+ Server aplikasi bersama mengurangi biaya sumber daya idle.
+ Fungsi serverless untuk tugas yang jarang menoptimalkan biaya.
- DB per-tenant bisa meningkatkan biaya pada skala vs. DB multi-tenant yang dioptimalkan.
- Tidak ada diskusi tentang instance cadangan atau instance spot untuk penghematan biaya.

Prompt 2

Role	Content
User	Buat dokumen tinjauan strategi untuk kepemimpinan teknis berdasarkan analisis strategi multitenancy ini. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Sertakan ringkasan eksekutif, analisis terperinci, dan rekomendasi.
Assistant {{STRATEGY_DOC}}	# Tinjauan Strategi Multitenancy: Produk SaaS Enterprise ## Ringkasan Eksekutif Strategi yang diusulkan menunjukkan fondasi yang kuat dalam prinsip skalabilitas dan keamanan tetapi memiliki celah dalam detail implementasi. Unggul dalam isolasi data dan penskalaan tingkat komponen tetapi kurang dalam penskalaan tier aplikasi yang kuat dan langkah-langkah keamanan lanjutan. Optimisasi biaya ada tetapi mungkin gagal pada skala tinggi. Dengan peningkatan yang ditargetkan, strategi ini dapat secara efektif mendukung ambisi SaaS enterprise kami. ## Analisis Terperinci ### 1. Skalabilitas: B+ Kekuatan: - Sharding database berdasarkan tenant sangat baik. Meminimalkan latensi query, mendukung pertumbuhan data tinggi, dan memfasilitasi penskalaan per-tenant yang mulus. - Arsitektur microservices memungkinkan penskalaan komponen individual berdasarkan permintaan, penting untuk menangani beban kerja enterprise yang beragam. Kelemahan: - Server aplikasi bersama berisiko menjadi bottleneck. Seiring pertumbuhan jumlah tenant dan lalu lintas, ini bisa menurunkan kinerja di semua tenant. - Tidak adanya auto-scaling dan penyeimbangan beban untuk tier aplikasi adalah kelalaian kritis. Ini penting untuk menangani lonjakan lalu lintas tanpa over-provisioning. ### 2. Keamanan: B- Kekuatan: - Database yang di-shard memberikan isolasi data tenant yang kuat, mengurangi risiko kebocoran data atau akses tidak sah antar tenant. - JWT dengan masa berlaku singkat dan token penyegaran selaras dengan praktik terbaik OWASP, mengurangi jendela kerentanan token. Kelemahan: - Tidak ada penyebutan enkripsi data saat diam atau dalam transit (TLS 1.3). Ini tidak dapat dinegosiasikan untuk data enterprise. - Strategi manajemen kunci tidak ada. Bagaimana kunci enkripsi, rahasia JWT, dan kredensial DB dikelola dan dirotasi? - IAM kurang mendalam. Kita membutuhkan RBAC dengan peran yang terdefinisi dengan baik, kontrol akses berbasis atribut (ABAC) untuk izin yang detail, dan integrasi dengan penyedia identitas enterprise (SAML, OIDC). ### 3. Efektivitas biaya: B Kekuatan: - Server aplikasi bersama mengurangi biaya kapasitas idle, bagus untuk lalu lintas steady-state. - Serverless untuk tugas yang jarang (mis., pelaporan) cerdas; bayar hanya ketika sumber daya ini digunakan. Kelemahan: - Database per-tenant mungkin tidak hemat biaya pada skala dibandingkan dengan database multi-tenant yang dirancang dengan baik dengan partisi data yang kuat. - Tidak ada penyebutan langkah-langkah penghematan biaya seperti instance cadangan untuk beban kerja yang dapat diprediksi atau instance spot untuk tugas yang toleran kesalahan. - Kurangnya auto-scaling tier aplikasi bisa menyebabkan over-provisioning, meningkatkan biaya. ## Rekomendasi 1. Ketahanan Tier Aplikasi: Implementasikan auto-scaling dengan Kubernetes atau layanan cloud-native (EKS, GKE). Deploy di zona ketersediaan dengan CDN untuk aset statis. 2. Penguatan Keamanan: a. Enkripsi data saat diam (AES-256) dan dalam transit (TLS 1.3). b. Gunakan KMS terkelola (AWS KMS, GCP KMS) untuk manajemen kunci. c. Tingkatkan IAM dengan RBAC, ABAC, dan SAML/OIDC untuk SSO enterprise. 3. Optimisasi Biaya: a. Evaluasi DB multi-tenant kolumnar (mis., Snowflake) vs. sharding pada skala. b. Gunakan instance cadangan untuk server aplikasi, instance spot untuk beban kerja non-kritis. c. Implementasikan pemantauan proaktif dan right-sizing untuk menghindari over-provisioning. 4. Proof of Concept (PoC): Sebelum implementasi penuh, lakukan PoC dengan simulasi skala tinggi: a. Uji DB yang di-shard vs. DB multi-tenant yang dioptimalkan untuk biaya dan kinerja. b. Uji beban tier aplikasi dengan simulasi lonjakan lalu lintas tingkat enterprise. c. Lakukan audit keamanan pihak ketiga, fokus pada isolasi data dan kontrol akses. Dengan peningkatan ini, strategi multi-tenancy kami akan berkelas enterprise: dapat diskalakan, aman, dan hemat biaya. PoC akan memvalidasi pilihan desain kami dan menanamkan kepercayaan pada klien enterprise kami.

Role

Content

User

Buat dokumen tinjauan strategi untuk kepemimpinan teknis berdasarkan analisis strategi multitenancy ini.

<strategy>
{{STRATEGY}}
</strategy>

<analysis>
{{ANALYSIS}}
</analysis>

Sertakan ringkasan eksekutif, analisis terperinci, dan rekomendasi.

Assistant
{{STRATEGY_DOC}}

# Tinjauan Strategi Multitenancy: Produk SaaS Enterprise

## Ringkasan Eksekutif
Strategi yang diusulkan menunjukkan fondasi yang kuat dalam prinsip skalabilitas dan keamanan tetapi memiliki celah dalam detail implementasi. Unggul dalam isolasi data dan penskalaan tingkat komponen tetapi kurang dalam penskalaan tier aplikasi yang kuat dan langkah-langkah keamanan lanjutan. Optimisasi biaya ada tetapi mungkin gagal pada skala tinggi. Dengan peningkatan yang ditargetkan, strategi ini dapat secara efektif mendukung ambisi SaaS enterprise kami.

## Analisis Terperinci

### 1. Skalabilitas: B+

Kekuatan:
- Sharding database berdasarkan tenant sangat baik. Meminimalkan latensi query, mendukung pertumbuhan data tinggi, dan memfasilitasi penskalaan per-tenant yang mulus.
- Arsitektur microservices memungkinkan penskalaan komponen individual berdasarkan permintaan, penting untuk menangani beban kerja enterprise yang beragam.

Kelemahan:
- Server aplikasi bersama berisiko menjadi bottleneck. Seiring pertumbuhan jumlah tenant dan lalu lintas, ini bisa menurunkan kinerja di semua tenant.
- Tidak adanya auto-scaling dan penyeimbangan beban untuk tier aplikasi adalah kelalaian kritis. Ini penting untuk menangani lonjakan lalu lintas tanpa over-provisioning.

### 2. Keamanan: B-

Kekuatan:
- Database yang di-shard memberikan isolasi data tenant yang kuat, mengurangi risiko kebocoran data atau akses tidak sah antar tenant.
- JWT dengan masa berlaku singkat dan token penyegaran selaras dengan praktik terbaik OWASP, mengurangi jendela kerentanan token.

Kelemahan:
- Tidak ada penyebutan enkripsi data saat diam atau dalam transit (TLS 1.3). Ini tidak dapat dinegosiasikan untuk data enterprise.
- Strategi manajemen kunci tidak ada. Bagaimana kunci enkripsi, rahasia JWT, dan kredensial DB dikelola dan dirotasi?
- IAM kurang mendalam. Kita membutuhkan RBAC dengan peran yang terdefinisi dengan baik, kontrol akses berbasis atribut (ABAC) untuk izin yang detail, dan integrasi dengan penyedia identitas enterprise (SAML, OIDC).

### 3. Efektivitas biaya: B

Kekuatan:
- Server aplikasi bersama mengurangi biaya kapasitas idle, bagus untuk lalu lintas steady-state.
- Serverless untuk tugas yang jarang (mis., pelaporan) cerdas; bayar hanya ketika sumber daya ini digunakan.

Kelemahan:
- Database per-tenant mungkin tidak hemat biaya pada skala dibandingkan dengan database multi-tenant yang dirancang dengan baik dengan partisi data yang kuat.
- Tidak ada penyebutan langkah-langkah penghematan biaya seperti instance cadangan untuk beban kerja yang dapat diprediksi atau instance spot untuk tugas yang toleran kesalahan.
- Kurangnya auto-scaling tier aplikasi bisa menyebabkan over-provisioning, meningkatkan biaya.

## Rekomendasi

1. Ketahanan Tier Aplikasi: Implementasikan auto-scaling dengan Kubernetes atau layanan cloud-native (EKS, GKE). Deploy di zona ketersediaan dengan CDN untuk aset statis.

2. Penguatan Keamanan:
a. Enkripsi data saat diam (AES-256) dan dalam transit (TLS 1.3).
b. Gunakan KMS terkelola (AWS KMS, GCP KMS) untuk manajemen kunci.
c. Tingkatkan IAM dengan RBAC, ABAC, dan SAML/OIDC untuk SSO enterprise.

3. Optimisasi Biaya:
a. Evaluasi DB multi-tenant kolumnar (mis., Snowflake) vs. sharding pada skala.
b. Gunakan instance cadangan untuk server aplikasi, instance spot untuk beban kerja non-kritis.
c. Implementasikan pemantauan proaktif dan right-sizing untuk menghindari over-provisioning.

4. Proof of Concept (PoC): Sebelum implementasi penuh, lakukan PoC dengan simulasi skala tinggi:
a. Uji DB yang di-shard vs. DB multi-tenant yang dioptimalkan untuk biaya dan kinerja.
b. Uji beban tier aplikasi dengan simulasi lonjakan lalu lintas tingkat enterprise.
c. Lakukan audit keamanan pihak ketiga, fokus pada isolasi data dan kontrol akses.

Dengan peningkatan ini, strategi multi-tenancy kami akan berkelas enterprise: dapat diskalakan, aman, dan hemat biaya. PoC akan memvalidasi pilihan desain kami dan menanamkan kepercayaan pada klien enterprise kami.

Prompt 3

Role	Content
User	Nilai dokumen tinjauan strategi ini untuk kejelasan, dapat ditindaklanjuti, dan keselarasan dengan prioritas enterprise. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc>
Assistant	1. Kejelasan: A + Struktur jelas dengan Ringkasan Eksekutif, Analisis Terperinci, dan Rekomendasi. + Analisis menggunakan sistem penilaian (B+, B-) untuk pemahaman cepat kekuatan/kelemahan. + Istilah teknis (RBAC, ABAC, TLS) dijelaskan atau dikontekstualisasikan, membantu kepemimpinan non-teknis. + Bantuan visual (poin bullet, indentasi) meningkatkan keterbacaan. 2. Dapat Ditindaklanjuti: A- + Rekomendasi spesifik dan teknis (mis., “Implementasikan auto-scaling dengan Kubernetes”). + Rencana PoC dengan tujuan jelas memberikan peta jalan. + Kurang: Timeline, kebutuhan sumber daya, atau penugasan tim untuk setiap rekomendasi. + Pertimbangkan: Tambahkan bagian “Langkah Selanjutnya” dengan tindakan segera, peran, dan timeline tingkat tinggi. 3. Keselarasan Enterprise: A+ + Langsung menangani prioritas enterprise: - Skalabilitas: Membahas penanganan lonjakan lalu lintas tingkat enterprise. - Keamanan: Fokus pada isolasi data, enkripsi, dan IAM enterprise. - Biaya: Strategi selaras dengan FinOps enterprise (instance cadangan, right-sizing). + PoC dengan “simulasi skala tinggi” dan audit keamanan menunjukkan komitmen terhadap kualitas kelas enterprise. + Bahasa beresonansi dengan kekhawatiran enterprise: “risiko yang tidak dapat diterima,” “kelas enterprise,” “menanamkan kepercayaan.” Secara keseluruhan, dokumen unggul dalam kejelasan dan keselarasan enterprise. Dapat ditindaklanjuti kuat tetapi bisa ditingkatkan ke A+ dengan bagian “Langkah Selanjutnya”. Kedalaman teknis, ditambah penjelasan yang jelas, membuat ini sangat efektif untuk kepemimpinan teknis dan non-teknis. Kerja bagus!

Role

Content

User

Nilai dokumen tinjauan strategi ini untuk kejelasan, dapat ditindaklanjuti, dan keselarasan dengan prioritas enterprise.

<priorities>
{{PRIORITIES}}
</priorities>

<strategy_doc>
{{STRATEGY_DOC}}
</strategy_doc>

Assistant

1. Kejelasan: A
+ Struktur jelas dengan Ringkasan Eksekutif, Analisis Terperinci, dan Rekomendasi.
+ Analisis menggunakan sistem penilaian (B+, B-) untuk pemahaman cepat kekuatan/kelemahan.
+ Istilah teknis (RBAC, ABAC, TLS) dijelaskan atau dikontekstualisasikan, membantu kepemimpinan non-teknis.
+ Bantuan visual (poin bullet, indentasi) meningkatkan keterbacaan.

2. Dapat Ditindaklanjuti: A-
+ Rekomendasi spesifik dan teknis (mis., “Implementasikan auto-scaling dengan Kubernetes”).
+ Rencana PoC dengan tujuan jelas memberikan peta jalan.
+ Kurang: Timeline, kebutuhan sumber daya, atau penugasan tim untuk setiap rekomendasi.
+ Pertimbangkan: Tambahkan bagian “Langkah Selanjutnya” dengan tindakan segera, peran, dan timeline tingkat tinggi.

3. Keselarasan Enterprise: A+
+ Langsung menangani prioritas enterprise:
- Skalabilitas: Membahas penanganan lonjakan lalu lintas tingkat enterprise.
- Keamanan: Fokus pada isolasi data, enkripsi, dan IAM enterprise.
- Biaya: Strategi selaras dengan FinOps enterprise (instance cadangan, right-sizing).
+ PoC dengan “simulasi skala tinggi” dan audit keamanan menunjukkan komitmen terhadap kualitas kelas enterprise.
+ Bahasa beresonansi dengan kekhawatiran enterprise: “risiko yang tidak dapat diterima,” “kelas enterprise,” “menanamkan kepercayaan.”

Secara keseluruhan, dokumen unggul dalam kejelasan dan keselarasan enterprise. Dapat ditindaklanjuti kuat tetapi bisa ditingkatkan ke A+ dengan bagian “Langkah Selanjutnya”. Kedalaman teknis, ditambah penjelasan yang jelas, membuat ini sangat efektif untuk kepemimpinan teknis dan non-teknis. Kerja bagus!

Perpustakaan prompt

Dapatkan inspirasi dari pilihan prompt yang dikurasi untuk berbagai tugas dan kasus penggunaan.

Tutorial prompting GitHub

Tutorial yang penuh contoh yang mencakup konsep-konsep prompt engineering yang ditemukan dalam dokumentasi kami.

Tutorial prompting Google Sheets

Versi yang lebih ringan dari tutorial prompt engineering kami melalui spreadsheet interaktif.

Langkah awal

Model & harga

Jelajahi fitur

Pelajari tentang Claude

Uji & evaluasi

Pusat Hukum

Komponen agen

Merangkai prompt kompleks untuk performa yang lebih kuat

Mengapa merangkai prompt?

Kapan merangkai prompt

Cara merangkai prompt

Contoh alur kerja berantai:

Lanjutan: Rantai koreksi diri

Prompt 1

Prompt 2

Prompt 3

Contoh

Prompt 1

Prompt 2

Prompt 3

Prompt 1

Prompt 2

Prompt 3

Perpustakaan prompt

Tutorial prompting GitHub

Tutorial prompting Google Sheets

Langkah awal

Model & harga

Jelajahi fitur

Pelajari tentang Claude

Uji & evaluasi

Pusat Hukum

Komponen agen

​Mengapa merangkai prompt?

​Kapan merangkai prompt

​Cara merangkai prompt

​Contoh alur kerja berantai:

​Lanjutan: Rantai koreksi diri

​Contoh

Perpustakaan prompt

Tutorial prompting GitHub

Tutorial prompting Google Sheets

Mengapa merangkai prompt?

Kapan merangkai prompt

Cara merangkai prompt

Contoh alur kerja berantai:

Lanjutan: Rantai koreksi diri

Contoh