Pendahuluan: Kode Tidak Peduli dengan Vibes Anda
Intinya tentang model bahasa besar dan kode: mereka sangat percaya diri dan sama sekali tidak peduli apakah program Anda berhasil dikompilasi atau tidak. dengan senang hati akan menulis skrip yang memecahkan masalah Anda, ditambah dua masalah yang ia ciptakan untuk bersenang-senang. Triknya—satu-satunya trik yang penting—adalah belajar cara melakukan pada untuk menghasilkan kode yang akurat dengan cara yang tidak memberikan ruang bagi dan memberikan ruang maksimal untuk kebenaran. Anda tidak ingin prosa yang terdengar seperti kode. Anda ingin kode yang bertindak seperti kode. Ada perbedaannya.
Orang-orang memperlakukan seperti mantra mistis—ucapkan kata-kata yang tepat, dapatkan aplikasi yang sempurna. Itu adalah pemikiran . Kode adalah sebuah kontrak. Jika Anda menginginkan akurasi dari , Anda harus menulis kontraknya. “Buat aplikasi web” bukanlah sebuah kontrak. “Hasilkan dalam yang menerima , memvalidasi skema dengan , dan mengembalikan 422 pada kesalahan skema dengan format tertentu” adalah sebuah kontrak. Begitulah cara melakukan pada untuk menghasilkan kode yang akurat: Anda memastikan kontraknya dengan baik.
Apa Ini (dan Bukan)
- Ini adalah panduan tentang cara mendapatkan kode yang andal dan dapat diuji dari .
- Ini bukanlah khotbah tentang “AI menggantikan pengembang.” Alat tidak menggantikan pemikiran.
- Ini berfokus pada praktis, struktur, dan batasan: bagian-bagian membosankan yang membuat keajaiban itu terjadi.
Jika Anda menginginkan kode yang berjalan, Anda perlu memberikan definisi kerja tentang “berjalan” kepada . Jika Anda menginginkan pembuatan kode yang akurat, Anda perlu mendefinisikan akurasi dalam istilah yang jelas dan dapat diuji. Itulah seluruh inti dari hal ini.
Definisikan Akurasi Seperti Pengacara, Bukan Penyair
Kode yang “akurat” bukanlah kode yang “terlihat masuk akal”. Akurasi adalah:
- Validitas sintaksis: ia berhasil dikompilasi atau berjalan di bawah interpreter.
- Fidelitas semantik: ia melakukan apa yang dikatakan spesifikasi.
- Perilaku deterministik: input yang sama, output yang sama, dalam batas kesalahan yang ditentukan.
- Koreksi versi: ia menggunakan SDK, versi API, dan fitur bahasa yang tepat.
akan memberi Anda apa yang Anda minta. Jika Anda meminta “sebuah fungsi yang mengurutkan daftar,” Anda kemungkinan besar akan mendapatkannya. Jika Anda meminta “pengurutan stabil menggunakan semantik dengan ruang tambahan O(1),” itu adalah janji yang berbeda. “Cara melakukan pada untuk menghasilkan kode yang akurat” dimulai dengan menuliskan janji-janji tersebut ke dalam .
, yang Ditingkatkan
Buruk: “Tulis API untuk tugas.”
Lebih baik: “Tulis API dengan rute /tasks yang memvalidasi bidang {title: string, dueDate: ISO 8601} dan merespons 201 dengan objek yang dibuat atau 400 dengan detail kesalahan.”
Benar: “Hasilkan dengan satu /tasks. Persyaratan: 1) Validasi body dengan [email protected]; 2) Bidang: title ( tidak kosong, maks 140), dueDate (tanggal di masa depan); 3) Saat berhasil: 201 dengan {id: ULID, title, dueDate}; 4) Saat tidak valid: 400 dengan {error: 'VALIDATION', details: array}; 5) Tanpa basis data; ; 6) Sertakan berkas pengujian yang mencakup valid, tidak valid (judul kosong, tanggal lampau); 7) Sediakan skrip untuk pengujian dan pengembangan; 8) Gunakan ; 9) Jangan sertakan komentar yang tidak perlu.” Perhatikan bentuknya: versi bahasa, pustaka, batasan, output, kesalahan, pengujian, dan bahkan struktur paket. Anda telah menghilangkan ambiguitas. Tugas adalah mengisi kode, bukan persyaratan.
Pola Perancah: Sistem, Spesifikasi, Pengujian, Kemudian Kode
Jika Anda menginginkan pembuatan kode yang akurat dari , Anda perlu memberinya landasan:
- Pembingkaian sistem (tali pendek)
- Anda: “Anda menulis berkualitas produksi untuk . Keluarkan hanya blok kode dengan nama berkas dan tidak ada yang lain.”
- Mengapa: Anda mengontrol nada dan format output. Jangan menyerahkannya pada kesempatan.
- Sertakan versi bahasa, pilihan paket, semantik kesalahan, format I/O, batasan kinerja, dan batasan keamanan.
- Suruh menulis pengujian unit terlebih dahulu. Pengujian mendefinisikan “akurat” lebih baik daripada kata sifat. Jika baris kode tidak melayani pengujian, itu bersifat dekoratif.
- Hanya setelah pengujian. Ya, ini pada dasarnya , tetapi dengan robot yang tidak pernah bosan menulis .
- Instruksi untuk pengulangan
- “Jika pengujian gagal atau impor tidak cocok, perbarui hanya bagian yang gagal. Jangan menulis ulang seluruh proyek.”
bekerja dengan baik ketika ia memiliki konteks dan batasan. Berikan batasan padanya.
Bukanlah Opsional
Data pelatihan penuh dengan dokumen lama dan baru. Itu adalah cara sopan untuk mengatakan bahwa ia telah melihat banyak saran yang bertentangan. “Gunakan ” itu ambigu. “Gunakan [email protected] dengan ” adalah arahan. Jangan percaya : - Bahasa: sematkan ke , , , —apa pun yang sebenarnya Anda jalankan.
- Kerangka kerja: tentukan versi yang tepat dan bendera perubahan yang merusak.
- : sematkan versi; aws-sdk v2 vs v3 penting.
- Linter/formatter: tentukan aturan untuk menghindari penulisan ulang “”.
Jika Anda tidak menyematkan, Anda akan mendapatkan campuran dari lima tahun posting blog. Pembuatan kode yang akurat alergi terhadap nostalgia.
Skema Dulu, Selalu
Jangan meminta struktur “profil pengguna”. Definisikan skema dalam dan wajibkan validasi:
Kemudian buat memberlakukan skema di perbatasan—input API, penulisan basis data, dan antrean pesan. Mintalah dan kode kesalahan eksplisit. Akurasi menyukai skema. Ambiguitas tidak.
Buat Dapat Diamati, atau Jangan Berpura-pura Itu Nyata
Suruh menambahkan , metrik, dan di tempat yang Anda butuhkan—dan menjaganya tetap tenang di tempat yang tidak Anda butuhkan. yang baik mencakup:
- Kebijakan : level, , struktur (log , tolong)
- Metrik: waktu per permintaan, jumlah kesalahan
- kesehatan: /healthz yang membuktikan bahwa dependensi berfungsi
akan menambahkan apa yang Anda minta. Jika Anda tidak meminta, Anda akan mendapatkan pernyataan —jika Anda beruntung.
Uji-Dulu Mengalahkan “Percayalah Padaku”
Cara yang baik untuk melakukan pada untuk menghasilkan kode yang akurat adalah dengan menjadikan pengujian sebagai sumber kebenaran. Contoh:
“Tulis pengujian untuk fungsi normalize_email(s) yang:
- mengubah bagian lokal dan domain menjadi huruf kecil;
- menghapus titik-titik di bagian lokal hanya untuk gmail.com;
- menghapus subalamat (+tag) hanya untuk gmail.com;
- menolak input tanpa satu @ atau dengan spasi;
- mempertahankan domain unicode apa adanya.
Cakupan kasus ekstrem. Setelah menulis pengujian, terapkan fungsi untuk meloloskannya.”
sering kali menulis kode yang lebih baik ketika dipaksa untuk memenuhi pengujian yang Anda jelaskan. Jika tidak, Anda memiliki kegagalan konkret, bukan argumen .
Tidak Ada Halusinasi dengan Konstruksi
Anda tidak dapat menghilangkan halusinasi, tetapi Anda dapat membatasinya:
- Minta kutipan atau URL sumber hanya jika sumbernya ada. Untuk metode , minta tautan dokumen dan wajibkan kode untuk mencocokkan dokumen tersebut.
- Untuk API pribadi, tempel spesifikasi di . Jangan berharap mengetahui internal Anda.
- Untuk pustaka dengan API yang membingungkan, sertakan cuplikan contoh dari dokumen resmi dan suruh untuk mematuhinya.
Kode yang akurat sebagian besar adalah referensi yang akurat. Berikan referensi kepada .
Panduan Gaya: Hal yang Paling Tidak Seksi, Paling Berguna
menulis kode dalam gaya apa pun yang disimpulkannya. Itu adalah resep untuk pergolakan. Tempel panduan gaya Anda. Tentukan:
- Pola penanganan kesalahan
Juga minta komentar rasional singkat untuk pilihan yang tidak jelas. Anda di masa depan akan berterima kasih, dan saat ini akan menghasilkan lebih sedikit “perbaikan”.
Panjang, Output Pendek
Cara lain untuk memikirkan cara melakukan pada untuk menghasilkan kode yang akurat: habiskan kata-kata Anda pada , bukan pada output. Anda menginginkan:
- Batasan yang lengkap dalam
- Narasi asing minimal dalam output
Suruh ia menekan penjelasan dan hanya mengembalikan blok kode dengan nama berkas dan pendek. Jika Anda menginginkan komentar, mintalah dalam proses terpisah. Menyelipkan prosa dan kode adalah bagaimana bug menyelinap masuk mengenakan kacamata lensa tunggal dan topi tinggi.
Penyempurnaan: Lingkaran Ketat yang Benar-Benar Berfungsi
Jalur tercepat menuju kode yang andal bukanlah “mendapatkannya dengan benar pada percobaan pertama.” Itu adalah lingkaran korektif pendek:
- Hasilkan pengujian + kode.
- Jalankan secara lokal. Tempel output pengujian yang gagal dan kesalahan kompiler kembali ke kata demi kata.
- Instruksikan: “Modifikasi hanya baris minimum yang diperlukan; jangan mengubah tanda tangan fungsi kecuali diperlukan oleh pengujian yang gagal.”
sangat baik dalam menerapkan ketika Anda memberitahunya dengan tepat apa yang rusak. Jangan parafrase log kegagalan. Tempel mereka. Log adalah kebenaran.
Keamanan Adalah Fitur, Bukan
Karena model dilatih pada kode publik (baik, buruk, dan terkutuk), Anda ingin menjadikan keamanan sebagai persyaratan kelas satu:
- Secara eksplisit melarang , shell=True, dan bertipe
- Wajibkan kueri berparameter, perlindungan , dan pembatasan laju
- Minta ditambah berkas kunci
- Tuntut penanganan untuk melalui variabel lingkungan atau
aman-secara- menghasilkan kode yang lebih aman. “kami akan menambalnya nanti” menghasilkan berita utama.
Kinerja: Katakan Apa Artinya “Cepat”
“Buat cepat” diterjemahkan menjadi “lakukan apa saja.” Alih-alih, tentukan metrik:
- Target latensi (p95 < 50ms untuk , p95 < 300ms untuk operasi )
- Kompleksitas waktu (harus O(n log n), bukan O(n^2))
akan memilih algoritma yang sesuai dengan anggaran yang Anda tetapkan. Berikan anggaran padanya.
Dokumentasi: Cukup untuk Memperkenalkan Orang Asing
Minta untuk yang mencakup:
- Instruksi pengaturan dengan versi yang tepat
- Perintah untuk pengujian, , , jalankan
- Contoh permintaan/respons
- Keterbatasan dan yang diketahui
“Kode yang akurat” mencakup dokumen yang akurat. Mereka adalah bagian dari yang dikirimkan.
Templat Konkret yang Dapat Anda Curi
Templat:
Sistem: Anda adalah insinyur yang teliti. Keluarkan hanya blok kode dengan nama berkas.
Pengguna:
- Bangun aplikasi dengan /convert.
- Permintaan: {amount: sebagai , from: 'USD'|'EUR', to: sama}.
- Validasi dengan pydantic v2; kembalikan bentuk 422 pada kesalahan skema.
- Gunakan fungsi murni convert(amount, from, to) dengan tarif tetap {USD:1, EUR:1.1}.
- Kembalikan {amount: , currency: } dengan 200.
- Sertakan pengujian yang mencakup valid, tidak valid (desimal buruk, kode tidak dikenal), dan (0).
- Sediakan pyproject.toml dengan dependensi yang disematkan; sertakan konfigurasi dan .
- Tanpa panggilan jaringan, tanpa komentar.
Templat: Utilitas
Sistem: Anda menulis . Keluarkan hanya blok kode dengan nama berkas.
Pengguna:
- Buat bernama slugify yang membaca stdin dan mencetak aman untuk .
- Aturan: huruf kecil, khusus , pemisah tanda hubung, ciutkan , hapus tanda baca.
- Sediakan main.go dan slugify_test.go dengan pengujian tabel.
- Sertakan dengan target pengujian dan pembuatan.
Templat: Komponen
Sistem: Anda adalah insinyur pragmatis yang menargetkan + .
Pengguna:
- Terapkan komponen <DebouncedInput>.
- Properti: value: , onChange(value): void, delay=300.
- Gunakan useRef/useEffect; tanpa pihak ketiga.
- Sertakan pengujian vitest dengan .
Templat ini menunjukkan cara melakukan pada untuk menghasilkan kode yang akurat dengan menyematkan versi, mendefinisikan perilaku, dan mewajibkan pengujian.
Menolak Menjadi Pintar: Kapan Harus Mengatakan “Jangan Optimalkan”
Jika Anda tidak menginginkan mikro-optimasi prematur (dan Anda tidak menginginkannya), katakan demikian:
- “Utamakan keterbacaan daripada kepintaran; tanpa kecuali pengujian membutuhkannya.”
- “Tidak ada rekursi jika iteratif lebih jelas.”
- “Tidak ada metaprogramming; eksplisit > implisit.”
suka membuat kesan. Jangan biarkan ia melakukannya. Buat ia lolos pengujian dan mudah dibaca. Itu sudah cukup mengesankan.
Sider.AI dalam Alur Kerja, Tempat Ia Benar-Benar Membantu Saya telah melihat orang-orang menyulap di tab obrolan acak seperti itu adalah ritual produktivitas. Gunakan ruang kerja yang memahami konteks kode. Sider.AI, misalnya, dibangun di sekitar menjaga spesifikasi, kode, , dan log pengujian Anda tetap terlihat, sehingga lingkaran “tempel kesalahan, perbaiki baris” benar-benar ketat. Ini bukan sihir; ini adalah perancah membosankan yang mencegah Anda kehilangan alur cerita. Jika alat Anda menyimpan kontrak, pengujian, dan kode dalam percakapan yang sama—tanpa mengganggu Anda dengan confetti—gunakan itu. melakukannya. Cara Melakukan Debug Dengan Sebagai Rekan Tim, Bukan Peramal
- Tempel output pengujian yang gagal persis apa adanya. Jangan meringkas.
- Minta : “Respons dengan terhadap berkas X saja.”
- Untuk , tambahkan cuplikan terkecil yang dapat direproduksi dan tuntut penjelasan ditambah .
- Untuk kesalahan pustaka, tempel kutipan dokumen yang menurut Anda berlaku dan tanyakan: “Apakah ini API yang benar untuk versi X? Jika tidak, perbarui kode dan kutip kutipan yang benar.”
Tujuannya adalah membuat berdebat dengan bukti. Anda membawa buktinya.
Parade Jebakan (dan Cara Menghindarinya)
- Perangkap API “terbaru”: Jangan katakan “gunakan terbaru.” Katakan “gunakan versi X.Y” dan tetaplah dengan itu.
- Berkas pengujian kosong: Jika Anda tidak menuntut pengujian, Anda tidak akan mendapatkannya.
- Kekeliruan satu kali: Rencanakan dua atau tiga penyempurnaan singkat. Itu lebih cepat daripada satu yang membengkak.
- Kebijakan kesalahan yang ambigu: Tentukan kode status dan . “Kembalikan kesalahan” tidak berarti apa-apa.
- Dependensi yang tidak dimiliki: Jika kode bergantung pada layanan yang tidak dapat Anda kendalikan, itu. Minta .
Daftar Periksa Anda (Tempel Ini Dekat Monitor Anda)
- Bahasa dan versi disematkan
- Semantik kesalahan didefinisikan (kode, bentuk)
- Pengujian dulu, lalu kode
- Batasan keamanan eksplisit
- Anggaran kinerja dinyatakan
- Gaya dan struktur ditentukan
- Format output dibatasi (nama berkas, blok kode, )
- Lingkaran penyempurnaan singkat dengan log yang ditempel
Jika Anda mencapai semua sepuluh, umumnya menghasilkan pembuatan kode yang akurat yang bertahan di siang hari.
Contoh yang Dikerjakan: Dari Tidak Jelas ke Terverifikasi
tidak jelas: “Tulis fungsi untuk mengurai dengan aman.”
Hasil: Mungkin oke, mungkin salah, tentu saja tidak teruji.
yang tepat:
“Anda menulis . Keluarkan hanya blok kode dengan nama berkas.
Buat csvsafe/init.py dan csvsafe/reader.py dengan fungsi read_rows(path: Path) -> list[dict[str,str]]. Persyaratan: gunakan csv.DictReader dengan newline='' dan encoding='utf-8'; larang byte nol; tolak berkas >10MB; batasi kolom hingga 100; hapus ; perlakukan sel kosong sebagai kosong; naikkan dengan kode pesan {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS}. Sertakan pengujian di tests/test_reader.py dengan yang mencakup jalur bahagia, byte nol, berkas 11MB, 101 kolom, dan penanganan . Sediakan pyproject.toml dengan dependensi yang disematkan dan konfigurasi .”
Anda akan mendapatkan kode, pengujian, dan penanganan . Kemudian Anda menjalankan pengujian, menempel kegagalan, dan melakukan iterasi dengan minimal. Itulah pembuatan kode yang akurat dalam praktik.
Tentang “Kreativitas” dan Kata-kata Pemasaran Lainnya
Saya tidak membutuhkan kode “kreatif”. Saya membutuhkan kode yang benar. Simpan kreativitas untuk menamai kucing Anda. Saat melakukan pada , kreativitas adalah produk sampingan alami dari batasan yang kuat. Pengujian yang tepat dan spesifikasi yang jelas menghasilkan solusi yang elegan. yang salah menghasilkan “base64 yang diciptakan kembali dengan emoji.” Jangan menggoda ia.
Rahasia Non-Rahasia
Cara melakukan pada untuk menghasilkan kode yang akurat itu membosankan: tuliskan apa yang Anda butuhkan, sematkan versinya, definisikan skemanya, tuntut pengujian, dan lakukan iterasi dengan kegagalan yang sebenarnya. Itu saja. Tidak ada mistisisme. Hanya disiplin teknik, dengan model yang dapat mengetik dengan sangat cepat dan tidak keberatan menulis lima belas kasus pengujian yang hampir identik.
Dan itulah -nya: akurasi itu tidak glamor. yang berfungsi dibaca seperti daftar periksa . Kode yang dikirimkan terbaca seperti ditulis oleh manusia yang peduli. Anda mendapatkan keduanya dengan memperlakukan model seperti insinyur junior yang berkembang di bawah persyaratan yang jelas dan layu di bawah arahan yang tidak jelas. Berikan kontrak padanya. Buat ia lolos pengujian. Kemudian, mungkin, Anda dapat mempercayainya—dengan jenis kepercayaan yang Anda berikan kepada alat, bukan nabi.
Kesimpulan: Lebih Sedikit Ilmu Gaib, Lebih Banyak Garansi
Jika Anda menginginkan ilmu gaib, pergilah ke pertunjukan sulap. Jika Anda menginginkan perangkat lunak yang dikompilasi dan berperilaku, tulislah yang berfungsi seperti garansi. Cara melakukan pada untuk menghasilkan kode yang akurat bukanlah tentang frasa berbunga-bunga atau kata kunci rahasia. Ini tentang batasan, pengujian, versi, dan lingkaran umpan balik. Lakukan empat hal itu, dan Anda akan mendapatkan kode yang berjalan. Lewati mereka, dan Anda akan mendapatkan fiksi yang diformat dengan indah.
Kode tidak peduli dengan perasaan Anda. Untungnya, pengujian juga demikian.
FAQ
Q1: Apa cara paling sederhana untuk meminta Claude Haiku 4.5 menghasilkan kode yang akurat?
Perlakukan seperti kontrak: tetapkan versi, definisikan skema, tentukan format kesalahan, dan minta pengujian terlebih dahulu. Semakin jelas batasannya, semakin akurat kodenya.
Q2: Bagaimana cara mengurangi halusinasi saat Claude menulis kode?
Tempelkan dokumentasi atau spesifikasi yang otoritatif dan tuntut kepatuhan terhadap API tersebut. Untuk titik akhir pribadi, sertakan spesifikasi Anda sendiri—jangan berharap ia menebak.
Q3: Haruskah saya meminta Claude untuk membuat pengujian atau menulisnya sendiri?
Minta Claude untuk membuat pengujian terlebih dahulu, lalu implementasikan kode untuk memenuhinya. Pengujian mendefinisikan akurasi lebih baik daripada kata sifat dan menjaga model tetap jujur.
Q4: Seberapa spesifik versi yang harus ditetapkan dalam perintah?
Sangat spesifik: runtime bahasa, kerangka kerja major/minor, dan versi SDK. "Terbaru" mengundang pola yang bertentangan; akurasi bergantung pada target yang stabil.
Q5: Di mana Sider.AI cocok dalam memberikan perintah untuk kode yang akurat?
Gunakan Sider.AI untuk menyimpan spesifikasi, kode, perbedaan, dan log pengujian dalam satu lingkaran. Ini tidak melakukan sihir—ini hanya mempertahankan konteks sehingga perbaikan Claude melacak kegagalan aktual Anda. 
