Cara Membawa Prototaip AI ke Pengeluaran

Untuk membawa prototaip AI ke pengeluaran, anda merapatkan jurang antara "ia berfungsi apabila saya cuba" dan "ia terus berfungsi apabila orang lain menggunakannya". Dalam amalan, ini bermakna lima perkara: uji aliran utama setiap kali anda menukar sesuatu, kunci siapa yang boleh melihat dan menukar apa, pastikan anda mendapat tahu tentang ralat sebelum pengguna memberitahu anda, buat sandaran data dan buktikan anda boleh memulihkannya, dan pastikan aplikasi cukup pantas pada telefon. Tiada satu pun daripada ini memerlukan penulisan semula — ia ialah senarai semak yang anda laksanakan bersama AI yang sama yang membina prototaip itu.

Prototaip berbanding pengeluaran: apa yang sebenarnya berubah

Prototaip hanya mempunyai satu pengguna yang berhati-hati: anda. Anda tahu butang mana yang perlu ditekan, anda menaip input yang munasabah, dan jika sesuatu rosak, anda mengangkat bahu dan minta AI membetulkannya. Pengeluaran mempunyai ramai pengguna yang cuai, beberapa yang ingin tahu, dan sesekali seorang yang bermusuhan. Kod tidak perlu menjadi "perusahaan"; ia perlu mengendalikan situasi yang tidak pernah dihadapi oleh prototaip.

Baki panduan ini menerangkan setiap baris jadual ini.

Langkah 1: Bekukan skop dan tulis aliran utama

Sebelum anda mengukuhkan apa-apa, tentukan versi pertama itu. Senaraikan tiga hingga enam aliran yang paling penting — contohnya "daftar, cipta projek, jemput rakan sepasukan, bayar". Ini menjadi skrip ujian anda, sasaran pemantauan anda dan perkara yang anda semak selepas setiap perubahan.

Apa-apa yang tiada dalam senarai sama ada dipotong atau dilabelkan dengan jelas sebagai beta. Jauh lebih mudah untuk menjadikan empat aliran boleh dipercayai daripada empat belas.

Langkah 2: Uji seperti orang asing, kemudian jadikannya boleh diulang

Pembina AI pandai menghasilkan kod yang berfungsi pada laluan yang gembira. Masalah pengeluaran wujud pada laluan yang tidak gembira. Uji setiap aliran utama dengan:

• Input buruk: medan wajib yang kosong, nama 5,000 aksara, e-mel tanpa @, kuantiti negatif, tarikh pada masa lalu.
• Muat semula dan butang belakang: muat semula di tengah-tengah pembayaran; tekan belakang selepas menghantar borang. Adakah sesuatu dicipta dua kali?
• Dua tab, dua pengguna: log masuk dengan dua akaun berbeza dan cuba buka halaman satu sama lain dengan menukar ID dalam URL.
• Perlahan dan kecil: skrin bersaiz telefon dan sambungan yang dihadkan (alat pemaju pelayar boleh mensimulasikannya).
• Keadaan kosong: akaun baharu tanpa data. Prototaip selalunya dibina dengan data sampel dan kelihatan rosak tanpanya.

Kemudian jadikan semakan itu boleh diulang. Sekurang-kurangnya, simpan senarai semak bertulis dan jalankannya sebelum setiap keluaran. Lebih baik lagi, minta AI menulis ujian automatik hujung-ke-hujung untuk aliran yang paling penting:

Tambah ujian hujung-ke-hujung automatik untuk aliran ini: daftar dengan e-mel, cipta projek, jemput pengguna kedua, dan selesaikan pembayaran dalam mod ujian Stripe. Tambah juga ujian yang mengesahkan pengguna tidak boleh melihat atau mengedit projek pengguna lain dengan menukar URL.

Ujian yang membuktikan pengguna tidak boleh melakukan sesuatu ialah ujian yang paling kerap tiada dalam prototaip.

Langkah 3: Asas keselamatan yang sering diabaikan prototaip

Kebanyakan masalah keselamatan dalam aplikasi yang dibina dengan AI bukan perkara yang luar biasa. Ia ialah semakan yang tiada. Lalui senarai ini, dan lihat senarai semak keselamatan untuk aplikasi yang dibina dengan AI untuk versi yang lebih lengkap:

• Kebenaran di pelayan. Menyembunyikan butang bukanlah keselamatan. Setiap permintaan yang membaca atau menukar data mesti menyemak, di pelayan, bahawa pengguna yang log masuk dibenarkan berbuat demikian. Jika aplikasi anda menggunakan pangkalan data dengan peraturan peringkat baris, pastikan ia diaktifkan dan diuji.
• Rahsia keluar dari pelayar. Kunci API untuk pembayaran, e-mel atau penyedia AI perlu berada dalam pembolehubah persekitaran di pelayan, bukan dalam kod hadapan. Jika anda tidak pasti maksudnya, baca apa itu pembolehubah persekitaran dan rahsia.
• Pengesahan di pelayan. Pelayar boleh dipintas, jadi ulangi sebarang semakan yang penting di pelayan.
• Log masuk yang dilakukan dengan betul. Gunakan pustaka atau perkhidmatan auth yang telah diuji dengan baik dan bukannya menyimpan kata laluan secara manual. Panduan kami tentang menambah log masuk ke aplikasi anda meliputi pilihan yang ada.
• Had kadar pada log masuk, pendaftaran, tetapan semula kata laluan dan apa-apa yang menghantar e-mel atau memanggil API berbayar.
• Ralat yang mesra. Pengguna sepatutnya melihat "sesuatu tidak kena"; butiran pergi ke log anda, bukan ke skrin.
• Tukar apa-apa yang bocor. Jika kunci langsung pernah ditampal dalam sembang, commit atau tangkapan skrin, gantikannya di penyedia.

Satu arahan yang meliputi banyak perkara sekaligus:

Semak aplikasi ini untuk keselamatan pengeluaran. Pastikan setiap laluan API mengesahkan bahawa pengguna yang log masuk memiliki rekod yang dibaca atau diubahnya, tiada kunci rahsia dihantar ke pelayar, input disahkan di pelayan, dan log masuk serta tetapan semula kata laluan dihadkan kadarnya. Senaraikan apa yang anda temui sebelum menukar apa-apa.

Meminta senarai dahulu membolehkan anda melihat masalah dan memutuskan susunan, bukannya menerima satu perubahan besar yang tidak terurus.

Langkah 4: Ketahui bila ia rosak — log dan pemantauan

Dalam pratonton anda melihat ralat semasa ia berlaku. Dalam pengeluaran, anda memerlukan aplikasi untuk memberitahu anda. Tiga lapisan, daripada yang paling murah kepada yang paling berguna:

1. Log pelayan. Pastikan ralat direkodkan dengan konteks yang mencukupi untuk diulang semula: laluan mana, ID pengguna mana (bukan kata laluan atau kad mereka), bentuk input apa. Minta AI menambah log berstruktur jika aplikasi hanya mencetak ke konsol.
2. Penjejakan ralat. Perkhidmatan seperti Sentry atau alat yang serupa menangkap pengecualian hadapan dan belakang, mengumpulkannya, dan menghantar e-mel kepada anda. Untuk aplikasi kecil, tier percuma perkhidmatan ini selalunya mencukupi; semak had semasa di laman mereka.
3. Semakan masa operasi. Perkhidmatan luaran yang memuatkan halaman utama anda dan satu laluan API penting setiap beberapa minit dan memberi amaran jika ia gagal. Ini menangkap masalah yang menghentikan aplikasi daripada mencatat log sama sekali.

Tambah satu lagi tabiat: selepas setiap keluaran, buka aplikasi yang hidup dan jalankan senarai semak aliran utama anda pada URL sebenar, bukan hanya pada pratonton.

Langkah 5: Sandaran dan cara untuk kembali

Dua perkara berbeza perlu dilindungi, dan ia mudah dikelirukan.

• Kod. Simpan projek dalam kawalan versi supaya sebarang perubahan boleh dibatalkan. Banyak pembina AI menyimpan titik semak fail anda; menyegerakkan ke repositori Git memberi anda salinan di luar pembina.
• Data. Memulihkan kod tidak memulihkan pangkalan data. Migrasi yang rosak atau butang padam yang bermasalah boleh memusnahkan baris yang tiada titik semak kod akan kembalikan.

Untuk data, sediakan sandaran berkala yang disimpan di tempat selain pengehosan aplikasi — untuk pangkalan data Postgres, pg_dump berjadual ke storan berasingan ialah pendekatan biasa, dan ramai hos pangkalan data terurus menawarkan sandaran automatik atau pemulihan titik-dalam-masa. Kemudian lakukan langkah yang kebanyakan orang terlepas: pulihkan sandaran ke pangkalan data percubaan dan semak data itu ada.

Minta juga AI untuk menjadikan tindakan memusnahkan lebih selamat: langkah pengesahan untuk pemadaman, dan "pemadaman lembut" (menanda baris sebagai dipadam dan bukannya membuangnya) untuk apa-apa yang pengguna mungkin mahu dapatkan semula.

Langkah 6: Prestasi yang bertahan pada telefon

Prototaip terasa pantas kerana anda pengguna tunggal dan set data kecil. Sebelum melancarkan:

• Muatkan data bersaiz sebenar. Minta AI menyemai beberapa ribu baris dan lihat halaman mana yang menjadi perlahan. Senarai biasanya memerlukan pagination dan pangkalan data biasanya memerlukan indeks pada lajur yang anda tapis dan susun.
• Kecilkan imej. Imej yang terlalu besar ialah punca paling biasa halaman lambat dimuatkan. Minta imej yang diubah saiz, dimampatkan dan lazy loading di bawah lipatan.
• Ukur. Jalankan Lighthouse dalam alat pemaju Chrome pada URL hidup dalam mod mudah alih. Core Web Vitals Google ialah sasaran yang munasabah: Largest Contentful Paint dalam masa 2.5 saat, Interaction to Next Paint 200 ms atau kurang, dan Cumulative Layout Shift 0.1 atau kurang.
• Perhatikan kelewatan "bangun". Pengehosan yang tidur apabila tidak aktif menjimatkan wang tetapi menjadikan lawatan pertama selepas tempoh senyap lebih perlahan. Itu selalunya pertukaran yang baik untuk aplikasi baharu; ketahui bahawa ia berlaku.

Halaman projek lambat dengan 5,000 baris. Tambah pagination di pelayan (25 setiap halaman), tambah indeks pangkalan data untuk lajur yang kita tapis dan susun, dan tunjukkan keadaan memuatkan semasa halaman seterusnya dimuatkan.

Langkah 7: Asas operasi

Beberapa perkara kecil membezakan aplikasi hobi daripada aplikasi yang dipercayai orang:

• Domain tersuai dengan HTTPS. Lihat cara menyambungkan domain tersuai.
• E-mel transaksi daripada domain yang disahkan untuk pengesahan pendaftaran dan tetapan semula kata laluan — diliputi dalam cara menghantar e-mel dari aplikasi anda.
• Dasar privasi dan terma yang menerangkan apa sebenarnya yang anda kumpulkan. Jangan salin tuntutan pematuhan yang belum anda capai.
• Laluan sokongan — walaupun alamat e-mel yang dipantau.
• Kunci berasingan untuk ujian dan langsung bagi pembayaran dan e-mel, serta nota yang jelas tentang persekitaran mana menggunakan kunci mana.

Langkah 8: Serah terima yang kemas

Cepat atau lambat, orang lain akan bekerja pada aplikasi itu: seorang pekerja bebas, rakan pengasas baharu, atau anda sendiri enam bulan lagi. Permudahkannya:

• README yang menerangkan cara menjalankannya, pembolehubah persekitaran yang diperlukan (nama sahaja, bukan nilai), dan cara menerbitkannya.
• Senarai semak aliran utama dan ujian automatik.
• Nota seni bina ringkas: bahagian hadapan, bahagian belakang, pangkalan data, perkhidmatan pihak ketiga, dan di mana setiap satu dihoskan.
• Senarai akses: siapa yang mempunyai akses pentadbir kepada domain, pengehosan, pangkalan data, akaun pembayaran dan e-mel. Letakkan akaun ini di bawah e-mel perniagaan, bukan e-mel peribadi.
• Kod dalam Git, sebaiknya disegerakkan ke repositori yang anda miliki. Jika anda mungkin menukar pengehosan kemudian, baca cara mengeksport dan menghoskan sendiri aplikasi yang dibina dengan AI.

AI boleh merangka kebanyakan perkara ini untuk anda:

Tulis README untuk projek ini untuk pemaju yang belum pernah melihatnya: apa yang dilakukan aplikasi, timbunan teknologi, cara menjalankannya secara tempatan, setiap pembolehubah persekitaran yang dibaca (nama dan tujuan sahaja), cara skema pangkalan data disusun, dan cara menerbitkannya.

Senarai semak kesediaan pengeluaran

• Aliran utama ditulis dan diuji, termasuk "tidak boleh mengakses data orang lain"
• Kebenaran dan pengesahan di pelayan pada setiap laluan data
• Tiada kunci rahsia dalam kod hadapan; kunci yang bocor telah ditukar
• Had kadar pada auth dan apa-apa yang menelan kos
• Penjejakan ralat dan amaran masa operasi dihala ke peti masuk yang anda baca
• Sandaran pangkalan data di luar pengehosan aplikasi, dengan satu pemulihan ujian yang berjaya
• Pagination dan indeks diperiksa dengan data yang realistik
• Domain tersuai, domain penghantaran e-mel yang disahkan, dasar privasi
• README dan senarai akses untuk sesiapa yang datang selepas anda

Melakukan ini dengan Mythex

Jika anda membina prototaip dalam Mythex, kebanyakan langkah ini ialah arahan dalam projek yang sama. Taip /test dan Mythex akan mengklik melalui pratonton langsung seperti pengguna dan melaporkan aliran yang rosak — lihat Ujian Aplikasi. Kunci dimasukkan ke dalam rahsia projek dan bukannya sembang, setiap giliran ejen yang berjaya menyimpan titik semak fail anda yang boleh anda kembalikan, dan penerbitan memberi anda URL hidup dengan pengehosan dan pangkalan data yang dibilkan daripada baki kredit yang sama (had pengehosan menerangkan cara aplikasi dan pangkalan data tidur dan bangun). Titik semak meliputi fail, bukan baris pangkalan data, jadi anda tetap perlu merancang sandaran data. Pada Pro, anda boleh menyambungkan domain tersuai dan mengeksport kod atau menyegerakkannya ke repositori GitHub anda sendiri untuk serah terima.

Soalan lazim