While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.
Mengapa merangkai prompt?
- Akurasi: Setiap subtask mendapat perhatian penuh Claude, mengurangi kesalahan.
- Kejelasan: Subtask yang lebih sederhana berarti instruksi dan output yang lebih jelas.
- Keterlacakan: Mudah menentukan dan memperbaiki masalah dalam rantai prompt Anda.
Kapan merangkai prompt
Gunakan prompt chaining untuk tugas multi-langkah seperti sintesis penelitian, analisis dokumen, atau pembuatan konten iteratif. Ketika tugas melibatkan beberapa transformasi, kutipan, atau instruksi, chaining mencegah Claude dari melewatkan atau salah menangani langkah-langkah. Ingat: Setiap tautan dalam 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 subtask: Pecah tugas Anda menjadi langkah-langkah yang berbeda dan berurutan.
- Struktur dengan XML untuk handoff yang jelas: Gunakan tag XML untuk meneruskan output antar prompt.
- Miliki tujuan tugas tunggal: Setiap subtask harus memiliki objektif tunggal yang jelas.
- Iterasi: Perbaiki subtask berdasarkan kinerja Claude.
Contoh workflow berantai:
- Analisis multi-langkah: Lihat contoh hukum dan bisnis di bawah.
- Pipeline pembuatan konten: Penelitian → Outline → Draft → Edit → Format.
- Pemrosesan data: Ekstrak → Transform → Analisis → Visualisasi.
- Pengambilan keputusan: Kumpulkan info → Daftar opsi → Analisis masing-masing → Rekomendasikan.
- Loop verifikasi: Buat konten → Review → Perbaiki → Review ulang.
Tips optimisasi: Untuk tugas dengan subtask independen (seperti menganalisis beberapa dokumen), buat prompt terpisah dan jalankan secara paralel untuk kecepatan.
Lanjutan: Rantai koreksi diri
Anda dapat merangkai prompt untuk membuat Claude meninjau pekerjaannya sendiri! Ini menangkap kesalahan dan memperbaiki output, terutama untuk tugas berisiko tinggi.Contoh: Ringkasan penelitian yang mengoreksi diri
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 double-blind dengan 500 pasien diabetes tipe 2. Grup A (n=250) menerima agonis dual GLP-1/GIP novel; Grup B (n=250) menerima agonis GLP-1 standar. Uji coba 24 minggu, endpoint primer: pengurangan HbA1c. Temuan: - Grup A: pengurangan HbA1c rata-rata 1,8% - Grup B: pengurangan HbA1c rata-rata 1,1% - 68% Grup A vs. 52% Grup B mencapai HbA1c <7% - Grup A: penurunan berat badan rata-rata 5,2kg - Grup B: penurunan berat badan rata-rata 3,1kg Keamanan: Profil kejadian merugikan serupa, tidak ada kejadian serius yang dikaitkan dengan pengobatan. Implikasi Klinis: Agonis dual menunjukkan kontrol glikemik dan penurunan berat badan yang superior dibandingkan terapi standar. Bisa menjadi game-changer, 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 kejadian merugikan serius dengan akurat. - Pernyataan “game-changer” dibenarkan oleh hasil yang jauh lebih baik. 2. Kejelasan: A- - Ringkas dan terstruktur dengan baik dengan bagian yang jelas. - Penggunaan bahasa komparatif yang baik (misalnya, “naik 3% dari Q1”) untuk konteks. - Masalah kecil: Akronim seperti “RCT,” “GLP-1,” dan “GIP” tidak didefinisikan. Pertimbangkan untuk mengeja penggunaan pertama. 3. Kelengkapan: B+ - Mencakup semua area yang diminta: metodologi, temuan, implikasi klinis. - Kurang: Karakteristik dasar grup (apakah mereka cocok dengan baik?). - Kurang: Endpoint sekunder apa pun (misalnya, tekanan darah, lipid). - Pertimbangkan: Implikasi jangka panjang atau kebutuhan untuk penelitian lebih lanjut. Secara keseluruhan, ringkasan ini akurat dan jelas, memberikan wawasan kunci untuk pemahaman cepat tentang studi. Untuk meningkatkan ke A+, definisikan akronim, sebutkan statistik dasar grup, catat hasil sekunder apa pun, dan sentuh secara singkat kebutuhan untuk 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. |
| Assistant | Metodologi: Uji coba terkontrol acak (RCT) double-blind dengan 500 pasien diabetes tipe 2. Grup A (n=250) menerima agonis dual glucagon-like peptide-1/glucose-dependent insulinotropic polypeptide (GLP-1/GIP) novel; Grup B (n=250) menerima agonis GLP-1 standar. Endpoint primer uji coba 24 minggu adalah pengurangan HbA1c. Grup cocok dengan baik untuk usia, BMI, dan HbA1c dasar. Temuan: - Grup A: pengurangan HbA1c rata-rata 1,8% - Grup B: pengurangan HbA1c rata-rata 1,1% - 68% Grup A vs. 52% Grup B mencapai HbA1c <7% - Grup A: penurunan berat badan rata-rata 5,2kg - Grup B: penurunan berat badan rata-rata 3,1kg Endpoint sekunder menunjukkan perbaikan dalam tekanan darah dan profil lipid untuk kedua grup, dengan Grup A menunjukkan hasil yang sedikit lebih baik. Keamanan: Profil kejadian merugikan serupa, tanpa kejadian serius yang dikaitkan dengan salah satu pengobatan. Implikasi Klinis: Agonis dual GLP-1/GIP menunjukkan kontrol glikemik dan penurunan berat badan yang superior 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 efikasi dan keamanan yang berkelanjutan, serta untuk menyelidiki manfaat potensial pada hasil kardiovaskular. |
Contoh
Contoh: Menganalisis kontrak hukum (tanpa chaining)
Contoh: Menganalisis kontrak hukum (tanpa chaining)
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 tanggung jawab. <contract> {{CONTRACT}} </contract> Kemudian buat draft email kepada 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 “perbaikan layanan.” - Risiko: Dapat menyebabkan berbagi data tidak sah atau monetisasi. 2. SLA (Bagian 5): - Masalah: Jaminan uptime 99,5% di bawah standar industri. - Risiko: Downtime berlebihan dapat berdampak pada operasi kami. 3. Tanggung Jawab (Bagian 9): - Masalah: Batas ditetapkan pada 3 bulan biaya. - Risiko: Tidak memadai untuk potensi pelanggaran data atau kegagalan layanan. Draft email: Dear {{VENDOR}}, Setelah meninjau perjanjian SaaS, kami memiliki kekhawatiran: 1. Privasi Data: Kami memerlukan bahwa data kami hanya digunakan untuk penyediaan layanan langsung, bukan “perbaikan layanan” yang luas. Harap ubah Bagian 7. 2. SLA: Uptime 99,5% tidak memadai. Kami memerlukan 99,99% dengan penalti yang jelas. Harap revisi Bagian 5. 3. Tanggung Jawab: 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 kami dan percaya perubahan ini akan mempersiapkan kami untuk sukses. Harap kirim perjanjian yang direvisi. Salam terbaik, {{CLO_NAME}} |
Contoh: Menganalisis kontrak hukum (dengan chaining)
Contoh: Menganalisis kontrak hukum (dengan chaining)
Prompt 1
| Role | Content |
|---|---|
| User | Anda adalah Chief Legal Officer kami. Tinjau kontrak SaaS ini untuk risiko, fokus pada privasi data, SLA, dan batas tanggung jawab. <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 “perbaikan layanan.” - Risiko: Dapat menyebabkan berbagi data tidak sah atau monetisasi data klien. - 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. Tanggung Jawab (Bagian 9): - Masalah: Batas tanggung jawab ditetapkan pada 3 bulan biaya. - Risiko: Tidak memadai untuk potensi pelanggaran data, pencurian IP, atau kegagalan layanan berkepanjangan. - Dampak: Kompensasi tidak memadai untuk kerusakan yang dapat jauh melebihi batas, seperti gugatan class-action atau denda regulasi. |
Prompt 2
| Role | Content |
|---|---|
| User | Buat draft email kepada vendor produk SaaS yang menguraikan kekhawatiran berikut dan mengusulkan perubahan. Berikut adalah kekhawatirannya: <concerns> {{CONCERNS}} </concerns> |
| Assistant {{EMAIL}} | Dear {{VENDOR}}, Setelah tinjauan 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 “perbaikan layanan.” - Kekhawatiran: Potensi berbagi data tidak sah atau monetisasi. - Perubahan yang Diusulkan: Batasi penggunaan data untuk penyediaan layanan langsung. Setiap penggunaan untuk perbaikan, 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: Uptime 99,99% dengan kredit layanan bertingkat. Misalnya, kredit 10% untuk <99,99%, 25% untuk <99,9%, 50% untuk <99,5%. 3. Tanggung Jawab (Bagian 9): - Saat ini: Batas pada 3 bulan biaya. - Kekhawatiran: Sangat tidak memadai untuk pelanggaran data, pencurian IP, atau pemadaman berkepanjangan. - Perubahan yang Diusulkan: 12 bulan biaya untuk tanggung jawab umum. Tanpa batas untuk pelanggaran data, kesalahan yang disengaja, pelanggaran IP. Perubahan ini tidak dapat dinegosiasikan bagi kami. Mereka selaras dengan standar industri dan komitmen kami terhadap keamanan data, keunggulan operasional, dan tanggung jawab fidusia. Kami menghargai potensi kemitraan kami, dan menangani ini akan menetapkan fondasi yang kuat. Harap tim hukum Anda meninjau dan memasukkan perubahan ini. Kami senang untuk berdiskusi lebih lanjut untuk memastikan pemahaman dan kesepakatan bersama. Salam terbaik, {{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 konfrontatif. - Penggunaan “tidak dapat dinegosiasikan” kuat tetapi dibenarkan mengingat kritisnya masalah. - Bahasa kolaboratif (“kami menghargai,” “senang untuk berdiskusi”) menyeimbangkan ketegasan, mempertahankan nada konstruktif. 2. Kejelasan: - Struktur yang sangat baik: Keadaan saat ini, kekhawatiran, dan perubahan yang diusulkan untuk setiap masalah. - Istilah teknis (misalnya, “EBITDA,” “kredit layanan bertingkat”) sesuai untuk konteks SaaS B2B. - 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), mengangkat diskusi. - Menawarkan diskusi lebih lanjut, menunjukkan komitmen untuk memahami dan menyelesaikan masalah. Secara keseluruhan, email 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 dengan pengiriman. |
Contoh: Tinjauan strategi multitenancy
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 kontention, mendukung pertumbuhan tinggi. + Microservices memungkinkan scaling independen komponen. - Server aplikasi bersama dapat menjadi bottleneck di bawah beban ekstrem. - Tidak ada penyebutan auto-scaling atau load balancing untuk tier aplikasi. 2. Keamanan: + Isolasi data tenant melalui sharding mengurangi kebocoran data. + JWT dengan expiry pendek dan refresh token adalah praktik terbaik industri. - Tidak ada penyebutan enkripsi (at rest, in 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 jarang mengoptimalkan biaya. - DB per-tenant dapat meningkatkan biaya pada skala vs. DB multi-tenant yang dioptimalkan. - Tidak ada diskusi tentang reserved instances atau spot instances untuk penghematan biaya. |
Prompt 2
| Role | Content |
|---|---|
| User | Buat dokumen tinjauan strategi untuk kepemimpinan engineering berdasarkan analisis strategi multitenancy ini. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Sertakan ringkasan eksekutif, analisis detail, dan rekomendasi. |
| Assistant {{STRATEGY_DOC}} | # Tinjauan Strategi Multitenancy: Produk SaaS Enterprise ## Ringkasan Eksekutif Strategi yang diusulkan menunjukkan fondasi yang solid dalam prinsip skalabilitas dan keamanan tetapi memiliki celah dalam detail implementasi. Ini unggul dalam isolasi data dan scaling tingkat komponen tetapi kurang dalam scaling 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 Detail ### 1. Skalabilitas: B+ Kekuatan: - Sharding database berdasarkan tenant sangat baik. Ini meminimalkan latensi query, mendukung pertumbuhan data tinggi, dan memfasilitasi scaling per-tenant yang mulus. - Arsitektur microservices memungkinkan scaling komponen individual berdasarkan permintaan, penting untuk menangani beban kerja enterprise yang beragam. Kelemahan: - Server aplikasi bersama berisiko menjadi bottleneck. Seiring pertumbuhan jumlah tenant dan traffic, ini dapat menurunkan kinerja di semua tenant. - Tidak adanya auto-scaling dan load balancing untuk tier aplikasi adalah kelalaian kritis. Ini penting untuk menangani lonjakan traffic 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 expiry pendek dan refresh token selaras dengan praktik terbaik OWASP, mengurangi jendela kerentanan token. Kelemahan: - Tidak ada penyebutan enkripsi data at rest atau in transit (TLS 1.3). Ini tidak dapat dinegosiasikan untuk data enterprise. - Strategi manajemen kunci hilang. Bagaimana kunci enkripsi, rahasia JWT, dan kredensial DB dikelola dan dirotasi? - IAM kurang kedalaman. Kami memerlukan RBAC dengan peran yang terdefinisi dengan baik, kontrol akses berbasis atribut (ABAC) untuk izin yang halus, dan integrasi dengan penyedia identitas enterprise (SAML, OIDC). ### 3. Efektivitas Biaya: B Kekuatan: - Server aplikasi bersama mengurangi biaya kapasitas idle, baik untuk traffic steady-state. - Serverless untuk tugas jarang (misalnya, pelaporan) cerdas; bayar hanya ketika sumber daya ini digunakan. Kelemahan: - Database per-tenant mungkin tidak cost-effective pada skala dibandingkan database multi-tenant yang dirancang dengan baik dengan partisi data yang kuat. - Tidak ada penyebutan langkah-langkah penghematan biaya seperti reserved instances untuk beban kerja yang dapat diprediksi atau spot instances untuk tugas fault-tolerant. - Kurangnya auto-scaling tier aplikasi dapat menyebabkan over-provisioning, meningkatkan biaya. ## Rekomendasi 1. Ketahanan Tier Aplikasi: Implementasikan auto-scaling dengan Kubernetes atau layanan cloud-native (EKS, GKE). Deploy di availability zones dengan CDN untuk aset statis. 2. Penguatan Keamanan: a. Enkripsi data at rest (AES-256) dan in 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 (misalnya, Snowflake) vs. sharding pada skala. b. Gunakan reserved instances untuk server aplikasi, spot instances untuk beban kerja non-kritis. c. Implementasikan monitoring proaktif dan right-sizing untuk menghindari overprovisioning. 4. Proof of Concept (PoC): Sebelum implementasi penuh, lakukan PoC dengan simulasi skala tinggi: a. Uji sharded DB vs. DB multi-tenant yang dioptimalkan untuk biaya dan kinerja. b. Stress-test tier aplikasi dengan simulasi lonjakan traffic tingkat enterprise. c. Lakukan audit keamanan pihak ketiga, fokus pada isolasi data dan kontrol akses. Dengan peningkatan ini, strategi multi-tenancy kami akan menjadi enterprise-grade: scalable, aman, dan cost-effective. PoC akan memvalidasi pilihan desain kami dan menanamkan kepercayaan pada klien enterprise kami. |
Prompt 3
| Role | Content |
|---|---|
| User | Beri nilai dokumen tinjauan strategi ini untuk kejelasan, actionability, dan keselarasan dengan prioritas enterprise. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistant | 1. Kejelasan: A + Struktur jelas dengan Ringkasan Eksekutif, Analisis Detail, 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 (bullet points, indentasi) meningkatkan keterbacaan. 2. Actionability: A- + Rekomendasi spesifik dan teknis (misalnya, “Implementasikan auto-scaling dengan Kubernetes”). + Rencana PoC dengan objektif jelas memberikan roadmap. + Kurang: Timeline, kebutuhan sumber daya, atau penugasan tim untuk setiap rekomendasi. + Pertimbangkan: Tambahkan bagian “Langkah Selanjutnya” dengan tindakan langsung, peran, dan timeline tingkat tinggi. 3. Keselarasan Enterprise: A+ + Langsung menangani prioritas enterprise: - Skalabilitas: Membahas penanganan lonjakan traffic tingkat enterprise. - Keamanan: Fokus pada isolasi data, enkripsi, dan IAM enterprise. - Biaya: Strategi selaras dengan FinOps enterprise (reserved instances, right-sizing). + PoC dengan “simulasi skala tinggi” dan audit keamanan menunjukkan komitmen terhadap kualitas enterprise-grade. + Bahasa beresonansi dengan kekhawatiran enterprise: “risiko yang tidak dapat diterima,” “enterprise-grade,” “menanamkan kepercayaan.” Secara keseluruhan, dokumen unggul dalam kejelasan dan keselarasan enterprise. Actionability kuat tetapi dapat ditingkatkan ke A+ dengan bagian “Langkah Selanjutnya”. Kedalaman teknis, ditambah dengan penjelasan yang jelas, membuat ini sangat efektif untuk kepemimpinan teknis dan non-teknis. Kerja bagus! |
Perpustakaan prompt
Dapatkan inspirasi dari koleksi prompt yang dikurasi untuk berbagai tugas dan kasus penggunaan.
Tutorial prompting GitHub
Tutorial yang dipenuhi contoh yang mencakup konsep prompt engineering yang ditemukan dalam dokumentasi kami.
Tutorial prompting Google Sheets
Versi yang lebih ringan dari tutorial prompt engineering kami melalui spreadsheet interaktif.