Cara memeriksa kod yang dijana AI jika anda tidak tahu membaca kod: 7 pemeriksaan untuk bukan pengatur cara pada 2026

AI menyiapkan laman web atau bot untuk anda dalam satu malam. Semuanya terbuka, butang berfungsi dan projek nampaknya berjalan lancar. Anda menunjukkan projek itu kepada orang lain—sehari kemudian, anda mendapat tahu bahawa borang pembayaran mengenakan caj, tetapi pesanan tidak diterima. Atau pangkalan data yang mengandungi nombor telefon pelanggan terbuka kepada seluruh internet.

Dulu saya juga melancarkan projek pertama saya dengan cara begitu: perkara yang nampak berfungsi akhirnya memberikan kejutan kepada pengguna sebenar. Sekarang, sebelum menunjukkan apa-apa kepada orang lain, saya menyemak projek menggunakan senarai semak yang sama. Saya tidak membaca satu baris kod pun semasa melakukannya—saya bukan datang ke sini untuk itu, dan anda pun mungkin begitu.

Ini bukan paranoia. Anthropic menganalisis 400,000 sesi Claude Code: sepanjang tujuh bulan, bahagian kerja yang digunakan untuk membaiki kod rosak menurun daripada 33% kepada 19%. Ia menurun, tetapi tidak hilang. Satu daripada setiap lima sesi masih mengenai “membaiki perkara yang dirosakkan oleh AI”.

Menulis kod itu sendiri bukan lagi halangan utama. Perkara yang penting sekarang ialah sejauh mana anda memahami tugasan dan sejauh mana anda boleh memeriksa hasilnya.

Bahan tambahan tentang penyediaan alat tersedia dalam dokumentasi Ailoot.

Mengapa Perlu Memeriksa Kod yang Dijana AI Jika Ia Sudah Berfungsi?#

AI menulis kod yang nampak baik pada pandangan pertama. Ia berjalan, skrin dipaparkan dan demonya kelihatan meyakinkan. Namun, melancarkannya tidak memberitahu anda sama ada wang dikira dengan betul, sama ada pangkalan data anda terdedah kepada pihak luar atau sama ada semuanya akan ranap apabila pengguna yang ke-100 tiba.

Angka-angka menyokong perkara ini. Penanda aras FrontierCode memeriksa pada Jun 2026 sejauh mana kod yang dijana AI sedia untuk kerja sebenar tanpa pengubahsuaian. Walaupun bagi model terbaik untuk tugasan paling sukar, bahagiannya hanya kira-kira 13%. Dengan kata lain, bagi tugasan yang serius, kebanyakan kod yang dijana AI perlu diperhalus secara manual sebelum anda boleh bergantung padanya.

Berita baiknya ialah sesiapa sahaja boleh melakukan pemeriksaan ini. Inilah kesimpulan Anthropic daripada 400,000 sesi yang sama:

Kelebihan anda berbanding mana-mana pengatur cara yang anda upah ialah anda memahami tugasan anda. Pemeriksaan juga tentang pemahaman; anda tidak perlu membaca kod untuk melakukannya. Pemeriksaan di bawah memang jenis pemeriksaan yang boleh anda lakukan sendiri, tanpa banyak kesukaran.

Apakah Yang Sebenarnya Boleh Menjadi Salah Dengan Kod yang Dijana AI?#

Sebelum memeriksa, elok anda tahu perkara yang perlu dicari. Kod yang dijana AI mempunyai lima masalah lazim, dan anda boleh melihat kelima-limanya tanpa membaca kod—dengan memerhatikan cara projek itu berkelakuan.

Seterusnya ialah tujuh pemeriksaan mengikut turutan. Pemeriksaan pertama mengesan masalah “tidak berfungsi” dan “berfungsi dengan salah”; pemeriksaan di tengah meliputi keselamatan dan rekaan; pemeriksaan terakhir ialah langkah perlindungan sebelum penerbitan. Sebaiknya lakukan semuanya mengikut turutan: setiap pemeriksaan bergantung pada pemeriksaan sebelumnya yang telah selesai.

Pemeriksaan 1: Minta AI Menerangkan Kodnya dalam Bahasa Mudah#

Anda menerangkan tugasan dengan kata-kata. AI menterjemahkannya kepada kod. Makna boleh hilang antara dua langkah ini: AI mungkin memahami anda secara berbeza, mengisi perkara yang tidak dinyatakan bagi pihak anda atau mengambil jalan pintas. Anda boleh mengesan ketidakpadanan itu tanpa membaca kod—hanya minta AI menerangkan perkara yang dilakukannya dalam bahasa mudah.

Terangkan dengan bahasa yang mudah, tanpa kod, dengan tepat apa yang baru sahaja anda lakukan:

tugas yang diselesaikan oleh kod ini

apa yang akan berlaku apabila pengguna mengklik butang atau menghantar borang

di mana data disimpan dan siapa yang mempunyai akses kepadanya

apa yang boleh rosak dan dalam keadaan apa

Tulis seolah-olah anda sedang menerangkan perkara ini kepada seseorang yang tidak pernah memprogram. Jika ada bahagian yang anda tidak pasti betul, nyatakannya dengan jelas.

Baca jawapannya dan bandingkan dengan perkara yang anda bayangkan. Jika sepadan, teruskan. Jika AI “bercakap kosong”, keliru dalam penjelasannya sendiri atau menerangkan sesuatu yang berbeza daripada permintaan anda, ini bermakna AI tidak memahami sepenuhnya perkara yang dibinanya. Minta AI menyemaknya semula dengan memberikan penjelasan, bukannya menerima kata-katanya begitu sahaja.

Ngomong-ngomong, jika AI kerap melakukan perkara yang berbeza daripada permintaan anda, masalahnya selalunya cara tugasan itu dirangka, bukannya model itu sendiri. Saya ada huraian berasingan tentang sebab Claude tidak melakukan apa yang anda minta.

Memeriksa hasil AI ialah sebahagian daripada kejuruteraan konteks: anda mengawal perkara yang diberikan kepada AI sebagai input dan cara anda menilai hasilnya sebagai output. Kit alat ini merangkumi klon AI, Second Brain dan Context Engineering. Selepas itu, Claude tidak lagi menjadi “pembantu yang berhalusinasi”, sebaliknya menjadi alat yang benar-benar boleh anda percayai untuk mengendalikan projek.

Pemeriksaan 2: Ikuti Senario Seperti Pengguna Sebenar#

Demo AI sentiasa mengikut laluan yang lancar: data betul, satu klik, semuanya berjalan lancar. Pengguna sebenar tidak berkelakuan begitu. Mereka membuat kesilapan, mengklik perkara yang salah atau memasukkan emoji dalam medan telefon. Tugas anda ialah menggunakan projek seperti yang akan digunakan oleh mereka.

1. Lengkapkan senario utama dari mula hingga selesai

   Lakukan perkara yang menjadi tujuan projek itu: daftar, buat pesanan, hantar permintaan. Teruskan hingga selesai, bukan setakat separuh jalan.

2. Periksa pembayaran secara berasingan dan dalam keadaan sebenar

   Jika projek menerima wang, buat pembayaran sendiri untuk jumlah minimum dalam mod ujian. Pastikan pesanan dicipta, status berubah dan e-mel dihantar kepada anda serta pelanggan. Pembayaran yang “berjaya” tetapi tidak mencipta pesanan ialah kegagalan senyap yang klasik.

3. Sengaja cuba merosakkan keadaan

   Biarkan medan kosong. Masukkan huruf pada medan yang memerlukan nombor. Klik “Hantar” dua kali berturut-turut. Muat naik fail dalam format yang salah. Projek yang baik akan memberitahu dengan sopan bahawa “anda tidak boleh berbuat demikian”; projek yang buruk akan ranap atau membuang data secara senyap.

4. Buka projek pada telefon

   Separuh daripada pengguna anda akan datang melalui telefon. Periksa sama ada susun atur masih elok dan butang yang sama berfungsi.

Berikan semua penemuan anda kepada AI dalam satu senarai: “Inilah perkara yang gagal dalam langkah-langkah ini; baikinya dan terangkan sebabnya.” Jangan uruskan satu masalah pada satu masa—berikan keseluruhan senarai supaya AI dapat melihat gambaran penuh dan kurang berkemungkinan merosakkan sesuatu semasa membaiki perkara lain.

Pemeriksaan 3: Tanya AI Tentang Keselamatan—Ini Promptnya#

Butang yang rosak jelas kelihatan serta-merta. Kelemahan keselamatan tidak begitu: projek terus berfungsi seolah-olah tiada apa-apa yang salah sehingga seseorang mengambil kesempatan daripadanya. Masalah paling lazim dalam projek vibe coding ialah kunci rahsia yang ditulis terus dalam kod, pangkalan data yang terdedah kepada internet dan borang yang membolehkan seseorang menghantar input berniat jahat. AI boleh menemui semua ini jika anda bertanya secara langsung.

Audit projek ini untuk mencari isu keselamatan dan terangkan setiap penemuan dengan bahasa yang mudah, tanpa jargon. Semak senarai ini:

Periksa sama ada terdapat kunci rahsia, kata laluan atau token yang ditulis terus dalam kod. Rahsia peribadi mesti digunakan pada pelayan sahaja, dengan konfigurasi rahsia setempat seperti .env dikecualikan daripada Git. Fail .env dan .gitignore tidak menghalang pemboleh ubah frontend/public daripada masuk ke binaan pelayar. Periksa JavaScript, source map, HTML dan respons rangkaian sebenar yang dihantar kepada klien, serta sahkan kunci peribadi tiada.

Periksa sama ada pangkalan data terdedah kepada internet dan siapa yang mempunyai akses kepadanya.

Periksa sama ada input boleh merosakkan borang: suntikan ke dalam pertanyaan pangkalan data atau kod tambahan dalam medan teks.

Apa yang akan berlaku jika pengguna menghantar data berniat jahat?

Periksa sama ada mana-mana halaman dalaman atau panel pentadbir terdedah tanpa kata laluan.

Bagi setiap perkara, nyatakan sama ada terdapat masalah, berikan contoh risiko yang jelas dan terangkan cara membaikinya. Mulakan dengan isu yang paling berbahaya.

Periksa juga sama ada projek anda mengikut sahaja apa-apa yang diterima dari luar. Ini dipanggil suntikan prompt tidak langsung: arahan disembunyikan dalam e-mel, komen atau fail orang lain, lalu ejen AI anda mengikutinya kerana menyangkakannya sebagai tugasan. Jika projek membaca data luaran dan bertindak berdasarkan data itu, tanya AI apa yang akan berlaku jika data tersebut mengandungi arahan tersembunyi.

Ini topik yang mendalam, dan satu prompt tidak dapat merangkuminya sepenuhnya. Jika projek mengendalikan wang atau data peribadi pelanggan, baca panduan berasingan tentang keselamatan vibe coding.

Pemeriksaan 4: Adakah AI Mereka-reka Pustaka atau Data?#

AI menulis dengan yakin tentang perkara yang tidak wujud. Ia mungkin menambah pustaka dengan nama yang munasabah tetapi sebenarnya tidak wujud. Ia mungkin meninggalkan pemegang tempat ujian dalam projek: produk bernama “Contoh”, alamat e-mel example@example.com atau teks pengisi sebagai ganti kandungan sebenar. Perkara ini mudah terlepas pandang dalam demo, tetapi memalukan atau menyebabkan masalah kepada pengguna sebenar.

Anda boleh mengesannya dalam dua langkah. Pertama, tanya secara langsung:

Semak projek ini dengan teliti dan jujur:

Adakah semua alat luaran dan pustaka yang anda tambah benar-benar wujud dan boleh dipasang dengan betul? Adakah anda mereka-reka sesuatu?

Adakah masih terdapat pemegang tempat ujian, contoh atau teks pengisi sebagai ganti data sebenar?

Adakah semua pautan, alamat dan butiran hubungan dalam projek ini benar, bukannya pemegang tempat?

Senaraikan perkara yang anda temui dan cadangkan perkara untuk menggantikannya.

Kedua, jalankan sahaja projek itu dan lihat-lihat kandungannya. Pustaka rekaan hampir selalu menyebabkan ralat semasa pelancaran. Pemegang tempat pula mudah dikenal pasti: jika halaman menyatakan “Produk 1”, anda belum menggantikannya.

Pustaka rekaan membawa bahaya tersendiri kerana penyerang sengaja mendaftarkan alat dengan nama yang digemari AI untuk direka-reka. Pasang salah satu daripadanya, dan kod orang lain akan masuk ke dalam projek anda. Sebab itulah anda patut mengambil serius soalan “adakah pustaka ini benar-benar wujud?”—soalan itu berkait langsung dengan keselamatan projek anda.

Pemeriksaan 5: Minta Model Kedua Memeriksa Model Pertama#

AI mempunyai sifat yang tidak menyenangkan: ia bersetuju. Tanya “adakah semuanya baik-baik sahaja di sini?” dan AI akan mengesahkan bahawa semuanya baik kerana ia menyesuaikan diri dengan jawapan yang dijangkakannya. Ini dipanggil sikap mengampu AI, dan saya menulis tentangnya secara berasingan. Rakan berbual seperti itu tidak akan tegas terhadap hasil kerjanya sendiri.

Penyelesaiannya mudah: dapatkan pendapat kedua. Buka sesi baharu atau gunakan model lain dan berikan projek untuk diperiksa menggunakan prompt yang sama seperti dalam Pemeriksaan 3, dengan tambahan: “AI lain menulis kod ini; cari kelemahannya.” Model baharu tidak terikat dengan perbualan sebelumnya dan lebih cenderung menunjukkan masalah.

1. Buka sesi baharu atau gunakan model lain

   Gunakan model kedua, atau model yang sama dalam tetingkap baharu tanpa sejarah tugasan.

2. Berikan projek dan arahan yang sesuai

   Katakan dengan jelas: “AI lain menulis kod ini; tugas anda ialah mencari ralat dan risiko, bukan memujinya.” Ini mengurangkan sikap mengampu.

3. Bandingkan kedua-dua pendapat

   Jika kedua-duanya bersetuju, mungkin mereka betul. Jika tidak sependapat, siasat perkara itu—di situlah perkara menarik bermula.

Inilah yang sedang berlaku dalam industri: AI menulis, AI memeriksa dan keputusan akhir kekal pada manusia. Anda tidak boleh menyerahkan keputusan itu kepada model—itu tugas anda.

Pemeriksaan 6: Bagaimana Anda Boleh Membatalkan Perubahan Jika Sesuatu Rosak?#

Pemeriksaan dalam senarai ini selalunya membawa kepada pengeditan, dan pengeditan kadangkala merosakkan perkara yang sebelum ini berfungsi. Untuk mengelakkan keadaan itu daripada menjadi bencana, simpan versi yang berfungsi dalam git sebelum setiap pusingan pembaikan. Ia seperti menyimpan permainan: jika anda merosakkan sesuatu, muatkan titik simpanan terakhir.

Anda tidak perlu membaca kod untuk melakukannya. Cuma minta AI: “Simpan versi semasa yang berfungsi dalam git dengan label yang jelas sebelum mengubah apa-apa.” Dan jika semuanya menjadi kacau selepas pengeditan: “Pulihkan projek kepada versi yang disimpan sebelum ini.”

Jika git masih asing bagi anda, saya ada dua panduan: cara membatalkan perubahan dalam Claude Code dan apa yang perlu dilakukan jika AI memadam pangkalan data anda. Panduan kedua adalah untuk keadaan apabila sudah terlambat untuk membuat pembatalan, tetapi anda masih boleh memulihkan data.

Pemeriksaan 7: Apakah yang Perlu Diperiksa Buat Kali Terakhir Sebelum Menerbitkan?#

Enam pemeriksaan pertama adalah tentang perkara yang dilakukan oleh kod. Pemeriksaan ketujuh pula tentang sama ada projek sedia menemui orang ramai. Di sinilah orang paling kerap tersilap: projek berfungsi tetapi mereka terlupa menukar pembayaran daripada kunci ujian kepada kunci langsung, lalu pelanggan pertama membayar “secara pura-pura”.

1. Pembayaran: daripada ujian kepada langsung

   Jika anda menerima pembayaran, pastikan kunci langsung sistem pembayaran disambungkan, bukannya kunci ujian. Buat satu pembayaran sebenar pada jumlah minimum dan bayarnya semula kepada diri sendiri.

2. Rahsia berada di tempat yang sepatutnya

   Tanya AI: “Adakah kunci peribadi digunakan pada pelayan sahaja, dengan .env dikecualikan daripada Git? Adakah binaan pelayar sebenar atau respons klien mengandungi kunci peribadi, termasuk melalui pemboleh ubah frontend/public atau source map?” Periksa fail binaan dan respons rangkaian pelayar, bukan fail sumber .env sahaja. Pengecualian Git tidak menghalang nilai daripada masuk ke bundle frontend.

3. Sandarkan data

   Pastikan pangkalan data disimpan secara automatik di suatu tempat. Jika projek anda berjalan pada pelayan sendiri, saya menerangkan perkara yang perlu dilakukan untuk penerbitan dalam panduan Coolify.

4. Penerbitan berfungsi di luar peranti anda sendiri

   Buka projek pada telefon menggunakan pautan luaran, bukan hanya pada komputer sendiri. Sesuatu yang berfungsi secara setempat tidak semestinya berfungsi selepas diterbitkan.

Semak keempat-empat perkara ini dan anda boleh menunjukkan projek kepada orang ramai dengan tenang. Jika ada sesuatu yang tidak betul, lebih baik luangkan setengah jam sekarang daripada berdepan dengan pelanggan yang tidak berpuas hati kemudian.

Bagaimana Jika Pemeriksaan Mengambil Masa Terlalu Lama—Patutkah Anda Percaya Sahaja kepada AI?#

Saya faham godaan itu. Pemeriksaan terasa membosankan dan “bukan sebab itu saya mendapatkan AI”. Tetapi anda, bukannya model, yang bertanggungjawab atas hasilnya. AI tidak mempunyai reputasi dan tidak menghadapi akibat: ia menghasilkan kod lalu melupakannya. Anda yang perlu menjawab kepada pelanggan yang pembayarannya tidak berjaya.

Pencipta Claude Code melihat perkara ini dengan lebih luas lagi:

Menulis kod bukan lagi halangan utama—AI telah menguruskannya. Nilai kini terletak di tempat lain: memahami tugasan dan memeriksa hasil yang diperoleh. Itulah kekuatan anda—anda lebih tahu daripada mana-mana pembangun luar tentang hasil yang patut diterima oleh pelanggan anda.

Mengapa Pemeriksaan Ialah Kemahiran, Bukannya Tugasan Sekali Sahaja?#

Tujuh pemeriksaan ini ialah tahap minimum yang membezakan “saya melancarkannya dan berharap ia berfungsi” daripada “saya melancarkannya dan tahu ia berfungsi”. Lakukan pemeriksaan ini sekali dan anda sudah dapat mengesan kebanyakan kejutan sebelum pelanggan mengalaminya.

Selepas itu, ia menjadi kebiasaan. Berikan konteks yang betul kepada AI sebagai input dan periksa hasilnya sebagai output; setiap projek baharu akan siap lebih cepat kerana anda tidak bermula dari awal.

Cari bahan tambahan tentang penggunaan alat dalam dokumentasi Ailoot.