Cara Menulis Prompt untuk AI App Builder (Dengan Contoh Sebelum dan Sesudah)
Prompt yang baik untuk AI app builder menggambarkan produknya, bukan kodenya: siapa yang memakainya, apa yang mereka lakukan langkah demi langkah, data apa yang disimpan, dan siapa yang boleh melihat apa. Setelah versi pertama ada, mintalah satu perubahan spesifik per pesan, katakan apa yang harus tetap sama, dan jelaskan masalah dengan format “saya lakukan X, saya harapkan Y, hasilnya Z”. Ketiga kebiasaan ini memperbaiki sebagian besar hasil yang mengecewakan.
Sisa panduan ini menunjukkan pola-pola tersebut secara rinci, dengan contoh sebelum dan sesudah yang bisa Anda sesuaikan.
Mengapa memberi prompt ke app builder berbeda dari mengobrol dengan AI
Saat Anda mengajukan pertanyaan ke asisten chat, prompt yang samar mendapat jawaban yang samar dan Anda lanjut saja. Saat Anda memberi prompt ke AI app builder, hasilnya adalah program yang berjalan. Setiap celah dalam deskripsi Anda diisi dengan tebakan, dan tebakan itu menjadi kode, tabel database, dan layar yang harus Anda jalani atau batalkan.
Jadi tujuan prompt bukan terdengar pintar. Tujuannya meninggalkan lebih sedikit keputusan penting pada kebetulan. Anda tidak perlu kosakata teknis untuk itu. Anda perlu spesifik tentang hal-hal yang hanya Anda ketahui: pengguna, alur kerja, dan aturan Anda.
Apa yang disertakan dalam prompt pertama
Sebelum menulis apa pun, jawab pertanyaan-pertanyaan ini. Setiap pertanyaan menutup celah yang jika tidak akan ditebak AI.
| Sertakan | Mengapa penting | Contoh |
|---|---|---|
| Produknya dalam satu kalimat | Menetapkan kerangka untuk setiap keputusan berikutnya | “Situs pemesanan untuk barbershop dengan dua kursi” |
| Siapa yang memakainya | Menentukan layar dan nada | “Pelanggan walk-in di ponsel, dan pemilik di laptop” |
| Alur utama, langkah demi langkah | Hal yang harus berfungsi lebih dulu | “Pilih layanan, pilih jam, isi nama dan nomor telepon, terima konfirmasi” |
| Data yang disimpan | Menjadi desain database | “Layanan, pemesanan, pelanggan” |
| Siapa yang bisa melihat atau mengubah apa | Menentukan login dan izin akses | “Hanya pemilik yang melihat semua pemesanan” |
| Tampilan dan nuansa, singkat saja | Menghindari gaya default yang generik | “Gelap, sederhana, tombol besar” |
| Apa yang dihilangkan untuk sekarang | Menjaga versi pertama tetap kecil | “Belum ada pembayaran atau ulasan” |
Baris terakhir itu sering diremehkan. Menyebutkan apa yang tidak Anda inginkan mencegah AI menambahkan blog, halaman harga, dan formulir newsletter yang tidak pernah Anda minta.
Sebelum dan sesudah: prompt pertama
Sebelum:
Buatkan saya aplikasi untuk gym saya.
Builder harus menebak semuanya: anggota atau staf? Kelas atau latihan personal? Pembayaran? Anda akan mendapat sesuatu yang terlihat seperti situs gym dan tidak melakukan apa yang Anda butuhkan.
Sesudah:
Buat aplikasi pemesanan kelas untuk studio yoga kecil. Member melihat kelas minggu ini (nama, instruktur, waktu, sisa tempat), memesan tempat, dan membatalkan hingga dua jam sebelumnya. Member mendaftar dengan email dan kata sandi. Pemilik studio login untuk menambah kelas, melihat siapa yang sudah memesan, dan menandai kehadiran. Simpan kelas, member, dan pemesanan di database. Desain tenang dan terang yang nyaman di ponsel. Belum ada pembayaran.
Versi kedua tetap singkat. Ia hanya menjawab pertanyaan dari tabel di atas.
Jelaskan perilaku, bukan implementasi
Sering kali Anda mendapat hasil yang lebih baik dengan mendeskripsikan apa yang seharusnya terjadi, bukan cara membangunnya.
Sebelum:
Tambahkan useEffect yang mengambil data pemesanan dan komponen modal untuk mengedit.
Sesudah:
Saat pemilik mengklik sebuah pemesanan, buka panel tempat mereka bisa mengubah jam atau membatalkannya. Perubahan harus langsung terlihat di daftar.
Prompt pertama mengunci AI pada teknik tertentu yang mungkin tidak cocok dengan cara aplikasi dibangun. Prompt kedua menyebutkan hasilnya dan membiarkan AI memilih pendekatan yang tepat untuk kode yang sudah ada. Jika Anda developer dan memang punya preferensi kuat, sebutkan, tetapi sertakan juga hasilnya.
Spesifik tentang aturan
Aturan bisnis adalah tempat aplikasi buatan AI paling sering salah, karena bagi Anda aturan itu jelas dan bagi AI tidak terlihat. Tuliskan dengan rinci.
- Batasan: “Seorang member paling banyak memegang tiga pemesanan mendatang.”
- Waktu: “Pembatalan ditutup dua jam sebelum kelas dimulai.”
- Kasus tepi: “Jika kelas penuh, tampilkan tombol daftar tunggu, bukan Pesan.”
- Izin akses: “Instruktur bisa melihat kehadiran kelasnya sendiri tetapi tidak kelas instruktur lain.”
Setiap hal di atas cukup satu kalimat. Jika salah satunya terlewat, aplikasi tidak akan menerapkan aturan itu atau akan membuat versinya sendiri.
Setelah versi pertama: satu perubahan per pesan
Setelah sesuatu berjalan di pratinjau, beralihlah dari mendeskripsikan seluruh produk ke meminta perubahan kecil yang bisa dicek.
Sebelum:
Desainnya kurang pas, pemesanannya tidak berjalan dengan benar, dan saya ingin tampilan kalender serta email.
Sesudah (sebagai empat pesan terpisah):
- Saat saya memesan tempat terakhir di sebuah kelas, kelas itu masih menampilkan “sisa 1 tempat”. Seharusnya menampilkan “Penuh” dan menyembunyikan tombol Pesan.
- Tambahkan tampilan kalender mingguan di halaman jadwal, satu kolom per hari. Pertahankan tampilan daftar saat ini sebagai pilihan.
- Buat kartu kelas lebih ringkas di ponsel: padding lebih kecil, nama instruktur di baris yang sama dengan waktu.
- Kirim email konfirmasi ke member saat mereka memesan.
Mengapa ini berhasil:
- Setiap perubahan cukup kecil untuk dikerjakan AI dengan benar dalam sekali jalan.
- Anda bisa menguji setiap perubahan sebelum lanjut.
- Jika satu perubahan salah, Anda bisa mengembalikan langkah itu saja tanpa kehilangan yang lain.
Sebutkan apa yang harus dipertahankan
Saat meminta perubahan pada sesuatu yang sudah berfungsi, katakan apa yang tidak boleh berubah. Ini cara paling mudah untuk mencegah regresi (hal yang dulu berfungsi lalu rusak setelah diedit).
Desain ulang bagian hero halaman depan dengan judul lebih besar dan foto di sebelah kanan. Pertahankan navigasi, warna, dan semua yang ada di bawah hero persis seperti sekarang.
Hal yang sama berlaku untuk data: “Tambahkan field nomor telepon ke member. Jangan hapus atau mengganti nama field yang sudah ada.”
Gunakan tangkapan layar dan teks yang tepat
Kata-kata seperti “yang di atas” itu ambigu. Sebagian besar AI app builder menerima gambar, dan tangkapan layar dengan catatan singkat lebih cepat daripada satu paragraf deskripsi.
- Lampirkan tangkapan layar dan katakan “tombol yang dilingkari merah menutupi menu di ponsel”.
- Tempelkan teks pesan error persis seperti aslinya, jangan diparafrase.
- Kutip label di layar dengan tepat: “tombol Simpan perubahan di halaman Pengaturan”.
Khusus untuk bug, gunakan bentuk ini:
Di halaman pemesanan, saya mengklik Batal pada pemesanan untuk besok. Saya berharap pemesanan itu hilang dari daftar saya. Namun tidak terjadi apa-apa dan pemesanan itu masih ada setelah saya muat ulang. Perbaiki dan pastikan pembatalan berfungsi.
Panduan kami tentang cara men-debug aplikasi buatan AI membahas ini lebih dalam.
Rencanakan dulu untuk perubahan besar
Untuk apa pun yang menyentuh banyak bagian aplikasi — menambahkan akun pengguna ke aplikasi yang belum punya, menambahkan pembayaran, atau mengubah struktur data — mintalah rencana sebelum ada kode yang diubah.
Sebelum mengubah apa pun, jelaskan bagaimana Anda akan menambahkan akun tim: tabel baru apa, halaman mana yang berubah, dan apa yang terjadi pada pengguna yang sudah ada. Jangan edit kode dulu.
Baca rencananya. Jika ada yang salah dipahami, mengoreksi satu paragraf jauh lebih murah daripada mengoreksi fitur yang sudah jadi. Banyak builder punya mode khusus untuk ini; di Mythex, itu mode Plan, bersama Build dan Ask.
Yang sebaiknya dihindari
| Hindari | Mengapa | Sebagai gantinya |
|---|---|---|
| “Buat lebih bagus” / “Biar mencolok” | Tidak ada target, sehingga AI mengubah hal secara acak | Sebutkan perubahannya: “ruang kosong lebih lebar antar bagian, judul lebih besar” |
| Satu prompt raksasa dengan sepuluh fitur | Kesalahan saling menumpuk; sulit diuji | Satu fitur per pesan |
| Menempelkan API key ke chat | Key berakhir di riwayat chat | Gunakan secrets atau pengaturan environment dari builder |
| Berdebat dengan hasil yang rusak | Setiap perbaikan menumpuk di atas bug | Kembalikan, lalu rumuskan ulang |
| Menentukan kode yang tidak Anda pahami | Mengunci kecocokan yang buruk | Jelaskan perilaku yang Anda inginkan |
| Meminta “keamanan kelas enterprise” | Tidak berarti apa-apa secara spesifik | Daftar aturan nyata: siapa boleh melihat apa |
Soal API key: jika Anda membutuhkan layanan pembayaran atau email, simpan key-nya di secrets proyek, bukan di prompt. Lihat apa itu environment variable dan secrets jika ini hal baru bagi Anda.
Template prompt yang bisa dipakai ulang
Sesuaikan dengan mengganti bagian dalam kurung siku.
Aplikasi baru:
Buat [jenis aplikasi] untuk [siapa]. Mereka [alur utama, langkah demi langkah]. [Jenis pengguna kedua] login untuk [apa yang mereka lakukan]. Simpan [data] di database. [Tampilan dan nuansa]. Tinggalkan [hal untuk nanti].
Fitur baru:
Tambahkan [fitur] ke [halaman]. Saat [pengguna] melakukan [aksi], [apa yang seharusnya terjadi]. Hanya [siapa] yang bisa [melakukan itu]. Pertahankan [hal yang sudah ada] seperti sekarang.
Perubahan desain:
Di [halaman], ubah [elemen spesifik] menjadi [perubahan spesifik]. Pertahankan [yang harus tetap]. Pastikan tampilannya benar di layar selebar ponsel.
Bug:
Di [halaman], saya [langkah-langkah]. Saya berharap [yang diharapkan]. Namun [yang terjadi, plus teks error persis]. Perbaiki dan pastikan alurnya berfungsi.
Pertanyaan tanpa perubahan:
Jangan ubah kode apa pun. Jelaskan bagaimana [bagian aplikasi] bekerja dan di mana [data] disimpan.
Menulis spesifikasi yang lebih panjang
Untuk proyek yang lebih besar, sering kali membantu menulis brief satu halaman dulu dan menempelkannya sebagai prompt pembuka: pengguna, alur inti, data, aturan, dan apa yang di luar cakupan. Anda bahkan bisa meminta AI membantu menyusun drafnya — panduan kami tentang cara menulis dokumen kebutuhan produk dengan AI menjelaskan caranya. Cukup batasi permintaan build pertama pada alur inti, dan tambahkan sisanya langkah demi langkah.
Prompt di Mythex
Semua yang dijelaskan di atas berfungsi di Mythex. Beberapa hal spesifik yang membantu:
- Mode Build, Plan, dan Ask. Gunakan Plan untuk perubahan besar atau berisiko dan Ask saat Anda ingin penjelasan tanpa edit.
- Checkpoint. Setelah setiap perubahan yang berhasil, Mythex menyimpan checkpoint, dan Kembali ke titik ini pada sebuah balasan akan mengembalikan proyek. Anda juga bisa mengedit pesan sebelumnya dan mengirim ulang untuk mencoba prompt yang berbeda dari titik itu.
- Kartu secrets. Saat agen membutuhkan API key, ia meminta lewat kartu di chat sehingga nilainya disimpan sebagai secret proyek, bukan ditulis ke pesan Anda.
- Gambar. Lampirkan tangkapan layar atau mockup dan agen akan melihatnya.
Dokumentasi memiliki halaman singkat tentang prompt yang efektif dan satu tentang iterasi tanpa membangun ulang. Jika Anda mulai dari nol, cara membangun aplikasi dengan AI membahas satu proyek penuh, dan cara mendesain aplikasi yang bagus dengan AI membahas prompt untuk poles visual.
Pertanyaan
Seberapa panjang sebaiknya prompt untuk AI app builder?
Untuk versi pertama, satu paragraf pendek berisi empat sampai delapan kalimat biasanya sudah cukup: siapa yang memakai aplikasi, alur utamanya, data yang disimpan, dan siapa yang boleh melihat apa. Setelah itu, prompt yang lebih pendek dan meminta satu perubahan per kali biasanya lebih efektif daripada prompt yang panjang.
Apakah saya perlu memberi tahu AI framework atau bahasa apa yang harus dipakai?
Hanya jika ada alasannya, misalnya ada developer yang akan mengambil alih kode, atau layanan yang hanya bisa bekerja dengan satu stack tertentu. Jika tidak, jelaskan produknya dan biarkan builder memilih default yang masuk akal.
Mengapa AI terus mengubah hal yang tidak saya minta untuk diubah?
Biasanya karena prompt-nya terlalu luas (“buat lebih bagus”) atau tidak menyebutkan apa yang harus dipertahankan. Sebutkan dengan tepat apa yang diubah, katakan apa yang harus tetap sama, dan minta satu perubahan per pesan.
Lebih baik memperbaiki hasil yang buruk dengan prompt tambahan atau mulai dari awal?
Jika perubahan terakhir membuat keadaan lebih buruk, kembalikan ke versi sebelumnya lalu rumuskan ulang, daripada menumpuk perbaikan di atasnya. Mulai proyek baru hanya jika idenya sendiri sudah berubah.