Saya membina produk dengan AI—cara menambah baik tanpa merosakkan perkara yang berfungsi

Ketahui lebih lanjut tentang bekerja dengan model dalam dokumentasi Ailoot.

Mengapa kerja yang paling mahal bermula selepas pelancaran?#

Anda membina aplikasi pada suatu petang, menerbitkan pautan dan menghantarnya kepada rakan-rakan. Ia berfungsi. Kemudian seminggu selepas itu, orang sebenar pertama datang, mengklik sesuatu dengan cara yang salah, lalu separuh ciri berhenti berfungsi. Anda meminta Claude membaikinya—ia membaiki satu perkara dan merosakkan perkara lain. Kedengaran biasa?

Di sinilah timbul soalan utama: apa yang perlu dilakukan selepas melancarkan produk, apabila keterujaan daripada prototaip berfungsi yang pertama sudah berlalu dan anda masih perlu menyelenggarakannya? Anda boleh menggelarnya vibe coding untuk orang dewasa. Pembinaan membawa keterujaan dan kepantasan. Penyelenggaraan memerlukan fikiran yang tenang: anda memahami perkara yang sedang diubah dan memastikan semuanya terkawal. Kebanyakan orang gagal dalam bahagian kedua ini kerana tiada siapa yang mempersiapkan mereka untuknya.

Satu kajian industri menganalisis lebih daripada sejuta perubahan kod daripada 2,444 pasukan dan mengira ke mana wang yang dibelanjakan untuk pembangunan AI sebenarnya pergi. Inilah gambaran keseluruhannya:

Panduan “Kos tersembunyi vibe coding” menerangkan angka ini dengan lebih terperinci. Di sana, persoalannya ialah apa yang anda bayar. Di sini, persoalannya berbeza: 44 sen daripada setiap dolar digunakan untuk membaiki pepijat—dan keseluruhan artikel ini membincangkan cara menghalang bahagian itu daripada bertambah. Kerja untuk mengawalnya dipanggil penyelenggaraan.

Perbezaan antara seseorang yang melakukan vibe coding untuk orang dewasa dengan seseorang yang sekadar mengasuh rangkaian neural terserlah selepas pelancaran. Pangkalan kod orang pertama berkembang, mereka membuat penambahbaikan dan tiada apa-apa yang rosak. Sebulan kemudian, produk orang kedua menjadi seperti alat yang bocor dan mereka takut untuk menyentuhnya. Seterusnya, saya akan menerangkan cara untuk berada dalam kumpulan pertama.

Perkara yang benar-benar rosak: 5 bencana selepas pelancaran#

Ini ialah bedah siasat awam bagi produk sebenar yang dibina dengan AI, lengkap dengan angka dan tarikh. Anggaplah ia sebagai peta medan periuk api—setiap periuk api sudah meletup untuk seseorang, dan cara mengelakkannya sudah diketahui.

Kelima-lima kes mempunyai punca utama yang sama. Secara lalai, AI memastikan sesuatu berfungsi sekarang, bukannya dengan selamat sebulan kemudian di bawah beban. Anda tidak dapat melihat perbezaannya semasa membangunkan produk pada komputer sendiri. Perbezaan itu menjadi jelas apabila orang asing pertama yang berniat jahat muncul.

Masalahnya bukan kerana kod tidak ditulis sendiri—ramai orang bekerja dengan cara ini. Masalahnya ialah tidak bertanya, “Adakah pangkalan data ini selamat?” Seterusnya, saya akan tunjukkan prompt yang menanyakan soalan itu untuk anda.

Jaring keselamatan pertama ialah git dan kembali kepada “keadaan semalam”#

Apabila Claude merosakkan sesuatu, anda memerlukan butang “kembalikan seperti semalam”. Dari segi teknikal, butang itu dipanggil git, dan ia lebih mudah daripada yang disangka.

Tiga istilah yang perlu difahami oleh bukan pengatur cara:

1. Repositori — folder projek anda yang disimpan di awan (biasanya di GitHub). Salinan semua kod anda yang tidak hanya berada dalam komputer anda.
2. Commit — titik untuk kembali. Pada asasnya, anda memberitahu kod, “simpan dalam keadaan ini”. Setiap commit ialah penanda yang boleh anda kembali kepadanya.
3. Deploy — pemindahan. Kod itu berada secara setempat pada komputer anda dan hanya berfungsi untuk anda. Deploy menghantarnya ke pelayan luaran supaya ia berfungsi untuk semua orang.

Selagi anda mempunyai titik kembali yang terkini, anda boleh mengundurkan sebarang kerosakan dengan satu ayat. Secara harfiah.

Saya telah merosakkan sesuatu—semuanya berfungsi semalam, tetapi hari ini tidak. Cari commit terkini yang semuanya masih baik, tunjukkan apa yang telah berubah sejak itu, dan undurkan projek kepada keadaan tersebut.

Dua peraturan yang perlu dilaksanakan segera, sebelum orang lain melihat produk:

• Repositori mestilah peribadi. Bukan awam. Jika tidak, sesiapa sahaja boleh membaca kod anda dan segala kandungannya.
• Masukkan fail rahsia dalam senarai pengecualian. Kunci, kata laluan dan kelayakan akses pangkalan data disimpan dalam fail berasingan (biasanya .env), dan fail itu tidak boleh dimasukkan ke dalam repositori. Tambahkan satu baris untuk .env dalam .gitignore, dan rahsia itu kekal dengan anda.

Terdapat panduan berasingan tentang cara mengundurkan perubahan dengan selamat dalam Claude Code: Cara mengundurkan perubahan dalam Claude Code. Tanpa titik kembali, anda berjalan di atas tali tanpa jaring keselamatan dan lambat laun anda akan jatuh.

Apakah yang diundurkan oleh /rewind, dan apakah yang tidak?#

Claude Code mengambil syot kilat keadaan sebelum setiap perubahan yang dibuatnya. Arahan /rewind (atau menekan Esc dua kali) mengundurkan kedua-dua fail dan perbualan kepada titik yang dipilih. Ia berguna: jika anda merosakkan ciri lima minit yang lalu, anda boleh kembali lima minit ke belakang.

Namun, terdapat perangkap yang menyebabkan pemula kehilangan data. /rewind tidak mengundurkan semuanya:

Anthropic sendiri menjelaskannya dengan terus terang: syot kilat ialah butang “buat asal” setempat, manakala git ialah sejarah kekal. Syot kilat melengkapi kawalan versi, tetapi tidak menggantikannya.

Kesimpulan praktikal untuk bukan pengatur cara: /rewind akan menyelamatkan anda daripada keadaan “Claude baru sahaja merosakkan satu ciri”. Tetapi jika ia sempat memadamkan satu baris pangkalan data atau memuat naik kod ke awan, hanya git dan sandaran pangkalan data boleh mengembalikannya. Jadi, kekalkan kedua-dua lapisan: syot kilat untuk unduran pantas, commit untuk sejarah kekal projek.

Bagaimanakah anda menambah baik tanpa merosakkan perkara yang sudah berfungsi?#

Setiap orang kedua terperangkap dalam kitaran ini. Anda meminta AI membaiki pepijat kecil. Ia mencadangkan perubahan yang munasabah. Perubahan itu merosakkan perkara lain. Anda memintanya membaiki masalah baharu itu, lalu dua lagi masalah muncul. Begitulah seterusnya.

Kitaran itu berlaku kerana vibe coding bersifat tidak deterministik. Prompt yang sama memberikan kod yang berbeza setiap kali. Oleh itu, setiap suntingan boleh mengubah logik sekeliling secara senyap: ambang diskaun berubah daripada 10 kepada 12 peratus, atau tingkah laku peraturan pengesahan berubah—tanpa pemeriksaan daripada anda dan tanpa sebarang amaran. Ini dipanggil hanyutan logik, dan ia merosakkan secara senyap perkara yang tepat menjana wang: harga, akses dan pembayaran.

Ada satu peraturan untuk mencegah hanyutan, dan peraturan ini cukup mudah untuk digantung di dinding: jangan membuat commit terhadap kod yang tidak dapat anda terangkan kepada orang lain, perkataan demi perkataan.

Dalam amalan, peraturan ini menjadi panduan sedia guna sebelum sebarang perubahan pada kod yang berfungsi. Ia memastikan AI mengambil langkah kecil dan menunjukkan dengan tepat apa yang berubah.

Sebelum mengubah kod, lakukan perkara berikut:

Simpan keadaan semasa yang berfungsi sebagai titik kembali berasingan (commit).

Terangkan dengan tepat apa yang anda rancang untuk ubah dan dalam fail yang mana.

Buat perubahan sekecil mungkin—hanya perkara yang menyelesaikan tugasan saya, tiada yang lain.

Tunjukkan apa yang berubah dan terangkan setiap perubahan supaya saya boleh menjelaskannya kepada orang lain.
Jangan sentuh logik harga, akses atau pembayaran melainkan saya memintanya.

Satu lagi prinsip yang menjimatkan masa berminggu-minggu ialah disiplin menetapkan sempadan tugasan. Satu masalah, satu perubahan, pelaksanaan pantas. Jangan minta AI menulis semula separuh projek dalam satu prompt. Kadangkala pembangun profesional mula membina Uber sepenuhnya sedangkan mereka hanya memerlukan satu butang—lalu kerja itu berlarutan berbulan-bulan. Anda tidak memerlukannya.

Segala yang saya terangkan bergantung pada satu perkara: pengurusan konteks. Untuk menghalang AI daripada merosakkan logik yang berdekatan, AI perlu mengingati peraturan projek anda.

Bagaimanakah anda menyemak perubahan sebelum menerbitkannya?#

Di antara “ia berfungsi pada komputer saya” dan “ia berfungsi untuk semua orang” terdapat satu langkah perantaraan yang sering dilewati pemula: salinan ujian. Ini ialah syot kilat berasingan bagi persekitaran produksi anda untuk menyemak perubahan sebelum orang sebenar melihatnya. Kitaran kerja kelihatan seperti berikut:

1. Bina dan semak perubahan sendiri (pembangunan).
2. Deploy ke staging—salinan produksi, tetapi tanpa pengguna sebenar.
3. Jalankan senario utama dan pastikan tiada apa-apa yang berubah.
4. Hanya selepas itu, deploy ke produksi.

Mengapa perkara ini penting selepas pelancaran: setiap keluaran membawa risiko. Perubahan kecil pada kod boleh menghalang log masuk akaun. Satu tetapan yang tertinggal boleh menjatuhkan seluruh produk. Staging mengesan masalah ini tanpa akibat; dalam produksi, anda kehilangan pelanggan.

Untuk mengelakkan pemeriksaan semuanya secara manual setiap kali, berikan prompt kepada AI supaya membandingkan tingkah laku versi baharu dengan versi lama dalam bahagian kritikal.

Saya akan deploy satu perubahan. Jalankan senario utama produk mengikut urutan dan semak bahawa setiap satunya masih berfungsi seperti dahulu:

Pendaftaran dan log masuk pengguna baharu.

Pembayaran dan akses diberikan selepas pembayaran.

Hak akses—pengguna biasa tidak boleh melihat data orang lain atau bahagian pentadbir.

Angka utama logik perniagaan (harga, diskaun, had) tidak berubah.
Jika apa-apa berkelakuan berbeza daripada versi sebelumnya, berhenti dan tunjukkan dengan tepat apa yang berubah.

Di manakah rahsia anda? Lubang terbesar bagi pemula#

Saya akan menerangkan perangkap terbesar ini dengan terperinci kerana ia menjejaskan lebih banyak produk berbanding perkara lain. Apabila AI menulis kod, cara paling mudah ialah meletakkan kunci di tempat yang akan terus berfungsi—terus dalam kod halaman yang dibuka pada pelayar. Anda tidak akan menyedari perbezaannya semasa pembangunan. Tetapi sesiapa sahaja boleh membaca apa-apa yang sampai ke pelayar dengan membuka alat pembangun.

Pengasas yang pelanggannya dikenakan caj $87,500 berkata kemudian bahawa satu prompt sahaja boleh mencegahnya. Caj itu akhirnya dibatalkan, tetapi yuran yang tidak boleh dikembalikan dan ketenangan yang hilang kekal. Inilah prompt tersebut.

Semak keseluruhan projek dan pastikan tiada kunci rahsia yang masuk ke dalam pelayar:

Cari semua kunci pangkalan data, sistem pembayaran dan perkhidmatan luaran.

Pastikan setiap kunci disimpan hanya pada pelayan, dalam pemboleh ubah persekitaran, dan bukan dalam kod halaman.

Semak sejarah projek—adakah mana-mana kunci pernah masuk ke dalamnya secara tidak sengaja?
Tunjukkan senarai setiap tempat anda menemui rahsia dan perkara yang perlu dilakukan untuk setiap satunya.

Perangkap seterusnya yang berdekatan ialah menyemak hak akses hanya pada bahagian pelayar. Jika produk anda menentukan sama ada hendak “menunjukkan bahagian pentadbir” dalam kod halaman, sesiapa sahaja boleh memintas keputusan itu. Hak akses mesti sentiasa disemak pada pelayan. Pangkalan data hanya patut memulangkan data kepada mereka yang berhak menerimanya—itulah kegunaan keselamatan peringkat baris (RLS), yang perlu didayakan pada setiap jadual.

Sebelum menjual akses atau membenarkan orang lain masuk, jalankan audit keselamatan umum terhadap produk.

Teliti projek seperti penyerang dan cari kelemahan keselamatan:

Adakah mana-mana kunci rahsia disimpan dalam kod yang dihantar ke pelayar atau dalam sejarah projek?

Adakah keselamatan peringkat baris (RLS) didayakan pada setiap jadual pangkalan data, dan adakah hak akses disemak pada pelayan dan bukannya pada pelayar sahaja?

Adakah sandaran pangkalan data automatik telah dikonfigurasikan, dan pernahkah saya menyemak bahawa saya boleh memulihkannya?

Adakah pangkalan data produksi diasingkan daripada persekitaran tempat ejen AI dijalankan?
Bagi setiap perkara, beritahu saya sama ada semuanya baik atau perkara tepat yang perlu dibaiki.

Terdapat panduan lengkap berasingan tentang keselamatan produk yang dibina dengan vibe coding: Cara melindungi aplikasi yang dibina dengan vibe coding. Peraturannya mudah: anggap apa-apa yang dilakukan AI secara lalai sebagai tidak selamat sehingga anda menyemaknya.

Di mana hendak mengehoskan produk anda: tangga pengehosan#

Anda tidak perlu terus menyewa pelayan sendiri dan mengkonfigurasikannya secara manual—pada peringkat awal, itu tugas yang rumit dan akan menghabiskan masa anda. Anda boleh menaiki tangga ini apabila produk berkembang:

1. Pengehosan percuma (contohnya, Vercel)—untuk diri sendiri, ujian dan projek kecil. Ia sesuai jika platform tersedia kepada khalayak anda dan anda tidak menyimpan data peribadi orang lain.
2. Platform dengan deploy satu arahan (Railway)—apabila anda mempunyai bahagian backend dan pangkalan data. Anda deploy dengan satu arahan dan tidak perlu mengkonfigurasi pelayan. Halangan untuk bermula adalah minimum.
3. Pelayan khusus milik sendiri—apabila beban tinggi dan anda memerlukan kawalan penuh. Beralih kepadanya kemudian, apabila anda mencapai had platform.

Bagi bukan pengatur cara yang baru melancarkan produk, pilihan paling mudah ialah platform dengan deploy satu arahan tanpa konfigurasi pelayan secara manual. Beralih ke pelayan sendiri kemudian. Jika anda mahu mengikuti laluan ini dengan contoh khusus, lihat panduan tentang deploy projek yang dibina dengan vibe coding ke pelayan sendiri menggunakan Coolify.

Bilakah aplikasi, pangkalan data dan sandaran perlu diasingkan?#

Tiga perkara tidak sepatutnya disimpan dalam satu bakul: aplikasi, pangkalan data dan sandaran. Apabila pengguna masih sedikit, semuanya boleh berada bersama, dan itu tidak mengapa. Namun terdapat petunjuk jelas bila tiba masanya untuk mengasingkannya.

• Letakkan aplikasi dan pangkalan data pada mesin yang berbeza. Petunjuknya: semasa beban puncak, CPU dan memori kekal melebihi 70–80 peratus, permintaan menjadi perlahan, dan aplikasi serta pangkalan data berebut sumber yang sama. Selepas diasingkan, anda boleh memperkukuh pangkalan data tanpa menyentuh aplikasi, dan sebaliknya.
• Ikuti peraturan sandaran 3-2-1. Tiga salinan data, pada dua jenis media yang berbeza, dengan satu di luar lokasi. Ini melindungi daripada kegagalan perkakasan dan perisian tebusan. Perkara penting ialah sandaran mesti dilakukan secara automatik.

Kekerapan sandaran bergantung pada betapa besar kerugian akibat kehilangan data selama beberapa jam. Bagi perkhidmatan langganan dalam talian yang tidak boleh menerima kehilangan sejam rekod pembayaran, selang sandaran mesti kurang daripada sejam, atau gunakan log transaksi dan pemulihan titik masa (PITR) yang disahkan. Pilih selang berdasarkan kehilangan data maksimum boleh diterima, dan uji secara berasingan masa yang diperlukan untuk memulihkan perkhidmatan. Satu sandaran sehari memadai untuk blog. Logiknya mudah: tentukan jumlah data yang sanggup anda hilang dan konfigurasikan sandaran sewajarnya.

Bantu saya memutuskan sama ada sudah tiba masanya untuk memindahkan produk saya kepada infrastruktur yang lebih mantap. Semak dan tanya saya tentang setiap perkara:

Sejauh manakah penggunaan CPU dan memori ketika beban puncak—adakah penggunaan kekal melebihi 70–80 peratus atau tidak?

Adakah pangkalan data dan aplikasi berada pada mesin yang sama atau mesin yang berbeza?

Adakah sandaran pangkalan data automatik telah dikonfigurasikan, dan adakah saya pernah menguji pemulihan daripadanya?

Adakah terdapat salinan persekitaran yang berasingan (staging) untuk membuat semakan sebelum deploy?
Berdasarkan hasilnya, berikan cadangan yang jelas: perkara yang patut dikekalkan, perkara yang perlu diasingkan dahulu dan sebabnya.

Ada satu lagi persoalan: pangkalan data terurus atau milik sendiri. Untuk pasukan kecil, pangkalan data terurus hampir selalu lebih baik: pangkalan data sendiri lebih murah dari segi perkakasan, tetapi memakan masa berjam-jam untuk diselenggara. Jika anda menguruskan semuanya sendiri dan produk anda bukan infrastruktur, masa itu lebih mahal daripada perbezaan harga pelayan.

Bagaimanakah penyelenggaraan boleh berjalan secara automatik?#

Penyelenggaraan manual meletihkan. Anda boleh menguruskannya dengan dua cara: pemantauan dan ejen rondaan.

Pemantauan menggunakan dua alat berbeza untuk dua tugas berbeza:

1. “Adakah laman web beroperasi?”—pemantau masa operasi (contohnya, UptimeRobot). Alat ini menghubungi produk setiap beberapa minit dan menghantar amaran jika produk terhenti. Terdapat pelan percuma.
2. “Apa sebenarnya yang rosak?”—penjejak ralat (contohnya, Sentry). Alat ini mengumpulkan ralat dalam aplikasi dan menunjukkan tempat serta sebab sesuatu gagal.

Alat pertama mengesan bahawa produk terhenti. Alat kedua menunjukkan ciri yang gagal dan sebabnya. Kedua-duanya bersama-sama menjawab soalan, “Adakah saya akan mengetahui kegagalan sebelum pelanggan menulis kepada sokongan?”

Tahap kedua automasi ialah ejen rondaan. Bayangkan sebuah agensi hartanah: pada pukul tujuh pagi, ejen AI membaca pertanyaan di laman web, mendapati borang tempahan rosak, mencari puncanya dalam kod dan membawa pembaikan sedia guna berserta penjelasan. Anda menyemaknya dan berkata “ya”—pembaikan itu dilaksanakan. Urutannya penting: selesaikan masalah pengguna dahulu (berikan akses, minta maaf), kemudian siasat punca dan soal wang.

Satu lagi peraturan tentang akses AI kepada pangkalan data produksi: berikan AI akaun baca sahaja dan sembunyikan data peribadi di sebalik lapisan perantara supaya ejen melihat “nama” dan bukannya nama sebenar seseorang. Dengan itu, walaupun ejen melakukan kesilapan, ia tidak akan dapat memadam atau merosakkan data produksi secara fizikal. Insiden dalam jadual di atas, apabila ejen memadamkan pangkalan data produksi, berkaitan tepat dengan ketiadaan sekatan ini. Panduan Perkara yang perlu dilakukan jika AI memadamkan pangkalan data anda menerangkan apa yang perlu dilakukan jika bencana sudah berlaku.

Bilakah tiba masanya untuk menutup produk?#

Bahagian penyelenggaraan yang paling dipandang ringan ialah mengetahui bila perlu berhenti menyelenggara. Sesiapa yang banyak membina produk mempunyai kubur projek: bina satu, usik seketika, kemudian tinggalkannya. Itu perkara biasa dan bukan kegagalan. Kegagalan ialah membiarkan sesuatu yang tiada sesiapa gunakan berlarutan selama berbulan-bulan kerana kesal dengan masa yang telah dilaburkan.

Ambang yang boleh digunakan untuk membuat keputusan:

1. Dua minggu—cukup untuk melihat sama ada sesuatu idea berkesan. Jika pengguna sebenar yang pertama kembali, teruskan. Kesunyian ialah jawapan.
2. Tiga bulan—had maksimum yang tegas. Jika produk itu belum mendapat sambutan dalam tiga bulan, tutupnya. Dengan kepantasan vibe coding, enam bulan untuk menguji satu idea terlalu lama.

Menutup projek memang sukar dari segi psikologi, jadi anggaplah ia sebagai keputusan, bukan perasaan. Melepaskan projek yang telah anda laburkan usaha adalah seperti memecat pekerja yang tidak mampu menjalankan tugas: tidak menyenangkan, tetapi mengekalkannya lebih mahal daripada melepaskannya.

Penyelenggaraan ialah kerja yang dilakukan untuk memastikan produk terus hidup dan berguna kepada orang ramai. Segala-galanya yang lain—git, sandaran, pemantauan—hanyalah alat yang membantu anda mencapai tahap apabila produk mula berfungsi untuk anda setiap hari.

Membina produk dengan AI dalam satu petang ialah separuh daripada kerja. Memastikannya terus hidup dan selamat semasa ia berkembang—itulah maksud vibe coding untuk orang dewasa.

Untuk langkah seterusnya—Ailoot.