Cara Menulis Prompt untuk Pembina Aplikasi AI (Dengan Contoh Sebelum dan Selepas)
Prompt yang baik untuk pembina aplikasi AI menerangkan produk, bukan kod: siapa yang menggunakannya, apa yang mereka lakukan langkah demi langkah, data apa yang disimpan, dan siapa yang dibenarkan melihat apa. Selepas versi pertama wujud, minta satu perubahan khusus setiap mesej, nyatakan apa yang mesti kekal sama, dan terangkan masalah sebagai "Saya buat X, saya jangka Y, dapat Z". Tiga tabiat ini membetulkan kebanyakan hasil yang mengecewakan.
Baki panduan ini menunjukkan corak itu secara terperinci, dengan contoh sebelum dan selepas yang boleh anda sesuaikan.
Mengapa memberi prompt kepada pembina aplikasi berbeza daripada berbual dengan AI
Apabila anda bertanya kepada pembantu sembang soalan, prompt yang kabur memberi jawapan yang kabur dan anda teruskan. Apabila anda memberi prompt kepada pembina aplikasi AI, jawapannya ialah program yang berjalan. Setiap jurang dalam penerangan anda diisi dengan tekaan, dan tekaan itu menjadi kod, jadual pangkalan data dan skrin yang kemudian perlu anda tanggung atau batalkan.
Jadi matlamat prompt bukanlah untuk kedengaran bijak. Ia adalah untuk meninggalkan lebih sedikit keputusan penting kepada kebetulan. Anda tidak perlukan istilah teknikal untuk itu. Anda perlu tepat tentang perkara yang hanya anda tahu: pengguna anda, aliran kerja dan peraturan anda.
Apa yang perlu dimasukkan dalam prompt pertama
Sebelum menulis apa-apa, jawab soalan-soalan ini. Setiap satu menutup jurang yang AI jika tidak akan meneka.
| Masukkan | Sebab ia penting | Contoh |
|---|---|---|
| Produk dalam satu ayat | Menetapkan rangka untuk setiap keputusan kemudian | "Laman tempahan untuk kedai gunting rambut dengan dua kerusi" |
| Siapa yang menggunakannya | Menentukan skrin dan nada | "Pelanggan jalan masuk di telefon, dan pemilik di komputer riba" |
| Aliran utama, langkah demi langkah | Perkara yang mesti berfungsi dahulu | "Pilih perkhidmatan, pilih masa, masukkan nama dan telefon, dapat pengesahan" |
| Data yang disimpan | Menjadi reka bentuk pangkalan data | "Perkhidmatan, tempahan, pelanggan" |
| Siapa boleh lihat atau ubah apa | Menentukan log masuk dan kebenaran | "Hanya pemilik melihat semua tempahan" |
| Rupa dan rasa, ringkas | Mengelak gaya lalai yang generik | "Gelap, ringkas, butang besar" |
| Apa yang ditinggalkan buat masa ini | Memastikan versi pertama kecil | "Tiada bayaran atau ulasan lagi" |
Baris terakhir itu sangat diabaikan. Menyatakan apa yang tidak anda mahu menghalang AI daripada menambah blog, halaman harga dan pendaftaran surat berita yang tidak pernah anda minta.
Sebelum dan selepas: prompt pertama
Sebelum:
Buatkan saya aplikasi untuk gim saya.
Pembina terpaksa meneka semuanya: ahli atau kakitangan? Kelas atau latihan peribadi? Pembayaran? Anda akan dapat sesuatu yang kelihatan seperti laman web gim tetapi tidak melakukan apa yang anda perlukan.
Selepas:
Bina aplikasi tempahan kelas untuk studio yoga kecil. Ahli melihat kelas minggu ini (nama, guru, masa, tempat kosong), menempah tempat, dan membatalkan sehingga dua jam sebelum. Ahli mendaftar dengan e-mel dan kata laluan. Pemilik studio log masuk untuk menambah kelas, melihat siapa yang telah ditempah, dan menandakan kehadiran. Simpan kelas, ahli dan tempahan dalam pangkalan data. Reka bentuk yang tenang, cerah dan berfungsi baik di telefon. Tiada pembayaran lagi.
Versi kedua masih pendek. Ia hanya menjawab soalan-soalan dalam jadual di atas.
Terangkan gelagat, bukan pelaksanaan
Anda selalunya akan mendapat hasil yang lebih baik dengan menerangkan apa yang sepatutnya berlaku dan bukannya bagaimana untuk membinanya.
Sebelum:
Tambah useEffect yang mengambil tempahan dan komponen modal untuk menyunting.
Selepas:
Apabila pemilik mengklik satu tempahan, buka panel di mana mereka boleh menukar masa atau membatalkannya. Perubahan perlu dipaparkan serta-merta dalam senarai.
Prompt pertama mengunci AI kepada teknik tertentu yang mungkin tidak sesuai dengan cara aplikasi dibina. Prompt kedua memberitahu hasilnya dan membiarkan AI memilih pendekatan yang betul untuk kod yang sudah ditulisnya. Jika anda seorang pembangun dan memang ada pilihan yang kuat, nyatakannya, tetapi pasangkan dengan hasilnya.
Jadilah konkrit tentang peraturan
Peraturan perniagaan ialah tempat aplikasi yang dibina AI paling kerap tersasar, kerana ia jelas bagi anda tetapi tidak kelihatan kepada AI. Nyatakannya dengan terperinci.
- Had: "Seorang ahli boleh memegang paling banyak tiga tempahan akan datang."
- Masa: "Pembatalan ditutup dua jam sebelum kelas bermula."
- Kes tepi: "Jika kelas penuh, tunjukkan butang senarai menunggu dan bukannya Tempah."
- Kebenaran: "Guru boleh melihat kehadiran kelas mereka sendiri tetapi bukan kelas guru lain."
Setiap satu ialah satu ayat. Jika anda meninggalkan mana-mana daripadanya, aplikasi itu sama ada tidak akan menguatkuasakan peraturan itu atau mereka-reka versinya sendiri.
Selepas versi pertama: satu perubahan setiap mesej
Setelah sesuatu berjalan dalam pratonton, beralih daripada menerangkan keseluruhan produk kepada meminta perubahan kecil yang boleh disemak.
Sebelum:
Reka bentuknya tidak kena, tempahan tidak berfungsi dengan betul dan saya mahu paparan kalendar serta e-mel.
Selepas (sebagai empat mesej berasingan):
- Apabila saya menempah tempat terakhir dalam kelas, ia masih menunjukkan "1 tempat lagi". Ia sepatutnya menunjukkan "Penuh" dan menyembunyikan butang Tempah.
- Tambah paparan kalendar minggu pada halaman jadual, satu lajur untuk setiap hari. Kekalkan paparan senarai semasa sebagai pilihan.
- Jadikan kad kelas lebih padat di telefon: padding lebih kecil, nama guru pada baris yang sama dengan masa.
- Hantar e-mel pengesahan kepada ahli apabila mereka menempah.
Mengapa ini berkesan:
- Setiap perubahan cukup kecil untuk AI betulkan dalam satu laluan.
- Anda boleh mengujinya sebelum meneruskan.
- Jika satu salah, anda boleh kembali hanya langkah itu tanpa kehilangan yang lain.
Nyatakan apa yang perlu dikekalkan
Apabila anda meminta perubahan kepada sesuatu yang sudah berfungsi, beritahu AI apa yang tidak boleh berubah. Ini ialah cara paling mudah untuk menghentikan regresi (perkara yang dahulunya berfungsi rosak selepas suntingan).
Reka bentuk semula bahagian hero halaman utama dengan tajuk yang lebih besar dan gambar di sebelah kanan. Kekalkan navigasi, warna dan semua yang berada di bawah hero tepat seperti sekarang.
Perkara yang sama terpakai untuk data: "Tambah medan nombor telefon kepada ahli. Jangan buang atau namakan semula mana-mana medan sedia ada."
Gunakan tangkapan skrin dan teks tepat
Perkataan seperti "perkara di atas" adalah samar. Kebanyakan pembina aplikasi AI menerima imej, dan tangkapan skrin dengan nota ringkas lebih pantas daripada perenggan penerangan.
- Lampirkan tangkapan skrin dan katakan "butang yang dibulatkan merah bertindih dengan menu pada telefon".
- Tampal teks tepat mana-mana mesej ralat dan bukannya memparafrasanya.
- Petik label pada skrin dengan tepat: "butang Simpan perubahan pada halaman Tetapan".
Untuk bug khususnya, gunakan bentuk ini:
Di halaman tempahan, saya klik Batal pada tempahan untuk esok. Saya jangka ia hilang daripada senarai saya. Sebaliknya tiada apa berlaku dan tempahan masih ada selepas muat semula. Betulkannya dan semak yang pembatalan berfungsi.
Panduan kami tentang cara nyahpepijat aplikasi yang dibina AI menyelami perkara ini dengan lebih mendalam.
Rancang dahulu untuk perubahan besar
Untuk apa-apa yang menyentuh banyak bahagian aplikasi — menambah akaun pengguna kepada aplikasi yang tiada akaun, menambah pembayaran, menukar cara data disusun — minta pelan sebelum sebarang kod diubah.
Sebelum menukar apa-apa, terangkan cara anda akan menambah akaun pasukan: jadual baharu apa, halaman mana yang berubah, dan apa yang berlaku kepada pengguna sedia ada. Jangan sunting kod lagi.
Baca pelan itu. Jika ia salah faham sesuatu, membetulkan satu perenggan jauh lebih murah daripada membetulkan ciri yang sudah siap. Ramai pembina mempunyai mod khas untuk ini; di Mythex ia ialah mod Plan, bersama Build dan Ask.
Apa yang perlu dielakkan
| Elakkan | Sebab | Sebaliknya |
|---|---|---|
| "Jadikan lebih baik" / "Jadikan ia menarik" | Tiada sasaran, jadi AI menukar perkara secara rawak | Namakan perubahannya: "lebih banyak ruang antara bahagian, pengepala lebih besar" |
| Satu prompt besar dengan sepuluh ciri | Ralat bertambah; sukar diuji | Satu ciri setiap mesej |
| Menampal kunci API dalam chat | Kunci berakhir dalam sejarah chat | Gunakan rahsia atau tetapan persekitaran pembina |
| Bertekak dengan hasil yang rosak | Setiap pembetulan menindih bug | Kembali, kemudian ungkapkan semula |
| Menentukan kod yang anda tidak fahami | Mengunci padanan yang lemah | Terangkan gelagat yang anda mahu |
| Meminta "keselamatan gred perusahaan" | Tidak bermakna secara khusus | Senaraikan peraturan sebenar: siapa boleh lihat apa |
Mengenai kunci API: jika anda memerlukan perkhidmatan pembayaran atau e-mel, letakkan kuncinya dalam rahsia projek dan bukannya dalam prompt. Lihat apa itu pembolehubah persekitaran dan rahsia jika ini baharu bagi anda.
Templat prompt boleh guna semula
Sesuaikan ini dengan menggantikan bahagian dalam kurungan.
Aplikasi baharu:
Bina [jenis aplikasi] untuk [siapa]. Mereka [aliran utama, langkah demi langkah]. [Jenis pengguna kedua] log masuk untuk [apa yang mereka buat]. Simpan [data] dalam pangkalan data. [Rupa dan rasa]. Tinggalkan [perkara untuk kemudian].
Ciri baharu:
Tambah [ciri] pada [halaman]. Apabila [pengguna] melakukan [tindakan], [apa yang sepatutnya berlaku]. Hanya [siapa] boleh [lakukannya]. Kekalkan [perkara sedia ada] seperti sekarang.
Perubahan reka bentuk:
Pada [halaman], tukar [elemen khusus] kepada [perubahan khusus]. Kekalkan [apa yang perlu dikekalkan]. Semak ia kelihatan betul pada skrin lebar telefon.
Bug:
Pada [halaman], saya [langkah]. Saya jangka [dijangka]. Sebaliknya [sebenar, serta teks ralat tepat]. Betulkannya dan sahkan aliran itu berfungsi.
Soalan tanpa perubahan:
Jangan ubah sebarang kod. Terangkan cara [bahagian aplikasi] berfungsi dan di mana [data] disimpan.
Menulis spesifikasi yang lebih panjang
Untuk projek yang lebih besar, ada baiknya menulis ringkasan satu halaman dahulu dan tampalnya sebagai prompt pembukaan anda: pengguna, aliran utama, data, peraturan dan apa yang di luar skop. Anda juga boleh meminta AI membantu mendraf, panduan kami tentang cara menulis dokumen keperluan produk dengan AI menerangkan caranya. Cukup kekalkan permintaan binaan pertama pada aliran teras, dan tambah selebihnya langkah demi langkah.
Prompt dalam Mythex
Semua yang di atas berfungsi dalam Mythex. Beberapa perkara khusus yang membantu:
- Mod Build, Plan dan Ask. Gunakan Plan untuk perubahan yang besar atau berisiko, dan Ask apabila anda mahukan penjelasan tanpa suntingan.
- Titik semak. Selepas setiap perubahan yang berjaya, Mythex menyimpan titik semak, dan Revert to this point pada sesuatu balasan memulihkan projek. Anda juga boleh menyunting mesej terdahulu dan menghantarnya semula untuk mencuba prompt yang berbeza dari titik itu.
- Kad rahsia. Apabila ejen memerlukan kunci API, ia meminta melalui kad dalam chat supaya nilainya disimpan sebagai rahsia projek dan bukannya ditulis dalam mesej anda.
- Imej. Lampirkan tangkapan skrin atau mockup dan ejen akan melihatnya.
Dokumentasi mempunyai halaman ringkas tentang prompt yang berkesan dan satu tentang mengulang tanpa membina semula. Jika anda bermula dari kosong, cara membina aplikasi dengan AI menerangkan projek penuh, dan cara mereka bentuk aplikasi yang kelihatan baik dengan AI merangkumi prompt untuk penggilapan visual.
Soalan lazim
Berapa panjang prompt untuk pembina aplikasi AI sepatutnya?
Untuk versi pertama, satu perenggan pendek empat hingga lapan ayat biasanya mencukupi: siapa yang menggunakan aplikasi, aliran utama, data yang disimpan dan siapa yang boleh melihat apa. Selepas itu, prompt yang lebih pendek yang meminta satu perubahan pada satu masa berfungsi lebih baik daripada prompt yang panjang.
Patutkah saya beritahu AI rangka kerja atau bahasa yang hendak digunakan?
Hanya jika anda ada sebab, seperti pembangun yang akan mengambil alih kod atau perkhidmatan yang hanya berfungsi dengan satu tindanan teknologi. Jika tidak, terangkan produk dan biarkan pembina memilih lalai yang munasabah.
Mengapa AI terus menukar perkara yang saya tidak minta untuk ditukar?
Biasanya kerana prompt itu luas ("jadikan lebih baik") atau tidak menyatakan apa yang perlu dikekalkan. Namakan perkara tepat yang hendak ditukar, nyatakan apa yang mesti kekal sama, dan minta satu perubahan setiap mesej.
Adakah lebih baik membetulkan hasil yang buruk dengan lebih banyak prompt atau mulakan semula?
Jika perubahan terakhir menjadikan keadaan lebih teruk, kembali ke versi sebelum itu dan ungkapkan semula, daripada menindih pembetulan di atas bug. Mulakan projek baharu hanya apabila idea itu sendiri telah berubah.