Empat batasan yang membuat setiap prompt di bawah ini efektif
Sebelum masuk ke prompt, ini aturan yang mereka semua bagikan. Menambahkan hal ini ke prompt coding apa pun meningkatkan hasil lebih baik daripada sekadar mengganti model.
Sebutkan versi Anda. Data pelatihan cenderung condong ke versi mayor yang paling banyak dibahas, yang sering kali bukan versi yang Anda pakai. Kami memakai [framework] [versi], [bahasa] [versi] mencegah sebagian besar jawaban yang sudah usang.
Batasi cakupan diff. Minta perbaikan dan Anda sering mendapat refactor. Ubah sesedikit mungkin, pertahankan struktur dan penamaan yang ada, dan daftar setiap baris yang Anda ubah dengan alasan singkat satu baris adalah kalimat paling berguna di seluruh dokumen ini.
Minta hipotesis sebelum solusi. Model yang ditanya apa yang salah memberi Anda dugaan yang disampaikan sebagai kesimpulan. Model yang diminta penyebab berperingkat dan pemeriksaan murah memberi Anda rencana debugging.
Wajibkan mode kegagalan. Apa yang bisa rusak akibat ini, dan apakah ini memperbaiki penyebab atau hanya gejalanya? menangkap kelas bantuan AI paling mahal, yaitu perubahan yang membuat gejala hilang sementara cacatnya tetap ada.
Debugging
1. Hipotesis berperingkat
Ini errornya, kode yang relevan, dan apa yang sudah saya singkirkan. Jangan beri saya perbaikan dulu. Daftar empat penyebab paling mungkin berperingkat berdasarkan probabilitas, dan untuk masing-masing beri satu pemeriksaan termurah yang bisa mengonfirmasi atau menyingkirkannya. Error: [tempel]. Kode: [tempel]. Sudah disingkirkan: [daftar]. Stack: [bahasa, framework, versi].
2. Bug yang muncul sesekali
Ini gagal sesekali, kira-kira [frekuensi], pada kondisi [kondisi]. Sebutkan kategori kegagalan intermiten yang bisa menghasilkan gejala spesifik ini: timing, urutan, kehabisan resource, dependensi eksternal, state yang bocor antar-run, jam atau zona waktu, caching. Untuk masing-masing, katakan apa di kode yang mendukung atau bertentangan dengannya, dan apa persisnya yang harus saya log untuk membedakannya. Kode: [tempel].
3. Berjalan lancar secara lokal
Ini berjalan lancar secara lokal tapi gagal di [environment]. Daftar setiap kategori perbedaan environment yang bisa menyebabkan gejala spesifik ini: konfigurasi, environment variable, versi, filesystem dan sensitivitas huruf besar/kecil, zona waktu dan locale, jaringan dan DNS, izin akses, batas resource, dan perbedaan build atau bundling. Urutkan berdasarkan kemungkinan mengingat gejalanya, dan beri saya perintah diagnostik untuk masing-masing.
4. Jelaskan perbaikannya sebelum saya terapkan
Jelaskan mengapa perbaikan ini berhasil, apa yang tidak diperbaikinya, dan apa yang bisa rusak akibatnya. Jika penyebab sebenarnya ada di tempat lain dan ini hanya menambal gejala, katakan itu secara langsung.
Code review
5. Meninjau diff
Tinjau diff ini sebagai reviewer yang menuntut. Kategori berdasarkan prioritas: bug ketepatan, masalah keamanan, mode kegagalan yang tidak ditangani, race condition, lalu gaya penulisan. Untuk setiap temuan beri tingkat keparahan, baris spesifik, dan mengapa itu penting di codebase ini, bukan secara umum. Jangan komentari formatting. Jika diff-nya sudah solid, katakan itu daripada mengarang temuan. Konvensi: [jelaskan]. Diff: [tempel].
6. Pemeriksaan keamanan
Tinjau kode ini khusus untuk masalah keamanan: injection, celah autentikasi dan otorisasi, deserialisasi yang tidak aman, secret di kode atau log, input yang tidak divalidasi mencapai operasi sensitif, dan risiko dependensi. Untuk masing-masing, beri jalur serangan secara konkret, bukan sekadar menyebut kategorinya. Nyatakan dengan jelas apa yang tidak bisa Anda nilai tanpa melihat [deployment, lapisan auth, sensitivitas data].
7. Audit mode kegagalan
Untuk setiap pemanggilan eksternal di kode ini, nyatakan apa yang terjadi saat lambat, saat gagal, saat mengembalikan data tak terduga, dan saat berhasil tapi sebagian. Mana dari itu yang saat ini tidak ditangani, dan mana yang akan diam saja tanpa peringatan?
Prompt terakhir itu menemukan lebih banyak masalah produksi nyata daripada review umum, karena ia menanyakan jalur yang tidak pernah dibuatkan test oleh siapa pun.
Refactoring dan arsitektur
8. Rencana refactor
Usulkan rencana bertahap untuk melakukan refactor [deskripsi]. Batasan: API publik dari [x] tidak boleh berubah, kami deploy terus-menerus jadi setiap langkah harus bisa dirilis secara independen, dan test harus lulus setelah setiap langkah. Untuk setiap langkah beri perubahannya, risikonya, cara memverifikasinya, dan cara membatalkannya. Urutkan berdasarkan risiko, terendah dulu. Jangan tulis kodenya dulu.
9. Bela sisi yang lain
Saya memilih [pendekatan A] daripada [pendekatan B] untuk [konteks dan batasan]. Buat argumen terkuat untuk B. Apa yang harus benar tentang batasan kami agar B menjadi tepat, dan apakah ada yang benar di sini? Jangan simpulkan bahwa keduanya sama-sama valid.
10. Pahami apa yang Anda warisi
Ini file sumber utamanya. Hasilkan: entry point, alur data dari request ke response, state yang dibagikan dan di mana ia diubah, dependensi eksternal dan apa yang terjadi saat masing-masing tidak tersedia, dan tiga area yang paling mungkin mengandung bug berdasarkan kompleksitas dan coupling. Nyatakan secara eksplisit apa yang tidak bisa Anda tentukan dari yang saya berikan.
Instruksi terakhir itu penting. Model akan mendeskripsikan perilaku file yang tidak Anda tempel, disimpulkan dari namanya. Memaksa daftar eksplisit hal yang tidak diketahui memberi tahu Anda apa yang perlu dibaca.
Test
11. Test yang tidak akan Anda tulis sendiri
Tulis test case untuk fungsi ini, fokus pada input yang mungkin belum saya pertimbangkan: batas nilai, kosong dan null, unicode, nilai sangat besar, pemanggilan bersamaan, dan asumsi implisit apa pun dalam implementasinya. Untuk setiap test, nyatakan asumsi yang sedang diperiksanya. Fungsi: [tempel].
12. Test suite yang menguji test
Ini fungsi dan test yang sudah ada. Perilaku apa yang belum tercakup? Secara spesifik: jalur error, nilai batas, interaksi antar parameter, dan hal apa pun yang dilakukan implementasi yang tidak diklaim oleh test mana pun. Jangan tulis ulang test yang sudah ada.
Yang kedua adalah prompt bernilai lebih tinggi dan jarang dijalankan. Persentase coverage memberi tahu Anda baris mana yang dieksekusi, bukan perilaku mana yang benar-benar terkunci, dan celah antara keduanya adalah tempat regresi bersembunyi.
Pola opini kedua
Kebiasaan dengan pengaruh tertinggi di seluruh paket ini, dan yang membutuhkan lebih dari satu model.
Dapatkan jawaban dari satu model. Lalu ganti dan serahkan:
Engineer lain mengusulkan solusi ini untuk masalah ini. Temukan apa yang salah dengannya: ketepatan pada edge case, konkurensi, penanganan error, performa pada [skala], atau pendekatan lebih sederhana yang terlewat. Jika memang solid, katakan itu secara jujur daripada mengarang keberatan. Masalah: [tempel]. Solusi yang diusulkan: [tempel].
Ada dua hasil dan keduanya berguna. Entah model kedua menemukan celah nyata, yang sekarang Anda ketahui sebelum merge, atau ia setuju meskipun didorong untuk tidak setuju, yang merupakan konfirmasi bermakna. Melakukan iterasi dengan model yang sama tidak memberi Anda keduanya, karena model yang meninjau hasilnya sendiri kebanyakan hanya setuju dengan dirinya sendiri.
Gunakan ini pada keputusan yang mahal jika salah: perubahan skema, perbaikan konkurensi, apa pun yang menyentuh auth atau uang. Bukan untuk pekerjaan rutin. Lihat membandingkan model secara berdampingan, beralih model di tengah percakapan, dan menulis dan debug kode dengan banyak model untuk keseluruhan alur kerja dalam satu tempat.
Hal yang perlu diwaspadai
API yang dikarang. Nama method, parameter, dan config key yang disebutkan dengan yakin padahal tidak ada, terutama untuk library yang baru diubah. Signaturenya akan terlihat benar. Periksa dokumentasi resmi sebelum membangun sesuatu di atas hal yang belum familiar.
Tidak ada sinyal keyakinan. Perbaikan yang benar dan yang salah secara halus muncul dengan kepastian yang identik. Nada bicaranya tidak memberi tahu apa-apa.
Scope creep yang diam-diam. Ini alasan batasan kedua ada.
Teater keamanan. Menyebutkan kelas kerentanan di kode Anda adalah langkah awal yang berguna. Itu bukan audit, dan model tidak tahu threat model, deployment, atau sensitivitas data Anda.
Simpan prompt yang Anda pakai setiap minggu di tempat yang bisa Anda tempel, dan taruh batasan tetap di instruksi project agar berlaku otomatis untuk setiap chat di project itu.
- Sebutkan bahasa, framework, dan versi Anda di setiap prompt coding
- Tambahkan kalimat pembatas diff ke prompt apa pun yang menghasilkan kode
- Minta hipotesis berperingkat dan pemeriksaan murah sebelum meminta perbaikan
- Selalu tanyakan apa yang bisa rusak akibat perbaikan dan apakah ia menangani gejala saja
- Jalankan pola opini kedua pada apa pun yang mahal jika salah
- Tanyakan apa yang belum dicakup test suite yang ada, bukan sekadar minta lebih banyak test
- Verifikasi API yang belum familiar terhadap dokumentasi resmi
- Simpan prompt yang Anda pakai setiap minggu di tempat yang mudah ditempel
Pertanyaan Umum
Apakah prompt ini hanya bekerja dengan Claude?
Tidak. Prompt ini ditulis untuk gaya konteks panjang dan penalaran hati-hati yang dikuasai Claude, dan bekerja langsung dengan GPT dan Gemini juga. Bahkan beberapa di antaranya lebih baik dipakai lintas model: prompt opini kedua membutuhkan dua model, dan prompt "bela sisi yang lain" lebih berguna ketika model yang berargumen tidak membuat pilihan aslinya.
Model mana yang harus saya pakai untuk prompt yang mana?
Sebagai titik awal: Claude untuk penalaran halus, arsitektur yang belum familiar, dan menjelaskan mengapa sesuatu berperilaku seperti itu; GPT untuk implementasi cepat pada wilayah yang sudah banyak dijelajahi dan output terstruktur yang ketat; model konteks besar saat pertanyaan mencakup lebih banyak kode daripada yang muat nyaman dalam prompt normal. Lalu timpa itu dengan seminggu perbandingan Anda sendiri, karena jawaban yang tepat lebih bergantung pada stack Anda daripada benchmark mana pun.
Apakah ini pengganti alat coding agentic?
Tidak, keduanya menyelesaikan masalah berbeda. Agent hidup di repository Anda dan mengedit file. Prompt ini untuk lapisan penalaran: memahami error, meninjau diff, merencanakan refactor, berargumen soal pendekatan. Kebanyakan developer memakai keduanya, dan pilihan model lebih penting di sini karena Anda mengevaluasi penalarannya, bukan diff hasilnya.
Bagaimana cara menghentikannya menulis ulang kode yang tidak saya minta?
Tambahkan ini ke prompt: ubah sesedikit mungkin, pertahankan struktur dan penamaan yang ada, dan daftar setiap baris yang Anda ubah dengan alasan singkat satu baris. Refactoring yang tidak diminta adalah alasan utama saran AI menjadi tidak bisa ditinjau, dan membatasi diff adalah perbedaan antara perubahan yang bisa Anda nalar dan yang harus Anda baca ulang dari awal.
Bolehkah saya menempel kode milik perusahaan?
Whizi tidak melatih model dari percakapan Anda dan kebijakan data setiap provider bisa ditinjau sebelum Anda mengaktifkan model itu, tapi kebijakan perusahaan Anda adalah batasan yang mengikat dan itu sangat bervariasi. Jika ada batasan berlaku, mereproduksi masalah sebagai contoh minimal yang mempertahankan struktur dan membuang logika bisnis biasanya diizinkan dan sekaligus menjadi prompt yang lebih baik, karena itu menghilangkan detail yang bersaing untuk mendapat perhatian.