Rekayasa prompt
Merangkai prompt kompleks untuk kinerja yang lebih kuat
Rekayasa prompt
Merangkai prompt kompleks untuk kinerja yang lebih kuat
Saat mengerjakan tugas-tugas kompleks, Claude terkadang bisa melakukan kesalahan jika Anda mencoba menangani semuanya dalam satu prompt. Prompting chain of thought (CoT) memang bagus, tapi bagaimana jika tugas Anda memiliki beberapa langkah berbeda yang masing-masing membutuhkan pemikiran mendalam?
Masukkan perangkaian prompt: memecah tugas-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: Dengan mudah mengidentifikasi dan memperbaiki masalah dalam rangkaian prompt Anda.
Kapan merangkai prompt
Gunakan perangkaian prompt untuk tugas-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 dalam rangkaian mendapat perhatian penuh Claude!
Tip 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 penyerahan 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: Penelitian → Garis besar → Draf → Edit → Format.
- Pemrosesan data: Ekstrak → Transform → Analisis → Visualisasi.
- Pengambilan keputusan: Kumpulkan info → Daftar opsi → Analisis masing-masing → Rekomendasikan.
- Loop verifikasi: Hasilkan konten → Tinjau → Sempurnakan → Tinjau ulang.
Tip 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.
Prompt 1
| Peran | Konten |
|---|---|
| User | Ringkas makalah penelitian medis ini. <paper>{{RESEARCH_PAPER}}</paper> Fokus pada metodologi, temuan, dan implikasi klinis. |
| Assistant {{SUMMARY}} | Metodologi: RCT buta ganda 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 utama: 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 yang obesitas. |
Prompt 2
| Peran | Konten |
|---|---|
| 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-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 untuk penelitian lebih lanjut. Secara keseluruhan, ringkasan tersebut 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 singkat menyinggung kebutuhan untuk studi jangka panjang. |
Prompt 3
| Peran | Konten |
|---|---|
| User | Tugas Anda adalah memperbaiki ringkasan makalah berdasarkan umpan balik yang diberikan. Berikut adalah draf pertama ringkasan 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) buta ganda 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. Titik akhir utama uji coba 24 minggu adalah 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 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 yang obesitas. Namun, studi jangka panjang diperlukan untuk mengkonfirmasi efikasi dan keamanan yang berkelanjutan, serta untuk menyelidiki potensi manfaat pada hasil kardiovaskular. |
Contoh
Perhatikan bahwa Claude melewatkan instruksi untuk memberikan perubahan yang diusulkan dalam draf emailnya.
| Peran | Konten |
|---|---|
| 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 draf email ke vendor dengan kekhawatiran dan perubahan yang Anda usulkan. |
| 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 berdampak pada operasi kita. 3. Kewajiban (Bagian 9): - Masalah: Batas ditetapkan pada 3 bulan biaya. - Risiko: Tidak memadai untuk potensi pelanggaran data atau kegagalan layanan. Draf 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 cukup. 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}} |
Prompt 1
| Peran | Konten |
|---|---|
| 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 cukup untuk kerusakan yang bisa jauh melebihi batas, seperti gugatan class-action atau denda regulasi. |
Prompt 2
| Peran | Konten |
|---|---|
| User | Buat draf 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 kita 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 dibatalkan, 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 pemadaman 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 bagi 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 menetapkan dasar yang kuat. Mohon tim hukum Anda meninjau dan memasukkan perubahan ini. Kami senang untuk mendiskusikan lebih lanjut untuk memastikan pemahaman dan kesepakatan bersama. Salam hormat, {{CLO_NAME}} |
Prompt 3
| Peran | Konten |
|---|---|
| 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 menjadi konfrontatif. - Penggunaan “tidak dapat dinegosiasikan” kuat tetapi dibenarkan mengingat kekritisan masalah. - Bahasa kolaboratif (“kami menghargai,” “senang untuk mendiskusikan”) menyeimbangkan ketegasan, mempertahankan nada yang 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 SaaS B2B. - Item tindakan jelas: tim hukum vendor untuk meninjau dan memasukkan perubahan. 3. Profesionalisme: - Berfokus pada manfaat bersama dan standar industri, bukan hanya tuntutan kita. - 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 tersebut mencapai keseimbangan yang tepat antara ketegasan dan kolaborasi. Ini dengan jelas mengartikulasikan kekhawatiran kita, mengusulkan solusi spesifik, dan mempertahankan nada profesional yang berorientasi kemitraan. Tidak perlu revisi; lanjutkan untuk mengirim. |
Prompt 1
| Peran | Konten |
|---|---|
| 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 penskalaan independen komponen. - Server aplikasi bersama bisa 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 token refresh adalah praktik terbaik industri. - Tidak ada penyebutan enkripsi (saat istirahat, 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
| Peran | Konten |
|---|---|
| User | Buat dokumen tinjauan strategi untuk kepemimpinan teknik 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 dasar yang kuat dalam prinsip skalabilitas dan keamanan tetapi memiliki celah dalam detail implementasi. Ini unggul dalam isolasi data dan penskalaan tingkat komponen tetapi kurang dalam penskalaan tier aplikasi yang kuat dan langkah-langkah keamanan lanjutan. Optimisasi biaya hadir tetapi mungkin gagal pada skala tinggi. Dengan peningkatan yang ditargetkan, strategi ini dapat secara efektif mendukung ambisi SaaS enterprise kita. ## Analisis Terperinci ### 1. Skalabilitas: B+ Kekuatan: - Sharding database berdasarkan tenant sangat baik. Ini 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 load balancing 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 expiry pendek dan token refresh sesuai dengan praktik terbaik OWASP, mengurangi jendela kerentanan token. Kelemahan: - Tidak ada penyebutan enkripsi data saat istirahat 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 lebih rinci, dan integrasi dengan penyedia identitas enterprise (SAML, OIDC). ### 3. Efektivitas biaya: B Kekuatan: - Server aplikasi bersama mengurangi biaya kapasitas idle, baik 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 terhadap 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 istirahat (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 kolom (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 stres 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 kita akan berkelas enterprise: dapat diskalakan, aman, dan hemat biaya. PoC akan memvalidasi pilihan desain kita dan menanamkan kepercayaan pada klien enterprise kita. |
Prompt 3
| Peran | Konten |
|---|---|
| User | Nilai dokumen tinjauan strategi ini untuk kejelasan, kemampuan 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. + Alat bantu visual (poin bullet, indentasi) meningkatkan keterbacaan. 2. Kemampuan 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 menang ani 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. Kemampuan ditindaklanjuti kuat tetapi bisa ditingkatkan menjadi 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 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.