“Bina satu aplikasi untuk saya.” Arahan itu pendek. Tetapi di belakang satu skrin yang cantik, ada soalan yang jauh lebih panjang: siapa boleh melihat data, apa berlaku apabila simpan gagal dan adakah rekod masih ada selepas halaman ditutup?
Inilah bahagian bina aplikasi dengan AI yang saya mahu pembaca fahami. Artikel ini menggunakan simulasi projek pengurus tugasan sebagai penerangan. Ia bukan jurnal eksperimen baharu atau dakwaan bahawa saya sudah menguji serta melancarkan aplikasi contoh ini. Sudutnya ialah proses dan bukti yang patut dikumpulkan sebelum berkata sesuatu aplikasi sudah siap.
Idea perlu ditukar kepada masalah yang khusus
“Saya mahu app produktiviti” belum cukup jelas. Untuk contoh ini, masalahnya ialah tindakan selepas mesyuarat hilang dalam nota. Pengguna mahu merekod tugas, pemilik dan tarikh, kemudian menandakan tugas selesai. Kita sengaja mengecilkan skop supaya aliran utama mudah diuji.
Tulis siapa pengguna, input yang diperlukan dan output yang dianggap betul. Jika aplikasi akan menerima nota AI, nyatakan sama ada ia hanya mencadangkan tindakan atau terus menyimpan rekod. Dua pilihan ini membawa risiko dan pengalaman penggunaan yang berbeza.
Rancang sebelum meminta kod
Sediakan senarai fungsi minimum: tambah tugas, lihat senarai, ubah tugas dan tandakan selesai. Tentukan medan wajib serta tindakan jika tarikh tidak diisi. Jangan meminta chat, laporan, pembayaran dan aplikasi telefon serentak pada versi pertama.
Pelan juga patut menyatakan perkara di luar skop. Contohnya, tugas belum dikongsi antara organisasi. Batas ini membantu AI membuat keputusan yang konsisten dan mengelakkan fungsi separuh siap yang sukar dibersihkan kemudian.
Rancang aplikasi tugasan selepas mesyuarat. Pengguna boleh tambah tajuk, pemilik dan tarikh, kemudian tanda selesai. Terangkan aliran, struktur data dan kriteria penerimaan dahulu. Senaraikan keputusan yang belum jelas. Jangan mula menulis kod sebelum skop diterangkan.
Prototaip boleh membantu, tetapi bukan bukti sistem siap
Prototaip menunjukkan bentuk skrin dan aliran. Ia boleh menggunakan data contoh yang dilabel dengan jelas. Anda boleh menilai sama ada butang mudah ditemui dan sama ada ruangan benar-benar diperlukan sebelum membina sambungan database.
Masalah berlaku apabila data contoh kelihatan seperti rekod sebenar. Menekan “simpan” mungkin hanya menambah item sementara dalam pelayar. Muat semula halaman untuk memeriksa tingkah laku, tetapi ingat ujian itu sahaja belum membuktikan keselamatan atau ketahanan sistem.
Minta perubahan kecil yang boleh disemak
Daripada menyuruh AI membina semua fungsi sekaligus, minta satu aliran dahulu. Terangkan apa yang sepatutnya berlaku dan bagaimana mengujinya. Semak perubahan sebelum bergerak ke fungsi seterusnya. Simpan versi yang berfungsi supaya anda mempunyai jalan kembali.
Apabila AI mencadangkan pakej atau servis, tanya sebabnya, kos dan alternatif. Jangan menerima komponen hanya kerana namanya popular. Setiap kebergantungan menambah perkara yang perlu difahami, dikemas kini dan dipulihkan apabila gagal.
Debugging: laporkan tingkah laku, bukan rasa kecewa
Arahan “app rosak, repair” terlalu luas. Laporan bug yang berguna mempunyai langkah menghasilkan masalah, hasil dijangka dan hasil sebenar. Sertakan mesej ralat yang relevan selepas membuang data sensitif. Ini membantu AI mencari punca tanpa mengubah bahagian lain secara rawak.
Contoh simulasi: “Tambah tugas tanpa tarikh. Dijangka rekod disimpan dengan tarikh kosong. Sebenarnya butang berputar tanpa henti dan tiada mesej.” Ini bukan bug yang ditemui dalam sistem sebenar di sini; ia contoh format laporan yang boleh digunakan.
Selepas pembetulan, ulang langkah yang sama dan satu aliran bersebelahan. Contohnya, uji tambah tugas dengan tarikh pula. Pembetulan yang menyelesaikan satu kes boleh menjejaskan kes lain jika peraturan data tidak difahami.
Database: fikir tentang pemilikan rekod
Data perlu mempunyai tempat simpan yang sesuai dan hubungan yang jelas. Untuk aplikasi contoh, setiap tugas mempunyai pemilik rekod. Jika terdapat pengguna berbeza, sistem perlu memeriksa hak akses pada bahagian pelayan, bukan sekadar menyembunyikan butang pada skrin.
Soalan penting: bolehkah pengguna A membuka atau mengubah rekod pengguna B melalui permintaan lain? Adakah rekod yang dipadam boleh dipulihkan? Apa berlaku jika dua orang menyunting pada masa hampir sama? Jawapannya mempengaruhi struktur dan ujian.
Jangan menampal kata laluan database atau kunci rahsia ke dalam kod yang dihantar kepada pelayar. Asingkan konfigurasi persekitaran dan gunakan data ujian. Jika anda belum memahami implikasi akses, dapatkan semakan sebelum mengendalikan data pelanggan.
Ujian patut mengikuti kerja pengguna
Aliran biasa
Cipta tugas, semak senarai, ubah pemilik, tandakan selesai dan buka semula halaman. Pastikan perubahan benar-benar disimpan. Semak status dan mesej supaya pengguna tahu sama ada tindakan berjaya atau masih diproses.
Input tidak sempurna
Cuba tajuk kosong, tajuk panjang, tarikh yang tidak munasabah dan klik berulang. Aplikasi patut memberikan maklum balas yang boleh difahami. Jangan biarkan mesej teknikal mentah menjadi satu-satunya panduan kepada beginner.
Kegagalan sambungan
Rancang cara sistem mengendalikan sambungan perlahan atau pelayan tidak tersedia. Pengguna perlu tahu jika rekod belum tersimpan. Butang yang kelihatan berjaya tetapi kehilangan data ialah masalah kepercayaan, bukan sekadar kecacatan visual.
Deployment: komputer sendiri dan internet berbeza
Aplikasi yang berjalan pada komputer pembangunan belum semestinya sedia digunakan orang lain. Persekitaran pelayan memerlukan konfigurasi, domain, sambungan database, log dan kaedah pemulihan. Kos operasi juga perlu disemak sebelum memberi akses kepada ramai pengguna.
Gunakan staging untuk ujian yang selamat sebelum perubahan ke sistem sebenar. Pastikan versi aplikasi sepadan dengan struktur data. Jika perubahan gagal, anda perlu tahu bagaimana kembali kepada versi yang berfungsi dan apa yang berlaku pada rekod yang sudah ditulis.
Apa sebenarnya berubah apabila AI menulis kod?
Lebih banyak masa boleh beralih kepada menerangkan keperluan, menyemak hasil dan membuat keputusan. Ini bukan bermakna pengetahuan teknikal hilang nilainya. Anda masih perlu menilai sama ada penyelesaian itu masuk akal dan boleh diselenggara.
Kajian tentang vibe coding menggambarkan kerja yang berulang antara arahan, penilaian dan pembetulan. Ia selari dengan prinsip praktikal: jangan memberi kepercayaan menyeluruh hanya kerana output pertama nampak baik. Bina keyakinan melalui bukti bagi setiap aliran.
FAQ: AI jadi programmer
Boleh bina app tanpa pengalaman coding?
Boleh meneroka prototaip, tetapi tahap bantuan dan pembelajaran meningkat apabila melibatkan data, akses pengguna serta operasi sebenar.
Kenapa AI membetulkan satu bug tetapi menghasilkan bug lain?
Ia mungkin tidak mempunyai konteks yang cukup atau perubahan menyentuh peraturan lain. Kecilkan skop dan ulang ujian berkaitan.
Perlukah belajar database?
Asas rekod, hubungan dan hak akses sangat membantu jika aplikasi menyimpan data. Anda perlu memahami siapa boleh membaca serta mengubahnya.
Apakah tanda aplikasi sudah boleh dicuba pengguna?
Aliran utama, keadaan gagal dan akses data sudah diuji, batas diketahui, serta bantuan dan pemulihan tersedia mengikut risiko projek.
Catat bukti, bukan sekadar screenshot
Untuk eksperimen anda, simpan skop, langkah ujian, bug dan keputusan selepas pembetulan. Itulah bahan yang menjadikan cerita pembangunan berguna kepada pembaca lain. Sambung bacaan dengan realiti membina aplikasi sendiri dan persoalan AI membina aplikasi dalam 24 jam.
Rujukan: panduan semakan kod GitHub dan kajian vibe coding oleh Sarkar dan Drosos. Contoh aplikasi dalam artikel ini ialah simulasi penerangan.
Jika mahu panduan belajar berstruktur, semak butiran BizBooking Lite dalam koleksi ebook. Pilih mengikut tahap dan prasyarat yang sesuai.
